An epic that used to take three weeks now takes an afternoon, and it arrives as forty agentic work items rather than six tickets. Every ceremony built around the old cadence, the daily scrum, the sprint board, the Friday demo of work in progress, was designed for a rate of change that no longer applies. This is what the life of a feature looks like when a harness runs it, and what breaks in the process around it.
Part 1 set the scene and Part 2 covered the architectural foundation. This part goes inside the process loop.
The feature factory
Feature factory used to be an insult. In John Cutler's twelve signs you are working in a feature factory he coined it for organizations that measure output instead of outcomes: tickets in, features out, nobody asking afterwards whether any of it worked. I have used it that way myself. Despite it's negative connotations, which are still valid, what we are building now is a feature factory in the literal sense, so it is worth being precise about which parts of the insult it inherits.
The symptoms Cutler named:
- Tech debt accumulating faster than it is paid down.
- Features built in isolation, with no design that spans them.
- Little automated testing, security handled after the fact.
- Features built because one customer asked, not because they belong in the product.
Those are resource allocation failures rather than manufacturing failures. Measurement, one of the four signals, puts keep-the-lights-on work at roughly a third of capacity. Starve it for a quarter and nothing visible happens, which is why it gets starved. Starve it for a year and you have a product that will not scale and engineers who dread the codebase. The agentic version inverts that. You cannot run the factory without the foundation, so KTLO stops being deferrable and becomes a precondition, and the same agents that need the foundation are effective at building it.
A traditional life of a feature typically runs through roadmap, ideation, scoping, implementation, deployment, go-to-market, monitoring. Before the agentic era, a technical lead broke the epic into tickets, moved them across a board, talked about them at standup, and demonstrated something partial on Friday. The unit of work was a ticket and the unit of time was a day.
In the agentic era, the epic goes through a planning skill that reads it against the codebase and produces an implementation plan naming every step and every file it intends to touch. Five to thirty minutes depending on size, and it returns the gaps and the questions for the human in the loop. The software architect reads the plan: Is configuration handled properly? Is there a local dev path? How do I validate this? Does it include tests? Those questions repeat often enough that they belong in the planning skill as rules on every design iteration rather than in your head. Once the plan holds, the work goes to the harness, agents run in parallel, and a few hours later there is something to look at. That description is simplistic, and good process is simple. Here is what Gas City does with it.
The feature loop in practice
Gas City uses a formula: a directed acyclic graph that moves anything through a series of steps. You can design your own or install one of the pre-made packs. Humans can be invited to any gate, or none. The one I use most is build-basic.
1. Prepare. The formula reads the one-page brief and pins the codebase state it is reasoning about, down to the commit SHA. Everything downstream traces back to that anchor.
2. Requirements. An agent turns the brief into numbered, testable requirements. This feature produced twelve. The check refuses to advance if they are not individually verifiable, which kills the "the form should feel nice" class of requirement before it reaches a plan. This is the step that surprised me most: a machine enforcing requirements hygiene that I have failed to enforce on human teams for twenty years, because it has no social cost for saying "that is not testable".
3. Plan. A separate agent writes the implementation plan against those requirements and the actual source tree, naming the files it intends to touch.
4. Plan review. A different agent reviews the plan cold, with no memory of having written it. This is the first of the two points where I am genuinely required. I read the review report and either approve or send it back.
5. Decompose. The approved plan becomes a convoy of work items with explicit dependencies. The convoy is a graph, not a list, so the factory knows what can run concurrently and what has to wait.
6. Implement. The convoy drains into separate agent sessions running in parallel, one per work item. Each session gets a scoped task and a clean context rather than a shared conversation that slowly poisons itself. This step does not exist in single-agent workflows, and it is the one that changes the wall-clock arithmetic.
7. Summarize. One agent writes the canonical implementation summary from what actually landed, not from what the plan said would land. Those two diverge more than you would like, and the gap between them is one of the more useful things to read.
8. Review. Multiple reviewers with different briefs: correctness, simplicity, acceptance against the original requirements, and a separate reviewer that only asks whether the test evidence supports the claims. Their verdicts consolidate at a quorum, so one enthusiastic reviewer cannot wave something through.
9. Finalize and publish. The final report carries SHA-256 hashes of every upstream artifact plus a coverage matrix mapping each of the twelve requirements to the evidence that satisfies it. Then it opens the PR.
Agents do what you defined, at the rate you defined it. The checks that got quietly skipped before the agentic era stop being optional, which is the upside. The volume that produces is the new problem.
Volume of work
One feature can leave thirteen files behind: brief, requirements, plan review report, implementation plan, decomposition, implementation summary, code review context, simplicity review, acceptance review, test evidence review, review fix summary, review synthesis, and the final report. Run an epic a day and the paper trail becomes a second codebase, growing faster than the first.
The work items multiply on the same curve. A single epic decomposes into dozens of items with a dependency graph between them, created and closed by machines within hours. That is why the work-item layer had to move into git, as covered in Part 2. A tracker designed for a team closing twenty tickets a week is not slow at this, it is the wrong shape: the artifacts are the discussion, and they belong in the same history as the code they justify.
The final report carries a gap analysis explaining why a reviewer could not confirm an item was implemented correctly. The human is invited back in to ignore it, acknowledge it, or send it round again. It might be a bad design, a harness that needs improving, something inconsequential, or something that can wait. Either way the failure is cheap, it is legible, and it arrives as a specific artifact explaining itself. Compare that to the usual failure mode of a long agent session: a confident summary, a green checkmark, and a codebase you now have to audit by hand to find out what happened.
A useful review depends on a good foundation and a good harness. The hard part is surfacing the one report that matters out of everything the factory produced that day, and you will end up designing that surfacing yourself as the loop matures.
Human roles in autonomous processes
Gate placement depends on your appetite for risk, your token budget, and the quality of your foundation and harness. Gas City lets you put the human gates wherever that calculation lands: requirements, design, architecture, review, or none of them. That flexibility is the most attractive property of the framework. It ships Lego, not a pre-fabricated hard-wired loop.
Everything else is an automated gate, and automated gates have three properties or they are theater. Cheap, because a factory will hit them hundreds of times a week. Automatic, because a check that requires a human is a queue. Non-negotiable, because the moment a gate becomes advisory it stops shaping behavior. Agents are exquisitely good at finding the path of least resistance through a system that offers one. Early on I put myself in the loop nearly everywhere, then automated gates away as the harness and the foundation improved.
Design is the exception I have not found a way to automate. A design system and a set of common components buy you consistency, and agents build those quickly and well. Good UX still requires judgment, and that sits firmly on the human side of the gate. The components were the easy part. I spent many more iterations on the user flow than on anything the factory generated.
Kaizen is essential
When an epic finishes, look at what the factory got wrong. A prompt was ambiguous. A gate let something through. A step needed a rule it did not have. Write the fix into a skill before the next epic starts. That is the loop. Run it every time and the factory gets better at building features, not just better at the feature in front of it. Skip it and you build the next epic badly for the same reason you built the last one badly. This is not tidy-up work for a quiet week. In the early weeks it is most of the work. Expect that and plan for it.
My first few epics produced mediocre output. Not because the agents were incapable, but because my packs did not yet carry the judgment the task needed. Every weak review report became a prompt edit, a new skill, or a tightened gate. Five of my eight weeks went into learning orchestration and building the factory, three into the application. What accumulated is a workflow pack of my own, sitting alongside the Gas City defaults:
- Triage. How a raw idea becomes a work item. What earns a brief, what earns an epic, what gets closed as out of scope, and what evidence a bug report needs before it takes a slot.
- PR workflow. Branch and commit conventions, what a PR description has to contain, which reviews are mandatory, and how a failing gate is resolved rather than escalated.
- Engineering design. The questions every design iteration must answer: configuration, local dev, validation path, test strategy, rollback. These were the questions I kept asking by hand at the plan review gate, so they moved into the plan step and stopped being my job.
- Folder organization. Where a document lives and when it moves.
plans/for transient work,docs/for the permanent record, archived after thirty days. It runs on a schedule and keeps the structure honest without me looking at it.
Every one of those started as me repeating myself to an agent. The rule I settled on: the second time I give the same correction, it becomes a rule in a skill. A third time is a failure of the process, not of the agent. That is the Kaizen loop pointed at my own workflow, and it is the highest leverage habit I picked up in eight weeks. That ratio of five weeks to three has an obvious precedent. When Tesla built the Model 3, the hard problem was not the car, it was learning to build the machine that builds the car while shipping the car. The production line was the product for a while. Mine was too, and if I had understood that in week one I would have spent week one differently. The consequence is that your competitive advantage becomes the accumulated judgment in your packs, which is versioned, portable, and improves every project you point it at.
Tooling is experimental
It is a command line world. You run formulas from a terminal, read JSON reports, and inspect the work-item database by hand when something looks wrong. There is no board, no burndown, and no view a product manager can open at agentic speed. You will feel like a hacker spinning up tmux sessions to see why the agents are stalled or are taking so long to implement a feature. That is the honest shape of frontier work: a meaningful share of the effort goes into absorbing breakage rather than building the product. Worth knowing before you commit to a delivery date on top of it.
The gap is also the opportunity. The primitives are open and the state is in git, so a competent team can build the view it needs in a week: a dashboard over the work-item graph, a notification on gate failures, a report showing which requirements have evidence behind them. Everyone I have spoken to is building some version of it, which is a reliable signal that the product does not exist yet. Waiting for polished tooling means starting after the teams that built their own.
That argues for flexibility over polish when you choose. Nobody has the right answer yet, and the processes that will look obvious in two years have not been discovered, so the property that matters is whether the harness bends. Can you change model provider without rewriting your skills? Can you add a step to a formula, or move a gate, without forking the tool? Can you point the same pack at a better agent when one ships in six weeks, which it will? A harness that hard-wires a workflow is betting that today's process is the correct one, and there is no evidence for that bet. Packs are the hedge: the judgment lives in versioned artifacts you own, and the runner underneath stays replaceable.
New Agile
The daily scrum is the first casualty, at least as a status ritual. When an epic moves from requirements to implementation in an afternoon, walking a board reports on something that has already changed. The useful conversation moves up a level: which stage each epic is in, which gates it failed and why, and what the pass rates say about the harness.
Meeting frequency falls out of that. A daily standing meeting assumes a day is the resolution at which the picture usefully changes, and the harness reports state continuously and in more detail than a person can hold. What survives is the conversation machines cannot have: what we are building, and whether it worked. Demo Friday earns its place back, because a demo is the one ceremony where a human looks at the product rather than at a description of it. Team size falls for the same reason. Most of the coordination cost in a six-person team exists because six people edit one system with partial knowledge of each other's work, and that is not the problem one engineer running a factory has. Part 4 covers what that does to team shape.
The retro survives with a different subject. It is no longer solely about how the team worked together, it is about what the harness got wrong and which skill absorbs the fix, and it runs per epic rather than per fortnight because that is the cadence at which evidence now arrives.
Observability grows a cost axis. You spend tokens as well as time, and the two do not correlate. A feature that burned three attempts and a large token bill was a good trade if customers use the change; a cheap first-pass feature nobody touches was not. Tokens per epic, cost per merged change and first-attempt pass rate belong alongside the delivery metrics, read against customer outcome rather than on their own.
Ideation becomes the bottleneck. The artifacts you hand an agent look much like the ones you handed a team, better in places, but they are now consumed at several times the rate. A pipeline that kept six engineers fed will starve a factory. That is the constraint moving, which is what always happens.
Improved cross-team communication
Communicating the state of a feature has been the bane of technology organizations for as long as there have been technology organizations. The CEO wants a high-level summary. Go-to-market needs to know what is coming. Sales needs to understand what a feature does and when it lands. Marketing needs the ship date. Everyone holds a piece of the puzzle, and collating those pieces into a useful update is manual, repetitive and never finished. This is the part of the new world where I will allow myself some optimism, because the shape of a fix is visible: the pieces consolidate into one document.
Agents get their context from the repo, from shared packs, and from hooks into other systems of knowledge. Part of that context is a document describing the feature being built. I am hesitant to call it a skill, because the word has a loose definition in this space. In practice it is a markdown file with useful frontmatter, so an agent can find it and act on it. The question worth asking is what happens when that document becomes the unit of work for the whole company rather than for engineering alone.
One root document holds the state of a feature for its entire life. The business agrees the request as a document. Engineering shapes it, and the shaping is added to the same document. The work is executed, and the business logic that changed, the gaps found and the deployment stage are recorded there. The feature ships and the document becomes input for the support agent answering customer questions about it. The next iteration reads it for the decisions already made and the reasons behind them. When the CEO asks what state a feature is in, that stops being an archaeological dig through a tracker, a wiki and three Slack threads. It becomes an AI summary linked to real evidence and powering internal realtime dashboards.
Utopian, and the tooling is nowhere near it. But context is the binding constraint on agents, and the thing that destroys context today is the handoff between teams. The discipline that makes a feature legible to an agent makes it legible to the people downstream too, which is a return worth having even if the utopia never arrives.
Summary
Processes will change, and the change will be resisted. Abandoning a way of working that has served for a decade is hard, and the difficulty is not stubbornness. Routine is part of what makes a team feel safe, and rewriting the routine takes that away before it gives anything back. The teams that get through it will be the ones that treat the new process as something to keep improving: Kaizen applied to how the team works, not only to what it ships.
None of this is settled. The tooling is experimental, the process is unproven, and the only way to find what works in your organization is to run it and measure it. Early wins will tempt you back into the old feature factory impulse, shipping because you can rather than because you should. The discipline that prevents that is the same one that protects the KTLO third: in these early stages, allocate roughly a third of your time to improving the harness rather than using it. It pays back on every epic after it.
Part 1, Building Production Grade Applications using Agent Orchestration. After eight weeks I built a production grade application. Five weeks spent building and learning the factory, three building the product. Pre-AI this product would have taken at least six months and a team of 3-5 to build. link
Part 2, Architecture: What Agentic Orchestration Changes About Your Tech Stack link
Part 3, Process: AI Agent Development Workflow from Brief to Pull Request link
Part 4, People. What is the human's role in this process. How has it changed? What grows, what shrinks, where do we sit? What are the new teams and structure needed to take full advantage? coming soon
Part 5, Measure. How do we measure in this new era? What were the stats of this project? What survives from DORA, and a metrics set for an org where machines write most of the diff. coming soon
This is a portfolio product and a portfolio article. If you want help getting your engineering team or organization onto this footing, from a lunch and learn through to a one to twelve month advisory engagement, fractional CTO work, or engineering leadership for your team, get in touch.