__atx__

Indeed. I remember taking a machine learning course as an undergrad in 2018 and scratching my head how could systems like these possibly scale to meaningfully interacting with computers let alone the real world. Well, here we are :)

Yes sure, but it's a bit of a whack-a-mole right:

Nothing: Opus plops down everything into one big schematic sheet

"Use hierarchical sheets!": Opus uses them but does not realize they can be multi-instanced

"...":

It would probably be well worth to optimize this on synthetic projects, but realistically we are small shop, our required PCB-design output is not that masive, and I expect Opus 5.8 to just do the correct thing automatically as its being RLHFed on these tasks as we speak :)

We have developed something similar inhouse (a CLI tool for agents that has a few dozen utilities for manipulating KiCad files) and the results are pretty good. In terms of complexity, I would say that tasks like "replicate the layout from the datasheet of this amplifier and make me a testboard" or "look, we need an adapter that goes from <this devkit (insert PDF schematic)> to <these boards (insert KiCad file)>" are basically solved. More dense layouts are a stretch at the moment. (speaking about Opus 5.5 specifically here, other models are likely worse at these visual-coding tasks anyway)

In terms of result quality, I would say that the results are distinctly "2024/2025 LLM programming quality". The models lack a certain... taste? Good and careful prompting can help, but for example "use hierarchical sheets" can yield a single hierarchical sheet containing 3 copies of the same thing instead of three instances of a hierarchical sheet containing the same thing once. When pointed out, the model can of course do it no problem the way you want.

Nice work! I have been messing with doing some radio DSP on the NPU in my laptop and found the Intel graph compiler to be rather unpredictable. Weird random mis-lowering to fp16 ops instead of int8, unpredictable throughput depending on tensor sizes, reshapes being sometimes extremely expensive and sometimes basically free etc.

Obviously I am mostly just driving the DPU, as the SHAVE cores are just not beefy enough, but maybe this will be useful at some point, at least to gain more insight into the architecture...

I checked and the solution is unique (at least within some reasonable bounds in terms of runtime etc, it's possible there is a 1000 bits long special solution hidden somewhere, but due to the relatively small amount of flops I doubt it).

> Circuit extraction can be done with magic.

So that was the missing part for me! I did it from scratch (with custom Python script with gdstk and shapely) (the GDS file does have the cells annotated, so not a big problem but still). I was thinking about scripting the "trace net" tool in klayout but decided that's going to probably bring its own can of worms...

I find this a rather interesting quirk of linguistics. In many languages, nouns have a "grammatical gender". For example, in Czech, "inteligence" has a feminine grammatical gender, so you are supposed to use feminine pronouns when refering to it. This sometimes leaks through with ESL people. I wonder if speakers of these languages anthropomorphize AI (or even animals or non-living objects!) more than native english speakers...

Also worth noting that the exploit was published nearly decade ago. Still, even at that time, those VIA CPUs were over 15 years old.

The "gaming" take is a strange one indeed for an ARM platform. Hopefully they (Microsoft or Nvidia?) put some real effort into the translation layer. They claim modern AAA games, but it is possible they strongarmed the developers to make them an ARM build for a few select titles...

> I'll also remove the end cap to avoid it blocking the mug's descent.

Ah yes, that matches my observations. It kinda sees that the stuff it is looking for is there, but does not see enough detail to actually notice that not only there is an endcap in the way, but the mug is also rotated the wrong way to sit in the holder.

It feels like the "r's in strawberry" effect where the models do not have enough introspection into the raw input data.

Apparently it took multiple tries to get this right. It is possible that the video is from one of the earlier failed attempts.

These days, running `/usage` in Claude Code shows you how close you are to the session and weekly limits. Also available in the web interface settings under "Usage".

I do wonder in particular about the startup time "time-to-plot" issue. I last used Julia about 2021-ish to develop some signal processing code, and restarting the entire application could have easily taken tens of seconds. Both static precompilation and hot reloading were in early development and did not really work well at the time.