I have been using Cursor w/ Opus 4.x to do extensive embedded development work over the past six months in particular. My own take on this topic is that for all of the chatter about LLMs in software engineering, I think a lot of folks are missing the opportunity to pull back and talk about LLMs in the context of engineering writ large. [I'm not capitalizing engineering because I'm using the HN lens of product development, not building bridges or nuclear reactors.]
LLMs have been a critical tool not just in my application but in my circuit design, enclosure design (CAD, CNC) and I am the conductor where these three worlds meet. The degree to which LLMs can help with EE is extraordinary.
A few weeks ago I brought up a new IPS display panel that I've had custom made for my next product. It's a variant of the ST7789. I gave Opus 4.5 the registers and it produced wrapper functions that I could pass to LVGL in a few minutes, requiring three prompts.
This is just one of countless examples where I've basically stopped using libraries for anything that isn't LVGL, TinyUSB, compression or cryptography. The purpose built wrappers Opus can make are much smaller, often a bit faster, and perhaps most significantly not encumbered with the mental model of another developer's assumptions about how people should use their library. Instead of a kitchen sink API, I/we/it created concise functions that map 1:1 to what I need them to do.
Where I agree with the author of this post is that I feel like perhaps it's time for a lot of libraries to sunset. I don't think replacing frameworks is the correct abstraction at all but I do think that it no longer makes sense to spend time integrating libraries when what you really need are purpose-built functions that do exactly what you want instead of what some library author thought you should want.
It seems to me that a lot of the discussion stems around different definitions of the word framework and I believe library is probably the more appropriate term to use here. I wouldn't replace .net framework with something I vibe coded but your example of a library of not so specific functions is ripe for replacement. If you're only using 5% of a library you've probably written as much adapter code as you would have if it was just specific code to solve your problem.
I didn’t even give Claude (Opus 4.1) the registers when I did this for a recent ESP32 + ST7789 Rust project. I think I literally just said “make a driver with a double frame buffer for the ST7789 on SPI1, with DMA updates“. And it did it.
In my experience, often the libs provided by manufacturers are thin wrappers over physical interface setup and communication in the form of a single header and cpp file. Isnt it easier to just use them instead of generating differently phrased copies of them?
The vast majority of parts do not have libraries provided by a manufacturer.
Instead, you get a datasheet (if you're using a well-known part) that contains a list of registers which you need to either write functions against or hope someone on GitHub has done the work for you.
Some display modules do come with sample code that you can build (on a good day) to test things out, but these are almost always half-baked and feel more like HELLO WORLD than something you'd use as a cornerstone of your product development.
Other parts come with sample code that is explicitly designed to work with an expensive $200 "dev board" that you're supposed to use to generate the code you're intended to drop into your project. It's just my opinion, but I'd rather use an LLM for this and skip the dev board stage.
The reason libraries like Adafruit Graphics exist is precisely because the code that comes with the display panels they sell is usually less helpful than if it didn't exist.