Retiring the Chat Box as the Primary Control Surface for AI Agents in Large Repositories

An interactive codebase graph for AI agent steering replaces free-text intent as the primary control surface with a shared map of code, dependencies, and architectural boundaries. Retiring the chat box means using that structure to guide agent work, show actions that have consequences, and enforce constraints in CI. Conversation remains useful, but it cannot serve as the architectural contract for autonomous work across a large repository.

Why the chat box was never designed for what agents now do

A modern coding agent takes a GitHub issue, explores the repository, implements a feature, runs tests, iterates on failures, and opens a pull request. The developer is no longer asking for a snippet. The agent makes a sequence of decisions about code, tools, and tests, and each decision shapes what happens next. A chat thread can express the goal, but it does not expose the architectural shape within which that sequence must operate.

That is a different job from answering questions. The chat box was a reasonable entry point when assistance meant a response that a developer could inspect before using. When agents work on their own, reviewers must check how changes relate to each other as well as check each response. Yet the chat window itself has no dependency graph, approved patterns, or constraint layer. Unless another system supplies those structures, the agent has no architectural control surface against which to evaluate its work.

What a structureless control surface costs at repository scale

A 300,000-line monorepo looks like a sea of undifferentiated code to an agent without an architectural map. The files are available, but their governing relationships are not. An agent cannot respect boundaries or conventions it has never been given, and generating more code does not resolve that absence. Instead, the responsibility for recovering the missing context falls on the people who must assess the output.

The cURL project illustrates the cost at the governance level. At the end of January 2026, it ended its bug bounty program after being overwhelmed with low-quality vulnerability reports, many of them AI-generated. The reports could be technically structured while remaining contextually useless. This exposed the distinction between producing plausible output and governing what is relevant or appropriate to a project.

LinearB’s 2026 Software Engineering Benchmarks Report found that agentic AI PRs had dramatically longer pickup times than unassisted PRs. CloudBees’s State of Code Abundance 2026 report found that a large majority of organizations had seen more production issues linked to AI-generated code, though nearly all had been confident in its production-readiness before they shipped it. Together, those findings expose the gap between confidence in output and evidence that it can be trusted.

The diff-view paradigm leaves reviewers poorly equipped to close that gap. Multi-file agent output is a trust-calibration problem because uneven work arrives with an even presentation of confidence. Without a structural frame, the reviewer must reconstruct which changes deserve scrutiny and why. Larger context windows can help, but they cannot by themselves repair retrieval that selects the wrong files or governance that disappears between requests.

Why architectural context cannot be delivered through a prompt

Richer prompts are a serious attempt to supply missing context. They can explain conventions, describe boundaries, and make the intent clear. But explanation is not enforcement. An architectural rule written into a prompt gives the agent information while leaving prohibited dependencies and noncompliant changes possible during execution.

Documentation leaves rules in prose that agents may or may not read, while conventions leave them in the habits of senior developers who apply them during review. Neither makes the rules machine-checkable. Prompt engineering can improve how those rules are communicated, but it cannot turn communication alone into a durable contract.

A spec-driven approach changes the status of the rule. The contract becomes a first-class repository artifact, versioned with the code, validated in CI, and capable of producing typed, structured errors when violated. A prompt alone cannot do any of that. Session-based retrieval compounds the difference because architectural knowledge carefully supplied for one request may be absent from the next.

What interfaces let developers navigate codebases while steering AI agents

The replacement is a set of complementary interfaces. An interactive codebase graph provides the shared structural model for navigating the repository and planning agent work. Its useful criteria are concrete, including visibility into where the agent is operating, which boundaries it is crossing, and whether the implementation still matches the intended design. Conversation can remain available within that workflow without governing it.

Codified context provides continuity across requests and sessions. A root file such as CLAUDE.md or AGENTS.md can hold global conventions, the architecture overview, cross-cutting constraints, and shared standards. This is operational memory rather than passive documentation when the agent depends on it for convention-adherent work. It still does not enforce itself. Its role is to supply stable context, while machine-checkable contracts govern the rules that must survive execution.

An activity panel keeps tool-call history, reasoning steps, memory retrieval traces, and decision rationale apart from the conversation so they have their own place for review. The conversation records what was requested, while the panel exposes how the agent proceeded. A team needs to see how the agent proceeded when it must debug a failure, rather than judge how convincing a demonstration looked.

Approval checkpoints restore control before consequential actions occur. Agents act on their own timeline, so the traditional assumption that a user initiates and the system responds is no longer sufficient. Multi-agent orchestration also needs structure for its different roles, as planners explore the codebase and create tasks, workers carry out assignments, and judge agents assess each cycle. MCP and A2A provide connective tissue, but supervising those distinct roles requires more than a single conversation stream.

How Salesforce and Meta redesigned review around structure rather than diff inspection

Salesforce rebuilt its review system around intent reconstruction. Developers author changes with a conceptual model, such as refactoring authentication or introducing a new API, but isolated diffs discard much of that organization. The redesigned system centers on iterative reasoning that preserves files, functions, and modules as structural boundaries during analysis. Purpose becomes part of the review frame.

Meta’s Code Spotlight research found that human reviewers overwhelmingly prioritized correctness and security, precisely the themes current AI code review systems underserved by the widest margins. More commentary was not the central need. Meta enabled a “self-ship path” in which diffs passing ARCTIC quality signals could land without upfront peer review.

Salesforce preserves the conceptual structure of the work, while Meta uses structural signals to determine when upfront peer review is unnecessary. Both make evidence central to the decision. For agent interfaces, the lesson is to expose intent and the basis for trusting an implementation, rather than treating a readable diff or a confident explanation as sufficient.

CI enforcement as the non-negotiable backstop when interfaces cannot catch everything

A structural interface cannot ensure that every file an agent touches follows the rules. Automated CI validation closes that gap by failing the build when specification and code diverge. Checking every commit makes architectural drift visible at the point where it can block progress, rather than allowing it to accumulate behind an apparently successful agent session.

A Thoughtworks Technology Director states that spec drift and hallucinations are inherently difficult to avoid, so highly deterministic CI/CD practices remain necessary to safeguard architecture and software quality. The DORA 2024 dataset linked AI adoption to less stable delivery when it was not matched by governance of the deployment pipeline. The surrounding delivery system must constrain what can proceed, even when the generated implementation appears plausible.

The practical distinction is whether the check can stop a merge. A CI check that exits non-zero converts an architectural rule from advice into a gate that the agent cannot pass. Running gr check in CI implements this pattern by enforcing graph-defined architectural constraints on every commit. The graph supplies the rules, and CI makes violations consequential. This is the enforcement counterpart to interactive steering.

The strongest objection: structured interfaces slow developers down and over-constrain agents

Specifying, versioning, and enforcing constraints creates real work. Developers already fluent in a repository may find that formalizing knowledge costs more time than a particular agent task saves. A new control surface can also make familiar work less direct by inserting approval and validation steps. Productivity gains are not automatic. The strongest objection is that structure can consume the very capacity that agent assistance was supposed to release.

Over-constraint creates a more serious failure than inconvenience. If contracts are too strict about implementation, agents may be unable to produce anything that passes validation, leaving teams to turn off enforcement altogether. There is also a legitimate skills-atrophy concern when developers spend less time implementing and more time approving generated work. Supervision that becomes passive acceptance would weaken the judgment needed to recognize bad changes. Giving teams a graph does not solve either of these problems.

The appropriate response is to constrain architectural invariants. Module boundaries, dependency directions, and layer rules define the space in which an agent can work without prescribing every internal choice. This leaves room for implementation judgment. A useful check fails on the right violations and remains silent on permissible variation, while an indiscriminate check invites abandonment. Likewise, developers must keep checking system behavior and evidence, rather than just approve whatever the interface shows them.

What the developer's job becomes when the chat box is no longer in charge

More of the developer’s work goes into intent, constraints, architecture, specifications, context engineering, and evaluation. The central question changes with that allocation. Alongside deciding how a feature should be implemented, the developer must ensure it has been specified, constrained, and evaluated well enough for autonomous execution.

A live codebase map gives that judgment a concrete surface. It needs to show what the agent is building, where it is operating, which boundaries it crosses, and whether the code on disk still matches the intended design. Mapping a repository with gr init and planning agent work on the graph puts steering on a shared model, while CI enforcement applies the architectural constraints automatically.

The resulting work is supervisory without being less technical. Effective supervision requires understanding what good software looks like, how the system behaves, what can fail, and which evidence is sufficient to trust a change. Making code easier to generate does not make those judgments easier. The developer becomes an “Architect of Intent,” defining the goal, governing the boundaries within which agents act, and deciding whether the result deserves to ship.