This essay is part of an ongoing series on how enterprise software delivery changes when agents become participants in the engineering system. The series starts with Your Platform Has a New User: The Agent.
Consider a developer using an agent to create a service on your platform. The configuration appears in minutes. Then the pipeline rejects it, the error points to a policy the developer has never seen, and a platform engineer gets pulled into a conversation about which deployment pattern is actually supported.
By the time the service finally ships, the agent's dashboard records a completed task. The platform records another service provisioned. The developer remembers a morning spent figuring out what the two systems meant by done.
All three accounts can be accurate. They end in different places.
In The Best AI Developer Experience Might Be Invisible, I argued that a platform should repair the failures it owns and meet developers where the work gets stuck. That creates a measurement obligation. We need to know whether the developer's day got easier, and what the platform took on to make that happen.
An adoption dashboard cannot answer that question. A ledger that follows the work can.
Follow the work past the tool
Licenses activated and weekly usage tell us whether a tool reached people and whether they use it. Those are useful questions. They are different from whether the work became easier, safer, or more valuable.
When I wrote The AI Operating Ledger, the discipline was to account for the whole path to a verified outcome: context, generation, review, rework, and the consequences of what shipped. The developer experience ledger applies that discipline to the platform's part of the journey.
Start with something a developer actually came to do, such as creating a service, deploying a change, or recovering a failed build. Give that journey a completion boundary the developer and platform team both recognize. For a new service, that might be a verified deployment with the required ownership, access controls, and observability in place. The agent finishing is an intermediate event.
A platform earns its investment when the useful journey gets easier without weakening the outcome or quietly handing the work to someone else.
That is a higher bar than a successful tool rollout. It also tells the platform team where to work next.
Where the saved hour went
Put numbers on the opening example. These are illustrative figures, not measurements from my team. Assume the same service request and the same acceptance criteria before and after adding the agent. Both journeys reach a verified deployment.
| Active human effort per completed journey | Before | With the agent |
|---|---|---|
| Developer prepares configuration | 70 min | 10 min |
| Developer reviews and verifies the result | 20 min | 20 min |
| Developer investigates platform problems | 10 min | 50 min |
| Platform engineer helps resolve the problem | 0 min | 15 min |
| Total human effort | 100 min | 95 min |
The agent saves 60 minutes of configuration work. In this scenario it also picks up a retired deployment example, and the developer spends 40 additional minutes untangling the resulting failures. The developer's net saving is 20 minutes. Fifteen minutes of new platform support leaves five minutes saved across the two people.
Counting only the first row turns a five-minute improvement into a 60-minute success story. Where the Saved Hour Goes made the case for deciding how to spend the dividend. First we have to establish how much dividend survived the journey.
This is a labor comparison, not an ROI calculation. Model spend, the cost of building the integration, and its ongoing maintenance still belong in the investment decision. Neither does this table tell us how long the service took to reach production. People and machines can work in parallel; minutes of human effort are not minutes on a clock.
What the example does provide is a place to intervene. The retired example needs to be demoted, the supported path needs to be authoritative, and the rejection needs to explain the correction. Buying more generation capacity would leave that failure intact. Fixing the platform would make the existing agent more useful and help the next human who finds the same old example.
The ledger has done its job when it changes that investment decision.
Attention is the resource, not the unit
I want to resist the temptation to collapse this into one score. The SPACE research makes the broader point: developer productivity cannot be understood through a single metric or dimension. A platform ledger needs several views for the same reason.
Elapsed time tells us how long the journey takes. Active human effort estimates how much work it consumes. Completion and rescue rates help describe where it breaks. Developer feedback tells us about confidence, frustration, and the effort the systems did not record.
They have different units because they answer different questions.
A 20-minute build that runs while an engineer does useful work differs from a 20-minute build that needs attention every two minutes. The duration is identical. The interruption is not. Even active minutes are an incomplete measure of attention: recovering the thread of a difficult problem does not always leave a timestamp.
So keep asking developers what the journey feels like. The survey is evidence, and so is the trace. If the instrument says the platform improved and its users disagree, the next step is to understand the disagreement. They may be noticing a cost you forgot to count.
Agents leave a different kind of evidence
Developers can hide friction remarkably well. They copy an old repository, ask the person who knows, or abandon self-service and solve the problem themselves. A platform can look quiet because its users have become skilled at working around it.
Instrumented agent runs give us another way to see those obstacles. A run can record the source it retrieved, the capability it called, the error it received, the retries it attempted, and the point where a person took over. That turns part of the journey into something we can inspect and, when the relevant state is retained, replay.
In Your Platform Has a New User: The Agent, I proposed asking whether an agent could discover and complete the approved path without relying on tribal knowledge. Run evidence can help make that test repeatable.
It still needs interpretation. An agent choosing the wrong argument is different from an API rejecting a valid request. A required approval is different from a platform engineer rescuing a broken workflow. Record those separately. A control that stops an unsafe action has done its job, even when the run ends without a deployment.
There is a quieter trap in the completion rate. It can rise because the system got better, or because this week's tasks were easier. Keep the journey type, relevant platform version, and agent configuration with the result. Look at the number of attempts and what was attempted before celebrating a percentage. A model update can change the rate without a single platform improvement.
The trace gives us a place to investigate. It does not assign the blame for us.
The ledger belongs to the people doing the work
A request for fewer tickets can produce fewer tickets. It can also produce a developer who decides asking for help will hurt the team's numbers.
The same problem appears if every human intervention becomes a failure. People will delay escalation, and the dashboard may improve just as the work becomes less safe. Some attention is an investment: reviewing a consequential change, learning why a control exists, or exercising judgment on a legitimate exception.
The purpose of this ledger is to find avoidable effort and make its owner accountable. It should help us improve a shared journey, not rank individual developers by how little assistance they need.
That distinction has to show up in the practice. Sample journeys with the developers who use them. Review the findings together. Retain the evidence needed to diagnose the obstacle, with access appropriate to the code and data involved. Do not turn a request to understand friction into a requirement to record everyone's working day.
The ledger will be least useful in an organization where people are afraid to tell it the truth.
Start with one journey and one decision
Pick a frequent journey whose friction your users can already describe. Agree on what completion means and which controls must hold. Follow a small sample through it, including unsuccessful attempts, and compare like work with like work.
Keep five things visible: elapsed time, active human effort by role, verified completion, unplanned rescue, and the developer's account of the experience. Use the system's timestamps where they are useful and brief estimates where they are not. Mark estimates as estimates. A useful baseline does not need to pretend it is a stopwatch study.
Then classify the obstacle before funding the remedy. Repeated confusion may call for a better error or a canonical example. A routine request may deserve self-service. A necessary approval may need a clearer decision and a shorter wait. A rare exception may be cheaper and better handled by a person. The ledger should allow each answer.
Choose one improvement, name its owner, and repeat the comparison. Check that the gain survives the verification and rework window appropriate to that journey. If later defects or support work consume the apparent saving, keep them in the account. Count the cost of maintaining the fix too.
The platform owner should convene this review, with product teams and the AI program contributing their parts of the evidence. No team should get to end the account at the boundary where its own numbers look best.
There is a leadership decision at the end of that review. If the platform returns time, decide with the team what it is for: deeper engineering work, learning, reducing operational debt, or finishing the day with fewer interruptions. If every saved minute immediately becomes another assignment, we may increase output while leaving the developer experience unchanged. Make that tradeoff explicit.
I would rather take one well-understood journey into the next engineering review than another slide of licenses, prompts, and generated lines. Show where the work went, what changed, and whose day improved.
Adoption tells you the tools arrived. The ledger tells you whether the attention came back.
