Gal Vered - Checksum.AI
The Binary Bet: Risk, Verification, and the Real Bottleneck in AI-Driven Development
Success Is Binary
Gal Vered wants to build the testing tool that every developer uses. He and his team at Checksum.ai are energized by that ambition, and so are his investors. But underneath that vision sits a framework for decision-making that most founders never articulate this clearly.
"You should optimize for success, for the probability of success versus the outcome. Success is binary. You either build a successful VC-backed business, or you don't. It doesn't really matter if you make 20, 50, 100, 200, or 500 million dollars. Either way it's more money than most people ever earn in their life. So it really doesn't matter. If you have a 50% chance to make $50 million or a 10% chance to make $700 million, I would still take the 50% chance. The utility function between 50 and 700 is so low. It's not about expected value. It's about: is it going to work?"
This is not an argument for capping ambition, but one for optimizing the variable a founder can actually control: the likelihood of getting across the finish line. And it shapes how Gal builds his company, how he chose his backers, and how he talks other founders through the moments when the whole thing seems like it might fall apart.
Meet Gal
Before Checksum, before super{set}, before any of it, Gal was the person who found the bugs.
“I was always frustrated by being the person that finds all of the bugs and needs to report them. The fastest way to ship was always just put it in production, have your customers use it, report all the bugs, and let your customers be your QA. But it’s also the fastest way to piss off your customers and have them churn.”
Most builders recognize the tension between moving fast and breaking things versus moving carefully and losing ground. What Gal did differently was to treat it as a product problem rather than a management problem. The frustration did not push him toward slower, more careful engineering. It pushed him toward asking whether the whole verification process could be rebuilt from scratch.
His time at Google added a specific dimension to that question. He saw what serious testing infrastructure actually looked like: hundreds of pre-release tests, thousands more in staged production, automatic rollbacks, and continuous comparisons between beta and production users. It worked. Production almost never broke. But the gap between “the feature is done” and “the feature is live” was long.
“It showed me the power of having really great coverage, but at the same time how costly it is.”
Meet Checksum.ai
Checksum is a testing and verification platform built on the premise that writing code is, increasingly, no longer the hard part.
“Writing code is for the most part a solved problem. The biggest problem is how do you know this code works?”
The product addresses that question through two parallel systems. The first is a traditional suite of end-to-end, integration, and API tests, generated automatically and expressed as open-source code so engineering teams are not locked into Checksum’s platform. The second is what the company calls the Code World Model, a runtime simulation that models how software actually behaves in production: across different infrastructure configurations, database states, network conditions, and distributed service interactions.
The distinction matters because most software bugs are not syntax errors.
“Very, very rarely do AI bugs end up being just a syntax error. Most of the time it’s just the service that you thought would work with the other service just doesn’t work as exactly as you thought. And it’s not from the code. It’s just from real usage.”
The simulation is designed to surface those failures before anything reaches production. Gal’s analogy is Waymo: before a new autonomous driving model ever touches a real road, it has already been tested across millions of simulated miles covering snow, pedestrians, edge cases, and unexpected scenarios. Checksum is attempting something structurally similar for software.
The Bottleneck Has Shifted
The business case for Checksum rests on a simple pipeline argument. When writing a new feature takes three weeks, a testing cycle that runs a few days is a manageable cost. When writing that same feature takes two hours because an engineer has pointed Claude Code at the backlog, that same few days becomes the entire problem.
“Testing becomes the bottleneck. That’s the reason it’s going to take you three to four days to release a feature that took two hours to write. And when you’re releasing 100 features a week instead of one, you increase the chance of something breaking exponentially.”
He also points to a subtler problem that tends to get less attention: the quality of human code review degrades as AI-generated pull requests accumulate. "People who review AI code are less attentive. It's just short attention span when you have a new PR coming in every hour. You just skim it and move to the next thing."
The instinctive response is to put AI on both sides of the equation: if humans cannot keep up with AI-generated code, let another AI review it. Gal's argument is that this misunderstands the nature of the problem.
"LLMs have no access to this information, and even if you do provide access via API or MCP, they have no ability to actually parse all of this information. Large language models are very good at high reasoning over small amounts of data."
The bugs that matter in production are not logic errors an LLM can catch by reading the diff. They live in the terabytes of context surrounding the code: the production database states, the weird edge cases from real user behavior, the learnings your team carries from the last time a deploy took down production. No model's context window can hold that.
On the enterprise side, Checksum is entering a market that was historically resistant to change. Large companies that have operated for 20 or 30 years on their existing development processes did not typically move unless there was a compelling forcing event. That has shifted.
“I think everyone is rethinking everything they do. The assumption used to be ‘do nothing’. Two years ago, that was the default. Today, everyone understands they might get disrupted by a smaller company moving faster with AI.”
Building Inside super{set}
Checksum came out of super{set}, a venture studio model in which founders build alongside investors from the earliest stages. Gal is direct about what the model is and what it is not.
“Nobody is going to come and give you a solution or a billion dollar idea or a billion dollar company. You need to come, you need to build hands on, you need to drive the path.”
The studio compresses the feedback cycle during the phase when a founder most needs signal and least has the network to get it quickly.
“I literally walk into an office where there are CTOs and engineers, and in one day I can get 20 interviews. Without it, that can take me four or five weeks, especially if you’re not super well-connected.”
Beyond access, there is the less quantifiable benefit of simply not being alone in the early uncertainty. “You just get a lot of support, and it’s fun to build with experienced people.”
Perseverance as Strategy
Gal’s probability framing connects to something he says with unusual specificity: the single biggest predictor of whether a startup succeeds is whether the founder keeps going.
“The number one predictor of startup success, maybe beyond the market you’re playing in, is perseverance. There are so many successful companies where, at the end, other founders would have just stopped. Not executed less. Not tried something different. Just stopped earlier.”
That reality is not behind Checksum. It is not behind any startup. "We still have it pretty often where you think it's either not worth it or it's not going to work out," Gal said. "It's never smooth sailing. Even if you talk to a founder with a successful company, you'll always hear it's always ups and downs."
Gal's point is not that something is broken. It is that the chaos is the baseline, and the founders who survive it are the ones who genuinely enjoy the process.
"If you're not enjoying it, it's going to be very hard to justify keeping going when it seems like it's most likely not going to work. And 99% of companies, there will be multiple times at multiple stages where it's going to seem like it's not going to work."
His answer is structural, not motivational: make the work itself worth doing so that conviction carries you through the stretches when the evidence does not.
"Make sure you would do this two-to-seven-year journey even if you knew the outcome at the end was not what you expected. Because there will be a moment when you don't think the outcome will be what you expected. And you need enough momentum and will to keep going."
Where the Real Moats Are Now
Gal’s view on what creates durable advantage has been shaped by building Checksum and by watching how his own behavior as a consumer has changed.
He uses Hermes, an AI personal assistant, over competing products not because of features but because it is more stable. “I need something reliable. I need something that works. I don’t have time to debug stuff.”
That preference, repeated across millions of users making similar quiet trade-offs, points toward where he thinks competitive advantage is forming.
“Speed is a moat. Having good taste and deep customer understanding is a moat. I do think stability will start to become the moat as companies ship more and more code into production.”
Software itself, the feature set, the interface, the functionality, is no longer protected ground. “It’s very easy for a two- or three-year-old startup to replicate something very fast, given all of the changes with AI,” he said. What cannot be replicated as easily is the judgment to know what to build, the speed to ship it reliably, and the verification infrastructure to make sure it holds when real users start pushing on it.
That last item is, not coincidentally, exactly what Checksum is selling.
More from Uncovered Media
 | A guest post by
|