Comment by garciasn | Hacker News Reader

Comment by garciasn | Hacker News Reader

Parent Full thread

Well; I can't speak to your specific experience (current or past) but I'm telling you that while I'm skeptical as hell about EVERYTHING, it's blowing my expectations away in every conceivable way.

I built something in less than 24h that I'm sure would have taken us MONTHS to just get off the ground, let alone to the polished version it's at right now. The most impressive thing is that it can do all of the things that I absolutely can do, just faster. But the most impressive thing is that it can do all the things I cannot possibly do and would have had to hire up/contract out to accomplish--for far less money, time, and with faster iterations than if I had to communicate with another human being.

It's not perfect and it's incredibly frustrating at times (hardcoding values into the code when I have explicitly told it not to; outright lying that it made a particular fix, when it actually changed something else entirely unrelated), but it is a game changer IMO.

> I built something in less than 24h that I'm sure would have taken us MONTHS to just get off the ground, let alone to the polished version it's at right now

Would love to see it!

See, your comment is a good example of what's going wrong. The OP specifically mentioned "mission critical things" - My interpretation of that would be things that are not allowed to break, because otherwise people might die, in the worst case - and you were talking about just SOMETHING that got "done" faster. No mention about anything critical.

Of course, I was playing around with claude code, too, and I was fascinated how fun it can be and yes, you can get stuff done. But I have absolutely no clue what the code is doing and if there are some nasty mistakes. So it kinda worked, but I would not use that for anything "mission critical" (whatever this means).

If you have absolutely no idea what the code is doing, something is wrong. Imagine someone with no engineering experience telling an engineer to build a jet engine "make it spin fast". Presented with the designs, he has no idea wether it's good. Obviously that is not workable. Rather, the one in charge for guiding, say, the design of a jet engine, would know the intricacies of the jet engine himself perfectly. It just would be too tedious to design all the little parts of it, and verify all the little characteristics by one person.

When developing with an LLM, you first figure out how you want to do it, and essentially start imagining the code. But rather than writing and testing, you tell the LLM enough to unambiguously implement what you have in mind, and how to test it/the expected behavour/scenarios you have in mind that it will support. Then you review the code; modern claude will not present you with buggy code, it will go through iterations itself to have something that works. The feedback than usually is something more about code style, consistency, or taking into account future expansions of the code.

The mission of a professional programmer is to deliver code that works according to the design specs, handles edge cases, fails gracefully and doesn't contain performance bottlenecks. It could be software for a water plant, or software that incurs charges to accomplish it's task and could bankrupt you if there is a mistake. It doesn't have to be a matter of life or death.

But there are a lot of projects and problem domains that don't even demand that much or have any real consequences for failure. I look at all the self-service stuff my employer has for HR, benefits, policy compliance, it's all half-broken, nobody ever seems to get held to fixing anything, and the only answers are "try it again later."

Professional programmers built this stuff too, or maybe it was vibe-coded but since it's been like that for years I think probably not.

But we don't know where on the spectrum of "people might die" to "try again later" most of these programmers who claim great productivity gains from LLMs lie. Maybe it is making them 10x faster at churning out shit, who knows? They might not even realise it themselves.

We haven't even come up with different methodology yet to leverage these tools that well.

At some point one would have to think the idea of coming up with one design will seem outdated if the model is producing a 1000 different versions at once and then testing to find the best design. Then working on improving and tightening the design 24/7 365.

Most of what I read on here seems like knocking the automobile while proclaiming the virtues of the horse. It only makes sense because we can't see all the paved roads, gas stations and highways yet that make the horse a complete relic for travel.

At some point, it will make as much sense to pay a human to write code as it does to take a horse on the interstate.

> So it kinda worked, but I would not use that for anything "mission critical" (whatever this means).

It means projects like Cloudflare's new OAuth provider library. https://github.com/cloudflare/workers-oauth-provider

> "This library (including the schema documentation) was largely written with the help of Claude, the AI model by Anthropic. Claude's output was thoroughly reviewed by Cloudflare engineers with careful attention paid to security and compliance with standards. Many improvements were made on the initial output, mostly again by prompting Claude (and reviewing the results)."

> It means projects like Cloudflare's new OAuth provider library.

the one that's a few weeks old and already has several CVEs due to the poor implementation?

https://neilmadden.blog/2025/06/06/a-look-at-cloudflares-ai-...

I don't understand. Of course you should read the code. There is no responsible engineer that would advocate for blindly accepting code written by another party for critical functions, be that a human or an LLM.

Reply on news.ycombinator.com