I use LLMs heavily for coding. Most engineers do at this point, and they're genuinely good. I can move faster, ship more, and offload the kind of tedious scaffolding that used to eat entire afternoons.
But I don't think I'm fast because the model is good.
I think I'm fast because I know what I'm asking for.
That distinction took me a while to figure out, and I only really understood it after an experience during my capstone where the LLM didn't make me faster. It made me stuck.
### The software guy in charge of electronics
For our fourth-year capstone, I ended up in charge of the electronics. This wasn't really my domain. I was the software guy on the team, and everyone else leaned heavily chem or mechanical. But electronics felt adjacent enough to software that the responsibility landed on me almost by default. I had taken a couple of circuits courses in second year, and in a team of nanotech engineers, that was apparently enough to make me the most qualified person for the job.
The task, in hindsight, was embarrassingly simple. We needed to read very low intensity NIR light off a photodiode and amplify the signal enough for a microcontroller to process it. What we actually needed to build was a reverse-biased transimpedance amplifier. A TIA. An op-amp, a feedback resistor, a feedback capacitor, a photodiode. That's it. Four components and a breadboard.
But at the time, I didn't know that.
All I knew was the problem statement: sense low intensity NIR light, get data out. I didn't know the name of the circuit. I didn't know what category of op-amp I needed. I didn't know which specs on a datasheet mattered and which ones I could ignore. I had a vague memory of LTSpice from second year and a general sense that circuits have resistors in them.
So I did the natural thing in today’s age. I opened up an LLM and started vibe-circuiting.
### Where it went wrong
The first conversation actually went well. I described the problem, and the model correctly identified that I needed a TIA. It explained op-amps, feedback resistors, the basic amplification formula. It gave me the right mental model. If I had stopped there and handed the conversation to someone who actually knew electronics, they probably would have finished the job in an hour.
The cracks showed up when I started picking parts.
I went to Digikey, sorted op-amps by price, and grabbed the first cheap one I found. I pasted the datasheet into the chat and asked how to wire it up. And this is where things quietly went off the rails. The model started talking about voltage dividers, reference grounds, biasing networks, rail-to-rail considerations. Some of it was relevant. Most of it was not, at least not for what I was building. But I couldn't tell which was which.
I asked it to just draw the circuit for me. It produced some ASCII diagram that looked plausible. I translated it into LTSpice. Nothing worked. The output was flat, or railed, or oscillating wildly. I went back and forth with the model for days. Each response added more complexity, more components, more caveats. I kept asking better-sounding questions and getting worse-working circuits.
The problem wasn't necessarily that the model was wrong. The problem was that I didn't have the vocabulary to tell it what I actually needed, so it kept guessing. And because I didn't have the vocabulary to evaluate its answers, I kept accepting the guesses. Every turn in the conversation pushed us further from the simple four-component circuit that would have actually worked.
Eventually I threw in the towel. I had gone so deep into the weeds that nothing made sense anymore. I couldn't even remember what the original goal was supposed to look like.
### A thirty-minute phone call
A mutual friend, a third-year electrical engineering student on an EE co-op, agreed to hop on a call.
The call lasted maybe thirty minutes.
He asked me a few specification questions first. Which microcontroller are you using? What's the supply voltage? How low is "low intensity" for the photodiode? Then he gave me the handful of things I actually needed to know. Look for an op-amp with low input bias current, because you're dealing with tiny photodiode currents and bias current will dominate your signal. Make sure the op-amp's supply range matches your Arduino's supply, or plan for an external battery. Pay attention to package type, SOIC versus DIP-8, because one of them won't go into your breadboard without an adapter. The ADC on your microcontroller matters more than you think for the resolution you can actually extract. Then he sketched the rough circuit on his LTSpice. It took him about ten seconds.
That was it. That was the whole gap.
None of what he told me was secret. None of it was advanced. It was the basic scaffolding any EE student picks up in their first real circuits class, and it was exactly the scaffolding I didn't have. With those five or six pieces of context in hand, I went back to the LLM, and the second conversation was completely different. I could ask specific questions. I could evaluate the answers. I could tell when the model was drifting and pull it back. The simulation worked. The breadboard worked on the second try, after I fried one op-amp by dual-supplying 9V batteries to a chip with a ±16V max range. Turns out ±18V is more than ±16V. Lesson learned.
But the thing I actually learned, the thing that stuck, had nothing to do with op-amps.
### The multiplier runs both ways
The LLM didn't get better between conversation one and conversation two. I did.
The exact same model, with the exact same weights, produced garbage when I prompted it from a position of ignorance and produced a working circuit when I prompted it from a position of basic competence. The delta wasn't in the tool. The delta was entirely on my side of the screen.
This is why I think the "LLMs make everyone a 10x engineer" framing gets it backwards. LLMs are a multiplier, and multipliers work in both directions. If you have strong domain knowledge, the multiplier is large and positive. You can skip the tedious parts, offload scaffolding, move through work that would have taken hours in minutes. But if you don't have the domain knowledge, the multiplier still runs. It just runs on garbage. You confidently produce things that look right, move fast in the wrong direction, and accumulate subtle errors faster than you can catch them. The speed is real, but it's speed away from the goal, not toward it.
The reason LLMs feel magical for coding, for me, is not because the model is magical. It's because I spent years building the instincts to know what good code looks like, what a reasonable architecture is, what questions to ask when something feels off. The model accelerates me because I can tell when it's right and when it's drifting. Take away that substrate and you get exactly what I got during capstone. Confident-sounding ASCII diagrams of circuits that don't work.
Garbage in, garbage out has always been the rule for computation. LLMs don't change it. They just raise the stakes, because the garbage now comes back in fluent English and sounds like it knows what it's talking about.
The best prompt in the world won't save you if you don't know what you're asking for. And that part, unfortunately, still has to come from you.