Nobody can explain the code, and the machine will not be asked

Nobody can explain the code, and the machine will not be asked

Read the title of the thread again, because the exact words matter and most summaries changed them. It is not "how do you spot AI code". It is "What do you do when a developer submits AI generated code they clearly don't understand?" (https://old.reddit.com/r/ExperiencedDevs/comments/1vg0cx8/what_do_you_do_when_a_developer_submits_ai/, 5 August 2026, 335 upvotes and 284 comments).

The complaint is not about quality. Quality is checkable, and if the code were bad the review would be easy. The complaint is about what happens six months later, when the change breaks something at two in the morning, and the only person the incident channel can page is the one whose name is on the commit, and that person cannot tell you why the code does what it does. There is no second party to ask. The thing that wrote it does not persist, was not identified, and has no obligation.

Four projects, six weeks, and none of them wrote a quality rule

Between 1 July and 7 August 2026, four large projects put rules in place. Godot moved first on 1 July. The GCC steering committee followed on 29 July, declining "legally significant contributions which include LLM-generated content". Oracle acted for OpenJDK on 7 August. LWN covered the shape of it at https://lwn.net/Articles/1086041/, and the Hacker News discussions were large and, by the one measure available from outside them, contested: 561 points and 403 comments for Godot, 535 points and 382 comments for OpenJDK, and 357 points against 429 comments for GCC. That last ratio is the interesting one. A thread that draws more comments than upvotes is a thread people are arguing in rather than agreeing with.

Then Rust, on 5 August, and this is where nearly everyone reporting on it got it wrong. Rust did not ban AI contributions. Its policy is published at https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/ and it explicitly permits them: "Pre-arranged, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally created by an LLM are allowed, with disclosure." The line it draws is about function, not tooling: use LLMs "to answer questions, analyze, distill, refine, check, suggest, review. But not to create." And it protects the reviewer rather than the codebase: "No one is required to review LLM PRs unless they volunteer."

If you are about to cite this trend, cite it correctly, because the correct version is more interesting. Not one of these four is a quality standard. There is no complexity threshold, no test coverage floor, no style rule. Every one of them is a rule about where a change came from and who will answer for it. Four independent groups of maintainers looked at the same problem and all four reached for provenance rather than for a bar.

That is a strong signal about what the actual failure is. If the problem were that machine-written code is worse, the answer would be a higher bar, and a higher bar is something these projects already know how to build. They did not build one, because a higher bar does not tell you who to ask.

The cost lands on somebody who was not in the room

"Why Software Factories Fail" names the incentive in eight words: "there is no penalty for eroding codebase maintainability" (https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/wsff.md, 23 July 2026). The author of an unexplainable change experiences no consequence. The consequence is paid later, by someone else, possibly by someone not yet hired, and it is paid in the currency of time spent reconstructing intent that was never written down.

Ford put a price on that currency. Over three years it hired 350 veteran engineers, many of them former employees, after AI-assisted inspection fell short, and the admission was unusually direct: "We didn't pay as much attention as we should have to the experience of our most knowledgeable engineers" (Bloomberg, 25 June 2026, via https://news.ycombinator.com/item?id=48674446, 632 points and 555 comments).

Notice what Ford bought back. Not code. The code was still there. What had left the building was the set of people who could explain why it was that way, and the only available way to acquire that again was to re-employ the humans who remembered.

We solved this for facts and we have not solved it for code

We build a system whose entire job is to hold what a company knows about its customers, and most of what it holds is produced by models. So the question in the thread is our question, in a different shape: when the system asserts that a contact is the economic buyer, who said so, and can you argue with them?

We answered it in the schema, because the schema is the only place an answer cannot be skipped. In the claims table, the pointer to the evidence, the identifier of the extractor and the version of that extractor are all NOT NULL columns. There is no code path that writes a fact without a pointer to the source it came from and the identifier and version of the thing that read it.

The stronger property is in the identity rather than the columns. A claim id is a SHA-256 over the workspace, the subject, the predicate, a hash of the object, the evidence source id, and the extractor version. You cannot mint a claim id without provenance, not because a validator rejects it, but because there is nothing to hash. Change the prompt, bump the extractor version, and re-extraction produces a new claim that supersedes the old one rather than silently overwriting it. Model drift becomes visible as supersession instead of invisible as an update.

That is the property the four projects above are reaching for and cannot have, and it is worth being blunt about the asymmetry: we were willing to make provenance structural for machine-produced facts, and neither we nor anyone else has made it structural for machine-produced code. A commit has no NOT NULL field for what wrote it. Git records an author, and the author is a human who may or may not have typed anything. Every policy in this article is an attempt to get that field filled in by asking people nicely, which is exactly the enforcement model that produced the threads.

Two things we have not done, said plainly

The schema records the extractor, always. It does not record a signed human actor unless a control is armed, and that control is off by default. The implementation says so about itself: with the flag unset, attestation "returns null, and the ingest path is byte-for-byte what it was. THE CONTROL DOES NOTHING". Built, not yet generally available. We would rather write that sentence than let "every action is attributed" sit here doing work it has not earned.

Second, the extraction pipeline that would fill this store at volume is not generally available yet. The store is shipped and contract-tested. The thing that pours facts into it is waiting on a human-labelled evaluation set, which is genuinely a human task and has not been done. What is described above is a schema property, provable by reading a migration, not a claim about traffic.

The line

The uncomfortable part of the thread is not that a developer submitted code they did not understand. It is that this was discovered at review time, by a human, by accident, and that the only remedy available was a conversation. There is no field to check. There is no version to bump. The machine that wrote it is not a party to anything and will not be asked, because nothing in the system knows it was there.

You can fix that in a schema, once, before there is data in it, and then it is simply true forever. Or you can write a policy and hope. Four serious projects just chose the policy, because for source code the schema option does not exist yet. It should.