How I Wrote 42

The first thing I ever built with AI was a Slack bot that answered questions about our own company documentation. It took an afternoon. It was ugly. It hallucinated about our vacation policy. Within a month it was answering around two hundred questions a week, and people at EltexSoft stopped asking me things they could ask it instead.

That bot is why there's a book.

Not directly. What happened after is that I started writing things down. Which tool, which configuration, which prompt, which failure. It was internal documentation, the kind nobody reads. Then it became articles on our site. Then someone asked whether there was a full version, and the honest answer was no, because the full version lived in fragments across a workspace and my head.

42: The AI Builder's Stack publishes on August 15. Twenty-two chapters, 396 pages, just under a hundred thousand words, written while running a forty-person studio. This is how it got made.

Twelve chapters became twenty-two

The first outline was a toolbelt. Terminal, editor, version control, deployment. Twelve chapters, each one a tool.

It fell apart around chapter six. Every chapter kept pointing at a chapter that didn't exist. You can't explain Claude Code without explaining what a good instruction file looks like, which means explaining how to write a spec, which means a chapter on PRDs. You can't explain MCP without first explaining why an API isn't enough. You can't recommend AI code review without confronting how much more often AI-written code fails a security pass, which is its own chapter.

Twelve became twenty-two, in six parts, arranged so a reader who has never opened a terminal can start at chapter one and a reader who ships daily can start at chapter twelve. The last two written were Chapter 7 on AI-powered IDEs and Chapter 21 on transforming a small team. Twenty-one is the one people will still care about in five years, when every tool in the other chapters has been acquired or deprecated.

Letting the scope grow cost me about a year. A half-book on a moving target is worth nothing, so it was the right trade, but it's the reason this took almost two years instead of one.

Every chapter has the same skeleton

I didn't figure this out until chapter four, and then I went back and rebuilt the first three.

Open with something that happened. A client problem, a mistake, a workflow that changed. Then explain the thing from absolute zero, assuming the reader has never heard of it, because the promise of the book is zero to deep and skipping the zero part is how technical writing loses people in the first page. Then go deep: architecture, configuration, the features that matter against the ones you can ignore, benchmark numbers with the source named. Then show what I do, with the config files and code that make it reproducible. Then compare it honestly to the alternatives, including where the alternative wins. Then close with what to do first.

Having a fixed skeleton meant I could write a chapter in pieces across a week of interruptions and it would still hold together. That mattered more than any tool. I was not writing in retreats. I was writing between calls.

The research came first and separately. For each chapter I'd build a research artifact of five to twenty thousand words before writing a line: official docs read directly rather than summarized, independent benchmarks alongside vendor claims, pricing confirmed on the pricing page with the month noted. Then the chapter got written from that. Keeping research and writing in different passes is the single biggest quality decision I made, because when they're mixed you end up writing toward whatever you found first.

The editing pass was quantitative

At some point I stopped reading my own prose usefully. Twenty-two chapters in, I could not tell my voice from my tics.

So I ran the manuscript as data. A cross-chapter scan found that "actually" appeared 73 times, "genuinely" 22 times. Terminology had drifted: open-source and open source, real-time and realtime, sometimes inside the same chapter. Chapters 8 and 21 had slid into a different register than the rest of the book.

None of that shows up when you read. All of it shows up when you count. I thinned the filler words except where they were doing contrast work, standardized the terminology, and pulled 8 and 21 back into voice.

I also paid for ProWritingAid and turned most of it off. Its readability, pacing, and vivid-verb rules fight technical writing constantly, because a sentence explaining row-level security is supposed to be flat. What earned its keep was consistency checking, grammar, and a custom banned-words list. Everything else was arguing with me about a job it didn't understand.

Two things came out of that pass that had nothing to do with grammar. First, every client name got anonymized: a specific real estate platform became "a major real estate platform client," and so on down the list. Second, I went back and added humor deliberately, and then had to vary it, because my default joke shape is "while doing X" and twenty-two chapters of one joke shape is worse than no jokes.

Writing about the AI stack, using the AI stack

Where it helped without argument was production. I started formatting in Atticus, the standard self-publishing tool, and killed it in a day: no code-block element, strips indentation, flattens the PDF text layer. For a book with a hundred-plus code samples and YAML configs that's disqualifying, and I found out by running a deliberately hostile test chapter through it rather than importing the whole manuscript and discovering it at page 200.

I rebuilt the interior on Pandoc and XeLaTeX, driven by Claude Code, so one command produces the print PDF and the EPUB from the same source files. The first clean build took days. Every rebuild after that took seconds, which is the only reason I could keep editing this close to the deadline.

That build also caught 158 failures in a single pass, all of them the same mistake I'd been making for two years: markdown links written as [supabase.com](supabase.com), with no scheme. EPUBCheck rejects every one. A twelve-line script fixed all 158 in a second. By hand it would have taken a weekend and I'd have missed some.

Now the part I think about most.

Early on, a placeholder advance-praise page got created with seven endorsements on it. Names, titles, companies, quotes. All invented, all labeled as a placeholder in the moment. Then it sat in the manuscript folder for months while the file list grew past forty and I stopped opening the files I thought were finished.

It surfaced in July, during a verification pass on the compiled interior, and only because that check ran against the built PDF instead of against my memory of what was in it. Seven fabricated endorsements from seven people who don't exist, one recompile away from shipping inside a book whose entire argument is that you verify claims instead of trusting them.

That was my failure, not the tool's, and the fix is a rule I now apply to everything: open the artifact and look at it. Not the summary of the artifact, not the report about it, not what you remember putting there. The file.

The praise page that ships has three names on it. Riley Davidson, an engineering manager at Instacart. Richard Cave at VSCO, formerly an engineering manager at Apple. Ivan Bercovich, an operating partner at ScOp Venture Capital. All three read the manuscript. A fourth one came later, with quite a few more still pending. This taught me the useful thing about blurbs: assume a solid portion of your asks evaporate, and never design a back cover around a quote you don't have in writing.

The thing I didn't expect from any of this is what the epilogue ended up admitting. I started the project thinking I knew my stack well. Researching twenty-two chapters showed me how much of it I'd been running on autopilot. The chapters on MCP, Skills, and agentic workflows forced me to formalize things that had been intuition, and the chapter on Chinese models forced me to check assumptions I'd been making about tools I depend on daily. The book changed how I work more than it documented it.

The cover took seven tries

I hired Mike Trent through Reedsy. He spent two decades at Wiley art-directing their technical and professional lines, which is exactly the shelf this book sits on, and the benchmark I gave him was Stripe Press and Holloway. Restraint, typography, no robots, no circuit boards, no blue glow.

He came back with seven concepts. We landed on deep forest green with a vertical stack of diamonds and a large serif 42, which turned out to be his own first instinct as well as mine. The one I still think about is the one we killed: a navy cover built from forty-two rows of layers with the gaps forming decision paths through them. It was the smartest thinking in the set and it was too clever for a thumbnail, which is the whole problem with book covers.

That's the argument for hiring someone. A generated cover would have saved four figures and cost the book its credibility in the half-second before anyone reads a word.

The free chapters are strategy, not generosity

Trimmed versions of all twenty-two chapters are free at eltexsoft.com/course. Web chapters run two to three thousand words. Book chapters run four to six.

The rule I wrote for myself when cutting them: teach the what and the why, sell the how. The opening story stays uncut. The zero-to-understanding section stays uncut. The closer stays uncut. What comes out is the configuration walkthrough, the working code, the config files, the full comparison tables, and the sections where I go step by step through my own workflow. A web reader finishes able to explain the topic at a standup. A book reader finishes able to run it.

People told me I was giving away the product. Eloquent JavaScript is free online and the print edition sits at the top of its Amazon category. Pro Git is free under Creative Commons and the paperback has been in print over a decade. Buyers self-select. The free version builds the audience, the paid version captures the people who want the uncut thing on a shelf.

Pricing landed at $9.99 for Kindle, $24.99 paperback, $39.99 hardcover, after a pre-order at $6.99. The Kindle number isn't taste. KDP's 70% royalty band stops at $9.99 and drops to 35% above it, so you'd have to charge twenty dollars to earn the same amount. The hardcover exists because hardcovers are rare in self-published technical books, which is exactly why it's worth having one.

No sponsors, no affiliate links, nobody paid to be mentioned. That's not a moral position, it's a functional one. The book tells you which tools are marketing ahead of reality. That sentence is worth nothing if a vendor bought a page.

The unglamorous half

Somewhere around month eighteen I learned that publishing a book properly means running a second project alongside the first one.

There's an imprint, Sub-Etha Press, which is a trade name over a small Wyoming company rather than a publishing house. There are three ISBNs from Bowker, so the imprint owns its own identifiers instead of borrowing Amazon's. There's a registered copyright, a library catalog number, and an insurance policy. The name is a nod to Douglas Adams, since the Sub-Etha is the network in The Hitchhiker's Guide to the Galaxy and the title is 42.

None of it makes the book better. It's what lets a book that names thirty-one people and rates twenty-five commercial products say what it says. If you're writing something opinionated, start it early, because all of it has dependencies on your publication date and none of it moves fast.

What I'd do differently

I'd fix the chapter skeleton before writing chapter one. Rebuilding the first three chapters to match the pattern I found in chapter four cost a week I didn't have.

I'd pick the production toolchain before writing a word. Two years of markdown written without a target format is two years of small inconsistencies that all arrive at once during the first build.

I'd never create a placeholder that looks finished. If a page isn't ready it should be empty, or it should say TODO in forty-point type. A well-formed fake is the most dangerous thing in a project, because it passes every glance.

I'd freeze the tool chapters six months out and let them age. I rewrote pricing and feature sections repeatedly chasing accuracy, and some of it changed again anyway. My own epilogue says the book has a half-life measured in months. I should have believed it sooner and spent that time on the chapters that don't decay.

I'd ask twice as many people for blurbs, twice as early.

The free-chapter decision is the one call I've had no second thoughts about at all.

42: The AI Builder's Stack publishes August 15, 2026 from Sub-Etha Press. It's on Amazon in Kindle, paperback, and hardcover. Trimmed versions of all twenty-two chapters are free at eltexsoft.com/course.