John Kaster is the founder of Sonde and a veteran developer-tools engineer, with decades of experience including Borland's Delphi team and Google. He builds deterministic verification for AI-generated code.
Connect on LinkedIn ↗AI can now write code faster than any human. The uncomfortable part, according to veteran developer-tools engineer John Kaster, is that speed is quietly borrowing against a debt someone else will pay later. "What you're actually doing is pushing the quality burden to the right, down to the people who are actually using your system, and they're discovering the bugs."
Kaster has spent decades building developer tools, including time on the Delphi team at Borland and later work at Google calling Vertex AI through its APIs. That background shapes a contrarian view worth sitting with: the answer to AI's code-quality problem is not a smarter AI. It's determinism. We spoke with him about Sonde, the tool he's building (currently in alpha) to keep AI-generated code honest, and what engineering leaders should be doing right now.
Kaster has a long-standing pet peeve, and AI poured fuel on it. At startups, he kept hearing the same line: we're a startup, we'll clean that up later. His response is blunt. "There's never a later." Worse, he argues the tradeoff is false to begin with, because doing it right from the start is actually faster: "there's absolutely no reason to implement substandard code practices in the first place, because if you do them right right away, everything happens faster."
Then agentic tools arrived and took "we'll fix it later" to a new level. Now teams can "make stuff that looks good really fast." The problem surfaces four months down the road, he says, when real customers start using the product and fundamental architectural changes are needed. At that point you often have to start over, because the underlying architecture was never designed well. That gap between looks done and is done is the problem Sonde was built to close.
Kaster is candid about the irony at the center of his work. "I'm primarily developing Sonde with AI. The ironic thing is I'm using AI to reduce the reliance on AI."
His guiding principle for any team leaning on agentic coding is to protect the parts of the system that must not wobble: "let's make sure that the infrastructure that we depend on for running our business is deterministic. It's 100% repeatable." The logic should be grounded in computer science and good engineering principles, he argues, "not relying on an AI's LLM pattern matcher to extrapolate the correct pattern, because the pattern is going to be different with every model."
That last point is the crux. An LLM is a moving target. Upgrade from one model to the next, he warns, and the same codebase may be handled differently. Determinism is how you stop chasing that target.
A natural rebuttal is: if AI writes the code, why not have AI review it? Kaster's answer is that a reviewing model has no way to guarantee it looked everywhere. Picture two million lines of code in a repository. No AI tool, he argues, can hand you the full picture of all of it and flag, unprompted, that a property in your front end is calling your back end with mismatched names, silently dropping values or truncating data. Unless you point it at that exact scenario, it can miss it.
The deeper issue is consistency. "Every time you run a review with AI, it'll find something different." Sonde takes the opposite approach: rules he calls probes, encoding standards a senior engineer specifies, run the same way every time. "It's not a human reviewing the code, but it is a tool that exactly follows the rules that a human specifies." And it's fast enough to keep up: Kaster claims Sonde can analyze code faster than AI generates it, scanning tens of thousands of lines per second.
He's careful not to turn AI reviewers into a villain. Some CI review agents are genuinely impressive. But they pattern-match rather than verify. As he puts it, anyone who understands how AI analyzes code will admit "it's not deterministic, it's not idempotent. Anytime you run it, you might get something different than the last time. How can you trust that?"
Kaster's favorite illustration of why pattern matching is fragile has nothing to do with code, and everything to do with trust. Scots, a language spoken in Scotland, is effectively broken in today's LLMs. The reason, he explains, traces back to a high-school student in the United States who built a website inventing English translations for Scots. Models learned the language from that flawed material and now treat that made-up vocabulary as authoritative.
The lesson transfers directly. If you don't know what the AI was trained on for the language your code is written in, you don't know how good that foundation was, "unless you're actually doing quality analysis on the code that it generates."
The risk Kaster worries about most is organizational, not technical: "nobody knows the code anymore." An experienced engineer who has lived in a codebase for a year usually knows where to look when something breaks. Push everything to AI and you forfeit that. You're left "at the mercy of whatever the AI thinks the issue is," which can turn a quick fix into a multi-day back-and-forth.
He's seen the pattern in "vibe-coded" builders too, people shipping impressive ideas with no prior software experience, only to hit walls six months later that force them to redo huge portions of what they built, because the AI coded them into a corner.
His analogy is grounded and memorable: you don't need to understand how your car works, but you do need a mechanic who can fix it. "You can't just say, 'Oh, well, okay, my car is not working, so I'm going to open up the hood and start taking things out.'" Something in your workflow has to provide the specifics and the repeatable process.
One more failure mode he flags for anyone relying on tests as a safety net: AI will sometimes change the test itself to make it pass. "I've caught Claude doing this where it's like, 'Wait, you just changed the test.'" His counter-technique for teams who won't build their own analyzer is to have AI write deterministic tests, then let the system rely on proven code rather than on whatever the model improvises next time.
Kaster's closing point reframes the whole conversation. "We can't surrender our thinking to the agents. They can be great partners, but they are not the pair programmer that you need for making sure that you have quality code."
For leaders whose businesses carry real legal exposure, around accessibility, PII, or financial data, he's emphatic that "AI vibes" don't cut it. You want proof: evidence that a specific behavior changed on a specific date in specific lines of code.
And there's a human cost he's trying to design against. He sees engineers on LinkedIn every day saying they're losing touch with their coding skills. Sonde attaches references to every finding so an engineer can click through and understand why something matters, a deliberate nudge toward continuous learning rather than surrender. His warning is stark: "The more AI generates AI code, the lower the quality of all code is going to be."
The takeaway for engineering leaders isn't to use less AI. It's to decide, deliberately, which parts of your system are allowed to depend on a moving target, and to put deterministic checks around everything that isn't.
