AI coding is a nightmare. Am I the only one experiencing this?

  try:
    something_that_should_not_fail_and_if_it_does_our_assumptions_are_all_wrong()
  except:
    fallback_that_will_not_result_in_correct_behavior_but_make_failure_hard_to_detect()

Scope adjudication is extremely important in vibe coding, or agent can easily break your whole system with not applicable features.

For any issue, start a brand new context, point it to the spec, explain the issue and explain if it's a regression.

Also on it might seem like an obvious one, the more test coverage you have, the more your llm can tell if something has broken or if there's been a regression without needing to eat up context.

All of these things can help but there's no perfect solution.

i use the skills /yaw-review excessively sometimes multiple times in a row on the same pr or session. followed by most often /yaw-address-all and then /yaw-coverage to add tests and /yaw-ship-ready to make production ready.

after a few rounds of these they are not needed every time on the same codebase.

if you are desperately wishing programming to go back to the before times it will never. or it will always be there but expect to be incredibly less productive than your peers.

Problem 1: "Obsessed with reinventing the wheel" " three duplicate functions":

Suggestion: plan then implement.

Tell LLM to scan your project and crete markdown file plan to solve the task first. DO NOT try to selve tasks in a single shot without planning. Review the plan file then, IN A NEW SESSION with clean context, tell LLM to read the implementation plan file and implement the plan according to the file.

---

Problem 2: "hyper-focuses on the current task and couldn't care less if its changes break other parts of the system"

Suggestion: add instructions to AGENTS.md file teaching LLMs how to run unit tests and other kinds of tests so it can make sure nothing broke. And also add to AGENTS.md that LLMs MUST run tests before marking the task done.

---

Problem 3: "you'll hit the 200k token limit in no time" "Long context = instant brain damage"

Suggestion: use 1 million context window LLMs. Also plan then implement will keep your context shorter.

If you can, use better LLM services which offer 1million context window. If you can't afford Anthropic or OpenAI, use DeepSeek V4 Flash or MiMo 2.5 for example. A $10/mo OpenCode Go subscription plan offers $60 in LLM credits which is A LOT for these cheap LLMs.

Also, planning phase is when the LLM has to scan the entire project to understand what needs changing. This is where the context bloat comes from. If you split tasks into planning + implementation, the scanning phase is condensed into a single markdown file which keeps context lean.

Bonus tip: Tell LLMs to use subagents when doing exploration.

---

Problem 4: The longer the context, the more incoherent its responses.

Suggestion: yeah, LLMs get dumber as their working memory fills up (just like me). If your session reaches 200k+ tokens, it's usually a sign you could have planned the feature better or split it up. It might be worth restarting with more clarification.

Did you ask it to delete stuff or consolidate functionality? Did you ask it to reuse certain available implementations? Or do you use it as a black box, letting it do all the design and code, and not caring to steer it, except with some high level request ("build x")?

If it's the latter, if we treat a (non-actually-intelligent, generative) AI as a hands-off developer and remove ourselves from the loop, we get exactly what you mention in the rant.

But nothing forces us to use it like this (except the craze of "vibe coding"). Use it as a carefully monitored and steered coding assistant.

It's slower that way? That slowness is a requirement to ingest the expertise/knowledge/taste of a human developer in the mix. It's what avoids an avalance of slop to be commited and become part of the codebase unchecked.

That's why all the focus on maximazing speed, and removing the humans from the loop, are misguided.

When LLMs are ready to removed humans from the loop, we'll know: we'd be out of a job. As long as we have one, our role is to act as a quality bottlenect, not to open the floodgates.

- "It hyper-focuses on the current task and couldn't care less if its changes break other parts of the system." - "Long context = instant brain damage"

This is why I quickly discovered that I had to turn AI into a knowledgable, patient tutor rather than let it code for me. I am thoroughly at the helm for all decisions big and small - I don't let AI touch the code anymore.

this is where i start (c2l code i translate at https://c2l.puter.site):

define..sq.x[* x x

(define (sq x) (* x x))

ai step:

translate this code to python

I don't believe the "you are holding it wrong", "works on my machine", "works on this model" or "do this spec structure" type of arguments to compensate the fundamental issues. The tech simply does not do what is advertised and claimed as it is.

I’m serious. Treat it like any other tool. When it helps solves problems, use it. When it makes problems, don’t use it.

There are a lot of people and an enormous amount of money trying to make hands off agentic happen, but the happiest and most effective enthusiasts I know do not give up control: they go function by function and class by class, generating or writing as they see fit.

The goal is to make useful software. At least, I think that’s still true?