AI-assisted development

A usable verdict runs without you, returns the same answer on the same input, is cheap enough to run every turn, and names what failed rather than that something did — and it has to be failing now, for the right reason.

A name that does not exist fails the moment anything resolves it. A real name used on a wrong assumption resolves and fits the code around it, since one run wrote both sides; the disagreement is with the real contract.

Re-order so evidence arrives first: open with a behaviour-preserving unit the existing suite already checks, then the smallest unit that settles the riskiest assumption. Merge any unit that cannot fail on its own.

Three tells, all visible before you type: the unit has no end state where the project still builds, no check that existed before the unit did, and no area you can name.

A long session is filled mostly by its own by-products: files read entire, full command output, failed attempts, its own restatements. The room is finite, so older material goes and the work carries on with less.

Wherever this service departs from the widespread way of doing something. A continuation follows shapes that recur, so on your unusual code the recurring shape is the wrong one - and it reads as entirely reasonable to anyone new here.

Give the tool a complete view of something small, not a partial view of something large: the block being moved, the uses you found yourself, the tests that pin it. What it cannot see, it fills in.

Review by shape, not by file: decide what every hunk should look like, read the ones that break the pattern, and search separately for the names a rename cannot reach - in configuration, stored data or message text.

Only what the build and the ordinary checklist cannot already cover. In practice a handful of lines: invariants the generator could not see, the caller's authority, provenance for a distinctive block, and whether the author can explain every line.

Surface the question, do not rule on it. Reviewers flag blocks distinctive enough to need a provenance answer and route them to whoever owns that risk; the team decides once, and sets a higher bar for code it redistributes.

The ones whose correctness depends on something outside the file the generator was working in: the caller's authority, the trust boundary the input crossed, how credentials are obtained, and what the failure path discloses.

The number counts code that ran. Generation made running code cheap and left the hard half - deciding what the right answer is - exactly as expensive, so a figure that stood in for effort no longer does.

A long autonomous run concentrates a large change into one review decision, widens what a mistake can touch before anyone notices, leaves less of the session reconstructable, and produces a result a re-run will not reproduce.

A point you verified — built, tested, recorded in version control — and a run whose reach stays inside that tree. Recovery cost is set by what the session could touch outside it, not by how many files changed.

Hand over what changes a decision the run would otherwise get wrong — the contract, the record shape, one example of the code you want. Surplus material gets imitated, and it makes a wrong result impossible to attribute.

Watch the failing set, not the last message. A converging loop shrinks it and keeps it shrunk; a stalled one moves it sideways — same size, different members. Fix the stopping condition before turn one, while the sunk cost is small.

Name the second implementation, caller or value the structure exists for. If it exists today or is genuinely planned, keep it; if it is only imaginable, the code is paying now for a prediction, and it comes out.

Which repositories a tool may be attached to, what it may see once attached, what never goes anywhere, the default for the unlisted case and who answers it quickly. A rule phrased as per-paste judgement decides nothing.

Sort the edit by what can check it, not by how good the suggestion looks. Name resolution covers mechanical edits inside the scope it indexes, a build check catches shape, and order, defaults and failure need a test.

A short trial mostly tells you about yourselves: how well your checks hold, how much of a run you can reconstruct, where your codebase resists being read. It generalises poorly to untried areas, other teams, and later versions.

A goal is statable when its acceptance exists apart from the implementation. Where acceptance is what the work discovers, or two teams disagree what done means, no wording fixes it — settle it first, or run to learn and discard.

Whatever decides the verdict should not move silently: assertions, expected values, skip lists, rule configuration, the threshold that fails the build. The cost is real — checks are sometimes wrong, and a locked loop burns turns failing against a stale expectation.

Your typing sets the deadline, not the tool: a suggestion that arrives after you wrote the line is worthless however good it is. Everything done to meet that deadline narrows what the suggestion could account for.

Everything about its own exposure: what it accepts into which products, what its existing contracts and licence obligations already require, and who it asks. The law is not the team's to settle, and stating it as settled is the error.

Asking for the approach first moves your review to the cheapest artefact: four lines read and rejected in seconds, against a working function that is expensive to read and hard to reject once it runs. Use it where the decisions carry the risk.

Re-run when the premise is wrong — a misread request or an unstated constraint — because that mistake is spread through every file. Repair when the premise holds and the defects are few. A re-run discards the review already done.

Only what is legible in the code carries across a boundary. A later run reads the repository, not the earlier run's reasoning — so a decision survives as a helper with no route around it, or as a failing test.

Record it as a fact, for provenance later, and do not turn it into a scrutiny tier. Review attention belongs on what a change touches and can break, which is verifiable, rather than on a self-reported label.

Weigh what each test would report that nothing else would against what everybody pays for it on every run: minutes of build time, failures that are not about the product, and an obligation to maintain something nobody can explain.