It is hiring season again, and I have been reading a stack of CVs that all say some version of the same thing: “proficient in AI-assisted development”. In interviews, candidates live-code impressively fast. The autocomplete hums, the boilerplate appears, the endpoint compiles. Then I ask them to trace a null pointer through three layers of a Spring service they did not write, and the room goes quiet.

I am not complaining about the tools. I use them every day and I am not giving them up. But somewhere between the demos and the hiring loops, we seem to have confused typing code with understanding systems. Those were never the same skill, and the gap between them is now the whole game.

The numbers back up the unease. Last summer METR ran a randomized trial with sixteen experienced open-source developers on their own mature repositories, mostly using Cursor with Claude 3.5 and 3.7 Sonnet. Developers expected a 24% speedup. They took 19% longer with AI enabled — and afterwards still believed the tools had made them 20% faster. They accepted less than 44% of the generated code untouched. And in last year’s Stack Overflow survey of over 49,000 developers, the top frustration, cited by 66%, was “AI solutions that are almost right, but not quite”, with 45% saying debugging AI-generated code takes more time. Usage keeps climbing while trust keeps falling.

The first planning week of the year is when everybody is brave. Roadmaps are fresh, the release calendar has that new-calendar smell, and someone always puts “clean up the user table” on the board like it is a half-day task. Renaming a column sounds trivial. It is one line of SQL. What could it possibly do?

Quite a lot, as I learned on an otherwise ordinary release train. The rename itself took milliseconds. The rolling deploy around it took down nothing and broke something subtler: for about ten minutes, old pods and new pods were serving traffic against the same database, disagreeing about what a column was called. Nobody paged. The errors just quietly piled up in the logs until support started forwarding screenshots. That morning taught me the rule I have followed ever since: never change the schema in one step when two versions of your code will ever meet it.

Not long ago, I watched a teammate’s agent loop burn through $2,300 in API calls overnight. The task? Classifying support tickets into three buckets. The model? GPT-4o. Every single ticket — even the “reset my password” ones — got the full frontier treatment.

That’s the trap. When you first get API access to a reasoning model, it feels like a superpower. You start reaching for it everywhere. Why wouldn’t you? It’s smarter, it reasons, it gets the hard stuff right. But somewhere between the demo and the production bill, the economics invert. You’re paying premium prices for commodity work.

Every few months this field renames something and half of us roll our eyes. This time I think the rename earns its keep. In late June, Andrej Karpathy came out in favor of “context engineering” over “prompt engineering”, describing it as “the delicate art and science of filling the context window with just the right information for the next step”. Shopify’s CEO Tobi Lütke had been pushing the same term as a core skill, Simon Willison endorsed it within days, and by the end of September Anthropic had shipped an entire engineering guide called Effective context engineering for AI agents. When that many practitioners converge inside one summer, a word has usually caught up with reality.

Here is my confession. I have spent much of the past year building chatbots and RAG pipelines at work, and a good share of my “prompt engineering” sessions were me fiddling with wording while the real problem sat somewhere else entirely: stale chat history, retrieved chunks nobody asked for, tool output dumped three turns ago still squatting in the window. The prompt was never the whole system. Naming the rest of it is oddly liberating.

Every coding agent I have picked up this summer has asked me the same question in a different accent. Codex CLI goes looking for an AGENTS.md. Gemini CLI wants a GEMINI.md. Claude Code reads CLAUDE.md. Cursor keeps its own rules folder. Four tools, four filenames, one identical need: tell me how this repo works before you let me loose in it.

A few weekends ago I opened one of my side projects and counted the instruction files piled up in the root. Three of them. All saying roughly the same thing in three dialects. That is when it clicked: my repos need onboarding documents for robots now, the same way they have always needed a README for humans.

Sometime in early February, Andrej Karpathy finally gave the thing a name. Vibe coding, he called it — giving in to the vibes, embracing exponentials, and forgetting that the code even exists. Four months later the phrase is everywhere, and like most catchy terms it is doing real work: it separates “I reviewed every line” from “I typed a prompt and it ran”.

And the tools caught up faster than anyone expected. Two weeks ago OpenAI put Codex into ChatGPT as a research preview — a cloud agent that takes your repository, works on tasks in its own sandbox, and opens pull requests for you to look at. Claude Code arrived as a terminal agent back in February. Copilot quietly grew an agent mode too. Meanwhile Y Combinator’s Garry Tan said that for about a quarter of their Winter ‘25 batch, 95% of the code was written by LLMs. Not a typo, apparently.

Here is my honest position after a few months of living like this: generating code has stopped being the bottleneck. Reading it is. And that flips a lot of assumptions about what code review is for.