Can you prove how your software was built?

From 11 September 2026, if a vulnerability in your product is being actively exploited, you have 24 hours to tell ENISA about it. Not 24 hours to fix it. 24 hours to report it, then 72 for the fuller picture and 14 days for the final account.

Sit with that clock for a second and ask a harder question than the one everybody is asking. Not "could we detect it in time". Assume you detect it. What could you actually produce, in a day, about a piece of code that has been in production for eight months?

Most CTOs I know could produce the diff. Some could produce the ticket. Almost none could answer the question the incident report really wants: what was this code trying to do, what was considered and rejected, and who decided it was safe to ship.

That gap is the most important unsolved problem in engineering leadership right now, and it is about to get a lot more expensive.

A bill of materials is not a bill of intent

The Cyber Resilience Act makes this concrete. From 11 December 2027, you must hold technical documentation for products with digital elements, including a software bill of materials in a machine-readable format, and keep it for 10 years after the product goes to market.

An SBOM is a good thing and long overdue. It tells you what is inside your software: every library, every version, every transitive dependency. When the next widely-used package turns out to be compromised, it tells you in minutes whether you are affected, which used to take weeks.

But notice what it does not tell you. It does not tell you why any of it is there. It does not record what problem a component was chosen to solve, what the alternative was, what tradeoff was accepted, or who accepted it. A bill of materials is an inventory. What an incident, an audit, a due diligence process, or a new joiner actually needs is a bill of intent.

We never needed to write that down, because for 40 years it lived in people. You asked the person who wrote it. The answer was in someone's head, and the head was still in the building.

Both halves of that arrangement are now failing at once.

Attribution collapse

By late 2025, roughly 24% of production code globally was written by AI, and that number has only gone one direction since. In the same research, 69% of organizations had already found vulnerabilities in AI-generated code, and around one in five breaches were being attributed to it.

The number I keep coming back to, though, is a softer one from the same survey. When AI-written code caused a problem, 53% of security teams, 45% of developers, and 42% of managers reported being blamed. Those add up to well over 100%, which is the actual finding. Nobody knows who is responsible, so everybody is.

That is what I mean by attribution collapse. It is not that machines write bad code. It is that the chain connecting a line of code to a human decision has quietly broken, and most organizations have not noticed because nothing has forced them to walk that chain yet.

Git tells you what changed and when. It has never reliably told you why. And now, increasingly, it does not even tell you who, because the commit says a person's name and the work came from an agent operating on an instruction nobody kept.

Run this forward two years at current adoption, and you get an organization that ships four times faster and cannot explain any of it. The velocity is real. So is the fact that no one in the building can reconstruct a decision from March.

The part nobody says out loud

Here is where I part company with most of the commentary, which treats this as a reason to slow down.

Agentic work is potentially the most auditable work in the history of software. Not the least.

Think about what actually happens when a person writes code. They hold the context in their head, make a hundred small judgments they never articulate, and commit a result. The reasoning is unrecoverable within about six weeks, including to them. We accepted this because there was no alternative.

Now think about what happens when an agent does the same work. It cannot hold anything in its head. Every piece of context it used had to be written down somewhere first, or it did not exist. The instruction, the constraints, the rules it operated under, the state of production it was reacting to. All of it is text, and all of it can be kept.

So the material for a complete record is generated for free, as a by-product of the work. The catch, and it is the whole game, is that this only holds if you capture intent at the moment of generation. Retroactively, it is gone permanently. You cannot reconstruct in 2028 why an agent chose an approach in 2026, because there is no person to ask.

That is the real deadline, and it is not in any regulation. Every month you run agentic development without capturing intent is a month of unexplainable code you will never be able to explain later.

Five artifacts, five questions

This is what we built, and each piece exists because it answers a question somebody will eventually ask.

The first phase of our harness is product work, done with the product manager rather than for them, and its output is a state file committed to the repository next to the code. What was this for, what was in scope, what was explicitly excluded, which edge cases mattered. That answers why, in the words of the person who wanted it, dated and versioned.

The harness itself lives in the repo, versioned and reviewed like code. Architecture rules, test conventions, the definition of done. That answers under what rules this was produced, and because it is versioned you can check out the rules as they stood on the day, not as they are now.

Evals are a fixed set of real cases, scored the same way every time. That answers how you knew it worked, with a number instead of a recollection.

Review is split. The engine takes the mechanical first pass, and a human always approves. That answers who is accountable, and it survives contact with a lawyer, because a named person approved a specific change on a specific date.

And the logs record what the agent actually did, with sensitive values redacted. That answers what happened, as opposed to what we intended.

Five artifacts. Why, under what rules, how we knew, who approved, what happened. Between them, they answer every question a regulator, an enterprise customer, an acquirer, or a furious board member is going to ask, and they do it in an afternoon rather than a quarter.

The claim that makes this worth your time

None of that is a compliance program. Every one of those artifacts exists because it makes the work faster.

The state file is not there for auditors. It is there because an agent that reads a proper specification does not need re-briefing, and because ambiguity surfaces in the first hour rather than in week two. The versioned harness is not there for auditors. It is there so twenty engineers stop maintaining twenty private setups. Split review is not there for auditors. It is there because human review went from a queue to minutes.

Development speed went up 4x. Bugs went down 28%. The evidence trail was not the cost of those numbers. It was the mechanism.

That is the whole argument, and it inverts the assumption almost every board operates on. Governance is not the tax you pay on speed. In an agentic organization, the artifacts that produce speed and the artifacts that produce proof are the same artifacts. If they are separate in your company, one of them is fake, and I would bet on the documentation.

Why this is commercial, not administrative

The AI Act's transparency rules are live. CRA reporting starts this month, and full technical documentation follows in December 2027. Enterprise procurement questionnaires already ask what AI you use and who reviews its output. Technical due diligence in M&A has started asking what proportion of the codebase is machine-written and how it was reviewed.

Every one of those is the same question wearing different clothes. Can you prove how this was built?

The company that answers in a day wins deals from the company that needs three months, and it will happen quietly, in a procurement review neither CTO ever hears about. That is the part I would put in front of a board, because "we might get fined" moves nobody and "we lost the tender on the security annex" moves everybody.

What it costs, honestly

It is not free, and I am not going to pretend it is.

Writing a real state file with a product manager is slower on day one than a ticket saying "add export to CSV". People who have spent a career keeping the reasoning in their heads experience this as bureaucracy, and some of them are your best engineers. The harness needs an owner, or it rots within two months. And none of it helps with the code you already shipped, which is the largest part of most estates and stays unexplainable.

There is also a limit worth naming. This gives you a record of intent, not a guarantee of correctness. A well-documented bad decision is still a bad decision. What it buys you is the ability to find it, explain it, and fix it quickly, which is nothing but not the same as being right.

Test yourself this week

Pick a pull request from about six weeks ago. Not last week, and not last year. Six weeks, when the memory has faded, but the people are still here.

Give yourself 10 minutes to answer four questions. What problem was this solving, in the words of whoever wanted it. What was considered and rejected? Which parts of it were machine-written? Who approved it, and on what basis?

If you can answer all four inside 10 minutes, you are in a small minority, and you already have the operating model this post describes. If you cannot, you have just measured the distance between how fast your organization ships and how much of that it can account for, and that distance is growing every sprint.

I have watched a lot of engineering leaders spend 2026 optimizing the first number. The second one is where the job is going.

If you want help closing that gap, that is the work I do.