The “agile is dead” argument appears on a reliable cycle, usually authored by someone who spent years watching organizations adopt the ceremonies, terminology, and org charts of agile while preserving the planning assumptions, reporting structures, and risk culture of waterfall. The frustration is legitimate. The conclusion is wrong. What failed in most organizations was not agile. It was a management consulting product that appropriated agile vocabulary while systematically removing the practices that give agile its value.

The promise was efficiency. Feed the prompt, review the output, merge the diff. What teams discovered instead is that AI-assisted code review is more cognitively demanding than reviewing code written by a colleague — not less — because the nature of the errors has changed. When a human writes a bug, there is usually a traceable cause: a misunderstood requirement, a missed edge case, a copy-paste error. The bug has an author with intent.

Software architecture has always been more about constraints than capabilities. A good architecture does not just describe what a system can do — it defines what it will not do, where the boundaries are, and how components relate to one another in ways that can be understood, tested, and changed over time. The value of architectural discipline is not immediately visible. It manifests as the absence of problems that would otherwise accumulate quietly and expensively.

The phrase prompt engineering acquired a skeptical connotation early — something between a joke about talking to chatbots and a transitional skill that would be obsoleted as models improved. Neither characterization was accurate, and teams that dismissed it on those grounds have paid a real productivity cost. Prompting a code generation model effectively is a software discipline because it shares the fundamental characteristics of all software work: it requires precise specification of desired behavior, systematic handling of edge cases, and iterative refinement based on observed output.

For most of software’s history, vague requirements were expensive but survivable. A developer who received an underspecified ticket could ask a question, make a reasonable inference, or build a small prototype and get feedback. The cost of ambiguity was absorbed in back-and-forth, rework, and the gradual clarification that happened naturally when humans were iterating together. AI-assisted development has changed the economics of ambiguity in a way that most teams have not fully reckoned with.

The conversation about AI in software development tends to collapse into two positions: either AI will replace developers, or AI is just a faster autocomplete. Both positions avoid the more interesting question, which is about the specific category of decisions that cannot be delegated and why. Some decisions remain irreducibly human not because the technology is insufficient but because the decision requires accountability, context, and judgment that exist outside the codebase.