Você não pode selecionar mais de 25 tópicos Os tópicos devem começar com uma letra ou um número, podem incluir traços ('-') e podem ter até 35 caracteres.

4.2KB

FOCUS Architecture — Chapter-22: Architecture for humans and for models

  • Source: /library/FOCUS Architecture/source-file.pdf
  • PDF pages: 677–679
  • Pages without text: none

Architecture for humans and for models Monday morning, somebody’s first day on the team. They clone the repository, open the editor, and ask the most ordinary question there is: where does the discount rule live? What happens over the next twenty minutes says more about that project’s architecture than any diagram hanging on the wall. Hold on to that scene, because it repeats several times a day with a different reader. When you hand a task to an assistant and it starts working, the first thing that happens on the other side is the same question, with one difference that changes everything: it can’t get up and walk over to the colleague at the next desk. Whatever it manages to retrieve on its own is all it gets. The pattern nobody designed on purpose The last few chapters answered that question five times over, each one without knowing about the others. Chapter 11 said the slice has to fit whole in the context window: to change a business capability, one folder is enough. Chapter 14 put the rule in a single file, with the signature declaring everything it consumes: to know what the policy decides, the use case is enough. Chapter 15 drew the point where reading can stop without owing anything, and promised that point stays put after the database changes. Chapter 9 concentrated in one file the

answer to “which concrete implementations does this program use?” Chapter 10 compressed the whole book into a page that keeps what decides. Five decisions, five retrieval questions, and not one of them was made with a language model in mind. The axis of change dates to the 1970s. The composition root predates any coding assistant. The single page exists because a tired reader doesn’t reread a chapter. What changed wasn’t the design: it was how many readers depend on it per day. The name for this AI-friendly architecture is the design that treats the cost of retrieving context as a design criterion, alongside the criteria the discipline already had. It isn’t a technique you install in a project. It’s the sum of the eight concepts that came into the previous chapters, each one in the place where the idea was already needed for another reason. Here’s my position, with no middle ground. AI-friendly architecture is not architecture made for AI. Not one line of this book asks you to write worse for people on the generator’s behalf, and the day those two readings genuinely conflict, the human one wins, because that’s the reader who answers for the system at three in the morning. What happened is more modest and more useful: a second reason showed up, a measurable one, for the same choices we already defended on readability grounds. Whoever was measuring the cost of change now measures the cost of retrieval too, and both accounts point the same way. It’s worth saying what this doesn’t promise. Good architecture doesn’t fix a bad prompt, doesn’t replace review, and doesn’t stop a model from inventing a rule nobody asked for. It does one

thing, and does it well: it shrinks what has to be loaded in order to decide, whoever is doing the deciding. The question left over Notice what stayed outside. This book organizes the repository, and organizing the repository determines what exists to be retrieved. The other half is left: given one specific task, who picks what goes into that call’s window, in what order, and at what cost? A well-drawn slice makes the choice possible; it doesn’t make the choice. That’s another book’s question, and the book exists. Context Engineering (2026, https://books.kodel.com.br/en/books/context-engineering) is about deliberately assembling the information that reaches the model on each call, and you don’t need it to finish this one, the same way you didn’t need the first volume to get to this page. The bridge is on the record, and nothing more. What’s missing is the part where the arguing stops. Turn the page: chapter 22 builds the whole app, slice by slice, with everything Part III promised.

Powered by TurnKey Linux.