Last week, OpenAI launched a $4 billion company called DeployCo. It’s not a model, not an API, not a product (What now?!?!). It’s a consulting firm. Its entire purpose is to send engineers, Forward Deployed Engineers(FDEs), to sit inside enterprise customers and build custom AI workflows for them. On day one they acquired Tomoro, a 150-engineer consultancy, just to staff it. Anthropic announced something similar with Blackstone and Goldman Sachs in the same week.
Why am I, a verification engineer, writing about this?
Because one of OpenAI’s first public FDE job postings is titled “Design Verification, Forward Deployed Engineering.” They want someone with UVM, SystemVerilog, and a few years of real SoC verification experience plus AI/LLM fluency, to embed inside chip companies and rebuild verification flows around AI agents. I read the job description and it felt like someone took my resume and turned it into a hiring brief. So I went digging.
The 70% Number You Already Know in Your Bones
In a previous post I wrote about the 2024 Wilson Research Group study, the data showed verification engineers spend 21% of their time just debugging, design engineers spend 49% of theirs on verification, and only 14% of IC/ASIC projects hit first-silicon success. That’s the lowest in two decades.
Now here’s the part that connects: in a writeup of OpenAI’s FDE practice, the team described embedding on-site with a European semiconductor company for weeks. They mapped the whole chip lifecycle. Their finding? Engineers spend 70–80% of their time on bug fixing and compatibility maintenance, not new development. They picked verification as the highest-value workflow to target.
This isn’t a surprise to any of us. Open any regression dashboard on the first day of the week… it’s a wall of unknown failures, half of them probably the same flaky test, and you don’t know which is which until you dig. The thing that is new is that the company that built ChatGPT just put a $4 billion bet on fixing it.
What’s a Forward Deployed Engineer, Actually
The role wasn’t invented at OpenAI. Palantir created it in the early 2010s, codenamed “Delta.” The idea was simple: complex software doesn’t deploy out of the box. You can’t just ship a license to a government agency or a Fortune 500 customer and walk away. You need engineers embedded inside the customer, blurring the line between consultant, software engineer, and product manager. Make the thing actually work in the real world.
Now AI labs are running into the same wall. The model is amazing in a sandbox. It breaks in real environments full of legacy tools, weird scripts, and tribal knowledge. So OpenAI and Anthropic are copying the Palantir playbook at scale. LinkedIn data shows FDE job postings grew 42× between 2023 and 2025. Even AMD just posted an internal “Principal Engineer – AI/ML Forward Deployment Engineering” role. The pattern is spreading inside semiconductor companies, not just at the labs.
What It Looks Like at the Bench
OpenAI’s DV-FDE posting spells out the targets explicitly:
- Change-aware test selection: given a code change, which tests are worth re-running?
- Directed test generation: generate stimuli for specific coverage holes
- Intelligent regression triage: sort signal from noise in massive log dumps
- Coverage closure: find the unreached bins and write the tests
- Debug: root-cause failures across RTL, testbenches, waveforms
These aren’t speculative. There’s already real research and tooling here. Infineon researchers just published an agentic AI coverage closure workflow for formal verification. The VerilogReader paper showed LLMs can actually read Verilog and generate input sequences that beat random testing on real DUTs. Synopsys has commercialized this in VSO.ai for coverage and Verdi RDA for regression debug. And as I wrote in my Siemens QuestaOne post, even traditional EDA vendors are shifting from “faster engines” to “faster engineers.”
But – and this is important – none of these tools work alone. A recent EE Times piece by a veteran DV consultant put it well: AI “reduces the search space but does not replace engineering judgement.” Hallucinations are real. Prompt sensitivity is real. The compute cost is real. When I’m debugging a tricky reactive sequence with a race condition, I don’t want to type prose at a chatbot. I want precise control over my testbench.
That’s exactly why FDEs exist. You need a human engineer with deep DV knowledge in the room to make any of this actually deploy.
Augmentation vs Automation, Again
I keep coming back to this thesis on my blog: AI works when it augments engineers, not when it tries to replace them. The Wilson study showed verification challenges outpacing our ability to solve them. The OpenAI FDE play is, at its core, an admission of the same thing. They’re not selling “an AI that replaces your DV team.” They’re selling “an engineer who arrives at your office and rebuilds your flow around AI.” The human is still in the loop. The deployment is the product.
This connects directly to something I wrote about junior engineers being squeezed by AI. The risk hasn’t gone away… if AI handles all the regression triage and basic coverage analysis, where do juniors learn the fundamentals? But the FDE model gives me a little more hope than pure automation does. Because it preserves the engineer. It just changes what the engineer does.
What This Means If You’re a Verification Engineer
Honestly? The OpenAI DV-FDE posting is the clearest career map I’ve seen in a while.
- Keep your UVM and SystemVerilog skills sharp. They’re not going anywhere. They’re now the moat, the specialized knowledge that AI alone can’t replicate.
- Add real fluency with LLMs and agentic workflows. Not “I used ChatGPT once.” More like: you can architect a flow where an agent reads logs, decides which failures are duplicates, and proposes the next test.
- Get comfortable with Python tooling. (If you’re not already, start with my pyUVM series.)
- Pay attention to the deployment layer. Knowing how to integrate AI into a verification flow – debug agents, coverage agents, triage agents – is the skill that separates “I can run a tool” from “I can rebuild a team’s workflow.”
I don’t know if OpenAI’s DeployCo bet will work. I don’t know if Anthropic’s parallel move will pay off. I don’t know if my regression dashboard will look fundamentally different in two years or twenty. What I do know is that the most interesting job posting I’ve seen this year wasn’t from a chip company. It was from an AI lab asking for someone like me.
That’s worth paying attention to.
If you want to dig deeper, my previous posts on the state of verification in 2024 and Siemens’ AI verification vision lay out the underlying thesis. What’s your take? are you seeing FDE-style embedding in your company yet? Have you tried AI agents on real regression triage? I’d love to hear what’s working (and what’s not) at your bench.
