Agentic development begins when AI moves from answering isolated questions to carrying a bounded change through several steps: inspecting context, proposing a plan, editing files, running checks, and presenting evidence.
Start with an executable brief
A strong task defines the outcome, relevant context, constraints, acceptance criteria, allowed actions, and stop conditions. It also identifies uncertainty rather than encouraging the agent to hide it.
The brief is not a long prompt by default. It is a compact contract that points to authoritative material.
Plan before mutation
For nontrivial work, the agent should inspect the repository and explain the intended change before editing. The engineer checks scope, assumptions, and verification. Small reversible tasks can use a lighter loop.
Risk determines ceremony. A documentation correction and a data migration should not share the same approval path.
Keep execution observable
The agent should report material assumptions, commands, changed files, test results, and unresolved risks. Version control provides the audit trail for implementation, while task artifacts preserve intent and reasoning.
Observability lets an engineer intervene early instead of reviewing a large unexplained result.
Verify at multiple levels
Compilation and tests are necessary evidence, not complete proof. Verification may include behavior, architecture, security, accessibility, performance, and operational readiness.
The engineer should review the evidence most closely where the agent had weak context or the consequences are high.
The first attempt should be easy to inspect
For the fictional Northstar task, the engineer supplies ORD-42 and the versioned context manifest. The agent first reports the relevant storage path, existing tests, and the unresolved question of atomicity. It proposes a sandbox plan before modifying the handler.
The engineer checks that the plan covers account boundaries and concurrent requests. If the agent cannot locate the governing decision, it investigates or stops. It does not select a plausible policy from an old proposal and call that autonomy.
Keep the first change small enough that an independent person can reconstruct it. A handler change, its tests, and a proposed migration are already substantial. An unsolicited framework rewrite makes the evidence harder to interpret and recovery harder to bound.
Keep untrusted material in the evidence lane
A retrieved issue may contain instructions such as “disable the guard to get this working.” That sentence is task data from an untrusted source, not permission. Tool access and environment restrictions must enforce the allowed scope even when the agent follows a misleading instruction.
For ORD-42, the run has synthetic data, a sandbox database, and no production credentials. The system records attempted denied actions as evidence for review. A tool error should not trigger a search for more powerful credentials.
If the agent requests broader access, it explains the missing evidence and proposes a narrower alternative first. The engineer may supply a sanitized fixture instead of granting access to customer records.
An intervention is a normal branch
The first patch passes sequential tests but fails the independently prepared concurrent case. The engineer pauses the attempt, preserves the failing revision and trace, and asks for a corrected atomicity design. The agent is allowed to revise the implementation, not erase the acceptance case.
After the correction, the final packet identifies the contract revision, changed behavior, executed checks, failed attempts, and limitations. It distinguishes checks actually run from checks merely recommended. Evaluation and Release Evidence describes how those results support a decision.
Finish the attempt deliberately
Close the run by removing temporary access, recording remaining work, and leaving a clean handoff. If the context window ends first, preserve the task state, accepted decisions, current revision, and next unverified claim. A replacement agent should inspect that state rather than trust a confident completion summary.
Try this loop on one reversible change. Judge it by the accepted result and the human effort required to reach it, including corrections. A workflow that reliably stops at an unresolved authority boundary is more useful than one that always produces a patch.