# astrimid - Generic intent component.This is e...

Channel: #contributor
Source: https://discord.com/channels/1233487248129921135/1529185540224847972
Started: 2026-07-21T17:57:24.133000+00:00
Last activity: 2026-07-21T18:44:23.607000+00:00

## astrimid — 2026-07-21T17:57:23.683000+00:00

Generic intent component.

This is extracted from the AI-assisted bug reporting thread. It serves several goals.

Currently, topological, electrical, mechanical, schematic, physical, etc domains are not explicitly tagged. So you don't know the difference between `<net connectsTo` and `<trace from to`, as both define a conceptual connectivity constraint.

There's no way to specify a generic model if you don't know a comprehensive list of all tscircuit features and component/props API. So when AI hallucinates, it tries to use something like `<nonexisting_element nonexisting_prop="desired_value">`. We need an escape hatch for AI to define things it doesn't know how to map becuase specification doesn't have it.

Another point is that tscircuit doesn't have a high-level intent components. You could define both schematic and pcb implementations of a concept, but there's no way to validate that schematic and pcb are both valid, even if you use LLM.

Example:
```
// TODO: This trace needs to be 90Ω impedance for USB 2.0
<trace from="J1.D+" to="U1.DP" />
```
Currently, `<differentialpair` exists, but pretend it didn't (previous versions). AI would hallucinate some nonexisting element and user would be confused while AI would gaslight them.

What I propose is some way to capture that TODO comment using general purpose `<intent> primitive. It could define topology (what connects to what), electrical connectivity (what the impedance or max resistance should be), mechanical/physical constraints (e.g. cutouts, footprint, 3D). It feels like circuitjson, but higher-level.

It is similar to subscircuit or group as it's a collection of domain properties, and interfaces, but it's more freeform.

The key difference it never fails. If there's no tscircuit element that defines the intent, it just works

## Seve — 2026-07-21T18:02:48.600000+00:00

i just want to re-iterate that we WILL/DO have high level intent, we just do not make it generic

## Seve — 2026-07-21T18:03:58.398000+00:00

if there is intent in code that is not used by the compiler, then that is typically stored as a comment, not an element

## Seve — 2026-07-21T18:04:27.065000+00:00

if we adopted this approach, AI would start to use <intent /> even as we introduced new elements

## astrimid — 2026-07-21T18:08:09.519000+00:00

How about making it a comment annotation?

```
/** @intent type="differential_pair" impedance="90Ω" targets={["J1.D+", "U1.DP"]} */
```

## Seve — 2026-07-21T18:10:51.579000+00:00

that's fine but it's outside of our framework scope- that could be a framework on top of tscircuit for example

## Seve — 2026-07-21T18:11:42.178000+00:00

because our philosophy is to define (strictly/well-typed) the intent specification and it's translation into circuit json

## astrimid — 2026-07-21T18:11:45.939000+00:00

The problem this solves is that currently, when AI generates some hallucinated code or reading existing implementation, we don't actually know what was the design intent. We see a couple of resistors and capacitrors, but we don't know whether it is voltage divider or a filter or both

## Seve — 2026-07-21T18:12:29.437000+00:00

comments are great for that but also we support things like <resistor pullupTo pullupFor /> etc. We would continue to add specific ways to indicate intent

## Seve — 2026-07-21T18:12:41.404000+00:00

also in general components names like <BoostConverter /> provide strong hints

## Seve — 2026-07-21T18:13:24.767000+00:00

it is also possible to enforce constraints via explicit <drccheck /> and <analog.simulationcheck /> elements (work here is ongoing)

## Seve — 2026-07-21T18:13:48.986000+00:00

so if you have characteristics that must be maintained, that is also specified and checked when the circuit is built

## astrimid — 2026-07-21T18:26:59.945000+00:00

The problem I constantly hit, is there's no escape hatch for stuff that is not supported. So if tscircuit doesn't support something, there's no workaround using low level stuff. I can describe in English what I want to do, but no way to draw schematic nets or PCB traces or add components to BOM or implement the circuit inside the chip.

This makes tscircuit unsuitable for general purpose CAD use case. So you can't conceptualy built upon tscricuit because it doesn't always provide low level primitives, even if circuitjson supports them.

## Seve — 2026-07-21T18:28:43.637000+00:00

i agree with what you're saying that that is a wall for users- and that is our fault if we don't have something supported in TSX, but we have to extend our specification rather than create generics because AI will prefer to use generics due to the way it is trained

## astrimid — 2026-07-21T18:40:45.331000+00:00

In my experience, AI prefers the most efficient representation. So if generic is most efficient way to describe intent why would a concrete specification even exist? If I could generate an SVG that would represent PCB or schematic using less number of tokens, why would I use tscircuit?

## astrimid — 2026-07-21T18:41:38.095000+00:00

if I could represent a PNG using less data, why would SVG exist?

## Seve — 2026-07-21T18:44:01.077000+00:00

generic is always less efficient, the higher level and more specific the representation, the less tokens needed to represent it

## Seve — 2026-07-21T18:44:23.607000+00:00

<connector standard="usb" /> carries with it effectively hundreds of lines of other elements