From Natural Language to a Real Circuit Board: The Pipeline

A prompt is the start of requirements capture

“Build a battery-powered air-quality sensor” is an idea, not a circuit specification. It omits battery chemistry, charging policy, radio, sensing range, operating temperature, enclosure, lifetime, interfaces, safety limits, production quantity, and cost target. A system that immediately draws a schematic must invent those decisions.

The first pipeline stage converts prose into a requirements document with unresolved questions. Use machine-readable fields where possible:

product: "desk CO2 monitor"
power:
  input: "USB-C, 5 V sink only"
  max_input_current_mA: 500
outputs:
  - "3.3 V MCU and sensor rail"
interfaces:
  - "I2C sensor"
  - "USB 2.0 device"
  - "SWD programming pads"
mechanical:
  max_board_mm: [60, 40]
  connector_edges: {usb: "south"}
environment:
  operating_C: [0, 40]
manufacturing:
  layers: 2
  assembly: "top-side SMT, hand-fit display connector"
open_questions:
  - "Which exact sensor measurement range?"
  - "Does USB carry data or power only?"

The pipeline pauses for answers that change architecture. This is the disciplined version of vibecoding hardware: natural language remains convenient, while ambiguity becomes visible.

Convert requirements into verifiable blocks

Break the product into interfaces with explicit limits:

USB-C receptacle → protection → 5 V input
5 V input → 3.3 V regulator → MCU/module + sensor
MCU/module ↔ I2C sensor
MCU/module ↔ programming/debug pads

For each arrow, record voltage range, maximum current, direction, signal levels, speed, fault behavior, and connector pinout. Define acceptance tests at the same time. For example, the 3.3 V rail must stay within its permitted tolerance from minimum to maximum load, and the USB input must not exceed the declared current.

This block contract is a useful intermediate representation. An agent can reason over it, a reviewer can challenge it, and later schematic nets can trace back to it.

Select exact parts with evidence

Part selection combines electrical fit, package, lifecycle, availability, assembly support, and layout burden. The output should be a decision record, not a product-search list:

Function: 3.3 V regulator
Selected MPN: [complete orderable number]
Input/output/current fit: [values and margins]
Required externals: [exact values/specifications]
Package drawing: [manufacturer code]
Lifecycle/stock checked: [timestamp and sources]
Layout constraints: [critical loop and thermal notes]
Alternates: [qualified exact MPNs or none]
Evidence: [manufacturer datasheet revision/pages]

The model may gather candidates, but a component is accepted only when primary documentation supports every mandatory requirement. Package and pin mappings need independent verification. Distributor stock is rechecked at release.

Generate a connected design, not a picture

The next stage produces editable EDA source: a KiCad schematic, a code-native circuit description, or both. A PNG of a schematic has no reliable connectivity. A Gerber-only result arrives too late for electrical review.

Text-based circuit source can make generation, reuse, and diff review easier; code-native EDA covers the available approaches and tradeoffs. A graphical KiCad schematic remains valuable as a human review document. Whichever representation is primary, define one direction of generation so edits do not silently diverge.

The schematic stage must include:

• exact MPN and footprint fields;
• all power pins and exposed pads;
• no-connect decisions;
• decoupling and application components;
• net names that preserve interface intent;
• test points and programming access;
• notes for non-obvious limits or population options.

Run ERC, but do not mistake it for circuit validation. ERC evaluates symbol electrical types and connectivity. It does not know whether a generated symbol copied the wrong package pinout.

Translate design intent into physical constraints

Before placement, compile an explicit layout contract:

• board outline, mounting holes, connector locations, and height zones;
• stackup and fabrication capability profile;
• net classes, clearances, widths, and via presets;
• controlled-impedance and differential-pair targets;
• current-loop and decoupling placement constraints;
• antenna, switch-node, high-voltage, thermal, and mechanical keepouts;
• assembly-side and test-access rules.

Automation can then place and route against something measurable. A result that merely connects every ratsnest line is incomplete. Review return-current continuity, power delivery, heat spreading, component orientation, access, and enclosure fit.

Use 3D models for collision screening, but validate their dimensions and origins against package drawings. A wrong 3D model creates false confidence.

Run deterministic verification on saved artifacts

Run checks in a clean environment, independently of the agent session:

mkdir -p build/checks

kicad-cli sch erc \
  --severity-error --severity-warning \
  --exit-code-violations \
  -o build/checks/erc.rpt \
  design.kicad_sch

kicad-cli pcb drc \
  --schematic-parity \
  --severity-error --severity-warning \
  --exit-code-violations \
  -o build/checks/drc.rpt \
  design.kicad_pcb

The headless KiCad automation guide shows how to make these checks repeatable in CI. Add project-specific tests: exact MPN fields present, BOM/CPL reference sets equal, no unapproved DNP changes, required test points present, and output origins consistent.

Have a second reviewer check source documents, symbol/footprint mapping, critical circuits, and layout. Automated checks and human review cover different failure modes.

Build one versioned manufacturing bundle

After approval, generate Gerbers, drill files, BOM, placement data, fabrication/assembly drawings, and optionally STEP from the checked source commit. Clear the output directory first so stale layers cannot survive. Inspect Gerbers and drills in a viewer, then inspect the assembler’s placement preview.

Record tool versions, source commit, requirements revision, output hashes, waivers, and sign-off. “Released” should refer to one immutable bundle, not whatever files happen to be in a desktop folder. The meaning of release for manufacturing is control of this boundary.

If a requirement changes after approval, create a new candidate revision and run the pipeline again. Never overwrite the released archive or swap one file inside it; a mixed bundle can no longer be reproduced or audited.

Close the loop with physical evidence

Bring up the first boards with a current-limited supply. Inspect for shorts before fitting or powering expensive modules when the assembly plan permits. Measure rails and reset/boot states, program a minimal test image, exercise every interface, and record thermal behavior at worst-case load.

Map each result back to the acceptance criteria written at the beginning. Failures become requirements, circuit, library, layout, manufacturing, or test issues—not vague “AI mistakes.” Feed verified corrections into reusable modules and regression tests.

The pipeline succeeds when natural language controls intent while deterministic artifacts control execution. A shorter prompt cannot replace the stages; a better system makes them faster, traceable, and difficult to skip.