Your Applied AI

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?

The easy use is the steamroller’s road

Before what to build, where to stand.

Chapter 2 defined the steamroller as the process that turns codified knowledge into a commodity, and warned against holding a position whose value is the codified part. That warning applies to how you use AI as much as to what you are paid for.

Consider the uses of AI that are easy. Summarize this. Draft that. Write the boilerplate. Answer the question anyone could ask. They are easy because they need little from you beyond the request, and for exactly that reason they are easy to copy. Other users with access to comparable model capability can ask for the same generic operation. As models improve, those generic uses improve for everyone who has access to them. Their advantage can be real, but it is easy to diffuse. That is not a durable position. It is the road surface.

Chapter 8 asked where the finished projects are. The prediction this chapter makes is not that finished projects can arrive only in one form. It is that an important class will be integrations: AI and one person’s work rearranged around each other, in shapes a generic product would not choose. The difficulty is part of the value because the integration depends on things only you can supply — the work you care about enough to define carefully, the judgment about what good looks like in it, the records only your work produces, the checks you trust, and the authority over what may change. Those are Chapter 2’s four jobs, applied to your own tools.

Chapter 9 supplies one plausible mechanism behind that prediction. A generic assistant brings a shared prior: an extremely capable sense of what work like yours usually looks like. Where your work is conventional, that prior is a gift. Where it is not, the same prior can pull it back toward the typical answer. Chapter 9 did not measure convergence in software teams; it argued that shared model priors can reduce independence as well as coordination cost. An application that is yours changes what the model is working from:

generic assistant      shared prior

your applied AI        shared prior
                         + your history
                         + your exceptions and rejected alternatives
                         + your local conventions
                         + your measurements and evidence

So building your own is not merely customization. It is partly how you keep what makes your work non-generic from being quietly averaged away. The generic model supplies broadly useful convention. Your runtime preserves the exceptions.

The practical rule is blunt. If a use of AI is easy for you, it is easy for everyone, and it is where the steamroller is heading. The ground that does not flatten is an application that is yours: built around the work you find most worth doing, shaped by your judgment, fed by your records, checked by your checks. Do not dabble at the edge of it. Pick the work you care about most and go all the way.

In Chapter 2’s terms this is a predicted claim, the weakest kind in the book, and its weaknesses are named near the end of this chapter. It is also the claim this book was written to act on.

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 a capability, and a low 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 has long been described. 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 still depended on someone who could build the software: Shirky’s examples were made by students at ITP, and Sloan built his family app himself. That leaves a practical barrier for people who cannot program or cannot justify the time. AI-assisted construction may lower that barrier; this chapter’s evidence does not measure by how much.

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 neighborhood 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 automatically 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 while building where it helps discovery or construction. In the finished tool, keep specified operations deterministic and keep model calls where proposing, interpreting, or exploring actually earns their cost. A frontier call on every use can be justified when every use needs that cognition; it is waste when a cheaper mechanism passes the required check.

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. AI-generated code can help; 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. A musician’s instrument is the same: set up over years by the person who plays it, until it is part of how they play. Software can start to behave like that — less an appliance you operate than an extension of how you work. 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 AI-assisted construction may have lowered the threshold enough to make personal tools worth attempting, and that the process built in this book gives those attempts explicit state, authority, verification and evidence. It does not make them safe in general.

Where this argument is weakest

A chapter that tells you to go all the way owes you the reasons it might be wrong.

The evidence is thin. The case for the economic 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.

Personalization may be flattened too. Assistants are adding memory, preferences and custom instructions, and adapting to a user may itself become a commodity feature. If it does, what stays yours is not the fact of adaptation but its content: your intent, your records, your checks and your authority over change. That is why this book put them in a runtime you own rather than in a provider’s settings page.

Not everyone can make the attempt. Construction is cheaper, not free. Even a small tool takes time, some skill and continued attention, and Chapter 2’s composition problem applies here too. “Go all the way” is advice for someone who can afford the attempt, and the people most exposed to the steamroller are often the ones with the least room to try.

Maintenance is now yours. 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.

Personal tools live inside shared work. Teams need shared contracts, shared records and software other people can read. Situated software is short-lived and hard to hand over; Shirky said so in 2004, and it is still true. A personal tool must meet shared interfaces rather than replace them.

Do this now

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

1. Write one sentence naming the work you find most worth doing — the thing you would keep doing even if nobody asked, and where your judgment is what makes it good. That is where to build.
2. Look back over the last two weeks of your AI conversations about that work. List ten requests you made more than once, in the same shape.
3. 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. Then strike out any stable request that anyone with the same subscription would make in the same words — that one is the steamroller’s road, not yours.
4. Pick one stable request that survives. 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.
5. 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 deterministic rules deterministic. Use a model where proposing,
  interpreting, or exploring adds value that a deterministic mechanism does not,
  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

• Using AI only the way everyone else does. The easy uses are available to everyone at the same quality, and improve for everyone at once. They are the steamroller’s road.
• 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.
• Rebuilding the chat window with a bill. A personal tool that calls a frontier model on every use without showing that the call earns its cost has added a permanent variable expense without establishing that the intelligence is needed.
• Letting the assistant adapt your tools unasked. Proposing is its job; authorizing is yours. An assistant that changes your tools without asking is an unreviewed effect with write access to your working environment.
• 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.
• If a use of AI is easy for you, it is easy for everyone, and it is on the steamroller’s road (Chapter 2). The finished projects Chapter 8 could not find are most likely to be integrations of AI with one person’s work, and the defensible position is an application that is yours — a predicted claim, held as such. Part of why: a generic assistant works from a shared prior that can pull exceptional work toward convention (Chapter 9), and your own runtime is where the exceptions are kept.
• 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 today’s wave of AI-assisted coding tools; this chapter argues that lower construction cost can make that niche easier to attempt.
• 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, and personalization itself may become a commodity — which is why the durable part is the intent, records, checks and authority you own.

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.

The steamroller will keep getting faster, and it will flatten everything that is the same for everyone. Stand somewhere it cannot: in work that is yours, with tools built around it.

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.