Testing AI-Generated Code: 5 Things Engineers Told Me at SF Tech Week 2026

In October I spent a week at SF Tech Week. Breakfast with 66 CTOs at Zendesk. A panel on reliability and security in AI native products, hosted by the PMI San Francisco Bay Area Chapter. A generative UI night at WorkOS. And a lot of hallway conversations with people who ship code written by AI every day.

I asked almost everyone the same question: how do you test code that nobody wrote by hand?

Five answers kept coming back. Here they are, with what I would do about each one after 16 years in QA.

1. “Half our code is AI-written. Our tests weren’t built for that.”

Co-founder, AI startup

Most test suites were designed around how people write code. A developer changes one area, writes tests for it, and a reviewer reads the diff. AI breaks that pattern. It produces more code per day, touches more files per change, and makes a different kind of mistake: logic that reads well and is wrong, edge cases that are simply missing, a package added without anyone asking for it.

Veracode’s latest GenAI code security update, published in October 2026, tested 18 models and found that roughly 4 in 10 coding tasks still produced code with a known security flaw. That number alone is a reason to stop treating AI output like code from a senior engineer, and to put a security check in every release instead of once a year.

What to change:

• Track where AI-written code lands, and point your regression tests there first.
• Add edge cases on purpose: empty input, bad data, a slow network, the second click on the same button.
• Review what the change does, not only how clean it looks.

2. “The AI writes the test and the code. Who checks the AI?”

Engineering manager

When the same model writes the feature and its tests, both carry the same assumptions. The tests pass because they agree with the code. That says nothing about whether the code does what the product needs. Developers feel this too: in Stack Overflow’s 2026 Developer Survey, 48% said they trust AI when they can easily validate its answers.

What to change:

• Keep one independent source of truth: acceptance criteria written by a person who knows the product, and tests written by someone who didn’t write the code. That can be your own QA engineer or an outside QA team.
• Use AI where volume matters. Generating hundreds of input variations, including hostile ones, is something no human team can do at that scale.
• If a model grades another model, have people grade the same sample every week and compare. When agreement drops, the green dashboard stops meaning anything.

The way I put it on the PMI panel: AI scales the verification. Humans own the definition of truth.

3. “Green pipeline doesn’t mean it works.”

AI engineer

This one surprised me most, because it came from someone who builds AI tooling for a living. Passing tests only prove what you thought to check.

The best public example is OpenAI’s GPT-4o update in April 2025. Offline evaluations looked good, and A/B tests suggested users liked it. A few expert testers said the model felt slightly off. OpenAI shipped on the strength of the numbers, rolled the update back within days, and wrote in its own postmortem that this was the wrong call.

Anthropic had a similar lesson a few months later. Three infrastructure bugs degraded responses for weeks, and their postmortem says plainly that the evaluations they ran didn’t capture the degradation users were reporting.

What to change:

• Monitor correctness, not only uptime. Your monitoring tells you the system is up. Nothing tells you it is right.
• Have a person read a sample of real production output every week.
• Turn every bug that reaches a customer into a test the same day.

4. “QA can’t keep pace with AI-generated code.”

Product manager

Output scaled ten times. Review capacity didn’t. Most teams react by cutting the review, and what gets cut is always the same: edge cases, real behavior, the dependencies nobody looked at.

The better answer is to make the feedback loop faster instead of shorter. With DualSoft, an i-gaming client, we took the regression run from 30 minutes to a minute and a half. At 30 minutes, you test some releases. At 90 seconds, you test every release, including the hotfix at 11pm before a big match.

What to change:

• Automate the checks that repeat, so people spend their time on the changes that carry real risk.
• Decide per change how much human attention it needs. A copy change and a payment flow should not get the same review.
• Measure how long a release waits for testing. If that number grows every month, you will start skipping steps.

5. “Nobody knows how the product actually works anymore. It’s in people’s heads.”

Project manager

If it isn’t written down, it can’t be tested. AI made this worse, because code now changes faster than any document describing it. The real behavior of the product lives with two or three people, and every new feature, test case and support answer is rebuilt from their memory. In Stack Overflow’s 2026 Developer Survey, the most trusted source of information for developers was still the people they work with, at 72%, ahead of code and documentation.

What to change:

• Write expected behavior down as test cases, starting with the flows that make money or can cause damage.
• Have the person who knows the flow sign off on those cases.
• Keep them next to the code, so they change when the product changes.

We built Asserta for exactly this problem: AI maps how your product works, and your team verifies that map before anyone writes tests from it.

What testing AI-generated code needs now

AI made writing code cheap. Checking it did not get cheaper. The teams I met that ship well treat testing as the thing that lets them keep the speed.

One example from our own work: a large US engineering company we have worked with since 2020 had no QA process when we started. Today they run more than 6,500 automated tests, and releases went from every six months to every two weeks. The speed came from the tests.

Want an outside check before your next release?

We run a free 7-day QA and security program for web and mobile apps. A 30-minute kickoff, seven days of testing by our QA engineers and security specialists, and a final report with every issue, its severity and how to reproduce it. No contract, no credit card.

Apply for the free program

Which of the five is true at your company? Tell me on LinkedIn.