How I work with AI

It opens the branches, writes the commits and puts up the merge requests, then merges each one itself once that request's own pipeline passes. I don't review every merge request by hand. The pipeline is the gate.

My part is the direction, and catching it when it gets that wrong. When I asked for the pipeline to be on the site, it added a whole new page for it. I told it that wasn't what I meant: I wanted the existing page about how the site runs to cover the pipeline, with the diagram redrawn to match. It folded the pipeline into that page, redrew the diagram and turned the extra page into a redirect.

Most of what it does, it just does. It can create or restart a service, edit a config file, or run a command that can be undone if it turns out wrong. I don't want to approve every small thing, and with reversible work I don't have to.

Anything that can't be undone waits for me. That means deleting data, sending anything outward that can't be taken back, or anything that could lock me out of a machine I can't walk over and touch. The rule I gave it is short: if it can be undone, go ahead, and if it can't, ask me first. For commands that delete data or could lock me out, a hard stop blocks them before they run. To get one through, it has to show me the exact command and what it will touch, and I say yes. That yes covers that one command, one time, and it runs out after a few minutes.

A green pipeline doesn't prove the site works. After one deploy, the new architecture diagram passed every check on the branch, but desktop visitors kept getting the old one for about twenty minutes, because a cache was still serving the old file under the same URL. Comparing the live file's bytes against the repository is what caught it. The fix was stamping a version into every stylesheet, script and image URL, and the build now fails if one is missed.

A helper agent reported that it had visually checked all seven diagram images and found no overlaps. A geometric check that measures each label against its own box found seven labels spilling outside their boxes and three lines cutting through text. After the fix it found none. The agent runs that check whenever the diagram changes, and it proved the check can fail by running it on a copy with one label stretched on purpose.

The pipeline has caught real problems too. A staging smoke test hit an intermittent error during a rolling update and stopped the deploy before production. Two standing rules sit behind all of this. A report from another agent is a claim to check. A passing test is one signal, and the thing it tests still has to be looked at directly.

Different jobs get different models, on purpose. Mechanical work, like reading a screenshot or classifying a pile of text, goes to a small model running locally first, since that costs electricity and nothing metered. Bulk or repetitive work goes to a cheaper hosted model. Judgment calls, and anything happening live with me, go to the strongest model I use.

The reasoning is total cost. A cheap model that struggles with a hard task can end up costing more overall than a stronger model that gets it right the first time, so the rule is to estimate the whole job, not just the rate on one token.

Speech to text and text to speech run on my own GPU at home, not a cloud API. The card is a gaming GPU first, so a model loads only when needed and drops from memory after ten idle minutes, which took idle memory use on the card from about 2.4 GB down to under 200 MB.

When a screenshot or dashboard needs reading, it goes to a local vision model first if that model can handle it. What made it reliable was giving it the exact set of possible answers up front, asking it to describe what it sees before answering, and letting it say it can't tell. In a test where the answer genuinely wasn't visible in the image, it said so in all three tries instead of guessing.

A local embedding model makes my notes searchable by meaning. It holds about 7,500 chunks of notes as 768-dimension vectors and rebuilds the index every hour. One test asked why an earbuds app refused to work on a phone that wasn't a Samsung. The note that answers it talks about Galaxy Buds and the Wearable app, words the question never used, and the search still found it. A plain keyword search for "earbuds" came up empty.

The agent keeps its working notes in a knowledge base on disk. The rule is to write things down as they happen, not at the end, so that clearing the conversation loses only the conversation.

When something gets corrected, the note records what it believed, what turned out to be true and what changed its mind, along with the fixed conclusion. The conclusion can be worked out again from the data later. Which instinct was wrong can't, once the conversation is gone.

Finished work moves into a history file, so the active notes stay about what's still open. Nothing gets deleted, only moved, and it stays searchable. Before searching those notes by keyword, the first move is a search by meaning, since a keyword search only finds the exact words used, and that's rarely how a question got asked.

Anything Claude Code reads that didn't come from me, such as a web page, a file or another tool's output, only gets a say in the shape of the task: which fields exist and what format is expected. It gets no say in what the answer is, which steps can be skipped or what its own instructions are.

Text in that material that tries to give the agent orders gets refused and reported to me, not quietly dropped, so the next run doesn't meet the same thing cold.

Pieces of work that don't depend on each other run at the same time, and separate reviewers each check one thing.

The redesign behind the diagram on the platform page is a real example: sixteen agents, about eighty minutes, and roughly two million tokens of work, including two different diagram designs built independently and judged against each other before one was picked. The review passes did catch real problems. One noticed the new page disagreed with an older diagram elsewhere on the site, and another caught an overstated claim about the servers' physical layout that had survived two earlier rounds. They also missed some. Clipped text in the diagram, a redirect that would have sent visitors to the wrong address, and a line wrongly saying production had hit an error that staging had actually caught were all found by the agent's own follow-up checks.

The platform page covers the pipeline itself, end to end, and its live panel shows how many of the latest change's commits came from the agent, pulled straight from that change's own merge request.