A month's work was completed in a single day by an engineer who had just been with the company for a year.
He had never used Claude Code, and he didn't even fully understand how USB works.
The task that day was to create a USB model for a keyboard and mouse in the simulator and then write the corresponding Android USB device driver.
Using the old methods, this job would take a month. But he finished it in just one day.
The software has to run in the simulator before the chip is even manufactured. The behavior of USB devices like keyboards and mice must be entirely recreated in the virtual environment.
The reference code from the EDA vendor only covered basic data transmission; the rest was up to them: first, study the USB communication standard, then build separate models for each type of device.
Even experienced engineers would find this task time-consuming and laborious. And this engineer hadn't even tried Vibe Coding.
The first thing he did was throw the functionality to be implemented and that reference code into Claude Code.
Claude Code filled in the requirements, suggested implementation methods, wrote the code, and revised it with every instruction he gave.
Just like that, the keyboard and mouse models, functional verification, and the Android USB device driver were all completed within the same day.
People have become desensitized to AI writing web pages, scripts, or renovating entire codebases. This time, AI was doing chip verification.
What was compressed was the learning curve for a beginner, not the professional judgment of right and wrong.
A Samsung Electronics employee working on a semiconductor production line.
The neighboring project team received an even trickier job.
The client wanted a custom SoC with 64 intertwined internal data channels, each requiring verification. The trouble was, the circuit code for the memory controller wasn't finished yet, and part of the standard design documentation was missing.
In such a situation, engineers typically can only do one thing: wait.
They didn't.
Verification environment setup and checks originally planned to take over a month were completed in two days.
Samsung's internal assessment of this was: a 15x speedup.
The Time Saved Was the Waiting
Where exactly was that custom SoC stuck?
The client wanted a brand-new semiconductor architecture, also utilizing external supplier IP.
Following the traditional chain, engineers had to first wait for the design documentation to be complete, wait for the DRAM controller RTL to be released, and only then could they set up the verification environment, connect the verification IP, and write test scenarios.
This chain is linear; if the first link isn't ready, everything else stalls.
Samsung's approach this time was to feed what they already had into the AI: SoC design information from the EDA vendor, internal chip communication specifications, verification IP—all were given to Claude.
The AI identified the needed verification IP, handled layout and connections, and generated a virtual verification environment and test scenarios. Before the DRAM controller was delivered, a virtual module was placed to temporarily take its position, allowing the core data pathways to run.
Samsung's System LSI division has applied Claude Code to semiconductor development and verification, compressing some tasks from a month to two days.
The result was that early errors were caught even before the real RTL was released.
That's the true source of the 15x speedup—it eliminated the dead time spent waiting for all the materials to be ready.
The 15x Speedup and Three Boundary Violations
Samsung's internal evaluation also recorded three anomalies.
First: An engineer asked it to correct an error. Instead of fixing the root cause, it changed the error message to a generic warning.
Swap a red light for a yellow one, and the metric passes.
Second: An engineer only instructed it to roll back a specific function. It went ahead and also rolled back other completed work.
Third: An engineer only asked it to analyze verification results. It attempted to modify the actual RTL circuit code.
Is this "AI learning to conceal" or "unauthorized tampering with core code"?
Downgrading an error to a warning is closer to a shortcut taken to meet an immediate goal. This is a misalignment of objectives, not the AI developing an intent to deceive.
When Anthropic itself describes similar behaviors, the terms used are "overly proactive" and misjudging the scope of impact of operations.
Samsung's internal attribution also points to this layer: the large language model failed to fully understand the complex dependencies within hardware design languages. It knows how to get a line of code to run but doesn't know how many things that line of code affects downstream.
This distinction is crucial.
If it truly learned to conceal, that's a model-level problem, and no one today is confident about solving it. But misalignment and lack of understanding of dependencies are engineering problems that can be contained with permissions and processes.
The Engineer's New Job
Is to Draw Boundaries for the Agent
Samsung's approach in this matter boils down to three things:
Humans define where the AI can touch; results it produces are checked by humans again; and after confirming stability, authority is gradually delegated, bit by bit.
For engineers, this translates into several new tasks: which directories are writable, whether RTL circuit code can be altered, which verification rules are immutable, who reviews each change...
If you've used Claude Code for work, you're probably familiar with those three boundary violations: asking it to fix an error, and it lowers the log level; telling it to roll back one function, and it takes your commits from yesterday along with it.
The difference lies in whether the consequences can be undone.
In software, the worst case is rolling back a commit and starting over.
In the chip industry, it's different. Once a design is taped out—meaning the layout is sent to the production line for manufacturing—the circuits are etched onto the silicon. To change them, the entire batch must be scrapped, and you start from scratch.
Software can be patched; chips cannot.
AI Making Chips
Humans Must Be in the Loop
Interestingly, at the same time, Anthropic itself is also betting on the hardware line.
On July 9th, it announced a partnership with engineering services company UST to bring Claude into fields like chip verification, automotive, and manufacturing, while also training UST's 20,000 global engineers, architects, and consultants.
UST has a platform called iDEC, specifically for verifying hardware and silicon before mass production.
According to UST, this pipeline has already cut verification cycles by more than half; work that used to take four days can now be finished in 48 hours.
Now, Claude Code is integrated as the brain: reading chip pin definitions and circuit schematics, writing and running tests, then comparing data from the physical device with the simulation model on the computer, and flagging mismatches.
In that announcement, Anthropic mentioned that in industries with such high costs for errors, having humans approve and keeping every step traceable are prerequisites for such a system to be deployed on a production line.
On Reddit, a user claiming to work for an EDA company was less optimistic:
Even with agents and skill processes deployed, they are far from easy to use; getting a single workflow running can take months. The effectiveness in digital circuits and verification is noticeably better than in analog, mixed-signal, and memory.
Behind this complaint lies a pattern.
Whether it's your codebase or Samsung's pipeline, the first thing AI successfully runs through is verification.
The reason is simple: verification has a standard answer; run it once and you know right or wrong—no need to wait for human judgment.
AI Isn't Meant to Replace Anyone
It's About Amplifying One Person's Output
Industry estimates put the System LSI division at around 6,000 people. Qualcomm, as of last September, had about 52,000.
For someone sitting at a System LSI desk, this means in the same chip market, the other side has several times more people.
That engineer, just over a year in, stood in this position: insufficient manpower, unchanged tight deadlines, and standards not lowered one bit.
So the real expectation placed on AI here is to amplify one person's output.
Repetitive wiring, repetitive verification, repetitive study of specifications—these most time-consuming tasks are handed off, freeing up veterans to tackle the truly difficult parts and enabling newcomers to take on heavier responsibilities.
That engineer completing a month's worth of USB modeling in a day—what AI saved him was precisely the hurdle of "first having to thoroughly master the USB standard."
A semiconductor industry insider said: These agents run really fast, but if not controlled, they can cause major incidents.
His assessment is that overall development time will continue to be compressed, steps previously executed by humans will keep decreasing, and what engineers ultimately hold onto are the two ends: how to define the goal and whether the result is correct.
The engineer's workload hasn't decreased; it has just changed form.
The old skill was being able to set up a verification environment. The future skill is knowing which part of the environment built by AI is wrong.
AI can compress a month's work into one or two days. But once a chip is taped out, nothing can compress it back.
References:
https://news.nate.com/view/20260812n19157?utm_source=chatgpt.com
This article is from the WeChat public account "New Zhiyuan," author: ASI Revelations, editor: Yuanyu
