To my coworkers at Elsevier in Aalborg and my dearest friends, who are always happy to talk about AI.
Preface
I wrote this book out of irritation. Not at the coding agents, but at the advice around them.
2026: Open my developer feeds on any peaceful afternoon, and you get another carousel of shouted titles:
- "Start an AI coding side hustle".
- "How I built a SaaS in a few weeks".
- "How to make money with vibe coding".
- "One prompt refactored my entire codebase".
Fine. Good for them. But I keep scrolling, waiting for the part that never comes: How? How did you do it? What did the codebase look like at week 2 when it all failed? What did you tell the agent? What did you burn? What broke in production?
That detail is usually absent. Though one-pagers are too thin to explain why the second week failed, which assumption broke, or which test exposed the flaw. The omission looks less like brevity than avoidance.
This book answers one question: how do you use coding agents in professional software work. Not the demo that looks clean on Tuesday and falls apart by Friday.
Vibe coding is fine for quick prototypes and mocks. Use it when you need a screen mock, a rough feature sketch, or a quick way to tease requirements out of somebody who cannot state them cleanly yet.
The prototype is not the product. I have joined teams expected to take over a codebase described as 90 percent done, only to find the challenging 90 percent still missing. The happy path worked. The system did not scale, could not run in the production environment, and had no useful metrics or deployment instructions. Calling it production-ready did not make it so.
My choice in such a situation is to scrap the prototype. Keep the ideas and the feedback it produced, then build from the real requirements. The architecture work usually makes the old implementation look naive anyway. Starting again gives the team something more valuable than rescued code: an understanding of the system and enough control to trust it.
This should not be new advice. Fred Brooks wrote it down in 1975: plan to throw one away. You will anyway. In 1975, throwing work away hurt, since rebuilding from scratch took weeks.
Sources: Frederick P. Brooks Jr. "The Mythical Man-Month: Essays on Software Engineering" (1975), plan to throw one away.
In 2026, when most of the build is done by a coding agent, that second pass is cheaper. Rebuilding is less painful than it was when a fresh start took weeks.
A prototype still has a good job. It lets you show an idea, challenge assumptions, and compare designs for a small service or component. Sometimes the right result is a better prototype, followed by another. Once the architecture, operational constraints, authentication, and delivery path are known, the prototype has finished its job. Use what you learned when designing the production system, then start its implementation separately.
A coding agent is not reading your mind. In 2026, a vague prompt still produces the wrong code in production work. State the rules, the intent, and the stack. Use the agent as a sparring partner for architecture and design, but keep the thinking on your side.
That is the purpose of the book. The machine writes more of the code. You do more of the hard thinking: what gets built, which scope is justified, which tradeoff is worth paying, and which tests must pass before merge. You become a writer, not a typist.
This book does not review or rank agents. The agent is the worker. The load-bearing variable is the input: the instructions, docs, specs, and checks you give it.
Context is most of the game. Do not cram a project into one prompt. Keep the decisions in plain-text documents and diagrams the agent can load again next month. Without that, every session re-creates the same conventions, reopens settled decisions, and ships code that breaks the constraints nobody wrote down.
From Vibe to Pro
This is the part the carousels leave out. Give the agent the current repo facts, the active constraints, and the acceptance criteria, and the work moves from rough prototype to production software. The hard part is not the code. The hard part is choosing the limits and verifying the result stayed inside them.
Software development still needs judgment. I expect better models and more automation, and I will update this preface as that line moves. In 2026 the job still belongs to developers and reviewers: choose the scope, set the constraints, and reject code that misses both.
The rest of the book starts with one shift in thought: the source-controlled workspace is no longer only for developers reading code. It is where the next agent session finds the ADR, the spec, and the rule you do not want re-litigated.
Flemming Nørnberg Larsen, 2026