Most conversations about AI and software development take the existing process as fixed. AI can help write the requirements, turn them into tickets, produce the designs, generate the code, review the pull request, write the tests and summarise the sprint. Each stage gets faster, but we still have the same stages. That may be useful in the short term, but it isn’t much of a reimagining. If requirements documents, backlogs, tickets, handoffs, ownership boundaries and approval gates developed around the cost of producing software, making each artefact cheaper to produce doesn’t answer whether we still need it. We could end up with high-velocity bureaucracy: far more requirements, tickets, code, tests and pull requests moving through a system no longer fit for purpose.
That volume isn’t hypothetical. GitHub’s Octoverse 2026 report counts 1.3 billion merged pull requests in the year to September, more than triple the year before, and over 40% of pull requests now start with an agent’s first draft, up from 17% in March. Linux Foundation Research’s October survey has maintainers estimating that a quarter of the pull requests arriving are low-quality AI output, and nearly two thirds say review is taking longer than it did. GitHub has had to respond too. In January its own product team opened a discussion about the volume of abandoned, often AI-generated contributions landing on maintainers, and by June it had shipped a cap on how many pull requests an outside contributor can have open at once. I asked in August how we would build the whole pipeline if we were starting today, knowing what code now costs. This is my attempt at an answer.
The principle I keep coming back to is: don’t automate the artefact. Recover the need that caused us to invent it. Backlogs serve memory and coordination, teams serve belonging and accumulated understanding, code ownership serves accountability, and roadmaps give customers confidence. The needs are still there. Their current forms don’t have to remain the same.
The SDLC was designed around expensive implementation
The software development lifecycle exists for good reasons. Producing software has historically taken a lot of specialist time, coordination has been difficult, and mistakes found late have been expensive. Requirements helped people agree what to build before engineers spent months building it, backlogs rationed limited capacity, and teams owned parts of the product because somebody needed to understand them. QA functions tried to stop poor-quality work reaching customers, while roadmaps helped companies and customers plan. These mechanisms reflect a world where implementation was expensive, changes arrived in batches, information moved slowly and work passed between groups of specialists.
AI changes some of those constraints quite dramatically. It can already explore an implementation, build it, instrument it, test it and produce alternatives much faster than a traditional team, and that will continue to improve. We still have to decide which outcomes matter, understand customers in their actual context, make trade-offs, recognise quality, earn trust and judge whether something feels like us. Somebody also has to decide which risks are acceptable and answer for the consequences. Producing an implementation gets cheaper; judgement, taste, customer understanding and accountability don’t.
Some of this isn’t new. Good technology companies stopped treating QA as a separate downstream function years ago. Plenty have reduced the role of long PRDs, given teams problems instead of feature lists, and become much more careful about roadmap commitments. AI didn’t invent good product development, but it does remove more of the remaining justification for continuing with the old system.
The unit of work should become an outcome bet
Most product organisations say they care about outcomes, while their machinery still runs on outputs. Funding goes to projects, roadmaps contain features, backlogs contain work and success is often measured by whether the thing shipped. A more useful starting point would be an outcome bet:
We believe changing X for Y people will produce Z business effect, subject to these constraints. This is the evidence that would strengthen, weaken or kill that belief.
The goal might be commercial: revenue, adoption, retention or a reduction in cost. It also needs to describe the customer behaviour we expect to change, the quality of the experience and the things we won’t trade away to get there. “Increase activation by 10%” gives an autonomous system far too much freedom and very little useful direction. It could increase activation while creating a miserable experience, attracting the wrong customers or increasing support demand.
A better goal might be to increase the proportion of new customers who complete their first meaningful task within a day, while making the experience feel calm and confidence-building, without hiding costs, adding coercive prompts or increasing support burden. This combines the business outcome, the character of the experience and the boundaries around it. Those boundaries are part of the goal, rather than polish to add later.
AI can work around that outcome continuously. It can examine customer evidence, propose different interventions, produce working versions, simulate journeys, identify risks, instrument the result and recommend what to retain. The answer might involve software, but it could also involve removing a feature, changing a default, rewriting an email, improving documentation, altering pricing or having somebody call the customer. The team chooses valuable outcomes, provides context, defines boundaries, judges the options and interprets the evidence. Software becomes one possible intervention.
Will Larson has been running a version of this. He described it in September as the software factory pattern: looping an agent on a broad goal and letting the harness drive progress towards it. His loop reads the project’s RFC for the goal and the strategy, reads the dashboards for whether the metric is moving, updates the project tracker, works on whatever is unblocked, and periodically re-reads the project description to check it is still pointed the right way. He found the agents could already work through tasks but had no way of knowing whether the project was heading anywhere useful, “the ability to evaluate if they were going in the right direction”. The outcome bet is what gives them that.
Backlogs should become context, and PRDs should become living intent
The backlog as an ordered list of future work can go. Most backlogs contain customer observations, feature requests, defects, ideas, commitments and things nobody has had the energy to delete. They mix evidence about problems with proposed solutions, then imply that an old solution becomes more deserving because it has waited patiently for long enough. I don’t think an idea from eighteen months ago should get built because it finally reached the top of Jira.
We should preserve customer evidence, previous experiments, unresolved tensions, explicit commitments and the reasoning behind decisions. That material becomes organisational memory and, yes, excellent agent context. When an outcome becomes important, agents can search it and generate options against the current evidence, constraints and product. They don’t need a queue of speculative future work. Preserve evidence and decisions, and continuously regenerate the possible work. Larson found the same thing from the other end. The first thing his loop demanded was that the goal, the strategy and the measures be written down somewhere an agent could read them. He says it showed him where he “was accidentally hoarding parts of the state”.
PRDs need a similar rethink. A document describing a chosen solution before implementation makes less sense when a system can produce several working interpretations quickly. We still need shared intent, constraints and a definition of success, but those can live with the outcome bet and evolve as evidence arrives. The specification and the evaluation start to become the same thing: what are we trying to change, how should it feel, what must remain true, how will we recognise success and what would make us stop?
Dedicated QA functions can disappear where they haven’t already. Quality remains a property of the whole system, with continuous evaluation built into every intervention. Humans still need to judge quality where the criteria are subjective, contested or consequential, but that doesn’t require a separate function waiting at the end of development to find out what happened.
Stable teams can remain while their missions move
Teams are more interesting because they serve a deeply human need. People need to feel safe, know who has their back, understand how decisions get made and build trust over time. Constantly assembling and dissolving groups would be a fairly grim way to work, however efficient it looked in the planning tool. We can keep the continuity of the human team without giving it a permanent feature boundary.
The group can remain stable enough to build trust and shared judgement, and accumulate knowledge of a durable customer or business area: getting started, managing money, creating content, resolving problems or building trust. Its current outcome can change, along with the implementation surface and the agents working beside it. A team that deeply understands customers getting started might work on activation, then retention, then cost-to-serve because those outcomes are connected in the customer’s experience. Its work might cross the website, product, documentation, pricing and support.
There is an obvious trap here. Area teams can become feature teams with more sophisticated names. The useful test is whether the team can conclude that the best intervention sits outside its usual surface, or that something it previously built should be removed.
Code ownership will also need to change. It is useful today because somebody needs the context, and somebody needs to feel responsible when things go wrong. Agents may eventually carry much more complete technical context than any one human can, but that doesn’t make them accountable. An agent can’t answer to a customer, take responsibility for a judgement or bear the consequences of a bad decision in any meaningful sense. At least not without compliance changing far more rapidly than it has in the last twenty years!
Agents can have operating remits. A payments agent might understand the implementation, commercial rules, operational history, known risks and regulatory constraints. It could continuously monitor the capability, propose improvements and make low-risk changes within defined permissions. Humans remain accountable for the outcome and set the boundaries within which the agent operates.
The thing being owned also becomes larger than the code. A capability includes its customer promise, behaviour, economics, operational health, constraints, implementation and decision history. Code is part of its current state and may become much more provisional. Customer understanding, trusted data, constraints, evaluations and the history of why decisions were made are the assets that need to endure.
Roadmaps have to serve customers moving at a different speed
Roadmaps are the difficult one. An AI-native product organisation may be able to explore and adapt very quickly, while its customers still have budgets, integrations, procurement cycles, governance, training and their own commitments. “We’ll continuously regenerate the product as evidence arrives” sounds exciting from inside the company and quite alarming when somebody’s production process depends on it.
Customers need confidence about what they can rely on, and they don’t necessarily need a speculative list of features arranged into quarters. A more useful roadmap would separate direction, promises and current bets. Direction tells customers which problems and capabilities we expect to keep investing in. A company might confidently commit to making onboarding possible without specialist implementation support, without claiming it already knows that the answer is a drag-and-drop workflow with twelve templates.
Promises are the smaller set of things customers can safely plan around: compatibility, supported workflows, migration periods, availability and any capability/date commitments we have deliberately made. Current bets explain what we’re exploring and how confident we are, without presenting every possible intervention as a promise. This gives customers useful information while preserving room to learn.
Some commitments do need dates. A customer may have a contract, migration, launch or regulatory deadline that makes an approximate direction useless. We shouldn’t pretend all commitments can become fluid. We should make them scarce, explicit and expensive.
A dated commitment gives up future options, so it deserves evidence, clear authority and an understanding of who will depend on it. Perhaps organisations need a commitment budget alongside their investment decisions, with most intentions remaining fluid and a small number promoted into promises because the value of certainty exceeds the flexibility being given up. The roadmap can then be clear about what is a promise, what is a direction and what may change as we learn.
Human accountability doesn’t require human approval of everything
My starting thought was that AI should handle the parts that don’t require judgement, taste or human sign-off. I’m less sure about the sign-off part now. AI can contribute provisional judgement: it can critique, compare, predict and make bounded decisions. Requiring a person to approve every output could become another inherited control point, especially when changes are small, reversible and continuously evaluated.
Human sign-off often exists because work moved slowly and arrived in large batches. If an AI system can make a low-risk change within explicit boundaries, observe the effect and reverse it quickly, routine approval may add delay without adding much safety.
Imprint, where Larson works, has started doing this for code review. Their merged pull requests quadrupled in two years and median review time went from 33 minutes to 77, so they now auto-approve changes that fit a strict profile: under a thousand lines, nothing serious flagged by their review bot, an author with ten or more merged changes in that service, a narrow blast radius and nothing in shared libraries. Around a tenth of changes qualify so far. They also made a rule that any error caused by a small change is treated as a failure in the system and fixed at that level, not pinned on the person who didn’t review it.
The obvious objection is that review was never only a safety check. It was how teams learned each other’s code, and Imprint kept human review partly for that reason. I think that goes too. Reading the diff was the cheapest way to find out what had changed when humans wrote all of it. It isn’t any more. An agent that holds the full current state of a capability can explain it to whoever needs to understand it, at the depth they need. The team still builds that understanding, but by asking the agent instead of reading the diff.
Humans should define where approval is required, including irreversible decisions, material customer promises, significant brand expressions, ethical or contested trade-offs, and changes that exceed an agreed risk budget. They also remain responsible for the design and behaviour of the system as a whole.
Agents can begin with narrow permissions and reversible changes, then earn wider authority where the evidence shows that their decisions are reliable. Humans still own the values, boundaries and consequences. The organisational work is deciding what may be delegated, what must remain with people and how quickly authority can be withdrawn when the evidence changes.
AI changes more than the cost of producing code. It changes what teams are for, what we treat as an asset, how we make commitments and where responsibility sits. A useful test for any AI program is whether it leaves the company producing the same backlog, PRD, tickets, pull requests, approvals and roadmap, only faster. If it does, all we’ve done is to automate the current shape of software development.