I kind of think the whole "Learn to Code" push of the 2010s was one of the worst things that happened to our industry. Call me a gatekeeper if you want but, we ended up with a lot of people that just can't do the job. The problem is our industry mostly doesn't have any sort of reasonable mentorship or apprenticeship culture, so we've always left it to the engineers to teach themselves. Sink or swim. The problem is that worked when the industry was mostly composed of people that were implicitly interested in this stuff, but the people that just got in it for a paycheck don't have that motivation, and we don't have a good culture of getting them up to speed. So now we have seniors that can barely write a function, much less reason about a complex system.

I remember people used to debate all the time about if there were "10x" engineers or whatever. A few I'm sure, but I think the real problem is we have a lot of 0.1x engineers or worse.

This 100%. I just requested a hackathon for performance improvement (might be wasted effort).

We are pushing tons of code and now our CPU usage has grown exponentially over the past year because the bad engineers just ship whatever Claude gives them and do not think about the consequences.

Our biggest consumer of CPU right now is HTTP connection churn because engineers are creating new clients every request we handle. If the engineers would just think for a second, push back on Claude, even Claude would tell them this is bad. But they don't... Platform engineering is now 10x harder with terrible engineers and unlimited code machines.

Don't even get me started on ffmpeg usage, engineers act like the resources are unlimited.

> The most egregious of these cases for me is often long tenured engineers who have lost interest in the craft, creating a dangerous combination of having enough merit to ship but not enough interest to make what they ship _good_.

I wouldn't be so quick to judge the long tenured engineers. They probably realized that moving business forward is more important than writing artisan code.

You always have some young hotshot who comes in and wants to rewrite your old boring Java monolith into a micro services disaster for "better architecture".

The greybeards learned the life lessons the hard way.

The other aspect to consider is this: stay in this industry long enough and it will beat the soul out of you.

> > bad engineers were always a liability

> With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.

Yup, and that's going to be the comeuppance for a decade of aggresive overhiring.

There are so many "bad engineers" filling the ranks now that in many teams and divisions there's not even anyone left around who can recognize them as such.

This was already manifesting as a rapid decline in software quality and worsening practices, and the amplification effect of AI is mostly going to make everything worse for a while as we wait for all these declining projects to buckle under their weight.

If you are a good engineer, it's a good time to work on small teams with other good engineers and rigorous practices. You can be using AI to amplify what you do (and probably should), but you need to be rigorously considering your processes and guarding yourself from seduction by blind-leading-blind hype you see on social media or in iconference talks.

pretty good presentation.

my take is everyone in the industry should read grog-brained developer, & no silver bullet before working as a professional.

the other is a mindset change - the best working code is code that's never written as it doesn't have bugs or suffer technical debt. Agentic coding doesn't solve that. Human taste does, which means our job is to reduce the amount of lines we write. agents etc are useful for the filler or bullshit part of our jobs e.g generating tests.

but ultimately I think the whole spec-driven development & agents spitting 100000s of lines era will be looked upon as mass psychosis.

last thing to give an analogy - you don't carve a David statue by gluing together pieces of marble - but you carve it by cutting pieces of a huge block of marble.

Tell me how to paradigm shift careers and I'll get out of your hair and stop shipping uninspired features.

But, right now I'm paralyzed with fear in how to make a successful career switch without starting from literally "new grad level." I have wisdom, so it doesn't feel like I should have to start at the bottom rung again. Egotistically, I don't even mind, it's just the salary hit that would be the main issue.

Maybe it's not even a paradigm shift (though, I've always wanted to work on film productions). I've sort of lost the passion for being an IC, but how can I make a transition to management without any management experience? Should I just apply for a managerial role and in the cover letter state management is my intended path for growth?

> With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.

It's even worse than that. We've got a CEO who has suddenly learned how to vibe code and the stuff he's coming up with is... kind of horrendous. He's coming up with new "products" and proclaiming them the next big thing for us to work on and we're kind of over here scratching our heads asking who would want this? Who would pay for it? I mean, he was able to put together a kind of a cool web app (with 0 web app knowledge) that's supposedly going to let users design thingys with AI, but it just seems like he re-invented a harness/IDE. I suggested that maybe what he wants is a VS Code plugin like Cline or KiloCode... but he hadn't used VS Code.

I think this point gets lost on people. A frequent argument I see in favor of vibecoding is: “well there’s also bad engineers”. In other words, bad code is already being written, so who cares if the LLM is wrong sometimes?

The issue is that with no reins, the LLM is a fire hose of bad code compared to the garden hose of bad code orgs had before. A good engineer, with a good model and harness will produce great stuff. A bad engineer with a good model and harness will produce something faster, but it will be worse.

This is right on the money. It's not that we have way more bad engineers than before; it's that the damage they do is out of all proportion to their numbers.

Rather than good or bad engineers, I'd focus on the quality of the idea. Every software engineer has good and bad ideas. Historically, bad ideas were kept in check by the effort it would take to code the implementation. With that barrier nearly gone, there's no friction - a bad idea in the morning gets deployed to prod in the afternoon. No thinking required!

So yes, garbage in -> garbage out, but framed in a way that makes it clear what is garbage. The ideas, not the engineer themselves :-)

This suggests we need to be doing more designing and planning; introducing that friction intentionally to make sure bad ideas get culled, viable ideas get refined. Critical thinking becomes the bottleneck; the quality of the idea becomes the deciding factor in success.

> but not enough interest to make what they ship _good_

I'm having the impression business decisions always win, time is always reduced and requirements always changed half-way during a project, having a much greater impact than any bored old engineer.

This is me to a tee. I think I'm a fairly good software engineer, and I loved building software and mentoring more junior engineers who I thought had both ability and a good attitude. I also think I was a pretty pragmatic engineer (I was not an "architecture astronaut"), but I did enjoy the craft of getting into the nitty gritty details of software.

The past 5-10 years or so saw me pretty beaten down though with software engineering, and AI was the final nail in the coffin that caused me to leave the profession in later middle age. I thought software as a business had "lost its way" from building great products with attention to detail to "how do we addict as many people as possible as quickly as possible". Think about the degradation in Apple software from say the "it just works" era to now.

With respect to AI, I'm not really against it, and I find it extremely valuable in my personal projects. I just feel in a large group/enterprise context that it's replaced a lot of tasks I actually enjoy doing with becoming an editor for what feels like a slightly inebriated junior developer. Or maybe it's better to say a junior developer on a mild amount of meth, because as you say this developer can churn out semi-but-not-fully-working code at an astonishing rate, and then I feel like it's often my job to mop the slop off the floor. Pass, not interested.

I feel lucky to have had my career during what I consider the golden age of software engineering, but I'd note I don't think that golden age lasted even a full career of one person.

The analogy I have heard is that LLMs are a force multiplier, so if you were a 2x engineer before you are now a 10x engineer, and if you were a -2x engineer you are now a -10x engineer.

I've seen a subtler variant of that. Since 2025 winter model improvements, low quality developers can now commit somehow decent stuff more regularly, but as before, they still don't own the solution space independently. LLM output is now larger than what they can envision and cracks will simply happen further away, only to be discovered by someone else later. It's strange everything changes so nothing changes phenomenon.

But sooner or later for AI to reach its true potential we need to have HOTL ie Human Out of the Loop. Meta prompting or using AI to develop the prompt by coaxing it to ask relevant questions , creating specs and going through multiple loops with LLMs - things like this can be a good start towards the final goal. Final means the over abundance of goods and services like the men of the millenium are suggesting us mere mortals will reach one day,. .. and work will be optional.

I think the parallels with AI art are uncanny - nowadays people with zero artistic skill, vision or effort invested are capable of creating stuff that would've previously taken a master artist a solid week of work - doesn't mean any of that is good, but it does mean that the logic of 'if it works and looks good, it's good' is completely broken now.

This is great.

We now need to talk about the 10xBad engineer.

Maybe those engineers that don't care about making their solution _good_ are actually the good engineers, have you ever thought about that??? There are exceptions where quality really matters but most software shops build CRUD web apps where it's not really a good characteristic to obsess over the cleanest and most elegant details, instead you need to get the stuff the customer wants done!

I for one tend to care less about the minutiae of solutions implemented by AI as long as it gets the job done, I do care about architecture and design decisions and correctness and I have ways to steer and verify these when working with LLMs but I couldn't care less about it writing "good" code. Bad engineers also produce better results with AI at least when they're working in established frameworks, AI doesn't really need a lot of high level architecture input when designing or building a web app with a common stack, so as long as you're not working on something that's completely novel I don't think it will make a strong difference.

Maybe designers think the same way about the AI generated web designs I have Claude Code do for me but to be honest I don't care, I just know that before this tool existed it would have taken me weeks or months to come up with a good design and I would have to rely on prefabricated UI libraries and stuff like that or pay a designer tens of thousands of USD to make one for me, now I can get a (for me and my customers) perfectly acceptable and professional design within a few hours. So maybe I'm also a bad designer that amplifies my bad design taste 10x in my company, but the fact is the stuff ships and makes money and the customer is happy! And I can tell you customers or users don't give a shit about how good your code is, they only care if the software works and does what they want!

> The most egregious of these cases for me is often long tenured engineers who have lost interest in the craft, creating a dangerous combination of having enough merit to ship but not enough interest to make what they ship _good_.

i think i fall into this bucket. our "leaders" and executives have told us they dont care about 'shipping good' . we are simply responding to incentives.

"Okay. I'll create a loop and goal so it doesn't stop until it's checked that everything works."

This is where the quality magnification seems to be occurring.

Goal-driven loops can make good code great, or bad code worse.

Ironically, AI mitigates bad developers quite a bit. The architecture/design is coming from above bad devs (in a functional org), and AI tends to write less sloppy code than bad devs, and test/validate it more rigorously.

Great talk

I have found this to some degree (even though I work with amazing people day to day).

It's much easier for people to pump out absolute garbage, you know the kind of "just get it done fast" slop that management types cry out for. And then they wonder why everything end ups broken, not being maintained etc.

And I think the contrast between good and bad code output is much more impactful. Someone can pump out 10x the bad code they used to before, never test it never read through it just push push push baby. And then for good code, sure it's increased my output for slop tasks like repetitive unit tests, but a lot of TLC and review is required for good code and I'd say I've had maybe a 2-3x speed up on a lot of things. But not 10x; you only get that when you don't give a fuck.

I think for senior devs, some of us are legitimately jaded, especially if have been facing the same or boring problems.

I am just tired of typing and looking up syntax for every line of code.

This, however, is a slippery slope, and one has to be mindful of falling into cognitive surrender.

Part of the problem is self confidence bias. Everyone things they're the good engineer, while dunning Krueger would say maybe you are the bad engineer.

Prove who's good and bad.

And you can't really, because there's always tradeoffs you're making as an engineer. The really self confident ones think their tradeoffs win, and maybe they do, though often they don't and these people are just self aggrandizing and stroking their large egos. Are you a better engineer just because you made a big talk and had the confidence to share it with lots of people?

seems a lot of comments below with disdain for "bad" coworkers. every industry has them, but if theyre objectively bad why not get rid of them? surely some periodic review would do that. how did they get hired in the first place? perhaps hiring managers are the "bad" employees.. or managers that let them go on not performing are "bad". or maybe your expectations arent aligned with reality? who knows? the worlds a complicated place.

I'm not sure if it's replacing the middle class of software engineering, but I do feel it's generally true that the static approaches to middle class software engineering are evolving quicker than people are keeping up.

Hopefully when there's bad devs, there's a bit less making a mess where someone doesn't know better and as a result some amount of average or general best practices start happening.

This can be true not just for software development, but making a mess in anything, including a spreadsheet.

What is A&D? Shouldn't it have been defined in your comment?

To everyone complaining about "slop" and "+20000 PRs," what kind of systematic quality assurance, test plans, and tech debt reductions were you doing before the "LLMpocalypse?"

Were you only relying on the difficulty of producing "working" from replacement skill/rate "software engineers" and their level of disinterest being the only real circuit breaker?

My team is currently developing our 3rd product this year where 99% of the code is written by an agent. One thing I've definitely noticed is our problem solving hasn't stopped, it just moved up the stack to the "agent layer".

A big part of this is ensuring that a "bad" engineers can still write solid code and also investing in systems that make it easier for us to review code.

When it comes to writing code, we have this entire library of coding standards that we've moved from one project to another. It describes, sometimes in excruciating detail, exactly how we want our code structured, antipatterns, best practices, etc.

On the review side we have invested equally into skills that split up code into readable chunks, take screenshots of any UI changes for quick validation, and a whole battery of tests to ensure that we're not generating slop.

If you were to look at just our development process, you would conclude that we're very lazy engineers. We seldom write code by hand, we seldom ask for corrections and our reviews are more of a cursory look at the PR rather than a deep review.

But the real work is not in the "development layer", it's now in the "agent layer". Making sure the agent knows how to write solid code so we don't need to write code by hand, making sure it doesn't make dumb mistakes so we don't have to correct it, and structuring our review process in such a way where an engineer only has to take a cursory look at the code.

The key difference we noticed between the "old way" and the "new way" is the "new way" is way more scalable and we're able to move way faster than we ever could before.