Coding agents need a harness, not another chat box

Chat is becoming too small for coding agents. A canvas is not a safety boundary. Give the agent a task, a test, and a diff you can inspect.

GitHub’s software feed has been making the same point in different ways: chat is useful for intent, but coding agents need somewhere to show the work. A canvas, a diff surface, a terminal, and a browser are more useful than another reply bubble. I agree with the diagnosis. I do not agree that a new surface is automatically a safe workflow.

The mistake is moving from “the agent can edit files” to “the agent has a development process.” On this portfolio, an agent touching BlogPostBody.tsx should know the exact behavior, the files it may change, the command that proves it, and what to do when the check fails. That is the harness. The canvas is only where the harness is visible.

Chat is good for intent. Agent work needs a surface where the plan, edits, and evidence stay together.

Ayush Adhikari

Step 1: Write the task as an observable outcome

“Improve the blog” is not an agent task. “Add two software posts to src/data/blog.ts, keep the BlogPost type valid, and make npm run build pass” is one. Name the behavior, the boundary, and the check. If a human cannot tell whether the task is done, an agent will fill the gap with confident prose.

Step 2: Give the agent a small tool and file boundary

An agent with a browser, terminal, editor, and the whole repository can do impressive work. It can also update generated SEO files, rewrite unrelated CSS, and hide the original problem inside a large diff. Start with one module. Add access only when the task proves it needs more.

• Allow reads across the repository when context is needed.
• Allow writes only in the module named by the task.
• Allow the focused build, test, or lint command required for evidence.
• Require approval before network calls, deploys, migrations, or destructive commands.

Step 3: Keep the plan visible beside the diff

A long conversation is a poor changelog. The useful state is shorter: goal, assumptions, files changed, commands run, and remaining risk. When the agent says “done,” I want to see the evidence without scrolling through forty turns of explanation.

A surface is not a control A canvas can make agent work easier to inspect, but it does not enforce permissions, test coverage, or correctness. Keep policy in code and evidence in the workflow.

Step 4: Make failure part of the workflow

The first failed check is often more useful than the first successful one. If npm run build fails, the agent should read that output, repair the same slice, and rerun the same command. It should not quietly switch to a broad refactor because the original path became inconvenient.

Step 5: Review the result like a human change

Agent-generated code still has to answer ordinary engineering questions. Did it change the intended behavior? Did it preserve the public shape? Are the sources real? A clean diff and a green build are necessary. They are not proof that the idea is correct.

• Copy: visible plans, bounded file access, focused checks, and a compact evidence trail.
• Do not copy: repository-wide write access for a one-file task.
• Do not copy: hiding the diff behind a polished agent summary. The diff is the artifact.

The interface will keep changing: chat, canvas, terminal, browser, pull request. The durable rule is simpler. Give the agent a narrow job, make the work visible, run the check, and review what it actually changed.

Coding agent workflow questions

Why is chat a poor interface for some coding tasks?

Chat is good for intent, but implementation needs a visible plan, files, commands, diffs, and test results. Without those surfaces, progress is difficult to inspect or reproduce.

What is a coding agent harness?

A harness is the bounded workflow around an agent: the task contract, allowed files and tools, validation commands, timeouts, and review step.

Should I let an agent edit the whole repository?

Usually no. Start with the smallest slice that can prove the task, limit the files, and expand the boundary only when the first result is correct.