By Kwame Boateng
AI-assisted coding is often described as a faster version of pair programming. That comparison is now too small. When an agent can inspect a repository, change several files, run tools, generate a preview, and open a pull request, the central collaboration problem is no longer simply “Can it write code?” It is “Can people see, review, approve, and later reconstruct what happened?”
This is why the most important design shift in agent-assisted software teams may be the move from private prompts to visible workspaces. Slack Code, for example, is described as combining project channels with coding agents, code-diff auditing, live HTML previews, feedback and approval workflows, automatic archiving, and audit logs. GitHub’s Copilot app has also added a “My work” pane for organizing issues and pull requests across projects. These features point toward a practical principle: an agent’s work should look less like an opaque answer and more like a change set moving through a controlled production process.
The chat is not the work record
A conversation with an agent can be useful for exploring an idea, but it is a weak system of record. Important details can be buried in a long thread: which files changed, which commands ran, what assumptions the agent made, what a reviewer rejected, and whether the final result differs from the first proposal.
A durable workspace makes those details inspectable. It should connect the request to a specific repository or project, preserve the agent’s plan, show tool actions and file changes, link to tests and previews, and record who approved the result. The exact interface can vary—an issue tracker, pull request, collaboration channel, or agent console—but the information should survive after the session ends.
This matters for ordinary engineering reasons, not only for compliance. If a bug appears two weeks later, a team needs more than the final diff. It may need to know the original requirement, the generated plan, the test evidence, the reviewer’s comments, and whether a human explicitly accepted a risky trade-off. A durable record shortens that investigation.
Five layers of visible work
Teams adopting coding agents can treat each change as a small, inspectable case file. Five layers are especially useful:
- Intent: the issue, acceptance criteria, constraints, and requested scope.
- Plan: the agent’s proposed approach before it edits files. For a non-trivial task, this is an approval checkpoint, not decoration.
- Diff: the exact additions, deletions, dependency changes, configuration edits, and generated assets.
- Evidence: test results, lint output, security checks, screenshots, and a live or deployable preview where relevant.
- Decision record: reviewer comments, requested changes, approval, rejection, rollback, or follow-up work.
The point is not to force every change through a heavyweight committee. A typo and a payment-flow change should not have identical controls. The point is to make the level of scrutiny proportional to the potential impact.
Approvals should be tied to actions
“Human in the loop” is too vague to be a useful control. A person might approve a plan without seeing the resulting diff, or approve a code change without noticing that the agent also modified a deployment file. Better workflows state what approval permits.
For example, a team might allow an agent to read a repository and run local tests automatically, require approval before writing outside a designated branch, and require a separate approval before merging or deploying. An agent could propose a database migration but be prohibited from executing it in production. The UAE’s proposed approach to classifying which tasks agents may complete versus merely recommend reflects this broader pattern: autonomy should be assigned by task, not assumed globally.
Approvals also need scope and expiry. An approval for “update the landing-page copy” should not silently authorize a new analytics package. A plan approved yesterday should not automatically cover a materially changed diff today. The interface should make those boundaries visible.
Previews turn review into inspection
Code review is often easier when people can inspect the result rather than infer it from source files. A live HTML preview can reveal broken spacing, missing states, inaccessible controls, or an unintended change in navigation that a reviewer may overlook in a textual diff.
Previews are not proof of correctness. They should sit beside, not replace, tests and source review. But they create a common object for discussion: a reviewer can point to a specific screen, state, or interaction and leave feedback attached to the proposed change.
This is particularly valuable when non-specialists are part of the review. A product manager may not be able to assess a framework change, but may be the right person to confirm that the workflow matches the requirement. A designer can validate a visual regression. A security specialist can focus on permissions and data handling. The agent-assisted workspace can route each question to the person best placed to answer it.
Diffs need context, not just color
A familiar red-and-green diff remains essential, but agent-generated changes can be broad enough to overwhelm a reviewer. Teams should ask agents to keep commits or change groups narrow, explain why each substantial file changed, and identify generated or vendor files separately.
Useful review prompts include:
- What user-visible behavior changed?
- Which files were changed only to support the implementation?
- What assumptions did the agent make about existing behavior?
- Which tests were added, modified, or not run?
- Could this change affect permissions, data retention, billing, or external APIs?
These questions turn review from a vague request to “look this over” into a repeatable examination. They also help expose a common failure mode: a plausible feature accompanied by an incomplete test update or an accidental configuration change.
Archive the reasoning that matters
Preserving every token of every model conversation is not automatically useful. Long histories can be expensive to store and difficult to search, while context-compaction research warns that summaries can lose important information. A practical audit trail should therefore preserve decision-relevant artifacts rather than indiscriminately saving everything.
At minimum, retain the request, approved plan, final diff, tool and test results, preview or deployment reference, reviewer decisions, and any exception granted. If an agent used external sources or retrieved internal documents, record the relevant source references and the point at which they informed the change. For high-risk work, retaining the complete interaction and execution log may be justified.
Make records tamper-evident where the stakes require it, and define retention rules before a crisis. An audit trail that disappears when a channel is archived—or that cannot distinguish an amended result from the original—will not support a serious investigation.
What this changes for software careers
The emerging skill is not merely writing better prompts. It is designing work that another person can inspect and trust. Developers will need to be comfortable specifying acceptance criteria, decomposing tasks, reviewing diffs at scale, building meaningful tests, and deciding where an agent must stop and ask.
Product and design professionals will have a larger role in reviewing previews and clarifying intent. QA engineers can help define approval gates and failure cases. Engineering managers will need to measure throughput without rewarding invisible risk-taking. Technical writers and operations specialists can contribute by making decisions, exceptions, and runbooks durable.
One useful exercise is to take a routine feature and map its evidence chain: request, plan, branch, diff, tests, preview, approval, release, and rollback. Then ask where a future teammate would be forced to guess. Every guess is a candidate for a better workspace, a clearer permission, or a more durable record.
A simple operating rule
Let agents move quickly inside a visible, reversible lane. Give them a defined workspace, restrict sensitive actions, require approval at meaningful boundaries, attach evidence to the change, and preserve the final decision. The objective is not to slow automation until it resembles manual coding. It is to make speed compatible with accountability.
In agent-assisted development, the best collaborator is not the system that produces the most code in isolation. It is the system whose work can be understood, challenged, approved, undone, and learned from.
