Code got cheap in 2026. Knowing what to build did not.

In 1986 Fred Brooks wrote that the hardest single part of building a software system is deciding precisely what to build. For forty years that was an engineer’s problem. Now anyone can describe an idea to an AI agent and get working code back, so it has become everyone’s problem.

People always worked from incomplete requirements. It was fine: whoever wrote the code had also sat in the meetings, and filled the gaps from memory.

An agent was not in your meetings. It fills the gaps as well, with confident guesses. You find out when the product does something nobody asked for, or quietly stops doing something it did yesterday.

This is no longer a niche concern. This summer JetBrains asked more than 15,000 professional developers how they produced last month’s code. On average, agents alone wrote about 47% of it. Nearly a third of developers already leave about 84% of their code to agents.

Checking has not kept up. In Sonar’s 2026 survey, 96% of developers said they do not fully trust AI-generated code, yet only 48% always verify it before committing.

We build tools for agent-driven development, and we develop them with those same tools. The first lesson arrived before any code did: the bottleneck has moved. Producing code is cheap. Knowing exactly what should exist, in a form you can hand to a machine, is not.

The industry has noticed. In 2026 tools for telling an agent what to build moved from experiments into everyday use. GitHub’s Spec Kit, a toolkit for writing the specification before the code, passed 116,000 stars by June. AGENTS.md, a plain file of instructions for coding agents, is now in more than 60,000 open-source projects and has moved under the Linux Foundation. A whole class of memory tools for agents has appeared alongside them.

These are first-generation answers, and each covers part of the problem. In the next posts I will go through what they do well, where they stop, and what we learned building our own.