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.

Engineering team composition has historically been organized around the constraint that writing code is slow and skilled developers are scarce. Ratios of developers to product managers, to QA engineers, to designers, to technical writers — all of these reflect an underlying assumption about where the production bottleneck sits. When that bottleneck moves, the ratios that were optimized for the old constraint become wrong. AI-assisted development has moved the bottleneck. For teams working effectively with generation tools, the constraint is no longer coding throughput.

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.

Technical debt was always a metaphor with a compounding interest rate. Decisions made quickly to ship a feature cost more to address the longer they remained in the codebase. Teams that managed debt well built systems that stayed malleable. Teams that ignored it built systems that eventually could not be changed without risk of collapse. AI-assisted development has not eliminated this dynamic. It has accelerated the principal. The speed at which code can be generated means that architectural decisions — or the absence of them — propagate through a codebase faster than ever before.

Test-driven development was always more useful as a design discipline than a testing strategy. Writing the test first forced clarity about what the code was supposed to do before any implementation decisions were made. The red-green-refactor loop was valuable because it built understanding incrementally. AI-assisted development has resurfaced this distinction in an unexpected way. When code can be generated quickly from a specification, the temptation is to generate the implementation first and the tests afterward — or to generate both simultaneously and treat passing tests as evidence of correctness.

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.

The definition of done is one of the more underrated concepts in agile practice. A shared, explicit, team-level agreement on what it means for a story to be complete is the mechanism that prevents the slow accumulation of almost-done work that eventually freezes a sprint. Without it, done means different things to different people, and the gap is always paid for later. AI-assisted development introduces a new category of questions that most teams’ definitions of done do not yet address.

Velocity was always a flawed proxy for progress. Teams learned to game it, inflate it, and defend it in ways that had little to do with delivering value. AI-assisted development has not fixed the underlying problem — it has made it worse, and in doing so forced a more honest conversation about what sprint planning is actually for. When individual developer throughput increases significantly — and for many teams working with AI coding tools, the increase in raw output is real — the assumptions baked into story point estimation break down.