They Build It, You Run It
The agentic-era inversion of DevOps's 'you build it, you run it': AI agents produce the software while humans own operating, running, and being accountable for it in production — the engineer's role shifting from author of the code to operator and supervisor of what the agents build.
Also known as: they build it, you run it, they build it you run it, build and operate, builds and operates, build it and operate it, you run it, who runs it, operate what the agents build, you build it, you run it
Part of: Human as Orchestrator of Agents
Documents (5)
- What's an Orchestrator—and Why Does Software Need One? Tim O'Brien · 2026-08-17 source ↗ Reader 🖥️
Software development is splitting the 'developer' role into an 'orchestrator' — a generalist who directs delegated-intelligence systems, remains accountable for what they produce, and can support them without AI — and this role should be professionalized (apprenticed, certified, insured) the way medicine and engineering are, because its holders now carry outsized responsibility without the licensing structures that responsibility normally requires. - Stop being skeptical about AI for development with Charity Majors Gergely Orosz (interviewing Charity Majors, CTO/co-founder of Honeycomb) · 2026-08-12 Reader 🖥️
AI skepticism about software development, though rational as recently as 2025 given the industry's track record of over-promised transformative technologies, has become irrational in 2026 because the model-plus-harness combination (Opus 4.5 running inside Claude Code) crossed a genuine, cloud-computing-in-2010-scale capability threshold — so the live question for engineers is no longer whether to adopt AI but how to build the validation discipline (tests, evals, conformance checking, observability) that makes shipping AI-written, unread code safe. - AI Is Changing Software Engineering. The Fundamentals Still Matter. Abby Bangser · 2026-07-07 source ↗ Reader 🖥️
AI is transforming who produces, consumes, and maintains software, but the organisations moving fastest succeed by doubling down on engineering fundamentals — right-sized boundaries, modular abstractions, clear interfaces, and operational discipline — as the foundation that lets humans and AI build together safely and sustainably. - Looking back at the Future of Software Engineering unconference Bartosz Ocytko · 2026-07-07 source ↗ Reader 🖥️
As agentic engineering matures into human-built-and-operated 'software factories,' the decisive questions of software engineering shift from raw automation to governance — where human judgment and sign-off sit in the automated loop, how platforms (rather than universal upskilling) safely absorb citizen developers, what would keep developer tooling relevant, and how organizations manage the widening gap between teams that codify their processes early and those that don't. - When AI Writes Almost All Code, What Happens To Software Engineering? Gergely Orosz · 2026-01-06 Reader 🖥️
As AI crosses a real capability threshold and starts writing the large majority of code for many developers and teams, the part of software engineering that was always about judgment, verification, architecture, and accountability — not typing syntax — becomes more valuable, not less, while the raw ability to write code in a given language stops being a differentiator at all.
Propositions touching this concept (5)
By publication month, oldest first (extraction month when no publication date is known).
2019-09
- explicitcontestedTreating software architecture as a standalone concept, designable in isolation from the teams that will build and operate it, is a mistake with predictable costs (e.g., the perpetuation of monolithic shared databases that outlive their original technical justification).
2026-07
- explicitdevelopedThe endpoint of agentic engineering is a largely self-evolving 'software factory' in which a feature request is built into the existing system, and which humans build and operate rather than hand-code.
- explicitFor the foreseeable future the developer's role is to build and operate the backbone that builds the system and to set the constraints under which the system is allowed to evolve, rather than to write the application code.
- explicitcontestedAs citizen developers gain the ability to build apps with AI, organizations risk drifting back to a 'they build it, you run it' model that dumps operational ownership of AI-generated apps onto an existing engineering team.
- explicitA personal AI-built system can now reach a scale and complexity (50 repositories, 50,000 lines of code, multiple named autonomous agents) that used to require an entire enterprise IT organization to build and operate.
Tensions
What kind of problem is AI adoption in software development, and who is the responsible actor for fixing it?
from: Is skepticism/rejection of AI for software development still rational in 2026 — and where exactly do practitioner "adopt fully" and "abstain entirely" positions actually diverge: on the facts (does AI work), the values (what counts as harm), or the frame (individual choice vs. systemic problem)?
- Stop being skeptical about AI for development with Charity Majors (Charity Majors): An engineering and organizational-leadership problem, solved inside the firm by building validation discipline and rebuilding trust between camps.
- I'm done using AI (Brett Codes): A personal ethical problem, solved by individual non-participation.
- The growing AI backlash (Gary Marcus): A political/regulatory problem, solved by governments constraining the industry.
Assessment: These aren't competing answers to the same question — they're answers to three different questions about where causal and moral leverage lies (org-technical, individual-ethical, political-collective), and the corpus never stages a direct confrontation between them. The weakest of the three on its own terms is Brett's: his abstention argument depends on an untested demand-signaling causal claim, and Marcus's own regulatory framing implicitly undercuts it — if the effective lever is political, one person's abstention is symbolic rather than causally load-bearing, however psychologically necessary it may be for him. Majors's org-engineering frame is the most operationally developed but explicitly scopes itself to teams that already have the discipline to execute it — it has nothing to offer someone in Brett's actual position (an individual contributor under a leadership mandate, with no control over org-level tooling investment).
Does verification/validation substitute for human care and authorship as the basis of software quality?
from: Is skepticism/rejection of AI for software development still rational in 2026 — and where exactly do practitioner "adopt fully" and "abstain entirely" positions actually diverge: on the facts (does AI work), the values (what counts as harm), or the frame (individual choice vs. systemic problem)?
- Stop being skeptical about AI for development with Charity Majors (Charity Majors): Yes — trust can and should relocate from authorship to process; once validation is good enough, shipping code nobody read is not a quality failure.
- I'm done using AI (Brett Codes): No — quality is constituted by care, which only a human relationship to the artifact supplies; verification does not substitute for it, even AI reviewing AI.
Assessment: A genuine values disagreement, not a disguised factual one, and under-argued on both sides. Majors asserts a substitution (trust moves from person to process) as self-evidently sufficient without ever specifying what validation would need to guarantee to make 'comfortable shipping unread code' true in practice — a gap her own extraction already flags. Brett asserts the opposite from pure introspection, without considering that his felt alienation might be a contingent response to a personal transition rather than a fact about what quality requires in principle — plenty of trusted professional domains (structural engineering, aviation, pharma) run on process-based rather than personal-craft-based trust and aren't usually accused of producing 'uncared for' outputs. Neither side defends its definition of quality against the other's; each asserts its own as obvious.
Does sustained, earnest, disciplined AI use degrade or improve a competent practitioner's skill and output?
from: Is skepticism/rejection of AI for software development still rational in 2026 — and where exactly do practitioner "adopt fully" and "abstain entirely" positions actually diverge: on the facts (does AI work), the values (what counts as harm), or the frame (individual choice vs. systemic problem)?
- Stop being skeptical about AI for development with Charity Majors (Charity Majors): AI use, wielded by disciplined teams, produces real capability gains without degrading quality, provided validation investment keeps pace.
- I'm done using AI (Brett Codes): Sustained AI use degraded his skill, care, and output quality over more than a year, despite being an experienced, motivated, initially-skeptical, earnestly-trying practitioner.
Assessment: Both are single-case evidence dressed as general claims, and the corpus offers a plausible reconciling variable neither author controls for: Parker's joy-gap data shows the split tracks codebase type (greenfield/small-product vs. legacy/enterprise) more cleanly than it tracks practitioner discipline or virtue. Fin is not described as legacy-constrained, and Brett's own most damning anecdote — the Linear/Claude Code project built 'without editing a line of code' — is closer to greenfield vibe-coding than to his day-to-day legacy work. The Majors/Brett disagreement may therefore be less a disagreement about AI's general effect on skilled practitioners and more two data points from different ends of Parker's spectrum, each over-generalized past its actual scope.
Is a moderate, bounded middle path between full adoption and full abstention psychologically and practically stable?
from: Is skepticism/rejection of AI for software development still rational in 2026 — and where exactly do practitioner "adopt fully" and "abstain entirely" positions actually diverge: on the facts (does AI work), the values (what counts as harm), or the frame (individual choice vs. systemic problem)?
- Stop being skeptical about AI for development with Charity Majors (Charity Majors): Yes — bounded, disciplined use is not only viable, it's the responsible default: small deliberate acts of withheld participation (no-AI Wednesdays), a rule against sending unread AI output, and validation discipline are all presented as workable, sustainable practices.
- I'm done using AI (Brett Codes): No — for him, moderate/trivial-only use was tried and did not hold; he kept reverting to using AI for everything, and concluded the choice is effectively binary.
Assessment: The sharpest values/psychology divergence in the corpus, and arguably what the central question is actually asking about, since 'is skepticism/rejection rational' presupposes a real choice-menu with a stable middle rung. Majors's evidence for stability (a team ritual everyone follows together) is a much weaker test than Brett's (a year of earnest solo attempt at bounded use against colleagues' and management's full-throttle adoption) — a shared team policy is a different psychological ask than one individual holding a line alone, which is closer to Brett's actual situation. On the specific question of whether bounded use holds under social/organizational pressure to go further, Brett's case is more probative than Majors's, even though his conclusion ('so it must be all-or-nothing') over-generalizes a personal finding into a universal claim.
Is 'skepticism' (doubting AI's capability) the same stance as 'rejection/abstention' (refusing to use AI), and does 'still rational in 2026' apply equally to both?
from: Is skepticism/rejection of AI for software development still rational in 2026 — and where exactly do practitioner "adopt fully" and "abstain entirely" positions actually diverge: on the facts (does AI work), the values (what counts as harm), or the frame (individual choice vs. systemic problem)?
- Stop being skeptical about AI for development with Charity Majors (Charity Majors): Effectively treats them as one stance: her essay is titled 'stop being skeptical about AI for development,' and her prescription for skeptics is to use AI more, with more validation discipline.
- I'm done using AI (Brett Codes): Demonstrates, without arguing it explicitly, that the two stances are separable: he is not skeptical of AI's capability, yet rejects use entirely on other grounds.
Assessment: This is the central question's own hidden ambiguity, and the corpus resolves it by demonstration rather than argument. Brett is a live counterexample to the premise, embedded in Majors's own title, that 'not being skeptical' (updating on capability evidence) and 'using AI' are the same move. Once separated, Majors's essay is only an argument against doubting-that-it-works, and has nothing to say to someone who concedes capability and objects on different grounds. So 'is skepticism still rational in 2026' and 'is abstention still rational in 2026' are different questions the corpus never poses side by side — and the practitioner discourse largely collapses them into one fight when they aren't the same fight. On the narrower question Majors actually argues (is doubting AI's capability still rational), the corpus evidence favors her: nobody, including Brett, disputes that current tools work. On the broader question the central question is really asking (is abstention still rational), the corpus offers no resolution at all — only two incompatible frames (organizational-engineering vs. individual-ethical) that never engage each other directly.
How much of the build pipeline should run with no human reading the code (the 'dark factory')?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): Toward a largely self-evolving software factory where a feature request is 'magically built' into the system; humans build and operate the factory and intervene only at explicit hand-off points.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): Deliberately bounded autonomy — keep humans in the loop.
- Software Design in the Agentic Age: Place Your Bets (Mathias Verraes): Dark factories are only safe for organisations that already have high test coverage, skilled engineers, and a high-quality engineering culture; most should cover their fundamentals first.
Assessment: Not simple optimism vs pessimism but a disagreement about preconditions and hidden costs. Ocytko's is a projection of where tooling is heading; Bangser and Verraes both supply reasons the projection is unsafe by default — learning-loss and missing prerequisites. Bangser has the stronger argument that the loss is structural (you cannot buy back organisational learning), which even an improving platform does not address.
How far can day-2 operations be handed to self-healing / autonomous remediation?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): A self-healing platform foundation should make whole classes of failure 'disappear', with increasingly autonomous background 'guardrail' agents refactoring, adding tests, and protecting invariants.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): Detection, context, and suggestion are safe wins, but automated remediation must remain an intentional, context-specific decision, not a default end state.
- What Survived Contact (Sam Ruby): Self-healing has, in practice, only moved halfway: diagnosis is automated while remediation is deliberately withheld from the machine.
Assessment: Ruby's report is descriptive (where practice actually stands) and Ocytko's is aspirational (where platforms could go); the gap between 'remediation is withheld' and 'failure modes disappear' is precisely the distance the optimists are projecting across. Bangser supplies the reason the gap may not close on efficiency grounds alone — the withheld human step is also the learning step.
Should the harness/platform-building function be centralised, or emerge per-team?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
- Notes from FOSE Europe (Giles Edwards-Alexander): Dedicated harness-engineering teams are a mistake; the friction of each team building its own harness is generative and creative.
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): A centralised platform / 'software factory' with tight, low-friction constraints should absorb operational concerns and guide both citizen developers and their agents from the first prompt.
Assessment: A precise split about the organisational form of the scaffolding, not its existence: both want shared architecture guidance, but Edwards-Alexander wants the building capability distributed (friction as feature) while Ocytko wants it concentrated in a platform (constraint as feature). Each concedes the other's pole — Edwards-Alexander keeps a central harness; Ocytko warns against over-constraining — which is why this is a live, unresolved tension rather than a clean contradiction.
Reversibility as a hedge vs a one-way commitment to deeper autonomy.
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
- Software Design in the Agentic Age: Place Your Bets (Mathias Verraes): Build systems that can revert from agent generation back to human engineering.
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): Head toward a self-evolving software factory — a progressive, largely one-directional build-out of autonomy and platform capability.
- We've Stopped Arguing About Whether AI Changes Software (Greg Herlein): Commit early and hard, because adoption is a compounding flywheel and the lead becomes a permanent structural moat.
Assessment: Incompatible risk models. Verraes treats deep AI-dependence as the danger to insure against; Herlein treats not-committing as the existential danger. They cannot both be the rational strategy: reversibility trades some upside for exit options, while flywheel-commitment trades exit options for compounding lead. The tie-breaker is empirical (will access/economics deteriorate?) and neither has evidence — Fowler's 'tokenpocalypse' data leans slightly toward Verraes.
Where is the locus of safety for non-engineers / citizen developers building software?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): In a tightly-constrained self-healing platform — not universal upskilling.
- What Survived Contact (Sam Ruby): In the director's management skill — a non-engineer steering an agent has made a hire, and the requirement is that they can manage by objective.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): In API-first, MCP-accessible tooling that supports rather than restricts the new builders.
- Why did Martin Fowler invite 60 engineers to a ski resort? (Ivett Ördög): It is genuinely unsolved — the tension between democratisation and its risks is an open question.
Assessment: Four different answers to the same governance question: the platform (Ocytko), the director's discipline (Ruby), the tooling interface (Bangser), or nobody-knows-yet (Ördög). Ruby and Ocytko are the true opposites — Ruby puts the burden on a human management skill, Ocytko designs the human out by making failure modes disappear in the platform. That both are held by attendees of one retreat is a measure of how unsettled the citizen-developer problem is.
What is the right metaphor for the human-AI relationship in coding?
from: What is the right approach to building harnesses around AI coding agents, and where are the limits?
- Patterns for Reducing Friction in AI-Assisted Development (Garg): AI is a teammate — treat it like a junior pair programmer who needs onboarding, context, and rituals.
- Harness engineering for coding agent users (Böckeler): AI is a system to be governed — the cybernetic governor model with feedforward and feedback controls.
- Agent Harness Engineering (Osmani): AI is a runtime to be engineered — the harness is an engineering artifact, not a social relationship.
- Looking back at the Future of Software Engineering unconference (Thoughtworks): AI is a new organizational participant — Conway's Law applies, and agent topologies must be designed.
Assessment: These metaphors are not mutually exclusive but they lead to different design decisions. Garg's teammate metaphor emphasizes collaboration rituals and may underplay the need for hard constraints (you don't sandbox a teammate). Böckeler's governor metaphor is the most theoretically rigorous but may overclaim the applicability of control theory to creative work. Osmani's engineering metaphor is the most actionable but may miss the social and organizational dimensions. Thoughtworks' organizational metaphor captures the broadest scope but is the hardest to operationalize.
Where does the non-delegable human asset now live — the harness/platform, the oracle, the fundamentals, or the developer's understanding?
from: What is the future of software development in the agentic/AI age?
- Notes from FOSE Europe (Giles Edwards-Alexander): In the harness — the continuously-evolving scaffolding of architecture guidance and rigour around the agents — though it must stay team-distributed, not centralized.
- What Survived Contact (Sam Ruby): In the oracle — the objective's evaluation is the single thing the person directing the model cannot delegate back to it.
- Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat (Jimmy Nilsson): In the fundamentals plus a renewed 'Extreme Humanism' — the durable disciplines and the conspicuously human element.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): In right-sized boundaries and the operational loop — humans must stay in operations because their learning is the irreplaceable asset.
- Fragments: February 9 (Martin Fowler (Feb 9)): In the developer's model-building and shared understanding — the craft of devising abstractions to reason about the domain.
Assessment: This is the deepest structural disagreement — every author agrees a human residue remains but nominates a different residue, and the choice determines what to invest in and what to teach. The harness-centric (Edwards-Alexander), oracle-centric (Ruby), fundamentals-centric (Nilsson/Bangser), and understanding-centric (Fowler) camps are not merely emphases: they imply different career ladders, different hiring, and different failure modes. Ruby's oracle and Bangser's operational-learning are the most operationally concrete; Nilsson's is the least argued. The absence in the corpus of anyone who holds 'nothing is non-delegable' is itself telling (see unexamined assumptions).
Should the harness/platform and its safety be centralized or left distributed across teams?
from: What is the future of software development in the agentic/AI age?
- Notes from FOSE Europe (Giles Edwards-Alexander): Distributed — dedicated harness-engineering teams are a mistake; per-team friction in building harnesses is creative and generative.
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): Centralized — safety for non-engineers should come from a tightly-constrained, self-healing platform that ships access and data guardrails.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): Centralized enabling layer — platform, SRE, and ops teams should provide API-first, MCP-accessible tooling that others safely consume.
- Fragments: February 18 (Martin Fowler (Feb 18)): Centralized golden path — platform teams should provide fast-but-safe 'bullet trains' with security built in by default.
Assessment: A real operating-model split. Edwards-Alexander's distributed stance rests almost entirely on the DevOps-team analogy (his own extraction flags it as asserted-on-intuition, not argued), whereas the platform camp has the stronger concrete case for the citizen-developer safety problem — you cannot distribute production-data guardrails to non-engineers. The tension is partly reconcilable: Ocytko himself concedes a platform tight enough for non-engineers may be too constraining for expert engineers' identity and innovation, which is exactly the freedom Edwards-Alexander is protecting. The unresolved question is whether one platform can be both.
How far should software be automated — toward the fully-autonomous dark/software factory, or held back to bounded autonomy with humans in the loop?
from: What is the future of software development in the agentic/AI age?
- Why did Martin Fowler invite 60 engineers to a ski resort? (Ivett Ördög): Full automation is genuinely viable in context and she is 'ironically' being pulled toward the dark-factory camp.
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): The aspirational endpoint is a largely self-evolving software factory; humans build and operate the backbone rather than the application.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): Bounded autonomy — keep humans in the operational loop; automated remediation must stay an intentional decision.
- What Survived Contact (Sam Ruby): Self-healing has stalled halfway on purpose: diagnosis is automated, remediation withheld from the machine.
- Software Design in the Agentic Age: Place Your Bets (Mathias Verraes): Dark factories are safe only for orgs that already have high test coverage, skilled engineers, and a quality culture; most should cover fundamentals first and stay revertible.
Assessment: The spectrum runs from Ördög/Ocytko (full automation is arriving and desirable) to Bangser/Ruby/Verraes (deliberately withhold the last step). The decelerationists have the better of the safety argument today — Ruby's 'nobody will cede the blast radius' and Bangser's 'removing humans removes learning' identify concrete, unmet prerequisites — but Ördög's context-dependence (backends, COBOL) shows the boundary is domain-specific, not absolute. The real disagreement is less about capability than about who absorbs the blast radius when an autonomous fix goes wrong.
Is preserving human understanding of the system a first-order value, or is comprehension safely offloadable so long as output is verifiable?
from: What is the future of software development in the agentic/AI age?
- Fragments: February 4 (Martin Fowler (Feb 4)): Preserve understanding: it is a first-order value, and practices that force explanation defend it.
- Fragments: February 9 (Martin Fowler (Feb 9)): Preserve understanding and craft: cognitive debt and the loss of model-building are the real costs to guard against.
- Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat (Jimmy Nilsson): Preserve the human: 'Extreme Humanism' and being conspicuously human are load-bearing anchors.
- We've Stopped Arguing About Whether AI Changes Software (Greg Herlein): Offloadable: the quality bar is 'is it verifiable enough,' not whether a human read or understood the code.
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): Offloadable for most builders: citizen developers need never read the code if a constrained platform makes failure modes disappear.
Assessment: The optimist-practitioner vs. skeptic-humanist axis. Fowler and Nilsson treat comprehension and craft as intrinsic goods whose loss is a harm even when output is fine; Herlein and Ocytko treat comprehension as instrumental — replaceable by verification and platform guardrails. The humanist camp has the stronger long-run argument (Fowler's cognitive-debt case and Ocytko's own 'who-guards-the-guards' problem both show verification and guardrails are themselves fallible artifacts that someone must understand), but the offloadable camp is describing what is actually happening at scale. The crux is whether verifiability can ever be robust enough to make understanding optional — which Ruby's own Goodhart gap (a passable oracle diverging from true intent) suggests it cannot fully be.
How should newly-empowered citizen developers be made safe — constrained platform, human stewardship, or supported API-first tooling?
from: What is the future of software development in the agentic/AI age?
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): A tightly-constrained, self-healing platform — not universal upskilling — should absorb citizen developers.
- The "funhouse mirror": How AI reflects the hidden truths of your software pipeline (Rachel Laycock (interviewed by The New Stack)): Senior technologists must act as stewards — teaching the 'why' and building guardrails, not gatekeeping or replacing juniors.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): Support, don't restrict — provide API-first, MCP-accessible tooling that non-engineers can safely consume.
Assessment: All three agree citizen developers are inevitable and must not be blocked, but the safety mechanism differs — encode it in a constraining platform (Ocytko), transfer it through human relationships (Laycock), or expose it as consumable interfaces (Bangser). Ocytko's platform-first case is strongest on the specific failure mode both he and Ördög name (non-engineers leaking or bypassing production-data access), which stewardship alone cannot prevent at scale. Laycock's stewardship answers a different problem — sustaining the junior-to-senior pipeline — that a platform does not. The positions are complementary in principle but compete for the same finite investment, and none supplies a concrete governance model for vibe-coded shadow IT.
Open gaps (4)
- incompleteThe accountability argument ('professional software engineers... must be accountable for code deployed to production based on their prompts') asserts who should be accountable but not how that accountability is actually discharged or enforced day to day when the engineer has not read most of the generated code (the article itself quotes Peter Steinberger saying he no longer reads most AI-generated code) — leaving a gap between the accountability claim and the article's own evidence about how little code actually gets read.When AI Writes Almost All Code, What Happens To Software Engineering? — read next: Material on accountability mechanisms for AI-generated code that a human has not fully read line by line (e.g. architecture-level review, system-behavior tests, debugging competence as a proxy for understanding).
- incompleteThe article never specifies the accountability mechanism when multiple orchestrators, or an orchestrator and a vendor/platform, jointly produce a system that fails — it only asserts that delegated intelligence is 'always traceable back to an accountable operator' without addressing shared or contested authorship, which is the common real-world case (an orchestrator directing a third-party agent platform built by another company).What's an Orchestrator—and Why Does Software Need One? — read next: Multi-party AI liability and supply-chain accountability frameworks (e.g. the enterprise-as-accountable-integrator argument in extract-outsourced-ai-still-own-the-risk); agent identity/attribution mechanisms that bind actions to a specific accountable principal.
- illogicalThe '100x productive, 100x responsible' claim underlying the insurance/licensing prediction is a bare assertion with no supporting mechanism — it isn't clear that liability scales linearly (or at all) with output volume rather than with the severity and irreversibility of specific decisions, which is how liability actually tends to be assessed (e.g. malpractice law weighs harm caused, not cases handled per year).What's an Orchestrator—and Why Does Software Need One? — read next: Legal/insurance literature on how liability and malpractice exposure are actually assessed for high-throughput professionals; the clinical-vs-legal-standards-of-proof distinction between diagnostic usefulness and legal culpability.
- incompleteThe article asserts that finishing and delivering software 'takes the same effort, energy, and technical expertise... as it always has,' which sits in tension with its own DRM anecdote showing a months-long task compressed to 40 minutes — it never reconciles why orchestration effort is claimed to be unchanged in kind when the article's own evidence shows it collapsing by roughly two orders of magnitude in time.What's an Orchestrator—and Why Does Software Need One? — read next: Measured before/after productivity studies of AI-assisted delivery (e.g. time-to-10th-PR, throughput metrics) that could clarify whether 'effort' and 'elapsed time' are being conflated here.