During one recent sprint I ran a small experiment. Instead of assigning a routine bug ticket to a teammate, I assigned it to our coding agent. Twenty minutes later, while I was still in standup, a draft pull request opened itself: commits pushed, checks running, a tidy checklist of what it intended to do. Nobody typed anything. The backlog had effectively started opening its own pull requests.

I have written before about reading AI-generated diffs and about repo instructions for coding agents, but those were about the inner loop, me at the keyboard with an agent beside me. Background agents are a different animal. They change not how I code, but how work flows through the whole team. Somewhere along the way my issue tracker quietly turned into a job queue.

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.

The DeepSeek-R1 release in January felt like a moment. Not just because a Chinese lab dropped an open-weight reasoning model that matches o1 on benchmarks — but because they released the whole family. Six distilled models, from 1.5B to 70B parameters. MIT license. API pricing that makes o1 look expensive. And critically, the community had GGUF quantizations ready within days.

I’ve been running local LLMs since the llama.cpp early days. My daily driver is a Lenovo IdeaPad 3 with a Core i3-1115G4 and 16 GB of RAM. No discrete GPU. Just integrated graphics and system memory. It’s the kind of machine most developers actually have, not the 4090 rigs you see in benchmark posts.

So when the DeepSeek-R1 distilled models landed, the question wasn’t theoretical. Could I run a reasoning model — one that actually shows its chain of thought — on this thing?