> The file is around 5000 lines

Yep, this is another case of different standards for "production ready."

Feel free to share it, would be very curious - ideally alongside the prompts.

I don't expect that - am merely responding to the parent comments claim that Claude consistently one-shots production ready code (which does not at all match my observations).

600k lines of code for anything on the ESP32 sounds like the absolute polar opposite of “good”

The more code is out there, the worse is the average in the training dataset. There will be legacy approaches and APIs, poor design choices, popular use cases irrelevant for your context etc that increase the chances of output not matching your expectations. In Java world this is exactly how it works. I need 3-5 iterations with Claude to get things done the way I expect, sometimes jumping straight to manual refactoring and then returning the result to Claude for review and learning. My CLAUDE.md (multiple of them) are growing big with all patterns and anti-patterns identified this way. To overcome this problem model needs specialized training, that I don‘t think the industry knows how to approach (it has to beat the effort put in the education system for humans).

> My experience with ESP32 development has been unreasonably positive. My codebase is sitting around 600k LoC and is the product of several hundred Opus 4.x Plan -> Agent -> Debug loops.

I feel like this is an example of people having different standards of what “good” code is and hence the differing opinions of how good these tools are. I’m not an embedded developer but 600K LOC seems like a lot in that context, doesn’t it? Again I could be way off base here but that sounds like there must be a lot of spaghetti and copy-paste all over the codebase for it to end up that large.

I'm better at pre-existing code, if only because empty text files give me writers block.

Whether we do or not it's besides the point. The comparison was between Claude, which produced competent greenfield code, and Gemini which struggled with brownfield. The comparison is stacked in Claude's favour.

Nope.

The only sources of these “it works flawlessly” I know of are:

- literal Claude ads I see online

- my underperforming coworkers whose code I’ve had to cleanup and know first hand that no, it wasn’t flawless

This kind of sentiment is gaslighting CTOs everywhere though. Very annoying.

I find it very much matters. I find Gemini better for pretty frontends, Claude opus for planning. Gemini and opus for code reviews. Codex is great when I want the LLM do follow instructions more strictly- good if you already have a detailed design.

Definitely depends on your use.

Swift/SwiftUI are two of the three experimental projects I'm using Codex on, the other is a physics simulation in python.

It keeps trying to re-invent the wheel, does a bad job of it.

The physics sim was supposed to be a thin wrapper around existing libraries, but instead of that it tried to write all the simulation code itself as a "fallback" (but it was broken), and never actually installed the real simulators that already did this stuff despite being told to use them in the first place. The last few dozen(!) prompts from me have been pairs of ~["Find all cases where you've re-invented the wheel, add them to the planning document", "now do them"]. And it's still not finished removing the original nonsense, so far as I can tell.

One of the two Swift experiments is just a dice roller, it took about 10 rounds of non-compiling metal shaders (I don't know metal, which is why I didn't give up and do that by hand after 4) before I managed to get that to work, and when it did work it immediately broke it again on the next four rounds. It wrote its own chart instead of using Swift Charts, and did it badly. It tried to put all the hamburger menu options into a UIAlertController. Something blocks the UI for several seconds when you change the dice font. I didn't count how many attempts it took to correctly label the D4.

The other Swift experiment was a musical instrument app, that got me to the prototype stage, eventually, but in a way that still felt like a student's project rather than a junior's project.