Skip to content
All books
New

Engineering Software with Coding Agents: Context, Control, and Evidence from Ticket to Production

Eighteen chapters in six parts follow one change from ticket to production: context, permissions, tests, review, CI and release, with the evidence that lets someone else check the work.

About the book

A coding agent can change your repository in minutes. It reports that the work is done, the diff looks fine, and the feature still does not work, because the missing piece sits between the files that changed.

This book follows one change, from ticket to production, through a fictional product called Relay. Each stage asks the same question: what evidence would let someone else check this work without trusting the agent's report?

It is written for engineers who already use Claude Code, Codex or a similar tool on a codebase that matters, and who still answer for what ships.

What you get

  • Keep context between sessions: checkpoints, handoffs and a context ledger, so a new session can rebuild the work from files instead of from the old chat
  • Turn a ticket into a work contract with acceptance criteria and forbidden behaviour, then read an unfamiliar repository before you change it
  • Separate guidance from enforcement: instruction files, permission profiles, sandboxes and boundaries that hold when a command is allowed
  • Delegate to more than one agent without losing the thread: separate workspaces, return schemas and one integration owner
  • Treat tools, connectors and retrieved content as untrusted input, and review the change that was made, not the report about it
  • Take the change through CI, release and rollback, and measure the whole delivery system, review time included

Where agent-assisted work loses control

The diff looks fine

Every changed file does what it says. The job that was supposed to pick up the scheduled update was never written.

The chat was the only record

A new session starts from nothing, and decisions you already rejected come back.

A rule nothing enforces

Do not use the network, written in an instruction file, is guidance. A blocked network is a boundary.

Many agents, no owner

Parallel agents return work that overlaps, and nobody owns the integration.

Input you did not write

Tool output, connectors and retrieved pages can carry instructions the agent will follow.

Reviewing the performance

A confident report is not evidence. The change that was made is what needs review.

If this work is correct, then under these conditions an actor can do the thing, while the forbidden outcome does not occur, and the evidence will show it.
From Engineering Software with Coding Agents

What changes when you use it

You stopYou stop starting from the prompt.

You startYou start from a work contract with acceptance criteria and forbidden behaviour.

You stopYou stop trusting the instruction file to hold.

You startYou separate guidance from enforcement, and check what blocks.

You stopYou stop carrying context in the chat.

You startYou keep checkpoints and a context ledger a new session can rebuild from.

You stopYou stop reading the agent's summary.

You startYou review the change, with a claim-to-evidence report beside it.

You stopYou stop measuring how fast code appears.

You startYou measure the whole delivery system, review time included.

Signs the agent is ahead of your controls

  • Tests pass and nobody can say which claim they prove.
  • The next session reopens a decision you already made.
  • The permission profile is wider than the task, because narrowing it was slow.
  • Two agents touched the same module and the merge was settled by whoever finished last.
  • Review comments are about style, because the diff is too large to read for behaviour.
  • A connector or retrieved page changed what the agent did, and nobody noticed.

Why this book exists

Most advice on coding agents is about prompts. The failures I kept seeing were not prompt failures. They were missing contracts, context that died with the chat, rules written in an instruction file that nothing enforced, and reviews of the agent's report instead of the change.

So the book treats the agent as a worker inside a system you design: a place to work, a contract to meet, boundaries that hold, and evidence you can inspect.

A page from the book

Copied as printed, so you can judge the format before you buy.

Chapter 1, page 30

Define the system-level claim

Before the first tool call, complete one sentence:

The template

If this work is correct, then under [conditions], [actor] can [observable outcome], while [forbidden outcome] does not occur, and [evidence] will show it.

For Relay

If this work is correct, then under the accepted authority and time rules, an incident commander can commit one future status publication, while retry and handover do not produce unauthorized or duplicate customer-visible messages, and state, audit, provider, and client evidence will show the result.

The sentence is not the full contract. It forces the assignment to name conditions, actor, outcome, negative behaviour, and evidence. A generated date picker can no longer masquerade as the completed feature.

Want more pages?

Free PDF, no sign-up: desktop layout, 12 pages or phone layout, 16 pages.

Before and after

A ticket handed to an agent

Before

Add scheduled status updates.

After

If this work is correct, then under the accepted time rules an incident commander can schedule one status publication, while a retry does not send it twice, and the log will show it.

The agent now has a claim to prove, not a date picker to build.

The agent says it is done

Before

The tests pass, so merge.

After

Ask for a claim-to-evidence report, then check each claim against the running system: trigger, boundary, state, negative path, deployment and observability.

Choose your edition

Both editions are on one Gumroad page: you pick the edition there, before you pay. Every edition includes free lifetime updates.

Book

The complete book

$149

The full method, from ticket to production, to read and apply with your own agent.

  • PDF and EPUB
  • 371 pages
  • 18 chapters in six parts
  • 5 appendices
  • 9 annotated spreads
Choose Book, $149

Secure checkout on Gumroad. Instant PDF and EPUB download. Lifetime updates.

Most complete

Book + Companion

The book and the runnable Relay lab

$299

Everything in Book, plus the Relay lab in 7 Git-tagged stages, so you can run the method instead of only reading it.

Choose this if you want to practise on a working codebase.

  • Everything in Book
  • Relay lab in 7 Git-tagged stages
  • 22 configuration files for Claude Code, Codex, Git, GitHub and MCP
  • Workbook, 35 pages
  • Session casebook, 27 pages
  • Swift case study with 20 tests
  • 13 companion PDFs
Choose Book + Companion, $299

Secure checkout on Gumroad. Instant PDF and EPUB download. Lifetime updates.

Nine annotated spreads from agent sessions

Each spread sets a moment from a session beside a note on what it proved and what it did not. Seven are captures of recorded sessions and two are reconstructions, and the book labels which is which. Relay is a teaching case.

Capture

Chapter 5 spread

  • Context that earns its space
  • What the session kept and what it lost

Capture

Chapter 6 spread

  • Instructions against enforcement
  • What the permission profile blocked

Two captures

Chapter 12 spreads

  • Delegation across separate workspaces
  • Return schemas and one integration owner

Capture and reconstruction

Chapter 13 spreads

  • Connectors and untrusted content
  • A reconstructed connector case

Capture

Chapter 14 spread

  • Reviewing the change, not the report

Capture

Chapter 15 spread

  • CI as an authority boundary

Reconstruction

Chapter 16 spread

  • Release, observe, correct on a store page

What is inside

  1. 1Beyond autocompletep. 23
  2. 2The system around the modelp. 35
  3. 3Responsibility does not delegatep. 47
  4. 4Give the agent a place to workp. 59
  5. 5Context that earns its spacep. 75
  6. 6Instructions, permissions, and boundariesp. 95
  7. 7The ticket is evidence, not truthp. 117
  8. 8Read the system before you change itp. 133
  9. 9Design an inspectable changep. 147
  10. 10Implement in small, reversible stepsp. 161
  11. 11Tests are claims with receiptsp. 181
  12. 12Delegation without diffusionp. 197
  13. 13Tools, connectors, and untrusted inputsp. 225
  14. 14Review the change, not the performancep. 249
  15. 15CI as an authority boundaryp. 267
  16. 16Release, observe, correctp. 287
  17. 17Security and governance under real constraintsp. 303
  18. 18Measure the system you builtp. 321
  19. Appendix A Field contractsp. 341
  20. Appendix B Evidence labelsp. 355
  21. Appendix C Companion lab mapp. 365
  22. Appendix D Maintain a versioned tool ledgerp. 375
  23. Appendix E Referencesp. 383

Who this is for

This is for you ifA coding agent can change your repository, and you still answer for what reaches production.

  • You use a coding agent on a codebase that matters, and you answer for what reaches production.
  • You are comfortable with Git, testing and code review.
  • You work in backend, frontend, mobile or platform code, and want a method that does not depend on one tool.

Not for

  • Engineers looking for a first introduction to programming
  • Anyone who wants a collection of prompts to paste
  • Anyone who expects one tool to be crowned the answer
The library pathWhere this fits
  1. 01Get foundThe Silent Rejection
  2. 02Build the record and negotiateThe iOS Engineer Playbook · Leverage
  3. 03InterviewThe iOS Interview Blueprint · The Senior Signal · Top 300 React Native Interview Questions · The Flutter Interview Book · The Senior SDET Interview Handbook
  4. 04Answer practice and live roundsThe 24-Hour iOS Interview Answer Book · The 24-Hour Android Interview Answer Book · Share Your Screen
  5. 05Architecture and qualitySwiftUI Under Load · Mobile System Design Blueprint · Security Is a Feature · The Second Pass
  6. 06Staff systems and ownershipAltitude · Ticket Taker, Outcome Owner
  7. 07Build with AIBuild With Your Brain On (coming soon) · Engineering Software with Coding AgentsYou are here
  8. 08LeadBefore the Room
  9. 09ArchitectControlled Change
Portrait of Mike Salari

About the author

Mike Salari

Staff mobile engineer · 500+ technical interviews from the hiring side.

I have spent 15 years in mobile and sat through 500+ technical interviews from the hiring side. I wrote this book for the engineer who lets an agent change the repository and still answers for what ships.

15 years building production mobile software, with experience across Apple, Adobe, Cisco, Mastercard and Visa.

Read the full story

Before or after you buy

FAQ

Engineering Software with Coding Agents: questions before you buy

What is Engineering Software with Coding Agents about?

It is a 371-page method for working with coding agents such as Claude Code and Codex in an existing codebase. Eighteen chapters in six parts follow one change from ticket to production: context, permissions, tests, review, CI and release, with the evidence that lets someone else check the work.

Who is it for?

Senior, staff and principal engineers, tech leads and contractors who already use a coding agent on real code and still answer for what ships. You should be comfortable with Git, testing and code review. Backend, frontend, mobile and platform work all fit.

Is it tied to one tool?

No. The method is about contracts, context, boundaries and evidence. The examples use Claude Code and Codex, and the book says which behaviour belongs to a tool and which belongs to the method.

What is the difference between Book and Book + Companion?

Book is the 371-page book in PDF and EPUB. Book + Companion adds the Relay lab in 7 Git-tagged stages, 22 configuration files for Claude Code, Codex, Git, GitHub and MCP, a workbook, a session casebook, a Swift case study with 20 tests and 13 companion PDFs.

What are the annotated spreads?

Nine spreads that set a moment from an agent session beside a note on what it proved and what it did not. Seven are captures of recorded sessions and two are reconstructions, and the book labels each one.

Is Relay a real product?

No. Relay is a fictional product used as the teaching case, so the examples can be argued without exposing any real system.

Can I read a sample first?

Yes. The free sample comes as a 12-page desktop PDF and a 16-page phone PDF, with no sign-up. You can also read it on the book page.

Share this book

XLinkedInBlueskyThreadsHacker News