AI writes the code. Deciding what to build is still the job.

Most of the code behind this blog was written by AI coding agents working in the repo. The editor these posts are written in, the comments, the sign-in. It went from an empty folder to production in about a day. I reviewed what came back and made the decisions.

Watching that up close changed how I think about what AI does to this work. It makes writing code nearly free. The harder part, deciding what the code should be, is still there, and it is now most of what is left.

What vibe coding is good at

In February 2025 Andrej Karpathy named a new way of working. He called it vibe coding, where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." You describe what you want, accept what the model writes, and paste the error back in when something breaks.

The agents that built this blog worked close to that, with more reviewing than Karpathy's version allows, and they were excellent at it. They wired forms to APIs and renamed things across the whole codebase without missing a file. Work that used to take an afternoon took minutes.

Brooks drew this line in 1986

Fred Brooks split the difficulty of building software into two kinds in his essay No Silver Bullet. The accidental part is the labor of expressing a design in code and getting the machine to accept it. The essential part is the design itself. In his words, the hard part is "the specification, design, and testing of this conceptual construct, not the labor of representing it."

His argument was arithmetic. If accidental work is less than nine tenths of the total, then even shrinking it to zero cannot make software ten times cheaper. The essential part is still there.

Nearly forty years later, AI is the closest thing yet to shrinking the accidental part to zero. Typing code costs almost nothing now. Brooks's arithmetic says that is exactly why the essential part becomes most of the job.

How fast it felt, and how fast it was

In 2025 the research group METR ran a randomized trial with experienced open source developers working in their own mature codebases. Before starting, the developers expected AI tools to make them 24% faster. Afterwards they believed they had been about 20% faster. Measured, they took 19% longer.

Those were early 2025 tools, and METR has since said its newer data is too noisy to give a reliable number and that developers are probably sped up more today. I would not build an argument on the 19%. The part I find useful is the gap between what people felt and what the clock said. Watching code appear quickly is very satisfying. It tells you nothing about whether it is the right code.

What the agents missed

This blog's editor shipped with its tests passing. A later review found two gaps. Phones rarely fire the event a browser sends before you leave a page, so switching apps in the middle of a post could lose the last few sentences. And many photos taken on a phone were larger than the upload limit, so adding a picture from a phone would often fail.

The code did what it was asked. Nobody had asked what should happen when a phone leaves the page, or how big a phone photo is. Those are questions about the specification, which is the essential part Brooks was talking about. AI is very good at writing the code. Deciding what the code should be is still the job.

Where the decisions live now

What fixed it was writing the decisions down where the agents can read them, because an agent starts every session with no memory of the last one.

In this repo that means a handful of plain files. A rules file every agent reads before touching anything. Before any code, an agent interviews me about the feature and writes its questions into a file, and I answer there. Decisions that are hard to reverse get a short decision record, a habit Michael Nygard described in 2011 so that "the motivation behind previous decisions is visible for everyone, present and future." A spec turns into small tickets with acceptance criteria, and a test suite has to pass before anything ships.

None of this is new. Teams have written these documents for decades, mostly for the next person who joins. What changed is that the next person who joins is an agent, every single session. When one session dies halfway through a ticket, the next one reads the files and carries on.

Where I still just vibe

All of this is slower than pure vibe coding, and sometimes that is the wrong trade. For a throwaway prototype or a one-off script I skip all of it. If it breaks, I lose an afternoon.

My line is data someone would be upset to lose, like a post or a payment. Once a system holds that, a missing decision costs more than an afternoon, and I want the decisions written down before the code.

If you build with agents, I am curious what they keep missing for you.

References

• Andrej Karpathy, the post that named vibe coding, 2 February 2025.

• Frederick P. Brooks Jr., No Silver Bullet: Essence and Accident in Software Engineering, 1986.

• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 2025, and the February 2026 update on why the newer data is unreliable.

• Michael Nygard, Documenting Architecture Decisions, November 2011.