Nothing was enforcing it
How we Organise
The junior work did not disappear, it moved
Sumin Yu and Taesup Moon interviewed fourteen people in South Korea, juniors about to enter software work and the seniors above them, and read the transcripts with reflexive thematic analysis. They came away with one pattern and gave it a name. Absorption: the junior work does not disappear, it moves, into work a senior now runs alongside the machine. Three things follow. Juniors stop doing the work by which people used to become good. Universities have already normalised the same pattern, so the route closes before anyone is hired. And the two groups read the situation differently, which is what stops either side correcting it alone.
The evidence for this has been thin in a specific way. We hold that taking the junior work away removes the route by which people become senior, and until now that rested on hiring counts and on controlled studies of individual task performance. Counts tell you the route is narrowing. Experiments tell you a task got faster. Neither can show the thing in between, which is how the narrowing actually happens inside a working week. This is the first group of people asked about that directly, and what they describe is what we said would happen.
Fourteen people in one country. They report what they perceive rather than what they can later do, and somebody could hold that the route is being rebuilt around review and judgement rather than removed. Nothing here settles that. It moves the argument off the hiring counts and onto something a firm can look at in its own teams.
How we Build
The rework did not fall as the session went on
Bowen Jiang and five colleagues started from an old observation: people cannot tell you a constraint until something exists for them to react to. Benchmarks are built so this never happens: the requirements are fixed before anything is written. So the authors went to 3,553 real coding-agent sessions instead. They coded each one for requirements arriving after implementation had already begun, and where they could replay the repository they tied each arrival to lines the agent had written and lost. A late requirement is followed by about twice the rework of an ordinary edit. That survives the checks they ran against it. It does not shrink as a session goes on. And in a controlled experiment, telling people in advance that late requirements were coming changed nothing measurable about how much was lost.
We sell thin increments partly on this. Work in pieces small enough to finish and judge before deciding what the next piece is, and let what one piece settles decide that. If that loop ran the way we describe it, a session ought to get less wasteful as it goes, because each piece settles something the next one would have run into. It does not get less wasteful. And the intervention that should have helped most, warning people that requirements will arrive late, did not help.
We may be wrong about the second half of what we sell. The first half survives: small pieces mean the rework is caught inside a session rather than after a release, and that is worth having. The claim that has to go is the one clients hear as a saving, that slicing thinner will reduce what gets thrown away.
There is room to disagree. The authors do not demonstrate cause, several of their intervals are wide, and chat sessions are not a team living with one repository for a year. Deleted lines are a proxy for rework, not the thing itself. Replacing a wrong implementation on day one is the loop doing its job. A reasonable person could read the same numbers as evidence that the loop is working as intended, and that the rework is what finding out early looks like. That reading is not the one we have put in front of clients.
If it holds, we stop telling a firm that thinner increments will cut what its coding agents throw away. That matters most to whoever chose the delivery approach on that basis, because the saving they were promised is not the one the evidence supports.
How we Assure
A hijacked sub-agent reached 1.5 actions instead of 8,100
A mean of 1.5 against 8,100. That is what Dantuluri and Sundi measured across 2,000 randomised scenarios: the number of actions a compromised sub-agent could still reach with their authorisation broker in front of it, against the number it could reach when the parent simply handed down its own credential. They set the bar at what they call an untrusted model. A system counts as correct only if an agent that has been fully prompt-injected still cannot do more than it was authorised to do. Against four adversaries, among them the confused deputy, they derive eight requirements. A runtime built the ordinary way, on broad bearer credentials with the authorisation decision made inside the model, fails all four. Across LangGraph, CrewAI, AutoGen and the Model Context Protocol authorisation model, three confine nothing of their own and one confines partially. No single standard covers the set. Their broker holds against all four. It turns away eleven direct attacks on its design. It accepts none of 200,000 forged tokens. It costs about 2.6 microseconds a decision.
That last figure is the one that closes the usual argument. We ask that an agent hold a credential of its own, short-lived, no wider than the person who set it going, and that each further hand-off cut it down again. The objection has always been that this is overhead nobody has time for. It is not overhead anybody can measure.
The finding also moves where the narrowing has to live. What fails here is the authorisation decision taken inside the model, which is where a team reaching for the obvious build puts it. A firm that can describe how its agents narrow authority, and has implemented that narrowing in the agent’s own reasoning, has described the thing rather than done it.
One broker, evaluated by the people who built it. The frameworks were assessed as they ship rather than as a careful team would set them up. The scenarios are randomised rather than drawn from anyone’s live traffic. A mean of 1.5 says nothing about the worst case.