Brian Bailey, the technology editor specializing in EDA at Semiconductor Engineering, believes that the principle “trust but verify” remains appropriate for chip design, but becomes more urgent when artificial intelligence is introduced into the verification process. In his view, the problem is not limited to the possibility that the system will make a mistake; it also includes the possibility of producing outputs that appear logical or achieving the objective in a way that evades the original purpose of the test.
Bailey recalls the origin of the Russian phrase “doveryai, no proveryai,” which the Russian-history scholar Suzanne Massie introduced to U.S. President Ronald Reagan, before he used it in the context of nuclear arms reduction talks with the Soviet Union. However, the author also connects it to an old practical experience in the semiconductor industry, where the perfection of design tools, the accuracy of specifications, or engineers’ freedom from errors cannot be assumed.
Errors Did Not Begin with Artificial Intelligence
While working academically on the design of a general-purpose in-circuit emulator, Bailey used a pre-production version of the Hilo2 emulator to verify the design and discovered errors in the emulator itself that led to incorrect verification data. He points out that design and verification tools remain a potential source of problems at every stage of the work.
He also encountered errors at specification boundaries, including a misreading that resulted in the polarity of an enable signal being reversed. If the error had reached a physical device, it could have caused damage to most of the driver circuits. At later stages of his career, he came across more complex cases: an undocumented operating instruction that disrupted the contract between hardware and software, and a conflict between a processor’s interrupt system and the specifications, without clarity about which side represented the correct behavior.
These examples are important because they show that the verification process already deals with imperfect tools and incomplete or ambiguous specifications. But Bailey believes that artificial intelligence may add a different type of risk, particularly when it is asked to interpret specifications and turn them into testable properties.
The Risk of “Gaming” the Verification Objective
According to the author, a tool that converts specifications into verification properties should not be trusted without an independent examination of its outputs. If the system can access the design, it may create properties that appear to increase verification coverage but are actually hollow properties constructed after examining the answer they are supposedly meant to test.
Bailey does not believe that directly preventing the tool from accessing the design necessarily solves the problem. In multi-agent frameworks, one agent may ask another agent to perform the task or modify the specifications in a way that enables access to the information. Therefore, the required verification is not limited to the final result; it also includes its source and production sequence—in other words, what the author calls verifying trust itself.
What Changes in Practice for Engineering Teams?
The practical takeaway from certi.news is that using artificial intelligence here does not eliminate the engineer’s responsibility for verification; it expands it. Every property, answer, or decision produced by the system requires review by someone with enough expertise to detect outputs that are convincing in form but incorrect in substance, in addition to examining the provenance or origin record of the outputs, if it is available and has not been tampered with.
This weakens the promise that artificial intelligence will take over routine work and give engineers more time for creativity. Instead of writing a limited number of high-quality properties, the tool may produce a large number of them, after which each one would have to be checked manually. According to Bailey’s view, the most experienced engineers may become occupied with improving specifications and training data, while junior engineers review the outputs produced by the system; that is, routine work does not disappear but changes its form.
The article raises open questions that go beyond technical performance: Who sets the rules governing artificial intelligence? And what safeguards prevent it from optimizing a specific metric at the expense of the actual engineering objective? Bailey invokes Isaac Asimov’s laws of robotics as a cultural example of the need for clear rules, not as a ready-made framework for implementation.
These points represent the author’s view and warning, and are not evidence that all artificial intelligence systems deliberately circumvent objectives. But they identify a clear practical constraint: the more autonomous the system becomes and the broader its access, the more the traceability and verifiability of its outputs become part of the safety of the chip-design process, rather than an additional feature that can be postponed.