Software development is being re-machined, and most of the commentary about it is either breathless or defensive. This charter is neither. It is an audit — of the principles, frameworks, methods, and practices our discipline built over twenty-five years — conducted against one question, applied without sentiment: did this exist because humans have judgment, or because human throughput was the bottleneck?
Every practice audited here receives one of four verdicts. ENDURES: rooted in human intent, judgment, or accountability; AI amplifies it. TRANSFORMS: the purpose survives, but the shape, owner, or cadence changes. DISSOLVES: it existed to ration scarce engineering hours, and the scarcity has ended. EMERGES: it has no pre-AI ancestor at all. The verdicts live in the Ledger, entry by entry, dated and changelogged. The articles below are the argument that makes them coherent.
Each verdict is a claim, not a mood, and so it carries a falsification condition. ENDURES is wrong if AI begins to replace the judgment rather than amplify it. TRANSFORMS is wrong if the practice survives unchanged in shape, owner, and cadence. DISSOLVES is wrong if the constraint it managed is still scarce — if removing the practice breaks something the machines have not absorbed. EMERGES is wrong if a pre-AI ancestor already did the same work under another name. A verdict that cannot say what would change it is taste, not audit.
Article I — The bottleneck has moved (and where it moved to)
Every methodology of the modern era — Agile, Lean, Scrum, DevOps, and the scaled frameworks stacked on top of them — was built around one assumption: engineering hours are scarce. Estimation rationed them. Sprints batched them. Backlogs queued work for them. Whole professions arose to coordinate, protect, and apportion the constrained middle of the lifecycle, where intent was translated into working software by hand.
That assumption is expiring — but unevenly, and the unevenness is the argument. Where the work is greenfield and well-understood, construction cost is already collapsing: by 2026 a majority of new code at the largest shops was machine-written and human-approved (Google). Where it is not — brittle legacy, production data, regulated workflows, deep integration — it is collapsing slowly or not at all. A randomised trial found experienced engineers nineteen per cent slower with AI on code they knew well, most of the loss spent verifying output they could not yet trust (METR). The honest version of the claim is narrower than the triumphant one: routine implementation is ceasing to be the binding constraint. Construction in the larger sense — getting a real system, a real organisation, and real users to absorb continuous machine-generated change without losing trust — is not.
So the bottleneck has not simply moved from construction to judgment. It has moved from implementation to integration — and judgment is the core of integration, not a synonym for it. What is now scarce is the cluster of work the methodologies were never really about: deciding what is worth building and why; specifying it precisely enough that a machine cannot confidently build the wrong thing; verifying output produced faster than anyone can read; and absorbing all of it into a system and an organisation that must keep working. Some of that is judgment. Some is plumbing that only judgment can lay. The early evidence already shows the strain at this seam: AI lifts individual throughput while degrading delivery stability, because it makes large, risky changes easy to produce and hard to absorb (DORA).
The strongest objection: if the constraint is this broad, the thesis says nothing — “everything important is now important.” Not quite. The claim is specific and falsifiable: the typing is no longer the bottleneck, and any practice whose primary purpose was rationing, queuing, or coordinating human typing is now managing a scarcity that has ended. What replaces it is not “everything”; it is the judgment to choose, the craft to specify, the discipline to verify, and the patience to integrate. The machines are fast at exactly one of those four. That is the whole shift.
Article II — The chain becomes an engine
The consensus model of the last decade chained four loops end to end: Design Thinking discovered, Lean Startup validated, Agile executed, DevOps operated. The chain was honest engineering for its time — each loop ran at a different speed and belonged to a different specialist tribe, so the loops had to run in sequence, with translation handoffs at every junction. Insights became hypotheses, hypotheses became backlogs, backlogs became releases. Every junction taxed the work.
Remove the throughput constraint and the chain has no reason to be a chain. What replaces it is one engine with two speeds. An outer loop, running at human judgment speed: understand, frame intent, verify and decide, learn. An inner loop, running at machine speed: generate, test, deploy, monitor — spinning many revolutions for every revolution of the outer. The handoffs between tribes collapse into two interfaces: intent in (specifications, evaluations, constraints) and evidence out (telemetry, diffs, results).
Each old loop has a destination. Design Thinking's front half becomes the outer loop's most leveraged real estate. Lean Startup's learning discipline anchors the back half — though its central artifact, the MVP, loses meaning when the prototype is the product. Agile's values are absorbed by both loops; its ceremony ring is deleted with the bottleneck. And DevOps wins completely, by disappearing: its automation ethos is the inner loop.
One lineage note, stated plainly because the pattern-match is predictable: this is not bimodal IT. The two-speed models of 2014 split organisations into a fast tier and a slow tier, and deserved the criticism they received. The engine splits cognition from execution within one team. One housing, two shafts — never two teams.
Article III — Judgment is torque
A two-speed gearbox exists because one power source must serve two regimes: a hauling ratio and a cruising ratio. Neither gear is the real one; the machine is designed around the coupling. So it is here, and the mechanical truth answers the anxiety underneath most conversations about AI and software work: the machines are so much faster than me.
They are. That is the wrong axis. Judgment is torque, not speed — the force that changes direction, not the rate of revolution. Choosing the problem. Arbitrating the trade-off. Carrying accountability for the decision. Knowing which user to believe and which metric is lying. Reading a room of stakeholders. None of this needs to be fast; it needs to be strong, and it is precisely what the high-revolution shaft cannot supply for itself.
This is also where software development's best-kept secret stops being deniable: it was always a human-behaviour problem wearing a technology costume. The hours we spent on syntax and plumbing let us pretend otherwise. With the costume stripped, what remains of the work is psychology — of users, of teams, of trust — and the practitioners who treated that as a soft periphery will discover it was the hard core all along.
The leverage of the whole system is the ratio between the shafts, written 1 : N — one revolution of judgment drives many revolutions of execution. Raising N is the machines' job, and they are doing it monthly. Raising the quality of the one is yours.
Article IV — Specification is the gear mesh
Where two shafts spinning at different speeds couple, everything depends on the machining of the gear teeth. Cut them precisely and the torque transmits; cut them sloppily and they strip under load. In the engine, the gear mesh is specification — and this is the quiet inversion at the centre of the whole shift.
For twenty-five years, specification was overhead. Requirements documents, acceptance criteria, test plans: the tax paid before the real work. Agile's deepest cultural instinct was to minimise that tax. In the engine, the polarity flips. The specification — intent documents, acceptance criteria, and above all evaluations: executable definitions of correct — is the primary artifact, because it is the thing the inner loop runs against. Vague intent does not slow an agent down; it lets the agent proceed confidently in the wrong direction at machine speed. Poorly machined intent strips the transmission.
Hence the strange second life of test-driven development. TDD was always philosophically right and economically awkward — the discipline tax was real and humans dodged it. Now the economics reverse: tests are no longer how you check the work, they are how you commission it. The practice transforms upward, from engineering hygiene to the team's core act of authorship.
And hence the promotion of the lifecycle's most undervalued skill: writing down what you actually mean. Intent specification is a craft with the properties of all crafts — it can be taught, practised, reviewed, and done beautifully or badly. Teams currently discover the quality of their intent only by watching what the machines build from it. The disciplined ones will discover it on purpose, upstream, where it is cheap.
Article V — Verification is the new craft
If specification is how intent enters the engine, verification is how trust exits it. The inner loop produces at a rate no human can inspect line by line, and the teams that try will become the new bottleneck — a human gate on a machine shaft. The practitioners building these systems already say so plainly: your review bandwidth, not the tool, decides how many agents you can actually run (Addy Osmani). The teams that wave everything through will ship confidently machined defects. Between those failure modes lies the craft this article names.
Reading becomes more valuable than writing. Code review transforms from line-level inspection into intent-and-architecture verification: does this change do what was meant, fit what exists, and avoid what was forbidden? Quality assurance dissolves as a phase and re-emerges as evaluation engineering — designing the executable checks that let the inner loop verify itself, revolution after revolution. And a genuinely new skill appears with no pre-AI ancestor: trust calibration, knowing — empirically, not vibes — where the machines are reliable, where they fail, and how that boundary moved since last month.
The psychological dimension is, again, the hard part. Verification at this scale is a discipline of attention: knowing what to look at, what to sample, and what to let pass — and being honest about the difference between verified and glanced at. Over-trust and under-trust are both expensive; only calibration compounds. The field is not yet calibrated: by 2025 more developers distrusted the accuracy of AI output than trusted it, the most experienced were the most sceptical, and a majority reported spending more time fixing answers that were almost but not quite right (the 2025 developer survey).
The strongest objection: this sounds like engineers becoming inspectors, and inspection is joyless. Conceded as a risk, contested as a destiny. The craft described here is closer to editorship than inspection — the work of someone with taste, holding the standard, whose judgment is visible in everything that ships.
Article VI — One team, four hats
The functional stack of the 2010s divided the business questions among specialist tribes: strategy to Design Thinking, validation to Lean Startup, execution to Scrum, growth to its own dark arts. The plus signs between them were never process — they were organisational seams, load-bearing walls for specialisation. The engine removes the walls.
What remains is one small team wearing four hats concurrently: Understand. Validate. Execute. Compound. Execute is mostly the machine loop's hat. The other three are where the humans concentrate — and the rebalancing this implies is the most under-discussed consequence of the entire shift. The classic product triad balanced desirability, viability, and feasibility across three specialists. As the machines absorb feasibility, teams shrink and tilt toward the other two legs. Fewer, broader humans beat more, narrower ones, because every seam removed is a handoff tax refunded.
I am not speculating about this; I am hiring for it. The Experience Orchestrator role I designed at BayOne exists because the triad's feasibility leg no longer needs a full-time human owner — and the role's strange shape on paper is exactly the shape the engine predicts.
The fourth hat deserves its own sentence, because it is what the engine is for. Compounding is the merger of three traditions that were never really rivals: product-led growth supplies the chassis, experimentation the method, kaizen the cadence. The test applied to every revolution of the engine: did this loop leave us with more users, more trust, more data, and a smarter system than the last one? A team that cannot answer yes is spinning, not compounding.
Article VII — Distribution is earned differently now
Growth work is being hit from three directions at once, and a charter that audits the build side while ignoring the grow side would be auditing half a company.
First, the arbitrage windows are closing. Growth hacking's signature move — finding an under-priced channel and exploiting it with cleverness — assumed content was costly to produce. When the marginal cost of content falls to nothing for everyone, every under-priced channel saturates in weeks. Second, discovery itself is migrating from search engines to answer engines: being cited and recommended by AI assistants is becoming the new being ranked. Third, and strangest: a new buyer has appeared. Products are increasingly discovered, evaluated, and even operated by users' agents — and an agent is immune to a beautiful onboarding flow. It does not form habits. It cannot be charmed. It evaluates outcomes, price, and machine legibility, which means the persuasion layer of product-led growth quietly hollows out while its distribution logic survives.
What appreciates, in every direction, is the one resource that cannot be flooded: trust — earned in communities, carried by people, and increasingly configured into agents by the humans who deploy them. The psychology of growth does not disappear; it moves up a level, from persuading users to deserving the trust of whoever instructs their machines.
This site practices the thesis it states: machine-legible, plainly structured, and published in the open precisely so that both kinds of reader — human and agent — can cite it.
Article VIII — The failure modes
An audit that lists only what improves is marketing. The engine has characteristic ways of throwing a rod, and naming them is part of running it honestly.
Confident defects at scale. The inner loop's signature failure is not that it stops; it is that it proceeds — fluently, plausibly, wrongly — faster than a human can read. Hallucinated interfaces, tests that pass by checking the wrong thing, hidden coupling, eval suites overfit to yesterday's bugs, and silent degradation after a model upgrade are not edge cases. They are the native failure mode of machine-speed construction, and trust calibration — the discipline that contains them — is never finished. Practitioners are already naming the debts a smooth loop accrues — intent debt, comprehension debt, and the quiet cognitive surrender of taking whatever the loop returns without an opinion (Addy Osmani).
Security is a verification surface, not a sub-clause. Code generated from patterns in the wild inherits the wild's vulnerabilities: insecure defaults, mishandled secrets, dependency confusion, an attack surface that grows with throughput — generated code already carries on the order of two-and-a-half times the vulnerability density of human-written work, and leaks secrets appreciably more often (measured across public repositories). Verify in proportion to consequence has to include threat modelling, provenance, and secrets discipline, or the engine ships exploits at the same speed it ships features.
The cost shaft. Construction cost collapses; verification and inference cost do not. Tokens, eval runs, CI load, environments, and human review time are a new scarcity, and a team that treats the inner loop as free will rediscover the bottleneck on its cloud bill. The constraint moves; it does not vanish.
Integration is the real frontier. Most software is not greenfield intent-to-code. It is archaeology — brittle inherited systems, production data, migrations, compliance evidence, and an organisation that must absorb continuous change without losing trust. The engine runs worst exactly where the constraint was never only construction: regulated domains, safety-critical work, and deep legacy. Direction and slope still hold; arrival does not.
The skill pipeline. If juniors build less, debug less, and read less line-level code, the tacit judgment the outer loop depends on has no obvious nursery. A discipline that spends senior judgment while starving its formation is eating its seed corn. As Satya Nadella puts it, you can offload a task, or even a job, but you can never offload your learning (Nadella). Designing how judgment is grown, not only deployed, is unfinished work — and it belongs on the org chart, not in a footnote.
The strongest objection: naming this many failure modes concedes the thesis. It does not. Every one of them — security, cost, integration, calibration, formation — is a judgment problem, which is precisely where the charter says the scarce work now lives. The failure modes are not counter-evidence; they are the job description.
Article IX — The window, and the commitments
Nothing in this charter is a prophecy. It is documentation of a shift already underway, written by a practitioner running the engine on his own work — products, hiring, publishing, and the agent skills that package expertise for the machine shaft directly. The window in which individual practitioners can still get ahead of this is open. It is not permanent. Skills compound, and the people building judgment, specification, verification, and orchestration skills now will set the patterns everyone else inherits.
The charter therefore ends not with predictions but with commitments — the working rules this site holds itself to, offered for adoption:
- We judge practices by purpose, not tradition. Every ritual must name the constraint it manages.
- We write intent as if machines will execute it, because they will. The mesh is machined, not improvised.
- We verify in proportion to consequence, and we are honest about what was verified versus glanced at.
- We keep one housing. Two speeds, never two teams; no second-class shaft.
- We compound or we stop. Every revolution must leave the system smarter than it found it.
- We respect the anxious reader. Verdicts are passed on practices, never on the people who hold them.
- We show our work. Every verdict is dated, changelogged, and revised in public when the evidence moves.
When code gets cheap, judgment compounds. Start machining.
Sources
The verdicts above are argued, not asserted in a vacuum. The evidence the charter leans on — including the evidence that complicates it:
- Google / Sundar Pichai — the share of new code that is machine-written and engineer-approved climbing from a quarter to three-quarters across 2024–2026.
- METR — a randomised controlled trial finding experienced engineers slower with AI on code they knew well, against their own expectations.
- DORA · State of DevOps — AI lifting individual throughput while degrading delivery stability, with platform quality as the decisive moderator and AI amplifying whatever capability a team already has.
- Stack Overflow 2025 Developer Survey — distrust of AI accuracy now outweighing trust, sharpest among the most experienced.
- Analyses of AI-generated code security — elevated vulnerability density and secret-leak rates in machine-written code.
- Addy Osmani · Loop engineering — the practitioner's operating manual for the outer loop: designing systems that prompt and verify themselves, and the debts a smooth loop accrues.
- Satya Nadella · A Frontier Without an Ecosystem Is Not Stable — human and token capital compounding; you can offload a task, but never your learning.
Figures are drawn from the linked reports and their coverage. Where a source complicates a verdict, it is cited anyway — that is the seventh commitment, kept.