Agentic Software Engineering Makes Human Context the Budget

Agentic software engineering is moving the bill into human context.

Code is coming faster, pull requests are piling up faster and validation work lands in ever larger piles of judgment work that still need to be handled by people.

This feeling has been captured by Honeycomb’s Douglas Soo in his August 3 piece, “LLM-driven development: the exhaustion of context switching for senior engineers, and anxiety of growth for junior engineers”. He writes that while agentic software engineering has the potential to increase the amount of software that is developed by engineering teams, it has the risk of shipping more software while understanding less about the software that is being developed. He writes that in LLM-driven development, “context transfer” becomes an expensive part of the engineering loop. The old software development rhythm of Design, Implementation, Validation, Operation (DIVO) is being compressed in implementation time in the new rhythm of design, implementation and validation in agentic software engineering.

Generative AI software development burns human context first

The old software development process had a bias towards the time it took to actually implement the software. So after the team had done a bit of design, the team spent longer writing the code for that design, then there would be code reviews to validate that the code written by the author(s) of the software was suitable for real traffic. After that the software would go live and then the team watched for operational problems, and that in turn would be used for design, implementation, validation and operation of the subsequent versions of the software. This process in software development has been referred to as DIVO, Design, Implementation, Validation, Operation.

This change in software development is important because the cheap part (implementation) and the scarce part (context) have traded places.

As we outlined before, context also becomes part of the design surface. So, within the boundaries of an agentic software engineering project, agents can only process as much context as has been previously stored in and connected between documents, tests, traces, ticket entries, comments, examples and a repository’s overall coding structure. A senior engineer later will have to actually re-construct the agent-shaped system around all those agents and contexts.

It’s an engineering culture problem with an architecture spine, therefore, the limiting resource is no longer keystrokes, but the transfer of judgment to and from the model.

The cost model finally has names

Story points have always been sort of fuzzy. Agentic software engineering makes them even fuzzier.

In the “A Cost Estimation Model for Agentic Software Engineering” paper, the ACEM authors say traditional cost models such as COCOMO II, Function Points, and Story Points assume that software cost is mainly human labor across design, coding, and testing. As software development becomes more agentic, human effort shifts toward planning, specifying, architecting, and validating agent output, while the budget absorbs LLM tokens, human-in-the-loop oversight, and orchestration infrastructure.

That framework is useful. First, it is easy to quantify the cost of token spend for an LLM. Then, the cost of the human oversight can be hand-waved away by stating that the already existing review process covers this. And last, but not least, the costs of the required infrastructure can be hidden in the agentic software engineering harness and all the additional layers such as sandboxes, eval runners, trace stores, routing layers, CI minutes, and permission layers. The improved way of speaking about the multipliers for the agentic software engineering cost estimation is by stating Revision Factors, Context Factors, and HITL Intensity Scores.

Yes. The ACEM paper is early and has constants that are symbolic. The important part is that the authors assert that the cost estimation model presented in the paper has not yet been validated against real project data, a point worth reiterating in order to keep other people from using this work in a mistaken fashion and prematurely to estimate the costs of agentic software engineering.

Quit pretending the following costs do not exist and start measuring them inside the organization.

Also note that count of retries that change direction (as opposed to just more of the same) will be relatively high. So too will be count of review passes that find product misunderstandings (as opposed to simple syntax errors). There will be high count of time spent by engineers in explaining why a 'cleaner' abstraction actually violates an operational invariant. High count of instances where a reviewer cannot approve a change because the relevant branch does not have relevant traces, screenshots, migration plans, or rollback plans (i.e., they are not able to make sense of the change).

These are the true costs of agentic software engineering, costs that should be incorporated into the budget for agentic software engineering.

Context transfer is runtime state

Agents also use organizational state to generate code.

To my knowledge, this is the formal version of the problem description given in the paper on Context Compaction Theory. Note that in modeling tasks that are to be carried out by coding agents, model calls have bounded context windows. Therefore, agents have to compact the context states that they accumulate while working on a task. They do so by either selecting parts of the state and generating a summary or by generating a summary right away. The two games that are modeled in the above paper are a Context Selection Game and a Context Generation Game. It is then possible to relate generation to one-way communication complexity.

That sounds abstract because it is. Still useful.

Every team is already running a human version of this game. Senior engineers join conversations, ask questions like “What matters here?” and help to steer the conversation in the right direction. Reviewers decide which files to open, which logs to trust and which product edge cases smell wrong. When writing a PR description, deciding what to put in a ticket and what to delete from chat, teams are making decisions about what matters and what doesn’t.

Stale system knowledge costs. We’ve already established how documentation drift affects the use of coding agents, but the same drift to documentation affects humans in the same workflow. So an agentic coding workflow that is based on a poor representation of the current system will lead to problems, not just for the agents but for the humans too in the same workflow. The agent follows the out of date README. The reviewer has the current state of the live system in their heads. The junior engineer does a diff to find out what’s changed and learns a new rule that’s actually wrong.

This is where agentic software engineering can become uncomfortable. A team can be able to produce more code, but at the same time reduce the shared understanding of a team. The throughput graph for such a team can look great, but when the live system asks a question that no one can answer, then there is a problem.

Make context a build artifact

Package the context where the work happens.

So instead of documentation as tedious implementation detail, we turn repeated human explanations into artifacts (as mentioned above) to support the agentic engineering loop.

This is also the humane version of pairing in the LLM era. Honeycomb argues that LLM-based development moves pairing away from typing code together and toward rapid design and validation in a “rapid feedback” style, with senior engineers modeling judgment and junior engineers driving the actual implementation. That beats generating a huge number of PRs and reading comments on each of them after they’ve been put in the queue and fallen far behind. Queue-backed review comments are not mentorship just because the diff came from an agent.

A technical approach would be to code up an ‘AtumAI’ style agentic approach to generating datacenter control plane policies. Such an approach would first compile natural language goals into formal specifications of objectives, constraints, decision variables and an evaluation methodology. It would then search for solutions to the formalized problem. In evaluations of such approaches, it has been found that the policies generated by agents for control of datacenter control planes outperform the same policies that have been hand-engineered by experts in terms of various metrics for use in workload placement, for scaling of computer resources, and for management of power in datacenters in AtumAI’s evaluation.

This is a narrow test, but it illustrates an important point. In general, the more context an agent gets about the world it is acting in, the better it will become. This is particularly the case when the prompt that is given to the agent is not as good as a specification, for example. The cleverly worded prompt is not as good as the eval. The heroic reviewer of the diff is not as good as a workflow that records why a change is safe.

When a pattern repeats, promote the behavior into deterministic execution. I have previously noted that exploration should turn into straightforward coding work when the shape is known. The same thing applies to engineering culture. If a senior engineer explains the same operational invariant for the third time, stop burning senior attention on rediscovery. Put that invariant in code, tests, agent instructions, and review checks where it can be found again.

Ownership survives by becoming explicit

Agentic coding means branch sprawl and weak ownership.

The better bargain is boring. Fewer disconnected work streams. Stronger handoff artifacts. Live traces that feed back into the next prompt, test, and acceptance criterion. Review that asks whether the code meets product intent, whether it is safe to operate, and whether the work captured enough learning to make the next run cheaper.

Process evidence matters here. The ACWorld paper on agentic commerce found that final state alone can miss evaluated errors, while incomplete trajectories still hold useful signals. Its environment validates actions before shared state changes and records interactions for reproducible evaluation of ongoing transactions. Software teams have the same problem in a less exotic outfit. A green merge is a final state. The interesting evidence lives in the path: what the agent tried, what the reviewer rejected, which assumption changed, which trace proved the fix, which rollback path exists.

Software engineering with agents will reward those teams who treat the human context in their process as scarce runtime input. Thus, it should be spent where necessary i.e. where high quality judgment is required. All other situations where similar explanations are needed in the future can be saved by turning them into artifacts that can be used by the agents as well as by the human for verification.

So fast as to be worth only one line in a software engineering budget, implementation speed!