Enterprises are accumulating coding-agent sprawl because developers need different tools while IT teams must manage contracts, security, billing, and access.
2
A coding agent gateway can give developers freedom to choose tools while giving administrators shared observability, cost controls, privacy controls, and procurement.
3
As agents increase code output, review capacity, CI systems, and realistic testing environments become the main limits on engineering speed.
Summary
Ankit Mathur argues that enterprises are losing control as developers adopt Claude Code, Cursor, Codex, and other coding agents for different tasks. IT teams face separate vendor contracts, scattered billing, limited visibility, and difficult security policies around sensitive data. Databricks built a coding agent gateway to put these tools behind one access point with shared reporting, cost limits, privacy controls, and model capacity. Its internal Isaac harness lets developers launch different agents while routing usage, MCP connections, and billing through the gateway. Mathur also describes the problems that appear after adoption. Databricks now has more code to review, higher CI costs, and a need for testing environments where agents can validate changes against realistic services. He is direct about unfinished areas, especially the governance of skills and MCP selection. The talk is useful because it treats coding agents as an enterprise infrastructure problem rather than only a developer-tool choice.
Coding agents create an enterprise control problem
Mathur says every new model can feel like another "10x engineer," with tools such as Claude Code, Gemini's CLI, Cursor, and Codex arriving quickly. For IT teams, supporting several tools means separate vendor contracts, admin consoles, bills, and usage records. They also need to enforce rules around PII and whether provider models can use company data for training. The problem is harder because agents may need access to Jira, repositories, cloud infrastructure, external APIs, and internal design documents. That access must still respect document-level permissions.
Developers need different agents for different tasks
A single enterprise-approved tool does not match how developers use coding agents. Mathur describes using Claude Code to write code and Codex to review it, because the model that produced code may miss its own design flaws. Developers may choose another tool for refactoring or test writing. He argues that a 10 to 15 percent improvement in productivity or code quality is valuable enough to justify using the best tool for each task. New model harnesses will make these differences more important.
Mathur calls the growing collection of tools "agent sprawl" and expects coding tools to become a major company cost. Databricks built a coding agent gateway that lets developers use the tools they prefer while giving administrators one place for oversight. The gateway collects usage data, identifies power users, provides dashboards, and supports a shared monthly budget across tools. It also helps enforce privacy requirements around sensitive data. Developers keep their existing workflows, while finance and IT receive a consolidated view.
A lightweight harness connects developers to shared controls
In Mathur's demonstration, a wrapper points Claude Code and Codex at the gateway and handles login in one place. The gateway can provide model capacity through Databricks, which avoids creating a separate provider relationship for every tool. Administrators can see requests, token use, popular tools, users, sessions, and lines of code in dashboards backed by the company's data warehouse. When a new model improves, developers can use it through the same gateway without creating a new debate about billing and visibility.
MCP expands agent capability while creating token risks
Mathur describes MCP as one of the largest recent changes in coding tools because agents can work through API endpoints instead of receiving copied information manually. The usual setup can leave tokens in local plain-text files, without rotation or consistent administration. Databricks puts MCP connections in an encrypted, managed data catalog with automatic rotation. Users authenticate through Databricks and can access connections either as themselves or through shared organizational credentials. Mathur says this gives enterprises a governance path for tools such as Jira.
Databricks relies on measurement and executive participation
Databricks has more than 2,000 engineers working across many offices and programming languages, so Mathur says measurement was necessary for deployment. Its internal Isaac harness launches coding tools, routes metrics through the gateway, manages MCP logins, and sends usage data to dashboards. Executives can see company-wide adoption, tool use, and lines written, while teams can inspect their own usage. Mathur also says adoption required every engineer to learn the tools and required explicit executive demand. He points to CEO Ali using Isaac as an example.
More agent output moves the bottleneck to review and CI
Mathur says Databricks' ability to scale code review has become its main limit because the volume of generated code has increased. CI also costs more when many agents create changes and dependency mistakes trigger large numbers of tests. He argues that projects and services need better abstractions so agents can get through development loops faster. Testing must also provide an early, explicit validation signal. Agents lack much of the deployment context held in engineers' heads or scattered across documents, so realistic validation environments matter.
During questions, Mathur admits Databricks has not solved the problem of organizing agent skills. Teams are creating similar skills, and developers cannot reasonably read thousands of Markdown files to find existing work. He expects skills to become part of governance and suggests that similarity discovery could help developers extend an existing skill. MCP selection also remains partly manual because activating too many connections floods the model's context and increases latency and cost. He expects harnesses and tool-search features to improve selection, while still requiring a governance layer.
