Applied AI on AIBussin — AI applications, systems and books

Beyond the Chat Box

Mon, 14 Sep 2026 05:00:01 +0100

Part 1 — Where You Stand

Before any of this can be built, it is worth being exact about where you are standing. Intelligence is no longer the scarce component. What is scarce is everything around it: deciding which work should never be stochastic, knowing what a model call costs, noticing that a person’s review decays as the model improves, and measuring a system whose output changes between runs.

These eight chapters make that case: the position a commodity technology erodes, the rule that keeps deterministic work deterministic, where this era’s training data came from, why human review becomes a rubber stamp, what intelligence actually costs, how to measure a stochastic system, and why projects still are not finishing.

Never Stand in Front of the Steamroller

Mon, 14 Sep 2026 05:00:02 +0100

Part 1 — Where You Stand

The plain version

The historical premise of this chapter is not controversial: machines have displaced codified parts of skilled work before. The inference for AI — which parts are now exposed, how fast the boundary moves, and where durable human responsibility remains — is the claim this chapter has to earn.

“Computer” was a job title before it was a machine: rooms of people did calculations by hand for engineers, observatories and space programs. Typesetters set newspapers line by line, first by hand and later on hot-metal machines, until photocomposition and then desktop publishing took the trade. Keypunch operators turned programs and data into stacks of punched cards. Typing pools produced every letter an office sent. Each of those was skilled work, done by people who were good at it and some who were superb. None of that skill protected the job once a machine could do the codified part.

If There's Any Doubt, It's Deterministic

Mon, 14 Sep 2026 05:00:03 +0100

Part 1 — Where You Stand

Seven operations, one of them intelligent

Take the paragraph review from Chapter 1 and write down everything the process actually has to do. Not the prompt — the process.

Select the paragraph to review.
Decide whether it has changed since the last review.
Decide whether there is budget left for a call.
Identify claims in the paragraph that need supporting evidence.
Extract the flagged sentence and its position.
Check that a cited source resolves and that its year matches the bibliography.
Decide whether to write the change to the file.

Six of those have exactly one correct answer, computable without a model. Selection is an index lookup and change detection is a hash comparison. Budget is arithmetic; extraction is parsing. Source checking resolves the request and compares it against the bibliography. The write decision evaluates policy.

Scrum Built the Training Set

Mon, 14 Sep 2026 05:00:04 +0100

Part 1 — Where You Stand

Why checkable work became unusually favorable terrain

An uncomfortable piece of bookkeeping

Software engineering became an unusually fertile early target for language-model automation. The usual explanation is that code is logical and therefore tractable for a machine.

That explanation points at only part of what made software favorable. The account this chapter defends is about the surrounding work records and checks.

Over decades, software teams increasingly worked through issue trackers, version control, code review, automated tests, and iterative planning methods. Not every team used Scrum, and none of these practices guarantees the others, but together they often left behind unusually structured records:

Meat Proxy

Mon, 14 Sep 2026 05:00:05 +0100

Part 1 — Where You Stand

Review degrades because the system succeeds

Ten weeks

Week one, the model drafts a paragraph review and you read every line of it. You disagree with two of its four flags, check a source yourself, rewrite one sentence. The whole thing takes twenty minutes and you feel you have earned the output.

Week three, the reviews have been good. You read them properly but you stop re-checking the sources it says it checked. Nothing bad happens.

The Price of Intelligence

Mon, 14 Sep 2026 05:00:06 +0100

Part 1 — Where You Stand

The invoice nobody runs at prototype time

The paragraph review from Chapter 1 costs about 1,200 tokens in and 400 out. At prototype scale that is a rounding error, and it is why nobody computes the next four numbers.

A manuscript has 3,000 paragraphs. That is one full pass.

The review is not run once. Every edit invalidates the review of the paragraph it touched, and a careful author edits most paragraphs four or five times.

Intelligence in the Wrong Direction

Mon, 14 Sep 2026 05:00:07 +0100

Part 1 — Where You Stand

Capability without an objective is magnitude without direction

The thing the marketing does not cover

Every vendor will sell you more capability. None of them can tell you whether that capability moves your process toward its objective without a measurement you supply.

A stronger model can execute the wrong objective more effectively just as it can execute the right one more effectively. Capability alone does not tell you whether the gap between what you wanted and what you got narrowed or widened. That is an empirical question.

Where Are the Finished Projects?

Mon, 14 Sep 2026 05:00:08 +0100

Part 1 — Where You Stand

The tireless coworker

Imagine you are given a colleague with the properties the industry has been describing for nearly four years.

They never tire. They work through the night and the weekend. They have read essentially everything and can recall it instantly. They write code faster than you can read it, and they will take on the tedious parts you have been avoiding since March.

One Runtime, Many Windows

Mon, 14 Sep 2026 05:00:09 +0100

Part 2 — Get the Model Out of the Chat Box

A chat window is an interface with a person inside the loop doing the integration. This part takes the process out of it and gives the work somewhere else to live.

That happens in stages. The work needs a durable identity and a record that survives the interface closing. The model underneath has to be replaceable, because it will be replaced. A model call has to become a recorded process event rather than a string. That call then has to survive a change of provider dialect, its usage numbers have to mean something before anyone does arithmetic on them, and finally a successful call has to stop being mistaken for finished work.

A Revolver, Not a Foundation

Mon, 14 Sep 2026 05:00:10 +0100

Part 2 — Get the Model Out of the Chat Box

The model will change; the frame should survive it

The book you could write better next year

Write a book with AI this year and you will be able to write the same book better next year. And better again the year after. The same is true of the code, the research synthesis, the review process, the classifier — anything where a model does part of the work.

The Smallest Useful Model Call

Mon, 14 Sep 2026 05:00:11 +0100

Part 2 — Get the Model Out of the Chat Box

The smallest working call

CodeAI’s OpenCode cognition adapter, invoked directly without the recorded-call runtime, does the minimum well. Chapter 1 reached it through prompt(), which builds the CallSpec for you. Underneath, one CallSpec becomes one user message, the message goes out as an ordinary HTTP request, and a CallResult comes back:

adapter = OpenCodeCognitionAdapter(model="mimo-v2.5", protocol="chat_completions")
result = adapter.invoke(spec) # one CallSpec in, one CallResult back
if result.status != "succeeded":
 raise RuntimeError(result.error)
review = result.raw_output

It keeps failure in its own channel instead of passing a diagnostic off as a review. It returns the usage with its source label alongside the convenient string. Those two habits already put it ahead of a great deal of production code.

One Operation, Several Model APIs

Mon, 14 Sep 2026 05:00:12 +0100

Part 2 — Get the Model Out of the Chat Box

Choosing a model can change the whole wire contract

Right model, wrong dialect

Chapter 11’s second live run failed with an HTTP 500. The gateway, the model, and the credential were all right. The request was shaped for OpenCode’s Responses endpoint, and mimo-v2.5 is served on Chat Completions.

That looks like a configuration slip. It is a property of the ground you are building on.

Token Counts Don't Add Up

Mon, 14 Sep 2026 05:00:13 +0100

Part 2 — Get the Model Out of the Chat Box

A field name is not a unit: normalize at the boundary

Every AI application ends up doing arithmetic on numbers a provider reported. It adds tokens into a budget, divides an invoice by them, compares two models on them, and routes work to whichever looks cheaper per token.

Those numbers arrive in fields with shared names: input_tokens, cached_tokens, reasoning_tokens. The shared names hide different rules. On one major API, cached input is counted inside input_tokens. On another, it is reported beside it. Add the two and the result is wrong even though every number in it is correct. Nothing crashes. The budget, the cost comparison and the routing decision are simply built on a sum that means nothing.

A Successful Call Is Not Finished Work

Mon, 14 Sep 2026 05:00:14 +0100

Part 2 — Get the Model Out of the Chat Box

The model is not the process

An AI pipeline gets a response back, the response looks right, and something marks the work done. That step is where many AI-enabled processes quietly lose track of the truth.

A successful model call tells you the call worked. It does not tell you that anyone checked the output against what the task required, that the thing checked is the thing being used, that someone with standing agreed, or that the agreement was written down. Collapse those into one status field and “done” starts to mean “the model returned something plausible”.

What Did the Model Actually See?

Mon, 14 Sep 2026 05:00:15 +0100

Part 3 — Give Intelligence a Runtime

A component with a contract still needs a world around it. This part builds that world out of the things that used to live in a person’s head and in the scrollback.

Each chapter makes one of them explicit and durable. What the model was allowed to see becomes a compiled, recorded input rather than an accumulated transcript. Working state becomes something another process can resume from instead of restarting blind. The provider’s response is preserved before anything interprets it, so a corrected reading can be applied later without asking the model again. Statements become claims that point at evidence, and decisions record what they relied on. Then the process is allowed to change something outside itself — and to observe the result rather than trust a report of it.

Restart Is Not Resume

Mon, 14 Sep 2026 05:00:16 +0100

Part 3 — Give Intelligence a Runtime

Externalize working memory

When an AI process dies partway through, the usual fix is to restart it and re-run whatever did not finish. For a model call, that can mean paying for the same request twice. For an agent that sends email, opens tickets, charges a card or edits files, it can mean doing something twice that cannot be undone.

The capability you actually need is a different one:

Preserve Before You Interpret

Mon, 14 Sep 2026 05:00:17 +0100

Part 3 — Give Intelligence a Runtime

Raw output first

Every rule an AI application applies to a model’s response is an interpretation. Did generation finish? Is this valid JSON? Is this a refusal? How many tokens did it cost? What does the answer actually say? Those rules can turn out to be wrong: a provider adds a field, a parser misses a case, a failure shows up that nobody anticipated.

Claims, Evidence, and Decisions

Mon, 14 Sep 2026 05:00:18 +0100

Part 3 — Give Intelligence a Runtime

What did the decision rest on?

AI output feeds decisions. A review says a setting is correct, a summary says the tests pass, an assistant says a change is safe, and someone merges. When one of those statements turns out to be wrong, asking whether the AI was wrong gets you very little. What you need to know is which statements the decision actually rested on, and what anyone had checked. Most systems cannot tell you, because the decision was recorded without its basis.

The Agent Said Done. Did Anything Change?

Mon, 14 Sep 2026 05:00:19 +0100

Part 3 — Give Intelligence a Runtime

Observe the effect, not the report

Sooner or later an AI application is allowed to change something: edit a file, update a record, send a message, merge a change. The moment it does, a new kind of mistake becomes possible. A worker reports “done”, the report is recorded as the outcome, and nobody looks at what actually changed. The report can be sincere and still wrong. The edit went to the wrong file, stopped halfway, or never happened.

Capability Is Not Authority

Mon, 14 Sep 2026 05:00:20 +0100

Part 4 — Make It Safe and Verifiable

The process can now act on the world. That is exactly when the safety questions arrive, and they are not questions a prompt can answer.

Three of them run through this part. Being able to perform an action is not being permitted to perform it, so permission has to be checked in code, outside the text a model generates. A check that passes is not proof, so verification has to be independent of the generator, adequate to the property that matters, and bound to the exact state being accepted. And trying again is not free, because a retry can cause a second real effect where a replay would have returned a record.

The Agent Cannot Grade Its Own Homework

Mon, 14 Sep 2026 05:00:21 +0100

Part 4 — Make It Safe and Verifiable

Independence, adequacy, and binding

A model saying its work is correct is not verification. Neither, on its own, is running a separate test. A test can run separately and check the wrong thing. It can check the right thing against a version of the artifact that has since changed. And a PASS that nobody can tie to the exact state being accepted is only another claim.

Retries Are Side Effects Too

Mon, 14 Sep 2026 05:00:22 +0100

Part 4 — Make It Safe and Verifiable

Retry, replay, duplicate

Retrying is the most ordinary recovery move in software, and in an AI application it is often the most dangerous one. When a call or an action fails, or only seems to, the loop tries again. If the first attempt already sent the email, charged the card, wrote the file or ran the model, the retry does it twice. A timeout says nothing about whether the far side acted.

Blind Before You Compare

Mon, 14 Sep 2026 05:00:23 +0100

Part 5 — More Intelligence Is Not Automatically Better

Once a system can produce several answers, adding more intelligence looks easy: call the model again, try another model, change the prompt, build a portfolio. None of that guarantees more useful coverage.

This part builds the comparison in stages. Proposals first have to be collected without influencing one another, because agreement after exposure means something different from agreement without it. Then variety has to be measured by what actually gets solved rather than by how many model names were involved. When the first benchmark turns out to be too easy to tell the methods apart, the test itself has to be made more discriminating. A promising signal found inside a failed experiment then has to survive a matched replication before it is allowed to change anything.

The Models Were Different. Their Mistakes Weren't

Mon, 14 Sep 2026 05:00:24 +0100

Part 5 — More Intelligence Is Not Automatically Better

Measure variety by what gets solved

Reach for a second model and the reasoning feels obvious. Different training, different weaknesses, so where one fails another may succeed. Add a third and you have a portfolio. It is an appealing story, and it is a hypothesis rather than a property of model names.

What you actually need is complementary errors: cases where one generator fails and another succeeds. Different names do not guarantee that. Models trained on overlapping data, prompted the same way, on the same task, can be wrong in the same way. When they are, a portfolio costs more and covers nothing extra.

When Your Benchmark Is Too Easy

Mon, 14 Sep 2026 05:00:25 +0100

Part 5 — More Intelligence Is Not Automatically Better

Make the problems harder

Suppose you compare two ways of using AI on your own evaluation set, and both solve eleven of twelve tasks.

Method A 11/12
Method B 11/12

The obvious reading is that the methods are equally good. There is another reading. If eleven of those tasks are easy enough that any reasonable method solves them, the comparison had almost nowhere to show a difference. Two methods can only disagree on tasks where at least one of them could fail. When nearly everything passes, the evaluation loses its power to discriminate, and “no difference observed” stops being evidence of equivalence. It may only be evidence of a ceiling.

Discovery Is Not Promotion

Mon, 14 Sep 2026 05:00:26 +0100

Part 5 — More Intelligence Is Not Automatically Better

Diversity without more models

The subgroup that almost rewrites the chapter

Start with the temptation, because the discipline only means something if the temptation is real. Inside a failed experiment sits this: one wording — counterfactual — with three draws per task covered 9 of 12 tasks. The normal wording, given three draws per task in the same portfolio, covered 7. Read quickly, that is a better prompt.

Replicate Before You Believe

Mon, 14 Sep 2026 05:00:27 +0100

Part 5 — More Intelligence Is Not Automatically Better

A signal is not a result, and a result is not a default

Somewhere in your own records there is an encouraging pattern: a prompt that seemed to work better, a model that looked stronger on the cases you happened to inspect, a setting that went with success more often than not. The temptation is to adopt it.

The problem is where the pattern came from. It was found by looking at data you already had, which means the data chose the hypothesis. Anything strong enough to notice in a small sample is also the kind of thing chance produces regularly, and hindsight makes it feel predicted rather than discovered.

What Should Happen Next?

Mon, 14 Sep 2026 05:00:28 +0100

Part 6 — Put Intelligence Into the Process

The pieces are all built. This part puts them under one policy and then joins them.

It starts with the decision that usually gets skipped: which operation does the process need next — a model call, a deterministic check, a person, or a stop? That choice comes before any question about which model, and this part measures what climbing from cheap to expensive actually bought. Then one task runs through every boundary the book has built, from intent and authority to effect, verification and acceptance, to find out whether mechanisms that each work alone still hold where they hand off to one another.

One Process, End to End

Mon, 14 Sep 2026 05:00:29 +0100

Part 6 — Put Intelligence Into the Process

Correct parts can still fail where they meet

Every mechanism in this book was tested on its own, against a fixture built for its chapter. Context was compiled and recorded. Effects were observed by the runtime rather than taken from the worker’s report — or so each component’s own test reported. Checks were bound to the state they examined. Acceptance cited its evidence. Replays refused to act twice. Each passed its own test.

Your Applied AI

Mon, 14 Sep 2026 05:00:30 +0100

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.