Agentic Development, Part 1 How do you develop software when agents write the code? Not someday. Now. Within a few weeks, my solo open-source project had more than 100 open issues. At the same time, an AI agent team was producing pull requests faster than I could properly review them. I had automated implementation, but not delivery. I had increased the capacity of the wrong part of the system. That was when I realized that agentic development is not simply faster Agile. It changes the bottleneck on which the whole development process has to be built. Agile solved a different problem Waterfall-shaped development made change slow and expensive. Releases were planned months ahead. Features felt carved in stone, and feedback or bug-fix loops often came late in the release. Scrum, Kanban, and the broader Agile movement addressed exactly those pain points. They shortened planning horizons, reduced batch sizes, and made it possible to react while development was still in progress. That was a necessary step, and software development is better for it. But these methods still grew around human teams working at human speed. Coding is not the whole of software development, but implementation used to consume a large part of its time and capacity. A team could only implement so much during a sprint. Planning, implementation, review, and acceptance operated at roughly compatible speeds. Agents break that capacity model. A human can now send several agents into the same codebase, or orchestrate a specialized team that plans, implements, tests, reviews, and reworks an issue. Execution can happen in parallel and continue as long as work is available. Work that previously filled a sprint can now be completed in hours. A sprint backlog can become outdated while a human is still reviewing the first results. The cadence no longer controls execution. Completed work arrives as a continuous stream. Human attention does not scale with it. The result is not just a shorter sprint. It is a different production system. Implementation becomes cheap and elastic, while intent, judgment, review, and responsibility remain scarce. Scrum does not scale to that situation. It was not designed for it. The system I built To be clear, most of my experience so far has been solo plus AI, not a larger engineering team. It is not representative of every organization. It is, however, a real system I use to develop real software. I built a tool for orchestrating AI agents around a workflow like this: Human commits an issue → agent team implements it, opens a pull request, reviews and reworks the result → human approves the merge The individual steps run through different agents, LLMs, and models. Each role has specialized rules and prompts for its domain. The setup worked. Then the speed blew up in my face. More output did not mean more delivery Features and issues were implemented so quickly that I could no longer keep up with reviewing the code and pull requests properly. Adding another agent did not solve this. It made the queue larger. The human became the bottleneck. I do not mean that as a problem to eliminate. The human still owns the product, the decisions, and the consequences. But the process kept optimizing agent output even though accepted change was limited by human review capacity. More agent throughput did not produce more delivery. It produced more inventory waiting for human judgment. The same thing happened before implementation even started. I used an LLM to discuss ideas, plan features, break work down, and identify follow-up tasks. While the agent team was implementing one issue, it could discover several more and file them immediately. Creating an issue was cheap, so almost every reasonable observation became one. After a few weeks, the project had more than 100 open issues. Each issue looked useful on its own. Together, they were no longer a plan I could oversee. The backlog had become exhaust from planning and implementation. An issue may be cheap to create, but it is not free to own. Someone still has to understand it, compare it with everything else, decide whether it matters, keep its context current, and eventually accept or reject the result. Agents had made both sides of the problem faster: producing software and producing demand for more software. The human capacity between them had not changed. Why shorter cycles are not the answer Scrum can reduce the amount committed to a sprint. Kanban can limit work in progress. Both are useful ideas, and I still use parts of them. But limiting a column on a board does not answer the new questions: May an agent turn a discovery into committed work? What must be known before an agent is allowed to start? How do we prevent an agent from expanding the scope while it works? What evidence must it produce before a human review begins? How much autonomy can it have without also giving it authority? Which capacity controls the flow: agent execution or human validation? In a human team, many of these answers are implicit. Developers carry context between conversations. They recognize uncertainty, ask questions, and remain accountable for their decisions. An agent can turn an unclear request into convincing code without ever resolving the ambiguity behind it. The danger is not that an agent cannot finish a vague issue. The danger is that it can. If we change the roles, capacity model, commitment rules, handoffs, and acceptance process to handle that, we are no longer just making Scrum faster. We are building a different operating model. A working method for agentic development I started with one simple correction: remembering work and committing to work must be separate actions. From there, the following rules emerged. 1. Anyone may capture. Only a human may commit. An idea, defect, risk, or improvement may be captured at any time. It does not matter whether a human or an agent found it. A capture records: what was observed, where it was found, why it might matter, and enough context to evaluate it later. It is not yet an implementation issue. It has no milestone, estimate, or detailed specification. It may later be merged with another capture, rewritten, discarded, or simply expire. This matters because an agent must be allowed to notice things without gaining the authority to expand the product. Commitment is different. A human explicitly pulls a capture into committed work. By doing that, the human is not only asking an agent to implement something. The human is allocating the attention required to specify, review, and accept it. Agents may propose work. They may not commit it themselves. 2. Committed work needs an executable specification. Once work is committed, it needs enough information for an agent to finish it and for a human to review the result against it. The specification should contain at least: the intended outcome and why it matters, the relevant context, scope and explicit non-goals, technical and product constraints, acceptance criteria, the required tests or other evidence, and any known risks. An LLM can help create that specification. It can ask questions, find missing cases, and propose acceptance criteria. The human still decides when the specification reflects the intended work. “Improve error handling” is not executable. It does not say which failure, which behavior should change, or how anyone can prove that the issue is complete. Agents are fast enough that unresolved ambiguity becomes code almost immediately. Preparation therefore matters more, not less. 3. Execution is limited by validation capacity. The important question is no longer how many issues the agents can execute in parallel. The question is how many completed changes a human can understand and evaluate without losing control of the system. I therefore limit committed work according to downstream review capacity. An agent should not start another issue merely because an execution slot is available. It should start when there is also a realistic path through review and acceptance. This can leave agents idle while technically more work could be produced. That is intentional. An idle agent is cheaper than a pull request that nobody can properly review. 4. Discoveries do not expand active scope. Agents regularly find adjacent problems while working: missing validation, a weak abstraction, outdated documentation, another feature that would fit well. These discoveries return to capture. They do not automatically become issues, and they do not extend the current task unless they block its acceptance criteria or require an explicit human decision. This keeps one useful implementation from turning into five unplanned ones. 5. The result must arrive with evidence. A pull request is not ready for human review just because the code compiles and another agent has approved it. The handoff should explain: what changed and why, how the result satisfies each acceptance criterion, which tests and checks were run, which relevant decisions the agents made, what risks or uncertainties remain, and where human judgment is specifically required. Agent reviews are useful quality gates. They can find mistakes, compare the implementation with repository rules, and request rework before a human sees the result. But an agent reviewing another agent does not create human accountability. At least in my current workflow, final merge authority remains with the human. The goal is not to keep up with the agents My first instinct was to make reviewing faster so I could keep the agents busy. That was the wrong goal. The method has to prevent the system from producing more committed change than the responsible humans can absorb. Otherwise, the queue grows, context is lost, reviews become superficial, and “approved” slowly stops meaning understood. The scarce resource is no longer typing code. It is making clear decisions and validating their consequences. I have been using this approach for only a few weeks. On this project, it works better than the Scrum-shaped workflow I used before. That is all I will claim. It is a field report, not proof of a universal method. The team case will also be different. Review capacity can be distributed across several people. Product, architecture, security, and domain decisions may have different owners. But adding agents will create the same underlying imbalance whenever execution capacity grows faster than human judgment. From Waterfall to Agile to Agentic Waterfall organized software development around phases and a long-term plan. Agile organized human teams around short feedback loops and their capacity to implement change. The next step has to organize autonomous execution around human intent, bounded authority, and verifiable outcomes. I call that broader step Agentic Development. Some Agile principles will survive inside it, just as planning survived the move away from Waterfall. But Agile will no longer be the operating model. It will become part of the inheritance. Agentic Development is not Agile with a faster coder added to the team. It starts from a different constraint: agents can produce almost continuously, while humans remain responsible for deciding what should exist and whether the result is acceptable. That requires a new method. This is my current attempt. If your team used Scrum or Kanban before coding agents became part of the delivery process, I would like to know what happened. Which bottleneck appeared first? What did you keep, and what did you have to replace?