I had written a whole big thing that could be summarized as "yes, of course" but then I read the article and realized that it is very specifically about designing silicon, not devices.
I understand that it makes sense for a blog called Semiconductor Engineering to be focused on semiconductor engineering, but I was caught off guard because I have been working on the reasonable assumption that "hardware designer" could be someone who... designs hardware, as in devices containing PCBs.
In the same way that not all software developers want to build libraries and/or compilers, surely not all hardware designers want to get hired at [big chip company] to design chips.
It is funny how "hardware design" is commonly used in the chip industry to describe what semiconductor design/verification engineers do. And then there's PCB designers using those same chips in their _hardware designs_.
Also there's computer architects being like "So, are we hardware design? Interface design? Software? Something else?"...
Meanwhile, all the mechanical engineers are looking from the outside saying "The slightest scratch and your 'hard'ware is dead. Not so 'hard' really, eh?" ;) ;)
Every sector has its nomenclature and sometimes sectors bump into each other. SemiEngineering is very much in the chip design space.
If you keep digging, you will also find that there's a small but vocal sock puppet army who will doggedly insist that any claims to productivity gains are in fact just hallucinations by people who must not be talented enough developers to know the difference.
It's exhausting.
There are legitimate and nuanced conversations that we should be having! For example, one entirely legitimate critique is that LLMs do not tell LLM users that they are using libraries who are seeking sponsorship. This is something we could be proactive about fixing in a tangible way. Frankly, I'd be thrilled if agents could present a list of projects that we could consider clicking a button to toss a few bucks to. That would be awesome.
But instead, it's just the same tired arguments about how LLMs are only capable of regurgitating what's been scraped and that we're stupid and lazy for trusting them to do anything real.
Daily agentic user here, and to me the problem here is the very notion of "vibe coding". If you're even thinking in those terms - this idea that never looking at the code has become a goal unto itself - then IMO you're doing LLM-assisted development wrong.
This is very much a hot take, but I believe that Claude Code and its yolo peers are an expensive party trick that gives people who aren't deep into this stuff an artificially negative impression of tools that can absolutely be used in a responsible, hugely productive way.
Seriously, every time I hear anecdotes about CC doing the sorts of things the author describes, I wonder why the hell anyone is expecting more than quick prototypes from an LLM running in a loop with no intervention from an experienced human developer.
Vibe coding is riding your bike really fast with your hands off the handles. It's sort of fun and feels a bit rebellious. But nobody who is really good at cycling is talking about how they've fully transitioned to riding without touching the handles, because that would be completely stupid.
We should feel the same way about vibe coding.
Meanwhile, if you load up Cursor and break your application development into bite sized chunks, and then work through those chunks in a sane order using as many Plan -> Agent -> Debug conversations with Opus 4.5 (Thinking) as needed, you too will obtain the mythical productivity multipliers you keep accusing us of hallucinating.
1. Allowing non-developers to provide very detailed specs for the tools they want or experiences they are imagining
2. Allowing developers to write code using frameworks/languages they only know a bit of and don't like; e.g. I use it to write D3 visualizations or PNG extracts from datastores all the time, without having to learn PNG API or modern javascript frameworks. I just have to know enough to look at the console.log / backtrace and figure out where the fix can be.
3. Analysing large code bases for specific questions (not as accurate on "give me an overall summary" type questions - that one weird thing next to 19 normal things doesn't stick in its craw as much as for a cranky human programmer.
It does seem to benefit cranking thru a list of smallish features/fixes rapidly, but even 4.5 or 4.6 seem to get stuck in weird dead ends rarely enough that I'm not expecting it, but often enough to be super annoying.
I've been playing around with Gas Town swarming a large scale Java migration project, and its been N declarations of victory and still mvn test isn't even compiling. (mvn build is ok, and the pom is updated to the new stack, so it's not nothing). (These are like 50/50 app code/test code repos).
Why do all of that when you can just keep a tight hold on an agent that is operating at the speed that you can think about what you're actually doing?
Again, if you're just looking to spend a lot of money on the party trick, don't let me yuck your yum. It just seems like doing things in a way that is almost guaranteed to lead to the outcomes that people love to complain aren't very good.
As someone getting excellent results on a huge (550k LoC) codebase only because I'm directing every feature, my bottleneck is always going to be the speed at which I can coherently describe what needs to be done + a reasonable amount of review to make sure that what happened is what I was looking for. This can only work because I explicitly go through a planning cycle before handing it to the agent.
I feel like if you consider understanding what your LLM is doing for you to be unacceptably slow and burdensome, then you deserve exactly what you're going to get out of this process.
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.
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.
I understand that it makes sense for a blog called Semiconductor Engineering to be focused on semiconductor engineering, but I was caught off guard because I have been working on the reasonable assumption that "hardware designer" could be someone who... designs hardware, as in devices containing PCBs.
In the same way that not all software developers want to build libraries and/or compilers, surely not all hardware designers want to get hired at [big chip company] to design chips.
reply