An assistant inside a client's codebase
The work is the awkward middle: reproducing a pipeline from a paper, rebuilding an index nobody trusted, cleaning a pile that had been ignored since 2019. One person states the goal in a sentence, another reads it back as a plan, and then a machine does the part that is long rather than hard.
Lian is the name we gave the thing that does the work, and it is not a product we bought. It is a setup we wrote and keep repairing: a wrapper around Cursor's coding agent, and the point of the wrapper is that several of them can work at once — each on its own brief, in its own repository, without treading on the others. Buying an assistant gets you one. Building one gets you a shift.
The interesting part is not that an assistant can write code. It is that the routine survives without anyone watching it closely: a brief with the goal first, a plan approved before the work runs, and a receipt that is the change itself.
The problem
The work arrives as a sentence. Reproduce this paper's pipeline. Make the retrieval index usable by the researchers. Clean this and tell us what is in it. Each one is real work, and each one is small enough that hiring for it is absurd and large enough that one person cannot hold the whole thing and still finish it. The bottleneck was never typing.
The wrong turns
We began by handing over the task and the files and asking for the change, which worked right up until it did not: with no stated boundary, the assistant invented scope, and the change arrived larger than the request. Then we asked it to summarise what it had done and believed the summary. A completion note is a claim, not evidence, and it is written by the same system that may have been wrong. A third attempt ran the reading and the writing in one thread, which left the thread unable to write at all: the approved work could not run, and nobody noticed until someone tried to run it.
What worked
The brief now opens with the goal — what the work is for, in company terms — before any file path, because a list of edits without the goal is an invitation to guess. The planning pass is read-only and produces a plan a person approves before anything runs, and we snapshot the working tree either side of that pass so a plan cannot quietly change the code it is describing. The assistant then works inside the client's own repository, not a copy of ours, so the code stays where the client's team keeps it. When it finishes it writes down what changed, the decisions it took, and the exact commands it ran — and we check the changes themselves rather than the note. On one client's codebase the routine has been running for three months: 458 commits across twenty-nine repositories in that window, measured 15 October 2026, with the review trail that goes with it — a written brief, an approved plan before each run, and the change itself as the receipt.
What it costs
Every handoff needs a written brief, and somebody has to read the result properly. The approval is real work, not a formality: it is the point where a person decides, and it is where every mistake we have caught so far was caught. A team that wants an assistant to run unattended will get a faster version of whatever they asked for, including the parts they did not mean.
What it would look like for a client
The routine travels: your repository, your approval, one writer per file, a plan before a change, and the diff as the receipt. If your engineering work is a long list of small, well-scoped pieces, this turns each of them into a brief you can review in a minute — and gives you a written record of what the machine decided, which is the part most teams discover they wanted afterwards.