Field notes / Startup & Product
Give coding agents a boundary before you give them a task
Define agent authority, review gates, and escalation behavior.
A coding agent can turn a vague instruction into a large diff very quickly. Speed makes the authority boundary more important: the task should say what the agent may change, which checks prove completion, and which effects require a person to decide.
Here is an illustrative task: add a search input to a public writing archive. The permitted work includes the archive component, its styles, and browser tests. It excludes production credentials, account settings, and publishing messages. This is a proposed task contract, not a claim about a particular agent product's security guarantees.
Treat source material as input
Repository files, issue descriptions, and downloaded pages can contain instructions. They should not automatically acquire authority over the task. A comment inside a fixture asking the agent to upload credentials is data to inspect, not permission to act.
Agent authority and trust boundaries
Keep untrusted inputs, isolated implementation, human review, and credentialed release on separate authority boundaries.
Illustrative framework · Graphic by Nick JensenRead the diagram as text
Flow from untrusted repository and input, then scoped task contract, then isolated workspace, then checks without production secrets, then human diff review, then separate credentialed release, then observe and recover. Keep untrusted inputs, isolated implementation, human review, and credentialed release on separate authority boundaries.
For the archive example, use synthetic content and an isolated test environment. The agent does not need customer records to prove that a query matches a title. If a test unexpectedly requests production access, investigate the dependency instead of expanding permissions until it passes.
Define the escalation before the surprise
Suppose the implementation discovers that the archive's data source is also used by a private customer page. That is a contract boundary. The useful next action is to describe the shared dependency, propose a narrow change, and prove the private path remains private. It is not an excuse to move the entire repository into the browser bundle.
The escalation contract
Allow bounded reversible work, review external effects, and stop when authority or secret handling is unclear.
Illustrative framework · Graphic by Nick JensenRead the diagram as text
Allow / reversible work: Read source, edit scoped files, run isolated tests with synthetic data.; Review / external effect: Deploy, send messages, change access. Inspect the concrete effect first.; Stop / unclear authority: Unknown owner or secret exposure. Escalate before using more privilege. Allow bounded reversible work, review external effects, and stop when authority or secret handling is unclear.
A practical task brief records allowed paths, prohibited data, local commands, expected user behavior, and who can approve an external effect. “Run tests” needs an environment: a command that sends live email is different from a test using a fake transport.
Review the effect, not the confidence
A reviewer should inspect the actual diff and the negative cases. Does clearing the search restore results? Does an empty query behave sensibly? Does the page still work with a keyboard? Can a source document inject executable markup? A summary saying “all good” answers none of those questions.
Isolation adds coordination work. Very narrow scopes can force repeated handoffs, while broad scopes can hide accidental authority. Start with reversible work and expand the boundary only when the task requires it and an accountable owner understands the effect.
Record unresolved assumptions in the handoff. A local browser check cannot establish production observability or credential safety. For the review side of this workflow, see testing generated code and human review gates. For help setting these boundaries across a team, talk about fractional engineering leadership.
From the idea to the work
Make the workflow useful in a real product.
Bring a product idea, an internal tool, or an AI-assisted workflow that needs a working implementation.