Hacker News Reader

Comment by archon1410 | Hacker News Reader

The naming scheme used to be "Claude [number] [size]", but now it is "Claude [size] [number]". The new models should have been named Claude 4 Opus and Claude 4 Sonnet, but they changed it, and even retconned Claude 3.7 Sonnet into Claude Sonnet 3.7.

Annoying.

View on HN

It seems like investors have bought into the idea that llms has to improve no matter what. I see it in the company I'm currently at. No matter what we have to work with whatever bullshit these models can output. I am however looking at more responsible companies for new employment.

I'd argue a lot of the current AI hype is fuelled by hopium that models will improve significantly and hallucinations will be solved.

I'm a (minor) investor, and I see this a lot: People integrate LLMs for some use case, lately increasingly agentic (i.e. in a loop), and then when I scrutinise the results, the excuse is that models will improve, and _then_ they'll have a viable product.

I currently don't bet on that. Show me you're using LLMs smart and have solid solutions for _todays_ limitations, different story.

Our problem is that non coding stakeholders produce garbage tiers frontend prototypes and expect us to include whatever garbage they created in our production pipeline! Wtf is going on? That's why I'm polishing my resume and getting out of this mess. We're controlled by managers who don't know Wtf they're doing.

It's been refreshing to read these perspectives as a person who has given up on using LLMs. I think there's a lot of delusion going on right now. I can't tell you how many times I've read that LLMs are huge productivity boosters (specifically for developers) without a shred of data/evidence.

On the contrary, I started to rely on them despite them constantly providing incorrect, incoherent answers. Perhaps they can spit out a basic react app from scratch, but I'm working on large code bases, not TODO apps. And the thing is, for the year+ I used them, I got worse as a developer. Using them hampered me learning another language I needed for my job (my fault; but I relied on LLMs vs. reading docs and experimenting myself, which I assume a lot of people do, even experienced devs).

When you get outside the scope of a cruddy app, they fall apart. Trouble is that business only see crud until we as developers have to fill in complex states and that's when hell breaks loose because who tought of that? Certainty not your army of frontend and backend engineers who warned you about this for months on end.....

The future will be of broken UIs and incomplete emails of "I don't know what to do here"..

The sad part is that there is a _lot_ of stuff we can now do with LLMs, that were practically impossible before. And with all the hype, it takes some effort, at least for me, to not get burned out on all that and stay curious about them.

My opinion is that you just need to be really deliberate in what you use them for. Any workflow that requires human review because precision and responsibility matters leads to the irony of automation: The human in the loop gets bored, especially if the success rate is high, and misses flaws they were meant to react to. Like safety drivers for self driving car testing: A both incredibly intense and incredibly boring job that is very difficult to do well.

Staying in that analogy, driver assist systems that generally keep the driver on the well, engaged and entertained are more effective. Designing software like that is difficult. Development tooling is just one use case, but we could build such _amazingly_ useful features powered by LLMs. Instead, what I see most people build, vibe coding and agentic tools, run right into the ironies of automation.

But well, however it plays out, this too shall pass.

Maybe a service mentality would help you make that bearable for as long as it still lasts? For my consulting clients, I make sure I inform them of risks, problems and tradeoffs the best way I can. But if they want to go ahead against my recommendation - so be it, their call. A lot of technical decisions are actually business decisions in disguise. All I can do is consult them otherwise and perhaps get them to put a proverbial canary in the coal mine: Some KPI to watch or something that otherwise alerts them that the thing I feared would happen did happen. And perhaps a rough mitigation strategy, so we agree ahead of time on how to handle that.

But I haven't dealt with anyone sending me vibe code to "just deploy", that must be frustrating. I'm not sure how I'd handle that. Perhaps I would try to isolate it and get them to own it completely, if feasible. They're only going to learn if they have a feedback loop, if stuff that goes wrong ends up back on their desk, instead of yours. The perceived benefit for them is that they don't have to deal with pesky developers getting in the way.

Reply on news.ycombinator.com