Assistant versus agent
A code assistant suggests. You stay in the editor, accept or reject each suggestion, run the tests and open the pull request yourself. The unit of work is a keystroke or a function.
An autonomous coding agent is given a task and a workspace. It reads the code, decides what to change, edits files, runs commands, reacts to failures and reports when it is done. The unit of work is a task with a result.
That shift moves the developer from author to reviewer. It only pays off if the result arrives in a form that is cheap to review and safe to reject.
What an agent needs to do good work
A task with acceptance criteria. Agents do poorly with vague goals for the same reason new team members do. A stated definition of done gives both the agent and the reviewer something to check against.
A way to verify. The most valuable input is a command that says pass or fail: tests, type checks, lint, a build. Without it, the agent's claim of success is just a claim.
Project context. Conventions, architecture notes and contribution rules reduce wrong turns. This context should be curated, since anything an agent reads can steer it.
- Acceptance criteria written before the run starts
- A validation command the platform runs, not the agent
- Approved project knowledge rather than everything in the repository
- Limits on time, cost and attempts
The risks that come with autonomy
An agent with a shell can do whatever its environment allows. The controls that matter are structural: which tools it has, which files it can reach, whether it holds any credential worth stealing, and what stands between its output and your main branch.
Prompt injection is real. Text in a repository or a tool response can try to redirect the agent. Instructions telling the model to ignore such text are not enforcement. Enforcement is the tool policy, a secret scan before anything is pushed, an independent review and a human approval.
Agents also fail in ordinary ways. They loop, they exceed budgets, and infrastructure crashes mid-run. A production system needs timeouts, cost caps, a record of every external side effect, and a rule that uncertain operations are never replayed blindly.
How PWR runs autonomous agents
In PWR a task runs as a durable job. The worker makes a fresh clone, creates a task branch from a pinned commit and starts the agent with an allowlist of tools confined to that workspace. The agent never receives the repository token.
When the agent finishes, the platform runs your validation command and records the result. It scans the change for secrets, pushes the branch and opens a pull request with the evidence. A separate review job then reads the pull request with read-only tools.
A person makes the final decision. Approval is bound to a specific commit, and merge passes through a gate that checks validation, CI, review, approval and branch protection. For larger work, a goal plans first, waits for approval, then executes tasks within a budget with a limited number of retries. PWR is clear about its current limits. The default sandbox is intended for trusted repositories. Container isolation is in beta, and network egress controls are not built yet.