Why This Book Exists
On February 4, 2025, Andrej Karpathy posted a single sentence that gave a name to something I had been doing for over a year. He called it agentic engineering — the discipline of working with AI agents that write code, run tools, and make decisions across extended workflows. The term immediately gained traction. Within hours, Google engineers were publishing analyses. Within days, the discourse had its own hashtag.
I read that post and felt an odd mixture of recognition and frustration. Recognition, because Karpathy had precisely described the kind of work I had been doing across 3,072 conversations and 57 sequential development sessions. Frustration, because the conversation had already moved on to frameworks and tooling — and nobody was talking about the hardest part.
The hardest part is not getting an AI agent to write code. The hardest part is getting it to remember what it wrote yesterday.
Industrial Agentic Engineering
This book introduces a term: Industrial Agentic Engineering. It is not a marketing phrase. It describes what happens when the principles of industrial engineering* — the discipline I practised for fifty years before I ever touched an AI — are applied to long-running AI development projects.
* Industrial engineering: the discipline of optimising complex systems, eliminating waste, designing workflows, enforcing quality gates, measuring outcomes.
I am a seventy-four-year-old industrial engineer with eighteen years in software development and technical project management. But my foundation — the first three decades — was the manufacturing floor: quality gates, role separation, shift handovers, and the conviction that systems must not fail. When I started working with large language models, it was the factory instincts, not the software experience, that saved me. I came from the manufacturing floor, where quality gates are not best practices — they are how you keep people alive and factories running. Where role separation is not an organisational choice — it is how you prevent a plant manager from operating the lathe and a machinist from redesigning the jig. Where documentation is not overhead — it is how you reconstruct the state of a system when something goes wrong at two in the morning.
When I began working with large language models in December 2022 — week one of ChatGPT’s public release — I brought those instincts with me. I did not know they would become a methodology. I just knew that when my AI assistant forgot everything between sessions, the problem felt familiar. I had seen it before, in every factory that ran without shift handover logs, in every project that lost institutional memory when key people left.
What This Book Is
Human to AI
The solution was also familiar. You write it down. You write it down in a structured format. You make the next shift read it before they touch anything. And you never, ever trust that the person taking over remembers what the person leaving knew.
This is the operating manual I built for myself after the first hundred sessions hit the same wall. Every technique in this book was developed through real use, tested across real projects, and measured against real outcomes. The evidence is not hypothetical. It comes from 94,155 messages, 83,693 code blocks, and a conversation archive that spans three years and two major AI platforms.
The core concept is simple: a re-anchor is a structured document that captures the complete state of a development session — what was built, what was decided, what broke, and what comes next. At the start of the next session, you feed it back to the AI. The AI reconstructs its understanding of the project. You pick up where you left off instead of starting from zero.
That is the simplest version. This book covers the full system: the session protocol that wraps around re-anchors, the two-layer architecture that makes Claude and ChatGPT actually enforce your rules, the role separation model that prevents the AI from designing and building at the same time, and the scaling patterns that let you govern multiple projects without losing coherence.
This is not a prompt engineering guide. There are hundreds of those already, and most of them are obsolete within months. This book does not teach you how to write better prompts. It teaches you how to build the infrastructure that makes every prompt land in the right context.
This is not a theoretical framework. Every chapter contains evidence from real sessions — real mistakes, real recoveries, real measurements. Where I show a screenshot, it is from my actual development environment. Where I quote a conversation, it happened.
And this is not a book about coding. I do not write code. I have not written a line of code in the creation of any of the five products built with this methodology. The human must never code. The designer must never code. The coder must never design. That principle — three separations, not two — is at the heart of everything that follows.
Response by AI
A Note on How This Book Was Made
This book was written using the methodology it describes. The AI designed the chapter structure, extracted evidence from a database of 3,072 conversations, drafted the prose, and formatted the output — all under the supervision of a human who does not code. The re-anchors that managed the writing process are numbered in the same bootstrap directory that holds the re-anchors for every other project.
If the methodology did not work, this book would not exist. That is the simplest proof I can offer.
Mohan Iyer
Auckland, New Zealand