When AI Writes Almost All Code, What Happens To Software Engineering?

Gergely Orosz · pdf · 2026-01-06 Reader 🖥️

AI Fluency (as Career Expectation)AI Labor Disruption Code Was Never the Bottleneck Code Quality Product Engineer (PM/Engineering Role Merge)Systemic Apprenticeship & Skill Transmission Technical Leadership Track (IC / Staff-Plus Ladder)They Build It, You Run It Vibe Coding

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.

practical · mixed — Opens narratively (the author's own holiday 'a-ha moment' and a chorus of named practitioners' quotes) to establish a factual premise (AI now writes ~90%+ of code for many devs/teams), then shifts to argumentative/expository mode to work out the professional consequences for individuals, teams, and the industry. The propositions throughout serve a practical aim: what should engineers, teams, and hiring pipelines do about this.

Structure

Part	Role
Opening narrative: the author's own holiday 'a-ha moment' building production features entirely via prompting, including from his phone	narrative hook / evidence
Section 1: a chorus of named, credible practitioners (Jaana Dogan, Thorsten Ball, Malte Ubl, DHH, Adam Wathan, Karpathy, Boris Cherny) independently reporting the same capability-threshold experience	evidence (testimonial, triangulated across skeptics and vendors alike)
Section 2: why now — specific model releases (Gemini 3, Opus 4.5, GPT-5.2) as the proximate cause, plus revisiting Amodei's '90% AI-written code' prediction as arguably already true	evidence / causal explanation
Section 3: the bad — which skills lose value (prototyping, language polyglot-ism, specialization, implementing well-defined tickets, manual refactoring, careful reading of generated code)	elaboration (cost side of the thesis)
Section 4: the good — which skills gain value (tech-lead traits, testing/test-infra skill, product-mindedness, architecture decisions, tech-debt tracking, reliability/performance/security judgment, 'engineer not coder')	elaboration (benefit side of the thesis — this is the core argument)
Section 5: the ugly — second-order organizational costs (more code/more bugs, declining change-quality data, weak practices hurting sooner, work-life-boundary erosion, juniors pressured to mature fast, CS-education as a hiring filter, accountability for an explosion of AI-generated software)	elaboration (externalities / risks of the thesis, mostly team- and org-level)
Section 6: product management vs. software engineering — the roles converging into a blended 'product engineer' rather than PMs replacing engineers	elaboration (role-structure prediction)
Takeaways: caveats (large/complex orgs may see less impact), personal ambivalence about losing the craft of hand-writing code, and an overall forecast of rising demand for software professionals	conclusion / qualification

Key terms

a-ha moment
The specific, recognizable experience of an experienced engineer suddenly finding a coding agent capable of producing code as good as, or better than, what they would have written by hand — described as a discrete threshold crossing, not a gradual improvement.
coder vs. software engineer
'Coder' = someone whose value was writing code by hand; 'software engineer' = someone who also breaks down problems, architects for testability/observability, verifies output, and builds for scale/reliability/security. The article's central claim is that AI absorbs the 'coder' part and raises the price of the 'engineer' part.
product engineer Product Engineer (PM/Engineering Role Merge)
A blended role (cited examples: WorkOS at ~1 PM per 80 engineers; early Linear with no PMs at all) where software engineers absorb enough product-management work (talking to customers, specifying, prioritizing) that a separate PM function becomes less necessary, and PMs in turn become hands-on enough to ship prototypes themselves.
the middle (thinning middle software work) AI Labor Disruption
Karri Saarinen's term (quoted) for the translation layer between intent and implementation — writing the actual code — which pure coding-agent workflows are making thinner, shifting the valuable work to forming and shaping the intent itself ('directing and managing agent work becomes the craft').

Propositions

explicitMultiple independent, credible software engineers (at AI vendors and outside them, including a prior AI-coding skeptic, Karpathy) report the same specific experience in November-December 2025: AI coding tools crossed a threshold where they produce code as good as, or better than, what the engineer would write by hand.conf: high
explicitThree specific model releases — Gemini 3 (17 Nov), Opus 4.5 (24 Nov), GPT-5.2 (11 Dec) — are the proximate, dateable cause of the capability-threshold experience reported across the industry.conf: high
explicitdevelopedBoris Cherny (creator of Claude Code) reports that in one month, 100% of his code contributions were AI-written — effectively fulfilling Dario Amodei's March 2025 prediction that AI would write 'essentially all code' within roughly a year, faster than most (including the author) expected.conf: high
extends ←Head of Claude Code: What happens after coding is solved | Boris Cherny · p1 — This interview is the primary source behind that article's citation of Boris's '100% AI-written code' claim, and adds the crucial qualifying detail the secondary article doesn't carry: Claude also auto-reviews 100% of PRs, but a human layer still follows except for throwaway prototype code.
explicitBeing a language polyglot, prototyping skill, and deep single-stack specialization will decline in value, because AI lets any engineer jump into any codebase, ask the AI to implement a feature, and get a decent attempt — collapsing much of the advantage of knowing multiple languages or frameworks deeply.conf: high
supportsWhat's an Orchestrator—and Why Does Software Need One? · p6 — Orosz's 'language polyglot value declines' and the other document's 'market shifts toward generalist orchestrators rather than per-technology specialists' are the same claim about specialization losing its premium, stated independently.
explicitImplementing a well-defined ticket (bug report, small feature request) is a task AI will increasingly absorb end-to-end, evidenced by Cursor's existing workflow where Linear tickets are automatically handed to Cursor, which one-shots an implementation for a developer to merge or iterate on.conf: high
explicitTech-lead traits (writing requirements precisely enough — including nonfunctional requirements like performance, accessibility, reliability — and empathizing with users to break work into well-defined tasks) will be in higher demand, because someone still has to write the 'ticket' precisely enough for AI to execute correctly, and non-technical people cannot articulate the nonfunctional half of that.conf: high
explicitGetting good at testing and test infrastructure becomes more important, not less, because an agent needs fast feedback signals (compilation, static analysis, automated tests) to be effective and less prone to hallucination — and because the author personally cannot trust AI-generated code without unit/integration/end-to-end tests, while finding AI itself unreliable at writing good tests without targeted prompting.conf: high
explicitMaking good architecture decisions (monolith vs. services, interfaces/boundaries, testability strategy) becomes even more important as code is generated faster, because these are the decisions you must specify for AI to follow — otherwise you risk ending up with hard-to-maintain software even with AI's help.conf: high
explicitcorroboratedBeing a solid software engineer rather than merely a 'coder' will be more sought-after than before, because the engineering discipline (verification, tight feedback loops) is what makes AI-generated volume actually work, and 2025's vibe-coding wave already showed nontechnical people struggling to build software that actually works even with AI generating their code.conf: high
supportsAI Is Changing Software Engineering. The Fundamentals Still Matter. · p14 — Both make the article's central 'good news' claim — that good engineering fundamentals matter more, not less, as AI generates more code — independently and from different vantage points (personal practitioner essay vs. platform/SRE essay).
supports ←Stop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge · p7 — Both claim being a solid engineer (judgment, fundamentals) becomes more sought-after, not less, as AI absorbs implementation.
extends ←The third golden age of software engineering – thanks to AI, with Grady Booch · p8 — Booch's historical abstraction-level framework provides the deeper theoretical grounding for why 'solid software engineer over coder' becomes more valuable, not less.
explicitEarly data already shows AI-era code is lower quality in production: the Cortex 2026 Benchmark Report (50+ engineering leaders surveyed) found change failure rates (the percentage of deployments causing outages or rollbacks) increased 30%.conf: high
extendsAI Is Changing Software Engineering. The Fundamentals Still Matter. · p12 — Orosz's 'massive explosion in code... much more maintenance to be done' adds a concrete data point (30% change-failure-rate rise, doubled PR volume) to the other document's more abstract claim that winning the AI gold rush requires investing in the growing maintenance burden.
explicitcorroboratedTeams without a culture of automated testing, coding guidelines, or good observability will see regressions and outages 'hurt sooner' than before, because AI increases both the pace of shipping and the volume of code reaching production.conf: high
supports ←Disposable Code Is Here to Stay, but Durable Code Is What Runs the World · p3 — Both argue that a culture of automated testing, CI/CD, and observability is what determines whether AI adoption helps or hurts -- its absence makes regressions and outages 'hurt sooner' (Orosz) or means you don't get AI's efficiency gains at all (Majors).
explicitMobile/remote coding workflows (prompting, validating, deploying from a phone or browser) risk eroding developers' remaining work-life boundaries, the same way mobile Slack did for communication — extending 'always reachable' expectations into code changes themselves, with no corresponding change in compensation norms for salaried engineers.conf: high
explicitcorroboratedEntry-level engineers will be expected to hit a baseline that used to be senior/staff-level (breaking down work, working across the stack, being product-minded, architecting early, verifying AI output, test/observability fluency, tracking tech debt) — but this baseline used to be earned over years of hands-on coding and mentorship, which the AI-heavy path may compress or skip.conf: high
supports ←Redefining the Software Engineering Profession for AI · p4 — Both describe the entry-level bar rising (or the entry-level population shrinking) as AI reshapes who gets hired and what they're expected to already know.
explicitA rigorous computer-science / software-engineering education may become a near-non-negotiable hiring filter for new grads — partly on its own merits (teaching architecture, testing, tech-debt concepts before day one) and partly because universities function as 'spam filters' against the flood of AI-assisted, hard-to-verify job applications.conf: medium
explicitAs code and deployed software volume explodes, the professionals who must remain accountable for production outcomes are professional software engineers who understand the generated software and can maintain it — not non-technical people, even though non-technical people can now generate code themselves.conf: high
supportsWhat's an Orchestrator—and Why Does Software Need One? · p13 — Both converge on the same claim from different angles: AI 'democratizing' software creation has a hard ceiling at production accountability — someone professionally accountable still has to exist once stakes rise past a prototype.
explicitcorroboratedProduct management and software engineering are converging rather than one replacing the other: engineers become more product-minded and closer to customers (fixing reported bugs without PM triage), while PMs become more hands-on (shipping their own prototypes), producing a blended 'product engineer' role and smaller, more efficient teams than the old formal PRD hand-off model.conf: high
supports ←Head of Claude Code: What happens after coding is solved | Boris Cherny · p7 — Both make the same claim — that product management and software engineering are converging rather than one replacing the other — with Boris's firsthand account of his own team (universal coding, ~50% role overlap) as independent, lived corroboration.
explicitdevelopedIn large, complex tech organizations where developers already wrote comparatively little code and most complexity lived in organizational/system navigation, AI is unlikely to make a comparably large impact, unlike in simple, well-tested, low-risk codebases (the author's own 'a-ha moment' case).conf: high
refines ←The third golden age of software engineering – thanks to AI, with Grady Booch · p6 — Booch's 'trained on already-seen patterns' claim adds a mechanism for why large, complex organizational codebases (not just CRUD) remain a frontier AI hasn't absorbed.
implicitThe article treats 'engineering fundamentals becoming more important' as an unambiguous silver lining, without weighing it against its own admission that becoming good at those fundamentals has historically taken years of hands-on coding practice that the new AI-first path may no longer provide in the same way.conf: medium

Arguments

Software engineering as a discipline (judgment, verification, architecture, accountability) becomes more valuable as AI absorbs more code-writing, even as 'coding' itself becomes commoditized. strength: medium

Explicit premises:

AI increasingly absorbs code-writing tasks: prototyping, well-defined ticket implementation, refactoring, cross-language/cross-stack implementation.
More AI-generated code volume means more tech debt, more bugs, more resource usage, and a 30% rise in observed change-failure rate (Cortex 2026 report) — i.e., more raw material for things to go wrong.
Good software engineering practice (testing, architecture, verification, observability, tech-debt management) is precisely what catches and manages that increased raw material for failure.
Teams lacking those practices will be hurt sooner and more visibly as shipping pace increases.

Implicit premises:

Organizations will actually respond to rising failure rates and tech debt by investing more in engineering discipline, rather than by tolerating more outages as an accepted cost of speed, or by simply hiring cheaper, less-disciplined engineers to churn out more AI-assisted code.
The market will correctly price 'solid software engineer, not just coder' as a scarcer and more valuable skill, rather than undervaluing it because the volume of superficially-working code makes the difference hard for non-technical decision-makers to perceive.

Inferences:

If hiring and compensation don't actually reward verification/architecture skill more than raw output volume, the 'good news' (fundamentals become more valuable) could fail to materialize even though the underlying technical need for it is real — the argument's optimism depends on an unstated market-correction mechanism the article never defends.

Product management and software engineering roles will converge into a blended 'product engineer' role rather than AI letting PMs simply replace engineers.

Explicit premises:

At WorkOS, roughly one PM services 80 engineers; at early Linear, there were no PMs at all — both examples predate widespread 90%+ AI code generation but already show the ratio skewing toward engineer-as-product-owner.
As AI absorbs 'the middle' (translating intent into implementation), what's left — forming and shaping the intent itself — is product work, which engineers are increasingly well-positioned to do directly for small, well-understood changes (e.g., fixing a reported bug without PM triage).

Implicit premises:

The two cited companies (WorkOS, Linear) are representative of where the broader industry is heading, rather than being unusually small, engineering-led, or early-stage organizations whose PM-light structure reflects their size/stage rather than AI's effect on the PM/engineering boundary.
Nonfunctional, cross-cutting product decisions (pricing, sequencing across teams, stakeholder alignment at scale) — the parts of product management that are not simply 'write a clear ticket' — will also compress under this convergence, rather than remaining a distinct, scarce skill even in an AI-saturated org.

Narratives

The author's own holiday-break experience: using Opus 4.5 and GPT-5.2 to ship a few hundred lines of production code for long-deferred features (subscription self-service, admin panel), including setting up Claude Code for Web so he could review and merge PRs entirely from his phone while traveling.
→ Grounds the abstract 'AI now writes 90%+ of code' claim in a first-person, dateable, falsifiable anecdote, and implicitly supports the article's framing that this was specifically a step change in capability (the 'magical feeling') rather than a gradual improvement he'd already adjusted to.
Michael Novati's (formerly Meta's most productive developer, the inspiration for Meta's 'Coding Machine' archetype) GitHub activity roughly doubling in pull-request volume from 2024 (low AI use) to 2025 (heavy AI use), while sustaining 400-600 commits/month and 1,500+ new features plus 800+ bugfixes in a year on a startup platform.
→ Serves as concrete evidence for the 'more code & more resource usage = more problems' proposition in Section 5 — it shows the raw volume increase is real and large, which is the premise the rest of Section 5's risk list depends on.
Shaquille O'Neal, in a Replit ad, 'vibe-coding' an app for finding pickup lines with no development experience, producing only prototype-quality output.
→ Illustrates, rather than argues, the limits of non-technical AI-assisted coding (prototypes only) — setting up the contrast the article later draws between low-stakes prototyping (fine for anyone) and production software (still requiring accountable engineers).

Questions addressed

✅ Has AI actually crossed a real capability threshold in code generation, or is this hype?
Resolved via triangulated testimony from named practitioners across vendors and independents, including a converted skeptic (Karpathy), dated to specific November-December 2025 model releases.
✅ What happens to software engineering as a profession when AI writes almost all the code?
The 'coder' component commoditizes while the 'engineer' component (judgment, verification, architecture, accountability, product-mindedness) appreciates — argued across Sections 3-6.
⭕ Will this change actually translate into better career outcomes and compensation for engineers who develop these 'engineer, not coder' skills?
⭕ How does a junior engineer acquire the judgment the article says will be more valuable, if the hands-on coding practice that traditionally built that judgment is itself being automated away?
Partially gestured at (CS education as a filter, new grads may 'mature faster') but not worked through as a pipeline design problem.

Gaps

incompleteThe article asserts that entry-level engineers will be expected to hit a baseline that used to be senior/staff-level, and separately floats rigorous CS education as a possible answer to 'how does anyone become qualified' — but never designs the actual apprenticeship mechanism: if juniors no longer spend years writing code by hand under senior mentorship, what specifically replaces that as the vehicle for developing judgment about verification, architecture, and knowing when AI output is wrong?
Read next: Material on deliberately engineered apprenticeship/mentorship models for an AI-saturated pipeline, as distinct from pre-AI, personality-dependent mentorship.
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.
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).
illogicalThe article treats the PM/engineering convergence (Section 6) as a smooth, mutually beneficial blending for both roles, but its own earlier evidence (Section 5's work-life-boundary erosion, juniors being pushed to senior-level baselines) suggests convergence could instead mean each role simply absorbing more of the other's workload without a corresponding reduction in total work or headcount pressure — the article doesn't reconcile 'teams become smaller and more efficient' (good news, Section 6) with 'tougher work-life balance' (bad news, Section 5) even though both follow from the same underlying mechanism (fewer people doing more, faster).
Read next: Organizational-design material on whether role convergence under AI actually reduces total workload or just redistributes and intensifies it.

Closes gaps elsewhere

Presentation: A Few Predicted Talks From QConAI 2030 · g4 — That gap asks how anyone becomes qualified for the senior 'conductor'-style role if deep tech-stack knowledge stops being the entry ticket. This article answers directly: it proposes rigorous CS/software-engineering education as a near-non-negotiable hiring filter (teaching architecture, testing, and tech-debt concepts before day one) and argues new grads may 'mature faster' by skipping the pure-coding apprenticeship stage and jumping straight to engineering judgment — an explicit, if untested, proposal for the pipeline the other document leaves open.