AI-Driven Development: Why Verification Matters More Than Ever

By Alexandre Manuel and Julia Baucher

September 3, 2026

Artificial intelligence has become one of the biggest topics in engineering. From code generation and documentation to design exploration and debugging, new AI tools promise to accelerate almost every stage of development. 

Alongside that excitement comes an equally familiar question: Can engineers trust the results? It’s an understandable concern. Engineering depends on accuracy, and AI doesn’t always produce accurate answers. But after using AI extensively while developing verification software at Arteris, I’ve come to believe we’re asking the wrong question.

Rather than asking whether AI can always be trusted, we should ask a much more practical question: How easy is it to verify what AI produces? That distinction may seem subtle, but it fundamentally changes how AI fits into the engineering process.

Learning from the last information revolution

This isn’t the first time engineers have wrestled with a technology that seemed both transformative and uncertain. When internet search engines became mainstream, engineers quickly learned that the answer wasn’t to avoid them. It was to verify what they found before relying on it. Search engines became indispensable not because every result was correct, but because engineers understood where they fit in the design process.

AI feels like the next chapter in that story. Large language models generate ideas, propose implementations, and explore solution spaces rather than simply retrieving existing information. They don’t remove the need for engineering validation; they shift more of an engineer’s effort from searching to evaluating.

The insight that changed my approach

That realization came while I was developing a C++ constrained stimulus generator used for verification at Arteris. Generating valid constrained stimuli is a difficult problem because every test case must satisfy numerous relationships and constraints simultaneously. However, verifying that a generated stimulus is correct is comparatively straightforward.

That contrast led to a simple question: “If I can easily recognize a buggy behavior, then I can ask an AI to find a scenario that triggers it.”

The first experiment focused on segmentation faults. The validation criterion couldn’t have been simpler: “The program segfaults, yes or no.” Instead of manually inventing input scenarios, I asked AI to generate candidate test cases while an automated framework verified the results. AI explored, the software validated, and I investigated only the remaining failures.

The process uncovered multiple tests that triggered segmentation faults. Some exposed the same underlying defect, while others exercised entirely different parts of the implementation. Each represented a genuine defect that the development team could then investigate and resolve.

One of the failures identified through this process also reproduced an issue that had been encountered independently during development. After addressing the underlying defect, that example no longer failed. That was the moment my perspective changed, and I realized that AI hadn’t debugged my software. It had dramatically accelerated the search for problems worth debugging.

From debugging assistant to adversarial sparring partner

The obvious next question was whether the same approach would work beyond segmentation faults. Memory leaks proved to be another ideal candidate, so rather than asking AI whether memory management was correct, I asked it to generate execution paths. At the same time, automated analysis tools verified the results. The methodology uncovered a memory-management issue.

By then, I had stopped thinking of AI as a coding assistant. It had become something much more useful: an adversarial sparring partner, constantly exploring combinations I might never have considered manually and exposing weaknesses I could then investigate with confidence.

Designing software that is easy to verify

The biggest lesson wasn’t about AI at all. It was about software design. Generating constrained stimuli is difficult. Checking whether a generated stimulus satisfies every constraint is much easier. That observation led me to build verification directly into my constrained stimulus generator itself. Every generated sample is self-validating, raising an exception when a constraint is violated before incorrect behavior can propagate further.

Once the software defined correctness, AI had a clear objective: search relentlessly for inputs that triggered the verification mechanism. That approach further increased our verification coverage across different test cases and, more importantly, established a repeatable methodology for identifying potential future issues.

The principle extends far beyond testing.

At first glance, this might sound like a methodology for software verification. In reality, the principle extends much further. Engineering is full of search problems. We search documentation, compare architectures, evaluate implementation strategies, investigate standards, and weigh design trade-offs before making informed decisions. Finding the right information often consumes far more time than verifying it.

That was the biggest realization from this experience: “A huge amount of the information in our job is much easier to verify than to find.”

Viewed through that lens, AI becomes less of an answer engine and more of a discovery engine. Its value lies in accelerating exploration while engineers remain responsible for deciding what is correct.

A practical framework for using AI

One practical lesson emerged from this work. Rather than asking, “Can I trust this answer?”, ask a different question: “How difficult is it to verify?” When verification is objective, inexpensive, and largely automated, AI can dramatically accelerate exploration while maintaining rigorous engineering controls.

Two habits have shaped the way I now approach AI-assisted development: 

• First, measure the research-to-verification ratio of your day. How much time is spent searching for information versus evaluating it? 
• Second, classify problems by the level of reliability they require. 

Those simple questions provide a practical framework for deciding where AI can create the greatest value.

Verification remains the engineer’s responsibility.

AI models will continue to improve. They will search larger design spaces, generate stronger proposals, and uncover increasingly subtle problems. What is unlikely to change is the engineer’s role.

Engineering has never been about collecting information. It has always been about evaluating evidence, making decisions, and accepting responsibility for the outcome. AI-driven development is therefore not about replacing engineers, but about enabling them to spend less time searching and more time applying their expertise where it matters most.

The teams that benefit most will be those that build software designed for verification, use AI to accelerate exploration, and maintain rigorous engineering validation throughout the development process. Because in the end, the most valuable contribution AI makes is not eliminating verification. It is making the search dramatically faster.

Explore Arteris IP:

• FlexNoC Interconnect IP
• CodaCache Last-Level Cache IP
• FlexGen Smart Network-on-Chip (NoC) IP
• FlexWay Interconnect IP