“AI designs chips” is too broad a description to tell an engineer what a system can actually do. I prefer to ask which design decisions it owns, where it starts, and what it independently verifies.
The following L0–L5 framework is my working proposal for RFIC automation. It is not an industry standard, a ranking of specific products, or a claim that any one system has mastered all six levels.
The capability ladder
| Level | Capability | Design responsibility |
|---|---|---|
| L0 | Design assistance | Help with information and operations; a human supplies the consequential design decisions. |
| L1 | Circuit optimization | Improve parameters within an existing circuit architecture and evaluate the result. |
| L2 | Circuit synthesis | Create a circuit solution from requirements, including meaningful topology and device choices. |
| L3 | Physical optimization | Repair or improve an existing physical design, closing the relevant manufacturing and RF checks. |
| L4 | Physical synthesis | Create a complete physical implementation from an allowed starting specification and verify it. |
| L5 | Joint circuit–physical synthesis | Revise circuit and physical choices together, using physical feedback to make cross-layer trade-offs. |
The boundary between L2 and L3 is intentionally pronounced. A successful circuit-level workflow does not automatically possess the representations, tools, or feedback necessary for physical design.
Use one task to make the distinction concrete
Consider an amplifier. At L1, the system might tune an existing topology. At L2, it might select a different circuit structure. At L3, it starts with a layout and improves a matching region, routing, or return path. At L4, it constructs the physical implementation rather than receiving the finished geometry.
At L5, physical feedback can trigger a change in the active configuration or the circuit topology, not only an adjustment to the passive geometry. The defining feature is the coupled decision loop. It is not the number of optimization passes.
A level needs a scope
A label without a task domain is misleading. A system may support physical synthesis for a constrained passive family without supporting complete amplifier design. A result on one process stack does not establish portability across foundries.
I would therefore attach a compact evidence record to any level claim: the permitted starting assets, the supported task and process domain, the acceptance checks, human interventions, the success rate over stated attempts, and the time and simulation budget.
These details are not qualifications added to weaken the result. They are what make the result useful. An engineer needs to know whether the demonstrated ability applies to the next task.
Architecture does not assign the level
A reinforcement-learning optimizer, a language-model agent, and a deterministic program can all participate at different levels. An agent does not become L4 because it can call a layout tool. Likewise, an effective L1 method is not uninteresting merely because it is narrowly scoped.
The same agent environment should ideally support assistance, optimization, synthesis, and human collaboration. Higher autonomy is not always the appropriate operating mode. Sometimes the valuable contribution is a well-explained diagnosis or a carefully bounded revision to a human design.
Grade the result, not the presentation
I want this framework to make demonstrations more comparable and development priorities easier to discuss. It should direct attention toward missing responsibilities: perhaps the topology search is effective, but native editing is fragile; perhaps the geometry is valid, but the evaluated file is not the delivered one.
The right next step is the one that closes a meaningful gap. More agent roles, longer transcripts, and additional orchestration layers do not constitute a higher capability level on their own.
In this framework, the central unit of progress is an expanded design responsibility supported by reproducible evidence.
Ideas in progress. Corrections welcome.
Find me online