When I was a kid, I read everything I could get my hands on. I started with children’s books and moved to young adult books while I was still in 4th grade. Once I knew enough English, I started reading science fiction, mainly Star Trek novels. As I grew older, I wanted to write a book. I had the whole saga planned, and if you had asked, I would have told you the frame story and probably walked you through the sequels.
This week, I finally published one. Alas, there are no starships in it. It is about what happens when the science fiction arrives, and how we should work once it does.
The book is Judgment-Driven Development: Leading Software Teams When AI Does the Work. Its argument fits in one line: AI made execution cheap, but it did not make judgment cheap. Somebody still has to decide what is worth building, whether it is right, and who answers for it when it goes wrong.
I want to tell you how it was made, because the process turned into the most honest test the book could get at this point. I did not plan it that way.
It started here. I launched this site a little over a year ago, and within a few months I was putting a name to Judgment-Driven Development. I kept asking a simple question: when AI removes so many of the barriers that used to slow us down, which barrier is actually left? My answer was human judgment, and I have spent most of this year thinking out loud about it in these essays, and to anyone who happened to sit next to me on my train rides. Looking back, those early essays were the Signals stage of the cycle the book describes: watching what kept coming up, before committing to building anything.
The book has been in the works for more than six months. The essays and the chapters grew alongside each other. An essay would test an idea in public, and the strongest ones became raw material for chapters.
I relied on AI a lot, and on more than one tool, each for what it did best, first drafts included. A traditional author has a team behind them: a research assistant, a developmental editor, a copyeditor, a skeptical first reader. I had all of them, on demand, for the price of a few subscriptions. What I did not have was anyone to make the calls. That part stayed with me. In April I wrote an essay called “Your Job Isn’t to Write the Code. It’s to Own the Decision.” This book is me taking my own advice.
The tools also did more than execute. They proposed structures, challenged my framing, and argued for directions I had not considered. I even used one to argue against the work of another, the way you would ask a second engineer to review code the first one wrote.
Writing a book about working with AI, with AI, carries an obvious risk. If I let the tools make the calls, I would be disproving my own thesis on every page. Worse, nobody reading it would know.
So the book had to pass its own test, even while the test was still being written. The method was not finished when I started, and I did not wait for it to be. I applied each practice to my own work as it took shape. Some, like rewriting paragraphs that did not sound like me, ran through the whole manuscript. Others, like the formal Judgment Log, arrived late, in the final editing. The book and the method shaped each other.
Not every part of JDD can be tested by one person writing alone. There are no specialist vetoes on a solo project and no production incidents. But the core practices can be: deciding deliberately, recording why, verifying what you claim, and knowing when to stop. I held the book to those.
The framework, the cycle, the decision boundaries, the Judgment Log: all of it came out of twenty years of watching how decisions really get made in R&D and product. The tools offered options. I chose.
In the final editing, I made the choosing visible, the way the book recommends. Every real decision went into a log: what was proposed, what I chose, what I rejected and why, and how confident I was. That phase produced 66 entries.
Most of them are small. Which name to use for a stage of the cycle. Whether a claim was strong enough to keep. Whether a chapter was earning its length. A lot of them are rejections. More than once, a paragraph came back that was fluent, well structured, and plainly not mine. It sounded like a machine being thoughtful. I threw those out and wrote them again in my own voice, and each one went into the log, because “this does not sound like me” is a judgment call too.
The log paid for itself in a way I did not expect. The stage names are a good example. When I set up my style sheet, I called one stage Design. Weeks later I changed my mind and renamed it UX, because the stage is about the experience of the user, and “Design” kept pulling readers toward visual polish. That reversal went into the log with the reason next to it. When chapters used different names, I did not have to reconstruct which one was current or why. I could read it, and align the whole book to one decision. Without that record, an old name could easily have crept back in during a late edit, and nobody would have known it was a reversal of a deliberate choice. That is exactly the failure the book describes: teams that keep the result of a decision and lose the reasoning behind it, until someone undoes it by accident.
Late in the editing, I realized I had been practicing this for a while without naming it. My own coding sessions with AI already kept a running record of the calls I made after reviewing its output. I had written a whole book about the habit before noticing I already had it. The book did not invent the practice. It gave it a structure, and the writing forced me to keep it up when it was inconvenient.
Facts got the treatment I would want for a release. I checked more than 150 claims, each traced back to a source. Several turned out to be wrong or out of date. A study had been revised. A figure had moved. A company statement said less than the version I had remembered. Some sources would not open in the tools I was using, so I tracked down the original documents myself. And I read the sources myself. A citation I had not read was not one I could stand behind. None of this is glamorous, and all of it is the difference between a book you can quote and a book you have to apologize for.
Then came the part I found hardest, which was stopping.
I sent the manuscript to readers I trust, with specific questions rather than a request for general impressions. No feedback came back. People are busy, and a manuscript is a big ask. So the reviews I worked from came from AI, including one I asked a different tool to make deliberately skeptical. When that feedback came in, there was a strong pull to keep going. That is the trap of cheap execution. When a revision costs almost nothing, there is always one more pass, and every pass feels responsible. I could have stayed in that loop for months and called it quality.
So I set a stop rule. One bounded round: the three changes that mattered most, done in one session, then freeze. Everything else went onto a list for the second edition. The list is real, and some of it is good. But a book that is never finished helps nobody, and deciding when it is done is a judgment no tool will make for you. If anything, the tools make it harder, because they never get tired.
Even the last mile had decisions in it. The print layout, the cover, the price, what to put on the copyright page, how to answer the AI question honestly. Each of those went the same way. Options in front of me, a recommendation, my call, written down. When Amazon asked whether the book contained AI-generated text, I said it did. Hiding it would have been a strange choice for a book about accountability.
What did I learn?
The tools made me much faster, and they moved almost all of my responsibility into the decisions. I felt that shift from the inside before I could explain it to anyone else.
I also learned that the method holds up best where it is least comfortable. Logging a decision you are proud of is easy. Logging the one you are unsure about, with “low confidence” next to it, is what makes the record worth reading later.
The kid who wanted to write science fiction would probably be a little disappointed that there are no starships in it. But I think he would recognize the question underneath. Star Trek always assumed that as our tools got more powerful, we would have to grow up to deserve them. That is still the job. It is just closer than it used to be.
The book is out now in paperback and Kindle. You can read more about it here or get it on Amazon.
The manuscript is finished, but the work behind it is not. If you try any of it, with your team or on your own work, I want to hear what happened. Good or bad. Write to me at rami@newrealm.co with “JDD report” in the subject. What I learn from you goes into the next edition.