--- title: 'Code is no longer the bottleneck. Deciding what to build is. — Flagridge' description: 'Agents can already write code around the clock. To use it, a team needs a steady flow of requirements, which product engineers give; the next bottleneck is quality, which platform engineers widen.' url: 'https://flagridge.com/blog/bottleneck-moves-to-requirements' type: 'post' template: 'blog-post' language: 'en' date: '2026-11-10' --- # Code is no longer the bottleneck. Deciding what to build is. > Agents can already write code around the clock. To use it, a team needs a steady flow of requirements, which product engineers give; the next bottleneck is quality, which platform engineers widen. Primary action: [Talk to us](https://flagridge.com/enterprise#contact) Our product engineer Alex has had agents writing code around the clock for about three months. At night the code keeps coming. The question is no longer how to write it faster. The question is what the agents will work on tomorrow night. That is the shift we see. The order of the work did not change: market, requirements, architecture, code, quality. What changed is where the work waits. For years it waited on the code. Now the code is fast, and the work waits on the decision what to build and what not to build. ## The code already runs at night Alex's setup is good, and it still drifts. One badly worded requirement, and the agent forgets to connect the front end to the back end and builds an interface for itself. In another run it started 25 Docker containers to test the database 25 times. Once the agents moved the tests from Vitest to Jest, and nobody decided that. His own conclusion is not "agents write code faster". They do not, by much. The gain is how much runs in parallel. And parallel work needs a lot of work to run: a queue of clear requirements that is long enough for the night. So we can write code around the clock. To use it, a team needs a steady flow of requirements. ## The bottleneck is the decision, not the code A long requirements document does not solve this. A document that says yes to everything gives the agents more work, not better work. The scarce part is the decision: which change goes in, which stays out, and which technical decision holds it together. The decision costs more now for a simple reason. An error early in the chain grows at every later stage, and at the end of the chain is code, which is expensive to rebuild. ![An error at the start grows to the end of the chain](https://flagridge.com/_astro/error-chain.light.DULhjHPQ.svg) People used to have a buffer against this. During a break, a developer would sometimes understand that something was wrong, or get a better idea. Agents have no such break. They answer almost at once, so the person who runs them loses that pause too. A misunderstanding caught in hour one is a sentence; the same misunderstanding caught after four automated cycles is a teardown. AI also made each role faster, but not the handoff between roles. When the handoff is a vague request, every fast role after it works fast on the wrong thing. ## A steady flow of requirements needs product engineers Someone has to produce that flow, and it cannot be a chain of handoffs. This is the work of a [product engineer](https://flagridge.com/blog/who-is-product-engineer): one person who owns a product capability end to end, from the requirements and the technical plan to the review of what the agents built. The unit of that work is the work package: one whole change to a capability of the product, with every change it needs on every platform. In Flagridge, the analyst role turns a change request into requirements and acceptance criteria, the architect role adds the decisions under the same ID, and the agents implement only that scope. Other teams call this a changeset or a dev plan. We call it a work package because it traces from the request to the code and back, and it delivers value. This is also how a team gets fewer rejections at review. Fix the task statement, not only the result. A result that gets patched while its statement stays wrong will go wrong again at each later stage. When a result is rejected, the trace shows where it broke: in the code, in the design or in the requirement. ## Then quality becomes the bottleneck Once the requirements are as wide as the code, the queue moves to the end of the chain. Thoughtworks sees the same in Technology Radar Vol. 35: "As developers run more agents, their attention and review capacity become bottlenecks" ([Thoughtworks Technology Radar](https://www.thoughtworks.com/radar)). Widening that part is the work of platform engineers. They make the conveyor work without bugs and without manual changes to the code. It is a separate job for a reason: when one person owns both the product and the harness (the agent and skill definitions and the tools around them), they switch to tuning the harness too often, and the product waits. ## Infrastructure is the bottleneck only for frontier innovators Anthropic sees the bottleneck elsewhere: "all of the developer infrastructure built for human scale: source control, builds, and CI". At their volume, merged changes grew from about 2,500 a day in May to more than 30,000 a day in September ([Anthropic](https://www.anthropic.com/research/redesigning-source-control)). For frontier innovators, that is true. Their work is almost all the creation of something new, they get large investments, and they run a very large number of A/B tests. It is not true for a regulated company or for a mid-size business. Their need is to develop what already exists. For them, the work waits on the decision, not on the builds. ## What we do not know yet We do not have a good way to check the quality of the requirements themselves. A test for code is clear. A test for a markdown file is not. Today a person approves the work package and the trace shows where a result went wrong, but that is a check after the fact. The agents can work all night. Whether the night is worth it is decided in the afternoon. --- HTML: https://flagridge.com/blog/bottleneck-moves-to-requirements Markdown: https://flagridge.com/blog/bottleneck-moves-to-requirements.md