These coding LLMs are essentially like a vacuum that sucks your brain dry. Anything you do with it is used to train: those comments you leave in a PR, the instructions you give within the chat thread, the manual fixes you make to the broken output, etc. So you lose ability, while the models gain ability.

The logical extreme here is that, in the future, the only way humanity will be able to code/write/design/whatever is through LLM products, because everyone forgot and stopped learning.

Whether or not you think that's progress, I think everyone can agree that what is definitely bad is that those models are centralized and controlled by a small group people (who also happen to be the worst people). It is the ultimate tech bro monopoly strategy, to win complete control over 100% of the high skill sectors of our economy. Any child not born to a billionaire family circle will only be able to make a living from physical labor.

Use it to skip the part where you type it all out yourself, and go straight to the part where you review the draft code.

Its not a 'do my job for me' imo its predictive text on roids.

Yeah. It's not why I became a programmer, to tell something else to program for me. Might as well find another job in that case.

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.

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.

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.

This might help, but tell Claude to do Test Driven Development [TDD] which will require each feature/function/etc.to have a test case and a pass before it can exit the worktree before a PR.

Also look into graphify which does a bit of "explain what this does" and makes things very easy to describe the code in a systematic way. AST is here again.

I'm having success with an agentic orchestration model that doesn't move on unless they pass the tests. And if they fail they hand off to a smarter model. I have to guide it and sometimes ask basic questions about why we're trying to load docker locally when I have guthub actions to do it, but if you know that much you can just poke it with a stick occasionally. The graph is updated and I have records for design decisions and reports on failure as well as tests to pass.

This is definitely a different approach and I can easily see how some people don't get it; and it's probably tied to doing things the hard earned way. Less developer and more TPM in terms of mindset.

I think throughput [lines of code, commits, PRs, beans, etc] is a worthless metric, velocity means speed + direction. A poorly guided version is just scattered all over, make it work and that's it, until the next round of changes.

But it's definitely a different game now.

Ok and what kinds of review comments do people leave? How often are PRs rejected? Do you have CI running your test suite? Why do you think so many bugs are getting through? Usually you need a strong culture of people demanding rigorous testing methodology in order for bugs to get caught early in the dev lifecycle.