Nobody had to form a view
How we organise
Sabry E. Farrag looked for the place where responsibility is settled. He found two, and they do not refer to each other. One is the set of platform controls that set what an agent may do, and the other is the provider’s terms, which name who is responsible for what it produces. He read both against the workflow events that leave a record, across four agentic coding tools and eighteen policy documents from seven providers. At each event he wrote down who holds authority, who executed, who must check, and which record survives. The layers disagree. One provider bars the developer who assigned a task from approving the resulting pull request. Another documents an agent that approves pull requests below a configured risk threshold and can dismiss reviews. Attribution runs the other way from one provider to the next. No trailer names an agent as author, though one provider uses the co-author trailer for it. Farrag then replaces the usual split between enforced, advisory and absent checking with a grid, separating whether a mechanism compels the check from who does the check.
We ask a team to write down every decision it waits on from outside. The register names who decides and who owns it on each side, and it would come out complete at every event Farrag describes. It asks for a named decider, and an agent can be named. So the register records a name. What it does not record is whether that name can form a judgement. Nor does it record whether the mechanism compels the check or merely advises it. Those are the two the grid separates, and we may be wrong about what a complete register evidences. The position holds only if the register records both.
The reach is limited and Farrag says so. He read the policy rather than the practice, and no harm is claimed. His own argument is that code-review research had already found the approval record carrying less than the terms assume. A reader could reasonably say that agents changed the volume and no more. If the finding stands, we stop telling a client that a complete decision register evidences accountability, and the register gains a field that some clients cannot fill.
How we build
State of AI Impact in Engineering: Q2 Report (DX)
DX measured more than 500 engineering organisations against its own Core 4 and its AI measurement framework. It starts with a rise. Median weekly output went from 1.42 to 1.94 pull requests per engineer per week over four quarters, a rise of 37 per cent. More than 90 per cent of engineers now use these tools, so the use has to pay. Under the rise, the figures move the other way. Pull-request size nearly doubled in the same window. Review turnaround declined, and so did incremental delivery and iteration speed. The average developer experience index fell from 67 to 65. Change confidence fell in the same window that code maintainability rose, and those two have not moved apart before. Median quarterly spend on these tools went from about 1,500 dollars to about 44,000. That is roughly 28 times in the tech sector alone. Over the same four quarters, the ratio of time on new features to time on maintenance stayed flat. Time saved is real and now runs over six hours a week. None of it has turned up as new work.
We hold that what limits a team is checking the work rather than producing it. Cheaper output should pile up in front of the people who check. Four quarters of these figures show that, with the review step slowing as the volume grows. This is the second source to bear on that position, and the first argued the other way. Microsoft studied tens of thousands of engineers and measured a 24.0 per cent rise in merged pull requests per engineer per day. They could show no quality cost against it. Both readings now stand, and a reader can say which of the two measured their own case.
DX sells the measurement. The figures come from telemetry rather than from asking people, which helps, and DX is still the source. The gains also fall to organisations under 100 engineers and to the tech sector, and the gap to everyone else is growing. A large traditional-industry client should not expect this at all.
How we assure
CompoSkill: Compositional Skill Chain Attacks from Individually Scanner-Passing LLM Agent Skills (Liu and others)
Mingxiao Liu and colleagues built two attackers against an agent skill marketplace. The white-box one knows which skills the victim has installed, and names them in sequence. The black-box one knows only a role profile. It downloads the top marketplace skills for that role. Then it builds a graph of how their outputs and side effects connect, and searches it for a chain whose lures never name a skill. Both ran against a benchmark the authors built. It holds 1,140 records drawn from long professional workflows, across five threats and six scenarios on two agent platforms. Chains formed in up to 83.3 per cent of white-box attempts and 80.6 per cent black-box, while existing scanners blocked a limited fraction of them. One result helps a defender. A bridge skill raises the attack rate, and the rate falls once a chain runs past three skills.
We already hold that the combination is the risk rather than the component. We ask that each agent be scored on three conditions together: untrusted content coming in, private data within reach, and a path by which something can leave. The trouble is which combination we named. Those three are properties of one agent. This risk is a property of a chain across several skills, each of which passes its own controls. An agent could score clean on all three and still build the chain. So the position holds only if what gets scored as one thing is the installed skill set and the graph it forms. That is not what we ask for today.
The benchmark is the authors’ own, built on two platforms. The block rate is measured against scanners that were never designed for chains, so somebody could reasonably say the finding is about today’s scanners and will date. If it stands, we stop telling a client that a certified skill marketplace bounds their risk. The check they run per agent has to run again per installed set, every time somebody adds a skill.