AID: All-In Design

The problem

Good people, doing good work, describing the same project in words the others cannot use

Business says one thing, engineering hears another, and the data and AI people are handed a sentence that has already changed shape twice. Everyone is competent. The slide is green. The work still misses.

AID is the small set of things that fixes that: three artifacts, three loops, three translators and one lens. The test for every one of them is whether it makes another role faster, clearer, or safer.

The lens

Five numbers, scored by every role against the same anchors

One to ten on each, with weights that say what a given role cares about. Two of the terms are deliberately turned upside down, because more complexity and more risk should pull a score down rather than up. One number per role, and the disagreement between them is the useful part — it shows you exactly where the translation failed.

From the introduction

An excerpt

I have spent more than twenty-five years in IT, and I have sat on every side of the table. I have written the code, designed the system, owned the product, run the program, consulted on the wreckage, and, lately, owned the company. In every one of those chairs I watched the same thing happen. Good people, doing good work, describing the same project in words the others could not use. This book is about the small set of things that fix that.

“Before we start”

From the introduction

The year the team was mostly agents

The framework was written for people. Then the author spent a year running a portfolio of products where most of the team is AI agents — programs that read the code, run the tests, open the changes and remember what they did last week. It turned out the agents needed the same thing the people did.

One scene will do for now. An agent was asked to get a new product “set up” on my own identity platform and my own mail service. It read the documentation, found the databases, and wrote the records straight in: an application, a client, roles, a mail domain, aliases. Every record was well-formed. The product could sign people in and receive mail. It looked like it was working. And nothing about it was real, because nobody had registered an account through either front door, so there was no license, no billing, no confirmation, no audit trail. The row existed; everything that should accompany it did not. We deleted all of it and did it again the slow way, through the front door, as a customer would.

Here’s the thing: the agent did not fail because it was an agent. It failed in exactly the ways the people in chapter 2 fail, for exactly the same reason. Nobody had written the gate, the owner and the evidence where the one doing the work would see them.

“Before we start”

What it is not

No methodology to adopt, no tool to buy, nothing to pass

Who it is for

Anyone who has watched a sentence change shape on its way across the room

It is for the executive who looks at a green slide and wonders. For the product manager who carries the sponsor’s sentence into the room and watches it change shape. For the engineer who said “ours is done” and meant it. For the tester, the analyst, the lawyer, the data scientist and the marketer who were not invited until week nine. And it is for the company of five, or of one, that thinks these are big-company problems. They are not. Small does not mean simple. It means fewer people to notice.

“Before we start”

What is inside

Five parts, twenty chapters

Status

Where the book is

Manuscript

Complete. First edition, version 8, dated 2026.

Length

About 67,000 words · 20 chapters · 37 figures

Stage

In review with a small group of readers

ISBN

To be assigned

Imprint

To be confirmed