[BUG] Damaged Hardware

This isn't a Claude Code bug. It's a hardware design and workflow issue.
Software-only control of a 1kW load through a GPIO is unsafe regardless of what code is running. Any firmware bug, watchdog reset, or partial initialization can drive a pin to an unexpected state. It doesn't matter if the bad code came from Claude, Stack Overflow, or a typo.

You need hardware interlocks: a watchdog circuit, an enable timer, a relay that defaults open. Something that physically cannot activate the load without sustained intentional signaling and protects from repeated rapid cycling.

Don't flash untested firmware with live hardware attached. Disconnect the load, flash, verify clean boot, check GPIO states, then reconnect.

You already knew the ZVS circuit was cycle-sensitive. The first board failed from normal use. That should have been the signal to add hardware protection before writing another line of code. The gap isn't in the coding assistant or the model used. It's in a workflow and circuit design that allows a single software fault to destroy hardware.

What user should have done: Reviewed changed Claude Code made before running on production hardware to ensure it wasn't making this exact mistake

“it compiled”

oh sweetheart, that’s adorable.
You just speedran the entire “my first magic smoke funeral” category in under 48 hours because “it compiled” has apparently replaced actual engineering judgment in 2025. Claude didn’t brick your board: You did!

By treating a language model like it’s simultaneously a senior EE, a safety-certification body, and your personal liability shield. Spoiler: it’s none of those things. It’s autocomplete with anxiety and zero skin in the game when 1 kW turns into a backyard arc welder.

“My own code behaved”

Yeah, because your own code wasn’t the one that got silently regressed by whatever prompt-engineering voodoo you (or Claude) did five minutes before you yeeted untested firmware onto live 1 kW hardware like it was a TikTok trend. Pro tip from people who’ve actually smelled gallium: if your safety philosophy boils down to “the compiler didn’t segfault so it must be fine”, you’re not doing embedded. You’re doing expensive fireworks with extra steps.

Next time maybe try (wild concept incoming)
disconnecting the damn load,
flashing,
probing every cursed GPIO state with a multimeter while swearing at the screen,
only then reconnecting the magic death rectangle.

But nah, too hard. Better to let an LLM roleplay as UL 508 while you film the aftermath for the group chat. Enjoy re-ordering MOSFETs, legend. The magic smoke always wins.

No @ilude is not AI, though there are days he likely wishes he was. There is a reason why Dario Amodei said he didn't want his AI involved in Kill-chains; it is not 100% correct. Every System that can result in Damage to itself or yourself should have safety interlocks. The Railroads learned this in Blood.

If this code is responsible for controlling hardware. Consider not if can go wrong, assume it will

I have worked in infrastructure; there are reasons why it takes years to make any changes to it.

That's fairly condescending attitude.

Yes, Yes it was... I provided you with very constructive feedback to your original post. But replying with "my own code worked" and "it compiled" are two of the most junior level dev statements possible. And show that you are way way out of your depth here.

I did not provide you with the full testing environment and methodology I used.

Yes you in fact did provide that, you test in production! And it bite you hard in the ass!

I can't understand why you're defending Claude?

Because the problem is not Claude's fault. Its your entire organization's fault, and you are part of that organization and are the key player with the best opportunity to change the organizations ways going forward, and before something even worse happens!

Here are two references for you to study and understand that are directly relevant to your situation:

Therac 25

Who Destroyed Three Mile Island? - Nickolas Means

I know how I mapped GPIO's and how it compressed the conversation and "forgot". It did not add my mapping to the rules as I asked.

And your procedure was to push this code onto a production system and hope! You didn't ask yourself, the AI, or anyone else to validate that your rules had been applied. You didn't validate that the code worked on a test bench. And finally and most importantly you didn't create an hardware safety mechanizes to insure the board would be protected when you already KNEW that it will fail if cycled over and over again!!!

I appreciate any real help, but flippant analogies and references to social media don't help. The AI performed poorly. When I made it refer to GIT and historical context in *.md" files. it admitted it messed up.

You mean the AI told you "You are absolutely right!" Shocking! If only someone had known! Perhaps they should put a message like "Claude is AI and can make mistakes. Please double-check responses." on their webpage or a link explaining these issues

I'm sorry if this is harsh medicine but its clear you need a bit of Shakubuku

Now I am going to challenge you to copy and paste the text from this issue, all of it, into any frontier ai chat and ask it where the failure was and see what the response is!

https://www.youtube.com/watch?v=BaC5FEN2e4Y

You've said enough about yourself to show you seek only self-glorification. I'll give it to you. You are better than everybody in the world.

I don't see this GitHub as constructive. I would have given you the AI Chat; unfortunately, it is compressed and I have lost it. I mentioned that.

Anyway, I was hoping Anthropic would constructively use my feedback to tweak their algorithm. Alas, like you, they think they are better than us.

I am done with this.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.