When Coding Agents Write All the Code, Where Does the Bottleneck Go?

Lately, every customer meeting that touches DevOps arrives at the same question: "So how does this relate to things like Claude Code and Cursor?" It's a good question, and from where we sit, a welcome one. I believe the better coding agents get, the more valuable the thing we're building becomes. This essay is about why.

What happens when code gets cheap

What tools like Claude Code and Cursor are actually collapsing is the cost of writing code. I can see it on my own team. Early on we merged maybe three PRs a week; now dozens go up. People didn't suddenly become ten times more diligent. The friction in the code-production step disappeared.

But writing code is one segment of the whole flow of building software. Remove one bottleneck and the flow doesn't simply speed up; the next bottleneck surfaces. Exactly what the theory of constraints predicts. The moment code production goes up tenfold, an organization faces three questions:

• What did this agent know when it wrote the code? (the context problem)
• Through which path does this code enter the system? (the execution problem)
• Who allowed this change, and when? (the permission and traceability problem)

Producing code inside the editor is the agent's job now. Turning that code into an issue, a change request, a pipeline run, an approval, a deployment record: that's where the bottleneck lives today, and that's where we stand.

What does the agent know when it writes code?

An agent's output quality is model capability multiplied by context quality. The first factor, the model labs keep raising. The second factor is the organization's responsibility.

You can't make a good change by looking only at the file you're changing. You need the connected sources; the issues and documents that record why the code looks the way it does; the incident that a similar change caused last time. It's the context a senior engineer carries around in their head.

In a fragmented toolchain, giving an agent that context means issuing an API token for the issue tracker, another for the repositories, another for CI, another for the wiki, then writing glue code to stitch four response schemas together. Anyone who has tried knows how it goes: it works, technically, but everything from token management to rate limits becomes an operational burden, and the data you collect are fragments that don't know each other. The fact that issue #1234 and commit abc123 are related appears in no API response.

We chose a different structure. Issues, documents, code, builds, and deployments live on a single graph of stable IDs from the start. Documents link to each other and open in a graph view, the way Obsidian does it. The agent travels this graph: the commits linked to this issue → the module those commits touched → the other sources referencing that module → the past incidents tangled up with those sources. Not searching a flat table, but following relationships. And nobody builds those relationships by hand; they accumulate as a side effect of doing the work.

Whenever I explain this in a meeting, the same question comes: "Who builds that graph?" Nobody does. That's the point.

Through which path does the code enter the system?

If context is the input, execution is the output. An agent that judges but cannot act is an assistant. One that acts is a colleague.

We ship a CLI for the terminal. We built it for humans, but its most diligent user today is Claude Code. Agents use it to create issues, check state, open change requests, read pipeline logs. Internally we already run a flow where an agent generates small change requests directly from an issue, proposed fix attached. In Slack, when a pipeline breaks, the agent doesn't relay the error message; it attaches an analysis and a diagnosis. Anyone who has taken an on-call page at 3 a.m. knows the difference between an alert that says "build failed" and one that says "this change in this commit conflicts with this module, and here's the fix."

The agent in the editor and the agent on the platform aren't substitutes; one extends the other. Code that Cursor writes still has to start from an issue somewhere and pass through a pipeline somewhere. The question is whether that path is open to the agent, or whether a human ferries things across it by copy-paste.

So what do humans do?

At a public-sector meeting, someone watching the demo said: "At this rate, people barely write code anymore." Correct. That's the direction. Humans do specification and approval.

But that sentence only holds under a condition: for approval to mean anything, the thing being approved has to be traceable. What the agent changed, on what basis, where a human intervened: all of it, intervention included, has to survive as history. In an organization where agent actions aren't traceable, "AI writes our code" stops being a productivity story and becomes an audit-risk story.

Which is why permission models and approval gates are not decoration in the agent era. They're the precondition. If change-request approval is wired in as a pipeline gate, the agent can open a hundred CRs a day and the road to production is still guarded by a person. When code production grows tenfold, what you need is not a reviewer who is ten times faster. It's a structure where what must pass review is built into the system itself.

The on-premises constraint

One condition keeps getting left out of this picture: a large share of Korean enterprise and public-sector environments are air-gapped. You can't call Claude over an API there.

So we abstracted the LLM layer. Commercial models like Claude and Gemini plug in, but given GPUs, it switches to open-source models in the Qwen family. Open models' raw capability trails the frontier, of course. Closing that gap with harness engineering is the research problem we're currently holding onto: not retraining the model, but raising its effective performance through how you slice the context, which tools you put in its hands, and how you wrap the verification loop. The goal is on-call response and incident diagnosis at a practical level, inside a closed network.

To be honest about where we are: our agents do small things today. Small change requests, diagnoses, summaries. Agents driving large greenfield development is still an experiment, and we never have enough GPUs. But I'm confident about the direction. The trend of code getting cheaper will not reverse, and in that world an organization's edge won't come from the agent. It will come from the floor the agent stands on: the context graph, the execution path, the approval structure.

The editor is already great. Now it's time to give the agent the rest of the company.