Codeai on Programmer.ie: Modern AI programming

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. 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

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.

OpenCode Go’s catalog, updated on 11 September 2026, lists every model on exactly one of three endpoints (OpenCode). Three of them carry this chapter:

Normalize at the Boundary

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

Part 2 — Get the Model Out of the Chat Box

Three numbers that will not add

Three calls in Chapter 12 performed the same small task, through the same gateway, and all three succeeded. One route reported 38 input tokens. Another reported 279. The third reported 73.

Put those in a spreadsheet and the next move writes itself: sum them, average them, divide the invoice by them, route to whichever chamber is “cheapest per token”. Every one of those moves assumes the three numbers measure the same thing.

The Model Is Not the Process

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

Part 2 — Get the Model Out of the Chat Box

Nothing went wrong

The task was small — repair one paragraph:

The new cache makes every page load 73% faster, according to the platform team [S1].
It stores rendered fragments close to readers.

It had three written criteria: the paragraph must contain no percentage figure, the source marker [S1] must appear exactly once, and the second sentence must survive word for word.

Context Is an Input, Not a Transcript

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

Part 3 — Give Intelligence a Runtime

The question the acceptance could not answer

Chapter 14 ended with a task that was provably complete. The acceptance cited the task’s criteria, the call, its final attempt, the interpretation, the exact artifact bytes and the checks run on them.

It did not cite what the model was shown.

Ask most systems that question and you get one of two answers. The first is “the conversation so far”: everything that happened, in the order it happened. The second is “whatever was in the prompt”: a string someone assembled and nobody recorded. Neither answer can be checked afterwards, and neither was decided on purpose.

Externalize Working Memory

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

Part 3 — Give Intelligence a Runtime

The step that didn’t finish

A process was reviewing a paragraph. It had compiled its context, recorded the call’s manifest, and sent the request. While the provider was still working on it, the process died.

The standard recovery is familiar: restart, find the step that didn’t finish, and run it again. Someone did exactly that in this chapter’s experiment, on a copy of the dead process’s files, and the step re-ran to completion.

Raw Output First

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

Part 3 — Give Intelligence a Runtime

The success that was cut off

Chapter 11’s fourth live run was recorded as a success. The provider had answered with HTTP 200 and text, and CodeAI’s interpreter at the time treated any answer with text as complete. Opening the preserved response told a different story: "finish_reason": "length". The model had used every output token it was allowed, and the review stopped mid-sentence.

Claims, Evidence, and Decisions

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

Part 3 — Give Intelligence a Runtime

Three sentences and a merge

A review of a cache change says three things:

The cache TTL is set to 60 seconds in config/cache.toml. The retry test passes.
p99 latency stays under 200 ms.

Someone reads it and merges the change. The next day, the deployed configuration turns out to say 600 seconds.

The obvious question is whether the review was wrong. The more useful question is narrower: which part of the decision rested on which sentence, and what had anyone actually checked? One sentence could be confirmed against a file. One could be tested. One had no evidence at all. The merge used two of them and knowingly left the third open, or it didn’t. The merge record lists no basis, so the basis cannot be reconstructed.

Let the Machine Touch Something

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

Part 3 — Give Intelligence a Runtime

The edit that has not happened

Constructed scene. A reviewer proposes changing a cache setting. The patch is in an artifact. A person decides to apply it. The file still contains the old value.

Then a worker returns “done” and nobody opens the file.

The decision might have been well supported, the instruction exact, and the worker’s return normal — none of those tells the person reading the record whether the file changed.

Capability Is Not Authority

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

Part 4 — Make It Safe and Verifiable

A sensible correction, refused

Constructed scene. A reviewer finds an incorrect cache setting and proposes the right replacement. Its worker can edit files. The person who opened the review asked for inspection only.

The correction’s quality is beside the point. An accurate proposal grants no permission to apply it. The presence of an editing tool grants none either.

Chapter 19 separated the actor’s report from evidence about the effect. Now move back to the moment before that effect: the process is about to call a worker that can change something. Which part of the system decides whether it may?

The Agent Cannot Grade Its Own Homework

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

Part 4 — Make It Safe and Verifiable

The patch that passed

Constructed scene. A patch arrives with a note: “all tests pass.” The note is confident and unchanged while you read it. Then you run one small check against the actual file, and it fails.

Keep both in front of you. The sentence says success. The command says failure. One of them examined the artifact; the other one is a report about it. The reader who can point to which is which already understands this chapter.

Retries Are Side Effects Too

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

Part 4 — Make It Safe and Verifiable

The line that may already be there

Constructed scene. An adapter appends one line to a file. The process dies before the completion is recorded. On restart the ledger shows no completed result — but the file has changed.

Three responses are available, and two of them lie. Appending again may write the line twice. Writing a success record by hand manufactures evidence for an effect nobody observed. Saying “unknown” is the only honest answer, and it is also the least actionable one. The question that matters is narrower than “what do we do?” It is: what evidence would justify another append?

Independent Calls

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

Part 5 — More Intelligence Is Not Automatically Better

Three reviewers, one paragraph

Constructed scene. Three reviewers receive the same versioned paragraph and the same source pack. Each writes a proposal. Every proposal is collected before any is revealed.

Contrast that with a second procedure: show the second reviewer the first answer and ask for agreement. The second process costs less and runs faster. It also sounds more confident, while answering a different experimental question. Agreement after exposure cannot distinguish shared insight from shared influence — which is why the blind collection exists first, and why the next four chapters need it before they ask whether extra candidates help.

The Models Were Different. Their Mistakes Weren't

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

Part 5 — More Intelligence Is Not Automatically Better

Seven repairs, one unresolved bug

Open on the stubborn task, before any percentage. The problem statement asks for a function that returns the mean of the list it is given, on every call. The starter code caches its first answer and never lets go:

def average(xs):
    if not hasattr(average, '_n'):
        average._n = len(xs)
        average._s = sum(xs)
    return average._s / average._n

The reference repair is one line: return sum(xs) / len(xs). Delete the state.

Make the Problems Harder

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

Part 5 — More Intelligence Is Not Automatically Better

Three tasks the baseline never solved

Chapter 24 ended under a ceiling: eleven of twelve tasks solved by a single draw, one shared failure, nowhere for a portfolio to go. The response was a harder corpus: forty repair tasks in four strata of ten, each stated as misbehavior plus a contract rather than a fault label, with hidden tests defining correctness. On that ground the arms finally differ. Lead with the paired difference, not the percentages: ¹ ²

Diversity Without More Models

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

Part 5 — More Intelligence Is Not Automatically Better

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

The challenger gets its matched fight

Chapter 26 ended with a subgroup that looked like a better prompt and a refusal to promote it. This chapter runs the test that refusal called for, and states the answer before interpreting it: at twelve draws per task on both sides, counterfactual wording covered 9 of 12 tasks, matching normal wording, passed 44 of 144 candidates, also matching, while using 46% more tokens. Normal stays the default.

What Should Happen Next?

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

Part 6 — Put Intelligence Into the Process

A claim awaiting a check

Constructed scene. A patch sits open with one review comment unresolved: a retry test that may or may not cover the new branch. Three things could happen next. A model could propose a fix. A deterministic check could run the test suite. A person could be asked whether the branch matters at all. Each costs something different, fails differently, and answers a different question. “Try a stronger model” is not on that list until something has established that generation is the missing operation.

Applied AI

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

Part 6 — Put Intelligence Into the Process

One paragraph, one process

A disposable file holds one line:

draft: models are stochastic, so review is hard [S1].

The frozen criteria for the task are narrow on purpose: the [S1] marker must be gone, and the sentence Models supply cognition. must be present. The “reviewer” is a fake model adapter that returns one canned revision. That is deliberate. This chapter is not testing whether a model can review a paragraph. Chapters 23 through 28 spent their evidence on what models and model policies do. This one tests whether everything around the model holds together when the pieces are joined.