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.
This is fun. I didn't grow up playing RCT but I get the gist. I am a bit confused about two main things: how do you rotate a tile, and what's the relationship between the park entrance and the border tile where the customers enter?
I truly do not understand the appeal of proto board. Certainly tastes are individual and like any skill worth practicing, you do get better at it... but it's just such a miserable way to work. IMO, again.
Not only can you now order a real PCB for under $10, but somewhere along the way I realized that I could just buy extremely large pre-cut wire kits and treat them as the consumables that they truly are.
I'd rather go back to wire-wrapping. Every time I think "this is a great opportunity to use up a proto board!" I end up covered in flux goo and wondering what on earth I was thinking.
The real problem with proto board is what happens when you inevitably need to change your circuit. Again, it's miserable and suddenly your perceived speed gains are simply gone.
I think that the most exciting thing in prototyping right now is Stephen Hawes experiments with a) creating a PCB with premade vias that can be used to prototype anything and b) using a fiber laser to make your own PCBs.
Yes, wire-wrapping is/was so great. Really good quality connections, no accidental connections due to solder ending up at the wrong places, easy to remove or change.
And no solder-iron that risks burning stuff. And no smoke either.
The only draw-back is that it seems to be so expensive and almost non-existant today.
Burning stuff isn't a problem when soldering. It sounds like you need a little equipment upgrade. Get a holder for your soldering iron, and a fume extractor (filtered fan).
I wasn't mainly thinking about the actual soldering process, although that can also be an issue with small components or when not focusing on where the iron touches while reading a schwematic. But more like when the solder iron is stuffed back in the holder and something else gets pushed against it or when I get stuck in the solder iron's power cable and the solder iron is pulled out of its holder. I guess with more space, less junk on the table and the power cable fixed somewhere would help, but still, it's an annoyance.
I would prefer holding a wire-wrapping pistol than an iron.
> I truly do not understand the appeal of proto board.
I didn't understand your comment until I looked at the pictures in the article. To me "proto board" has always meant wire-wrapping. I lost count of how many of my designs back in the dark ages started as wire-wrapped protoboards. CPU cards, drive controllers, memory cards, motor drivers, keypads, I/O cards and myriad other projects.
In fact, I still have my OK Industries wire-wrapping gun[0]. I still have pins, sockets, boards, wire, etc. I probably reach for them once every couple of years these days. On those rare occasions when it's the middle of the night or a weekend and I have to wire-up a small board (nothing substantial). It's fast and works well for the right kind of project.
The problem with wire-wrap (and breadboards) is that, once clock frequencies (or frequencies in general in analog designs) rise the capacitive and inductive effects quickly conspire against you and make it impossible to build circuits that work. This is where the OP's approach can provide a bit of a bridge between a full PCB and wire-wrap/breadboard. I have done hand-wired (just like the article) boards with twisted pairs and carefully routed point-to-point connections. I never used magnet wire, just kynar or teflon wire-wrap wire.
[0] Mine is exactly like the one in figure 4 in this article. It works with spools of wire and auto-strips as you wire a board. It is very fast. Not sure why the article shows pre-stripped wire, the tool does the work for you auto-magically. I didn't read the article, maybe they are using a bit that does not strip (why?).
I'm just surprised that my blog post from almost 6 years ago suddenly made it to the HN front page...
That said: only when I need it the same day and it's not too complicated will I use protoboard. Otherwise it's JLCPCB every time, even if it's just a small debug interface board. I recently bought a cheap wire-wrapping tool and that's so much faster than messing around with enamel wire.
The board that is featured in this blog post was the first prototype of a skunkworks design for work that was on the shelves of Best Buy 7 months later. It was started just a week or two before COVID shutdown. I created PCBs soon after. Another month or 2 later and you'd have had a really hard time getting any PCB out of JLCPCB due to the supply chain disruption.
While I agree with you about protoboards (especially the non-strip kind, which seem to be the predominant ones nowadays), I feel like, for anything but the most trivial circuit, drawing the schematic in CAD, picking footprints, laying out a board, doing paper printouts for verification and sending it off to a manufacturer is easily a full working day or more. It also runs the risk of scope creep -- your quick and dirty prototype suddenly turns into "a product" and you start thinking about form factor and enclosures and extra features.
And over a week later when your minimum order quantity arrives, you discover your mistake and can add five more boards to the junk pile...
UV laser exposure feels like the correct way to go about doing small scale prototyping imho.
Yeah! What is the deal with the shift to non-strip protoboards? If you're going to work like that, why on earth wouldn't you want to at least start with the assumption that you're going to need to connect things?
The thing that really gets me is when I see designs on non-strip protos that involve the creator drawing a bead of solder across multiple holes to form a really unreliable wire. It's like they spent time using red stone in Minecraft and brought that instinct to electronics.
As for your larger point... I hear you - especially on the scope creep. However, it's distinctly possible that there's a realistic minimum time commitment to certain things we want to accomplish in life that are worth doing. If I have an idea for a little amp circuit or something, maybe the right thing to do is to make my best effort in KiCAD, spend that afternoon, measure everything twice... then not think about it for a week. Maybe that's when you jump into Fusion and whip up that quick enclosure.
Maybe the antidote to "slop" is that anything worth doing is worth that bit of attention. A product for one customer.
Otherwise, the solution is likely still the trusty and small drama solderless breadboard.
If you want to play around now and with little preparation, there's no beating proto-boards. No toying around with designing the PCB, no waiting for the order. They're also great to practice your soldering skills.
Sometimes you just want a sandwich, not to bake bread
Depending on the complexity/situation/mood/need for permanence I use some combination of double-headed (male) jumper wire and pre-cut breadboard wires. I buy my jumper wire as tear-off ribbons because sometimes I need 14 in a row for a GPIO bank or similar.
Jumper wires are the fastest and easiest to work with, but as complexity grows things quickly get out of hand visually and spatially.
Pre-cut wires are great, though I have some hot takes. First, for a long time I would carefully remove them from previous projects for reuse. I now believe that this is objectively bad because they grow brittle and become harder to re-insert. Instead, think of them like sandpaper, which has an obvious point of diminishing return. Throw them away as you use them up and order more when you're running low.
My main beef with pre-cut wires is that for reasons that anger me every time I think about it, they all come in lengths that increment by one 2.54mm unit up until about 10 lengths, at which point they start jumping to arbitrary lengths. So you end up either a) using two wires to cover a distance or b) with an overly long wire that you need to manage.
A silver lining to this unfortunate situation could be the possibility that Kontakt is sold to someone who will be a far better steward of that ecosystem.
Yes, there are a lot of amazing software instruments that live in Kontakt. However, there is a darker side to it; companies that author libraries often describe it as being in "Kontakt jail" because they pull all of the same tricks Apple does with their iPhone app store. In fact, it might be worse because they coerce people into signing exclusivity agreements in exchange for slightly better terms.
Meanwhile, the Kontakt VST itself keeps coming out with new versions that somehow still don't support no-longer-new features like MPE. If you want to use MPE with a Kontakt library, you need to run 8-10 instances of it and use a 3rd-party hack to round-robin your notes. It's not awesome.
I feel badly for the people who might lose their jobs, but the people at the top are not doing the products any favours.
No, the fact that Show HN is spammed with LLM-generated garbage is what drives me bonkers. The Show HNs are in fact living proof of how illusory LLM productivity gains are, because we are overwhelmed with trivial proof-of-concepts that have no merit, not even the merit of a human having put effort into creating something neat, rather than actually interesting software anybody would try or discuss.
Related that r/selfhosted has banned AI built projects except on Fridays[1] to keep up with the increased deluge of garbage, which are mostly built for CV padding rather than making anything useful for the community.
Counterpoint: You won't admit anything generated with LLMs is good? I don't see any evidence of your fairness in your comment, so why should I consider you any differently than the angry dude at the bar complaining over his drinks about how things were in his day?
> You won't admit anything generated with LLMs is good?
Nowhere in my comment did I say this, so this is quite a non-sequitur you've based the following personal attack upon. Regardless of whether it's possible to use LLMs to generate good things, the vast majority of things generated with them are not good, and if the good things exist, they are being drowned out in a sea of spam, increasingly difficult to discover along with the good human-generated content.
I have to say, I would characterise both your comment and the original comment I replied to as being considerably more "unfair" than mine. The first comment was clearly written in such a way to get a rise out of people. Your reply is directly insinuating that I'm out-of-touch and ranting at clouds.
This is a valid observation. I wonder though if people who have been coding for decades, but choose to use AI assistance, would fall under the same AI slop category. It’s an interesting dilemma because the overwhelming amount of content getting posted just ends up breeding a ton of negative feelings towards any amount of AI usage.
It will if you let it. The number of times the AI has come up with 'I can write you 'x', 'y' or 'z' in a heartbeat, just say the word' and I keep on having to steer it back to the track of being a repository of knowledge rather than an overeager very junior co-worker that can't help themselves to want to show off their skills.
It's very tiresome. Like an idiot/savant, they're an idiot most of the time and every 10th try you go 'oh, but that's neat and clever'.
I feel like HN is quite divided about that actually, A couple of days I started a survey which I plan to run monthly to see how the community feels about "LLM productivity etc". Now I have ~250 answers, need a couple more to make it significant but as of now it looks like >90% report productivity gains from AI tools - happy if you participate, only takes a minute: https://agentic-coding-survey.pages.dev/
Note that self-reporting productivity gains is a completely unreliable and unscientific metric. One study[1], small in scope but a noteworthy data point, found that over the course of the study that LLMs reduced productivity by ~20% but even after the fact the participants felt that on average their productivity had increased by ~20%. This study is surely not the end-all be-all and you could find ways to criticise it or say it doesn't apply or they were doing it wrong or whatever reason you think the developers should have had increased productivity, but the point is that people cannot accurately judge their own productivity by vibes alone.
If you look at the survey it's not only about productivity it's also about usage, model choice etc. But I agree with you self reported productivity gains is to be taken with a grain of salt. But then what else would you propose? The goal is to not only rely on benchmarks for model performance but develop some kind of TIOBE Index for LLMs.
The ever-present rebuttal to all LLM failure anecdotes: you're using the wrong model, you're prompting it wrong, etc. All failures are always the user's fault. It couldn't possibly be that the tool is bad.
If it generated something that saved you weeks, I think it's almost certainly because it was used for something you have absolutely zero domain understanding for and would have had to study from scratch. And I, at least, repeatedly do note that LLMs lower the barrier to entry for making proof-of-concepts. But the problem is that (1) people treat that instant gratification as a form of productivity that can replace software engineers. At most, it can make something extremely rough that is suited to one individual's very specific use case, where you mostly work around the plentiful bugs by knowing the landmines are there and not doing the behaviour that trips them; and (2) people spam these low-effort proof-of-concepts, which have no value to other people on account of how rough and lacking in ability to be extended to cover more than one person's use case they are, and this drowns out the content people actually put effort into.
LLMs, when used like this, do not increase productivity on making software worth sharing with other people. While they can knock out the proof-of-concept, they cannot build it into something valuable to anyone but the prompter, and by shortcircuiting the learning process, you do not learn the skills necessary to build upon the domain yourself, meaning you still have to spend weeks learning those skills if you actually want to build something meaningful. At least this is true for everything I have observed out of the vibe-coding bubble thus far, and my own extensive experiences trying to discover the 10x boost I am told exists. I am open to being shown something genuinely great that an LLM generated in an evening if you wish to share evidence to the contrary.
There is also the question of the provenance of the code, of course. Could you have saved those weeks by simply using a library? Is the LLM saving you weeks by writing the library ""from scratch"", in actuality regurgitating code from an existing library one prompt at a time? If the LLM's productivity gain is that it normalized copying and pasting open-source code wholesale while calling it your own, I don't think that's the great advancement for humanity it is portrayed as.
I find your persistent, willful bullheadedness on this topic to be exhausting. I'd say delusional, but I don't know you and you're anonymous so I'm probably arguing with an LLM in someone's sick social experiment.
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.
I happen to believe that you're foolish for endlessly repeating the same blather about "vibe coding" instead of celebrating how amazing what you yourself said about lowering the barrier to entry for domains that are extremely rough and outside of their immediate skillset actually is and the incredible impact it has on project trajectory, motivation and skill-stacking for future projects.
Your [projected] assumption that everyone using these tools learns nothing from seeing how problems can be solved is painfully narrow-minded, especially given than anyone with a shred of intellectual curiosity quickly finds that they can get up to speed on topics that previously seemed daunting to impossible. Yes, I really do believe that you have to expend effort to not experience this.
During the last few weeks I've built a series of increasingly sophisticated multi-stage audio amplifier circuits after literal decades of being quietly intimidated by audio circuits, all because I have the ability to endlessly pepper ChatGPT with questions. I've gone from not understanding at all to fully grasping the purpose and function of every node to a degree that I could probably start to make my own hybrids. I don't know if you do electronics, but the disposition of most audio electronics types does not lend itself to hours of questions about op-amps.
Where do we agree? I strongly agree that people are wasting our time when they post low-effort slop. I think that easy access to LLMs shines a mirror on the awkward lack of creativity and good, original ideas that too many people clearly [don't] have. And my own hot take is that I think Claude Code is unserious. I don't think it's responsible or even particularly compelling to get excited about making never looking at the code as a goal.
I've used Cursor to build a 550k+ LoC FreeRTOS embedded app over the past six months that spans 45 distinct components which communicate via a custom message bus and event queue, juggling streams from USB, UART, half a dozen sensors, a high speed SPI display. It is well-tested, fully specified and the product of about 700 distinct feature implementation plan -> chat -> debug loops. It is downright obnoxious reading the stuff you declare when you're clearly either doing it wrong or, well, confirmation of the dead internet theory.
Yes exactly, it's a standalone cloudflare page with some custom html/css that writes to a D1 (Cloudflare SQL DB) for results and rate limits, thats's it. I looked at so many survey tools but none offered what I was looking for (simple single page form, no email, no signup, no tracking) so I built this (with claude) Thanks for the feedback!
/r/selfhosted also got tons of new submissions, all unmaintainable AI slop. Now that they are only allowed on Fridays, it calmed down again. But I guess folks who insist on AI superiority think that’s a productivity gain.
The people spamming built bad stuff because they don't know any better. They would have built zero software without AI, so to the extent that anyone built anything working at all, it's basically an infinite productivity increase for those people.
AI productivity gains are not found in the slop bucket with projects tossed off after five prompts and zero intention of keeping them alive for the longer run.
A $200/month Cursor plan spent on Opus 4.5 calls is not expensive compared to the silly amount of work it will do if you make proper use of plan/agent/debug cycles.
I just wanted to vote with my feet and say that my experience echoes yours closely.
Modern coding agents have a remarkable grasp of circuit design and the net result is that they keep pushing me to learn more, faster.
I do find that I often have to specify that I only want parts that are "active on Digikey" because otherwise it will recommend obsolete parts. However, I consider this just like reviewing code generated by an LLM. You don't get a pass on reading datasheets or verifying statements.
I recently had GPT 5.2 spit out a progression of circuits that can amplify a dynamic mic signal to line level, simple to complex, with the intention of finally learning how good amplifiers work. Adding transformers and gain stages with the different OPA family parts and hearing the hum disappear and noise floor drop is the best kind of education.
A tip: BAT54SW specifically is the best part for protecting your pins.
This sounds interesting for quick prototypes, but tbh it doesn't map onto how most iterative layout processes actually work. At least in my experience. $0.02
However, I wanted to say that for a lot of common parts I find the Adafruit open source schematics to be at least as useful as the application layout suggestions in many datasheets. When it comes to regulators etc it's nice to see how they did it, because like your project, you really can approach it like a block.
I actually had this exact scenario come up last week except that in my version it warned me to make sure that I added a resistor to each LED to keep brightness normalized.
I didn't happen to need this particular advice, but it stuck in my head as something that would potentially save someone learning a lot of pain.
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.
reply