A software change can be quick to implement and still take days to deliver.
The missing time may sit in an unresolved ownership question, a decision buried in chat, or a review that cannot establish whether the change is safe. Generating the patch faster does not resolve those constraints.
Over the past year, I have written a series of articles about those surrounding systems and how AI changes them.
At first, each article addressed a specific problem.
| Article | The problem it addressed |
|---|---|
| Hierarchical Context | Explored how organizational knowledge needs to be structured when humans and agents both depend on it. |
| Async by Default | Looked at what happens when implementation accelerates but cross-team coordination still moves at calendar speed. |
| What Async Can’t Teach You | Examined the learning gap that appears when agents perform more of the routine work through which engineers traditionally developed judgment. |
| The Engineering Leadership Stack | Asked what each leadership layer should design when producing code is no longer the center of every role. |
The articles worked individually, but the ideas were becoming harder to separate.
Communication depends on context. Context depends on ownership. Ownership depends on organizational design. Faster execution increases the importance of validation. Validation depends on judgment. Judgment depends on learning. Leadership shapes all of it.
Eventually, I had to admit that I was no longer writing a collection of independent blog posts.
I was describing an operating model.
That is how AI-Native Engineering Organizations became a book.
The problem is larger than code generation
Most conversations about AI in software engineering begin with coding productivity.
That is understandable. Generated code is visible, easy to demonstrate, and relatively easy to measure. It is also only one part of the delivery system.
A software change still needs intent, context, decisions, implementation, validation, release, operation, and learning. AI can assist with several of those activities, but it does not make the lifecycle disappear.
It changes where the constraints sit.
| What AI speeds up | Where the constraint still sits |
|---|---|
| An agent may prepare an implementation in twenty minutes. | The work can still wait two days for another team to identify the correct owner. |
| A model may generate a technically plausible migration. | The organization still needs to decide which risk it accepts. |
| A team may produce more pull requests. | Review capacity, operational confidence, and customer adoption do not automatically expand with them. |
This is why I use the term AI SDLC to describe more than AI-assisted coding.
The AI SDLC is the operating model through which people and AI jointly define, build, validate, deliver, operate, and improve software.
Once you view the problem at that level, many familiar engineering practices need to be examined together. A blog is excellent for developing each argument. A book is better for showing how the arguments connect.
Not a linear transformation playbook
I do not think there is one universal sequence that turns an organization into an AI-native organization.
A startup with twelve engineers and an enterprise with twelve thousand engineers do not have the same constraints. One may struggle with implicit decisions and rapidly changing architecture. The other may struggle with fragmented ownership, legacy systems, governance, and coordination across dozens of teams.
They can still use the same questions.
- How does intent become executable work?
- Where does authoritative context live?
- How do changes move across team boundaries?
- Which decisions require accountable human authority?
- How is generated work verified?
- How do engineers develop judgment when agents perform more routine execution?
- What should engineering leaders design at each level?
- How does learning from one change improve the next one?
The book is organized around eight connected dimensions: Foundations, Communication, Knowledge, Learning, Leadership, Execution, Organizations, and Future.
Readers do not need to proceed in order. They can enter through the dimension that matches the constraint they are facing, then follow the links into the surrounding system.
That structure reflects how organizational change actually feels. Nobody wakes up on Monday and says, “Today I will transform Dimension III.”
They say, “Why did this agent miss a rule that everyone on the team apparently knows?” or “Why did a twenty-minute implementation require four meetings?”
The operating model begins with those practical failures.
Why this has to be a living book
The operating model has support in recent engineering practice, with limits. OpenAI’s harness-engineering account connects reliable agent work to maintained context and feedback. Anthropic’s context-engineering guidance explains why information selection matters. These support the book’s context argument, not its exact organizational hierarchy.
The evidence also changes the recommendations. Anthropic’s long-running application harness work shows why scaffolding should shrink when stronger models no longer need it. Its coding-skills study motivates checking learning without treating all assistance as harmful. OpenAI’s business-value guidance supports measuring outcomes and full cost rather than generated activity. The relevant chapters explain each source’s limits.
The practices around AI-assisted engineering are still developing.
Tools change quickly, but the deeper reason for keeping the book current is not product churn. Teams are still learning which organizational practices remain durable when AI becomes a meaningful participant in delivery.
Some approaches will mature into conventions. Others will prove too complicated, too expensive, or too dependent on a particular generation of tools. New evidence will challenge ideas that currently look sensible. Organizations will discover failure modes that are not obvious in small experiments.
I do not want to hide that evolution behind a publication date and a confident cover.
Each chapter has an updated date, a version, and a note explaining the current revision.
| Chapter state or change | Version | Publication date |
|---|---|---|
| Draft | 0.x |
None |
| Approved and published | Begins at 1.0 |
Original date retained as it evolves |
| Meaningful editorial change | Minor version | Original date retained |
| Substantial change to the argument or model | Major version | Original date retained |
A previously published chapter can need review again. Publication history and approval of the current text are different facts. The manuscript makes that distinction visible, along with AI assistance and its review status.
This also creates a useful discipline for me. Updating a chapter should mean more than quietly changing a paragraph. I need to ask whether new evidence changed the explanation, the practice, or the underlying model.
A textbook with a version number may feel less permanent than one carved into stone. It is also considerably easier to correct.
From articles to an integrated operating manual
| The blog | The book | |
|---|---|---|
| Editorial job | Gives me room to develop one idea and invite disagreement. | Resolves contradictions between those articles and makes their dependencies explicit. |
| Over time | Each article preserves what I thought was worth arguing at a particular moment. | When practice changes, I can revise the relevant chapter and explain what changed. |
This distinction matters because a pile of individually useful articles does not automatically create a coherent system.
An organization cannot implement async communication without considering where context lives. It cannot delegate more work to agents without redesigning validation. It cannot accelerate delivery while leaving learning and leadership untouched.
The book is my attempt to connect those dependencies explicitly.
Follow one change through the system
The current manuscript contains 32 chapters, including a running case: One Change Through the System.
Northstar is a fictional company trying to prevent duplicate orders when a client retries a request. The people, artifacts, and outcomes are invented teaching material. They are not a customer success story or evidence of a productivity gain.
The case begins with a bounded task. Orders and Checkout must agree on what a retry means. The agent needs the accepted decision rather than an abandoned proposal. The first implementation passes sequential tests and fails an independent concurrency check. The team corrects the failure, records the evidence, and keeps production authority outside the agent’s sandbox.
That single change gives the abstract model somewhere to stand.
The reader can inspect an executable ticket, follow the context and decision trail, and examine the evidence needed for release. The economics chapter works through costs, including review and maintenance. The company playbook chapter asks whether the evidence justifies expanding the workflow at all.
Sometimes the useful answer is to keep the scope small. A model that can only recommend more automation is not much of a decision tool.
The book also examines Recursive Self-Improvement and Organizational Change. A system that improves its own workflow presents a different opportunity from a model developing its successor. Neither makes organizational adoption, trust, or decision rights automatic. The chapter asks what a company can improve now and what evidence would justify calling the process recursive.
Who I hope it helps
I am writing this for people trying to make AI useful inside real engineering organizations.
That includes individual engineers learning how to work with agents without surrendering understanding. It includes managers redesigning team workflows. It includes staff engineers making architecture and context legible. It includes directors and executives deciding where to invest, which controls matter, and how to measure progress without counting generated motion.
I also hope it is useful across different organizational scales.
For a startup, the book can provide structure before accidental habits become operating policy.
For a growing company, it can help identify which coordination and knowledge systems need to mature as agent-assisted execution expands.
For an enterprise, it can provide a common vocabulary across engineering, product, platform, security, operations, and leadership.
The goal is not to prescribe maximum automation.
The goal is to help organizations move from intent to reliable software more predictably and with less avoidable friction.
An invitation to read critically
Start with the introduction and the Northstar case. Then follow the constraint that looks familiar:
- If generated work is difficult to trust, read Evaluation and Release Evidence.
- If implementation is faster but delivery is not, read Engineering Economics.
- If the challenge is deciding what your company should change, read Applying the Book.
The book’s practices are proposals to test against a real organization, not a validated recipe for transformation. A bounded software example cannot establish what will work across an enterprise.
I will do my best to keep the book updated as the technology, evidence, and industry practice develop. I also expect readers and practitioners to see gaps that I have missed.
Read it as an operating manual, but not as doctrine.
Choose one recent change. Identify where it waited, which evidence was missing, and who could authorize the next step. Use the book to propose one improvement, then check whether it helped. If it created more maintenance than value, that belongs in the result too.
If you send feedback, name the chapter, the recommendation you tried, and the conditions under which it failed. Include what you changed afterward. That gives me something specific to reconsider in the next revision.