Home / Articles / Send an agent, not a spreadsheet / Versions / v1.2.0
Send an agent, not a spreadsheet: what changed in v1.2.0
From v1.1.0 (2026-10-05, f0b5b72b4) to v1.2.0 (2026-10-05, dc11503b4), paragraph by paragraph.
0 paragraphs added, 0 removed, 8 changed in place, 78 unchanged. About 7 words added and 0 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
← v1.1.0 · all versions · v1.2.1 →
1 unchanged paragraph
Summary: The last article asked how I would build a company on code review. This one turns it round. The buyers of software have alwayslong wanted to know whether a vendor understands what it is selling them, and have never been able to find out, because due diligence was a questionnaire: a spreadsheet of questions answered by the people being asked, disconnected from the code, too expensive to do properly and out of date on arrival. That has changed in the same way code review has. A buyer can now send a prompt, or a small agent under a behaviour policy, to run inside the vendor's environment and come back with a graph of what is actually there: what reaches production that no person reviewed, whether the documentation matches the code, whether there is a threat model and who wrote it, what the last fifty bugs touched, which agents touch the pipeline and under what policy. The vendor reads what leaves before it leaves, and can redact but not rewrite, because the answer is derived rather than written, and companies are careful about what goes on a record. The test is risk-based, not pure: a startup that says it generated its code fast, that the product is not mission-critical and here are the mitigations has passed. What fails is not knowing. That is the consequence that has been missing for the companies that stopped reviewing code, let the engineers go and let anyone prompt features into production: their customers, their investors and their acquirers are about to be able to see it. A startup should double down on understandability, because it has less code and the same tools, and the best way to build the code review company may be to sell it to the people who buy software rather than the people who write it.
9 unchanged paragraphs, under In short
• The consequence that has been missing. Companies that stopped reviewing code, let the engineers go and let anyone prompt features into production have been accumulating liability nobodythat few outside could see. Buyers who can send an agent are the consequence, and investors and acquirers get the same visibility at the same time.
3 unchanged paragraphs, under The form that never connected to anything
Anyone who has sold software to a large organisation has met the spreadsheet. Three hundred questions, the same ones every buyer sends in a slightly different order, about policies, controls, encryption, access, incident response, business continuity, and somewhere near the end, software development: do you review code before release, do you have a secure development lifecycle, do you test. The 2025 edition of the standard one, the Shared Assessments SIG, has 627 questions in its core form and 128 in its lite one. Whistic's 2025 survey of 525 practitioners found the average vendor answering 37.3 assessment requests a month and spending 179 hours a month on them, with 84 percent needing a follow-up. The vendor's compliance team answers from last year's answers. Each answer is true, in the sense that there is a document somewhere with the right title, and each is written so that it commits the vendor to as little as possible. The buyer files it. NobodyOften nobody on either side has read the code, and the questionnaire did not ask them to.
I want to be fair to the people who built this, because the form was the best that could be done at the time. Due diligence was a form because the alternative did not exist. Reading a vendor's code was impossiblerarely possible for a buyer, politically andor practically. Reading a vendor's practices meant interviews, which do not scale and which the vendor prepares for. The data about what actually happened in a vendor's repositories, who changed what, what was reviewed, what broke and why, was not available to the vendor itself in any usable shape, let alone to a buyer. So the industry built the thing it could build, a questionnaire, and then a market of tools that help vendors answer questionnaires faster from their own documents: Vanta's product "combs through your knowledge base of security documentation and previous questionnaires" and answers eighty percent or more of the questions; Conveyor reports eighty-five percent of answers "going out unedited". That is where the automation stopped: at the form, not at the facts behind it. The other kind of tool, the outside-in rating, scores DNS health, patching cadence and IP reputation from the internet, which is a view of the perimeter and says nothing about what is inside.
6 unchanged paragraphs, under What changed
The second is cost. The questionnaire costs days of a compliance team per buyer, per year, and is out of date when it arrives. The agent costs compute, once, and a delta per release after that. That changes who can ask: a mid-sized buyer who could neverrarely afford a technical audit can afford to send a prompt, and so can an investor doing a seed round and an acquirer in the first week rather than the last. And the buyer holds the power to ask, which the July brief put plainly: "in the same way that they go, can I have the due diligence, are you SOC compliant, all you have to do is put an extra requirement in there, because they're the buyers, they control the power." Its other line is the one this whole article rests on: "A buyer asking costs nothing. A supplier not answering looks worse than a supplier answering badly."
24 unchanged paragraphs, under Questions where the non-answer is also an answer, Risk-based, not pure, The behaviour policy is the due diligence document…
NothingLittle has pushed back on this, because there was norarely a consequence. The customers could not see it. The questionnaire asked whether code was reviewed and got a careful yes. The investors saw velocity. The acquirers ran a snapshot scan of the code for licence conflicts and known vulnerabilities, which finds plenty, Black Duck's 2026 M&A audit data found unpatched vulnerable open source in 97 percent of transactions and licence conflicts in 94 percent, and finds neither practice nor understanding, because, as Black Duck's own description of the service says, it is "a speedy, one-time snapshot", and because, as the same paper notes, "targets generally don't share code with potential acquirers". The regulation that is arriving, which I set out in the next section, creates duties but not visibility.
3 unchanged paragraphs
So if I were a startup I would double down on understandability, and I would do it for two reasons. First, the startup can play the same game as the biggest buyer. The tools that build the graphs are the same tools and they are open source. A startup can build the graph of its own repository, keep its threat model with its code, write a behaviour policy for every agent, trace its bugs to its changes, and answer the agent's questions in the agent's own format before being asked. Second, the startup has less code. Understanding ten thousand lines is a week; understanding ten million that nobody alivestill at the company wrote is a programme. The incumbent's advantage was always that nobody could check. The startup's advantage is that it can be checked and pass.
10 unchanged paragraphs, under What the regulation does and does not do, The twist on the last article
Developers have just been told, loudly, that they do not need review. Selling it back to them is selling an argument. Buyers have neverrarely had a way to see inside the software they depend on and are about to be handed duties that assume they can. Selling them the same graphs and the same workflows, framed as due diligence rather than review, is selling a tool to people with a reason to use it, and every vendor that receives the agent has a reason to run it on itself first, which is how the review gets back to the developers through the door that is open.
22 unchanged paragraphs, under What is open, Threads woven here, Sources