The SDLC After AI

What constrains software development? Why can't teams and organizations just build every application they can dream of, and reap the benefits of ever-expanding productivity? There are technical obstacles, of course; the technology available may not be able to deliver the capabilities needed. As the breakneck construction of data centers illustrates, availability of compute cycles is also a limiting factor. There are bandwidth limits as well; the 'speeds and feeds' that define transaction and communication throughput. The real constraining factors, however, are the same in software development as in many other specialized disciplines: time, cost, and expertise.

Software development takes time, requires expertise, and costs money. The salaries of skilled coders aren't trivial, and even when the firm can afford to pay for top coders and software architects, it must find and recruit them first, another expense. The infrastructure they need to develop, test, and deliver software, from cloud compute to data storage to transmission, is another major budget item.

Stakeholders can visualize new applications all day long, but the inhibiting factors are powerful, putting a check on development efforts, even those with significant potential benefits. Every software effort is, in part, an experiment, as engineers try to synthesize a system that fits the stakeholders' vision. Even on a two-week sprint cycle, large projects can take months of development, with multiple checkpoints that require review and acceptance, often leading to significant blind alleys and dead ends. Triage of development ideas is done by default; firms can't afford to experiment endlessly with every brainstormed idea for a new application.

How AI Changes the SDLC

Or can they? Does the advent of AI-enabled software development flip the script on familiar constraints and call for new development lifecycles and approaches? When expertise is shared between human coders and their AI collaborators, when prototypes can be quickly and cheaply created en masse, does that alleviate the obstacles to abundant application development? Or does the bottleneck just move, from one set of constraints to another, constraints based not in technology or expense, but in human attention and judgment?

One of the fundamental ideas of modern software development is the role of the Product Owner, explicitly designed to own the responsibility for articulating the product's requirements (as user stories in a backlog), and for guiding ongoing development by accepting, or withholding acceptance of, the features and functions as they are incrementally developed. This critical role takes on the most problematic activity of the entire development cycle: the communication of expectations from the ultimate users of the product to its designers and developers. As the conduit for transmitting intent and expectation in both directions, from the user to the developer and back, the Product Owner role requires fluency in both domains and both lexicons, as well as an appreciation for the concerns and constraints of each.

Now let's consider the product owner role in our imagined AI-enabled development shop. The constraint of coding expertise has been alleviated; our AI-code collaborator can design and program a prototype from raw specs or prompts, based on the product owner's description and guided by a human coder. Some of the cost constraints have been reduced as well, as the firm changes its team mix to include less high-level coding talent and more AI collaborative co-working skills. As the next generation of data centers comes online, compute costs may also decline due to competitive pressures. New open-weight AI models are also driving inference costs down.

In short, it's become almost free to generate multiple versions of a running prototype for the product owner to evaluate. When development of prototypes, complete enough to enable evaluation, is cost-free and nearly immediate, the constraints don't disappear; they migrate. The limiting constraint is now the attention of the product owner, the authorized evaluator of the abundant software generated from the AI-enabled software factory. In software development, the 'human-in-the-loop' is the primary keeper of the project's intent, the prime communicator and translator, and the decision-maker on the product's progress and success.

Responsible Attention

The term "human-in-the-loop" has become standard shorthand for keeping people involved in automated processes, and it implies a workflow: AI runs a process or prompt, returns a result, and a human with domain knowledge reviews it for accuracy or safety. In many cases, the human is there to assure compliance, and the intent is a checks-and-balances review cycle.

The new product ownership role we're envisioning isn't a check-and-balance; it's the decision gate that determines whether the firm benefits from the product. Accepting or withholding acceptance of a feature is a judgment, and judgment requires active evaluation: comparing the increment against the product vision, weighing trade-offs the backlog doesn't capture, with the authority and domain expertise to say no when necessary. Call this "Responsible Attention": the exercise of business judgment by an evaluator with the standing, authority, and confidence to accept or reject the product presented.

Responsible attention was never unlimited, even in the traditional SDLC. It was rarely the binding constraint because cost and development time limited the queue of things requiring focused judgment. A two-week sprint produced a predictable cadence, timed so that a Product Owner could give each decision real consideration.

An AI-enabled development shop compresses that cadence. If prototypes arrive daily, or in batches of multiple variants at once, the Product Owner's responsibility remains the same, but their capacity to exercise it does not scale with the volume demanding it.

Why Not Just Review Faster?

The obvious answer to a compressed build cycle is a compressed review cycle. If prototypes now arrive daily, move the Product Owner's cadence to daily as well. The math seems to work: less time per feature, more features per week, but the review scales down proportionally, so the judgment-to-output ratio stays constant.

That math is wrong. It assumes decision quality stays steady no matter how often the product is evaluated, but judgment degrades with repetition in ways review time doesn't capture. A Product Owner can technically sit through a daily review indefinitely; what degrades first isn't their calendar, it's the quality of judgment they bring to each decision.

This is decision fatigue, and it rarely announces itself. Nobody says "I'm too tired to evaluate this properly." They just start saying yes faster.

Volume creates a second failure mode, independent of fatigue. When prototypes are cheap enough to generate in multiples, more of them compete for the same fixed pool of attention. A polished, easy-to-evaluate variant will win attention over a harder, more consequential proposal simply because it's faster to judge, not because it matters more. Abundance doesn't just tax the evaluator; it can quietly reorder what gets evaluated seriously at all.

The Factory's Real Constraint

It is tempting to imagine an AI-enabled development shop as a factory: raw prompts in, finished software out, limited only by compute and imagination. But a factory implies throughput without a bottleneck, and this one has an unmovable one. Every increment the factory produces still has to pass through a human being who decides whether it deserves to exist in the product. That decision cannot be manufactured, parallelized, or accelerated the way the code beneath it can.

Every dev shop chasing AI-enabled velocity should ask a harder question than "how fast can we build." Ask who is deciding what gets built, how many decisions they're being asked to make this week, and whether anyone is still checking the quality of those decisions. A factory that produces faster than its judgment can absorb isn't accelerating. It's accumulating risk at the speed of its own success.