Gal Vered: How to Test AI-Generated Code Without Slowing Down
The faster AI writes software, the more important it becomes to verify what that software actually does. For founders and engineering leaders, that changes the economics of development.
A five-person software team can now produce the kind of application complexity that once required a much larger engineering department.
AI coding agents can write features, resolve tickets, generate pull requests, and continue working after developers close their laptops. The productivity opportunity is enormous. But faster code generation creates a new problem: Who verifies that everything still works?
A feature can look complete while quietly disrupting another part of an application. An automated code review might identify suspicious logic without revealing whether customers can successfully complete their intended tasks.
The bottleneck has moved.
Gal Vered, co-founder and CEO of Checksum, believes this shift requires a fundamental change in how software teams organize their work.
His argument is straightforward: the future of software engineering is less about producing code and more about defining and verifying how software should behave.
Why AI-Generated Code Creates a New Bottleneck
For decades, developers spent much of their time writing software. Reviewing, testing, and releasing that software followed the development process. AI has dramatically compressed the first stage. An engineering team can now delegate large parts of its backlog to coding agents. Tasks that previously competed for scarce developer hours can be executed in parallel.
But the resulting code still needs verification.
The 2025 Stack Overflow Developer Survey illustrates the challenge. While 84% of respondents were using or planning to use AI tools, 46% said they distrusted the accuracy of AI-generated outputs. The problem isn't simply whether AI can produce useful software. It clearly can.
The problem is whether organizations have developed the processes to validate that software at the same speed.
Google Cloud's 2025 DORA research identified a similar tension: greater AI adoption was positively associated with delivery throughput but negatively associated with delivery stability.
In other words, producing more changes does not automatically mean delivering more reliable products.
For founders, this creates a potentially expensive trap. A business can accelerate its development pipeline while unintentionally increasing the cost of debugging, quality assurance, customer support, and production incidents.
The solution isn't necessarily to slow development. It's to make verification scalable.
The Shift From Reviewing Code to Verifying Behavior
Vered sees software engineering moving through three stages:
Writing code: Developers implement the functionality themselves.
Reviewing code: AI generates the implementation while developers inspect its output.
Defining and observing behavior: Developers specify what the software must accomplish and verify that it actually does so.
The distinction matters.
Imagine a subscription business introducing a new billing feature. A traditional review examines the implementation: Are the functions correct? Are dependencies handled properly? Is the code secure and maintainable?
A behavior-focused review asks different questions.
Can a customer successfully upgrade a subscription? Does the correct amount appear at checkout? Is the payment recorded? Does the account reflect the new plan? Can an existing customer still cancel successfully?
Both perspectives matter. But only the second directly demonstrates the experience customers encounter.
In his interview on 21st Century Entrepreneurship, Vered described the emerging engineering role as being centered on defining desired behavior and verifying the implementation through automated and manual methods.
This doesn't eliminate the importance of source-code inspection, architecture, or security review. Rather, it makes functional evidence a more central part of release decisions.
For engineering leaders, the management question changes from How much code did we produce? to How much verified functionality can we safely deliver?
How Deterministic Testing Makes AI Development More Reliable
One of the most important distinctions in Vered's approach is the difference between using AI to design tests and depending on AI to judge every test execution. Checksum uses AI agents to understand application workflows, identify test scenarios, and generate deterministic tests using Playwright, an established end-to-end testing framework.
The resulting scripts then execute through conventional software instructions.
The AI proposes what should be tested. The test runner performs repeatable checks against expected outcomes. That distinction is critical.
An AI model asked to decide whether something looks correct can produce inconsistent judgments. A deterministic assertion—for example, that a successful checkout must display a specific confirmation and create the appropriate account state—provides a defined pass-or-fail condition.
Of course, deterministic tests are only as trustworthy as the assumptions and assertions behind them. An AI-generated test can still encode the wrong expectations, overlook important edge cases, or fail because of an unstable environment. The value comes from combining AI's ability to generate and maintain testing scenarios with the predictability of executable verification.
Regression Testing Protects What Already Works
Consider an application with interconnected authentication, billing, reporting, and account-management functions.
A change to one component may affect another in ways that aren't immediately obvious.
Regression testing checks whether previously working behaviors continue to function after changes.
Vered wants this process to become increasingly automated.
When a pull request introduces a change, an AI-assisted testing system can identify affected workflows, generate relevant test scenarios, and execute existing and new checks before release.
Successful results reduce the amount of repetitive manual checking required. Failed tests can direct engineers toward specific behaviors that need investigation.
Evidence Matters More Than a Green Checkmark
A test result is most useful when developers can understand what happened.
Vered emphasizes artifacts such as videos, execution traces, and step-by-step snapshots.
These allow an engineer to examine the actual user journey rather than relying exclusively on a textual assertion that a test passed.
Playwright's Trace Viewer, for example, allows developers to inspect recorded actions, snapshots, and debugging information from test runs.
For a founder or product manager, visual evidence can also make technical verification more accessible.
The review conversation becomes less about interpreting thousands of lines of generated code and more about assessing whether the product behaves as intended.
What Software Teams Can Learn From Managing AI Agents
Vered's perspective on testing is closely connected to how he manages AI agents in his own working day. He describes treating agents much like employees to whom meaningful tasks can be delegated. Before going to sleep, he prepares the next day's priorities and identifies work that can be assigned to AI.
Rather than issuing a vague instruction and hoping for the best, he provides context, works through an execution plan, and establishes acceptance criteria.
The agents then operate remotely while he sleeps, commutes, or attends meetings.
He reviews the outputs at intervals and supplies further direction where necessary.
In his account, roughly 70% of his personal task list can often be delegated, with agents producing about 90% of the desired result before he completes the remaining work. Those figures describe his own experience, not a benchmark that every organization should expect to reproduce.
But the underlying method is transferable.
Effective AI delegation requires four elements:
Context: Explain the business problem and relevant constraints.
Alignment: Agree on the plan before execution begins.
Acceptance criteria: Define what a successful result must demonstrate.
Reviewable evidence: Require an output that can be assessed quickly.
Vered offers a presentation as an example. Instead of merely asking an agent to create slides, he specifies the outline, requires the agent to inspect images of the completed slides, and asks for a PDF delivered through WhatsApp.
The same principle applies to software. A completed pull request is not sufficient evidence of success. A demonstrable, verified user journey is much more useful.
The broader lesson for entrepreneurs is that delegating tasks to AI increasingly resembles management rather than traditional software operation.
Why Small Teams Need Enterprise-Level Verification
AI changes the relationship between team size and technical complexity.
A small startup may now operate a product that integrates payment systems, cloud infrastructure, authentication providers, customer databases, and several AI services.
The team may be small, but the system is not.
Vered distinguishes between relatively simple internal applications and complex software delivered to customers. For basic use cases, he recommends starting with existing coding tools such as Claude Code or Codex and determining where their capabilities become insufficient.
For complex enterprise workflows, he argues that deeper, tailored testing infrastructure becomes more valuable.
This distinction prevents an important mistake: confusing sophistication with necessity.
Not every company requires an additional testing platform. But every company needs verification proportional to the consequences and complexity of failure. For a simple internal dashboard, manual checks and a modest automated test suite may be adequate.
For a customer-facing application handling critical transactions or intricate workflows, relying primarily on manual quality assurance can become a major operational bottleneck.
The objective should be to reserve human attention for decisions that genuinely need human judgment while automating repeatable verification wherever practical.
Could Software Verification Become More Important Than Code?
Vered's longer-term vision extends beyond testing individual application workflows. He imagines a software verification layer that can simulate increasingly complex environments before new code reaches production.
He compares the idea to autonomous vehicle development, where simulated environments allow systems to be evaluated against many scenarios before operating in the physical world.
For software, a sufficiently mature simulation environment could reproduce interactions among users, infrastructure, third-party services, and application components. The ambition is to make verification so comprehensive that autonomous coding systems can operate with much greater independence. That remains a vision rather than an established guarantee.
No finite collection of tests can conclusively prove that a complex application has no possible defects. Simulated environments can also fail to capture real-world conditions. Still, the strategic direction is significant.
If generating software becomes increasingly inexpensive, the ability to specify correct behavior, construct trustworthy tests, and demonstrate operational reliability becomes more valuable.
This may also change how companies evaluate engineering productivity. Lines of code, ticket counts, and development speed reveal activity. They do not establish customer value or reliability. Verified outcomes offer a stronger foundation for decision-making.
What Founders Should Do This Week
The immediate opportunity isn't to redesign an entire engineering department. It's to identify one recurring release problem and improve the evidence required before shipping.
Choose a customer journey that matters commercially: registration, checkout, onboarding, subscription renewal, or another critical workflow.
Document its expected behavior, including failures and edge cases.
Then ask the development team to create or improve an automated end-to-end test that demonstrates the workflow from the user's perspective.
Run it against the next relevant change. Review the results, inspect failures, and determine which parts of the process can be automated further.
This small experiment can reveal whether the organization has a code-generation problem, a verification problem, or both.
The central insight from Vered's approach is that AI doesn't eliminate the need for engineering judgment. It changes where that judgment creates the most value.
The winning question may no longer be how quickly a team can write software. It may be how confidently that team can prove the software works. And that is a question every founder should be asking before the next release.
Comments