Part 6 — Put Intelligence Into the Process

You will still open the chat window tomorrow

You have read a book about getting AI out of the chat box. Tomorrow morning you will type something into one.

That is not a contradiction, and it is worth saying why before anything else. Conversation is the most direct way a person has to say what they want. Typing or talking to a model will stay part of how you work for as long as intent has to come from somewhere, and intent comes from you.

What this book moved out of the chat box was never the conversation. It was the process around it: which context the model saw, what came back before anyone interpreted it, what was claimed and what supported the claim, who was allowed to change what, whether the change happened, and whether the work was done. In a chat window you carry all of that in your head. In the preceding twenty-nine chapters it moved into software you can inspect.

Something else happened while this software was being built. Most of it was constructed with an AI assistant, one bounded increment at a time, under the discipline this book describes. It was not selected from a catalogue or configured from a generic product. It grew around a particular way of working, one missing capability at a time.

For most of the history of software, that would have been an absurd way for one person to get a tool. Building software was expensive enough that applications had to justify themselves across teams, companies, or markets. Increasingly, that constraint is weakening. Software can be built around a particular person, a particular workflow, or even a particular recurring frustration.

That is a different kind of software.

When software can be built around one person, what should that person build — and how does it keep getting better without losing the discipline that made it trustworthy?

Why software was built for everyone else

Chapter 6 stated the economic fact that shaped the last forty years of software: a high fixed cost to build, and a near-zero cost to serve one more user. That fact did more than make software a good business. It decided what kind of software got built.

If building is expensive and serving is cheap, you build once for as many people as possible. You look for the requirements they share. You add settings for the ways they differ. Word processors, spreadsheets, issue trackers and editors are the result: impressive, general, and designed for nobody in particular. Each user then does the remaining work — learning where things are, bending their habits to the tool’s model of the job, and living with the parts that do not fit.

The alternative was always known. In 2004 Clay Shirky described situated software, “designed in and for a particular social situation or context”, written for a group he could name rather than for an unknown market (Shirky, 2004). He argued it was becoming viable as tools and hardware got cheaper, and he was candid about the price: such software is small, short-lived and hard to move elsewhere. In 2020 Robin Sloan wrote about a messaging app he built for exactly four people — his parents, his sister and himself — and argued that code written for the people you love is closer to cooking a meal than to shipping a product. Freed from having to be professional and scalable, he wrote, programming “becomes a different activity altogether” (Sloan, 2020).

Neither idea needed AI. Both ran into the same wall: building something useful for a handful of people still took a programmer’s time, and most people are not programmers, and most programmers do not have the time.

What changed is the price of construction, not the need for engineering

That wall is moving. Not everywhere, and not as fast as the loudest claims suggest, but far enough to change what is sensible to attempt.

The honest evidence is thinner than the enthusiasm. This book’s own construction is one case: a runtime with a ledger, context compiler, claims, authority, verification, experiments and a routing ladder, built largely by directing an assistant through bounded, checked increments. It is a single author’s case, not a measurement of anyone else’s productivity. Practitioners report the same shift in their own terms. One developer building neighbourhood services — street-sweeping and hail alerts for a single metro area — wrote that before decent LLM harnesses they would have been prohibitively expensive in time and resources, and that they now expect to sustain them by covering hosting and token costs (Ask HN, September 2026). That is a self-report, useful as a signal and nothing more.

Two earlier chapters bound what that shift means.

Code was never the whole cost. Chapter 8’s arithmetic still applies: if writing code is a fraction of what a tool costs over its life, making that fraction nearly free leaves the rest untouched. Deciding what the tool is for, checking that it does it, and keeping it working when the world around it changes are not accelerated by a faster typist. They are the four jobs of Chapter 2 — intent, authority, verification and frontier judgment — applied to your own environment instead of to someone else’s product.

Spend intelligence on construction, not on every use. Chapter 6’s rule matters more for personal tools than for products, because you pay the running cost yourself. Use a strong model freely while building. Keep the finished tool mostly deterministic, and keep model calls where the input genuinely cannot be enumerated. A tool that calls a frontier model every time you open it has rebuilt the chat window with extra steps and a bill.

There is also a warning from the people who have thought longest about adaptable software. Geoffrey Litt and colleagues at Ink & Switch define malleable software as an ecosystem where anyone can adapt their tools with minimal friction, where “modification becomes routine, not exceptional” (Litt et al., 2025). They argue that AI code generation alone does not get there: it helps you write a new tool, but it does not make existing applications open to change, make separate tools share data, or give you control without programming. Their image is a talented sous chef dropped into a food court. That is the right caution. Generated code is necessary; it is not sufficient.

The interface is yours; the model inside it is not

The idea is older than any of these tools. In 1960 J. C. R. Licklider proposed that people and computers should be “coupled together very tightly”, with the machine helping a person think through problems that were not yet formulated, not only compute answers to ones that were (Licklider, 1960). Two years later Douglas Engelbart framed augmenting human intellect as raising a person’s capability to understand a complex situation and reach solutions suited to their particular needs. He treated the person, their artifacts, their language, their methods and their training as one system, in which a change to any part can reorganize the rest (Engelbart, 1962).

Read that against what this book built. The mapping is the book’s, not Engelbart’s, but it fits closely:

The top three rows are the interface between you and everything digital you work with. The bottom row is replaceable by design. That is why the book spent so much effort keeping the model to one slot: not because the model is unimportant, but because the part you own should not depend on which model occupies that slot this quarter.

This is also the most useful way to hear the claim that AI is becoming the interface to technology. Treated as a single product, that claim hands the interface to whoever sells the model. Treated as layers, it hands the interface to you: your context rules, your records, your checks, your authority, your tools, with a model you can swap underneath.

Tools that accumulate

Here is how this tends to happen. It is a constructed illustration, not a measured case, and it will look different for everyone.

You notice you have asked a model the same kind of question many times: check this chapter’s citations against the style you use; pull the three sources you always want for this kind of task; draft the weekly summary from the same five places. Each time you re-explain the rules. Each time you check the answer the same way.

The first time you stop and build a small tool for one of these, the chat window does not go away. It becomes the place where you describe the tool, and later the place where you ask for changes to it. The tool holds the part that should not be re-explained: the rules, the sources, the definition of good, the check.

Then there is a second tool, and a third. They start to share things: the same sources, the same record of what was checked, the same notion of which changes need your approval. Without anyone deciding it, a small runtime appears underneath them — the thing Chapter 9 described as one durable process with many windows. The windows are no longer generic. They are shaped around how you actually work.

A carpenter’s bench after twenty years does not look like the one in the catalogue. The jigs exist for the cuts that carpenter makes often; the tools hang where that carpenter reaches; the things never used have gone. Software can start to behave like that. The progression is roughly:

generic software  →  configured software  →  custom software
        →  software built around you  →  software that improves through use

The last step is the one that needs care.

Adapting the software without losing the process

The tempting version is an assistant that watches you and quietly rewrites your tools. Almost everything in this book argues against that version. A change nobody authorized, that nobody checked, recorded nowhere, is exactly the kind of effect Chapters 16 through 22 were built to prevent.

The better version turns the book’s own architecture onto the software itself:

    flowchart TD
    A["Use the tool"] --> B["Notice friction"]
    B --> C["Record evidence"]
    C --> D["Define intended improvement"]

    subgraph S["STOCHASTIC SLOT"]
        E["AI proposes adaptation"]
    end

    D --> E
    E --> F["Evaluate against intent + evidence"]
    F --> G{"Authorize?"}

    G -->|No| H["Reject / revise"]
    H --> A

    G -->|Yes| I["Apply bounded change"]
    I --> J["Verify resulting state"]
    J --> K["Measure outcome"]
    K --> L{"Keep?"}

    L -->|No| M["Revert"]
    M --> C

    L -->|Yes| N["Preserve new version"]
    N --> A
  

Every step already has a chapter.

• Notice friction. Record it, instead of remembering it. The working state of Chapter 16 is where “this keeps going wrong” becomes a fact a later session can find.
• Propose a change. This is where the model is genuinely useful: suggesting the new rule, the extra source, the missing check. If you want several options, collect them blind first (Chapter 23).
• Evaluate it. A proposal is a claim — “this will make the weekly summary better”. Chapter 18 separates what was said from what supports it.
• Authorize it. The assistant can propose how your software should change. Applying the change is an authorization, and authorization is yours (Chapter 20).
• Verify it. Check the changed tool against the state it now has, not the state it had before (Chapter 21).
• Measure it, then keep or revert. A change that felt better may not be. Part 5 spent five chapters on how to tell, including one where the promising idea did not survive a fair comparison (Chapter 27). Keep the old version recorded, so reverting is a decision, not an archaeology project (Chapter 17).

Two rules from earlier chapters keep this from becoming endless. Chapter 8 warned that cheap capacity gets spent on scope rather than arrival; with personal tools nobody else has to agree to the scope, so the pressure is stronger. Write down what each change is for before making it, and keep it only if it did what you wrote. And Chapter 10’s split still holds: finish the frame you own, and let the model slot keep changing underneath it.

The goal is not software that behaves exactly as you currently behave. Some of your habits are bad habits, and encoding them makes them harder to see. The goal is an increasingly effective interface between what you intend and what happens.

Why there is no demonstration here

Every other construction chapter in this book ended with a run you could inspect. This one does not, deliberately.

The parts of this argument that generalize — preserved observations, explicit context, claims with evidence, authority separate from capability, bound verification, measured promotion, a replaceable model — have been built and tested in the chapters before this one. What does not generalize is the application. A demonstration here would show one person’s tool, and a reader would reasonably take it as the shape theirs should have. It should not have that shape. Yours should have the shape of your work.

That makes this an argument chapter, and its claims are bounded accordingly. It does not show that software built around a person outperforms generic software. It does not measure how much cheaper construction has become. It argues that the economics have moved enough to make personal tools worth attempting, and that the process built in this book is what makes attempting them safe.

Where this goes wrong

• Encoding habit instead of intent. A tool that faithfully reproduces how you work today also reproduces what you do badly, and makes it harder to notice.
• Scope without an end. Nobody else has to approve the next feature. Unwritten purposes become permanent maintenance.
• Maintenance you now own. Models drift, APIs change and dependencies age (Chapters 10 and 12). A tool built around you breaks around you too, and there is no vendor to call.
• One user inside shared work. Teams need shared contracts, shared records and software other people can read. A personal tool must meet those interfaces rather than replace them.
• Adaptation that authorizes itself. The moment an assistant can change your tools without asking, you have an unreviewed effect with write access to your working environment.
• Tools nobody else can use. Situated software is short-lived and hard to hand over; Shirky said so in 2004, and it is still true.
• Thin evidence. The case for this shift rests on an author’s own construction and on practitioners’ self-reports. That is enough to act on carefully, not enough to promise results.

Do this now

Thirty minutes. Find the first tool worth building around your own work.

1. Look back over the last two weeks of your AI conversations. List ten requests you made more than once, in the same shape.
2. Mark each one. Stable: the rules, sources or definition of good are the same every time. Open: each instance is genuinely new. Open requests stay in the chat window.
3. Pick one stable request. Write four lines: what done means, what the tool may change, how you would check its output, and how you would undo a change to it.
4. Ask your assistant to build the smallest version that meets those four lines. Use it for a week. Each time it annoys you, write one sentence down — that list is the input to the adaptation loop, not a to-do list to clear at once.

If you are building with an assistant:

Help me build a small personal tool for a task I repeat.
- Start from my written definition of done, what the tool may change, how its
  output is checked, and how a change to the tool is undone. Ask if any is
  missing; do not invent them.
- Keep the tool mostly deterministic. Use a model only where the input cannot
  be enumerated, and record which model answered and what it returned.
- Record every run: inputs, outputs, check result.
- When I report friction, propose one change at a time, state what it is for
  and how we will know it helped, and wait for my approval before applying it.
- After a change, run the checks against the changed tool, keep the previous
  version, and tell me plainly if the change did not help.

Failure modes

• Rebuilding the chat window with a bill. A personal tool that calls a frontier model on every use has kept the cost and lost the conversation.
• Automating a habit you should have dropped. Faithful is not the same as good.
• Letting the assistant adapt your tools unasked. Proposing is its job; authorizing is yours.
• Keeping changes because they felt better. Measure, or revert.
• Owning the model instead of the interface. The durable asset is your context, records, checks and policies; the model will change.
• Building for one person inside work shared by many. Personal tools must still meet shared contracts.

What this chapter established

• The chat window stays: conversation remains the most direct way to express intent. What leaves the chat box is the process, and once it leaves it can be shaped around one person’s work.
• Software was built for average users because construction was expensive and serving was cheap. Situated software (Shirky, 2004) and home-cooked apps (Sloan, 2020) described the alternative long before AI made construction cheaper.
• Cheaper construction does not remove intent, verification or maintenance (Chapters 2, 6 and 8), and AI code generation alone does not make software malleable (Litt et al., 2025).
• The interface between a person and technology can be owned: conversation, tools and runtime are yours, and the model inside is replaceable — a reading of Licklider’s symbiosis and Engelbart’s augmentation that is the book’s own (Licklider, 1960; Engelbart, 1962).
• Software that improves through use should adapt through the book’s own loop — friction recorded, change proposed, authorized, verified, measured, kept or reverted — never by rewriting itself unasked.
• No demonstration is offered, deliberately. The contracts that generalize were built earlier; the application is the reader’s. The evidence for the economic shift is an author’s case and practitioners’ self-reports.

Next

This book set out to make intelligence a dependable participant in a process, and it ends with the process in your hands.

What it does not cover is the larger change behind this chapter: people, their AI and their software developing together, each changing what the others can do. That is the subject of a planned companion book, Level Up Your AI.

Applied AI begins where the chat box ends. Your applied AI begins with the next thing you decide to build.

References

• J. C. R. Licklider. Man-Computer Symbiosis. IRE Transactions on Human Factors in Electronics, HFE-1, March 1960. https://groups.csail.mit.edu/medg/people/psz/Licklider.html
• Douglas C. Engelbart. Augmenting Human Intellect: A Conceptual Framework. SRI Summary Report AFOSR-3223, October 1962. https://www.dougengelbart.org/content/view/138
• Clay Shirky. Situated Software. March 30, 2004. https://www.gwern.net/doc/technology/2004-03-30-shirky-situatedsoftware.html
• Robin Sloan. An app can be a home-cooked meal. February 2020. https://www.robinsloan.com/notes/home-cooked-app/
• Geoffrey Litt, Josh Horowitz, Peter van Hardenberg, and Todd Matthews. Malleable Software: Restoring User Agency in a World of Locked-Down Apps. Ink & Switch, June 2025. https://www.inkandswitch.com/essay/malleable-software/
• Arubis. Comment in Ask HN: What are you working on? (September 2026). Hacker News, comment 49687023. https://news.ycombinator.com/item?id=49687023 — practitioner self-report, used as a signal only.