The SDLC Bottleneck Moved

The Horses Are Gone

When automobiles first appeared, people called them “horseless carriages.” The name reveals the difficulty of a real change: people understood the new machine through the old one. The carriage remained the mental model. The horse was merely removed.

Only later did society redesign roads, cities, logistics networks, emergency services, and entire industries around what automobiles made possible.

AI coding systems may be putting software teams in a similar moment. We can use them to make the familiar process move faster. Eventually, we have to ask which parts of that process were built around the cost of implementation and which still protect us from the risks we have now.

The History

For most of my career, the software development life cycle (SDLC) followed a familiar pattern.

Requirements > Design > Implementation > Testing > Deployment > Repeat.

The order made sense because implementation was expensive. Human developers were the bottleneck. If writing the software required the most time, then the schedule organized around the coding effort.

Unit testing emerged for good reasons. Small components were easier to reason about. Smaller boundaries made defects easier to isolate. Entire methodologies were built around the practical limits of human cognition and the tools available at the time.

Some practices may still be essential. Others may be answers to a bottleneck that has moved. The task is to tell the difference.

What GenAI Changes

Recently, while working with modern AI coding systems, I noticed that a dependable validation system changes the review I need to perform. I can spend less time reconstructing every implementation choice inside a subsystem when the work has clear requirements, enough context, and evidence that the system behaves as intended.

While building a command-line tool to summarize errors and retries from a larger test run, a coding agent changed the parsing and aggregation logic. I gained confidence from running the tool against known samples, reconciling its totals with the raw logs, and verifying that malformed records produced visible errors rather than disappearing silently. That meant I did not need to reconstruct every loop and intermediate data structure. I still had to decide whether the tool should stop on incomplete input or produce a partial report with warnings, because that choice affected how much trust users could place in the output.

That does not make implementation irrelevant. Code can satisfy a narrow outcome check and still create security, maintainability, cost, compliance, or operational problems. Good validation adds a confidence boundary; it does not remove the need for code review, ownership, or technical judgment.

Teams often organize review around the things that are easiest to assign and inspect: functions, classes, modules, and services. Those are useful handoffs for humans. They are not always the boundaries where the system succeeds or fails.

We can confuse the way we review something with the thing itself. A pull request may be organized around a module while the real question lives across a customer workflow, a financial reconciliation, or a control that spans several systems.

My team once reviewed the code that refreshed a dataset and confirmed that the job completed successfully. The real business question, however, was whether the report shown to users contained current and complete data. When we checked the full workflow, including upstream loads, dataset refresh timing, report mappings, and the displayed “as of” date, we found that a successful technical job did not always mean the report was ready to trust. The distinction taught us to review the outcome users depend on, not merely the process that returned a success status.

• A finance team cares whether the numbers reconcile.
• A customer cares whether their order arrives.
• A risk engineer cares whether controls remain effective.
• A business cares whether reality matches the report.

These are truth boundaries: the places where the system has to prove that reality matches the promise.

AI makes it more practical to define correctness at those levels and test for it. That demands more discipline in requirements, context, validation, and accountability.

When implementation becomes cheaper, ambiguity becomes more expensive. A vague requirement that once wasted a developer’s afternoon can now produce an entire subsystem that faithfully implements the wrong idea.

Conclusion

Organizations are full of intelligent solutions to real problems: checklists, approval processes, review gates, documentation standards, and testing strategies. Each exists because somebody got burned.

The challenge is to understand which controls still protect us from current risks and which were built around constraints that have quietly disappeared. The teams that adapt well will keep the discipline, then put it where the system needs proof.