During a recent group discussion about Sparse Agents, someone asked how programming could become an ongoing responsibility. When we use Claude Code, or CC, and Codex, we usually give them a task, let them read the code, make changes and run tests, then review the result. This already works well. But if the assignment is to “keep improving a reporting service’s production performance over the next three months,” the work will span many code deliveries.
After a release, its effects may take until the next day, or even several days, to become clear. If performance has not improved, someone needs to investigate again. If it looks better for now, someone still needs to check whether the improvement holds as data volumes grow. Traditionally, people have had to remember these follow-ups. One participant pointed out that people easily forget. That gets to the value of making coding Sparse: give the Agent responsibility for continued observation, judgment and improvement, so it picks up the work when needed.
Start by making the assignment concrete. Suppose I want to improve a business report generated every morning. I need to specify which processing path matters, what data volume to use, where to obtain timing and error information, and how to judge whether a change helped. I also need to set requirements for correctness, resource use and budget, clarify what the Agent may change and test on its own, and establish the conditions for a production release. This gives it a clear account of what to improve and which actions it may take.
Three months is the duration of the responsibility. The next run might be tomorrow, or after the new version has completed a full business cycle. These are separate decisions. Once the long-term objective is clear, the Agent still needs to decide, based on current progress, when another round of work would be useful.
This is where the division between Dense and Sparse becomes useful. Reading code, diagnosing a problem, making changes and testing them require concentrated work on the current task. I call that Dense. Working toward the same objective at different times, waiting for feedback and then continuing is what I call Sparse. Here, “sparse” describes how execution is distributed over time; it has nothing to do with sparse parameters inside a model. A Sparse objective can include many concentrated rounds of Dense coding.
Work intensively when action is useful. Between rounds, retain the objective, progress and next check. Spacing in the diagram does not represent elapsed time.
For the reporting service, the first round could measure the baseline, identify a worthwhile problem, make and test a change, and deliver it under the agreed conditions. The Agent should then record what changed, which version was involved, what data was used for validation, the result, and what still needs observation. Later decisions need to build on those records.
The work then enters an observation period. As someone in the discussion noted, changes involving data often require waiting until the next day for feedback. If there is not enough data from the new version yet, the Agent can arrange a suitable follow-up. There is no need to repeatedly check an unchanged result just to appear busy. If other independent, worthwhile work is available, it can pursue that within its existing authorization.
At the next review, the Agent needs to consider the original objective, earlier conclusions and new operational data. If execution time has not fallen, it needs to reconsider its diagnosis and investigate again. If it has fallen, the Agent still needs to confirm that the measurements are comparable, the results are correct and no new problems have appeared. Passing a test, delivering a code change and meeting the overall performance objective each require a separate judgment.
Using the hypothetical numbers from the discussion, reducing a task from 100 seconds to 60 seconds could indicate progress in that round. These numbers are an illustration, not a measured result. Whether to continue optimizing depends on the agreed objective and the value of further effort. If the requirements have not been met, choose the next worthwhile problem. If the milestone has been reached, move into observation, maintenance or completion.
Individual code changes now form a continuing body of work: a change is followed by an assessment of its effects, and those effects inform the next change. After an improvement, the Agent should explain which problems have been resolved and which still need observation. Further work follows the actual results and continues toward the original objective.
After a code delivery, observe the real effects. Revise the approach if the result falls short; move into maintenance, pause or completion when the agreed stage is finished.
Making this work also changes how people assign tasks. If I still decide what to inspect today, whether to look again tomorrow and when to check after a release, I still own the follow-up. Making coding Sparse means handing over the objective, the way progress will be judged and the scope of permitted action together, so the Agent can organize the routine work already entrusted to it.
This is also where the discussion revealed the value of Sparse Agents. Periodic reports, log inspections and security scans can all be part of the work, but the Agent must also arrange follow-up based on their results. Have the findings been addressed? Did the last change help? Is there useful work to do today? Those questions need continued attention. Routine reports keep people informed; authorized work should not automatically stop because a person has not replied to every report. Decisions beyond the Agent’s authority can be brought back to the person.
From the user's perspective, the important change is delegating continued follow-up. After a code change, the Agent keeps attention on its real effects and pursues further improvements when new problems appear. Each project still needs clear metrics, criteria for validating changes, and limits on independent releases. Whether performance actually improves must be judged from that project's operational results.
Returning to CC and Codex, my classification in the discussion becomes easier to understand. Their usual coding sessions are Dense: they concentrate on the current round of work, can autonomously take many steps and may run for a substantial period. Within the process described above, those coding capabilities can handle diagnosis, changes and validation for a Sparse objective.
The classification depends on the actual way the system works. Claude Code already offers looping and scheduled execution, while Codex automations support recurring work and returning to existing conversations; see the Claude Code scheduling documentation and Codex automation documentation. When a configuration can maintain follow-up toward a long-term objective and adjust its actions based on feedback, it should be judged by the responsibilities it actually takes on. Scheduling is a useful foundation. Results from successive runs must also be connected so the system can decide whether to continue, wait or change its approach.
People define the objective, acceptance criteria and authority. The Agent organizes continued follow-up and concentrates on the coding work needed in each round.
The group also discussed when to stop. One participant wanted to optimize for a phase, then pause and put limited resources elsewhere. That is entirely reasonable. Ongoing work also needs milestones. It can move to less frequent maintenance once requirements are met, pause at a budget limit or end altogether. When it stops, completed work, unresolved issues and current state should be retained so the work can resume later if needed.
Ongoing service still has a cost. Working too often, or repeatedly investigating the same problem, can waste resources. Deciding when to work, wait and stop is therefore part of the responsibility itself. Each investment of effort also needs to be assessed for useful progress.
Making coding Sparse comes down to this change: after delivering code, the Agent still remembers why it made the change, checks the result at a suitable time and decides what to do next. A person sets an ongoing objective; the Agent turns it into successive rounds of concrete work within the agreed scope. The responsibility I want to delegate extends from writing code through observing its effects and continuing to improve it.