AI coding agent: why chat alone isn’t enough to control development agents

Un AI coding agent can analyze a repository, modify multiple files, run tests, fix an error, then continue its work. As these agents gain autonomy, one limitation becomes clear: chat is not a great cockpit.

The issue isn’t the conversation itself. It remains highly effective for stating intent, clarifying a request, or arbitrating a point.

The problem arises when the work takes time.

After dozens of actions, where is the last validated decision? Which file was modified? Which assumption was discarded? Which tests passed? What still awaits human validation?

On August 17, 2026, GitHub highlighted this very issue with its “canvases.” The idea is to persist an agentic workflow’s state in a structured interface rather than asking humans to reconstruct it from a conversation history.

For an IT department, this shift is significant. Controlling an AI software development agent is no longer just about writing better prompts. It requires designing a system where its work remains inspectable.

The challenge is no longer just getting the AI to code

Early code assistants mostly addressed local questions: “Can you complete this function?”

A coding agent works differently. It can receive a broader objective, explore the project, choose a series of actions, and progress through multiple steps.

Google Cloud describes agentic coding as an approach where agents can plan, write, test, and modify code with reduced human intervention.

This autonomy changes the core problem.

When the AI suggests three lines of code, the developer can review them immediately.

When an agent works on a migration, a cross-cutting fix, or a feature over several steps, you need to understand where it stands and why it got there.

Model quality remains important. But it’s no longer enough.

The control interface becomes part of the architecture.

A chat history is not a state

A conversation gives an impression of continuity. Yet it mixes many things: instructions, responses, logs, corrections, changes of mind, and intermediate results.

Eventually, the reader must interpret the history to reconstruct the current situation.

GitHub sums up the issue well in its post-mortem: when agentic work stretches on, it’s easy to lose track of what has been executed, modified, validated, or what still requires human judgment.

For a technical team, the difference between history and state is critical.

A history says:

"Here’s everything that happened."

An inspectable state says:

"Here’s where we stand now."

The latter is far more useful for managing an AI coding agent.

For example, you might see that a migration is in the validation phase, that two tests are still blocking, that an architecture decision has been approved, and that a sensitive change is awaiting developer review.

Humans no longer need to re-read twenty messages to grasp the situation.

What ‘making an agent inspectable’ really means

An inspectable state doesn’t just mean ‘displaying more logs.’

In fact, piling on more data can have the opposite effect.

The goal is to surface the information needed for human decision-making.

For a software development agentic workflow, this may include:

• the current workflow step;
• completed, in-progress, or blocked tasks;
• key decisions made by the agent;
• current drafts or retained changes;
• test and validation results;
• elements requiring human validation.

GitHub illustrates this logic with two distinct experiences.

The first, Java Modernization Studio, structures modernization work around explicit phases such as assessment, correction, validation, and delivery preparation.

The second, Site Studio, tracks the state of different site sections, their drafts, and validation status. Despite very different use cases, GitHub applies the same pattern: define states, make decisions visible, persist work, and maintain human approval points.

This is the model that interests an IT department.

It transforms an agent that “talks and acts” into a system whose progress can be supervised.

Persistent state also reduces a context problem.

With a standard chat, each new interaction heavily depends on what came before.

The longer the workflow, the costlier it becomes to maintain a clean context.

A developer can recall a decision. The agent can revisit elements. A new team member can review the conversation. But all these operations consume time—and sometimes tokens.

A structured interface moves part of this memory outside the conversation.

A task’s status doesn’t need to be re-derived from ten messages. It can be directly recorded as “under review.”

A validated decision doesn’t need to be restated at every step. It can become a persistent element of the workflow.

We thus shift from a logic wherethe conversation contains the work to one wherethe conversation drives a shared work state.

This is a critical nuance for AI agent orchestration.

For IT departments, the real benefit is governance.

A more autonomous agent isn’t necessarily easier to operate.

In fact, it’s often the opposite.

The more a system can act independently, the more a business needs to know its state and control its decision points.

This question ties into a broader topic ofAI agent governance. An agentic workflow must define what the agent can decide autonomously, what needs to be logged, and when human intervention is required.

At Scroll, we already make this distinction when comparing AI agents and automation. An agent can choose its path based on context. This autonomy brings power, but also greater needs for framing, testing, and oversight.

For a technical leadership team, three levels then become complementary.

The code reveals what was produced.

Logs reveal what was executed.

The workflow state reveals where the process stands and what should happen next.

This third level is often missing from chat-centric experiences.

But making the agent inspectable comes at a cost

This is likely the most interesting part of GitHub’s published feedback.

Building this control layer is not free.

GitHub states that roughly 2,000 AI credits were consumed for Site Studio and around 3,000 AI credits for the Java modernization canvas.

These figures should be interpreted cautiously.

They correspond to the two experiences described by the author. The article does not provide a methodology to benchmark the cost of a canvas or an AI coding agent in a business context.

In other words, the right question isn’t:

“Does an inspectable state cost 2,000 or 3,000 credits?”

The right question is:

“Is the cost of this control layer offset by the reduction in rework, repeated prompts, context errors, and supervision time?”

And the answer depends on the workflow.

Cost per task is not the right metric

The natural temptation is to track only the number of tokens or credits consumed.

That’s not enough.

GitHub also observed this in its work on the efficiency of its agentic workflows. Teams had to instrument token usage, the number of model calls, and other signals, as two executions of the same workflow can handle very different workloads. GitHub also highlights the difficulty of measuring real efficiency without a reliable way to assess result quality.

For an IT department, the cost of an AI agent must therefore be linked to an operational outcome.

A relevant analysis might look at cost per resolved ticket, human review time, rework rate, required validations, or the number of executions needing manual intervention.

An agent that consumes less but forces a senior to spend forty minutes understanding what it did isn’t necessarily more cost-effective.

Conversely, a more expensive control interface can become cost-effective if the same workflow is executed hundreds of times.

Repeated workflows are the best candidates

Not all development agents therefore need a complex canvas.

For a one-off, short task, chat often remains sufficient.

The logic becomes more compelling when a process is recurring, involves multiple steps, or includes multiple people.

An application migration is a good example. You need to analyze the existing system, identify dependencies, modify it, verify results, and obtain multiple validations.

The same applies to feature generation with human review, legacy code modernization, or a bug-fixing pipeline.

In these situations, the need is closer to a business tool driven by AI agents.

This is also what we observe when moving from an AI prototype to a robust application. Initial generation can be fast. The difficulty arises when you have to manage architecture, data, permissions, validations, and edge cases. We detail this transition in our take on the transformation of an AI prototype into a robust application.

A new layer is emerging in the AI development stack

For a long time, the debate around AI software development has focused on models and tools: GitHub Copilot, Claude Code, Codex, Cursor, and other coding agents.

For businesses, the next topic may be less visible but more structural.

It concerns the control layer between humans and agents.

It must preserve state, make decisions readable, organize validations, and provide the data needed to measure the true cost of the workflow.

The best AI coding agent, therefore, won’t necessarily be the one that requires the least human intervention.

It will often be the one whose autonomy remains understandable.

What technical leadership should take away

Chat remains an excellent interface for expressing intent.

It becomes far less suitable when it must serve as command, memory, execution log, task manager, and validation system all at once.

As development agents take on longer workflows, an inspectable state becomes a prerequisite for control.

But this visibility must itself be measured. Adding an interface, persistence, and controls only makes sense if the benefit outweighs their cost.

For an IT department experimenting with AI agents today, the issue is no longer just about choosing a model or a coding agent. It’s also about determining which workflows deserve a sustainable control layer, which states need to be preserved, and how to measure their value.

This is precisely where Scroll can step in: workflow architecture, choosing between automation and AI agents, designing control points, integrating with internal tools, and transitioning from an agentic prototype to a production-ready system.

The goal isn’t to add AI everywhere. It’s to build agents that your teams can truly control.