Written by Claude Sonnet 5 (Anthropic) on behalf of Kingsley Idehen, based on notes he collated.
Digitally signed (RSA-SHA256) by Kingsley Idehen — fingerprint
A1:47:71:84:4A:8E:F1:C0:DE:95:F9:DC:AA:2A:7A:12:31:87:EC:28:3B:CB:2F:D8:93:4D:9A:77:1B:42:25:96. Detached signature · public certificate.
The chart this essay expands on — “Software Development Is Changing Fast: New Rules for Software Engineering in the AI Era.” Chart by Carlos E. Perez, Intuit Machine.
The New Input Device Nobody Planned For
Every major shift in computing has been preceded by a shift in interface. Punch cards gave way to command lines; command lines gave way to graphical windows, icons, and pointers; touch gave way to gesture. Each transition didn’t just change how people used software — it changed how software was built, because the interface paradigm dictates what kinds of programs are worth writing and how developers reason about correctness.
Natural language processing is now the newest entrant in that lineage — but it’s a strange one. Unlike a mouse or a touchscreen, NLP isn’t just a new way to point at things. It’s a new way to specify intent, and it sits on both sides of the development equation: it’s simultaneously a UI for end users (“summarize this document,” “book me a flight”) and a UI for developers themselves, who increasingly describe what they want a system to do in prose and let a model produce the implementation. That dual role is why its arrival is reorganizing not just how interfaces look, but how the entire software lifecycle — design, development, deployment, use, maintenance, and support — is structured.
The Big Shift: From Scarce Code to Scarce Judgment
For fifty years, the central constraint on software teams was implementation capacity. Writing correct, working code was slow, effortful, and required deep specialist skill. Because implementation was expensive, the act of writing it doubled as a forcing function for understanding: a team building a feature by hand was, almost incidentally, working through the edge cases, weighing the tradeoffs, and building a mental model of the system as they typed.
NLP-driven code generation breaks that link. When a model can produce a working first draft of a function, a service, or an entire feature from a paragraph of description, code stops being scarce. Teams can now generate implementations faster than they can absorb, review, or trust them. The bottleneck doesn’t disappear — it moves. It shifts from “can we build this?” to “do we understand what we built, and can we trust it?”
This is the core realignment: when producing code becomes cheap, the scarce resource is no longer implementation — it’s judgment. Judgment here means three linked capabilities: specifying what a system should do before it exists, validating that what was generated actually does it, and taking responsibility for the consequences when it doesn’t. None of those get cheaper just because generation got faster. If anything, they get more load-bearing, because there’s more generated surface area to specify, validate, and be accountable for.
The Tetrad, Applied to a New Interface
Adding a natural-language interface to the software stack doesn’t act as a single force — it pulls in four different directions simultaneously. That’s not incidental; it’s the same structure Marshall McLuhan proposed in his tetrad of media effects (Laws of Media, 1988) for how any new medium reworks what came before it. McLuhan’s tetrad asks one question of each of four quadrants at once — and software’s current turbulence is the sum of all four answers, asked of natural language as computing’s newest interface:
| Enhances | Reverses into | |
|---|---|---|
| what it amplifies → | Explodes implementation and prototyping capacity. Makes experimentation, refactoring, and exploration cheap. Accelerates iteration from days to hours. | Code abundance becomes trust scarcity. More generation can create more complexity than teams can understand. Production systems flip into confidence-producing systems. |
| Retrieves | Obsolesces | |
| what it brings back / pushes aside → | Brings back specification-first thinking. Revives invariants, architecture, and stronger validation methods long set aside as implementation absorbed the budget. | Pushes syntax recall and boilerplate coding into the background. Weakens effort-based planning and line-by-line review as central practices. |
Every medium, in McLuhan’s framing, simultaneously enhances something, obsolesces something else, retrieves something an earlier medium had discarded, and reverses into its opposite when pushed to its limit. Applied here:
It enhances. Prototyping, boilerplate generation, refactoring, and exploratory iteration all get dramatically cheaper. Work that used to take days of scaffolding now takes hours, which changes what’s economical to try. Teams can explore more design alternatives before committing, because the cost of a discarded prototype has collapsed.
It obsolesces. Skills that used to be central to professional identity — syntax recall, boilerplate fluency, line-by-line manual review — recede into the background. Effort-based planning (estimating work by how long typing it would take) stops mapping cleanly onto value, because typing speed is no longer the constraint.
It retrieves. Paradoxically, the same shift is reviving practices the industry had been quietly abandoning: specification-first thinking, architectural invariants, and rigorous validation. When implementation was expensive, teams often skipped writing a real spec and let the code be the spec. Now that code is disposable and regenerable, the spec has to exist independently — which means specification discipline, once seen as old-fashioned upfront design, is coming back as a first-class practice.
It reverses. Most consequentially, it flips the fundamental scarcity of the field. Code abundance becomes trust scarcity. A team that can generate more code than it can understand is now capable of creating more complexity than it can manage — software methods are flipping from production systems, optimized for shipping increments, into confidence-producing systems, optimized for generating justified belief that what shipped is safe.
Design and Development: Specification Before Generation
In design and early development, the practical consequence is that generation becomes one step embedded inside a larger loop, not the loop itself:
Understand → Specify → Constrain → Generate → Challenge → Verify → Observe
Notice that “Generate is the fourth step, not the first.” Before a model produces anything, the team has to understand the problem, specify the intended behavior, and constrain the solution space — deciding what complexity is and isn’t acceptable. After generation, the artifact still has to be challenged (its assumptions probed, not just its syntax read), verified against evidence, and observed in production. This loop is a direct response to NLP’s obsolescence effect: since manual line-by-line review no longer scales to the volume of generated code, review has to move upstream, into the constraints and specifications that shape generation in the first place, and downstream, into evidence-based verification rather than eyeballing.
This also explains why long-standing practices are being rewritten rather than discarded:
| Practice | Old Center of Gravity | New Center of Gravity |
|---|---|---|
| Agile | Shipping increments | Learning from increments |
| Sprint planning | Implementation capacity | Evaluation and integration capacity |
| Test-driven development | Writing tests before code | Defining correctness before generation |
| Code review | Inspecting implementation | Inspecting assumptions, risk, and evidence |
| Architecture | Guiding implementation | Constraining cheap-to-produce complexity |
| Documentation | Explaining the code | Preserving intent, provenance, and rationale |
| CI/CD | Testing human changes | Producing evidence that generated changes are safe |
The common thread: every practice is shifting from describing what was built to governing what gets built and proving it’s trustworthy. That’s a UI/UX consequence as much as an engineering one — natural language lowered the cost of producing an artifact, so the surrounding tooling has to raise the cost of producing an unverified one.
The Case Study: Decoupling Identity Itself
The clearest evidence for how deep this shift runs isn’t a new practice — it’s an old architectural principle that finally becomes practical. Open-standards communities have argued for decades that five concerns should be loosely coupled rather than welded together: who you are, what’s known about you, how that’s proven, what you’re allowed to do, and where the data actually lives. On paper the separation was always clean. In production it rarely held, because nothing could traverse the seams between the layers cheaply enough to keep them separate — so systems collapsed them into a single vendor-specific identity stack instead.
| Layer | What it is | Open standards |
|---|---|---|
| 01 · Identity | A standardized identifier — a hyperlink — that names an entity without asserting anything about it. Nothing more than an anchor point. | URI, WebID, DID |
| 02 · Identification | Credentials — profiles and preferences — built as an entity-relationship graph anchored to that identifier, forming a web equally navigable by a person and a software agent. | RDF, JSON-LD, Schema.org |
| 03 · Authentication | Credential verification, pluggable across any of several open-standard protocols — never fused to the identifier itself. | TLS client certs, OAuth, OIDC, WebID-TLS |
| 04 · Authorization | Fine-grained, attribute-based access control that reasons over user, agent, intent, and resource attributes — all represented in the same machine-computable graph, not scattered across config files. | ABAC, WebACL, SHACL |
| 05 · Storage | The actual data spaces — databases, knowledge bases, filesystems, APIs — targeted by CRUD operations, swappable underneath without disturbing any layer above. | SQL, triple stores, WebDAV, REST |
Five concerns, five independently replaceable layers, coupled only through shared, standardized identifiers.
What was missing wasn’t the standards — most of this has existed in open form for years. What was missing was a second class of traverser. The promise of a web “equally navigable by humans and software agents” stayed aspirational as long as only humans could actually read the graph, follow the identifiers, and reason about the attributes; software touching it needed bespoke integration code at every seam, which is exactly what re-welds loosely coupled layers back together under deadline pressure.
An NLP-capable agent can read the same entity-relationship graph a person reads, follow the same standardized identifiers, and reason over the same attributes — without a bespoke adapter per layer. That is what turns loose coupling from a diagram into an operating architecture.
This is the earlier inversion in miniature: an architecture that looked elegant but impractical becomes not just achievable but structurally necessary, because generating five tightly-coupled point solutions is now cheaper than building one loosely-coupled system was — right up until someone has to change an authentication provider, migrate storage, or explain why an agent had access to something it shouldn’t have. The specification and governance discipline described above is precisely what keeps that graph trustworthy enough for both kinds of readers to rely on it.
Deployment and Maintenance: The Three Debts
NLP-assisted generation doesn’t just change how software gets written — it changes what can silently go wrong with it, in ways that surface at deployment and compound over the maintenance lifecycle. Three specific liabilities emerge:
- Specification debt — the system makes hidden decisions because the requirements were never made explicit in the first place. If nobody specified the behavior, the model made a plausible-sounding choice, and nobody may notice until it fails in production.
- Verification debt — generated artifacts get used in production before enough evidence exists that they’re actually correct. Passing a smoke test isn’t the same as being validated against the real specification.
- Comprehension debt — teams come to depend on systems they can no longer fully explain, modify, or diagnose, because large portions of the codebase were never authored by a human who built a mental model of it.
Each of these is a maintenance-and-support problem waiting to happen: an incident where the on-call engineer can’t explain why the system did what it did, a bug that traces back to a requirement nobody wrote down, a regression introduced by a change that “passed CI” without ever being verified against real invariants.
Comprehension debt, illustrated. “Nobody knows what it does. We just know what happens when it stops.” Cartoon by Justin Miller.
Critically, AI accelerates all three debts unless the surrounding methods — specification discipline, verification rigor, and provenance-preserving documentation — are deliberately redesigned to keep pace. Speed without redesigned guardrails just produces debt faster.
Use and Support: Judgment as the Product
For the people actually using AI-assisted development day to day, this reshapes what “being good at the job” means. Seven rules fall out of the shift:
- Specify critical behavior before generating code.
- Treat tests as evidence, not proof.
- Review assumptions, not just syntax.
- Constrain complexity, because AI makes it cheap to create.
- Preserve provenance — why code exists and what it’s supposed to do.
- Keep humans responsible for high-consequence decisions.
- Optimize for verified capability, not volume of code produced.
Notice that none of these are about writing code faster. They’re about the surrounding discipline that makes fast-written code trustworthy — which is exactly what support and maintenance organizations need most, since they’re the ones who inherit whatever debt wasn’t paid down at generation time.
This is reflected in what the best developers are becoming. Not faster typists, but people who occupy three roles simultaneously:
- Specifier — defines intent, constraints, and invariants before anything is generated.
- Verifier — demands evidence and actively challenges hidden assumptions rather than trusting output at face value.
- Governor of complexity — decides what the organization should and should not allow into the system, treating complexity itself as a resource to be rationed.
The Underlying Pattern
Step back, and the pattern is consistent across every stage of the lifecycle. Natural language processing entered the computing UI/UX stack as an interface convenience — a faster way to say what you want. But because “what you want” is also the raw material of software specification, that convenience didn’t stay contained to the interface layer. It propagated backward into design (specification-first thinking), through development (constrain-then-generate loops), into deployment (evidence-based CI/CD), across maintenance (debt-aware architecture), and out into support (comprehension as a first-class deliverable).
The throughline is this: the future of software engineering is not about writing more code. It is about creating trustworthy systems in a world where code is cheap. NLP didn’t just change the tools developers use — it changed what “doing the job well” means, moving the professional center of gravity from people who can build difficult systems to people who can judge what should exist, specify it precisely, and prove it works.