Should a change record that an AI tool helped write it, and what should that record change?
answer
- Ask what the record is for
- Provenance yes, scrutiny tier no
- A label that costs you disappears
- Gate on blast radius, not instrument
basics
~20 sRecord 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.
solid answer
~50 sIt depends what the record is for, and two purposes get confused. As **provenance** it is cheap and worth having: months later, a question about where a block came from has an answer instead of a shrug. As a **routing rule** it backfires. If the label buys a slower review or a more suspicious reader, authors quietly stop applying it, and the team loses the data and the candour together - and the premise was weak anyway, since attention belongs on what a change touches and can break rather than on which instrument typed it. So record the fact, gate on the surface, and accept that the label decays: as assistance becomes ambient, a binary flag partitions less and less. What disclosure legitimately changes is smaller and real - it tells a reviewer which questions to ask the author.
go deeper
Know that recording how a change was produced is a provenance question rather than a confession, and that whether your team wants it recorded is a team decision, not a personal one.
Explain the incentive problem: a label that costs the author something stops being applied, so the team loses the data it wanted along with the candour it depended on.
Show what you would route review attention by instead - what the change touches and can break - and what a disclosure note honestly changes about the questions you ask the author.
Own the policy: what is recorded, what it is used for, what it is never used for, when any heightened-attention period sunsets, and how you would notice the label going stale.
## Two purposes wearing one label "Should we mark AI-assisted changes?" is really two questions that pull in opposite directions, and most arguments about it are two people answering different ones. - **Provenance.** A durable note about how a change was produced, read months later by someone reconstructing where a block came from. - **Routing.** A live signal that tells this review to be more thorough than the last one. The first is cheap, honest and worth doing. The second is where teams get into trouble. ## The case for recording A contemporaneous note costs almost nothing and answers a question that is otherwise unanswerable. When someone asks where a distinctive block came from, or an incident review wants to know how a change was produced, an unverified note written at the time beats reconstruction from nothing. It also gives the team a way to talk about the subject without accusing anyone: a fact about the change rather than a confession by the author. Two properties keep it useful: 1. **It attaches to the change, not to the person.** Provenance is a property of an artefact. A per-author tally is a performance record wearing a provenance costume, and it will be read that way. 2. **It states what it is used for, and what it is never used for.** Write both down. The second half is what makes the first half credible. ## Why the scrutiny tier backfires Suppose the team decides that a labelled change gets a stricter review permanently. Three things follow. - **The incentive inverts.** The label now costs the person applying it - a slower merge, a more suspicious reader. A self-reported label that costs something gives every author a reason to stop applying it, and the honest ones are the only people who pay. Before long you have neither the data nor the candour. - **The premise is weak.** Scrutiny should follow what a change can break. A one-line assisted fix to a log message is not more dangerous than a hand-typed change to an authorisation path, and a tier based on the instrument says otherwise. - **It cannot be verified.** There is no way to confirm the flag, so the tier enforces itself only on people who volunteer for it. There is an honest exception, and it is worth conceding in an interview: a team in its **first weeks** with these tools may deliberately route extra attention while it learns what the changes look like. That is defensible if it is explicitly temporary, has a date, and is described as a learning measure rather than a standing judgement. The failure is letting it become permanent by default. ## Gate on the surface instead | Gate on | Verifiable from the change? | What it buys | |---|---|---| | What files and modules it touches | Yes, mechanically | Attention where blast radius is largest | | Whether it alters an authorisation path | Yes, mechanically | A second reviewer on the risky class | | Whether it changes a schema or a migration | Yes, mechanically | Review proportional to irreversibility | | A self-reported assistance label | No | An incentive not to report | Every row above the last is a property of the artefact, so it holds no matter who or what typed the change, and it does not decay as the tools spread. ## What disclosure legitimately changes Something, but less than people expect, and it is worth being precise about it: - It tells the reviewer **which questions to ask the author** - "walk me through why this branch is here" rather than "does this look right". - It signals that the author's familiarity with a section may be shallower than usual, which is a reason to ask, not a reason to distrust. - It makes a later incident review able to describe how the change was produced without anyone having to remember. None of that requires a separate review tier. All of it is served by a factual note. ## The decay problem Any binary label partitions a population only while the population is mixed. As assistance becomes an ordinary part of an editor, "assisted" stops distinguishing changes from one another, and a policy built on the distinction quietly stops doing anything. That is the strongest argument for keeping the policy simple: record the fact if it is cheap, do not build process on top of it, and expect to revisit what the record is for rather than the record itself. ## The week this policy usually gets written It is usually drafted just after an assisted change shipped a bug, which is the worst moment to design an incentive: the obvious move - flag these changes and review them harder - is the one that destroys the signal. The durable outputs of that week are a short checklist line, a sentence about who owns merged code, and a factual provenance note. ## What an interviewer is listening for That you separated the two purposes before answering, and that you reasoned about the incentive rather than asserting a policy. A candidate who says "yes, always disclose, and review those harder" has not noticed that they have just designed a system that punishes disclosure. A candidate who says "no, never, it is nobody's business" has given up a provenance record that costs nothing. The answer worth hearing names both purposes, keeps the cheap one, refuses the expensive one, and says what would make them revisit it.
- Your team wants heavier review on assisted changes for the first month. Is that wrong?Not if it is temporary, described as a learning measure, and has a date on it. The failure is making it permanent: a standing tier teaches people that disclosing costs them, and the honest signal fades. Put the sunset in writing when you start, and say up front what you expect to have learned by then.
- If the label cannot be verified, what is it actually good for?Answering a question later. When somebody asks where a block came from, or an incident review wants to know how a change was produced, an unverified note written at the time beats reconstruction from nothing. Treat it as a memory aid with known gaps rather than as a control, and do not build process that assumes it is complete.
- Should the record name the tool, or just say that assistance was used?Prefer the weaker, more durable form. Naming a specific tool dates the record and invites arguments about which ones count as assistance, and the question it needs to answer later is only whether a person wrote this block line by line. Keep it factual and coarse, and keep it attached to the change rather than to the author.
saying these in an interview costs you the question
- Wants an assisted label to buy a permanently stricter review tier
- Believes a self-reported assistance flag can be verified
- Treats disclosure as an admission of weaker work
- Says recording provenance is pointless because everyone uses these tools
- Assumes the label will keep partitioning changes as assistance spreads