Customer support in the age of coding agents

April 9, 2026

Agents have changed customer support. Coding agents aren’t just writing more software. They’re generating software like games have procedurally generated terrain. How must support evolve?

Moving targets

Vibe coding and plastic software have arrived. Agents mean code stability and software stability have universally declined. Yes, we are shipping faster and code improves faster, but that means we’re constantly in a state of things being broken at the edges. And not only in our own code bases, but in our customers and our vendors. Stability is sacrificed because all businesses feel like they’re only a few months away from irrelevance or obsolescence.

Yet historically, stability and support were hand-in-hand concepts. Ubuntu had “LTS” or “long-term support” releases because support was tied to stability. How can you ask your support team to constantly keep up-to-date with the latest code changes? New bugs appear at the edges, and as soon as a bug is understood, it can be fixed with an agent and the fix deployed in minutes—but that fix may introduce new edge cases of its own. Support teams must track both: the breakages and the fixes. Sure, the broad feature or product might look the same, but how it works and therefore how it breaks is constantly changing under the hood. I’ve literally had conversations with customers where I have to verify when they hit a bug because we may have landed a bug fix since then.

Interventions, not questions

Customer support used to be answering questions around “opaque interfaces”. Kernel has these SDKs and APIs. I can help you understand them, but they’re fixed points. People would ask “How do I set up X?” or even “How do you bill for Y?” This old way of thinking results in knowledge bases that you can search over: either docs, StackOverflow, or literal FAQs. And because those interfaces were firm and therefore stable, the knowledge bases were relatively up-to-date.

That’s gone. Firstly, the questions around our interfaces have been soaked up by agents. When setting up Kernel, our customers are asking their agents. Agents are poring over our public docs and repos. Not only can the agents answer those questions, most of the time, the customers don’t even need to ask them because the agents have done all the setup work.

Instead, support has shifted to managing interventions. Almost all support questions are now “This feature isn’t working, tell me why.” They are asking for server logs and expecting code fixes. Customers, more than ever, push into our code, literally even contributing code to our open source repos. And it makes sense: asking for a code change used to be a major request: likely taking weeks or months. But coding agents make software feel like it should be responsive, fluid to our needs. Behind every bug, a customer thinks “I could vibe-code a fix in 5 minutes!”

Yet, bug fixes or feature requests require human-gated decision making. Bug fixes still need to be approved and feature requests need to be triaged onto the roadmap.

Humans in the loop

The combination of instability of the software and complexity of customer requests means that support, too, must shift. I see customer work splitting into two types: relationship management and intervention triage.

Relationship management will exist for the same reason you still talk to a sales associate to buy a Rolex. Humans trust humans, especially for major purchases. However, relationship management is an embarrassingly parallel problem. If you have two account managers, each account manager can talk to their own assigned customers. The relationships and egos are always complex, but it’s a tale as old as time. Agents will augment this world, but will not fundamentally change it: the best hotel concierges can send up towels at the press of a button, but the art of hospitality remains.

It’s intervention triage where change is occurring. I’ve long stopped looking at Kernel docs, nor do I train new support staff on our docs. Everything comes from the code. I open a new terminal session in a directory with a rapidly-evolving CLAUDE.md and all of Kernel’s repos, locally downloaded, and a directory of skills for diving into logs, databases, events. In that CLAUDE.md, I threw in an addendum to my customer response instructions: “Provide code samples.” This has broadened the spectrum of communication because we can communicate in code. If a customer tells me they have a bug, my agent can trivially write code to repro. If I can’t repro, I can send the customer runnable code, asking them to modify it to create the repro case.

“So what? You could always send code snippets to customers.” The difference is scale and cost. Code is as cheap as prose now and scaling these kinds of conversations is possible. When you’re collaborating on code, support isn’t a queue or even a conversation. It’s Hanabi. Support and customer are solving a problem together as quickly as possible, but communications are constrained by policy and privacy. We’re figuring out whether the next “play” is a code fix in Kernel or the customer’s codebase.

Framed this way, the next natural step is to have two agents talking to each other, one customer agent with one Kernel agent. The human’s role then becomes gating trust, at three layers:

• Verify incoming messages that require more in-depth investigation (db access or running code) are not malicious.
• Verify outgoing messages with potentially confidential information. Over time, trust can be automated. Like Cursor BugBot’s automatic approvals for low-risk changes, a similar approach can be done with replies to customers.
• Verify bug fix pull requests for Kernel’s own repos

I suspect that agents, optimizing little buggers that they are, will learn to avoid “risky” steps that will require human approval. In this world, two customer agents could initiate and conclude a conversation in a matter of minutes, producing either pull requests in one or both Kernel and customer code bases.

Support used to be a knowledge problem: memorize the interfaces, maintain the docs, answer the questions. Coding agents have both made that world obsolete and open the doors for a new world. The value of support is no longer knowing how the software works—an agent can read the code faster than any human. The value is managing agent inputs and outputs to orchestrate company and customer code.