It comes down to knowing what a UX is, and how everything underneath works together. This is “computers” all over again. Growing up alongside the evolution of the stack gives you a special background in what goes wrong, why it goes wrong, and how to fix it. Jumping into it when it’s gotten so abstracted it’s not possible to understand the stack from the ground up is where this sort of slop comes from.

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.

Oh I agree with that as well. I have no idea how I would be a junior on this industry now, nor do I even know how to manage juniors anymore given management’s expectations. We’re gonna have a real dearth in some years and I don’t know what’s gonna happen.

In a decade, all the current seniors will be a decade older and burning out and there won’t be any new ones to take their places.

That’s by design. Nvidia, OpenAI, Anthropic, etc will fill that void.

I also think org rot is real and is a different problem. Or at least… related but distinct.

Corpo leadership is completely brainrotted by promises of LLM sentience and firing half the company and I have no idea how to manage upwards on that front.

So, here’s where I think I’m gonna lose you. These days I read diffs but I so rarely read entire files. I generally know how pieces of things fit together, and I generally know how the systems are architected, the tech stacks, and I can still read functions and syntax… but I wouldn’t say I “know how it works” at a code level at this point. Once I accepted that it’s OK to know the high level, and verify the diff/PR level, it’s OK to not have 100% awareness on implementation, using claude became a lot less… smelly to me.

It’s not an easy thing to let go of, but the reality that I’ve experienced is that generally, claude can write good, secure functions. From a purely mechanical perspective, it’ll probably do a better job than I would on syntax, knowing the nooks and crannies of libraries, etc. But I review the diffs to be sure. However, I, the human, know what I want and generally how it should be done.

I’d say that learning where to not bother with claude and where it works well was a bit of a thing to figure out, but I really don’t spend hours debugging claude slop. Cause honestly in qualified hands, it doesn’t really write slop. It does write slop if you let it, or ask it to take on too much scope, but… “work this ticket for me, pay attention to x y z and don’t change a b or c” is well within a reasonable model’s capabilities.

I’d never pressure anyone into using LLMs and I have large ethical issues with the industry, but the idea that claude only slops doesn’t match with my lived experience in the past 6 months. I suspect when the finances of this whole thing go boom, KIMI and other open source models are gonna be able to run on rented GPUs for relatively cheap. Deepseek’s (reported) profit margins on inference seem to pay for the hardware (inc. GPU) in months… $1.6M per card in 5 years for revenue (not profit).

Obviously these models are not intelligent and cannot be, but they can be very powerful code generators.

I think the sloperators I see at my company are people who weren’t fantastic in the first place. If you were already a “rockstar” or a “10x” dev, claude probably makes you a 12-15x dev. But if you’re just a person who works hard, and you aren’t at a point where you understand when and why it’s OK to break rules, I think your output is gonna suffer and make your team suffer as a result.

I have no idea how i would be a junior in this environment but I know as a senior/staff, claude has let me do more than I could before, and my defect rate is not higher than pre-LLM. Mostly because I’m a SME and I bring my judgement and humanity to the design, and claude is just there to generate diffs for me to read and nudge.

Sorry for the barrage of comments, I’ve just been thinking and talking about this a lot recently and I tend to think out loud.

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.