What is ABSORB?
Agentic Bottleneck, Speed & Output Readiness Baseline. A diagnostic for one question: can this organization turn faster AI-driven coding into faster, safer delivery?
The name is the reminder: the whole system, not just the development team, has to absorb the new speed.
| Letter | Stands for | Meaning |
|---|---|---|
| A | Agentic | Work done by AI under human direction |
| B | Bottleneck | The slowest stage, which caps end-to-end speed |
| S | Speed | Delivery speed from request to customer use, not typing speed |
| O | Output | Value shipped safely, judged by outcomes rather than activity |
| R | Readiness | How prepared people, process and platform are to absorb faster change |
| B | Baseline | A measured starting point to re-assess against |
What "agentic" means here. Any AI that writes or changes code for a human who stays accountable for it, from an assistant in the editor to an agent that opens its own pull requests. ABSORB is about what happens to that code after it is written, so it does not depend on how autonomous the agent is.
Why: eight principles
AI made code cheap to produce. It did not make software cheap to deliver, because delivery also needs deciding, specifying, verifying, releasing and adopting.
- Writing code is not delivering software. Coding is a minority of lead time, so speeding it up alone lifts the whole by far less. Reports show more pull requests and longer queues at the stages that follow. See evidence.
- The slowest stage sets the pace, and the constraint moves. Fix one stage and the queue forms at the next.
- Trust is the scarce resource. When generation is cheap, verification becomes the expensive step, and human attention is the budget to spend carefully.
- People move from doing to governing. The durable human work is owning risk, defining intent, designing evidence, and being accountable for what ships.
- Readiness depends on the goal. More output and lower cost need different targets from the same capability. Name the goal first.
- Outcomes over activity. Pull-request counts and the share of AI-written code say little if reverts, incidents and rework rise with them.
- Fix the system before the headcount. Cutting people at an unfixed constraint leaves the constraint in place, and the people cut are often the ones who would relieve it.
- Readiness is temporary. Models, tools and costs keep changing. An assessment is a baseline to revisit, not a certificate.
One principle, several laws
The second principle is old: a system's output is set by its most limited part, and relieving that part exposes the next. Several well-known ideas describe it from different angles. ABSORB uses them as lenses, not proofs.
| Law or idea | What it says | What it means here |
|---|---|---|
| Amdahl's law | Speeding up one part is capped by that part's share of the whole | Faster coding helps little when coding is a minority of the path |
| Theory of constraints | Output is set by the slowest stage; fix it and the next becomes the limit | Fix the binding constraint first, then re-assess |
| Little's law | Work in the system equals arrival rate times time spent there | If agents add changes faster than people clear them, queues and waits grow |
| Queueing theory | Waiting climbs steeply as a stage nears full utilization | Reviewers at full capacity make every change wait; leave slack at gates |
| Brooks's law | Adding people to a late project tends to make it later | More reviewers is not a direct fix for a stalled stage |
| Goodhart's law | A measure that becomes a target stops measuring well | Targeting PR counts or AI-code share invites gaming |
| Conway's law | Systems mirror the communication structure that builds them | Hand-offs between teams become delivery stages |
The third column is ABSORB's interpretation, not a claim by the original authors.
Why the name
It borrows on purpose from absorptive capacity, a firm's ability to recognize new outside knowledge, take it in and put it to use (Cohen and Levinthal, 1990, doi:10.2307/2393553). That idea is about learning. ABSORB applies the same intuition to delivery: a new capability pays off only as fast as the organization around it can take it in.
What ABSORB is not
Not a tool-selection exercise, not a productivity audit of individuals, not a headcount-reduction model, and not a validated benchmark. It can inform a headcount decision; it does not make one.
The mistakes it is built to catch
- Cutting headcount while the real constraint sits elsewhere.
- Scaling agent output into a review queue that cannot grow.
- Letting green CI alone mean merge for every change type.
- Using the same model to write the code, the tests and the review.
- Reporting the share of AI-written code as success.
- Treating the assessment as a one-time certificate.
Next: the method.