Reported operating use · Semiconductor engineering and FDE delivery
AI chip verification workflows: OpenAI example
OpenAI's account describes its forward deployed engineers embedding with an unnamed semiconductor company's verification team to build directed-test generation, debugging and architecture assistance. Custom applications later moved onto shared Codex harnesses, plugins and skills, with customer engineers helping define evaluations.
Build and reuse AI-assisted chip-verification workflows
Unnamed semiconductor company
OpenAI reports production and early adoption across an unnamed customer’s verification use cases; the initial work began in 2025.
A published third-party example, not a Nuvepro customer case or evidence of a partnership.
The workflow at a glance
Build and reuse chip-verification assistance
Illustrative summary of the published account
Reported work components. Their arrangement does not imply a fixed execution order or simultaneous work.
- Embedded engineering
FDEs and verification engineers
Teams build directed-test generation, debugging and architecture assistance.
- Shared tooling
Codex harnesses, plugins and skills
Custom applications move toward reusable harnesses with adapted connectors.
- Evaluation
Customer engineers help define checks
Evaluations and integrations are adapted for additional teams.
What the source reports
OpenAI’s FDE account describes engineers embedding with a semiconductor verification team to build directed-test generation, debugging and architecture assistance, with customer engineers helping define evaluations. It later describes moving custom applications onto shared Codex harnesses, plugins and skills, while adapting connectors and evaluations for additional teams.
Reported technology: OpenAI Forward Deployed Engineering and Codex. Scope and outcomes are source-reported.
What the enterprise environment would need
The following is a proposed project design for an enterprise doing similar work. Published details are marked; the remaining systems, data and scenarios would be agreed for your project.
Proposed practice environment
Build a bounded verification assistant
Illustrative project design to scope with your enterprise.
- 1 · Set up the environment
Licensed design and test fixtures
Use an approved design subset, specification, testbench and seeded defects with independent expected behavior.
- 2 · Preparation and agent contributions
Agent proposes tests and diagnoses
Connect only agreed tools; retain design and harness versions.
- 3 · Independent checks
Domain engineers reproduce results
Check that tests expose known defects and rerun unchanged regressions after repair or adaptation.
- 4 · People decide acceptance
Verification owner accepts demonstrated scope
Review tool authority and diagnosis support before any separate production decision.
A reviewable evidence package
Useful directed tests and supported diagnoses with a second-context adaptation report.
If a check fails → withhold acceptance.
A generated test shares the diagnosis’s wrong assumption. A separate reference and seeded defect must expose both.
Failure or owner rejection returns to review
- Hold
- → 2 · Revise work
- → 3 · Rerun independent checks
- → 4 · Owner review
Operating boundary. Generated tests cannot redefine expected behavior or authorize production changes.
- Systems and tools
- Published: custom harnesses evolved into shared Codex-based plugins and skills. Proposed: connect only the agreed test-design, repository and simulation tools in a licensed engineering environment.
- Data and state
- Proposed: use an approved design subset, specifications, testbench and seeded failures with known expected behavior; retain their versions.
- People and handoffs
- Published: FDEs worked with customer verification engineers on evaluations. Proposed: domain engineers review generated tests and diagnoses before accepting changes.
- Rules and authority
- Proposed: restrict design and repository access; generated tests cannot redefine the expected behavior or authorize a production change.
- Normal and exception cases
- Proposed: include a real design defect, an incorrect test expectation, ambiguous specification and a failure that cannot be reproduced.
- Reset and replay
- Proposed: rerun held-out cases after harness, skill, model or connector changes; verify adaptation to another team rather than assuming transfer.
A proposed simulation
An illustrative practice design derived from this work, not an executed assessment.
Build a bounded verification assistant, demonstrate useful tests and supported diagnoses, then adapt it to a second approved design context.
Review gate: Independently verify test effectiveness, diagnosis support and tool authority, preserving domain-engineer acceptance.
Challenge the result: Allow a generated test to encode the same wrong assumption as the agent’s diagnosis. A separate reference and seeded defect must expose the shared error.
What needs checking
- Proposed: domain experts qualify expected behavior independently of the generating agent and check that tests expose known defects.
- Proposed: reproduce diagnoses and rerun unchanged regression checks before accepting a proposed repair.
- Proposed: record integration, expert review and correction effort when reusing the harness on another team.
Review environment fidelity, human capability and agent performance separately. The enterprise’s accountable owners decide acceptance of the shared workflow and any operating use.
How an enterprise could build similar work
A proposed build order for an enterprise doing similar work, written by Nuvepro from the published account and our interpretation of the environment and checks above. It is not how Unnamed semiconductor company built or operates this work.
- Scope a bounded verification assistantThis is a proposed design for a similar project, not the described organisation's method. Build a bounded verification assistant connected only to agreed test-design, repository and simulation tools in a licensed engineering environment.
- Prepare designs and seeded failuresUse an approved design subset, specifications, a testbench and seeded failures with known expected behaviour. Retain their versions, so every result can be rerun later against exactly the same inputs.
- Set authority and review rolesRestrict design and repository access. Generated tests cannot redefine the expected behaviour or authorise a production change. Domain engineers review generated tests and diagnoses before accepting any change, and the agent's tool permissions are written down.
- Include hard casesInclude a real design defect, an incorrect test expectation, an ambiguous specification and a failure that cannot be reproduced. These show whether the assistant's tests and diagnoses are supported and not merely plausible.
- Verify tests and diagnosesDomain experts qualify expected behaviour independently of the generating agent and check that tests expose known defects. Reproduce diagnoses and rerun unchanged regression checks before accepting a proposed repair. Let a generated test share the agent's wrong assumption, then confirm a seeded defect exposes it.
- Adapt to a second teamRerun held-out cases after harness, skill, model or connector changes. Adapt the assistant to a second approved design context, recording integration, expert review and correction effort rather than assuming that it transfers.
Your systems, data, rules and accountable owners decide the real project. Agree acceptance criteria, escalation owners and operating responsibility with the people accountable for the work before anything runs on live records. Treat the first run as a rehearsal on test records: compare the draft output with an independently prepared answer, and record what the people reviewing it change.
Questions about this example
- What does the semiconductor company use AI for in verification?
- According to OpenAI's account, the work covers directed-test generation, debugging and architecture assistance for chip verification. Custom applications later moved onto shared Codex harnesses, plugins and skills, with connectors and evaluations adapted for additional teams. The customer is unnamed.
- Who reviews the AI's chip verification output?
- OpenAI reports that customer verification engineers worked with its engineers to define evaluations. The account does not say who reviews each generated test. A proposed check, not from OpenAI, would have domain engineers review generated tests and diagnoses before accepting any change.
- How strong is the evidence for this chip verification example?
- The evidence class is reported use: OpenAI reports production and early adoption across the unnamed customer's verification use cases, starting in 2025. The account is provider-reported, publishes no full evaluation data and offers no audited results. Reuse timelines are not promises for another enterprise.
- What would an enterprise need to build something similar?
- This is Nuvepro's proposed design, not what OpenAI or its customer did. It would use an approved design subset, specifications and seeded failures, restrict tool authority, have domain experts qualify expected behaviour independently of the agent, and verify adaptation to a second team.
Shape this around your enterprise
Bring a similar workflow and the people responsible for it. Together, define the records and systems to use, the result your team will build or configure, and how its owners will check it. Nuvepro scopes the simulation, environment and preparation. Agree any existing-agent evaluation, implementation assistance and production responsibilities separately.
Sources and limitations
Curation review: . This is the date this source example was reviewed, separate from source publication dates.
- The customer is unnamed and the account is provider-reported. It does not publish full evaluation data or independently audited business results. The 22 October publication describes earlier engagements; reported reuse and deployment timelines are not promises for another enterprise.
- OpenAI: What FDE means at OpenAISource publication: 2026-10-22
More software engineering examples
- AI energy model customization: Exowatt exampleExowatt
- AI content platform migration: Wimbledon exampleAll England Lawn Tennis and Croquet Club (Wimbledon)
- AI database migration: The New York Times exampleThe New York Times
- AI engineering agent coordination: Deel exampleDeel