The speed was the same for everyone
How we Organise
Repository maturity and the cost that does not show up in velocity
Denisov-Blanch and seven colleagues posted this on 26 August. They built RAMP, a four-level maturity model. RAMP is read off the configuration a team commits to its own repository to steer AI tools: behavioural rules and coding standards at the bottom, named agents above that, several agents orchestrated at the top. Almost all practice sits in the first three levels. Across 441 repositories the levels behave as a scale, and human annotators matched RAMP’s labels on 97 per cent of a held-out sample.
Two findings come out of re-estimating an existing agent-adoption panel inside each of them. Agents accelerate everybody: commits rise 28 to 38 per cent whatever configuration a team has committed. Quality does not follow. Among agent-first repositories, where the contrast is identified, those with no committed configuration show roughly twice the increase in cognitive complexity, 53 per cent against 27, and 1.7 times the increase in static-analysis warnings. The configuration is rarely revisited: 73.8 per cent of it is committed once and never changed again.
We ask a client to compute what one good outcome costs, fully loaded, and to keep computing it. The measure is meant to price the work rather than count it, so a team cannot book a gain that a later bill takes back.
The trouble is where the measure is read. Cost per successful outcome settles when something ships, and both groups here ship at the same rate. A firm computing it faithfully across these repositories would find the two indistinguishable, while one of them accumulates twice the complexity and 1.7 times the warnings, and somebody pays for that later, reading the code. We may be wrong that the measure catches this at all. This is not the first source to bear on that position. Vercel’s July gateway index bore on it two days ago, where the price per token fell 13.6 per cent while the bill rose 37, and that one showed the measure working. This one shows where it cannot see.
RAMP’s maturity is observational, and the authors say so: engineering discipline or model capability could explain part of the gap, and they present the work as a hypothesis rather than a finding. Public repositories are not a client’s estate. Somebody could reasonably conclude that teams committing configuration are better teams, and would have shown the same difference with no agent anywhere near them.
If it stands, we stop telling a client that a stable cost per successful outcome means the work is being done at a stable cost. The figure needs a second leg, one that reads the state of the code an outcome leaves behind. Without it a client has a flat line and a bill nobody has attributed yet.
How we Build
Vercel on replacing stored credentials with ones an agent asks for
Hedi Zandi and two colleagues published this on 25 August. Vercel Connect is now generally available, after a public beta, and they open on vaults. Putting a long-lived credential in a vault makes it harder to steal and no less dangerous once stolen, because it still never expires and nothing limits what it can do. Their answer is to stop storing one. An application registers a connector for a provider and attaches it to the projects that need it. It then asks for a credential at runtime. That credential is scoped to what the request says it is for, and it expires on its own. Nothing has to prove itself with a second secret, because every deployment on the platform already carries an OIDC identity and the platform uses that to establish who is asking. The beta grew past 100 connectors. Revocation is one command, for one person or for all of them.
An agent’s reach is settled by its credential rather than by a document describing what it may touch. A written boundary is a claim; a credential is the thing the other system actually checks.
Here that position arrives as shipped infrastructure rather than as an argument for it, and the properties listed are the ones it asks for. Lifetime short rather than permanent. Reach scoped to the task named in the request rather than to everything an agent might need. Identity a named application or a named person rather than one shared bot standing in for everybody.
It is a vendor announcement and worth reading as one. Vercel is describing a product it sells, on its own platform, and the mechanism that removes the second secret is that platform’s deployment identity, which a client running elsewhere does not have. There are no adoption figures, no measured fall in incidents, and one named client. A reasonable person could read this as a well-designed feature rather than evidence about how agents will be governed generally.
Nothing changes in what we tell a client. What changes is what we can point at when a client asks whether anybody builds this way.
How we Assure
A review of what military testing practice assumes about the thing it tests
Ulysse Richard and five colleagues posted this on 20 August. Agentic systems are being bought for military command and control under public commitments to rigorous testing and human oversight, and the paper asks what would have to hold for those commitments to be dischargeable. An assurance case needs three parts: claims saying what would count as acceptable, evidence bearing on those claims, and an argument joining the two. The authors reviewed 240 documented testing and evaluation practices across eight evaluation dimensions and three lifecycle stages, and drew out eight assumptions those practices make about the thing under test. The assumptions group into four clusters: that the system can be specified, that it is stable, that it composes, that it can be supervised. Agentic properties weaken all eight.
What erodes is the argument. The claims survive and so does the evidence, which means a result can be correct, honestly obtained, and still not carry the inference from what was tested to what is now fielded. Memory changes state between runs. Tools and retrieved information are chosen at the point of use, and subagents can join an assembly after it was certified. Ten assurance claims follow for the first three clusters. Each is assessed against current and emerging methods, and traced through five scenarios. The last cluster they identify and decline to assess, because evidencing it rests on stability results and on methods beyond the paper’s scope.
The rule we give a client is that any change capable of altering behaviour reopens the assessment, so a release in an affected class carries a fresh verdict rather than inheriting the last one. It is a good rule with a hinge in it: it fires on a change, and a change is something somebody makes and ships.
None of the drift described here arrives that way. The model version can be identical, the code untouched, no release cut, and the system carrying authority this morning is not the one the evidence was gathered on. Our test asks what changed since the last verdict and gets the honest answer that nothing did. We may be wrong to have keyed it there. For the position to survive, the trigger has to take in elapsed operation and accumulated state rather than deliberate change alone. That is close to what the paper reaches for. Bound the mission envelope, assess correctness over a trajectory rather than an output, run the constraints at runtime, characterise the variance rather than assume it, and give the evidence a stated expiry with somebody’s name against it.
This is a preprint and a structured review rather than an experiment, and it does not show a particular testing regime failing in the field. The paper is careful that narrower claims stay recoverable, and what it rules out is the broad claim about behaviour at the level of a whole system. Somebody could reasonably say most client deployments never make a claim that wide.
We stop telling a client that a change-triggered reassessment covers them. It covers the changes they make. A verdict on an agentic system needs a date it expires on. A client whose register shows every system reassessed on its last change has a green board and evidence that may no longer describe what is running.