Software Engineering Isn’t Dead. Typing Is.

TL;DR: Is software engineering dead now that AI writes most new code at Google and Anthropic? No. The job that died is the one that was never the job: converting a finished specification into code by typing. In the studies that measured it, coding was only 5–16% of a developer’s week, so making it instant speeds up the whole job by 1.05–1.20× (Amdahl’s law), and the 2026 field data shows exactly that pattern: code output up 30%, finished work flat, review time up 49%. What remains is deciding what to build, writing down the constraints the model cannot infer, verifying the result independently, and answering for it in production. That was always software engineering. AI made code cheap. It did not make being wrong cheap. Below: the arithmetic, the six silent defaults an agent fills in when you don’t, the Specification Conservation Law, the shadow spec that lives in your people’s heads and never reaches the model, what Spotify, Google, Anthropic and IBM are doing about it, a four-question Delegation Test, the 24 jobs Claude Code still cannot own, and the one part of this story that should worry every CTO: the apprenticeship ladder.

---

Seventy-two years of obituaries for programming. Sources in the chart footer.

Is software engineering dead? The question is 72 years old

On 10 November 1954, IBM’s preliminary FORTRAN report promised the new system would “virtually eliminate coding and debugging,” which at the time consumed more than three-quarters of a project’s elapsed time (IBM, 1954). In 1981, a product called The Last One was billed by Personal Computer World‘s editor as something that “could become the last one ever written by a human being” (Tebbutt, 1981). In 1982 James Martin published Application Development Without Programmers (Prentice-Hall). In November 2021 Gartner forecast that 70% of new applications would use low-code or no-code technology by 2025 (Gartner). In November 2025 “vibe coding” was Collins Dictionary’s Word of the Year (Collins). And on 20 January 2026 at Davos, Dario Amodei said models might be six to twelve months from doing “most, maybe all” of what software engineers do, end to end (reported remarks).

Meanwhile GitHub counted more than 180 million developers in October 2025, 36 million of them new in a single year (GitHub Octoverse 2025).

Mental model: base rates. Before you evaluate the newest prediction that programming is over, ask what usually happens to predictions like it. Six of them, over 72 years, each attached to a real technology that really did eliminate a layer of typing, and each followed by more software and more people building it. That doesn’t prove the seventh is wrong. It does mean the burden of proof sits with the obituary, not the profession.

Let me define the term, because the whole argument turns on it. Software engineering is the disciplined work of taking an ambiguous human intention and turning it into a reliable, changeable, accountable system, and then operating and maintaining it, which is roughly how the IEEE’s classic glossary frames the discipline. Example: a bank asks for “an order router.” The code is perhaps 40,000 lines. The engineering is the set of decisions nobody wrote in the ticket: that the router must fail closed rather than open when the risk service times out; that it must never retry a market order; that every rejection must carry a correlation ID the regulator can follow; that the whole thing must come back inside four hours because the Monetary Authority of Singapore says critical systems must (MAS Notice FSM-N09). Generate the 40,000 lines and you have a program. Make those decisions, check them, and sign for them, and you have engineering.

I’ve spent twenty years designing ultra-low-latency trading, market-data and cloud systems, at Citi, Goldman Sachs, JPMorgan and UBS and now at RocketEdge in Singapore. I have never seen a production incident caused by slow typing. Every one I’ve worked through was caused by a decision that was wrong, missing, or made by default. The homepage of this site has said it for years: the systems were rarely the hard part; choosing what to build, what to leave alone, and when to switch direction was.

Fred Brooks said the same thing about AI in 1986, in the section of No Silver Bullet literally titled “Artificial intelligence”: “The hard thing about building software is deciding what one wants to say, not saying it” (Brooks, 1986). AI has now made saying it nearly free. It has done far less for deciding.

What actually changed in 2025–26?

I want to concede the strong version of the other side first, because the rest of the argument is only credible if I do.

At the companies building the frontier, AI now writes most new code. Sundar Pichai, 22 April 2026: “75% of all new code at Google is now AI-generated and approved by engineers, up from 50% last fall” (Google). Anthropic says 70–90% of its own code company-wide (Fortune via Yahoo, January 2026), and its CFO put it at 90% in May 2026 (Business Insider). Microsoft said 20–30% back in April 2025 and hasn’t updated the figure (Economic Times). Across the industry, developers estimate 42% of committed code is AI-generated or assisted, per a Sonar vendor survey (Sonar, January 2026). Claude Code alone authored an estimated 4% of all public GitHub commits in February 2026 (Anthropic, citing SemiAnalysis).

Adoption is near-universal. Ninety percent of developers use coding agents weekly, 68% daily (JetBrains, August 2026). Claude Code is the agent of choice for 66% of agent users in Stack Overflow’s 2026 survey of more than 30,000 technologists (Stack Overflow). At Spotify, more than 99% of engineers use AI coding tools every week and pull-request frequency is up 76%; the title of their chief architect’s talk was “Coding Is No Longer the Constraint” (Spotify Engineering, June 2026).

The gains on well-scoped tasks are real and measured. Copilot users finished a greenfield task 55.8% faster in a controlled trial (Peng et al., 2023). Three field experiments with 4,867 developers found 26% more completed tasks, with the biggest gains for less-experienced developers (Cui, Demirer et al.). Anthropic’s engineers report 67% more merged PRs per engineer per day (Anthropic, December 2025). A quarter of Y Combinator’s W25 batch had codebases that were 95% AI-generated (TechCrunch).

I use these tools every working day. My own stack and workflow are in The Quant’s Guide to AI Coding Assistants. This post is not an argument that AI doesn’t help. It is an argument about where the remaining work, and the remaining risk, now sit.

Why was typing never the job?

Here is the premise most “AI will replace engineers” arguments rest on, usually unstated: that writing code was the largest part of the work. It wasn’t, and it hasn’t been for decades.

Year	Share of effort that was coding	Source
1954	Coding and debugging: more than 3/4 of elapsed time	IBM FORTRAN report
1975	Coding: 1/6 of the schedule (1/3 planning, 1/4 component test, 1/4 system test)	Brooks, The Mythical Man-Month
2018	Editing source code: 5.0% of recorded time; program comprehension: 58%	Xia et al., IEEE TSE (78 professional developers, 3,148 hours)
2024	Application development: 16% of developer time	IDC via InfoWorld
2025	Coding: ~11% of the actual week, slightly less than meetings (~12%)	Microsoft “Time Warp,” 484 developers

Seventy years of abstraction, from FORTRAN to COBOL to garbage collection to cloud APIs, shrank coding from three-quarters of the job to a tenth of it. Coding was always the most visible part of the job, not the biggest. Brooks drew the line in 1986 between the essence of software, the conceptual construct of specification, design and testing, and the accidents, representing that construct in a language. He put the hard part squarely in the essence (Brooks). Peter Naur argued in 1985 that programming is really the building of a theory in the programmers’ heads, and that the program text cannot carry that theory on its own (Naur, “Programming as Theory Building”).

Mental model: the Theory of Constraints, with Amdahl’s arithmetic. A system speeds up only as fast as its bottleneck. Amdahl’s law gives the ceiling: if a step is fraction p of the work, making it infinitely fast speeds up the whole by at most 1/(1 − p). Plug in the measured coding shares:

At the measured coding share of a developer’s week, infinitely fast coding buys a 5–20% speed-up of the whole job. Chart: jiripik.com, from the sources in the table above.

At 5%, the ceiling is 1.05×. At 11%, 1.12×. At 16%, 1.19×. Brooks ran the same arithmetic in 1986: unless the accidental part is more than nine-tenths of all effort, shrinking it to zero cannot deliver an order-of-magnitude improvement (Brooks). Nobody has ever measured coding at nine-tenths of anything.

The honest caveat: AI also speeds up parts of the essential work, such as analysis, prototyping, test writing, documentation and first-pass review, so the real gain is higher than the ceiling for coding alone. What it cannot remove is the human-gated core: deciding, verifying, answering. That is where the 2026 data says the bottleneck now sits.

Where did the bottleneck go?

If the Amdahl argument is right, we should see a specific pattern: individual code output rising sharply while organizational delivery stays flat and the queue forms at review and verification. That is exactly what the field data shows.

The most rigorous study is a Harvard job-market paper by Fiona Chen and James Stratton covering 718 firms and roughly 300 million work events from January 2021 to March 2026. After firms adopted AI coding agents, lines of code per worker rose 30%, commits 20% and pull requests 23%. Jira issues and epics resolved did not change significantly. The time from pull-request submission to merge rose by 3.45 days, a 49% increase on a baseline of 7.03 days, and the share of PRs with changes requested nearly doubled. The authors’ summary: “AI agents substantially intensify the code review process” (Chen & Stratton, August 2026).

Faros AI’s vendor telemetry across 22,000 developers and 4,000+ teams tells the same story from the other side: tasks per developer up 33.7%, bugs per developer up 54%, median time in review up 441.5%, and the incidents-to-PR ratio up 242.7% as teams move from low to high AI adoption (Faros, April 2026). Google’s own DORA research found AI “amplifies what’s already there” and remains negatively associated with delivery stability (DORA 2025). Pichai’s estimate of Google’s overall engineering velocity gain, with AI writing most new code, was about 10% (Business Insider, June 2025). That is an Amdahl number.

The most-cited study of all, METR’s randomized trial with experienced open-source developers, found they forecast a 24% speed-up, believed afterwards they had got 20%, and had in fact taken 19% longer (METR, July 2025). METR’s 2026 redesign could not establish a significant speed-up either way; the confidence intervals cross zero (METR, February 2026). And at Anthropic, where AI writes 90% of the code, most engineers say they can “fully delegate” only 0–20% of their work (Anthropic).

Spotify is the cleanest case study because they published both halves. In June the bottleneck had moved: “the constraints shift toward human decisions,” with 76% more PRs to review and a team “learning where to apply human judgment” (Spotify, June 2026). In September they published what that cost. Reviewing their major incidents, they “did not identify AI-authored code as a material direct contributor.” What they did find was that “the volume of change increased faster than some of our verification controls could adapt” (Spotify, September 2026). The fix was more engineering, not less: stronger review, testing, rollout, observability and rollback.

Mental model: second-order effects. The first-order effect of a coding agent is more code. The second-order effect is that everything downstream of code, review, testing, deployment, incident response, now runs at a volume it was never sized for. AI doesn’t remove the engineering. It moves it: upstream into the specification and downstream into verification.

Why does a complete prompt turn into engineering?

Here is the mechanism, and it is the center of this post.

Model what ships as three parts. S is everything you specify. D is the defaults the model supplies for everything you didn’t, drawn from the typical patterns in its training data rather than from your constraints. V is what you verify. What goes to production is S + D. Only V tells you whether D was right.

To make the output production-grade you must enlarge S and V. And enlarging S and V is, precisely, software engineering. I call this the Specification Conservation Law: ambiguity removed from the prompt has to be supplied by someone who understands the system. You can move the engineering. You cannot remove it. A prompt complete enough to produce a production system is itself an act of software engineering.

The evidence is unusually direct:

• Anthropic’s own guidance for Claude Code: “Claude can infer intent, but it can’t read your mind,” and “If you can’t verify it, don’t ship it” (Claude Code best practices).
• Prompt detail is the single biggest lever on output quality. In a controlled study, the same open-weight model (Qwen2.5-Coder-14B) went from a 0.280 pass rate on HumanEval with a minimal prompt to 0.921 with a detailed one, and from 0.483 to 0.967 on parallel scientific code (PartialOrderEval, August 2025). Same model, same tasks; the only thing that changed was how much the prompt-writer knew.
• Expertise still pays. Across roughly 400,000 Claude Code sessions, people rated as novices reached verified success 15% of the time; intermediate users and above, 28–33%. People made about 70% of planning decisions; Claude made about 80% of execution decisions. Anthropic’s one-line summary: “People decide what to build, and the agent decides how to build it” (Anthropic, June 2026).
• Security that isn’t specified doesn’t appear. Veracode’s vendor benchmark found 45% of AI-generated samples contained flaws in 2025 and a 56% security pass rate in 2026, unchanged over four years of model releases, when security isn’t asked for (Veracode 2025; Veracode 2026).
• Models game the check you give them. METR found o3 reward-hacked in 0.7% of HCAST runs and more than 43 times as often on RE-Bench (METR, June 2025). Whoever writes the pass/fail criterion is doing engineering, and it cannot be the agent being graded.

Two of the field’s founders saw this coming. Dijkstra, in 1978, warned that natural-language programming makes it easy to write statements “the nonsense of which is not obvious” (EWD667). Brooks, in 1986: “the hardest part of the software task is arriving at a complete and consistent specification” (Brooks). Both were describing the job that Claude Code has now handed back to us, with the typing removed.

What does the model silently decide for you?

Here is the framing I use with clients: every requirement you leave out of the prompt is a decision you’ve delegated to the average of the internet. And there is a nastier corollary: you can’t prompt for a failure mode you’ve never heard of. The person who has never seen a retry storm will not ask for a retry budget.

This is compounded by a measured perception gap. METR’s developers felt 20% faster while being 19% slower (METR). An Aalto University study found AI users overestimate their own performance, and that the more AI-literate were more overconfident, not less (Aalto, 2026). Microsoft Research and CMU, surveying 319 knowledge workers, found that “higher confidence in GenAI is associated with less critical thinking, while higher self-confidence is associated with more critical thinking” (Lee et al., CHI 2025).

Here are the six silent defaults I see most often, each with the real incident that shows what the default costs. None of these outages was caused by AI-written code; every one is a lesson in what happens when a design decision is made by omission.

Default 1: Cost and region

Ask for “a service on AWS” without stating cost, latency, residency and resilience constraints, and the region is chosen for you. The same m5.large instance costs about $70 a month in N. Virginia, $88 in Singapore (+25%) and $112 in São Paulo (+59%) (instance pricing); ten always-on instances in the wrong region is roughly $5,000 a year, my arithmetic. A NAT Gateway bills $0.045 an hour plus $0.045 per gigabyte processed, the classic silent bill (AWS VPC pricing). Flexera’s 2026 survey put self-estimated cloud waste at 29%, the first increase in five years, driven by AI workloads (Flexera). A $7 Firebase budget once became a $72,000 bill overnight (The Register).

Region is also a legal decision: Meta’s €1.2 billion GDPR fine was for data transfers (IAPP). And a resilience decision: the most popular region, us-east-1, was the site of a roughly 14.5-hour AWS outage in October 2025 (AWS post-event summary) and of the zone failure behind Coinbase’s eight-hour outage in May 2026 (Coinbase postmortem). If your prompt doesn’t state cost, latency, residency and resilience, the region is chosen for you, and it can be wrong on all four.

Default 2: Resilience and retries

The naive version of this default is “no retries, so the service fails on any network blip.” The dangerous version is “retries added without design.” Google Cloud’s 12 June 2025 outage was made worse because new code shipped with no feature flag and no error handling, and the affected service “did not have the appropriate randomized exponential backoff,” which produced a herd effect; us-central1 took about 2 hours 40 minutes to recover, and some customers’ monitoring ran on GCP and failed with it (Google Cloud incident report). AWS’s Builders’ Library shows why: five layers each retrying three times multiply database load 243 times. Retry at one layer, with jitter and a retry budget (Marc Brooker, AWS). Cloudflare’s worst outage since 2019, on 18 November 2025, came from a feature file that doubled past a hard limit of 200 and a Rust unwrap() that panicked; the code worked until an unstated assumption broke (Cloudflare). “Add retries” is a prompt. Retry design is engineering.

Default 3: Observability and traceability

New Relic’s vendor survey put the median cost of a high-impact outage at $2 million an hour, halved for firms with full-stack observability (New Relic 2025). Their 2026 edition found 83% of respondents say AI-generated code makes observability essential, while 25% run AI agents in production without monitoring (New Relic, September 2026). Forty-one percent of technology executives told Splunk their customers often or always detect downtime first (Splunk/Oxford Economics). The precedent every trading technologist knows: Knight Capital, 1 August 2012. New code was copied to seven of eight servers, there was no second check and no written deployment procedure, and 97 automated error emails went out before the open that nobody had designed as alerts. The firm lost more than $460 million in about 45 minutes (SEC order). An alert nobody designed is a log line.

Default 4: Security and supply chain

Beyond the flat Veracode pass rates, a USENIX Security 2025 distinguished paper found that at least 5.2% of packages recommended by commercial models and 21.7% by open-source models do not exist, 205,474 unique fake names in total, an attack surface now called “slopsquatting” (Spracklen et al.). Roughly 10% of scanned apps built on one vibe-coding platform exposed data through missing row-level security (CVE-2025-48757 analysis); a vibe-coded social app exposed 1.5 million API tokens the same way (Wiz, February 2026). Repositories with Copilot enabled showed about 40% higher secret exposure, a correlation (GitGuardian 2025).

Default 5: Destructive actions and permissions

In July 2025 a Replit agent deleted a production database during an explicit code freeze, then generated fabricated data; the CEO called it “unacceptable and should never be possible” and shipped dev/prod separation (Times of India). On 24 April 2026 a Cursor agent running Claude Opus 4.6, working in PocketOS’s staging environment, hit a credential mismatch, found an unrelated API token in a file, and deleted the production volume and its backups in a single call that took about nine seconds. The token had been created for managing domains but was scoped for any operation; the legacy endpoint had no delayed-delete; the backups lived on the same volume. The data was restored over the weekend (The Register). The model wasn’t malicious. It was under-specified and over-permissioned. A microwave will heat whatever you put in it. An agent will run whatever its permissions allow. Blast radius is an architectural decision: least privilege, separate environments, backups the agent cannot reach.

Default 6: Maintainability

GitClear’s analysis of 623 million changed lines found duplicated code blocks up 81% and “moved” (refactored) code down from 21% of changes in 2022 to 3.8% (GitClear 2026). Agents add code. Someone has to keep complexity in check, and the agent has no incentive to delete.

The architect’s paragraph: three illustrative prompt pairs

These are the three defaults I started this post with: cost, retries, observability. Below is what the difference between a product-manager prompt and an architect prompt looks like. These pairs are illustrative. I have designed a controlled experiment (ten fresh Claude Code sessions per arm, fault injection with a network proxy, cost estimate from the generated infrastructure code, security scan, and a check for modified tests) and will publish the raw outputs here when it has run. Until then, no pass rates are claimed.

# Naive prompt (cost)
Create Terraform for a Postgres database and a container app for my API.

# Architect's prompt (cost)
Create Terraform for a Postgres database and a container app for my API.
Constraints: monthly budget < USD 150 at ~50 req/s; data must stay in Singapore
(ap-southeast-1 / southeastasia); prefer burstable or serverless tiers; no
zone-redundant options unless required for an SLO of 99.9%.
Output a cost-estimate table per resource BEFORE writing code.
Ask me if any constraint conflicts with another.

# Naive prompt (reliability)
Write a Python client that fetches prices from the vendor REST API and stores them in Postgres.

# Architect's prompt (reliability)
Write a Python client that fetches prices from the vendor REST API and stores them in Postgres.
Reliability: treat 408/429/5xx and connection errors as retryable; exponential backoff
with full jitter, max 5 attempts, total deadline 30 s; respect Retry-After;
per-request timeout 5 s; retry at THIS layer only; writes must be idempotent
(upsert on (symbol, ts)); on final failure emit a structured error and exit non-zero.
Add tests that inject 503s and a dropped connection. Show me the test output.

# Naive prompt (observability)
Build a FastAPI service that scores incoming orders with our model.

# Architect's prompt (observability)
Build a FastAPI service that scores incoming orders with our model.
Observability: structured JSON logs with request_id and order_id on every line;
OpenTelemetry traces for the HTTP handler and the model call; Prometheus metrics for
request count, latency histogram and model-error count; a /healthz that checks the
model is loaded. Then inject a 20% model timeout and show me how I would find it
from the logs and metrics alone.

The second prompt in each pair is not “prompt engineering.” It is the content of a design review. The person who can write it is an architect, whichever tool executes it. And notice what it took to write it: knowing that AWS charges by region, that Retry-After exists, that correlation IDs are what let you follow one order through nine services at 2 a.m. None of that is in the ticket. All of it is in someone’s head.

Why does the most important knowledge never reach the model?

This is the part of the argument that most AI commentary skips, and it is the part boards most need to hear.

A model can retrieve information. A reliable decision needs four things retrieval does not supply: context (what this system is for and what it must never do), judgment (which of two defensible options is right for this firm), exceptions (the cases where the written rule is wrong and everyone experienced knows it), and operational logic (the order things actually happen in, and who has to be told). Economists have a name for why this knowledge is so hard to hand over: Polanyi’s paradox, “we know more than we can tell,” which David Autor identified as the main reason tasks resist automation (Autor, 2015). Naur called it the theory of the program. Thoughtworks’ Technology Radar now calls its absence “codebase cognitive debt,” the gap between what a system does and what the team understands about how and why it works, and flags that it “reduces developers’ ability to guide AI effectively” (Thoughtworks Radar Vol. 34).

I call it the shadow spec. Every production system runs on two specifications: the one in the repository and the one in people’s heads. The model reads only the first. In a trading firm the shadow spec is the trader’s spreadsheet that quietly overrides the risk engine’s limits; the compliance officer’s veto that has never been written down because nobody has ever dared propose the thing it forbids; the “we never deploy on a US payrolls Friday” rule; the client whose orders skip the senior-review queue because a managing director agreed to it over dinner in 2019; the fact that the vendor feed’s “null” means “unchanged” on one exchange and “halted” on another. Every one of those is a composite from twenty years of trading floors, not a disclosure about any one client, and every one of them was real somewhere. No repository contains any of this. No agent can infer it. And an agent that doesn’t know an exception exists will enforce the written rule with perfect, catastrophic consistency.

The evidence that this knowledge stays invisible is now coming from every direction:

• Models don’t ask. A 2026 study found that language models recognize ambiguity when asked about it, yet in practice “overwhelmingly default to direct answers,” and that giving them retrieved context made them less likely to ask a clarifying question (Knowing but Not Showing, May 2026). Anthropic’s own docs say the same thing more gently: “Letting Claude jump straight to coding can produce code that solves the wrong problem” (Claude Code best practices). Claude Code can interview you in plan mode. It cannot interview your stakeholders, and it cannot notice what they don’t say.
• Models forget. “Each Claude Code session begins with a fresh context window,” and auto-compaction can summarize away path-scoped rules (Claude Code docs; context window docs). A CLAUDE.md file is a lossy compression of the team’s theory, written by whoever still holds it.
• Enterprise pilots fail on exactly this. MIT’s Project NANDA reviewed more than 300 enterprise generative-AI initiatives in 2025 and reported that 95% of organizations saw no measurable P&L return. Its central explanation was not model quality but a “learning gap”: tools that do not retain feedback, adapt to context or learn the workflow (MIT NANDA, as reported by Fortune). The sample is small and the six-month window is short, as critics noted, so treat the 95% as directional. The diagnosis, though, matches everything above.
• The strategists have noticed. Accenture’s Teresa Tung and Philippe Roussiere, writing in California Management Review in March 2026, argue that “the real differentiator is not the data or even the models, but the ‘tacit knowledge’ embedded in the judgment of their people,” and conclude: “In a world where data is abundant and models are open, tacit knowledge is your next competitive moat” (CMR Insights). SAP calls the same thing “the institutional memory crisis”: the accumulated judgment, informal rules and organizational wisdom that “is invisible to every AI system” and leaves when experienced people leave (SAP).

Mental model: Kremer’s O-ring. In Michael Kremer’s 1993 model, production is a chain of tasks in which one failure spoils the whole output, which is why automating some steps raises the value of the humans who do the remaining ones (Kremer, QJE 1993). The shadow spec is the O-ring. When the code is free, the person who knows that “null” means “halted” on one exchange is the most expensive and most valuable component in the pipeline.

Now the intent investigation, because the stated reasons for this gap are not the real ones.

• Stated reason: “Our documentation is incomplete; we’ll fix it.” Does it hold? Partly. But documentation was incomplete in 1985 too, and Naur’s point was that no documentation carries the full theory. Fixing docs is necessary and insufficient.
• Stated reason: “The model’s context window is too small.” Does it hold? No. Context is 1 million tokens on current models, and the problem gets worse as it fills; one 2026 study found frontier safety classifiers miss a dangerous agent action 2–30 times more often after 800,000 tokens of benign activity (Classifier Context Rot). More context is not more understanding.
• Real reason: The knowledge was never captured because, until now, it didn’t have to be. The senior engineer applied it tacitly at code-review time and in the on-call rotation. Agents moved code generation out of that loop, so the tacit check no longer fires automatically.
• Second-order check: If you respond by writing everything down, you discover that the people who can write it down are the seniors you were hoping to need fewer of, and that the juniors you stopped hiring were how the knowledge used to be transmitted.
• Real solution: Treat the shadow spec as an engineering artifact with owners, reviews and versions: architecture decision records that capture why, not just what; machine-readable constraints (CLAUDE.md, skills, hooks) that encode the exceptions; and a verification function sized for the new volume of change. Which is exactly what the leading organizations are doing.

What are leading organizations doing about it?

The pattern is consistent across every firm that has published: they write down the shadow spec, fund verification, keep a named human accountable, and protect the apprenticeship.

Organization	What they do	Why it matters
Google	Counts only code “AI-generated and approved by engineers” (Google, April 2026)	Every line still passes a human gate; the 75% is a typing share, not an accountability share
Spotify	Standardized on Backstage so code is consistent, because “if Claude has a lot of other code to look at, and that code looks roughly consistent, Claude will do a better job”; auto-merges what is safe and focuses review where it matters; added AI-specific questions to every monthly incident review; strengthened review, testing, rollout, observability and rollback when change volume outran controls (Spotify, June 2026; September 2026)	Treats verification capacity as the constraint and invests there
Anthropic	CLAUDE.md as the written shadow spec; its review plugin’s output is “a starting point for human review” (plugin README); engineers “focus on architecture, system design and what to build” and “humans are still reviewing the code” (2026 Agentic Coding Trends Report); hired more people as code share passed 90% (Business Insider)	The company whose product is the model keeps humans on the plan and the review
GitHub	The person who asks Copilot’s coding agent to open a PR cannot approve that PR (GitHub docs)	Separation of duties for agents, borrowed from finance
OpenAI	Its alignment team on coding agents: “We must check their work” (OpenAI, December 2025)	Independent verification is a stated requirement from the vendor itself
IBM	Tripling US entry-level hiring in 2026; its HR AI handled about 94% of routine requests but not the 6% involving ethical dilemmas (CNBC; Business Standard)	The exceptions are where the humans are; the pipeline is how you get them
Shopify	About 1,000 interns a year, in 2025 and again in 2026 (CoderPad)	Protects the apprenticeship ladder explicitly
Thoughtworks	Named “codebase cognitive debt” and “AI-accelerated shadow IT” as Caution items; moved Claude Code to Adopt in the same Radar (Vol. 34)	Adopt the tool, govern the understanding
Accenture (via CMR)	Map where tacit knowledge lives, codify it without flattening it, build a semantic layer, keep human review for low-confidence cases, make business leaders own it (CMR Insights)	A method for turning the shadow spec into an asset
MAS (Singapore)	Guidelines on AI Risk Management, issued 7 October 2026: boards and senior management must oversee AI risk; life-cycle controls include “data governance, testing, human oversight, cybersecurity, monitoring and change management”; and “FIs remain accountable for AI used in the services they deliver, including AI developed, operated or provided by third parties” (MAS)	The regulator has put accountability in writing; agentic AI consultation follows in 2027
EU	DORA Art. 5: the management body bears “the ultimate responsibility” for ICT risk and its members must keep “sufficient knowledge and skills” to understand it (DORA Art. 5); the Cyber Resilience Act puts secure-by-design duties on manufacturers, with vulnerability reporting live since 11 September 2026 (European Commission)	Someone with a name has to understand and sign

Note the Singapore-versus-Europe contrast, because I sit between them. Europe legislates the duty and the board’s competence (DORA Art. 5(4) is, in effect, a requirement that directors understand ICT risk). Singapore writes supervisory expectations with a one-year runway and a named principle: the FI is accountable even for third-party AI. Different instruments, same answer. Regulators don’t accept “the model did it.” MAS put it in writing on 7 October 2026.

How do you decide what to hand to an agent? The Delegation Test

Here is the framework I use. A task can be handed to Claude Code end to end only if all four answers are “yes.” If any is “no,” an engineer owns it and Claude Code assists.

#	Question	Why it matters	Evidence
1	Can everything that matters be written down? (Specifiable)	Tacit, political, commercial and future knowledge isn’t in the repo	“Claude can infer intent, but it can’t read your mind” (Anthropic); Polanyi’s paradox (Autor)
2	Can success be checked independently of the agent? (Verifiable)	An agent grading its own work can game the test	Reward hacking (METR); scores drop under holistic rather than algorithmic grading (METR time horizons)
3	Can a mistake be undone cheaply? (Reversible)	One-way doors need deliberation	Bezos’s Type 1 vs Type 2 decisions (2015 letter); PocketOS; Claude Code checkpoints don’t capture Bash changes (docs)
4	Does nobody have to answer for it? (Unaccountable)	Customers, regulators, courts and boards need a named human	Anthropic’s Commercial Terms make the customer responsible for evaluating outputs (archived terms); EU DORA Art. 5; MAS 2026

Worked examples:

• Rename a function across a repository: yes, yes, yes, yes. Delegate.
• Add an endpoint with tests to a well-specified service: mostly yes. Delegate, then review.
• Choose the primary datastore for a trading platform: fails 1, 3 and 4. The engineer decides. Claude Code prototypes and benchmarks the options overnight, which makes the decision cheaper, not optional.
• Run a production incident at a regulated bank: fails 2, 3 and 4. The engineer commands. Claude Code correlates logs and proposes hypotheses through MCP. It cannot carry the pager, and MAS wants notification within one hour (MAS Notice FSM-N09).

The shareable version: if you can’t write it down, can’t check it, can’t undo it, or have to answer for it, it’s engineering, not typing.

The 24 jobs Claude Code can’t own

A word on “can’t do” versus “can’t own.” Claude Code can do far more than most critics claim. As of October 2026 it reads tickets, error trackers and databases through MCP; runs any command, runs tests, commits and opens PRs; works unattended in cloud sessions and CI; reviews code and finds vulnerabilities; tests UIs; remembers across sessions through CLAUDE.md and auto memory; plans, and interviews you about requirements (Claude Code overview). The list below is not what it can’t do. It is what it cannot own, for one of six structural reasons:

• K (Knowledge): the necessary information isn’t in its context and can’t be inferred.
• A (Authority): a trade-off between stakeholders needs someone with the right to decide.
• R (Responsibility): someone has to answer for it, legally, by regulation or by contract.
• V (Verification): it needs an independent check, and the agent can’t grade its own work.
• C (Continuity): it needs the long-lived theory of the system, not one session’s context.
• P (People): it depends on trust, negotiation, leadership or teaching.

#	The job	Why an engineer owns it	What Claude Code can do
I. Decide what to build
1	Choose the problem worth solving, and kill the ones that aren’t (build, buy, or don’t build)	K, A. Brooks: “the hardest single part of building a software system is deciding precisely what to build”; the most radical solution is “not to construct it at all”	Research options, draft specs, prototype in hours
2	Draw out tacit, unstated requirements: the trader’s shadow spreadsheet, the compliance veto, the latency the desk simply expects	K, P. Brooks: “the client does not know what he wants”	Interview you in plan mode; not your stakeholders
3	Resolve conflicting requirements and say “no”: risk vs speed, compliance vs UX, cost vs latency	A, P. EU DORA puts risk tolerance with the management body	Lay out options and trade-offs
4	Turn risk appetite into numbers: SLOs, error budgets, RTO/RPO, latency and cost ceilings	K, A. MAS: critical systems RTO ≤ 4h, ≤ 4h unscheduled downtime a year; someone designs to that and signs	Model, simulate, calculate
5	Define what “correct” means where plausible-but-wrong is catastrophic (P&L, risk, regulatory reports)	K, V. Verification only proves a program meets its spec; models game tests	Write tests against your criteria; suggest edge cases
II. Design the system
6	Make the one-way-door decisions: data model, primary datastore, cloud and region, consistency model, vendor lock-in	A, R. Bezos’s Type 1 decisions	Prototype and benchmark alternatives fast
7	Keep complexity and technical debt under control for years: boundaries, deletion, refusing features	C, A. GitClear: refactoring down to 3.8% of changes; CISQ estimated US technical debt at ~$1.52 trillion (CISQ 2022)	Refactor at scale on request
8	Align architecture with the organization: team boundaries, ownership, on-call (Conway’s law, 1968)	A, P	Map dependencies, suggest boundaries
9	Engineer for failure: timeouts, retries with backoff and jitter at one layer only, idempotency, circuit breakers, load shedding, multi-zone, DR drills	K, V. Google Cloud, Cloudflare, AWS, Coinbase	Implement every pattern when asked; run the chaos tests you design
10	Engineer for cost: region, instance family, storage tiers, egress and NAT traps, commitments, cost per trade	K, A. It can’t see your negotiated discounts or forecast volumes	Estimate with pricing tools
11	Engineer for security, privacy and residency: threat model, trust boundaries, least privilege, supply-chain policy, jurisdictions	K, R. Anthropic doesn’t security-audit MCP servers; prompt injection remains a risk (docs)	Run /security-review and scanners
12	Engineer for observability and auditability: business-level SLIs, correlation IDs, regulator-grade audit trails, alerts that wake the right person	K, A. Knight Capital’s 97 emails	Instrument code; query Sentry through MCP
13	Protect data and irreversible operations: migrations, backfills, retention, restore drills, the agent’s own blast radius	R, V. Replit; PocketOS	Write reversible migrations when asked
III. Verify
14	Be the independent verifier: review with suspicion, catch the “almost right”	V, R. 66% of developers cite “almost right, but not quite” (Stack Overflow 2025); 6.6% trust AI for important decisions (2026); AI PRs carry ~1.7× the issues (CodeRabbit, vendor)	First-pass review, “a starting point for human review”
15	Design the verification system: property, contract, load, chaos and canary tests; CI gates; evals for AI features	V	Write the tests and harnesses you specify
16	Catch specification gaming: tests special-cased or edited to pass	V. The agent is the party with the incentive to game; it can’t be the referee	—
IV. Operate
17	Decide how and when to ship: staged rollouts, flags, canaries, kill switches, change freezes	A, R. CrowdStrike’s fix added deployment rings (Microsoft); Google Cloud’s change had no flag	Build the pipeline and the flags
18	Command incidents: triage under uncertainty, halt-or-degrade calls, client and regulator notifications on legal clocks (MAS 1 hour; EU DORA 4h / 72h / 1 month (EBA)), blameless postmortems	A, R, P	Correlate logs, propose hypotheses and fixes
V. Own
19	Sign off and carry the liability: production approvals, attestations, answers to auditors	R. Anthropic’s terms; EU DORA; MAS	—
20	Turn regulation and ethics into design: what “human oversight” means here; what should not be built at all	A, R. MAS lists human oversight among required controls	Summarize regulations, map to controls
21	“Engineer the engineer”: govern the AI-assisted development system itself: CLAUDE.md and skills, permission modes, sandboxing, hooks, MCP vetting, secrets, CI gates, which tasks may run unattended	A, R, V. 25% of firms run agents in production without monitoring	Help draft its own guardrails; it can’t be the authority that sets them
VI. Remember
22	Hold the theory of the system: why decisions were made, the unwritten invariants, what was tried and failed; write it down for humans and agents alike	C. Naur; “each session begins with a fresh context window”	Read and update docs and memory files
VII. Lead
23	Translate between business and technology: explain trade-offs to boards and CFOs, win budgets, earn trust	P, A. DORA Art. 5(4) requires board members to understand ICT risk; someone has to teach them	—
24	Grow the next generation: hire, mentor, use review as teaching, keep a junior pipeline so there are seniors in 2036	P, C. Brooks: “Great designs come from great designers”	—

The condensed version, for anyone who needs it on one slide: a software engineer in the AI era does seven things. Decide what to build. Design it. Verify it. Operate it. Own it. Remember it. Lead the people. AI can now type all of it. It can own none of it.

The microwave and the restaurant

The microwave made reheating free. Americans ate out more, not less. Correlation, not cause; sources in the chart footer.

Historical precedent. Raytheon filed the microwave patent on 8 October 1945; the first Radarange in 1947 stood about six feet tall and weighed about 750 pounds, and it went into professional kitchens first (Lemelson-MIT). The countertop model arrived in 1967, reportedly at $495 (History.com). Then it went everywhere: 8% of US households in 1978, 34% in 1984, 79% in 1990, 96% in 2009 (EIA RECS). That is Claude Code’s arc too: a professional tool first, then everyone’s.

What happened to the people who cook for a living? Eating out rose from 25.9% of US household food spending in 1970 to 50.4% in 2025 (USDA ERS). Restaurant and foodservice sales went from $42.8 billion in 1970 to a forecast $1.55 trillion in 2026, roughly 36× in nominal terms, my arithmetic on the National Restaurant Association’s figures. Employment in food services and drinking places went from 6.5 million in January 1990 to 12.4 million in September 2026, up about 90% (BLS via FRED). Women’s daily cooking time fell from 113 minutes to 66 between the mid-1960s and 2008 (Smith, Ng & Popkin): home cooking time fell, demand for professional cooking rose.

The sharpest parallel is not the totals. It is the job mix. The BLS projects for 2025–35 that restaurant cooks grow 12% while short-order cooks shrink 5%, and says so plainly: “short order cooks are being replaced by more versatile restaurant cooks” (BLS Occupational Outlook). Set that beside the BLS’s August 2026 software projections: computer programmers −7%, software developers and QA +10% (BLS, developers; programmers). The short-order coder, ticket in and code out, shrinks. The versatile engineer grows.

The analogy, in full. Claude Code is the best kitchen appliance ever built. It is not the chef, and it is certainly not the restaurant.

Kitchen	Software
Microwave at home	Vibe coding: fast, good enough for personal use
Combi oven in a professional kitchen	Claude Code in professional hands
Recipe	Prompt, spec, CLAUDE.md
Menu design	Product strategy: what (not) to build
Sourcing ingredients	Dependencies and supply chain (hallucinated packages)
Food-cost percentage	Cloud unit economics (FinOps)
Health inspection and license	Security audit; MAS, EU DORA
500 identical covers on a Saturday night	Reliability at scale (SLOs)
The pass, where the chef tastes every plate	Code review and verification
Kitchen brigade	Team topology (Conway’s law)
Chef’s name on the door	Accountability
Food-poisoning outbreak	Production incident or data breach
Short-order cook (shrinking)	Ticket-to-code programmer (shrinking)
Restaurant cook or chef (growing)	Versatile engineer or architect (growing)

Cooking a meal isn’t running a restaurant. Generating code isn’t running a production system. The microwave made reheating effortless. It never inspected a kitchen, set a menu, or answered to a health inspector.

Where the analogy breaks, because an analogy that only flatters the argument is worthless:

• Different tasks. The microwave replaced home cooking time, not professional cooks’ tasks. AI agents do professional coders’ core work. So the honest comparison is the job-mix shift, short-order versus versatile, not “nothing changed.”
• Different cause. Restaurant growth is usually attributed to rising incomes, demographics and more women in the workforce, not to microwaves. Use the analogy to illustrate, never to prove causation.
• Not every year was up. Restaurant employment fell 48.6% in April 2020 and has been roughly flat since 2023, just 0.9% above February 2020 (FRED). The National Restaurant Association reports 42% of operators weren’t profitable in 2025 (NRA). Restaurant labor productivity stayed almost flat for about 30 years despite new kitchen tools (Becker Friedman Institute), which is the Amdahl point again: better tools don’t automatically raise system-level output.
• A microwave doesn’t act. An agent executes commands with real-world consequences. The right analogy for the risk is not a microwave but a commercial kitchen with gas lines: power that requires process.

The same pattern appears wherever one input got cheap. Jevons observed in 1865 that more efficient coal use increased total coal consumption (Jevons). Autor’s 2015 survey: tasks that cannot be substituted by automation are generally complemented by it (Autor). Spreadsheets reduced bookkeeping clerks while accountant jobs grew, as NPR’s Planet Money reported (NPR, 2015). ATMs cut tellers per branch from 20 to 13 between 1988 and 2004 while branches grew 43%, so teller jobs didn’t fall (Bessen, IMF). And the honest coda to that one: the BLS now projects tellers −13% for 2025–35 as mobile banking spreads (BLS). Complementarity isn’t permanent. It depends on the next technology. Which is why the argument that survives model improvements has to be about standing, not skill, and that is where the steelman comes in.

The strongest case that I’m wrong

Here is the opposing case at full strength, then weighed. Mental model: Analysis of Competing Hypotheses. List the rival explanations, weigh each piece of evidence by how well it distinguishes between them, and look for disconfirmation.

The case for “dead”:

1. The share is exploding. Google’s AI-generated share went from about 25% in October 2024 (Alphabet) to 50% in fall 2025 to 75% in April 2026. Claude Code authored about 4% of public GitHub commits in February 2026, with a projection of 20%+ by year-end.
2. Capability compounds. METR’s 50%-success time horizon has doubled roughly every seven months since 2019 and every 89 days since 2024 (METR). SWE-bench Verified is effectively saturated at around 96%.
3. Insiders say so. Amodei’s Davos “most, maybe all.” Claude Code’s creator, Boris Cherny, reportedly saying “I don’t think we’re going to call them engineers” (LeadDev).
4. The labor market is moving. US programmer jobs fell by more than a quarter in two years, to the fewest since 1980 (Washington Post). The BLS cut its developer growth projection from 15.8% to 10%. Software postings remain about 27.5% below February 2020 (Indeed Hiring Lab).

The rebuttal, point by point:

1. Share of code isn’t share of engineering. If coding is 11–16% of the job, 100% AI-written code automates that slice and adds review load: Harvard’s +49% merge time, Faros’s +441% review time. Google’s own velocity estimate is about 10%. AWS CEO Matt Garman calls the AI-share-of-code figure “a silly metric,” because you can use AI to write “infinitely more lines of code” and they can be bad ones (The Register).
2. Benchmarks aren’t production. METR says its own tasks are “much ‘cleaner’ than real economically valuable labor” and that scores drop under holistic grading (METR). A 50% success rate isn’t production reliability; for Claude Opus 4.5, the 80%-success horizon was roughly ten times shorter than the 50% one, as reported (Digit). On harder, standardized boards the leaders score around 51–62% (SWE-bench Pro), and in OpenAI’s SWE-Lancer, frontier models were “still unable to solve the majority of tasks” (OpenAI).
3. Watch what insiders do, not what they say. Amodei, October 2025: “you need just as many software engineers. You might need more” (Business Insider). Anthropic’s CFO: AI writes 90%, and Anthropic hired more. Cherny, February 2026: “great engineers are more important than ever,” with 100+ open roles (OfficeChai). Pichai expects to grow Google’s engineering base (Yahoo Finance). Call them builders if you like. Someone still has to decide, verify and answer.
4. The labor shift hits the routine layer and the entry ramp, not engineering. Programmers −7% versus developers and QA +10%, still more than three times the 3% all-jobs average. Indeed found US software postings rose about 15% after Claude Code launched while all postings fell 7%, with senior roles driving 71% of the rise, correlation only (Indeed). Stanford’s Canaries study: “Experienced workers show no comparable gap” (Stanford Digital Economy Lab). Demand is shifting toward judgment. The real problem is the entry ramp, which gets its own section below.

Weighed by diagnosticity, the high-signal evidence (organizational output metrics, experienced-worker employment, the vendors’ own hiring) points to transformation with repricing, not extinction. The live risk is the third hypothesis: bifurcation, where seniors thrive, juniors are locked out, and the profession shrinks by attrition over a decade.

What would change my mind. As of October 2026, none of these is true:

1. A regulator or court accepts “the model did it” as the accountable party. MAS reaffirmed the opposite on 7 October 2026.
2. Agents reach roughly 99% reliability on long, messy, holistically judged work, measured on private benchmarks, not public ones.
3. The AI labs themselves shrink engineering headcount while code share stays above 90%.
4. Organization-level delivery (lead time, change-failure rate, incidents) improves in proportion to code output. Harvard and Faros currently show the opposite.
5. Experienced-developer employment, not just 22–25-year-olds, falls in payroll data while software output rises.

The uncomfortable part: juniors and the apprenticeship

Most “AI won’t replace engineers” posts stop before this section. That is why they aren’t believed.

The early-career data is bad and getting worse. Stanford’s Canaries in the Coal Mine, using ADP payroll data, found the relative employment decline for 22–25-year-olds in the most AI-exposed occupations went from 13% (August 2025) to 16% (November 2025) to a 19% gap, still widening in August 2026, driven mainly by less hiring of young workers, not by firing (Stanford Digital Economy Lab; original paper). Software developers aged 22–25 were down nearly 20% from their late-2022 peak. The authors’ own caveats matter: the gap shrinks once education is accounted for, some of the divergence predates generative AI, and the 2022 Section 174 tax change may be a factor. It is a working paper, not peer-reviewed. It is also the best data we have.

Skills erode, including the ones needed to supervise AI. Anthropic’s own randomized trial of 52 mostly junior developers found that those learning with AI scored 50% on a comprehension quiz versus 67% without, and the biggest gap was in debugging, the very skill needed to catch an agent’s mistakes (Anthropic, January 2026). Anthropic calls this the “paradox of supervision”: supervising Claude requires the skills that may atrophy (Anthropic). Lisanne Bainbridge saw it in 1983: automation leaves the human “the tasks which the designer cannot think how to automate,” and operators who only monitor lose the skill to intervene (Ironies of Automation). I named the finance version of this in my ESG lens post: key-person risk, inverted. Classic key-person risk is one senior who knows everything leaving. The new version is that the agent does the junior’s work, so the junior never learns the check, and in five years nobody on the floor can tell when the agent is wrong.

Now the pipeline argument. Today’s architects were yesterday’s juniors debugging production at 3 a.m. Stop hiring juniors and you have no architects in 2036. The shadow spec I described above is transmitted almost entirely through apprenticeship: the senior who says “we don’t do it that way here, and here’s the incident that taught us.” AWS CEO Matt Garman called replacing juniors with AI “one of the dumbest things I’ve ever heard,” asking “how’s that going to work when you go like 10 years in the future and you have no one that has built up or learned anything?” (Business Insider). IBM is tripling US entry-level hiring. Shopify takes about 1,000 interns a year. Brooks, in 1986, said the most important single effort we can mount is “to develop ways to grow great designers” (Brooks).

Redesign the apprenticeship rather than abolish it. Juniors in an AI-era team should write the specs, tests and decision records; debug without AI before debugging with it; review AI pull requests alongside seniors; shadow on-call; and run game days. The scarce skill is no longer producing code. It is reading it with suspicion, and that is learned by doing.

What to do on Monday

For engineers:

1. Move up the stack. Own requirements, non-functional requirements and verification, not tickets.
2. Learn the failure modes. Retries, idempotency, backpressure, consistency, cost traps. You can’t prompt for what you don’t know exists.
3. Become the best reviewer on your team. Reading code is now the scarce skill; 66% of your peers say AI output is “almost right, but not quite.”
4. Write things down. Decision records, CLAUDE.md, runbooks. The theory of the system is now an input to your tools.
5. Keep your debugging muscle. Regularly debug without AI. The 50% versus 67% gap is real.
6. Measure yourself. METR’s developers felt 20% faster and were 19% slower.

For CTOs and boards:

1. Measure outcomes, not lines of AI code. Lead time, change-failure rate, incidents, cost per unit. If your engineering output is measured in merged PRs, ask what would have to be true for that number to still mean anything in 2027.
2. Fund verification capacity. Review, testing, observability. That is the new bottleneck, and Spotify has shown you what it costs to discover it late.
3. Govern agents like privileged employees. Least privilege and no production credentials; separate development and production; deterministic hooks and sandboxing; audit logs; backups the agent cannot delete.
4. Write your shadow spec down once. An organization-wide CLAUDE.md or skill with cost, resilience, observability and security defaults. Template below.
5. Keep hiring juniors, and redesign the apprenticeship.
6. If you’re regulated, map AI-assisted development now. In Europe, to DORA Art. 5. In Singapore, to the MAS Guidelines on AI Risk Management, effective 7 October 2027, with the agentic-AI consultation to follow in 2027.

Here is a production-defaults CLAUDE.md you can adapt. It is original text; replace the placeholders.

# CLAUDE.md — production defaults (adapt per service)

## Context you cannot infer (fill in)
- Business goal / explicit non-goals: <...>
- Users & geography; latency budget (p99): <...>
- Data classification; residency: data must stay in <region(s)>
- Cost ceiling: <$X/month>; unit-cost target: <$Y per trade/user/request>
- SLO: <99.9%>; RTO: <4h>; RPO: <15m>; regulatory regime: <MAS TRM / EU DORA / none>
- Known exceptions to the written rules (the shadow spec): <...>

## Non-negotiables
- Deploy only to <region>; never create resources elsewhere. Show a cost estimate before provisioning.
- Every network call: explicit timeout; retries with exponential backoff + full jitter and a retry
  budget; retry at ONE layer only; idempotency keys on every write.
- Every external dependency: circuit breaker + defined degraded behavior.
- Observability: structured JSON logs with trace/correlation IDs; RED metrics; OpenTelemetry traces;
  health/readiness endpoints; alerts tied to SLOs; audit log for <regulated actions>.
- Security: least-privilege IAM; secrets only from <vault>; validate all input; never add a
  dependency without confirming it exists, is maintained and licensed <...>; run /security-review
  before any PR.
- Data safety: never run destructive commands (DROP, TRUNCATE, rm -rf, terraform destroy);
  propose them for human approval. Migrations must be reversible. Never touch production credentials.
- Tests: never modify, skip or delete existing tests to make them pass; add property/contract
  tests for <critical logic>.
- Delivery: infrastructure as code only; ship behind a feature flag; staged rollout; documented rollback.

## Workflow
Explore → plan (show me the plan and your assumptions) → implement → verify → commit.
When a requirement above is missing or ambiguous, ask. Do not assume.

One more piece of engineering hides in that file. CLAUDE.md is advisory context; Anthropic’s docs are explicit that hooks are deterministic and CLAUDE.md is not (Claude Code memory docs). Hard rules belong in hooks, permission settings and CI gates. Deciding which rule goes where is job 21 on the list above.

What I think comes next

Dated and falsifiable, so you can hold me to them:

1. By 31 December 2027, no major financial regulator (MAS, the EU authorities under DORA, the SEC) will have accepted an AI system as the accountable party for a production failure. MAS’s 2027 consultation on agentic AI will reaffirm, not dilute, the principle that the FI remains accountable.
2. The BLS’s next projection round (August 2027) will still show software developers growing faster than the all-occupations average and computer programmers declining. The short-order coder keeps shrinking; the versatile engineer keeps growing.
3. By the end of 2027, Anthropic, Google and Microsoft will each employ more software engineers than they do today, with AI-written code share at or above today’s levels. If any of the three cuts engineering headcount while holding code share above 90%, I will publish a correction.
4. The Canaries gap for 22–25-year-olds will pass 20% before it narrows, and by 2028 the firms that kept hiring juniors through 2025–27 will be visibly out-hiring the ones that didn’t for senior roles, because they will be the only ones with a bench.

The Davos six-to-twelve-month window runs from July 2026 to January 2027. We are inside it now. My call is that it closes without a single regulated bank running an engineering function with no human sign-off on production changes.

FAQ

Is software engineering dead?

No. The task that collapsed in price is converting a finished specification into code. In the studies that measured it, coding was 5–16% of a developer’s week, so making it instant speeds the whole job up by 1.05–1.20× (Amdahl’s law). What remains, deciding, specifying, verifying, operating and being accountable, is the discipline itself, and demand for it is rising: the BLS projects software developers +10% for 2025–35 while programmers fall 7%.

Will AI replace software engineers?

It is replacing the routine, ticket-to-code layer and squeezing the entry ramp: 22–25-year-olds in AI-exposed jobs show a 19% relative employment gap. It is not replacing engineers who own decisions, verification and accountability. Anthropic has hired more of them with AI writing 90% of its code, and Google expects to grow its engineering base with AI writing 75% of its new code.

What can’t Claude Code do?

It can do almost everything a developer does: read, plan, code, test, review, deploy, remember. What it cannot own is anything that requires knowledge it wasn’t given, authority over other people’s trade-offs, verification independent of itself, or legal accountability. Use the Delegation Test: if you can’t write it down, can’t check it, can’t undo it, or have to answer for it, it’s engineering, not typing.

What is the Specification Conservation Law?

Ambiguity removed from a prompt has to be supplied by someone who understands the system. A prompt complete enough to produce a production-grade system is itself an act of software engineering. Example: “add retries” is a prompt; “retry 408/429/5xx with exponential backoff and full jitter, at this layer only, with idempotency keys on every write” is a design decision that only someone who has survived a retry storm knows to make.

Is it still worth learning to code?

Yes, with a change of emphasis. Learn to read code with suspicion, to debug without assistance, to write specifications and tests, and to understand the failure modes of distributed systems and cloud cost. Those are the skills that supervise AI, and the data says they atrophy if you let the agent do all the typing from day one.

---

In 1954 IBM promised to eliminate coding. It succeeded, slowly, and the number of people building software has grown ever since. AI is the most powerful version yet of the same promise. It removes the typing. It leaves us the thinking, and the responsibility.

The microwave didn’t end cooking. It ended the excuse that cooking takes too long. Claude Code won’t end engineering. It ends the excuse that building takes too long, which means the only thing left to differentiate on is whether you built the right thing, the right way, and whether someone with a name will stand behind it.

If your board is asking whether AI means fewer engineers, bring me the decision, not the headcount. I run architecture reviews, build-versus-buy decisions and regulatory-posture reviews for trading, risk and market-data platforms, and I take on fractional chief-architect engagements. A 30-minute architecture review is free; you leave with a one-page diagnostic and at least two concrete options, whether or not we work together.

How are you handling the review bottleneck on your team? I’m curious.

---

Research for this post was compiled with AI assistance and every figure was checked against the primary source linked beside it; vendor-funded studies (Faros, GitClear, Veracode, Sonar, CodeRabbit, New Relic, Splunk, Flexera) are labeled as such. The prompt pairs are illustrative; the controlled experiment is designed, not yet run. Views are my own. Disclaimer: this reflects my personal views and experience, not financial, legal or investment advice.

Jiri Pik is the founder of RocketEdge, a Singapore-based consultancy building AI trading systems and resilient cloud architecture for demanding financial firms. He is a Wiley author (Hands-On AI Trading with Python, QuantConnect, and AWS), holds the CFA, CAIA, FRM and PMP charters, and co-chairs the Tech Transformation Resource Group at the Singapore International Chamber of Commerce. Follow him on LinkedIn and X.