Spent the weekend letting Claude write my Verilog and the results surprised me

I had a similar weekend with one of these tools, though my failure mode was different. I asked it for an interface between a rotary encoder and the counter logic on a small Digilent board I had sitting in a drawer. It wrote something that compiled first try and looked tidy, but it assumed my clock and the encoder were related when they are not, so the counts drifted. That kind of mistake is invisible until you probe it, and working out where it went wrong took me most of the evening anyway.

Where it actualy earned its keep for me was the boring parts. I asked it to write a testbench for the corrected version and to throw together a few stimulus patterns, and both came out fine. I have started treating it like a junior engineer who is fast but needs every assumption spelled out. When I tell it exactly what the reset looks like and how the clock domains relate, the output is ussually worth keeping. When I leave it vague, I pay for it later. On the faster or lazier question, I type less but I read more, and reading other people's code was always the slow part for me anyway. So I would call it about even, maybe slightly ahead on a good day.

My expirience runs the other direction, I only let the AI near the checking side of things. I write the actual logic myself beacuse I type faster than I can read what it hands back, but I always hated writing the inputs and expected outputs by hand. It eats up an evening every time. Now I paste in my finished code, ask it for a testbench, and go from there. Last month that flow actually caught a mistake in my own work, a counter in a PWM generator I did for an LED dimmer that never wrapped because I'd fat-fingered the width. So maybe I'm using it backwards compared to everyone here, but for me the code is the fun part and the checking code is the chore, and this thing is very good at chores.

I've found the big AI code blocks to be sketchy when they get too large. It handles the simple stuff well, but state machines turn messy fast. I once had to debug a huge state transition that the AI generated and it was a mess of tangled logic. The only way I found to really nail the behavior was running the code through the formal verification scripts I pulled from an old Xilinx forum guide. That forced me to map every single corner case manually. It proved that while it gets you off the starting line, you still have to do the deep dive to make sure the chip doesn't crash. It's less about who is typing faster and more about who is better at checking the output.