AI-assisted development

An unstated environment gets filled in from what is most common, not from what your build accepts. You then get an answer that is correct somewhere else: a newer idiom, a different framework line, a dependency you do not carry.

It cannot catch the function being wrong. An expectation taken from the implementation agrees with that implementation by construction, so the test reports that behaviour has changed rather than whether the behaviour was ever right.

An agent's own earlier conclusions sit in the session record, and later turns read them as given rather than as guesses. Each restatement drops the hedge the first one carried, so certainty grows while evidence does not.

The request names an outcome and no behaviour. Retrying a payload the receiver rejected, sending the same one twice, and giving up silently all satisfy it — so the agent picks one, and you usually find out from the diff.

The run's output carries the failing case, the expected and actual values, and the line that produced them. A summary replaces those facts with your diagnosis, and if the diagnosis is wrong the next turn inherits it.

A generated change carries no author intent, so an unexplained line is not evidence of a reason you lack — it is an open question. Reconstruct intent from the request, verify the risky parts, and answer for what you merge.

A single run has no interior — nothing inside it meets a check you already trusted. An early wrong decision surfaces only after later work is built on it; five units catch it while it is still one unit wide.

Attach what the codebase has already fixed and the answer should not re-choose: the signature the caller expects, the record type it must return, the helper that already exists. Otherwise you get a correct function that needs an adapter.

An extraction can preserve every happy path and still move the edges: which order side effects run in, whether an early exit still leaves the caller, which failure escapes, and what a missing value defaults to.

The people, not the tool: the author owns the change they submitted and the reviewer owns the approval, exactly as before. What follows is a bar at submission - do not send code you cannot explain.

The build decides whatever has a deterministic oracle: resolution, types, style, declared dependencies, the existing suite. A person is needed wherever correctness depends on a rule the generator could not see, and that is where review attention belongs.

Split it in two. Settle what you can alone - unit, scale, sign, which side of the boundary the value falls on - then take what is left to whoever owns the rule, as one concrete case with a yes-or-no answer.

The broken build is not the risk; the reflex is. Fetching a name to make the build pass hands the decision to whoever claimed that name, and a plausible invented name is worth claiming in advance.

Add the fact that tells the two cases apart — a refusal the receiver would repeat is not retried, a silence is — and name the wrong behaviour as an explicit non-goal. Emphasis carries no information; a fact does.

A loop optimises the verdict it was given, and the verdict is editable. Green can be reached by weakening an assertion, skipping a case or widening a catch — all cheaper than fixing the cause.

Write the request out as observable outcomes before reading the change, then walk it both ways: every outcome present, and every behaviour change traceable to an outcome. The backwards walk is the half reviewers skip.

Throughput alone settles nothing: over six months the people, the codebase and the work all changed alongside the tool. Report where effort moved and which narrow claims you are willing to defend.

The task decides it: whether a fast, trustworthy check exists; whether the change is wide and mechanical or narrow and subtle; whether you know the code well enough to review at speed; and whether it must be explainable later.

Enough to triage, not to review: whether it does what you were about to write, and whether its names exist here. Anything you cannot settle in that moment should be rejected rather than accepted to check later.

The first line continues code you wrote and can inspect; every line after it mostly continues text the tool just produced and nobody has checked. One early wrong assumption is then carried, consistently, by everything below it.

Reading load rises for people whose own output did not. An assistant multiplies how fast drafts are produced and barely touches how fast anyone reads them, so the constraint moves to review and lands on whoever is absorbing.

Fluency at producing routine code decays first and returns quickly. Judgement decays only if you stop exercising it, which accepting makes easy. The costlier loss is a model of the system you never built.

Amend when the shape was right and one decision was wrong, because everything already established still stands. Restate cleanly when the approach itself was wrong, because corrections there land as patches on a structure you did not want.

Pin the surface: list the names the code may call with their shapes, close the list against anything new, and ask it to say so rather than substitute when something is missing. Pinning narrows the answer; it does not enforce it.

Name the situations, not the quantity. A model drafting from the code produces cases the code already implies. The awkward ones live in the rule, so list them yourself: the period that ends before it starts, the joiner on the boundary.

Four shapes, two axes: what each can read, and what each can act on. A completer writes at one point; an in-editor agent edits an open project; a terminal agent also runs commands; a hosted agent changes only its own copy.

Each turn is judged against the state the turn before it left, so the baseline moves with the change. A turn that repairs the previous turn's side effect is locally right and carries the session further from what you asked.

File count is the weakest signal: a rename legitimately reaches every caller. The warning is new territory the request never named — a stored-data change, an externally visible shape, an edited test expectation — and it appears well before the count does.

Three things the goal itself does not carry: the fence, naming artefacts the run must not change; what done means, in terms you could check against the diff; and the decisions it must bring back rather than settle alone.