I just published a book called Software Engineering in the AI Era: From AI-Assisted Coding to Autonomous Software Engineering. Six parts, twenty-eight chapters, written over the stretch of 2026 while I was leading a 17-dev team through an AI First rollout and shipping six AI products in production. This article is not the book’s summary. It is the argument underneath it, the one I kept coming back to every time an engineer on my team asked me what their job becomes in two years.
The short version: software engineering is changing, and AI-assisted coding is the least interesting part of the change. What is actually happening is a shift in what the discipline is for. Writing code was always a means. The end was always software that runs reliably in the real world. AI is moving the engineer further from the means and closer to the end, and that shift is bigger than the tooling discourse makes it look.
The thing everyone agrees on, and the thing almost nobody does
Everyone in engineering has now agreed that AI generates code. That consensus took about eighteen months and is already uninteresting. Autocomplete in the IDE, PR drafts from an agent, test scaffolding, boilerplate migrations, one-off scripts: these are table stakes. A developer who is not using them in late 2026 is doing something strange, and the organisation around them has either made a deliberate choice or is drifting.
What almost nobody has done is reorganise the engineering function around the fact that code generation is cheap. The teams I observe, including my own on some days, are still using an engineering operating model designed for a world in which typing is the bottleneck. In that world, you hire for throughput. You review for syntax and local correctness. You run sprints that treat tickets as roughly equal units of work. You measure velocity. You keep architecture in the head of a senior engineer or two.
That operating model does not survive contact with AI generation at scale. When typing is no longer the bottleneck, the bottleneck moves. It moves to specification, evaluation, integration, and accountability. A team can now generate a feature in a day that used to take a week, and then spend three weeks discovering that the feature does the wrong thing in a subtle way, or that nobody on the team can explain how it works at 3am when it breaks. The savings on the coding side have been quietly spent on the other sides.
From writing code to orchestrating intelligence
The thesis that runs through the book, and the thesis I want to make explicit here, is that the engineer’s centre of gravity has moved. Five responsibilities now matter more than the ability to write a correct function from scratch.
Defining the problem. Translating a business need into a technical specification that an AI system can actually act on, including the invariants, the failure modes that are unacceptable, and the behaviour that falls outside scope. An AI that generates against a vague prompt generates the wrong thing faster than a human would have.
Designing the system. Deciding where AI sits in the architecture, what it is allowed to write to, what contract it must respect, what evaluation gates it must pass, and how the humans in the loop are structured around it. The hardest problem in an AI-native product is almost never the model. It is the architecture that keeps the model honest.
Directing the agents. Running an engineering workflow where some of the labour is done by agents, some by humans, and the handoff between them is explicit. The teams that do this well treat agents the way they treat junior engineers: with clear tasks, scoped autonomy, and a review loop that catches regressions before they land.
Evaluating what comes back. Reading generated code and architectural proposals as a senior reviewer rather than a typist. This is a different skill from writing code, and it is the one that most quickly separates the engineers who are moving up from the engineers who are staying flat. I wrote about this at length in What I tell my developers when they ask if AI will replace them.
Governing the outcome. Owning the system in production. Being the person whose name is on the thing when it fails. Keeping an audit trail, a rollback plan, a human in the loop for safety-critical decisions. AI can generate. AI can test. AI cannot take responsibility. The engineer still can and still must.
Why agents change the shape of the work more than assistants do
Most of the public conversation about AI in software engineering is still stuck on the assistant frame. An engineer writes code, an assistant suggests completions, the engineer accepts or edits them. In that frame, the engineer is still the author and the assistant is a better keyboard.
The agent frame is different. An agent reads the repository, plans a change, writes the code, runs the tests, opens the pull request, responds to review comments, and iterates until the change lands. The engineer in that loop is not writing. The engineer is specifying, bounding, reviewing, and deciding when to stop.
I have shipped work this year through both frames. The assistant frame makes a good engineer slightly faster. The agent frame changes what you can attempt. A single engineer can carry three or four parallel workstreams in the agent frame, as long as the engineer has built the evaluation infrastructure that makes it safe to do so. Without that infrastructure, the same engineer ships three or four unreviewed patches a day and discovers two months later that the production system contains a growing region nobody understands. I called that region dark matter in Test coverage was enough, ownership coverage is what matters now, and it is the single largest hidden cost of agentic development done without discipline.
What the book spends time on, and why
The book is organised into six parts. I want to say a few words about why each one is in the book, because that tells you more than a table of contents.
Part I, Understanding the AI revolution in software engineering. This part exists because most of the teams I audit have never been given a honest primer on how large language models actually work, what they can and cannot do, and why the distinction matters when you are deciding whether to put one in your product. You cannot govern what you do not understand at a mechanical level.
Part II, The AI-augmented software engineer. This is the part that overlaps most with the usual AI coding content, and it is the part I most wanted to write differently. Prompt engineering is a skill. It is not the skill. The skill is knowing when to prompt, when to design, when to not use AI at all, and how to keep your own thinking intact while you ship faster, which I unpacked in Stop delegating your thinking to AI.
Part III, Agentic software engineering. This is the part that will age the slowest, because the architecture questions it raises will outlast the specific tools. How do you give an agent the right amount of context without blowing the context window on noise? How do you structure a multi-agent pipeline so that a failure in one agent does not corrupt the work of the others? What does the Model Context Protocol change about how we expose internal tools? What does human oversight look like when the agent can act faster than a human can review?
Part IV, Building AI-native software systems. RAG, embeddings, vector databases, system architecture. I kept this part grounded in the specific trade-offs I have actually faced shipping these systems. The theory of retrieval is easy. The practice of retrieval that returns the right chunk for the right question in a legal, medical or financial domain is where almost every team gets stuck. I wrote about one such trade-off in RAG vs deterministic routing.
Part V, Production, governance and engineering excellence. Observability, evaluation, security, privacy, responsible AI engineering, DevOps, CI/CD, cost, performance, governance. This is the part that is missing from almost every public conversation about AI in software, and it is the part that decides whether a team ships AI responsibly or just ships. The design rule I apply to any system that writes a safety claim is in In safety-critical AI, the dangerous default is done.
Part VI, The future of software engineering. What the AI software architect looks like, how engineering teams restructure around agents, what skills become load-bearing, what the career path becomes when writing code is no longer the thing that distinguishes a senior from a junior.
The uncomfortable part of the shift
The part of the shift that is hard to write about honestly is that it is not neutral for the people living through it. Engineers who built a decade of identity around writing elegant code are being asked to spend more of their time reviewing code written by a machine. Teams that measured themselves by lines shipped are being asked to measure themselves by outcomes. Managers who hired for coding ability are being asked to hire for judgement.
None of this is a loss for anyone who was already doing the right work. The engineers who always designed before they typed, who always thought about failure modes before they wrote tests, who always asked whether the problem was the right one before they solved it, they are the engineers whose careers accelerate in the AI era. The engineers who used typing speed as a proxy for value are the engineers who feel displaced, because the proxy has stopped working.
I say this in the book and I will say it here: the question is not whether AI will replace engineers. It will not. The question is whether a given engineer is building the muscles that matter in the new operating model, and whether their organisation is restructuring to reward those muscles. The two questions are separate. An engineer who upskills inside an organisation that still rewards throughput is in a bad local minimum. An organisation that restructures without helping its engineers upskill is also in one.
What accountability means when the system writes itself
The hardest intellectual problem in the book, the one I rewrote the most times, is the problem of accountability. When an agent writes code, runs tests, deploys the change, and the change breaks production at 3am, who owns the incident?
The honest answer is that the engineer owns it. Not the vendor of the agent. Not the model provider. Not the reviewer who approved the PR in thirty seconds because the tests were green. The engineer who built the system in which the agent was given that level of autonomy owns the outcome, and that ownership is not transferable.
This is not a comfortable conclusion for the industry to sit with, because it implies that the governance infrastructure most teams have is not sufficient for the level of autonomy most teams are already granting. A code review process designed for human authors does not catch the class of error an agent makes. A test suite designed to prevent regressions does not catch an architectural drift that an agent introduces gradually across twenty PRs. A CI pipeline designed for deterministic builds does not catch a non-deterministic failure in a model call.
The infrastructure the AI era requires is being built right now, and it is being built unevenly. The teams that invest in evaluation, observability, scoped autonomy, and explicit human-in-the-loop gates will ship AI responsibly. The teams that do not will ship AI at the same pace and discover the gap when something breaks that cannot be rolled back.
Where the discipline is going
If you forced me to give the one-line version of where the discipline is going, it would be this: the software engineer of the AI era is the person who defines the problem, designs the system, orchestrates the intelligence, and owns the outcome. The person who writes the implementation is still important, but the implementation is increasingly written by a system the engineer directs rather than typed by the engineer directly.
That shift does not reduce engineering. If anything, it raises the ceiling on what a small team can do, because the constraints that used to bound ambition have moved. A team of five that knows how to direct agents can now carry what used to take twenty. A solo engineer can now ship what used to require a startup. I know this because I have done it this year.
But the discipline is not easier. It is more responsible. The engineer in the AI era is asked to hold more of the system in their head, to think harder about failure modes, to be more explicit about contracts and invariants, to build more evaluation infrastructure, to justify more architectural decisions. The reward is leverage. The cost is that the easy version of the job, the version where you solve well-defined tickets with a steady cadence, is quietly being removed from the market.
What I hope the book does
I did not write this book to sell AI tools, and I did not write it to hype autonomous agents. I wrote it because the engineers I work with, the ones I lead and the ones I advise, kept asking the same questions in slightly different words. What should I be learning. Where should I be investing my time. How should I think about the next five years. What do I tell my manager, my team, my spouse.
The book is my attempt at a serious, grounded answer to those questions, structured as a map of the terrain rather than a prediction of the weather. The specific tools will change. The specific models will change. The underlying shift in what it means to engineer software is not going to reverse, and the engineers who understand the shape of it early will spend the rest of the decade compounding on it.
If you read it and one chapter changes how you approach a problem at work this month, the book did its job.
Software Engineering in the AI Era: From AI-Assisted Coding to Autonomous Software Engineering is available on Amazon. If your team is going through this shift and you want a second pair of eyes on your AI First operating model, see my consulting offerings or book a free 30-min call.