Analog Design in the Age of AI - the Missing Semantic Representation
1. Powerful AI Agents That Can’t Speak Circuit
We witnessed a leap in the capabilities of AI agents in 2025.
LLM-backed software development has evolved far beyond generating isolated code snippets. Today’s agents can see entire codebases. They don’t just write code, they run it, debug it, refactor it, review it, and manage version control. In practice, this routinely translates into an order-of-magnitude productivity gain.
I’ve experienced this firsthand. Using tools like Cursor, Claude Code, and Codex CLI almost daily, I feel like a fundamentally different engineer than I was a few years ago. Projects that once felt prohibitively large or complex now feel tractable. Software development has crossed a qualitative threshold.
Yet analog circuit design, the field and craft I love, remains almost completely opaque to these same AI tools.
I have repeatedly tried to ask AI models meaningful circuit questions. They know the textbooks well. They can reason through idealized thought experiments. They can even point me to relevant papers. But the moment I want to say something simple and concrete:
“Here’s my circuit. Let’s figure out how it works.”
the interaction breaks down.
What, exactly, should I give the agent as context?
Figure 1. The analog design representation gap.
I tried schematic screenshots. Most models struggle to reliably recover even basic connectivity. I tried raw netlists. Surprisingly, AI can often parse and reason over them — but I can barely recognize the circuit structure myself, let alone author or edit a design in that form.
At that point, the problem becomes obvious. We are missing something fundamental.
Schematics are excellent for human visual reasoning, but hostile to machines.
Netlists are excellent for machines, but hostile to human authoring and structural reasoning.
There is no shared representation that both humans and AI agents can fluently read, write, edit, and reason about. What’s missing is not intelligence, but language: a semantic representation of analog circuits that captures structure and intent without being tied to either drawings or simulator-specific syntax.
This missing layer is the real bottleneck and AI has simply made it impossible to ignore.
2. Netlists: The Wrong Layer to Speak At
At first glance, the answer seems obvious.
We already have a plain-text representation of analog circuits: the netlist.
Netlists are the de facto standard handoff format across the entire analog design toolchain. They connect schematic editors, simulators, LVS and extraction tools. They are simple, efficient, deterministic, and machine-friendly. In principle, they are complete and unambiguous. If we want a textual representation that AI can read, why not just use the netlist as-is?
The problem is that netlists were never designed to be authored or reasoned about by humans.
Historically, the netlist is an input format for circuit simulators. Its syntax is optimized for fast parsing and deterministic execution, not for expressing structure or intent. As a result, netlists are tightly coupled to specific simulators, each with its own dialect and extensions. There is no neutral, agreed-upon standard. A representation meant to serve as a common language should not be vendor-specific.
More importantly, the netlist exposes several fundamental limitations as an authoring surface.
Lack of support for arrays and patterns.
Arrays of devices and repeated structures are everywhere in analog design: differential pairs, current mirrors, capacitor banks, resistor ladders. Netlists do not represent these abstractions directly. Instead, they fully elaborate and flatten everything into individual instances and nets. This is a strong signal that netlists are compiled artifacts, not sources of truth. Once flattened, structural intent is erased.
Implicit positional bindings.
Connectivity in netlists is often defined positionally rather than by name. Consider a simple MOSFET instance:
M1 net1 net2 vss vss nmos L=0.5u W=5u NF=4 M=1Without memorizing the default pin order (D, G, S, B), it is impossible to know what this device is actually doing. This becomes far more fragile with large subcircuits. A single missing or misordered port silently corrupts the entire connectivity. Ironically, parameters are easy to reason about precisely because they are named.
Implicit and fragmented nets.
Netlists serialize instances first and infer nets indirectly from their usage. For simulators, this is perfectly fine. For humans, it is cognitively expensive. Analog reasoning revolves around signals—node voltages and branch currents—yet nets are never first-class entities. Tracing a signal means mentally chasing symbols across many disconnected lines of text.
Taken together, these properties reveal what netlists really are: a low-level execution format. They are excellent for machines and terrible as a shared language for authoring, refactoring, and reasoning.
In other words, netlists are the wrong layer to speak at. They are already downstream of the abstraction we are missing.
3. The Paradox of Schematics
Schematics are the bread and butter of analog design.
We sketch them on napkins and whiteboards. We draw them in EDA tools, then redraw them again for documentation and presentations. With a single glance at a schematic, an experienced designer can recognize a differential pair, a current mirror, or a folded cascode. We reason about node voltages and branch currents visually and intuitively. Nearly all analog knowledge, from textbooks and papers to lectures and design reviews, is communicated through schematics.
Schematics are deeply engraved in how we think.
At the same time, schematics are an extraordinarily slow and friction-heavy method of design capture. We author circuits by manually drawing wire segments and placing symbols one instance at a time. This cost is paid not just during initial creation, but repeatedly during iteration. Real analog design is an iterative refinement process. Devices are resized, topologies are tweaked, biasing strategies are reworked, and control signals propagate through multiple layers of hierarchy. Editing and refactoring often dominate the total effort.
For hierarchical designs, the burden is even heavier. Schematics and symbols must be maintained as separate but consistent representations. Port definitions must match exactly, yet this consistency is largely enforced by discipline rather than tooling. Any designer who has added a new control signal deep in a hierarchy knows the pain. Symbols must be updated, ports propagated upward, and connections manually verified at every level. These tasks are mechanical, repetitive, and error-prone, yet they receive little automation support.
The friction becomes most apparent when we try to involve AI.
Schematics are stored either in proprietary binary databases, such as Cadence Virtuoso, or in ad hoc plaintext formats, such as Xschem or LTspice. Even when these formats are technically readable, they are dominated by drawing primitives rather than semantic structure. Asking an AI model to understand a schematic effectively means asking it to infer intent from geometry. At best, this is a one-way and lossy process. Without the ability to reliably edit and regenerate the design, the usefulness of such understanding is limited.
Despite all this, analog designers strongly resist replacing schematics with a purely textual hardware description language, and for good reason. Schematics are not just an input method. They are a cognitive tool. If we cannot see the circuit, we will redraw it elsewhere. The visual representation is not optional.
This leads to a fundamental paradox.
Schematics are indispensable, yet insufficient as a representation.
They are indispensable for human reasoning, but insufficient as a scalable, editable, machine-friendly source of truth.
4. The Overloaded Responsibilities of Schematics
The paradox of schematics comes from asking a single representation to do too many different jobs.
Today, schematics simultaneously serve as:
- a visualization for analog reasoning
- the source of truth for circuit connectivity
- an authoring and editing surface
These roles are related, but they are not the same. Collapsing them into a single artifact creates unnecessary friction.
A simple thought experiment makes this clear. Suppose we tidy up a schematic by rerouting a wire or moving symbols to improve readability. Electrically, the circuit is unchanged. Yet the schematic file itself has changed. This reveals a seam in the representation. Some parts of the schematic encode electrical meaning, while others encode only presentation.
Devices and their electrical topology are core invariants of a circuit.
Symbol placement, wire routing, and visual layout are not.
Once we recognize this distinction, the paradox dissolves. Schematics are not flawed. They are simply overloaded. They are being used both as a semantic description of a circuit and as a visual projection of that description.
A useful analogy comes from document authoring. Word documents mix content and presentation into a single format. This makes them convenient for direct editing, but awkward for automation, version control, and large-scale refactoring. Markdown, by contrast, separates content from presentation. It is not inherently better for writing, but it is far better as a shared, machine-readable source of truth from which many views can be generated.
Schematics today resemble Word documents. They combine electrical intent and visual presentation into a single artifact. What analog design lacks is the equivalent of Markdown: a representation that captures circuit structure and intent without committing to a particular visual form.
With such a representation, the schematic becomes what it should have been all along. It is no longer the source of truth. It is a projection.
The mental model becomes straightforward:
A semantic representation defines the electrical topology and design intent.
Schematics are generated views for human reasoning.
Netlists are compiled views for simulators and tools.
Once these responsibilities are separated, each layer can be optimized independently, and the original paradox disappears.
5. Documentation: Comments With Nowhere to Live
High-quality circuit designs are inseparable from high-quality documentation.
In software engineering, this is taken for granted. Documentation lives alongside the code. Comments, docstrings, and structured annotations are first-class citizens. Modern tooling can extract them, render them into searchable websites, and keep them in sync with the implementation. When the code changes, the documentation changes with it, or at least fails loudly.
Analog design is far behind in this regard.
Most design intent in analog circuits lives in fragile and informal places. We write notes directly on schematics: “match these devices with symmetric layout,” “critical net, minimize parasitic capacitance,” “keep IR drop below 5 mV.” These annotations are attached by geometric proximity rather than semantic meaning. They float near wires and symbols, hoping the reader infers what they apply to.
As soon as the design is netlisted, these notes disappear.
Netlists technically support comments, but in practice they are dominated by auto-generated metadata such as timestamps and tool versions. The original design intent is gone. What remains is a circuit that can be simulated, but not easily understood.
To compensate, we create slide decks for design reviews. We explain constraints verbally in meetings. We rely on tribal knowledge when handing designs to layout engineers, or when we do the layout ourselves. When IPs are reused across projects or ported to new technologies, much of the original reasoning is lost. Understanding why certain decisions were made often requires digging through old review slides or email threads, if they still exist.
This is not a documentation problem. It is a representation problem.
Schematics have no stable semantic entities to attach documentation to. Notes are bound to geometry, not to devices, nets, ports, or subcircuits as explicit concepts. As a result, documentation cannot survive transformations such as netlisting, refactoring, or hierarchy changes.
A semantic representation changes this fundamentally.
If devices, instances, nets, ports, and subcircuits are explicit entities in the representation, they become natural anchors for documentation and design intent. Constraints, layout guidance, assumptions, and rationale can be attached directly to what they refer to. Documentation becomes part of the design itself, not an external artifact that inevitably drifts.
Once documentation is embedded at the semantic level, it can flow downstream. It can be rendered into schematics, carried into netlists, surfaced in IDEs, or compiled into design reports. Design intent stops being something we explain repeatedly and starts being something the system remembers.
This is another role that schematics were never designed to carry alone, and another reason a dedicated semantic layer is unavoidable.
6. A Forward Look
Taken together, the picture is clear.
Analog design today lacks a representation that both humans and machines can work with fluently. Netlists operate too far downstream, after structure and intent have already been erased. Schematics remain indispensable for human reasoning, but they are overloaded with responsibilities they were never designed to carry. Documentation, constraints, and design rationale have no stable place to live.
This is not a tooling gap, and it is not a limitation of AI models. It is a representational gap.
What is missing is a text-first semantic representation of analog circuits. One that makes electrical topology explicit. One that preserves hierarchy, patterns, and intent. One that can be authored, inspected, refactored, and version-controlled directly. One that can serve as a stable source of truth, from which schematics, netlists, documentation, and analyses can all be derived.
Such a representation does not replace schematics. It makes them sustainable.
Once this layer exists, AI agents gain something they have never had in analog design: a language they can actually speak. Designers gain something just as important: a representation that matches how circuits evolve over time, not just how they are drawn at a moment.
In the next post, we will step back and ask a more fundamental question. If we were to design this missing representation from first principles, what properties would it need to have? What should it make explicit, what should it abstract, and what should it deliberately avoid?
That question is where the real work begins.