Spent last week rewriting an AI module line by line and it was worth it

Same thing happened to me but with an SPI peripheral for a data logger board. The AI version worked on the bench and I shipped it. Two months later we had a customer with intermittent data corruption and I had to spend three evenings figuring out that the generated code used a clock enable trick I had never seen before. Nothing wrong with it, just not something I would have written and therefore not something I could debug quickly.

What I do now is treat the generated file like code review from a contractor I barely know. I read the whole thing before simulation, not after. If I hit a section where I cannot explain why a signal exists, that section gets rewritten even if it works. usally that is about a quarter of the file for me.

One thing I added to my flow is writing the testbench myself before I look at the generated RTL. That way I know exactly what behaviour I expect and I can spot when the generated code solves the problem in some alien way. It also gives me a natural place to add comments about intent, wich the generated code never has. The cost is real but so is the alternative. Sitting in a meeting unable to answer a question about your own design is worse than losing a day up front.

I took the opposite path with a DDR3 interface on a Zynq board last spring. Instead of rewriting the generated module, I wrote a spec document first and made the AI regenerate everthing against it, twice. The second pass came back much cleaner because I had pinned down the refresh timing and the write leveling sequence in plain English before it started. So my review cost was mostly reading, not editing. Where I still agree with you is the ownership part. There was one submodule, a lane alignment thing, that I never fully understood no matter how many times I reread it. I ended up deleting it and writing about 80 lines myself over a weekend. Took me half a Saturday, worked first try on the ILA capture, and I have never worried about it since. My rule now is that anything I cannot explain out loud in a design review gets rewritten by hand, no exceptions. The generated stuff earns its keep on the plumbing, FIFO wrappers, address decoders, that kind of thing, and the parts where a bug whould cost us a respin stay human written. diffrent split than yours but same underlying principle I think.

I found that when using AI to generate a complex state machine, while the functionality often appears sound upon initial simulation, the resulting resource utilization metrics, specifically the lookup table count, frequently exceed what I would implement manually. It seems the machine prioritizes sheer logical completeness over achieving an optimal gate placement, which is quite frustrating for long term maintenance. My approach now involves running formal synthesis tools and comparing the resource footprint of the generated code against known, manually optimized designs before considering that module safe for integration.

I think stating that the review cost is mostly reading is a little optimistic. Even when you pin down every detail in a spec, the AI doesn't just write perfect logic. It often creates subtle issues that don't look like simple code errors. For instance, I saw a module generated based on a clean document that looked perfect during a logic read, but failed miserably at timing closure. It was making assumptions about clock synchronization that my high level specs didn't even cover. You can't just trust the implementation without deep regression testing. It's always about what the synthesizer decides to do with the blocks. Even the best draft needs rigorous physical verification.