AI Assisted Coding

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.

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.

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.

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.

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.

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.

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.

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.