Coding agents aren’t just writing more software. They’re generating software like games have procedurally generated terrain. This has changed the support demand, so how must support operations evolve?

Moving targets

Vibe coding and plastic software have arrived. Agents mean code stability and software stability have universally declined. We’re shipping faster and code improves faster, but we’re constantly in a state of things being broken at the edges—not only in our own codebases, but in our customers’ and our vendors’. Stability is sacrificed because every business feels a few months away from irrelevance.

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

Interventions, not questions

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

That’s gone. Questions about our interfaces have been soaked up by agents. When setting up Kernel, customers are asking their agents, and those agents are poring over our public docs and repos. Most of the time, customers don’t even need to ask because the agents have done the setup work.

Support has shifted to managing interventions. Almost every ticket is now “This feature isn’t working, tell me why.” Customers ask for server logs and expect code fixes. They push into our code, literally even contributing to our open source repos. It makes sense—asking for a code change used to be a major request, weeks or months. 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.”

Humans in the loop

Unstable software plus complex requests means support must shift too. Customer work is 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. It’s also an embarrassingly parallel problem—two account managers, two sets of assigned customers. The relationships and egos are complex, but it’s a tale as old as time. Agents will augment this world without fundamentally changing it. The best hotel concierges can send up towels at the press of a button, but the art of hospitality remains. If even a full AI-pilled tech founder wants a human, the human touch has no expiration date.

Intervention triage is where the change is happening. In the last month, I’ve changed. I’ve stopped looking at Kernel docs, and I no longer train new support staff on them. Everything comes from conversation, relationships, and code. Each conversation, I open a new terminal session in a directory with a rapidly-evolving CLAUDE.md, all of Kernel’s repos downloaded locally, and a directory of skills for diving into logs, databases, events. The CLAUDE.md outlines how to tackle issues and—importantly—gives me an “internal” explanation and drafts a basic customer response that gets copied to my clipboard via pbcopy.

My favorite part is my addendum to the customer-response instructions: “Provide code samples.” This broadens the spectrum of communication—I’m speaking to the human in English and to their compute in code. If a customer reports a bug, my agent can trivially write code to repro. If I can’t repro, I send the customer runnable code and ask them to modify it into a repro case. Their agent can take my repro, compare it to their production code, and find the difference. Before, I only spoke to the human customer. Now I’m increasingly talking to their agent directly.

“So what? You could always send code snippets.” The difference is scale and cost. Code is as cheap as prose now, and scaling these conversations is possible. When you’re collaborating on code, support isn’t a queue or even a conversation. It’s Hanabi—the cooperative card game where you can see everyone’s hand but your own. Support and customer are solving a problem together as fast 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.

Context for support agents

Agentic support requires context. Before, context was the docs. Maybe a knowledge base. The problem is that these are just “knowledge caches” without a coherent revocation or TTL. Agents allow us to derive knowledge from the ground truth. So what is that new ground truth?

Conversational: what questions have already come up, what repro code has been sent, what tickets closed how, what was said in the latest sales call. To speed up access, I vibe-coded a simple MySQL cache. Relationship is the health of the customer—who they are, what they’re trying to accomplish with Kernel, the current state of the relationship (happy, dissatisfied). It lives in your CRM, managed by the account owner. Product is which surface areas they use, which known bugs or feature scenarios they’re likely to hit. For instance, Kernel has a diagnose-aw-snap skill for a class of browser crashes. Customer-facing and product-facing engineers both contribute to these skills, and a post-deploy agent step updates them against new commits.

Agent to agent support

Two agents talking across the customer/company boundary. The human’s role becomes gating trust. Look at the workflow at the top. There are three gates—actual queues with actual humans at them, not three layers of verification:

• A prompt-injection agent screens everything coming into support@. Flagged messages get blocklisted until a human reviews. The models are good enough at this now that I don’t lose sleep over it. The real risk isn’t the jailbreak—it’s data export. An attacker who can’t access info or execute with privileges gives up.
• Privilege escalation requires a human. Read-only on proprietary data doesn’t. The moment the agent wants to write, run sample code against a customer’s resources, or touch anything with export potential, a human signs off. Code can exfiltrate; that’s the gate.
• Customer-facing output gets human review—every reply from support@, every escalation into #user-discuss, every draft Linear issue. Not because the draft is bad—it’s usually fine—but because this is where the company’s voice lands.

I suspect agents—optimizing little buggers that they are—will learn to avoid the steps that trigger review. In that world, two agents could initiate and conclude a conversation in minutes, producing pull requests in one or both codebases.

This is what I’m focused on. I’ve evaluated other off-the-shelf vendors, but in infrastructure, truth comes from code and evaluating truth requires reading, writing, and executing code. Kernel runs its own unikernel infrastructure, which gives us isolation and (relatively) safe execution. Piggybacking on that for support agents is nearly free—and we already have the browser the agent needs to drive.

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.