Forge Fate
English
AI

When Developers Can Delegate More, What Do They Need to Decide?

5 min read

The previous article looked at how to check what an agent read and ran after taking on a task. This time, let’s start before the work begins. If a developer does not yet know the cause or the solution, how much can they delegate, and what should they decide first?

Consider an illustrative request: “The list view is slow. Fix it.” The request does not say what needs to improve. Which user is doing what when it feels slow? How much data is involved? Under what conditions can the problem be observed again? The developer does not have to answer all of those questions before delegating the work. They can ask the agent to investigate and propose a clearer goal first.[S1]

Define the Investigation Before Asking for a Fix

Compare these two requests. Both refer to the same hypothetical list view.

Vague request: “The list view is slow. Fix it.”

Request with decision boundaries: “First, investigate which user tasks and data volumes make the list view slow. Identify reproducible conditions and establish the current state. Then propose a performance goal and possible approaches. Preserve sorting, pagination behavior, and the response contract.”

The second request does not presume to know the bottleneck. It limits the immediate outcome to investigation and a proposal. For example, the agent might determine whether the problem appears when a user opens the first page or moves through multiple pages, and what data and environment are needed to observe it. There is no repository or measurement data for this example, so we cannot say which situation is problematic or what causes it.

A performance goal follows the same sequence. Without a baseline and reproducible measurement conditions, it is hard to choose a meaningful target. At that point, the task can end with a proposed target based on the investigation. Receiving a proposed target is different from declaring the improvement complete. Completion requires agreement on the target and how to verify it, followed by evidence from the changed system. Codex’s guidance on Goals also recommends defining the desired result alongside evidence for verification.[S1]

Delegate the Solution, but State What Must Stay the Same

Based on the investigation, the agent can identify possible causes, compare approaches, and propose a plan. An official example of a long running task likewise gives Codex a goal, constraints, deliverables, and completion criteria, while leaving it to develop a phased plan.[S3] Delegation does not require the developer to prescribe the implementation in advance.

For this list view, though, it helps to say what an improvement must preserve: sort order, behavior when moving between pages, and the response contract callers rely on. That sets a boundary around proposals that would change what users or callers see. These are conditions for the illustrative request, not a claim that we have inspected a real system’s contract.

The request can also define where the agent may choose for itself. In this example, it can investigate, select, and make local changes within the existing structure, provided those conditions hold. If it concludes that the work calls for a DB schema change, a shared cache, or a public contract change, it should present alternatives before proceeding. The developer can then compare their cost, compatibility effects, operational burden, ease of rollback, and the reasons for each choice before setting a new scope.

This boundary is a policy chosen for the example, not a universal approval rule. In another system, even a local change might have wide effects. A schema change that follows an established procedure might already fall within the delegated scope.

How Do You Choose When to Step Back In?

When I choose where to step back in, I look at three things together: the reach of a change, how easily it can be reversed, and what remains uncertain. If a change has broad effects, is difficult to undo, and rests on limited evidence, there is more reason to review the alternatives and their rationale before it goes ahead. If its effects are narrow, it is easy to reverse, and the conditions it must preserve are clear, there is more room to delegate the choice. This is my way of setting a task boundary, not a product rule.

For the list view, that leads to concrete questions. Can a change within the existing structure preserve sorting, pagination, and the response contract? If the proposal requires a schema change, what happens to the relevant data and deployment process, and how could the change be reversed? What operational work would a shared cache add? How would a public contract change affect existing callers? The developer can expand the agent’s scope after comparing the answers.

Permission to run a command, or a technical approval to do so, does not establish that a design choice is sound. Authority to execute a change and the reason to choose it are separate questions.

Ask for Different Evidence at Each Stage

The deliverables for the initial investigation stage are the user tasks and conditions where the problem appears, a reproducible way to measure it, the observed baseline, possible causes, alternative approaches, and a proposed performance goal. Conditions the agent could not verify should be visible too, so the next decision can account for them. The agent should distinguish observations from inferences when describing possible causes.

If the work moves to an improvement stage, the developer and agent should first agree on the proposed goal and verification method. To judge completion, they would need evidence gathered after the change using that method, plus confirmation that sorting, pagination behavior, and the response contract still meet the stated conditions. This article contains no actual measurements or changes, so it cannot claim that any approach worked or that an improvement is complete.

Connecting the desired result, conditions to preserve, task boundaries, and verification evidence also aligns with the official guidance on Goals.[S1] Those conditions do not require a separate document. The guidance describes an ordinary prompt as suitable for a small, one-off change, while a development workflow presents goal and plan files as optional conventions.[S1][S4] The boundaries in this example could fit in a single prompt. If the work grows long enough that decisions need to be carried forward, a Goal or Plan may help.

Being able to delegate more also means being able to ask for an investigation, alternatives, and a plan.[S1][S3] A useful skill for developers, then, is the ability to explain the goals and conditions behind a proposed choice—and revise those criteria when new evidence appears.

Pick one development task you expect to delegate next and write down brief answers: What result do you want? What must stay the same? What may the agent decide on its own? Which changes should come back to you for a decision? What evidence would show that the task is complete? Once the work is delegated with those boundaries, another question remains. The next article asks: “How Do I Evaluate Code I Didn’t Write?”

Sources

Report an error or share feedback

Open a draft with this article’s title and URL. Review the message and recipient before sending.

To: [email protected]

Open email draft

If no email app opens, copy these details into your usual email service.

Contact information

Related posts