Four questions about AI-generated code your team can't answer yet

Engineering teams adopted AI coding assistants faster than any tool in recent memory, and largely without changing anything about how they record work. That was reasonable while the only audience was the team itself. It stops being reasonable the first time someone outside the team asks a question about it — and those people have started asking.

The pattern is familiar from previous cycles. A practice becomes ubiquitous, then something makes it consequential, and suddenly you need evidence you never thought to collect. Dependency scanning went that way. So did license compliance. AI authorship is going the same way, and the difference is that you cannot backfill it: if you didn't record who wrote a line at the time, that information no longer exists anywhere.

Who's actually asking

Four groups, with different motivations and the same underlying question:

• Procurement and contracts. Enterprise and public-sector agreements increasingly contain clauses about AI use in deliverables — sometimes requiring disclosure, sometimes prohibiting machine-generated code in specific components. Both directions require you to know.
• Diligence in acquisitions. A buyer assessing a codebase wants to understand what share was generated, whether it was reviewed, and what that implies about maintainability and IP. "We don't track that" is a discount, not a neutral answer.
• Security and audit functions. Internal audit and external assessors are adding AI usage to SDLC reviews. The question isn't whether you use it — it's whether you have controls.
• Insurers. Underwriters pricing errors-and-omissions or cyber cover ask about development practices. Demonstrable controls are a pricing input.

The four questions

1. What share of this release was written by a model?

Not "do you use Copilot" — a number, for a specific release, ideally at line granularity. Most teams can produce a vendor dashboard showing acceptance rates last month, which answers a different question about a different time period and doesn't survive being asked about a specific artifact.

2. Which models, specifically?

This matters more than it first appears. Different assistants carry different licensing terms, different indemnification positions, and different training-data provenance. "AI-generated" is not a single category, and a buyer's lawyer will not treat it as one.

3. Which of that was verified by anything?

The strongest question in the set, and the one teams handle worst. There is an enormous difference between "a model wrote this and our test suite passed on it and a named human approved it" and "a model wrote this at 3am and it merged." Most repositories cannot distinguish the two after the fact, because verification results live in a CI system keyed by commit SHA with its own retention policy.

4. Could this record have been altered?

The question that decides whether any of your answers count as evidence. If provenance lives in a mutable database, a spreadsheet, or a file any engineer can edit, a serious reviewer will treat it as an assertion rather than a record.

What good evidence looks like

Whatever tooling you choose, a defensible answer has four properties:

1. Captured at write time. Authorship is only free to record at the moment of the change. Everything reconstructed later is inference, and inference doesn't survive scrutiny.
2. Structured, not prose. "AI" mentioned in a commit message is not queryable and not verifiable. A typed field — human or agent, which model, which session — is both.
3. Tied to verification. Authorship alone is half the story. The evidence should say what happened to that code afterwards: tests run, results, human approval.
4. Tamper-evident. The report should be anchored so that altering it is detectable — minimally a content digest, ideally a signature bound to a key the engineering team doesn't hold alone.

Where kal fits

This is the problem kal was built around, so treat the following as a description of one approach rather than a claim that it's the only one. Every snapshot records its author as structured data — human or AI, with the model and session — and verification results attach to the snapshot as notes rather than living in an external system. kal attest turns that into a report:

kal attest v1.0 --key release.key -o attestation.json

The output states the AI-written share of that revision, the breakdown by model, verification coverage, and an explicit list of AI-authored changes that were never verified. It carries a SHA-256 digest of its own canonical form plus an optional HMAC signature. Edit any figure and both checks fail; recompute the digest to hide the edit and the signature still fails.

Two honest limits, because a compliance tool that oversells itself is a liability. HMAC is symmetric — it proves a key-holder produced the report, not which named party did, so for third-party-verifiable signing you sign the printed digest with infrastructure you already trust. And no tool can attest to what wasn't recorded: if attribution is switched off, or an engineer commits agent output as their own, nothing catches that. Provenance tooling raises the floor; it doesn't replace the practice.

What to do this quarter

You don't need a procurement cycle to start. Three steps, roughly in order of value:

1. Turn on attribution somewhere. Whatever tool you use, make AI authorship automatic rather than something engineers remember. Incomplete provenance is worse than none, because it looks authoritative.
2. Record verification next to authorship. If your CI results can't be tied to a specific change six months from now, that's the gap to close first — it's the question with the sharpest teeth.
3. Generate one report and read it. Whatever your stack, produce the artifact once and look at the number. Most teams are surprised, and the surprise is the point: you now know something you would otherwise have learned in front of an auditor.

None of this is about using less AI. The teams that come out of the next two years well will be the ones using plenty of it, who can also say precisely what it wrote and show what happened next.