AI Demands More Engineering Discipline, Not Less
Charity Majors · rss · 2026-07-27 source ↗ Reader 🖥️
Agentic EngineeringEphemeral CodeFeedback LoopsMultiplayer vs Single-Player AINear-Zero-Cost CodeNon-Deterministic SoftwareVerifiability (as the Quality Bar)
AI's collapse of the cost of writing code doesn't reduce the need for engineering rigor — it relocates that rigor away from the code itself and into the validation, observability, and feedback infrastructure surrounding it, which is why nondeterministic AI-generated systems demand more engineering discipline, not less.
practical · argumentative, built on an autobiographical narrative spine and extended block-quotation of a third party (Chad Fowler) — Majors is arguing for a specific stance engineers should take (don't mistake AI-generated-code speed for a license to drop rigor) and grounds it in a theoretical economic claim (the cost of producing code collapsed to near-zero) — the practical prescription rests on the theoretical reframing.
Structure
| Part | Role |
|---|---|
| Opening rebuttal to reader backlash over her prior piece | context |
| 'In 2025, the question was whether AI could ever generate good code' | evidence / timeline |
| 'It was reasonable to be skeptical the first time' | self-critique / credibility-building |
| 'What happened in 2025, exactly?' — the economics of code production inverted | core claim / premise |
| 'The real product of a software team is shared understanding' vs. the SRE view that production is the product | counter-view then reframing |
| Honeycomb's AI mandate and discovery of Chad Fowler's Phoenix Architecture essays | narrative / provenance |
| Extended Chad Fowler quotations (Death and Rebirth of Programming, The Deletion Test, code-as-cache) | evidence via authority |
| 'Do you remember the sysadmins?' — immutable infrastructure analogy | analogy / precedent |
| 'Lines of code are not the ideal artifact to review' | proposal |
| 'Our brains were not built for validation' | argument |
| 'Nondeterministic systems will require more engineering discipline, not less' | conclusion / thesis statement |
| 'This is our chance to bring our engineering values to the mainstream' | conclusion / call to action |
Key terms
- engineering discipline
Fast, short feedback loops, production instrumentation, and rigorous validation of what a system actually does — the SRE-style practice of treating production as the real proving ground. - production
The true product and proving ground of a software team — 'only prod is prod' — where correctness is actually determined, as opposed to a downstream deployment target. - code (as an artifact)
A disposable, regenerable 'materialized view of understanding' — a cache of current intent, valid while fresh and discardable when stale, borrowed explicitly from Chad Fowler. - validation
Empirically observing and encoding what a system IS doing (traces, behavioral tests, characterization tests, capture/replay) rather than judging what it OUGHT to be doing by reading its code.
Propositions
- explicitThe economics of code production inverted in 2025: generating code went from slow, hard, and expensive to effectively free and instant.conf: high
- explicitSince Opus 4.5 (November 2025), AI can generate code approximately as good as a median software engineer for common patterns, and much faster and cheaper.conf: medium
- implicitCode is losing its status as a durable asset and becoming a disposable, regenerable artifact: 'a materialized view of understanding that is useful while current, disposable when stale.'conf: highextendsFragments: February 4 · p9 — Both build on 'code becomes free, so the durable artifact must be something else,' but Majors extends the claim by locating the new durable artifact in architecture/production observability, not only in specification-plus-tests.
- explicitNondeterministic, AI-generated systems require MORE engineering discipline, not less.conf: highsupportsSoftware Design in the Agentic Age: Placing Your Bets · p8 — Both independently arrive at 'rigor does not vanish when the agent writes the code, it migrates' — Majors specifies the destination as production/observability discipline rather than only upstream specs and downstream ops.
- explicitShort, fast feedback loops are the cardinal sign of engineering discipline, and fewer than 10% of software teams currently work this way.conf: low
- explicitHuman brains are not well-suited to the validation/quality-gate role that code review assigns them; humans are 'the weakest link' when it comes to catching errors through inspection.conf: high
- implicitThe true product of a good software engineering team is production itself, not the shared understanding stored in developers' heads.conf: mediumrefinesFrom Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI · p11 — Majors doesn't deny that shared understanding matters — she relocates where it must live: not fragile 'meat brains' but encoded into production/systems, since 'the knowledge in our heads is unavailable to AI until we encode it into the system.' This refines rather than flatly contradicts the shared-understanding-as-first-class-deliverable claim.
- explicitValue in software is ultimately backed by durability, not disposability, wherever a system meets physical or human reality (persistence of data, consistency of user experience) — determinism in outcomes for users is not going away even as the code itself becomes disposable.conf: medium
- implicitThe hardest parts of software engineering — understanding problems, defining boundaries, validating correctness — were never actually about the speed of writing code, so making code free does not make those hard parts easier.conf: highsupportsThe keyboard was never the bottleneck · p1 — Both make the identical claim (Majors in footnote 9) that the limiting factor in software was never the speed of writing code, so cheap/free code generation does not remove the actual hard parts.
- explicitAI mandates issued without accompanying engineering discipline (fast feedback loops, observability) will not, by themselves, produce discontinuous returns on investment.conf: medium
Arguments
Nondeterministic, AI-generated software requires MORE engineering discipline, not less. strength: medium
Explicit premises:
- The economics of code production collapsed in 2025; code became free and disposable rather than the treasured product of expensive labor.
- Code was never the hard part of software engineering — the hard parts (understanding requirements, boundaries, invariants, correctness) are evaluation problems, not code problems.
- Humans are structurally bad at the validation/quality-gate role that code review has historically assigned them.
Implicit premises:
- The apparent decrease in one specific historical practice (line-by-line review of individual diffs) is a relocation of rigor, not a reduction in overall rigor — discipline migrates rather than disappears.
- An organization that has not already built fast feedback loops, evals, and production observability cannot safely let AI generate large volumes of disposable code — the argument implicitly presumes teams will build these capabilities, not merely stop reviewing code.
- Knowledge must be encoded into systems (not left in developers' heads) specifically because AI cannot read minds, and this requires engineering artifacts (architecture diagrams, behavioral tests, traces) that mostly don't exist yet in mature form.
Inferences:
- Teams that adopt AI code generation without building observability and validation infrastructure will accumulate compounding quality and reliability problems even as raw code output rises.
- The gap between already-disciplined teams (existing fast feedback loops, observability practice) and undisciplined teams should widen, not narrow, as AI adoption increases — the opposite of a leveling effect.
Traditional line-by-line review of individual code diffs is not the artifact worth defending; architecture- and behavior-level artifacts should become the primary reviewed object instead. strength: low
Explicit premises:
- Lines of code have historically carried too much freight (bugs, intent, tribal knowledge) because they were the only cheap-to-produce durable record engineers had.
- Operations and QA already have techniques — behavioral tests, characterization tests, capture/replay, traffic splitters — for encoding what a system actually does, distinct from code-review's focus on what it 'ought' to do.
Implicit premises:
- Architecture artifacts (e.g., a diagram from which code could be regenerated) can, in principle, be made rigorous enough to substitute for code as the object of review, even though the tooling for this does not yet exist.
- A specification or architecture description can be made precise enough to constrain safe regeneration, despite the author's own caveat elsewhere in the piece that formalizing user expectations (as in database migrations) has historically proven very hard.
Inferences:
- If architecture-as-source-of-truth becomes practical, code review as an institution would be subordinated to architecture review plus behavioral verification rather than eliminated outright.
Narratives
- The author's own history as a teenage university system administrator with unrestricted root access, and the industry's broader shift from handcrafted 'server pets' to immutable-infrastructure 'cattle.'
→ Analogy establishing that the discipline of killing and regenerating components — rather than editing them in place — is what redeemed infrastructure, and by extension is the same discipline that now needs to apply to code itself. - The author's discovery of Chad Fowler's 'Phoenix Architectures' essays, which happened after she had already replied to a Martin Fowler recap with her own post, 'Production Is Where the Rigor Goes.'
→ Establishes an intellectual lineage and borrows Fowler's authority and vocabulary — especially the 'code as a materialized view... disposable when stale' formulation — to underwrite the article's central economic reframing of code. - Honeycomb issuing its own AI mandate in August 2025, despite the author's admitted lack of personal enthusiasm for AI ('I was all in on AI, but I can't say I was super excited about it, in my heart of hearts').
→ Grounds the essay in the author's own lived organizational decision rather than abstract theorizing, framing the whole piece as retrospective processing and justification of a mandate already issued. - Reader backlash to the author's previous essay, in which she was accused of telling everyone to skip code review and push their worst code straight to production.
→ Rhetorical setup letting the author separate the specific practice she is willing to jettison (line-by-line review of disposable diffs) from her actual, more radical claim (that rigor must relocate, not vanish) — pre-empting the 'AI means no discipline' misreading of her position.
Questions addressed
- ✅ Was the 2025 debate over whether AI could ever produce 'good' code settled, and if so, in whose favor?
Yes, decisively, in the enthusiasts' favor — as of Opus 4.5 (November 2025), AI-generated code reached roughly median-engineer quality for common patterns. - ✅ If code becomes free and disposable, what is left for engineers to actually own and be rigorous about?
Production itself, plus the artifacts that encode what a system does and should do — architecture, tests, observability, evals — rather than code authorship. - ✅ Does AI adoption reduce the need for engineering discipline?
No — the opposite: nondeterministic AI-generated systems require MORE discipline, redirected toward feedback loops and production validation. - ⭕ What concrete tooling or format would let architecture/specification artifacts actually replace code as the reviewed, source-of-truth object?
Left explicitly open — the author states "the tools to do this don't exist yet, but many of the ideas do." - ⭕ If human review is a poor validation mechanism and the trusted automated alternative (deep observability, mature evals, behavioral tests) is conceded not to fully exist yet, what actually catches quality and correctness problems during the current transitional period?
Not addressed — the essay moves from 'brains are bad at validation' directly to a call for better infrastructure without engaging the interim gap where neither reliable human review nor mature automated validation is in place.
Gaps
- incompleteThe article never specifies what a sufficiently rigorous architecture or specification artifact would look like, nor what would make code regenerated from it trustworthy — she flags 'the tools to do this don't exist yet' but does not engage with how much verification or re-validation cost such regeneration would carry.
Read next: Read Chad Fowler's Phoenix Architecture essays directly, plus corpus material on spec-driven development and executable specifications, for concrete proposals about what a regeneration-safe spec actually looks like. - incompleteThe claim that fewer than 10% of teams work in fast feedback loops is asserted with no citation or methodology ('Five percent, maybe?'), yet it is load-bearing for the article's optimistic claim that AI tooling 'brings this more within reach.'
Read next: Check DORA / State of DevOps survey data and other measured accounts of feedback-loop and CI/CD adoption rates against this impressionistic estimate. - incompleteThe essay argues humans cannot be beaten by machines at 'validation' but does not address the transition period when the SRE-style production/observability discipline she prescribes has not yet been built — leaving open how teams should behave in the likely-long interval where neither strong human review nor strong automated validation exists.
Read next: Read maturity-model and incremental-adoption literature on sequencing testing and observability investment relative to AI code-generation adoption. - illogicalThe essay's optimism that encoding knowledge into systems will yield 'discontinuous returns on investment' sits in unexamined tension with her own earlier caution (the database-migration aside) that formalizing user expectations into a replayable, automatable spec has historically proven extremely hard — the two claims are never reconciled.
Read next: Read failure-mode literature on requirements formalization and specification languages to assess how much of the promised 'discipline dividend' is attainable versus aspirational. - incompleteThe piece does not address the token, compute, or latency cost of continuously regenerating code from specs or architecture rather than editing it in place — a cost this corpus's own extraction of 'Software Design in the Agentic Age' explicitly flags as unresolved industry-wide.
Read next: Read cost-of-regeneration analyses (token economics, verification overhead) before assuming continuous regeneration is economically superior to durable, maintained code.
Related documents
- From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI
- Software Design in the Agentic Age: Placing Your Bets
- Fragments: February 4
- The keyboard was never the bottleneck
- Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project
- We've Stopped Arguing About Whether AI Changes Software
- Have your agent record video demos of its work with shot-scraper video
- [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero
- Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices
- Harness engineering for coding agent users