This article reports on Markus Eisele’s experience using a coding agent to build Task Viewer, a small convenience plug‑in for IBM Bob used internally at IBM. Task Viewer is not a critical production component; it exists to help some internal users and to serve as a real‑world experiment in how much implementation can be delegated to an agent.
Why this was a delegation experiment
For Eisele the project was a test of what parts of implementation are reasonable to hand off. How much to delegate depends on what the person doing the task still needs to learn: an engineer who already knows the application may simply check results, while someone learning the system may need to work through parts of the implementation to gain understanding.
Manual verification remains necessary
Even when the agent wrote most or all of the code, Eisele kept a personal requirement to manually verify functionality and design. He used the application to see whether it behaved as intended and whether the interface presented information in a comprehensible way. These questions remain important even for small applications whose implementation was largely delegated.
UI tests and SQL checks
For Task Viewer Eisele created many UI tests to ensure data appeared correctly; these tests allowed repeating checks as the app evolved. However, seeing a number in the right place on the screen does not guarantee it is the right number. To validate calculations he ran SQL queries against the underlying data and inspected the records the application was expected to represent.
That apparently ordinary step requires significant understanding: to check a calculation you must know what the result is supposed to mean and which records should contribute. You need an expectation to compare the application’s output against. Eisele received help from colleagues to uncover relationships in the data that he could not have derived or explained alone.
Why “the agent did 80%” is hard to interpret
Eisele notes that statements like “The agent got me 80% of the way there” are increasingly difficult to interpret. It’s easy to get something running and assume the remaining effort is smaller, but a calculation based on incorrect records may look reasonable until you find a way to verify it. The amount of code an agent produced tells you little about how long it will take to discover and fix divergences between your understanding and the application’s behavior.
External findings and measuring effort
He cites DORA’s analysis of 1,110 responses from Google software engineers, which describes time saved during code generation being used for auditing and verification alongside productivity gains. That supports the point that we should include the time needed to reach an outcome we’re prepared to use when comparing human and agent work. Stopping the clock when the agent reports completion or omitting checks from the human version will skew comparisons.
Eisele also refers to Shen and Tamkin’s randomized experiment with 52 developers learning an unfamiliar Python library. Participants assisted by AI scored lower on an immediate assessment of understanding, but researchers observed that those participants who stayed actively engaged with the AI had better learning outcomes. This suggests we should look beyond whether a feature was completed and consider what the developer learned from the task.
Deciding agent autonomy
Eisele recommends deciding on autonomy before the agent starts by agreeing which parts it should carry out and which parts the developer should attempt. Two guiding questions can help make the choice:
- How much effort will the team need to establish that this result is correct for its intended use?
- What does this developer need to learn by doing this part of the task?
Sometimes verification is the limiting factor; other times we deliberately keep work with the developer to cultivate a skill. Limiting autonomy can be appropriate both to ensure correct results and to create learning opportunities.
Concrete example: a status filter in an issue list
Eisele gives a concrete scenario: a new hire is asked to add a “show only open issues” filter to an issue list in a small Java application. An agent could generate the request parameter, the query condition and the UI changes; for someone familiar with the app that may be sensible. A developer learning the system still has to learn which statuses count as open, where the application selects records, and how the team expects the change to be tested.
He outlines an example test setup: suppose the list shows twenty issues at a time, and the test data contains twenty closed issues followed by five open ones. Selecting “show only open issues” should display those five. If the application first loads twenty issues and then filters them in the browser, the screen will be empty. Working through that discrepancy with a colleague gives the developer an opportunity to understand where filtering and pagination happen. The agent can help with unfamiliar framework code while the developer investigates why the expected issues are missing.
Once the developer can explain the behavior and has a test that catches the mistake, the agent can take on more of the implementation. A later request to filter by assignee lets them apply what they learned. Their explanation during review gives the team a basis to decide how much of the next change to delegate. The initial assignment also gives the new hire experience in asking about requirements and discussing changes with another developer.
Additional considerations
An experienced engineer may also limit an agent’s autonomy when a task touches an unfamiliar part of the system. Eisele needed help with Task Viewer’s data despite being comfortable writing queries. When a task takes the team into an area not yet understood, it makes sense to reconsider how much to hand over. Teams can make verification easier by improving tests and sharing knowledge, or deliberately preserve a learning opportunity for future contributors even after verification has become straightforward.
A developer tasked with learning through work needs time to trace behavior through the application and a colleague to discuss it with. If the team agrees on that learning purpose but then judges success only by how quickly the feature appeared, the developer loses the chance to keep the learning step. The team may end up leaving more checking to the same experienced colleagues while giving others fewer opportunities to develop the necessary knowledge.
Before starting, the developer and the supporting colleague should agree what the agent will handle, what the developer will do and why, and what would justify changing that division later. For the status‑filter example, that might mean allowing time for the developer to trace the request and write the first test before asking the agent to implement the filter; they can revisit the division as understanding grows.
Conclusion
Eisele concludes that he could delegate much of Task Viewer’s coding because he had ways to check results and colleagues to help where his understanding was incomplete. He urges teams to keep creating those conditions as they ask agents to do more: better checks reduce the effort to accept a change, and time spent learning helps other developers become able to make that judgment. Sometimes that means deliberately leaving the first test and investigation with a person, even though an agent could finish them, because if we expect that person to take responsibility for the next change, giving them the opportunity to understand this one should factor into how much we delegate.
