4 ms·
> there really is no moat. For ChatGPT and Gemini, yes. But for Claude, they have a very deep & big one: Its the only model that gets production ready output
by KellyCriterion 8mo ago
> there really is no moat.
For ChatGPT and Gemini, yes.
But for Claude, they have a very deep & big one: Its the only model that gets production ready output on the first detailled prompt. Yesterday I used my tokens til noon, so I tried some output from Gemini & Co. I presented a working piece of code which is already in production:
1. It changed without noticing things like "Touple.First.Date.Created" and "Touple.Second.Date.Created" and it rendered the code unworking by chaning to "Touple.FirstDate" and "Touple.SecondDate"
2. There was a const list of 12 definitions for a given context, when telling to rewrite the function it just cut 6 of these 12 definitions, making the code not compiling - I asked why they were cut: "Sorry, I was just too lazy typing" ?? LOL
3. There is a list include holding some items "_allGlobalItems" - it changed the name in the function simply to "_items", code didnt compile
As said, a working version of a similar function was given upfront.
With Claude, I never have such issues.
- ben_w 8mo agoThat's been my experience too. I'm using the recent free trial of OpenAI Plus to vibe code, and from this I would say that if Claude Code is a junior with 1-3 years of experience, OpenAI's Codex is like a student coder.
- Oreb 8mo agoDoes it depend on what type of programming you do? Doing Swift/SwiftUI work, I have exactly the opposite experience. I’ve been using both recently, and I want to use Claude alone (especially after the last week’s events), but Codex is just so much faster and better.
- ben_w 8mo agoSwift/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.
- ben_w 8mo ago(Just outside edit window, I now realise I was ambiguous in this comment, it was more like "Find all cases where you've re-invented the wheel, add their removal to the planning document")
- skeledrew 8mo ago> Find all cases where you've re-invented the wheel Did you put in the original prompt the "wheels" you wanted it to use? It's a toss-up when you aren't very specific about what you want.
- ben_w 8mo agoFor the swift apps, at least half of the errors are of a type where I wouldn't expect to have needed to tell someone to not do it like that, and only a student could reasonably be expected to not know better. For the python physics sim, step 1 was to generate the plan, the prompt included "I want actual plasma physics, including high-density, high-field regimes, externally applied fields, etc., so consider which FOSS libraries would suit this.", and then it proceeded itself to choose some existing libraries, and I made sure those specific named FOSS libraries actually ended up in the plan. My first clue this wasn't going to work was that even from step 1 it was pushing for writing all the simulation code and not actually using e.g. WarpX despite that it itself had suggested WarpX. In fact, even when WarpX was in the plan, it was "integrate" rather than "just use this from the get-go". I may well throw the whole thing out and try again with Claude when this trial expires. Most of the runs have been comically non-physical, to the extent you don't even need a physics degree to notice, or even a physics GCSE.
- skeledrew 8mo agoDefinitely give Claude a go. I've been nothing but impressed by the performance thus far. My only gripe is the usage limit that I keep hitting.
- ben_w 8mo agoAlready have done, hence earlier comment: https://news.ycombinator.com/item?id=47204959 https://news.ycombinator.com/item?id=47204959 Claude made far fewer mistakes in general, never gave me non-compiling code.
- boxedemp 8mo agoI 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.
- noname120 8mo agoDo you use GPT-5.3-Codex Extra High or another model?
- littlestymaar 8mo ago> But for Claude, they have a very deep & big one: Its the only model that gets production ready output on the first detailled promp That's not a moat though. Claude itself wasn't there 6 months ago and there's no reason to think Chinese open models won't be at this level in a year at most. To keep its current position Claude has to keep improving at the same pace as the competitor.
- ptnpzwqd 8mo agoI have used Claude (incl. Opus 4.6) fairly extensively, and Claude still spits out quality that is far below what I would call production ready - both littered with smaller issues, but also the occasional larger blunder. Particularly when doing anything non-trivial, and even when guiding it in detail (although that admittedly reduces the amount of larger structural issues). Maybe it is tech stack dependent (I have mostly used it with C#/.NET), but I have heard people say the same for C#. The only conclusion I have been able to draw from this, is that people have very different definitions of production ready, but I would really like to see some concrete evidence where Claude one-shots a larger/complex C# feature or the like (with or without detailed guidance).
- je42 8mo agoInteresting - what kind of structural issues have you encountered? Is these more related to the existing source code or is this a bad pattern thar you would never do regardless of the existing code?
- huflungdung 8mo ago[dead]
- peteforde 8mo agoI see this over and over again. I don't dispute your experience. 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 review everything that goes through, but I'm reviewing the business logic and domain gotchas, not dumb crap like what you and so many others describe. What is so strange to me is that surely there is more C# out there than ESP-IDF code? I don't have a good explanation beyond saying that my codebase is extensively tested and used; I would know very quickly if it suddenly started shitting the bed in the way you explain.
- ivan_gammel 8mo agoThe 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).
- AlecSchueler 8mo ago> Its the only model that gets production ready output on the first detailled prompt. Yesterday I used my tokens til noon, so I tried some output from Gemini & Co. I presented a working piece of code which is already in production: One does often hear that where LLMs shine is with greenfield code generation but they all start to struggle working with pre-existing code. It could be that this wasn't a like for like comparison. That said I do personally feel Claude to produce far better results than competitors.
- jacquesm 8mo ago> One does often hear that where LLMs shine is with greenfield code generation but they all start to struggle working with pre-existing code. Don't we all?
- seba_dos1 8mo agoNope.
- AlecSchueler 8mo agoWhether 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.
- astrange 8mo agoI'm better at pre-existing code, if only because empty text files give me writers block.
- ivan_gammel 8mo agoGreenfield implementation is not flawless as well.
- ajshahH 8mo agoThe 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.
- otabdeveloper4 8mo ago> Its the only model that gets production ready output on the first detailled prompt. That's, just, like, your opinion, man.
- KellyCriterion 8mo ago...and of a lot of colleagues in and out of my sector :)
- jccx70 8mo ago[dead]