Back in the days I wanted to work at Google and I remember finally interviewing for a position many years ago. What was surprising is that they sent me a bunch of books to read and some of them were very interesting. I have not accepted the position, but i kept reading, following and investing in the company.

Coincidentally the best definition of software engineering I know came also from a a Google book called Software Engineering at Google:

"Software engineering can be thought of as programming integrated over time"1. 

The authors meant it almost literally. Programming is the act of writing a program. Software engineering is what happens to that program over its whole life: from conception to introduction to maintenance to deprecation. As they put it, "Cubes aren't squares, distance isn't velocity. Software engineering isn't programming"2.

I keep coming back to that, because AI has just made the square almost free. Code that took a day now takes minutes. The question I hear from engineers, founders and clients every week is some version of: if the machine writes the code, what's left for us? 

Google's definition already has the answer. Most of the job was never the code.

Three things that were never about typing

The book builds everything on three key principles that put software development efforts into a long-term thinking context1:

  • Time and change: how code needs to adapt over the length of its life.
  • Scale and growth: how an organisation needs to adapt as it grows.
  • Trade-offs and costs: how an organisation makes decisions, based on the first two.

Then it splits the practice of software engineering into three parts: Culture, Processes and Tools1. Culture is about working in teams, sharing knowledge and leading. Processes cover style guides, code review, documentation, testing and deprecation. Tools cover version control, build systems, continuous integration and the rest of the machinery. 

Code itself barely appears in the text. The book even says it contains little actual "programming" advice, because it's about engineering1. 

It's kind of funny that we forgot what engineering is as soon as AI coding tools appeared. 

The framing by Google makes us step back and look at what we do as engineers in the context of a real organization that evolves over time. It seems that long-term thinking is healing (again).

So yes, we are coding much less, but that was never the full job. The bottleneck moved to a different place.

So how does the job of an engineer change when we take the principles into consideration? Where is the responsibility set moving?

PrincipleWhat AI makes cheapWhat gets harderThe engineer's job now
Time and changeWriting code that works todayKeeping code that "happens to work" maintainable for yearsDecide how long code must live, and hold it to that standard
Scale and growthProducing changes, including huge migrationsReviewing, integrating and trusting the volumeBuild the tests, docs and guardrails agents work within
Trade-offs and costsTrying several options before choosingKnowing which option is right, and owning the resultMake the call, explain it and stay accountable for it

The counter-argument by AI aficionados could be that teams are shrinking and that we live in the age of a "Single person billion dollar company", but reality is far from that. Any sufficiently ambitious product will live and evolve inside an organization where multiple humans work together.

As long as there is a team, the problems of developing software become people and organisational problems.

The only exception might be personal software and very simple products.

Programming got cheap

The numbers keep moving. Google said about a quarter of its new code was AI-generated in October 2024, and about half a year later. In April 2026 Sundar Pichai put it at 75%, all of it reviewed and approved by engineers3. Boris Cherny, who leads Claude Code at Anthropic, said in June that he hadn't written a line of code by hand in about eight months, and that most Claude Code sessions are now prompted by another Claude4.

Andrej Karpathy, who coined "vibe coding", described the switch in January: he went from about 80% manual coding in November to about 80% agent coding a few weeks later5. A month before that, he wrote that he had "never felt this much behind as a programmer", and that the profession was "being dramatically refactored"6.

Kent Beck saw it coming in 2023. He wrote that the value of 90% of his skills had dropped to $0, while the leverage of the other 10% went up 1,000 times7. He also admitted he didn't know yet which skills were which. Three years later, I think Google's definition tells us.

Writing code was never most of the work. Bain estimates coding is only 25 to 35% of the time it takes to get an idea to a customer8. So even if AI made coding infinitely fast, the rest of the job would still be there: understanding the problem, agreeing what to build, reviewing, testing, releasing, operating and changing it later. That's the integral. AI shrank one term inside it.

Time: "it works" is now the cheap part

The most useful question in the book is: "What is the expected life span of your code?"2 Reasonable answers vary by a factor of 100,000, from a script that runs once to a system like Google Search that will live indefinitely. Short-lived code is just a programming problem. Long-lived code is an engineering problem, because over a decade almost everything it depends on will change.

AI is brilliant at the short end. A prototype, a one-off data cleanup, an internal tool for a single meeting: these used to need an engineer's afternoon and now need a prompt. In The AI Paradox, one year later I called this disposable software: simple tools built by their own users, often for one job and then thrown away. That part came true. The long tail of personal software is real, it just lives mostly in chat rather than in app stores. In Google's terms, that's software with an expected life span of minutes or days, which makes it a pure programming problem. And that's the point for our profession: when anyone can write the short-lived program, what's left for engineers is everything at the long end of the spectrum. I don't think we should feel guilty about throwaway code that was always meant to be thrown away. We should just be clear about which code is which.

Karpathy drew the same line a year after naming vibe coding. Back then, he wrote, it was mostly for "fun throwaway projects, demos and explorations". Now professionals use agents by default, "except with more oversight and scrutiny", and his favourite name for that is "agentic engineering"9. Simon Willison, who had suggested "vibe engineering", now says "agentic engineering" is coming out on top10. Without meaning to, they rebuilt Google's distinction. Vibe coding is programming. Agentic engineering is programming integrated over time.

The danger is that AI writes long-lived code in the same style as throwaway code. The book draws the line between code that "happens to work" and code that "is maintainable". It has a lovely way of saying it: "It's programming if 'clever' is a compliment, but it's software engineering if 'clever' is an accusation"2. Models are very good at code that works today. They're much less concerned with whether it will survive the next five upgrades.

There's evidence of what that does to a codebase. GitClear analysed 211 million changed lines and found that in 2024, for the first time, copy-pasted lines outnumbered moved lines, a rough sign of refactoring and reuse11. Moved code fell from about 25% of changes in 2021 to under 10%. Code is getting added faster than it's getting cared for.

And then there's Hyrum's Law, the book's most famous idea: with enough users of an API, "all observable behaviors of your system will be depended on by somebody"12. AI agents are about to become the biggest users of most APIs. They read whatever is observable and depend on it, documented or not. Every accidental behaviour becomes someone's contract a lot sooner.

So the first new job is an old one: decide how long each piece of code is meant to live, and hold it to the right standard. A prototype can be vibe coded. A payment system can't.

Scale: agents are the new contributors

The book's test for a policy that doesn't scale is simple. Imagine the organisation 10 or 100 times bigger, and ask whether the work for each engineer grows with it2. If it does, you have a scaling problem.

AI agents are that 10 times bigger organisation, arriving all at once, and the 2026 data shows what happens when the processes don't change. Faros AI tracked 22,000 developers and found that teams with high AI adoption completed 66% more epics, but had more than three times as many incidents per pull request, and a median review time five times longer. Their summary: "Volume is up, quality is down"13. LinearB's benchmarks, across 8.1 million pull requests, show AI-generated pull requests waiting 4.6 times longer before anyone reviews them, and being accepted 32.7% of the time, against 84.4% for code written by hand14.

The bottleneck moved from writing code to reading it. That's the curation problem from the same essay, showing up inside engineering teams. Cherny describes Anthropic's approach as "Find the bottleneck, solve the bottleneck": first code review, then maintainability and security, each handled by more automation with a human still approving4.

The answer isn't more people reading more code. Human review doesn't scale to agent volume, any more than it would to an organisation 100 times bigger. The answer is moving verification into the system, and it's the same one Google wrote down years ago. The practices that let tens of thousands of engineers work in one codebase are exactly the practices that let agents work in one: tests, documentation, continuous integration, automated checks and small, reversible changes. Google calls it the Beyoncé Rule: "If you liked it, then you shoulda put a test on it"15. For an agent, the test suite is the only contract it reliably reads.

Simon Willison makes the same point about coding agents: testing, planning, documentation, version control, CI and code review all get more valuable, not less, because "AI tools amplify existing expertise"10. Google's DORA team found the same at company level. Its latest report calls AI an "amplifier": it makes strong teams faster and struggling teams more unstable16.

When the foundations are there, the gains are real. Google has used AI for large internal code migrations, the kind of work the book describes as a chore nobody wants. In landed changes, 80% of the code modifications were fully AI-authored, and engineers estimated the total migration time fell by about half, including review17. One engineer could generate all the changes, which cut a lot of communication overhead. That's the book's argument that "expertise scales better"2, now with a machine doing the repetition.

So the second new job is building the environment agents work in. It's platform work, and it's increasingly the most valuable work on a team.

Trade-offs: judgment is the job

The third principle is the one AI touches least, and the one that matters most. The book says the job of a software engineer is to aim for sustainability and manage scaling costs, then "evaluate your trade-offs and make rational decisions"2.

AI makes options cheap. You can ask for three implementations before lunch. But cheap options don't make choosing easier. They make it harder, because now there are more of them and each one looks plausible.

Developers know this. Stack Overflow's 2026 survey of more than 30,000 developers found that 66% now work in coding agents, with Claude Code the most used. But they use AI mostly for generating code in familiar areas (67%) and debugging (61%). Only 20% use it for deploying, operating or troubleshooting production systems, the long end of the life span. And 93% say they need source attribution before they trust what AI gives them18. A year earlier, the top frustration was AI answers that are "almost right, but not quite"19.

Security is the same story. Veracode tested more than 100 models and found security flaws in about 45% of the generated code across its test tasks, with no improvement as models got better at writing code that runs20. And our own sense of speed is unreliable. In METR's 2025 study, experienced developers took 19% longer with AI tools while believing they'd been 20% faster21. METR's 2026 follow-up points to a speedup now, but METR itself calls the evidence weak, partly because many developers refused to take part if it meant working without AI22. Nobody wants to go back. That's not the same as knowing how much faster we are.

None of that means AI is bad at code. It means someone still has to decide what's good enough, what's safe, what's worth the maintenance cost and what to throw away. And someone has to answer for that decision, which is where the third job starts.

Ownership: the part you can't delegate

The book already has a word for this part of the job. At Google, every change needs approval from an owner of that part of the codebase, listed in OWNERS files. The book is careful to say that ownership isn't possession of code, but "a sense of stewardship" for a part of the codebase, and admits that "stewards" would have been a better word23.

An agent can write a change. It can even own a piece of work: a task, an area, an incident. What it can't own is the outcome. Agents already handle some on-call work, fixing a broken build at 2am without waking anyone, so being on call was never really the point. The point is that an agent can't decide whether a change should exist at all. It can't explain a decision to a customer, an auditor or a regulator. It won't be around to carry the consequences of a trade-off five years later. A line often traced to an IBM training manual from 1979 is being quoted again for exactly this reason: "A computer can never be held accountable, therefore a computer must never make a management decision"24.

That's why Google's 75% comes with "reviewed and approved by engineers"3, and why Anthropic's Code Review, after a team of agents has checked a change, still won't approve it: "that's still a human call"25. Approval is the moment responsibility moves from the machine to a person. When that click becomes a rubber stamp, the code still ships, but nobody really owns it.

A Hacker News thread from June, "Where is the programming profession going?", described exactly that: a 15-person company where code review wasn't done by humans and "the code is not the source of truth anymore"26. The problem there isn't that people stopped reading every line. It's that nothing took their place: no system that checks the work, and no person who answers for it. That's what the Faros incident numbers look like from the inside.

So the third new job is the one that can't be automated: put your name on it. Owning code now means understanding it well enough to defend it, whether you typed it or not. Anthropic's engineers already describe their future as "taking accountability for the work of 1, 5, or 100 Claudes"27. That's not a coding job. It's an engineering one, in exactly the book's sense.

What the frontier looks like

Put the three jobs together and you get a picture of where this is heading. The clearest examples come from the teams furthest ahead.

At Anthropic, the researcher Nicholas Carlini built a C compiler with 16 Claude agents working in parallel on one codebase. Over about two weeks and 2,000 sessions, for roughly $20,000 of compute, they wrote a 100,000-line compiler in Rust that can build the Linux kernel. The human wrote almost none of it. He wrote the loop that restarts an agent when it finishes a task, the test harness, the continuous integration that catches regressions, the progress notes each new agent reads first, and a simple way for agents to claim tasks without colliding. His main lesson: the tests have to be "nearly perfect, otherwise Claude will solve the wrong problem"28. He also warns how easy it is to see tests pass and assume the job is done. That's the whole job now: define what correct means, build the system that checks it, and still check the result. None of it is writing the feature code.

The same pattern runs through Anthropic's own tooling. Code Review sends a team of agents to check every pull request. Inside Anthropic, the share of pull requests getting substantive review comments went from 16% to 54%, and engineers marked fewer than 1% of findings as wrong25. Agents also work longer on their own: the longest Claude Code turns nearly doubled in three months, from under 25 minutes to over 45. On the hardest tasks, Claude now stops to ask for clarification more than twice as often as people interrupt it29.

The most extreme example I've read is Spawn, a ten-person company building a multiplayer game engine. Its founder wrote this week that a fleet of permanent agents, each owning a part of the company from the engine to finance to bug triage, shipped 77,000 substantial changes in 30 days30. The token bill was $3.1 million a month, for ten people. That's the payroll-to-compute shift from my revenue per employee essay in its purest form. They even dropped pull requests and human code review. But they didn't drop verification. The full test suite runs every 15 minutes, helper agents that didn't write a change try to break it, any broken change can be rolled back in 30 seconds, and agents watch every error in production. Over the past year, about 0.9% of changes were reverted. They also turned two years of recorded decisions into AI judges: in eight days the judges returned more than 11,000 verdicts, and the founder had to answer personally only 27 times.

It's self-reported, it's a game engine rather than a bank, and most teams shouldn't copy it. It's also the opposite of the company from the Hacker News thread. Both stopped humans reading every line, but only one replaced that with a system. And look at what the humans there still do. They make the calls on taste, say no to things that work but aren't right, delete what new models make pointless, and push for ideas 100 times bigger than the agents would suggest. Their engineers have stopped owning one system and work more like paratroopers, dropping in wherever the agents are stuck. And anything that touches the outside world and can't be undone, like sending a payment, still goes through what they call "dumb, hard-coded gates"30.

Spawn didn't escape Google's three principles. It automated them. Time and change became hourly releases and instant rollbacks. Scale became agents coordinating through the code itself instead of through meetings, which is the old Mythical Man-Month communication problem2 solved a new way. Trade-offs became judges trained on past decisions, with people for the new ones. The engineering is all still there. It just isn't typing anymore.

Most teams don't work like that, and in regulated industries they shouldn't. Closer to home, we see the same shift at Ministry of Programming, in a more careful shape. On the insurtech and fintech products we build with our clients, our best engineers now spend most of their time well beyond writing features. They build the tooling and processes the agents work within: test harnesses, evals, CI checks and review rules. They design the loops agents run in, from a ticket to a tested pull request, and the graphs that chain agents and checks together.

In insurance and payments, a wrong answer isn't a bug report, it's a compliance problem, so that system is where the judgment lives: which checks must pass, which changes need a person, and which actions an agent is never allowed to take on its own. The code the agents write matters less than the system that decides what ships.

Beyond coding

Go back to the book's three parts. AI arrived as a tool, and tools are where it has changed the most. Processes are being rebuilt around it right now. Culture, how people learn, share knowledge and lead, has barely started to change. The job is moving in the same order.

The most useful reply in that Hacker News thread came from an engineer who said writing code "has always been the easy part". Understanding the problem and the existing system well enough to design the right solution is harder, and they're doing more of it: "more productive, but also more tired"26.

Here's where I see the role moving, in our teams and in the people I hire.

  • From writing to specifying. The clearest engineers now write the best prompts, plans and acceptance tests. A good spec used to help a team. Now it directly controls what gets built.
  • From reviewing code to designing verification. Reading code critically still matters, but no one can read everything agents write. The leverage is in tests, evals and checks good enough that agents can't fool them: Carlini's "nearly perfect" verifier.
  • From features to systems. Tests, docs, CI, observability and safe rollouts are what make agents useful. Whoever builds that environment multiplies everyone else.
  • From authorship to ownership. It matters less who typed the code and more who stands behind it in production.
  • From specialist to full stack. Anthropic found that "everyone is becoming more 'full-stack'", taking on work outside their core expertise27. When code is cheap, the boundaries between front end, back end, data and design get thinner.
  • From code to product. The hardest part of software is still deciding what deserves to exist. I wrote about this in hard vs easy product: copying a feature is easy now. Knowing which problem is worth solving isn't.
  • From output to outcomes. Lines of code and pull requests were never great measures. Now they're meaningless. I wrote more about measuring productivity in the AI era.

There's one uncomfortable catch. Anthropic calls it the "paradox of supervision": using AI well takes the skills to supervise it, and those are the same skills that fade when you stop writing code yourself27. Juniors used to learn the craft by doing the easy work. If agents do the easy work, we need new ways for people to build judgment. The labour data already shows the pressure. Stanford's Digital Economy Lab finds employment of 22- to 25-year-olds in AI-exposed occupations, software development among them, now 19% below where it would have been had it kept pace with less-exposed peers, while experienced workers show no comparable gap31. That's the culture part of the book, and I don't think anyone has solved it yet. It's probably the most important open question for our industry.

Still programming integrated over time

I wrote in 2023 that ChatGPT was not replacing software engineers anytime soon. I still believe it, but for a more precise reason now. AI is replacing programming, the cheap and visible part. It isn't replacing the integral: the years of change, the growing team, the decisions with imperfect information and real consequences.

The three jobs that are left are the integral. Decide how long code should live. Build the system that checks it. Put your name on what ships.

If anything, Google's definition is more true now than when it was written. When the square is free, all the value is in the cube.

Google publishes the book free online under a Creative Commons licence (CC BY-NC-ND 4.0). I put the free HTML edition together into one unmodified PDF for offline reading. It's not affiliated with Google or O'Reilly, and the print edition is available from O'Reilly.

Software Engineering at Google (free edition)

Titus Winters, Tom Manshreck and Hyrum Wright · CC BY-NC-ND 4.0 · 537 pages

PDFSoftware Engineering at GooglePDF · 12 MB

References 31

  1. Titus Winters, Tom Manshreck and Hyrum Wright, Software Engineering at Google, Preface, "Programming Over Time" (O'Reilly, 2020), https://abseil.io/resources/swe-book/html/pr01.html#programming_over_time ↩
  2. Titus Winters, Tom Manshreck and Hyrum Wright, Software Engineering at Google, Chapter 1, "What Is Software Engineering?" (O'Reilly, 2020), https://abseil.io/resources/swe-book/html/ch01.html ↩
  3. Semafor, "Google CEO says 75% of company's new code is AI-generated" (24 Apr 2026), https://www.semafor.com/article/04/24/2026/google-ceo-says-75-of-companys-new-code-is-ai-generated ↩
  4. Fortune, "The head of Claude Code hasn't 'written a line of code by hand' in 8 months" (11 Jun 2026), https://fortune.com/2026/06/11/anthropic-claude-boris-cherny-doesnt-write-code-by-hand-anymore/ ↩
  5. Andrej Karpathy on X (26 Jan 2026), https://x.com/karpathy/status/2015883857489522876 ↩
Show all 31 sourcesShow fewer
  1. Andrej Karpathy on X (26 Dec 2025), https://x.com/karpathy/status/2004607146781278521 ↩
  2. Kent Beck, "90% of My Skills Are Now Worth $0" (Apr 2023), https://newsletter.kentbeck.com/p/90-of-my-skills-are-now-worth-0 ↩
  3. Bain & Company, "From Pilots to Payoff: Generative AI in Software Development", Technology Report 2025, https://www.bain.com/insights/from-pilots-to-payoff-generative-ai-in-software-development-technology-report-2025/ ↩
  4. Andrej Karpathy on X (4 Feb 2026), https://x.com/karpathy/status/2019137879310836075 ↩
  5. Simon Willison, "Vibe engineering" (7 Oct 2025, updated Feb 2026), https://simonwillison.net/2025/Oct/7/vibe-engineering/ ↩
  6. DevClass, "AI is eroding code quality, states new in-depth report", on GitClear's AI Copilot Code Quality 2025 research (20 Feb 2025), https://devclass.com/2025/02/20/ai-is-eroding-code-quality-states-new-in-depth-report/ ↩
  7. Hyrum Wright, "Hyrum's Law", https://www.hyrumslaw.com/ ↩
  8. Faros AI, "AI Engineering Report: The Acceleration Whiplash" (2026), https://faros.ai/research/ai-acceleration-whiplash ↩
  9. LinearB, "2026 Software Engineering Benchmarks Report" (2026), https://linearb.io/blog/engineering-benchmarks-report ↩
  10. Titus Winters, Tom Manshreck and Hyrum Wright, Software Engineering at Google, Chapter 11, "Testing Overview" (O'Reilly, 2020), https://abseil.io/resources/swe-book/html/ch11.html ↩
  11. Google Cloud, "Announcing the 2025 DORA report: State of AI-assisted Software Development" (Sep 2025), https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report ↩
  12. Stoyan Nikolov et al., "How is Google using AI for internal code migrations?" (Jan 2025), https://arxiv.org/abs/2501.06972 ↩
  13. Stack Overflow, "The results of the 2026 Developer Survey are here" (6 Oct 2026), https://stackoverflow.blog/2026/10/06/the-results-of-the-2026-developer-survey-are-here/ ↩
  14. Stack Overflow, "2025 Developer Survey: AI" (Jul 2025), https://survey.stackoverflow.co/2025/ai ↩
  15. Veracode, "AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks" (30 Jul 2025), https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/ ↩
  16. METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (10 Jul 2025), https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ ↩
  17. METR, "We are Changing our Developer Productivity Experiment Design" (24 Feb 2026), https://metr.org/blog/2026-02-24-uplift-update/ ↩
  18. Titus Winters, Tom Manshreck and Hyrum Wright, Software Engineering at Google, Chapter 9, "Code Review" (O'Reilly, 2020), https://abseil.io/resources/swe-book/html/ch09.html ↩
  19. Simon Willison, "A computer can never be held accountable" (3 Feb 2025), https://simonwillison.net/2025/Feb/3/a-computer-can-never-be-held-accountable/ ↩
  20. Anthropic, "Code Review for Claude Code" (9 Mar 2026), https://claude.com/blog/code-review ↩
  21. Hacker News, "Ask HN: Where is the programming profession going?" (25 Jun 2026), https://news.ycombinator.com/item?id=48668199 ↩
  22. Anthropic, "How AI is transforming work at Anthropic" (2 Dec 2025), https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic ↩
  23. Nicholas Carlini, Anthropic, "Building a C compiler with a team of parallel Claudes" (5 Feb 2026), https://www.anthropic.com/engineering/building-c-compiler ↩
  24. Anthropic, "Measuring AI agent autonomy in practice" (18 Feb 2026), https://www.anthropic.com/research/measuring-agent-autonomy ↩
  25. Jacob (@jsnnsa), founder of Spawn, "How I Built the Most AI-Pilled Company in the World", on X (29 Oct 2026), https://x.com/jsnnsa/status/2115623382721126826 ↩
  26. Erik Brynjolfsson, Bharat Chandar and Ruyu Chen, "Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence", Stanford Digital Economy Lab, https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/ ↩