I don't grow as a developer

This for me. I code for computational physics stuff and I feel like it's when I implement stuff that I find out if I really understand things.

So many people at work are just implementing shitloads of useless shit entirely by Claude, while complaining about people using their codes as black boxes.

There's a reason the term "protoduction" was coined.

I remember when the numbers of lines of code per developer were a thing. Or fix in one go, where test failures counted against devs ratings. This is neither the beginning nor the end of shitty KPIs mandated by clueless management.

Good luck with that when management is dumb and only looks at number of lines committed and PRs reviewed. Then those who commit with reckless abandon and rubber-stamp PRs are seen as superstars while those who take care are seen as slow and holding up the process.

I do like the specification and differentiation between llms and ai. Good point.

Sorry 2 mil in dollars. I should have specified.

I'm in the same boat, although the vibe coders where I'm at are a bit more put together so sometimes they do get something out that's not entirely half baked but generally only CRUD apps.

They are however using it A LOT for research which is a huge fucking problem. I've had to read a bunch of "vibe papers recently" and it's been a mess.

Very unhappy.

Your not alone, Ive stopped using LLMs for any of my work. It's doesn't have any net value gains for me. The work is shittier, more expensive in the long run, less secure, I don't grow as a developer, and locks us in to using LLMs more.

Edit: and to add I am not old by any means

Thanks.

Hope is at some point they'll break something important enough that the boss will consider that it's costlier to keep doing business with them than to migrate everything. 🤷‍♂️

Meanwhile we're porting as much as we can to in-house solutions. Trying to minimise the amount of work needed to transition away from them.

Good luck my dude!

Didn't catch the cases in which it failed.

And the ERP troglodytes don't seem to have tests, no. Obviously not for our stuff (unless they're testing to make sure it breaks), and it certainly doesn't look like they do any kind of testing for theirs either.

I tried to AI a project at work. Once.

Yes it did the job but it had poor error handling, logging and zero standardization/structure.

I tried again with writing a template file with my own code snippets and blocks.

It did better. Still nowhere near done, but I used that as a first draft. I'd say half done to my standard. Deleted/reworked/added code.

I guess it saved time at that point. Still can't see a whole ass project being full AI gen.

It's a story as old as time itself.

Just see if you can get it to work; don't worry, we'll make it right before we ship.

Don't you have tests for all that 😰?

Like a CI pipeline with tests? You just push stuff?

Thats valid but likely not the only way you're capable of doing it, just the way you're used to.

Thats the skill, finding them in review.

Its valid to think that sucks and is perhaps less enjoyable than doing it yourself, but I think a lot of things are going to head that way over the next decade or so.

Just wait until they make your PMs "engineers" because "Claude can do the work" so they literally just prompt Claude all day and raise the shittiest PRs without know how to even use Git or Virgin, Claude does it all for them.

MFW when management discovers the rapid prototyping technique, but forgets that they’re only prototypes.

This was an issue before LLMs, Senior developers just doing all the work because it was easier and they were under pressure of a deadline. Maybe if a Senior over committed and they had to YOLO with a junior to do a small part to have any chance of meeting expectations, that would be easier to replace with a LLM. But in that case, is a junior really learning anything that they couldn't by self learning anyway?

If you really think the answer is still yes. There is usually, always something to throw someone at and seeing what sticks, It will just fall in the maintenance realm and not on some critical path. That's how I was "trained", got almost no feedback because it wasn't important, and ultimately failed because I was mislead and had to do it twice.

Training someone up has always been intentional IMO, LLMs just makes "necessary" accidental "training" easier to avoid.

Worse case if a junior is hired, there is work to find for them, and throw them at.

Its pretty good at SQL

Eh 🤷‍♂️. Call it anecdotal if you want, but this is my experience:

The imbeciles who manage our ERP silently pushed some update that must have removed some indexes because suddenly several complex queries were one or two orders of magnitude slower.

While I got to work on optimizing them, a colleague who's outsourced most of his thinking to LLMs got what according to him was “the most powerful model” (some flavour of claude, I assume) to take a look at one particular affected query relevant to the project he was working on.

To be fair it went for more or less the same approach I was taking (storing intermediate results in table variables, spending memory to save speed, though it used temporary tables instead for some reason), but in a significantly more inelegant and inefficient way than I would have (for instance, it put SELECT *s — from tables with hundreds of columns! — into the temporary tables, when we only needed a few columns; an absurd waste of memory; it also missed several other optimizations, being apparently happy with “good enough” instead of trying to be thorough).

Happy with the result he pushed it into production, while I kept working on the rest of the queries, managing to also bring them back to reasonable times.

Couple days later, ticket comes in about that specific query being slow again, for particular parameters. I'm not sure what was wrong (the design of the database is absolute unadulterated shit, but it belongs to the ERP anthropoids and we can look but not touch, and have to work around it), but in some specific cases some joins produced many duplicate results, leading to massive slowdowns. While diagnosing that I also noticed that some of the values it produced weren't correct.

So I rewrote the whole thing based on the work I'd done with the other queries, and now it works properly and efficiently, and significantly faster (at least until the ERP assholes break something again).

TL;DR, sure, the machine quickly produced an apparently working solution (I don't know what the cost of the tokens was, though), in much less time than I could, but the result was ugly, poorly thought out (which, I mean, since it was made by something that can't think and just statistically processes language, I'm not sure to which extent can be a criticism of the technology, but is a criticism of those using it), less efficient than mine (and I wouldn't call myself any kind of SQL master or guru, I just meddle), and failed in some particular cases. I was not impressed.

TBH I would recommend some of the competing APIs over free Claude.

Xiaomi’s token plan, in particular. It’s dirt cheap (a couple of bucks for a whole year), Mimo 2.6 is great, but they’re a “dark horse” in the LLM race now. They aren’t widely known like Deepseek/GLM, and their models are under-hyped, hence they aren’t popular and are pricing things accordingly.

Define what you want, have the tests written, lock the tests and then have the code written.

Ah! No, I never suspected LLMs would work for architecture.

This thread got me to sign up for the free version of Claude, which promptly hosed a very simple Powershell script I had on hand. BUT, it did give me ideas on speeding it up, things I hadn't thought of. I'll take another pass without so many beers in my blood.

The part where I type it out is the part where I come up with better ways to do it, though.

Also the part where I store a mental map of it so I know where to look when something breaks.

And medium chunks. Medium chunks require a good agentic framework, but they can handle sizable chunks of code.

It can also help you brainstorm/debug, as long as you recognize the sycophantic tendency.

And yes. If you can’t understand what it’s written (or mathematically prove the module functions correctly), that’s a problem.

I guess I’m saying LLMs are bad at “architecting” big projects. They aren’t intelligent, they are ephemeral constructs akin to weather prediction models that don’t have a mind, nor any memory, nor any adaptiveness. They simply do not understand things like a person does, and they cannot grasp some things, so it’s up to the person to provide the framework and point them at monotonous tasks to automate.