AI-assisted software development is past the proof-of-concept stage. In the Stack Overflow Developer Survey 2025, 84% of developers said they use or plan to use AI tools at work, and 51% of professionals use them daily. Trust hasn’t caught up: in the same survey, only 3.1% said they highly trust the output, while 45.7% admitted they don’t.
At Cubit, we got here through an internal problem. On a hardware project, the useful information already exists – schematics, netlists, bill of materials, layout, design decisions – and a lot of people need it: firmware engineers, mechanical designers, purchasing and, these days, AI agents. In practice, most of it can only be read by whoever has a seat of the design tool. That bottleneck is what led to the PCB Viewer: an EDA viewer developed, documented and tested by a team of LLM agents, with one engineer setting requirements, constraints and acceptance criteria. The tool is now in daily use across the company.
Altium Designer projects, in the browser
The PCB Viewer is a web app that opens native Altium Designer projects – PcbDoc, SchDoc, PrjPcb, PcbLib – so you don’t need the design suite installed to look at a board. You load a project as an archive; the viewer detects the format and resolves the project parameters. From there you can walk the multi-layer layout in 2D, pad by pad and track by track, page through the schematics with nets highlighted, or inspect the board in 3D, rebuilt from the project’s STEP models. Around the rendering you get the tools you would actually use every day: component and net search, cross-probing between schematic and PCB, measurements, and detail panels for objects, layers and components.
The architecture keeps responsibilities separate: a Python backend handles rendering and services, and a .NET microservice parses the Altium Designer files, extracting geometry, schematics, project parameters and 3D models. Specialist features – connectivity, schematics, the 3D view – are add-ons sitting on a common core. The 3D scene is assembled server-side from STEP models converted to GLB, with a per-component fallback when a model is missing. We started with the ODB++ format and added Altium Designer support later. Operations follow product discipline too, with separate staging and production environments. The driver was the internal need above: letting people analyse, debug and document electronics projects outside the design office.
Costing a bill of materials across suppliers
The part that pays for itself is the costing module. For every component, the system compares offers from multiple suppliers – unit price, minimum order quantity, order multiples, price breaks and, where they bite, packaging constraints – and puts the real first-order cost next to the theoretical cost computed from BOM quantities. On the board shown in the screenshots, the BOM has 69 components, pricing was found for 97% of them, and you can read the gap between the two costs line by line.
This is the kind of feature that separates an engineering tool from a demo. The value is in the semantics of the calculation: the MOQ that does or doesn’t kick in, the packaging that makes you buy more parts than you need, the price break that applies to the quantity you actually order. If you stop at the theoretical cost at quoting time, you never see that gap. The module’s spec – and its tests – were written around these rules.
An API that makes hardware readable to AI agents
The feature with the biggest impact on day-to-day work is the least flashy one. The backend exposes designs and netlists through an API, which makes a technical asset that already lives in the Altium Designer project – in a format built for the people who draw the board – queryable by software. Connections, pinouts, which components sit on which bus: once that is available in structured form, our AI agents can generate and verify firmware code against a trusted reference, with a level of context that used to take manual copy-and-paste to assemble. On the BOM side, a language model handles the semantic matching of components.
The API is what turns the viewer from a reading tool into a platform for design data, and it bridges the disciplines: firmware engineers check layout, schematics and netlists; mechanical and thermal people use the 3D view; purchasing lives in the BOM; the agents come in through the API. Engineers still make the decisions; what goes away is the transcription work, and the class of errors that comes with it.
How we organised the development
If you want to repeat the experience, the method matters more than the product: it’s the part that transfers. The work started before the platform itself, with a shared knowledge system – atomic memory plus RAG, accessible to every agent, under a company-wide versioning policy. Development was then done by LLM agents coordinated by a single engineer, who owned requirements, constraints and acceptance criteria, working test-driven: tests are derived from the acceptance criteria and written before the code, and agents work on both development and review, under supervision.
For the costing module, the data contract was written and frozen before any parallel work started: a binding spec that no workstream could reinterpret. Each agent worked in its own copy of the code, on files that didn’t overlap with anyone else’s, in small, verifiable changes. The coordinator re-ran the integration checks and opened the merge request only when the acceptance criteria passed.
Around the project we kept the rules of any well-run software job: every task gets an issue and a branch, no agent merges to main on its own, every agent has a recognisable identity in version control, and nothing counts as done without a concrete, documented check. Priorities, architecture calls and the final merge stay with humans.
The same rules would apply to a team of people working in parallel on one codebase; with agents, we applied them to the letter. Inside these boundaries, AI multiplies an engineer’s execution capacity, and every step stays auditable.
Anthropic’s multi-agent research system
The coordinator-plus-specialists pattern is well documented outside Cubit too. Anthropic describes it for its own multi-agent research system: in internal evaluations it reports a 90.2% improvement over a single agent, at roughly fifteen times the token spend of a normal conversation. Those are numbers from one specific case, and the costs need to be weighed project by project. What does transfer is the control structure: separating who coordinates from who executes, with explicit contracts in between, makes the result verifiable instead of merely plausible – the same reason engineering contracts keep the spec writer, the builder and the tester separate.
Validate first, then talk
The PCB Viewer remains an internal tool, and we only told this story once the platform was in real use. What Cubit offers clients is the method, and the competencies the project demonstrates: hardware-software integration, agentic development, and turning a company’s technical knowledge into a working asset. We stress-tested these technologies on our own problem, with our own data and our own costs, before making them a proposal.
What separates an AI-agent development process from a one-off experiment is structure: requirements and acceptance criteria written up front, boundaries and contracts along the way, independent verification at the end. We validate competencies first, and talk about them after.
