# Brief 42 — founder memo: the craftsman makes the tools, and the book should lead with them **Date:** 28 August 2026 **Source:** a voice memo (Otter transcription, speaker label and timestamp preserved), the third of the day and the one that states the making-of book's thesis outright. It gives the principle, refines the two audiences, adds a requirement the site does not yet meet, and ends with a concrete structural instruction for the book. Reproduced verbatim below. The numbered reading beneath it is the agent's, for the founder to correct. --- ## The memo, verbatim > Dinis Cruz 0:00 > Okay, so so the the concept I want to talk I want to start talking here, which is the concept of the the approach, is actually very important because in a way this is one of the key principles of the making a book. In fact, it's what it's possible, and it's also very tied to what I was talking about in terms of the refactoring, right, and in terms of the making changes, and and I think the the key principle here is going back to I would say Brett Victor's inventing on principle, and also going back to the whole idea of design, where you design the function and you design, you know, something, and you keep iterating little bit by bit by bit by bit on on what's happening, and we've seen this already in what we've done because what we have here is a series of small changes and and the ability of me in a way has not just the author but the creator of the environment to to basically to keep improving the tooling and and the key concept that I want to talk about here is the idea that you can't distinguish the creator from the technology and the workflows and the practices and the scaffolding that you use when you create something, and I think that if you look historically, it always been like that. If you look at the big advances on a technology or a domain, you know, they always tend to occur when there's a new technology, when there's a new pattern, when there's a new idea, when there's a new approach, because that's where innovation occurs, and innovation is driven by the individuals that happen to be in that intersection, that happen to be that moment where a piano was a musical instrument was created, right? That you know spout a whole bunch of innovation, or a moment where a particular technology, from microprocessors to cloud, now AI, like there's always this, I think, correlation. But I think that the bit that sometimes gets missed is that, and again, historically, I believe this is the case because I remember somebody asking Ryan May, "Why did he create his own guitar? And he basically said, "Well, why don't others do? Because in the past, the craftsman would create his own tools, and that's how it used to be, right? And and I think this is the this is this has always been my approach. So my approach is because I come from a programming background, because I can do the technology, I've always have this very interesting intersection where I'm never just a user, right? I'm never just a passive consumer of technology, which is kind of the key concept I'm saying here, right? I'm not a passive consumer. I create the environment that allows me to be productive or to achieve what I'm trying to achieve creatively, programmatically, business, etc. and I think that's in essence what the making a book is. Because if you think, if you really look at it, right, the the key approach to making a book is that I'm not using Gen AI just to write some some some words, right? Which is what a lot of people use. I'm not just using it just to have a conversation like we're having right now, just to have a debate, just to have a kind of a bit, you know, almost like a little incremental improvement on on something. I'm actually leveraging Gen AI technology, especially the ability to write code, the ability to create things, the ability to reason, the ability to push back, the ability to have conversations like we have even just right now, the ability to have these hyper productive sort of workflows That was not possible before, right? And I think what, for me, the real big power of Gen AI, and I think which is why I feel that we need to experiment with the naming of the book because I think this also comes around to that, is the big power for me of Gen AI is that it really enables this feedback loops, right? Enables the creation of these environments that. These environments that we never had before. So, and this is what I think is the real story. So again, again, the second stories and the third stories, which I talked before, you know, like the the really interesting story of making a book, right, is the the workflow, and that's why when you talk about, and this is what I want to really capture on this memo next, is when you talk about the audience for the book. I think you do have two audiences, which is the audience that want to consume the tools. Because remember that everything we're doing here is open source, right? Eventually, everything may even become a service, right? But everything that is published, every single technique, everything in the book, the whole history, but not just the whole history, the whole of technology, is open source. Which basically means that we do need to have pages on the side that, again, are designed for agents to to be able to consume it, right, and to be able to process it, right, and and I think that that's the the key one of the key concepts here, right? One of the key concepts here is this idea that you know you can create your own tools. So we have one audience that just wants to consume the stuff, and the other audience that is more of a programmer who can do something about it? But again, the the the although, and I think this is important to clarify, right? Like, there's a lot of decisions and there's a lot of requests that I do that I can only do because I'm a programmer, right? I can only do because I have deep knowledge of programming of language, and yes, although I'm not writing the code, I'm having a lot of influence on the code that has been written, right? And I think that's very important concept. So I don't think it's realistic to say that somebody without programming experience could provide the prompts and the requests that I have because you need some experience. Which is the same way that I'm sure that a more sort of knowledge editor and book editor and and author will be able to create much better flows than I have, right? Because again, I'm I'm learning here, right? So, but the key concept I have here is is this ability to create the tools that make you productive, which is sort of like you you are not a passive consumer of technology. You create the tools in a way. My view is always like you create the tools until they're becoming invisible. And in the worldly maps mode, is you you are always productizing everything you do, and eventually they become a product or a commodity that you just use. So suddenly you you start not seeing it anymore because it's just there, right? And and then you you leverage. Then you start using it to the next level. Then you start, you know, taking it to, you know, evolve because suddenly that becomes part of your workflow, which is also the bit becomes interesting because that's where it means it now needs to be maintained, it needs to be productized, it needs to be supported, which is why a lot of people they think that you can just wipe code your way out of this. No, you can't. You still need really good engineering, which is also why we, you know, every now and then do spend some time here just, you know, refactoring things to make sure that we still have a very strong engineering ground, right? But but that's the concept. So now, if you go back all of this to say, when we go back to the book, I think that one of the first parts of the book should actually be about talking about the features that we have in our book publishing workflow, comparing them in a weird way to the normal book publishing workflow, which is when you compare, you know, is based usually based on a word document, is highly inefficient, takes lots of time. Making changes are very hard, right? You you end up in this sort of like position where a lot of ideas sometimes get locked sooner rather than later, and then you can't really change, or it becomes a really painful exercise. And in fact, I can show you what happens when you don't have these workflows, which is my lean per books. If you look at the books I publish, I think most of them have I never finished because I got to that sort of 60 70% of the content, and then the overhead of making changes. I actually remember having some of the books where I had tonnes of notes made, but it was almost like I didn't have the time, and not just the time. I didn't have the ability to keep it consistent, and that's important, right? Like going back to our refactoring concept, right? It's it's super critical to take into account that when refactoring and making changes in this case to a book is not just about making change. It's about keeping the book consistent and having the book with a common voice and having the book being sort of a unit in itself, right? And and that's very hard, and and that's why I guess the key concept I'm pushing here is that the the way you create the product, the way you create, in this case, the book, is part of the story. And so, so the question then becomes to the reader of the book is, a do you have the skills to keep changing your workflow, customise your workflow, and B, do you have access to somebody who can help you? Are you a pay or part of a company who has the skills and the capabilities? Because you know that's also how somebody is going to move and adopt these principles, where they can look at the body of the the capabilities that we have and say, yes, I'm going to start with this. I'm going to start with that. I'm going to start with this, which is sort of why I think we should show. I think the first part of the making the book should almost be a feature, but you know, and go to town on it, right? Like literally describe screenshot features and basically say, hey, here is what writing a book in 2026 looks like, and here are the tools that you have, and here's how you can think about it. And that's why the stuff that we've done in terms of breaking, for example, the book into a JSON file, where now we have a two-way conversation, you know, sorry, two-way conversion from Markdown to JSON back to Markdown, again allows us to think about refactoring different ways. The way that we think of the book in the in the five different layers, the way that we create a PDF. So we create a print PDF, and we have all. In fact, if you take a step back and look at all the technology and all the workflows and all the capabilities that we have here, you know, there's compare this then to the normal book editing process. This is pretty pretty powerful stuff, right? So we should kind of start there, and then go into those two modes of going. If you just we just want a user, here's what it is, and then and then we explain you know the kind of behind the scenes and how we got there, and then then you have the historical view, which is very important because I think the current book is really cool at providing how we got there, but I think for a lot of people we need to show what there looks like. We need to show them what is the art of the possible. Then we show how we got there because then they motivate it. Because then they go, "Oh, I want that bit. I want that bit. So cool. > > Transcribed by https://otter.ai --- ## The agent's reading Sixteen items. Item 12 is the concrete instruction; everything above it is the argument that makes it the right instruction. ### The principle 1. **You cannot separate the creator from the tools.** *"You can't distinguish the creator from the technology and the workflows and the practices and the scaffolding that you use when you create something."* This is the making-of book's thesis, stated outright for the first time. 2. **The historical claim.** Advances cluster where a new technology, pattern or idea appears, and are made by the individuals standing at that intersection. The piano; microprocessors; cloud; now AI. 3. **The craftsman's tools.** Brian May was asked why he built his own guitar and answered, in the founder's recollection, *"why don't others? Because in the past, the craftsman would create his own tools."* (The transcript renders the name as *Ryan May*.) 4. **The founder's own position, stated plainly:** *"I'm never just a user… I'm not a passive consumer. I create the environment that allows me to be productive."* 5. **What this project actually is.** Not using generative AI to write words, and not merely to converse. *"I'm actually leveraging Gen AI technology, especially the ability to write code, the ability to create things, the ability to reason, the ability to push back… hyper productive workflows that was not possible before."* And the conclusion that follows: *"the big power for me of Gen AI is that it really enables these feedback loops… the creation of these environments that we never had before."* 6. **Tools until they are invisible.** The Wardley motion applied to one's own working life: productise what you do until it is a commodity you stop noticing, then use it to reach the next level. With the cost named: *"that's where it means it now needs to be maintained, it needs to be productized, it needs to be supported, which is why a lot of people think that you can just vibe code your way out of this. No, you can't. You still need really good engineering."* (The transcript renders *vibe* as *wipe*.) ### The audiences, refined 7. **Two audiences, and the estate is open source.** One wants to consume the tools; the other is a programmer who can change them. *"Everything that is published, every single technique, everything in the book, the whole history, but not just the whole history, the whole of technology, is open source."* A service may follow. 8. **A third audience, and it is a requirement the site does not yet meet.** *"We do need to have pages on the side that are designed for agents to be able to consume it and to be able to process it."* `llms.txt` and `llms-full.txt` exist; per-capability machine surfaces do not. **This is a build instruction, not an observation.** 9. **An honest limit the founder places on his own method.** *"I don't think it's realistic to say that somebody without programming experience could provide the prompts and the requests that I have, because you need some experience."* And symmetrically: *"a more knowledgeable editor and book editor and author will be able to create much better flows than I have."* Both halves belong in the book; the first stops it overselling, the second stops it posing as finished. ### The evidence from failure 10. **The founder's own Leanpub books are the control group.** *"Most of them I never finished, because I got to that 60, 70% of the content, and then the overhead of making changes… I had tonnes of notes made, but I didn't have the ability to keep it consistent."* This is the strongest argument the book has and it is not currently in it. 11. **Refactoring a book is not editing it.** *"It's not just about making change. It's about keeping the book consistent and having the book with a common voice and having the book being sort of a unit in itself."* Consistency, not speed, is what the machinery actually buys. ### The instruction 12. **The first part of the book becomes the features.** *"The first part of the making the book should almost be a feature[s section], and go to town on it — literally describe, screenshot features, and basically say: here is what writing a book in 2026 looks like, and here are the tools that you have."* Compared throughout against the ordinary process: a Word document, slow, changes expensive, ideas locked early. 13. **The order changes, and the reason is motivation.** *"The current book is really cool at providing how we got there, but for a lot of people we need to show what THERE looks like. We need to show them what is the art of the possible. Then we show how we got there, because then they're motivated."* **Art of the possible first, history second.** 14. **Then the two modes**: *"if you just want a user, here's what it is"*, then the behind the scenes, then the historical view. 15. **Named capabilities to show**: the two-way conversion of a book between markdown and JSON and back, the book as five layers, the print PDF. The agent has verified the machinery behind the first: `gen_coregraph.py` decomposes a document to sections, blocks, sentences and words and reports **`rebuild byte-identical`** on every run. 16. **This bears on the title.** *"Which is why I feel that we need to experiment with the naming of the book, because I think this also comes around to that."* The naming question is at stage 5 of 7, and this memo shifts it: a book whose first part is *what is possible now* is a different promise from a book that is only a chronicle. ## What this settles, and what it opens **Settled:** the making-of book gets a **revision**, not just a rename. The editor's question at stage 5 was *"A or C — is the next edition a rename or a revision?"* and this memo answers **revision**, and specifies its shape. **Opened:** three things, and the first is the biggest. - **Nobody has counted what the estate can actually do.** Part one is a feature tour, and a feature tour written from memory would break every rule this project has. The inventory has to be built and measured before the chapter can be written. It is in [the capability register](../dev-pack/features-00-the-capability-register.html). - **Agent-facing pages per capability** (item 8) are a build, not a chapter. - **The Leanpub failure story** (item 10) is the founder's own and cannot be written from the repository. It needs him, or his permission to characterise it.