I was puzzled a bit, then realized they only handle schematics. Saying "PCB schematics" is weird.
A schematic is just a representation of a netlist, something where text is more than fine since the graphical form is only for human consumption. An LLM is actually a pretty good fit to cross-reference datasheets and netlists.
Would it be actual PCB layout I would be skeptical as LLMs are quite poor at anything spatial. For schematics however, it could work quite well as a double check.
Some anecdata: This weekend as a lark I asked Claude Code to design a (fairly simple) analog circuit and simulate it in LTSpice to verify. It did three edit-simulate-fix cycles and to my surprise ended up with something that seemed pretty sane.
That said, schematics (as opposed to netlists) don't seem to be a practical I/O format yet. It did generate a KiCad schematic file when asked, but it was pretty bad (penguin on a bicycle level).
Anyway, somehow there does seem to be some electronic tools training happening, becuase I tried this maybe a year ago and it was pretty hopeless.
This is exactly why the first version of our tool worked with netlists only. We've since evolved to parsing the full KiCad project and generating a netlist from it so we can also extract schematic-specific metadata that doesn't make it into the netlist (designer notes/annotations, component positions, etc.)
This looks great, but I want to know when LLMs will be useful for generating schematics rather than just checking them! It’s such a letdown right now to jump from doing firmware with Claude Code to drawing schematics manually like it’s 2022. :) When does KiCad get its little assistant pane on the right?
Schematic generation doesn’t really make sense to me because the cost of a problem going unnoticed is much more significant in hardware design than software.
Ive had that argument with many of the schematic PCB ai startups. Online open source schematics and PCB designs are awful training sets by large. There are some gems out there publicly but that's gems in a sea of sand. Far different than training a LLM on all the published books of the world.
You can throw Claude at a completely private Rust code base with very specific niche requirements and conventions that are not otherwise common in Rust and it will demonstrate a remarkably strong ability to explain it and program according to the local idioms. I think your statement is based on liking a popular language, not on evidence..
I find that having a code-base properly scaffolded really, really helps a model handle implementing new features or performing bug-fixes. There's this grey area between greenfield and established that I hit every time I try to take a new project to a more stable state. I'm still trying to sort out how to get through that grey area.
I had Claude nearly one-shot (well, sequence-of-oneshots) a fairly complex multi-language file pretty-printer, but only after giving it a very specific 150-line TODO file with examples of correct results, so I think pure greenfield is very achievable if you steer it well enough. I did have to really focus on writing the tasks to be such that there wasn't much room for going off the rails, thought about their ordering, etc; it was pretty far from vibecoding, produced a strict data-driven test suite, etc.
But ultimately, I agree with you, in most projects, having enough existing style, arranged in a fairly specific way, for Claude to imitate makes results a lot better. Or at least, until you get to that "good-looking codebase", you have to steer it a lot more explicitly, to the level of telling it what function signatures to use, what files to edit, etc.
Currently on another project, I've had Claude make ~10 development spikes on specific ~5 high-uncertainty features on separate branches, without ever telling it what the main project structure really is. Some of the spikes implement the same functionality with e.g. different libraries, as I'm exploring my options (ML inference as a library is still a shitshow). I think that approach has some whiff of "future of programming" to it. Previously I would have spent more effort studying the frameworks up front and committed to a choice harder, now it's "let's see if this is good enough".
I don’t see how this demonstrates that at all. Issues as a concept seems sound. There is a huge variety of social structures that are built around issues which might make it a good or bad fit
> you need the borrow checker guarantees to implement downstream compilation steps.
You don't technically. The borrow checker doesn't effect the semantics of the program (like, for example, type inference does) and the rest of the compiler doesn't need to (and in fact, doesn't) use its analysis to figure out how to compile the code.
The downstream compiler does assume that the code followed the rules for accessing references - i.e. didn't violating aliasing rules. The borrow checker guarantees this, but it's fundamentally a conservative check. It rejects programs it can't guarantee are correct, and rice's theorem proves that there are always correct programs that it can't guarantee are correct.
That said if you just treat rust-references like C-pointers you will run into issues. The aliasing rules for rust references are stricter. Also not fully agreed upon yet - the currently closest to accepted definition is in the "tree borrows" paper but it has yet to be adopted as the official one by the rust team.
The wealth inequality in the U.K. is very genratioanly skewed, mainly from the source of that wealth (housing and final salary pensions) which is no longer available to younger people.
Would you mind telling me if you are a genuine person who lived in the UK, or at least have some knowledge of the country beyond recent tweets?
Honestly I am shocked at the recent rise of anti-UK comments with horribly incorrect information or skewed views and curious about what is sourcing this.
The core issue is that most major businesses are ultimately owned directly or indirectly abroad, largely in America, with some tapping by London-based intermediaries.
Supermarkets and shopping centres, national assets (e.g., water) the story is the same. Then there's Amazon et al.
Profit generated in this country is by and large not spent here, and is certainly not taxed adequately.
This causes inequality by short-circuiting redistributive measures, either local economic multipliers or government spending.
What gains are felt are concentrated in service sectors which facilitate global capital, concentrated in London. See OP's thoughts on legalistic societies.
It compares to inequality in England before the US was a thing, in the same way. Small elite benefiting from global plunder, vast inequality internally.
The British Empire didn't actually end. There was a hostile takeover by Washington at the end of WW2.
reply