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.

> 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.

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.

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.

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.

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 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!

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

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

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?

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.

Bruh..I haven't consistently sat at my computer for even a hour at a time to code for a decade..people spend that much time in Claude??

Although, I don’t think immigration or country of origin is particularly relevant here. I never worked in the US but there are plenty of "assembly line" developers here in London too.

If your job is essentially taking a ticket and turning it into code without contributing much else, then yes, I think that category of developer is going to be decimated.

That applies equally to everyone.

I'm not working at massive scale. I've not built any public-facing projects from scratch. But I have done years-worth of cleanup and improvement on projects that I'm very familiar with and have been in my backlog. It's not 100% success, but it's better than I could have done on my own, in the last few months anyway.

You are still an engineer but you’ve delegated your technical judgement to an LLM. You just stopped doing the most important part of your engineering job.

> Fixing it would require such a colossal amount of work that it would be impossible to even start justifying it to anyone in management. > And what are you even thinking about? It would end up in the exact same state again in just a few months anyway.

The management side of this probably deserves a whole post of its own. There’s only so far I can take each tangent before the original post becomes too long for anyone to finish.

You still have to understand the change yourself if you’re going to take responsibility for approving it.

That work is fundamentally much slower than generating the code, even with the help of AI.

We’ve made producing a large change extremely cheap and fast. We haven’t found an equivalent shortcut for building a correct mental model of what that change does, how it interacts with the rest of the system and whether the decisions behind it are actually sound.

Maybe one day we'll find one. As of today, I don’t think we have.

I always joke with my wife and invoke a line from this [1] Art Bell episode "the disasters that are coming..."

People really don't seem to consider that our civilization is remarkably fragile and dependent on humans. Any given system can just fail at a moment's notice and you need people around who know how not to panic and what to do.

We seem to be adamant at disproving this reality for some weird reason (money, duh), but life isn't going to be fun when a large portion of the population needs a chat bot to do any form of work. And it's worth asking: what population will be left if we submit all of our faculties to LLMs? My guess is one that's either limited in size or practically inert.

An outright idiocracy doesn't have to happen, but we sure as hell seem to be speed-running our way there. It's actually worth watching Idiocracy and Wall-E and just contemplating "do I really want to live in this world?" Because, at least right now, we're charting course directly toward that.

[1] https://www.youtube.com/watch?v=gkPHMEvp-Tk

We still teach arithmetic and algebra despite computers being vastly better at calculation. We teach spelling, grammar and essay writing. We even teach history and geography while everyone permanently has a device in their pocket that can look up almost any fact in seconds.

How else would you be developing the mental models required to understand, question and verify anything?

See "AI Won't Take Your Job, Someone Using AI Will" > There's no lucrative middle ground where 'AI whispering' is a high-value skill.

https://blog.florianherrengt.com/vibe-coder-career-path.html

AI massively increases the speed and scale at which bad engineers can do damage while fixing it is still slow, difficult work.

>What tends to happen is that the EMs and PMs look at who’s free and give that person the task.

The gp you replied to qualified it with "enterprise software" (LOB, CRUD, etc aka "cost center") so your observations where senior -vs- junior engineers being more fungible can be true.

However, in "engineering" type of software products (game engines, RDBMS engines, operating systems, etc) where the software is more often a "product" that's sold (aka profit center) ... there are definitely different layers of complexity where senior and junior engineers are not fungible at all.

One way to describe the differences of complexity and criticality in various parts of the source tree is the "core" parts vs the "leaf" parts. E.g. in a game engine or Linux kernel, the deep parts of the engine or os process scheduler where the tight loops are located are the "core" parts. They most likely would be worked on by the most senior people.

But the game engine may have some less complex code for handling text width on a menu for different foreign languages. Or the os needs a new menu option on the installer to ask for the users age. Those would be more "leaf" functionality in the source tree. A junior could get assigned to those parts with less risk. After a few years of experience, he might be trusted enough to work on the deep "core" logic without screwing things up in catastrophic ways for a million customers.

A product with several million lines of source code will invariably have both the "hard parts" and "easy parts" so the new hires and juniors will work on the easier stuff first.

There's also a spectrum of hard-to-easy in enterprise software but it's much more narrow than engineering code bases.

Unfortunately, looking back, I could easily see Claude replacing 3 out of 4 of those developers. Myself + one other dev + AI would probably would've shipped a bit more a little faster. With that said tokens aren't free so the net cost savings would've been 2 dev salaries maximum.

Sure you might lean more on Google or SO if it's something you haven't seen before, or it's something deep in a stack that isn't code you actually wrote. But as the noob eventually learns when he thinks he's found a bug in a runtime or compiler that thousands of other people are using every day: No. It's probably your code.

I suppose there are people who never advanced beyond the "type (or copy/paste); run; google the errors" loop, but I've never seen anyone with more than a year or two of experience doing that very often.

I worked in a company where this happened, and it wasn't pretty. Product managers used their experience and seniority to intimidate junior engineers and exert control over project management of engineering projects, which they predictably used to move as much work as possible to post-launch, including testing and security. They also gaslit junior engineers into agreeing that issues with contradictory or impossible product asks could be figured out later, leading to software getting released to customers that fundamentally could not be made reliable, performant, or even secure.

Even after the entire company went on site visits where customers told us they weren't using any of the features released in the last year because they were all buggy, and the only information they wanted about upcoming releases was assurance that their use cases wouldn't be impacted, product still kept claiming that the time it took to release new features was the biggest problem facing the company and kept fighting back against engineers who said we were in a quality crisis and desperately needed to make time for better testing and design.

The only thing that can shield you is good engineering management. Weak management will end up getting rolled by product and start promoting the bad behavior that product insists on. At that company I had a boss whose attitude towards us was "engineers in a startup should make decisions independently and stand by their work" but made sure engineers felt unsafe making engineering decisions that product wasn't happy with, likely because they felt unsafe themselves.

I would have said the same thing for the first 15 years of my career across several jobs and acquisitions.

Then I took a job at a company that fit this description. They had so many managers and PMs that every task was talked about, broken down, and documented so much that every Jira ticket was a little piece of work that a junior could handle by Googling things.

The quirk was that they had started hiring a lot of experienced and staff level engineers, too, but then tried to force this same framework on to everyone. We spent more time discussing tasks than doing them by a factor of 2-50X. There are some situations where this is appropriate, but none of our work was actually high scale or difficult. Your day might be spent writing design docs and collective sign offs as you worked through committees until the tickets at the end were so simple that any junior could do them.

It didn’t lead to better software. It was one big cargo cult game of performative management. A frequent outcome was that someone would get into the micromanaged tickets and realize there was a better way to handle something, but it wasn’t worth doing all of the fighting and meetings involved to do the meeting and Jira ticket dance all over again.

Same but with 10 years, and I don't think I would do well in a place like that. That removes you from writing code and there is a similar complaint about relying too much on AI and not writing enough code on your own.

I've seen a twist - not juniors but just offshore engineers.

Primarily in Silicon Valley or outside of it?

I worked most of my two decades in the Valley but also spent time outside of it. There is in many cases a vast gulf between the dev cultures. What the parent comment is describing I've seen many many times.

I’ve worked with two junior devs recently who are very good precisely because they’re trying to understand what they’re doing, rather than just producing code.

I’ve also worked with senior devs who basically gave up and stopped trying to understand the code. They became much worse engineers as a result. At this point I would much rather work with those 2 juniors.

They use it to explore things they don’t understand, ask me questions to clarify their reasoning, double-check assumptions. They generally use the tools available to increase their understanding.

Those people are doomed. Which is fine in a lot of ways, but will be devastating for their economic prospects.

I’m convinced the only reason there’s a Fortran crisis is because nobody wants to work on Fortran or make a career out of it.

Has nothing to do with willingness to hire juniors. Good luck finding promising juniors who survey their career opportunities and decide that Fortran is a good technology for building their resume.

Think about all the open source the world got from some random person in Finland or Sicily or wherever hacking on a cool idea. Will that still happen with a high (for someone who is not employed... maybe a student) monthly cost?

We keep hearing this, but where is the Photoshop killer written by a gas station attendant? Where is the PayPal alternative written by a retired nurse?

Over and over we're told that software is now trivial to write, and Claude is evidently writing some billions of lines of code a day, but where are the results? Where is the vibe coded app toppling the legacy hand-coded monster product from 20 years ago?

There are around 100k U.S CS graduates . You're telling me 100k H1-Bs don't make any impact on them?

I was very fortunate to get a job in a NOC a little bit after high school where I learned things one'd expect to learn in an entry level job. The team I worked on was all about mentorship, learning, and building people to the next level.

Haven't seen that attitude elsewhere in my entire career except in the non-profit world where I reside these days. It blows me away that people are surprised that these industries have failed to build entry level positions.