Yes, an agent wrote it
We're writing this page because the question keeps coming up, and we think the honest answer puts you in a better position than most people expect. If someone asks whether AI wrote your code and you can say yes, and then say what you checked, you're in good shape. The hard part is the second half, and that's what this page is about.
Who's asking, and what they actually want
Mostly, so far, it's open-source maintainers, and they ask in writing. This isn't a new idea on our part; it's essentially what projects have been asking for since the first agent-written pull requests showed up. MicroPython puts it on every pull request as a box you have to tick:
I used generative AI tools when creating this PR, but a human has checked the code and is responsible for the code and the description above.
As far as we can tell, the worry underneath is rarely the tool itself. Ghostty says it plainly in their AI policy: low-effort work "puts the burden of validation on the maintainer". Somebody is being asked to check something the author didn’t check, and that’s what they mind. Their policy is here.
What a pull request can say for you, and what it can’t
A pull request already records a fair amount: who approved the change, when, and against which commit. If you've set up branch protection it can also show that the approver wasn't the author. All of that is real evidence and anyone can check it.
What it doesn't have is a field for what the approver actually opened. That was fine for a long time, because the person reviewing had usually written half the change themselves. With an agent writing most of it, the gap between “I approved this” and “I read this” starts to matter, and there's simply nowhere in the pull request to record which one you mean.
What a record of the review looks like
Here's what we mean by a record. Picture a change to a checkout service: eighteen files, an agent wrote most of it, and one engineer reviewed it and signed. The record keeps one line per file, saying whether that file was opened and what was decided about it. We've made this one up to show the shape, so the names are placeholders, but the shape is the real thing.
Add partial refunds to the checkout service
your-team/checkout-service · a41c7d2 · signed by one engineer, by name
- files
- 18
- opened
- 9
- approved unopened
- 4
- flagged
- 1
- src/checkout/refund.tsapproved · opened
- src/checkout/tax.tsflagged · opened
- src/lib/currency.tsapproved · not opened
- docs/refunds.mdcleared · not opened
- package-lock.jsoncleared · not opened
- and thirteen more, each recorded the same way.
The line to look at is “approved unopened: 4”. Four files went through without anyone reading them. That isn't a scandal, most of us do it with lockfiles and generated docs, but it's the number an honest answer needs, and it's exactly the one a pull request can't give you. It also tells whoever looks next where to start.
A paragraph for your policy
If your team already has a development policy, and most do, this is written to sit inside it rather than replace it. Take what fits.
Code contributed by an automated agent is subject to the same review and approval requirements as code written by a person. The approver is identified in the change record, together with the files they reviewed and the outcome recorded for each.
Where this stands
Today this is mostly a maintainer's question. If you contribute to open source, you've probably met it already. If you ship to customers, you probably haven't yet, though the contract clauses for it are being drafted, and it's a lot easier to start keeping the record before anyone asks than to reconstruct one afterwards.
If someone has asked you, in whatever words they used, we'd genuinely like to hear how it went. Write to us and you'll get a reply within a few days.
Proof keeps this record: what was reviewed, by whom, and how much of it they opened. How it works.