This part of the article hits home for me. With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization. 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 am still a firm believer in garbage in -> garbage out, AI is only as good as the abstractions and contracts you put in place for it. I don't subscribe to the idea that AI generated code is fundamentally bad, just that people lack the right skills today to wrangle agents into writing good code.
Earlier in the year I put together a talk for my company on what the future of architecture & design means for us in the career, I'm very proud of it and will share here in case folks have their own thoughts to share on the topic: https://youtu.be/SIZrt9Rt05Q?si=W57eirniWmoSFeBu
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.
But how many of those bootcamp people actually went on to get software jobs? One of the big criticisms of that whole phenomenon that I recall is that people were graduating them and then were unable or unprepared to actually get a job in the industry?
So how many people "learned to code" and then ended up back on non-software related careers?
The whole "learn to code" and software bootcamp craze always baffled me. Like what other profession markets themselves as "Hey, our job is so easy that any schmuck off the street can enter the career with 4 months of training." Practically every other job I can think of at a similar salary level has entrance requirements (e.g. grad school admissions exams), extensive and expensive training, a lengthy apprenticeship period and follow on licensure exams.
And more directly, I believe good software engineering is really hard. I think it takes a certain mindset to begin with that many people just do not and will never possess, and it takes years of experience to get a good sense of what works and what doesn't, especially with respect to the entire relationship between code, business, people and teams. Yet we constantly see all this devaluation of the practice of software engineering ("code was always the easy part" - bull-fucking-shit), often times by our own practitioners of the craft.
I mean, the obvious thing is that the "learn to code quick, code bootcamps!" drive was driven by connected people who were, as they are now, attempting to drive down the cost of software development.
Management types really really really loathe software developers for making good money, and have spent decades now jumping at any advertisement that suggests it can undercut the salary of your current crop of engineers.
Devaluing software developers has always been the point. Whether you take the cynical view of "They resent us for being expensive" or the apathetic view of "Capitalism simply wants to eliminate any and every cost by definition"
> Call me a gatekeeper if you want but, we ended up with a lot of people that just can't do the job.
Increasingly I am of the opinion that software engineering aught to be a licensed profession, similar to civil engineers, medical professionals, or lawyers. A board of peers to hold you accountable and a license that can be revoked at any time. Additionally legislation could be written to require such licensed individuals in safety critical roles.
I suspect the debate around AI assistance tools would be quite different if there was greater accountability for programmers and a constant threat of losing a license.
If you brick millions of machines impacting hospitals and airports, you should probably never be trusted to write code again.
> software engineering aught to be a licensed profession
Only in certain industries, where outcomes can hurt people in any way. There's opportunity to engineer software in just about every industry, but I don't think a widget vendor that wants to connect to a WMS should be compelled to hire licensed anything. Of course, licensed engineers should cost more too.
In my previous job the entire DevOps team were terminators from the gym. I don't know when or how they were attracted to software, and why. There's so many other jobs they could spend time on and be successful rather than writing yamls.
Or it’s just the largely self-taught intrinsically curious autodidact developers and engineers have always been 10x and the “average” person in it for the paycheck is really what a 1xer has always actually been.
I think the industry highly skewed towards the former back in the 90s (and earlier!) when I first entered it. There certainly were vast differences between the best and the worst, but nothing like the gigantic gulf there is today between say a competent kernel driver developer who can get code mainstreamed into Linux vs. a boot camp style disinterested frontend dev who leet coded and brute forced themselves into a FAANG job.
Working closely with other white collar “generic” jobs and the folks who just show up each day and are not interested in the fundamentals at all make me believe this is kind of the baseline for most industries.
Most folks are in it for the money and are happy to just be good enough to not be fired. Since most middle management is utterly incompetent at performance management the results tend to not be great for pretty much the entire corporate white collar industries. A stellar manager though really stands out in such situations, but they are so rare many won’t work for or with one their entire career.
I also have a suspicion that people’s microdistributions of talents is underappreciated. Some people are good architects and average at algorithms. Some people are unusually good at debugging or QA. Some can spin out whole systems at an impressive speed that may not be a great long term fit for the larger system.
And most businesses aren’t managed in a way that’s interested in adapting to the microshapes of personnel.
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.
When I worked at a particular fruit company in Cupertino, my boss had been asked repeatedly by the developer teams to provide a tour of the data center we'd recently finished building out, which housed the servers their code ran on.
He gave them a lengthy, grueling, hyper-detailed tour of the entire facility, encompassing the HVAC systems, electrical systems, network and computing systems, finishing with about 20 minutes where he had them stand inside a hot aisle that he was just outside of, giving a fantastic soliloquy on the importance of code efficiency, and the consequences of ignoring it. It was hilarious to watch from the comfort of the cold aisle, knowing full well what he was doing.
The scale of a cloud datacenter is pretty awesome to witness. I had the opportunity to visit a large cloud company’s data center years ago, it was immense in scale and (mostly) very well thought out.
Busy servers generate more heat. Inefficient code makes servers busier. There’s a real physical outcome for bad performance code at scale.
But you don’t really want lots of idle or underused servers, aside from burst capacity management. So if they universally and consistently wrote more efficient code I’d expect a smaller datacenter. Full of still busy servers but just less of them.
He was showing how complex and expensive a data center is and giving them real-world visceral experience that inefficient code has real-world implications.
Exactly. For most of my career, bad engineers (or juniors who were earnestly learning) would struggle to even create output that compiled, let alone ran. And it would take them a long time to implement something poorly. So the blast radius from their incompetence would be limited. Today, a bad engineer can churn out ten thousand lines of garbage that actually compiles and runs, before my first cup of coffee. If not on a tight leash, they'll sink the whole codebase or inundate every senior person with garbage code review requests. The blast radius is unlimited!
> Today, a bad engineer can churn out ten thousand lines of garbage that actually compiles and runs, before my first cup of coffee. If not on a tight leash, they'll sink the whole codebase or inundate every senior person with garbage code review requests. The blast radius is unlimited!
The term for that is "10x AI engineer." Anyone who has anything negative to say about such people is just jealous of their insane productivity and speed.
The supposed “10x engineer” may simply be someone stealing productivity from everyone around them.
You measure the output of one person while ignoring the cost they impose on their team.
If I generate 10 PRs in a day but three engineers now have to spend the next two days reviewing them, figuring out what I changed, correcting bad assumptions, debugging regressions and explaining why half of it needs to be redone, I haven’t become 10x more productive. I’ve just moved the work onto other people.
Worse, I’m consuming the time of the people who are usually the hardest to replace and whose attention is already scarce.
That’s why PR count, lines changed or features “completed” are terrible measures of productivity. You can make your own numbers look incredible while reducing the throughput of the entire team.
FYI, your comment showed up as [dead] like you were banned until I vouched for it, but I don't see any reason for that. Just thought I'd let you know in case you want to follow up.
> You can make your own numbers look incredible while reducing the throughput of the entire team.
Taken how some companies award promotions and bonus this is actually a double win. You not only improve your own numbers but also make this of your competition worse! /s
Sadly AI also amplifies both the good and the bad managers and tech leads. If you have managers who fail to set a clear direction or tech leads who fail to define a good framework for developers to operate within then AI just means the poorly directed developer effort goes further in the wrong direction faster. Meanwhile teams with well-specified goals and better structure and processes can exploit the benefits of AI tools much more effectively.
In the before times, a small dedicated team could hold back against bad engineering culture and intentional enshittification. Now the balance has changed.
> 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.
Sometimes this can be a death by a thousand cuts. Any individual change may not impact performance to a noticeable degree but when they're pumping out a 10x increase in commits it can be a slow decline.
Just look at how they're merging ~300 commits a week into bun.
That really sounds like the kind of people who will complain in university about being forced to study calculus.
Natural consequence: Then they never grasped the concept of computational complexity.
O(n) Vs O(n²)? They have n, what's the difference? Python is fast enough. The only thing that matters is shipping features fast! Features! Our competitor will have this next week, we need to write code fast, everything else is a matter of adding more compute, which we will pay with revenue!
As a side note; There is plenty of useful math that many people need (or would benefit from) in the real world. Much math curricula is arguably poorly aligned to needs, as it emerged from various historical flukes of design-by-committee. Popular math curricula is not perfect by any means. I recommend looking at high school or college textbooks and considering whether it is well prioritized.
The missing part of mathematics education, IMO, would be to focus more into developing the intuition of what something means, instead of the current focus on getting some (numeric) results.
You don’t learn Big-O in Calculus because it requires CS algorithmic concepts.
But the core question of “how does this behave as N -> \infty?” is asymptotic behavior (ie: limits) which were developed for calculus and are very much part of the foundational calculus canon.
The actual issue is not the "bad" engineers but the bad organization. While people are allowed to push and merge whatever crap is generated there is no point to do otherwise. Even if you do care about performance, "good" code your teammates don't and close more tickets and are better by many metrics.
If you are closing one ticket per week with "good" code but your teammate does three with "bad" code - it's actually you are a bad employee. Also they may say you are a toxic one.
A hackathon for performance improvement screams to me "you'll be re-interviewing for your own job." I don't foresee this going well for the company. Best case scenario: you wildfire churn all the chaff engineers which limits the company's throughput until they're rehired... with no expectation the new hires will be any better. You also lose A LOT of domain experience and are self-inflicting brain drain.
I'd try and push for some "lunch and learn" meeting where the engineers get lunch catered and in exchange sit in on a meeting where you explain your point of view. Without monetary incentive it'll be hard to change the culture, but not impossible (and food goes a long way in greasing the wheels).
If your company has sketchy process and minimal checks on the software quality, of course it naturally follows that they hire bad engineers as well. fortunately, that also opens up an opportunity to be a emergency leader with an eye towards promotion.
> If your company has sketchy process and minimal checks on the software quality, of course it naturally follows that they hire bad engineers as well. fortunately, that also opens up an opportunity to be a emergency leader with an eye towards promotion.
AI disease is encouraging "sketchy process and minimal checks on the software quality." QA has been eliminated from my team, and the QA engineers that are left have been declared to be developers now.
Gotta move fast, and I guess making sure the stuff we ship works was "slowing us down."
> a emergency leader with an eye towards promotion
i've gone this route a few times in my career, it's very stressful and involves angry/panicked people and many all nighters. Also, the glory fades fast. would not recommend.
The bigger issue (I find) is that the pipeline for finding those engineers is completely fucked.
Hiring pipelines that tested the wrong thing have existed for years but the problem is magnified 10x when you test for something that weakly correlates with ability at best which an AI can do better than a human.
This is leading to stuff like incompetent junior-level engineers being hired as principals.
My company's hiring process is basically: Can you code a product quickly with AI? Can you understand the generated code?
That's basically it. It is surprising hard to find people that can do both, but engineers are becoming much, much better at the first gate while flaming out on the second.
Do you have SLO/SLAs defined? Are you monitoring performance? CPU usage? Cost increases?
You should have plenty of data to review regularly and push back on any teams that are causing problems. That's a process problem and you need a process for it.
Trace the increase back to specific deployments, call out those teams, and make them fix their shit.
Yes to all, but it's just me responsible for monitoring performance/cost. I either push back or fix it myself, but I am behind. So this is an attempt to give/push more ownership to the teams.
The handling of backpressure is such a good example to distinguish bad from good engineering. A good implementation even presents all the typical "clean" code indicators: DRY, KISS etc.
My company got rid of line management. I now report to a director with over 20 reports and barely any time for career development. Our performance reviews are AI generated and we’re losing engineers. The industry has gone completely insane.
Startups have limited resources, we prioritize the best we can. As a staff engineer it's my responsibility to bring this to my company, but it's not an overnight process.
why wouldn't you use those limited resources to test things before they go to production, instead of creating more crappy things that go to production?
> 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.
> With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.
I think the real pain though is that AI also often removes the feedback loop between "good" engineers and "bad" engineers. A lot of "good" engineers started as "bad" engineers that learned, sometimes the hard way and sometimes with patient mentorship, how to be better engineers. Patient mentorship becomes harder as code reviews become less personal. "The Hard Way" becomes harder when the consequences get divorced from actions. For a bad engineer it becomes "Claude broke Production" more often than "I broke Production" and learning mostly ceases.
We're starting to recognize how many junior developers AI is replacing, making the pipeline to senior developers harder (if not disappearing), but we also maybe aren't focusing enough on how much we are also losing the pipeline from "bad" to "good" engineers.
> 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.
I agree. Why is everyone so hard on everyone else? Look at the outages Anthropic and OpenAI have had. They aren't hiring stupid people but they can't seem to go a week without major platform instability. And you can't even argue that it's because of high load because all of these engineers have worked at Facebook, Meta, etc. They are seasoned veterans that should be able to build resilient systems.
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?
>> Egotistically, I don't even mind, it's just the salary hit that would be the main issue.
This is whare I am right now. Even senior positions have dropped 50-60K in range so I've effectively priced myself out of a lateral move because I would be taking a massive hit in salary for the same role I'm doing now. I'm currently at a company that continues to lay people off in lieu of offshore talent and AI. I'm stuck in a weird state of purgatory.
>> Should I just apply for a managerial role and in the cover letter state management is my intended path for growth?
I know many of my friends in senior dev roles have put their resume in Claude and said they were interested in moving into a management role and had Claude revamp their resume into something that was more management focused. Three of them were hired quite quickly not only based on their dev backgrounds with mentoring, training and light management of junior devs, but having enough emerging AI skills they said helped them close the deal.
Interesting. Thanks for that last anecdote. I feel you on the weird state of purgatory. I'm confident we'll find a path forward, though. Gotta keep your head up
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.
> 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.
The easiest way is to actually review the prompt input, put it through a LLM to catch the typical missing steps and automatically forward the result as review comment to the MR.
> 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.
A good engineer, without LLM assistance, will still produce great stuff.
Yes, but much more slowly. And if they realize halfway through implementation that there is a better way to do it, but they are under pressure to deliver, they wont have time to rewrite it and will live with the consequences of that decision forever
> And if they realize halfway through implementation that there is a better way to do it, but they are under pressure to deliver, they wont have time to rewrite it and will live with the consequences of that decision forever
I've never really seen that. What I've seen is the much pragmatic take of marking the source code with a few comments to highlight the problematic areas and then goes on with the implementation. Refactoring can always be done later when the first batch of value has been extracted.
There's always tradeoffs to balance and perfection is something you inch towards, not something you get done in one go.
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.
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.
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.
In retrospect, the golden age was the pre-internet era. Some rose-colored glasses maybe, but as I remember it:
Paying for software was the norm, so it was more clear what the "product" was, and software writers had a direct incentive to write better software.
Updates could not be pushed out so you had to be pretty sure your code worked before you shipped it. Having to ship physical media to all your customers for a bug fix was very expensive. Any new release was a big deal, so you had to put some real thought into what features it should contain.
Significant amounts of your development time were not spent trying to work around browser bugs, or differences in browsers, or supporting random old browsers that your customers still use for <reasons>.
Stack churn was much slower. The feeling of constantly trying to keep up with a treadmill was much less.
Users, while often not technology experts, were a much more competent slice of people than the general public who showed up when they got internet service and a computer at home.
The only ads were in print in trade magazines or publications like Computer Shopper. Yes, people actually used to buy a magazine that was nothing but ads.
You're right about those things, but you're forgetting that we had no source control, and almost all software was closed source. You took what you were given and you liked it, and you developed strong attachments to particular versions of software which you clung to well beyond its use-by date (like Python 2.7). MS-DOS 3.3 forever!
In the 80s, source control was like networking. Yes some orgs had it (mostly academia) but the rest of us just had a precious floppy that we copied the known-good source onto.
Going to CompUSA and looking at the back of the box for not only video games, but spreadsheet and translation software, too; was awesome. As a kid I always wondered about the adults who needed such software as the back of the Deus Ex or Shogun Total War boxes captured my imagination.
Since it sounds like you built software during that era, thanks. Thanks for the memories.
I also consider myself a fairly good pragmatic software engineer. I have led small (3 engineers), medium (15), and large (100+) teams.
To me, the best time was late 90s, early 2000s. We had a lot of autonomy. People would just trusted that we knew what and how to build it. I could focus on building a great product. Overtime, we lost control, to the point that we now work based on jira tickets made by managers or product owners with one tenth of the experience that we have.
I definitely hear about segments of the industry being like that, but FAANG and adjacent generally isn't. Engineers are expected to display ownership of a problem space (scope depending on seniority), navigate ambiguity, and manage their own time.
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.
> 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.
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.
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!
Totally agree with your framing here, but that is also what I fundamentally consider "good" code -- it's code that solves the problem that your customers/business needs without making it _harder_ to solve the next problem.
There are valid situations where the best code you can write is code you never look at and throw out the next month; there are equally valid situations where the best code is well thought through and reasoned abstractions for an area you expect to become core to the business in the near future.
Thanks for the wording on your first sentence there. I've been trying to figure out a way to get that thought expressed succinctly.
I think with AI coding, what we call "good" code changes. Lots of abstractions really only exist to help load the context into the human brain so that they can solve the next problem. If an agent can just search and find all the places to make a change, or to duplicate code with small changes for the next problem, is that bad? Does is just feel bad because that's not what we're used to?
We use structured looping instead of gotos because that makes sense to us, but the compiler still turns it into jumps in assembly. If our interaction is now at a higher layer, do we need good "code" or do we just need good "architecture"?
I don't know, but it's just something I've been thinking about lately.
Using context always means there's less for something else, whether you're a human or a machine. Abstractions that localize reasoning and help load the context into a human brain are ideal for machines and humans alike.
I tend to find that this perspective comes from people working on relatively small or isolated projects.
On a large system, the customer being happy today isn’t enough. You need other engineers to be able to understand the system.
Have you ever been on call and been woken up in the middle of the night to fix a production incident in a system you didn’t write?
If everything you build is small, isolated and easy to replace (basically fire-and-forget), then yeah... who cares? Ship the ugly thing, get paid and move on.
If you’re going to be working on something for the next 5+ years, you should definitely spend some time thinking about what you’re doing.
This is a great point. I find myself in the middle, where I appreciate and look up to past coworkers who were way better than me at attention-to-detail, but I have a tendency to focus on delivering actual results quickly with maintainable and easy to read code. A lot of engineering teams go into their own world on adhering to best practices with no eye on inefficiencies in the process that causes days of delay because it makes them feel better. I definitely believe in shift-left (findings bugs early saves a lot more time than finding them in production). I believe in balancing fast delivery with quality/process.
In my experience, those that can’t understand design in the small (code level) don’t understand it in the large (sw or systems architecture) either.
Doing the right thing for the customer is independent from good design and good code. It’s a problem of requirements and project management.
This is an excuse some poor programmers use, that they can’t write good code, but at least they fulfilled the customer requirements :D
> 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.
They’ll care when nothing works, nobody seems able to fix it, building new features takes forever and every change breaks something somewhere else.
This was already happening before. But now, a lot more companies that previously might have taken many years to reach an unmaintainable state can now get there in just a few months.
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.
I don't agree here. Yes Claude is great at following patterns, and for very standard tasks (e.g. "add this HTTP handler" which can copy existing patterns for database transaction management, session management, authentication, etc etc) it does great! The problem is that when you do something that doesn't quite fit int an existing pattern, Claude will optimize for solving the task at hand, producing code that doesn't use a sensible architecture. Doing things like checking user credentials or establishing a database connection deep in domain logic.
If you're a good dev, you can totally prompt Claude to not do this and correct itself, that's not an issue. The issue is that bad devs won't even notice this is happening in the first place.
Strong disagree. A lot of AI development still requires good engineers to keep tight leash on it so I'm seeing more bad developers create a feature until we need to iterate on said feature and we find AI did such a bad job that it becomes extremely difficult to do so.
A bad developer with any current frontier model will happily produce syntactically correct code that is unreadable, in a spaghetti architecture, and write an elaborate test suite that tests all of the wrong things.
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.
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.
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?
The difficulty of producing code WAS one of the circuit breakers.
We had tests, CI, code review, QA, architectural reviews, etc. None of those disappeared. But they were designed for a world where producing such a large amount of change was impossible.
Tests don’t solve that. Tests can tell you that the behaviours you thought to test still work.
How many times have you had a completely green CI with 100% coverage and still shipped a bug?
Trust actually does work that way though, the implicit and collective fuzzy agreement of “having my name on it”. Of course that ambiguity needs enforced automated checks, but reputation and one’s own integrity is not for nothing.
Generative AI breaks that agreement. It took me over a year to realize my previous CTO actually didn’t care too much about the system design he shipped . And the expectation was actually to just throw it away, have AI reimplement “what wasn’t working”. Use AI to ship, AI to learn what shipped, and AI to fix what shipped.
I quit because of it. Hell is working on other people’s AI code.
We had a dedicated QA team and an extensive test base... which we fired to reduce headcount, and we've trimmed back because we don't have the hardware resources to run those tests sufficiently expeditiously.
Secondarily, the business itself is also driving the throughput increases by demanding more volume, but there is no accountability to them for asking for throughput at the expense of quality. They may also deny the engineering time to work on things that would stabilize quality that supports faster delivery because features earn money more directly than developing quality processes.
This isn't coming solely from engineers wanting to produce more stuff faster.
Quality assurance and test plans don't catch slop. They just test your code. It can't prove the absence of bugs.
In general, the way we still do it is: some basic static analysis finding anti-patterns, but the meat of it is, and always will be, code review. Except you can't review code at the pace AI generates it.
Where I work someone is still responsible for the output. We expect developers to examine the code the LLM produces before burdening someone else with it.
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.
What you’ve described solves a different problem. You’ve put a lot of effort into making sure generated code conforms to your standards. That’s all good.
But do the people still understand what the system is doing and why?
You can have code that perfectly follows every standard and passes every test while gradually building a system nobody has a mental model of.
> an engineer only has to take a cursory look at the code
If that means you’ve automated away checking syntax and implementation, great. But we already had that before. If it means nobody needs to understand the change anymore, then this is exactly the risk I'm talking about in the article.
I think of it more as "the automation of the stackoverflow engineer". In enterprise software, there has always just been a non-negotiable large volume of code that was required to be written. This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code and punch every hiccup into google along the way. This hand off is no longer necessary as that same senior can just kick off an agent and have it handle the implementation for them.
I've heard some refer to this as a "nature is healing" scenario for the industry where if you only signed up for a high paycheck and didn't care to think critically about any of the work you're doing then this will be painful because that previously manual process has been automated. The floor of what's necessary to be considered valuable has been raised.
>This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code and punch every hiccup into google along the way.
This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
What tends to happen is that the EMs and PMs look at who’s free and give that person the task. This means that sometimes you get a senior leading a simple project and sometimes you get a junior leading/designing a complex project (usually with help from a very minorly technical PM).
Then the senior/staff/principal (often on a different “special” team) gets pulled in at the last minute to rescue the project.
If your company is highly product driven, you’ll often find that the juniors end up leaving projects more often than not because they will tell the PM exactly what they want to hear.
>This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
>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.
> There's also a spectrum of hard-to-easy in enterprise software but it's much more narrow than engineering code bases.
I'm not going to bang this drum too much, because it's been done to death for well over a decade, but lines-of-business supported by CRUD apps are rarely simple from an engineering perspective. Much of that engineering is in the decisions made outside the codebase, or spread across multiple codebases. If you're looking for the one obviously brilliant line of code to tip your fedora to while sipping your snifter of wine, you're not gonna find it. In fact, "clever" code like that is rightfully and instantly rejected as cowboy code.
By your reasoning, civil engineering isn't "real" engineering like aerospace cuz they don't build things that go really really fast and shoot out fire and stuff. Also, there's like too many responsibilities delegated out. Like, man, I only wanna talk to the guys who put the rockets on the thing. Everyone else are just overpaid slackers that smooth talked their way! They're gonna get replaced by AI! Mark my words!
>, but lines-of-business supported by CRUD apps are rarely simple from an engineering perspective.
You misread my comment as some dig at CRUD LOB enterprise coders. I used to work on enterprise ERP code with 20000+ tables. Yes, I agree it definitely wasn't simple.
Instead, I was responding to a very specific observation the gp made: he saw that both senior and junior devs were interchangeable when randomly assigning the next JIRA ticket.
That can only happen in a situation where the JIRA tickets are similar enough in complexity that the difference in skills between your senior and junior devs are irrelevant when the work is assigned.
Maybe some enterprise software teams can work like that. However, none of the engineering-heavy type of codebases can treat seniors and juniors interchangeably.
All engineers should be spending more time "planning" than "doing".
Even before LLMs, the coding tasks were less than 50% of the time spent on all my Jira boards in the past 15 years. It makes perfect sense that they are assigned based on available capacity. By the time the coding begins, it's already too late to worry about implementation.
You're right that small tasks are trivial enough to be assigned to anyone. That's the point. That's how it feels to work on the "good" projects regardless of complexity. Planning a complex project should result in more tasks, not harder tasks. Your epics and stories can vary in points, but your tasks should not. You want to keep them as low as you can with the time you have to plan.
If assigning to a senior produces better code, you're not spending enough time planning ahead.
> 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.
That's great and all, but that's a small minority of all software written. I'd love to work on projects like that but ultimately I have to pay the bills. Many software engineers are in the same boat I am.
Now I guess I'm just up shit creek because I built a career on SAAS work that was available instead of holding out hope I could get in at my dream job working on game engines or some other non-SAAS product?
Sorry if I sound bitter. I'm variations tired of hearing variations "If you only worked in SAAS you were always close to meaningless and now we've automated you so you don't deserve to earn anything anymore". Feels like every day.
Nor have I seen this "punch every hiccup into google" approach. Most errors are things that (a) you've seen before if you have any significant experience and (b) have a pretty obvious cause if you simply read the error message and look at your code.
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'm more likely to have several tabs of the libraries/language docs open than opening Google. And when I do, it would be just a faster way to get to the docs. After a while in a project, my history and bookmarks list is much more useful than a web engine. If it goes into months and years, it's mostly tweaking the code to solve some bugs, meaning a lot of reading of source code.
Oh I'd say its real. Years ago I worked as that senior who divvied up the work to a team of 4 mid-level engineers in that exact fashion (they were mostly Latin American contractors with limited english). We actually shipped some good stuff too!
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.
I'm there now. I have a team of low level engineers in Hyderabad and Bengaluru which can be useful but I have to spend a lot of time writing very detailed specifications and instructions to walk them through what has to be done. There are plenty of instances I can point to where it would have been faster for me to implement the solution myself, by hand, no Claude. Now bring Claude into the mix and I do not really have any use for these engineers at all aside from providing operational support during IST.
We're not too much an AI-friendly company yet, so we don't officially have Claude access, but I can tell with certainty that several of my Indian teammates are using Claude anyway. I'm pretty familiar with the style of code it creates. And the comments are decidedly better English, which is a big giveaway itself.
> This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
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.
>This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
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.
> If your company is highly product driven, you’ll often find that the juniors end up lea[d]ing projects more often than not because they will tell the PM exactly what they want to hear
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 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.
While the picture painted here is viceral... I think the reality is closer to this..
Before AI, most big software was desgined and originally writen by a few key (founder-esq) architects. But they can only add functionality at human speed, so the team grows, and the quality of engineer drops as the functionality footprint grows. Eventually the functionality is much bigger, but most of it was written by a much lower quality engineer, and thus the code (even if functionally correct) is less efficient and less clean, and the big refactors a talented architect would have done never happened, so it just got bigger and bigger and more unweildy and bug prone and inflexible - until some new talented architects see the waste and build a startup to displace it.
With AI, big software can be entirely written by 1-3 people, plus alot of agent usage. Which means it can be refactored more, and the design kept cleaner. But this only happens if those senior architects are actually paying attention and controlling the design. If the agents are heavily automated and subtasaking and controlling the design, then nothing much changed, because the agents themselves are no better than the "stackoverflow engineer".
Again, this ignores the second order effect of entirely gutting the personnel pipeline that is required to create new senior devs...
So without a training pipeline to provide experience to jr. Devs, in 15 years we will be hurting for senior devs to replace all the graybeards. Kind of like the fortran crisis of the last decade or so.... Just across an entire industry that supports every other industry....
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.
It's true that developing junior devs is challenging (but it always was), but that's not what this is about: This is about the kind of not-that-good, mid-ass programmers who make up the silent bulk of the industry. The ones who have 20 years of experience, but who you still wouldn't trust to write fizzbuzz.
Those people are doomed. Which is fine in a lot of ways, but will be devastating for their economic prospects.
Yeah. Technology and social change has done this all over the economy. E.g. from my dad's field, there's not enough public health people with field experience to replace the folks who are retiring. We have plenty of entry level people who can't get a job, but then there's a gaping hole in the pipeline between them and the graybeards who are retiring.
also who knows if prolonged ai development for years actually doesn't atrophy your coding muscles so to speak such that you are fully reliant on ai programming to get things done
by then we'll have an mfc, instead of trying to get llms to write code our prompts will compile and execute efficiently. after that inversion "programming" becomes "using language to describe some processing" it's just writing. knowing a computer language of old helps but not necessarily
> Kind of like the fortran crisis of the last decade or so....
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.
> 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.
Most jobs involving Fortran I see are not looking for a programmer, software developer, etc. They're looking for a PhD scientist in whatever scientific/engineering domain they're in who can work on Fortran code. They almost exclusively want domain experts, excluding most juniors anyway.
Pay them and they will. The problem with many people bemoaning the lack of Fortran and COBOL developers is that they are not willing to admit that the code they "need" to maintain isn't actually valuable enough to be worth paying what that maintenance costs.
It's like complaining that no mechanics work on carburetors anymore. Well some do, but they are expensive and not worth it to keep your old hoopty running. Might be worth it if you have a show-quality 1960's era muscle car.
It also ignores the effects of having a critical tool in the software pipeline controlled by a large corporation. That is an absolute sea change from the years when you could (and some of us did) run most of our software development on open tools.
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?
The StackOverflow devs being replaced were never going to become real senior developers no matter how much time was given to them. There is an entire cohort of people who were told to go to college for programming because it was an easy way to make good money, who did what they were told while having zero interest in it and never touching a line of code outside of work/school hours. Those people were never going to understand actual programming, all they were doing was copy-pasting code for a paycheck. Does it suck for them that they're being replaced by automated copypasting bots, yep. But frankly speaking nobody should've ever been paid 6-figure salaries to copy paste snippets from SO and jam JS library legos together in the first place.
I have been a software engineer for 8 years and not once I have had a jira ticket handed over to me by a senior engineer.
I have worked in startups before and currently work at bkng, and have friends at uber. Everywhere it is expected that the engineers will create their own tickets and refine them with the team. If you are in a product facing team, your PM could even help you with a PRD but I have not seen one in the last few years.
By contrast I have not worked anywhere that engineers originated tickets. And thankfully, only one place that used Jira (but the engineers didn't interact with it).
Tickets came from the product side, after being evaluated and prioritized. Engineers got involved with estimating effort (in "points") and doing the actual implementation of course.
usually in most when engineers tend to create their own tickets - it's for useless shit like improve x, clean up y etc.
very few people have worked in places with high agency - where you work with a higher up & create a feature/product line that has customer impact. startups are one of the few places I can think of with high agency.
My last job was like that, it was miserable having no agency. The whole team was from fang companies and were all ok with the tell me what to do dynamic.
Do you think it's acceptable to do the work of multiple full time positions? I can't imagine it's very sustainable, nor healthy for you (both body and soul).
> This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code
I wish this were the extent of it nowadays. But for whatever reason, I've seen multiple really promising engineers get a hold of AI tools, and just outsource all of their thinking to it.
The self-infantalization is so bad that I was pair programming with a guy one day (partly to see how he was using AI) and watched him ask Claude if it makes sense to do X for every single decision.
I get using it as a form of linting... But you'll never learn how to be an independent developer if you constantly outsource your decision making. And it's disappointing too, because he was developing so rapidly as an engineer before Copilot came out.
I agree the time it takes to go from planning to deployed is condensing. I'm not sure the hand off is no longer necessary (though it admittedly often feels like it). Perhaps it means we need better ways of planning and collaborating faster and on larger features? So you still end up with a hand off, but it looks different, is maybe more detailed, or spans a wider implementation than we previously might?
I think AI is getting pretty good at generating the tickets as well. Not amazing, but it feels like ticket generation today is where code generation was a year ago.
I wonder if there's an agent harness that would work well for requirements gathering.
That assumes you're the one that's implementing it. If the agents get good enough at figuring out specs, I'd expect you could just pass it along to the next agent for implementation -- vibe coding today, vibe speccing tomorrow.
> I've heard some refer to this as a "nature is healing" scenario for the industry where if you only signed up for a high paycheck and didn't care to think critically about any of the work you're doing then this will be painful because that previously manual process has been automated. The floor of what's necessary to be considered valuable has been raised.
I feel like this is a bit of cope.
Right now you still need to have some skill to guide these things correctly to produce cohesive and functional products, but at the rate we've seen them improve I question how long this will remain true.
Nobody is getting paid significant money just to build a simple CRUD app. Even before AI. Companies pay experienced engineers because the supposedly simple CRUD sits inside a messy real system with years of business rules, constraints, integrations and bad decisions have consequences.
This blog post illustrates the importance of NEVER outsourcing your critical thinking or outsourcing decision-making to an LLM. And to never take shortcuts with learning. Learning is hard, but learning things properly allows you to understand what is happening and allows you to ask the right questions about whether the changes an agent wants to make are the changes that will best serve the goals of the project (without creating an unwieldy level of tech debt in the future).
Personally speaking (and I'd love to hear others' takes on this): when using an LLM for work-related and development tasks, I never use the "full-auto" mode, and I never manually approve of something that I don't understand. When I don't understand something an agent wants to do, I go on a side-quest to learn more about said thing and to educate myself first. This takes extra time, but I feel that it's the right thing to do, so I can at least approve/deny/redirect from a more informed position, rather than flying blind and hoping for the best.
In addition to what the author discusses, I think skill-atrophy, stagnation due to complacency (i.e.: "why grow and learn if an agent can do it" mindset), and cognitive laziness are additional risks that come with overrelying on LLMs. Humans were meant to think. LLMs are a tool.
> In addition to what the author discusses, I think skill-atrophy, stagnation due to complacency (i.e.: "why grow and learn if an agent can do it" mindset), and cognitive laziness are additional risks that come with overrelying on LLMs. Humans were meant to think. LLMs are a tool.
I know it's a cliche but the old IBM adage holds very true today
Machines should work, people should think
Maybe that's part of the problem I have with LLMs writing code. It would be nice if they just did the work, but there's a lot of underlying thinking and decision making with software work that is being offloaded any time you have the LLM do it
It seems like those decisions are being handwaved off as "not important" nowadays. Just let the LLM make those choices! But that is not sitting right with me for whatever reason. Something I should think about I guess
The decisions are important, but the understanding is that you define them as constraints. Which is what a segment of the software community, the upper class if you will, has always believed you should do, even before LLMs were a thing. The LLM simply becomes a constraint solver: machines do the work, people do the thinking.
This is the challenge of the middle class developer. They aren't accustomed to working with constraint thinking and they're past the junior stage where one is expected to still be shaping their thinking so they are struggling to find a fit.
> They aren't accustomed to working with constraint thinking
That's one way to frame it I guess
I would frame it as "they have been abused by AGILE and impatient PMs into never actually taking time to do constraint based thinking or design"
It is impossible to think about constraints, or really do any proper engineering, if you are constantly "sprinting"
Edit: I also don't personally like engineering based on constraints. It feels like constructing a building based on where walls aren't allowed to go. I get that defining constraints and letting the software go is where a lot of useful emergent behavior lives, but I struggle a lot to think that way. Maybe I'm not wired right for software in the end
I have witnessed first hand this and must say is a disaster, the person that came up with a fix to an issue that I didn't understand tried everything to convince me that the automated fix works.
Indeed the fix did work, but when I asked him to explain me the problem and the fix he started to use the prompt to get answers.
At that point I just let it go, the only thing that I mentioned later on is that I'm ok with pushing that to prod if that was ordered to me but I'm not responsible for it.
I prefer to keep the bug live until I fully understand the problem, reproduce it, come up with a solution and maybe just maybe perform a check against what a computer generated.
Please note that the bug came from a real human code base but being complex and not familiar with that part of the code (moreover the code was handed to us without any type of support/documentation) rendered me in a weak position where I couldn't come up with a solution so far.
How can someone trust so much a computer generated hotfix without fully understanding a problem is what still baffles me.
Still resisting to use any aided coding, no LLM is not going to steal the capacity to use my brain. The day I'm forced to used these tools, the day I quit.
Pretty much no other engineering field made sense to go into for about a decade. Even kids who did go EE, Mech E, or even Chem E ended up taking software jobs. The pay, benefits, and work/life balance of SWE just absolutely obliterates everything else. Or did at least
I think the field is basically over as a long term career unless you are truly exceptional. It will become very easy to build most software, and the upper end will be filled with the top people in the country/from abroad.
Wages are certainly going down for most software roles
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?
Why ask such extreme stuff? Why not ask about the solo entrepreneur who creates a convincing iOS app without a programming background? Advantage the problem on the side of ML and look for winning scenarios today.
because this comment is responding to: "I think the field is basically over as a long term career unless you are truly exceptional. It will become very easy to build most software"
photoshop, paypal, and many more companies etc. have software of vast complexity that cannot be reproduced or maintained today solely with llms, ipso facto you still need software developers or some similar role to build and maintain the complexity of _yesterday_
some guy shipping an iOS app to zero users doesn't change that. although i think it is good we can have more bespoke software.
And today the line for amateur capability is being drawn at eager entrepreneur making an app on the back of Supabase and Lovable. The fact that iOS apps have zero users owes far more to sales and marketing than to software, so maybe that's where we should be putting our focus?
What can a mid level person do? Instead of a consultancy loaning out a team of 3-4 people, it might just be one person now. That could mean a lot of downsizing.
One thing mid level people wouldn't be counted on to do was create Photoshop or Paypal. The original thread is about top level pros being the ones who stay in the industry, right? That sounds about right if we're moving the conversation over to Photoshop and Paypal.
this is a more reasonable argument IMO, but i would still disagree that that means only the top level pros stay for a few reasons (although it might happen / is already happening in the short term):
- if it is true that AI enhances our abilities it just means the goal posts move of what was expected for each level
- the complexity ceiling will rise for the level a superstar or a company is capable of maintaining, meaning there will still be stratified complexities for the mid levels of old to handle, it might just be higher than before
- counter intuitively but time and again increased software creation more often than not increases demand for more software rather than decreases
if the world decides it has no more problems to solve with software, then we are in trouble. i don't think that is happening anytime soon.
You aren’t getting it. They can pay their engineers half what they used to, you don’t need the same level of skill to build photoshop. Yes, you need a bunch of engineers, but they will be driving coding agents, not writing code by hand. They can be hired and fired for cheap
It won't be photoshop then. It will be shitty, buggy clunky app that costed a (major) fraction to develop but it will also earn a fraction. Companies like MS can afford this ie with Office suite but patience of markets and customers can allow them to go only so far, if ie Excel becomes semi-useless thats the end of Office and big cash cow for M$ (I'd say about time, that monopoly is not good for consumers at all).
This is in a way the same argument that all companies will use just boxed (albeit customized) software. In reality many, ie banks run their own custom software and for good reasons. Wake me up (in retirement) when any major bank decides to run their finances, regulatory stuff and transactions on llm-generated stuff made by underpaid devs like you describe.
This is cope, ai coding agents will follow the path of self driving cars. They will be watched with extreme caution, but will slowly but surely expand outwards. Eventually manually writing code will be considered a dangerous/bug introducing act
In the "iceberg" of boring company systems I see working day to day I actually think delivery of production software has been slowed down. The cost of "writing" code went down a bit, while validation costs positively exploded.
There are definitely more apps developed these days but I haven't seen anything much vibe coded which actually seems to have staying power. Everything is prototype quality.
See this is the big issue I've been seeing. The only vibe coded product I can think of off the top of my head that's succeeding at all is Bun, and maybe I'm behind the times but it feels like Bun's success is mostly being pushed by Anthropic; I've yet to see much other than Claude Code use it.
All fields are basically over as a long term career besides perhaps prostitutes and even there I'm not entirely sure.
But the questions of how soon and by how much matter a lot.
Being early is the same as being wrong a clever guy once said.
I hear you, but just to pedantic.. prostitution is certainly not a long term career either.. never has been. After 35, you're not going to find work as a sex worker..
A lot of AI believers (me too fwiw) seem to forget it’s a lot harder to ‘close the loop’ on non-code projects. I think this is because they are usually coders.
Is it really that simple ? A programming function that has set inputs and determinstic outputs is rather verifyable.
A ten million lines code base is not easily verifyable. Knowing whether an agent is improving when it's working on a huge codebase is not that easy - it could easily start hurting code quality without it being clear in any output.
> no programming is verifiable, and the major LLM companies are focused on it. its the first domino to fall by probably 5+ years
Which is kinda proof they're populated by sociopaths with extremely little empathy. The people who are building that stuff are programmers, and if they had a tiny bit of functioning empathy they'd stop or slow down or at least be unenthusiastic.
And we're not talking about very high level empathy here, but the very basic kind of thinking about the effects on someone very much like yourself.
I agree. And I would remove the basically. I give it five years before essentially just a few very senior people are managing the whole cycle. Downward pressure on wages is just gonna keep ratcheting up.
nah the world needs more software - it's just the delivery mechanism that's different.
we are entering the world of smaller service firms (1 - 3 people) - where technical chops will even get paid more. the age of cookie-cutter apps is over.
My backlog is less empty than ever - it just happens to be overflowing with whispy Claude-written tickets for functionality that somebody else's Claude suggested after summarizing some other Claude-infused Slack chat.
ofcourse not, but they can pay someone 80k a year to work on the backlog, whereas maybe they used to pay 175k. its not about work going down, its the skill set needed to complete the work is lower than ever, and they need less people than ever
they won't even need that as agents talk to their own lanes in some Linear project management workflow that your sales team agents are connected. The entire system is going to end up agentic and even the CEO will be out of work unless they are founders and owners of the company. We'll all have our own business this way. Or it all collapses. Time will tell.
color me skeptical that the CEO or anyone non-technical is ever going to prompt their way out of a major incident when all the AI chickens come home to roost.
I don't accept that argument. As I see it, laws should be structured as data rather than code, using a clean non-Turing-Complete DSL for any embedded logic and calculations. Maybe there would still be occasional situations when new software features are needed, but it should be a rare occurrence rather than on every new change.
I'm hopeful that software will be applied in new areas where it was too costly before, with AI help it will be possible. Software will be cheaper, even more prevalent, lower quality in since respects, but SW engineering will still be a viable career.
There are really a ton of fields where people have done an absolutely terrible job of properly using the advantages of software, even pre AI. Like, even today there are people manually drawing footprints in PCB design software, manually determining what pins carry differential signals, manually forgetting to swap RX and TX lines..
except for the functions they absolutely had to have a computer do, they forgot to move out all the drudgery and footguns and continue operating in "PDF space". It's embarrassing for a profession that is supposedly made of engineers.
PDF space is still more advanced than the people typing into "word processors" however. Making software to emulate letters was such a massive mistake for the trajectory of computing, it let people effortlessly "adopt computers" by making a digital facsimile of their terrible analog processes. Only with AI we now have the ability to digest all this unstructured mess.
it could mean they are not completely out of automation opportunities, and will lose to more innovative players if won't invest into software.
The end state of these companies is grid of cheap robots controlled by software.
In case of productivity surplus, exponential demand can be easily created by government: e.g. they print N trillions dollars, and say we spend it on some (hopefully useful) mega project(s): fusion, carbon capture, give nice home to everyone, fully verifiable, glitch free, hyper optimized software, etc. It will immediately create lots of demand, supply chains, customers, etc.
You can see current AI hype as example, and its government didn't step in and printed N trillions yet.
If maintenance and security is fully automated and for small changes or a small feature you will only dump some spec document into your agent platform, for sure.
It's not a scapegoat, it's basic economics that wages are determined by supply and demand; increasing the supply decreases wages. It's also basic economics that this ultimately reduces costs to consumers, but that doesn't make it any less painful for the workers whose wages face downward pressure due to increased competition from labor force growth.
Never heard the words "basic economics" used outside of strawman political arguments.
To think that H-1B developers can meaningfully shift the supply to the point that is felt by other people it's very shortsighted. The job market has been very difficult for years with vastly more supply than demand and its due to plenty economic, financial and political reasons. Interest rates itself affect it way more than any H-1B developer could ever do it. If you were to actually sit down and look deeply into it and look at the data, I'm sure that H-1B would be a small percentage of the problem and you would get fired up about so many other things.
But that's difficult and time consuming, if anything it's advanced economics and requires effort to decode what's happening. What it's very easy to do is getting angry at a group of people and to feel deep unfairness about it, then think that if that group of people were to leave, the problem would improve or be solved. That's exactly the kind of thought that seems to be so pervasive at all levels and yes, it is a scapegoat.
Especially since that the only merit someone has over H-1B is to (by pure chance) having being born in a different place. I really feel that many people complaining against H-1B wouldn't even qualify for it if they were born somewhere else.
What if the new entry level is what we consider senior today? Isn't it possible today to obtain entry/mid level skills with LLMs? I wonder if things will shift more in that direction.
People have been fretting about 'foreigners' taking their jobs for decades and it never really happened. This is all about LLM's.
I mean, think about it; just a few short years ago there was a very strong market for software engineers, despite outsourcing and immigration being very much part of the landscape.
Orrrrrr... it could be a complex combination of outsourcing, an over-reliance on degrees, LLMs, a lack of "apprenticeship" mentoring, etc etc etc.
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.
> outsourcing, an over-reliance on degrees, LLMs, a lack of "apprenticeship" mentoring,
Which of those things changed (along with higher interest rates) in the past few years though? All the other variables did not change. They were present 5 years ago and present 10 years ago too. To me that's indicative that those factors are not the cause of a soft market for software engineers in 2026.
IMO it is and I've been saying it for more than ten years that it would catch up with the industry. And it is now. The LLM shit is just a mask over the larger problem.
The front fell off because the base was never built to support a shakeup of the industry. There's so little support, now and for as long as I can remember, for people to fail gracefully in the field. It's just up up up. And now that programmers are finding their jobs to be a little more precarious, maybe folk will start supporting mentorship as a practice.
This isn't just a "market" problem. It's a problem of people not teaching others skills that help them thrive inside AND outside of work.
Yeah my new VP is from a certain country in the eastern hemisphere, and the interviews I've conducted for US-based candidates oddly enough have been 100% of engineers from that same country (say 30 or so in the last 2 years).
ive worked at multiple FAANG, almost always been the only american on a team of 10. theres some huge push by corporations to deny it to justify shipping in more foreign labor.
There are 100K H1-Bs a year and 4 million grads a year in the US. Anyone who thinks H1-Bs are actually contributing to their inability to find a job is a moron.
But those H1Bs all come for a very narrow set of work - mostly software development or other adjacent roles. So your 4 million figure that counts all graduates in all fields doesn't make sense when we talk about tech.
There are around 100k U.S CS graduates . You're telling me 100k H1-Bs don't make any impact on them?
-85,000 NEW visas granted each year, not including renewals
- The mass majority of those are going into the tech/software
- there are only around ~100k CS graduates each year
- H1B workers will take much lower salaries and benefits than their US citizen counterparts.
And H-1Bs are easier to overwork and abuse because the threat of deportation and the dangling carrot of citizenship are very powerful motivators that don't exist with US citizens.
Agree with the article the way I think of it is basically like before AI good engineers put in effort either currently or over cumulated years of experience.
A bad engineer has been lazy for years and will never change.
You likely have experience with this already first hand. Ever had a lazy day and just hit "yes" "continue" on the AI over and over? I've had to revert entire days of work because I was so burnt out I didn't put effort into the design.
A good rule of thumb though is if an AI can't solve the bug and fixing it creates more you have a bad abstraction and architecture that needs a gutting and rebuild from near scratch.
>AI makes projects with weak engineering culture fail much faster.
>There used to be a time when people sat down and talked about how they'd do something. Now they can just prompt an agent for a few hours and open a PR.
>The most tragic aspect of this way of working is that, to the untrained eye, it works.
>If you pull the branch and test it, you'll probably get something somewhat functional. So what do they do? They keep going. Again and again. Until the project reaches a point where no one knows how anything works.
Isn't this the opposite of failing faster, it lets people who would have never made it past the first few hurdles and give up get deep in and then the false hope that they can then prompt their way out of whatever mess resulting in deeper and deeper spaghetti.
But now they can now move so fast that nobody has a realistic chance to stop them before the damage compounds.
They get into a much deeper mess much faster.
You deploy an application that ostensibly has the desired capabilities but it fails at scale, or the architecture is not extensible to add new capabilities or fix bugs. Those are expensive mistakes and in safety-critical domains could be deadly.
The thing is I've worked on plenty of code like this written by humans. AI just accelerates the process and puts this type of code within reach of more people. It could be seen as a step backwards in good software engineering practices we've painfully learned over the last two decades. I see it as a cycle repeating itself in a new iteration, with the hope that we'll end up with still better tools and processes in another few years. But I agree it can and will result in real harm in the meantime.
Code that accidentally ships every 100th order out for free... exploits releasing customer PID and causing regulatory nightmares... self-driving cars that reboot at 70mph... The only limit is your imagination!
Now the question is - no one was born good or best engineer/programmer/scientist. Often it was a long path of sleepless nights, daily grinding, failing million times, doing dumb mistakes along the way, the usual package of suffering sometimes called "experience". What is the path now for the next generation of good or best engineers? There will be no opportunities/budget to do the same anymore.
AI gives the skilled more ability than ever before to create wealth; they can realize an idea by themselves and a few hundred dollars of LLM spending, that would previously have been out of reach for anyone lacking the capital to hire 5-10 people.
> You were never expected to understand every service and every database. But at least someone did and would explain it to you.
I agree with most of this except this. Think there’s some rose tinted glasses here or I’ve got bad luck over time.
Life before ai was bad as well. There wasn’t any one to explain to you anything! You had to figure it out yourself. The people either already left or was busy with something else.
No one wrote tests (to my standard). Most of the ops works was skipped. Docs were just not there. Nobody linted properly. Just bad mannnn
the vpn is called dev-test-prod and some containers are stored in a dev subscription, but still used in production. Some intangible network error forces you to use the production cluster for testing (the bucket is at least called test).
I feel this kind of setup is invariant everywhere I go to do engineering. Fable level intelligence has no effect!
If there is any positive to be had from this, it's that we finally started documenting the codebases for AI as we should have always done it for other teammates.
From the title I thought this post would be about something completely different. The post is about splitting the world into "good" and "bad" engineers with an emphasis on the bad engineer. Ok but what does that have to do with the middle class? The post leaves the best part out.
What I thought the post would be about is the dissolution of the White Collar Kitchen Brigade
The kitchen is run by the Chef but it needs the Sous Chef, Line Cooks, Kitchen Hands to operate.
Many software engineers have made a good living acting as the sous chefs and line cooks underneath the rockstar chefs, but with AI companies are inclined to turn the whole kitchen over to the top dog and their AI crew and the ordinary human crew is slowly being churned out.
Technology has been doing this for decades. I think a lot of our "K shaped economy" discourse is about the bifurcation of the upper middle class creating downwardly mobile educated young people. Nobody in my wife's immediate family finished college. She and all of her cousins are quite indisputably better off than their parents. My father in law drove a forklift at a soup factory. My sister in law is studying to be a nurse. It's a big step up. But the "white collar" middle class has become very winner-take-all. To use an example from my field, if your dad was a partner at a regional law firm, that path probably isn't open to you. Technology enabled consolidation and scaling, so you don't need lawyers in every city in the U.S. to be able to handle legal work there. Lawyers at national firms serving Wall Street clients are making more money than ever, but the drop below that has become pretty precipitous. The same has happened to small businesses all over the country competing with Amazon, etc. It's had a huge impact on the petit bourgeoisie.
Of course, this is economically efficient. Nobody is going to give up Amazon same-day-delivery so that some local small business owner's kids can live better than the median person.
Interesting article, and it makes a lot of salient points.
I think I can agree with most of it while also arguing that I don't think good code has ever had an honest measurement of quality. From an end user perspective, the end product either works or doesn't. Working terribly is the same thing as doesn't work and working well is the same as works.
What AI changes is the actual code part. The actual code lines output by AI is identical to or better than the best programmers. The systems design, architecture, QA, integration into existing legacy systems, to just name a few, is where the strengths and skillset lies.
In order to be a good engineer, you have to be a systems thinker. AI or no AI does not change that. The entire picture has to be taken in to account, and I think this is going to obliterate the vast majority of engineers who cannot or don't want to think about systems. It's no longer about putting on your headphones and outputting code. It's about having to interact with other humans, systems, architectures, organizations, and an API or MCP is not going to help with that.
I truly do feel bad for terrible older aged engineers, and the young new grads. I think it's unfair that a lot of new grads were told that CS was a great career, only for them to start their freshman year before AI, and then graduate when AI coding is in full use at nearly every workplace.
This is exactly how I feel about my job now. I'm the new manager. But honestly claude is better than any team of developers I've ever had working under me. It does exactly what I ask it to, in 10 minutes instead of 3 weeks. And apparently we can't afford a development team now anyway...
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.
Exactly this for me too. I don't know how to feel about this overall honestly, I'm able to do so much more but now I barely get to write any code. It's weird.
A manager isn’t normally the person deciding how the software should be architected or implemented. Their job is largely priorities, people, coordination and resource allocation.
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.
Nooo. But seriously, that does appear to be the end result on most of my recent sessions. The time I spend is on correcting, adjusting.. dare I say managing the process as opposed to actively editing every aspect of it.
I think it is less about junior/mid engineers, and more just about the kinds of work inexperienced/cheap developers are often doing: assembly line, JIRA-ticket-taker type development.
This is especially impacting Indian tech workers in the US [0] since these are often the types of roles that InfoSys and other foreign tech consulting firms are staffing. The new $100,000 fee to sponsor an H1B visa has made it difficult to justify hiring foreign tech workers when most of the time they are just going to be using American LLMs to do their work anyway.
I’d expect that layer of the industry to shrink substantially.
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.
Not really. 0-based indexing is different from counting and starting with 0 in a counting context is weird. Would you ever say a set has zero elements when it actually contains a single element?
Look, stupid companies who use A.I. to generate their code will simply fail. Companies that use bright engineers to engineer their product and write code (and pay them accordingly) will thrive and thrash the competition.
Darwinism in action.
I don't believe A.I. will change much, but it will lead to winners and losers, that's certain. Lessons will be learned, A.I. will remain but play a minor role, just like IntelliSense and ReSharper.
People need to understand that when things break management will hold you accountable, not the A.I. If you can't fix it you'll be out of a job. So you'd better make sure that you understand the generated code and clean it up before putting it in production because you'll be maintaining it.
I think the worst part is that some companies may be okay with it. They will pay attention only when it's messed up beyond repair. And it’s possible that fixing it will be a task for more advanced models, not humans. Do they win or lose at the end of this martingale? I am not sure
> Good engineers have become more valuable because AI lets them move much faster. They don't need as many people around them just to do the implementation work anymore.
This would be true if the goal was to get good working code faster. But the actual goal is to get any code faster. So, in reality, it doesn’t matter whether you are a good or a bad engineer. It just amplified how good you are at manipulating the hiring process with your fine tuned resume and how smoothly you can talk your way through.
I got a person from my small team fired before the sommer holidays. Not that I wanted to, but he didn't deliver the quality that I was expecting from a thinking human with an engineering degree.
Adding AI to the mix just made things worse. I'm still finding issues in the codebase/documentation that I need to review, test and fix.
The replacement is being trained. I made sure that, while I expect them to use LLM supported development .. they own their contribution.
People should realize that programming is not a liability.
Programming per se is the actual creation of detailed knowledge by writing.
You get a task, how does it interact with all other invariants?
What are the implications on data flow, processing and user workflows?
You can rarely answer those questions beforehand, you step on them during programming as the formal language forces you to take them into account sooner or later.
If you outsource this knowledge-building you’re losing the steering ability when stuff hits the fan.
You lose the ability to navigate the code properly in order to identify bug or violations of invariants.
LLM optimize locally, that’s their nature.
Invariants are often implicitly scattered around the whole code base.
Explaining them to the LLM is much more tedious than just to write the code in the first place.
At least for me as I have much better expression-ability in Code than in natural language when it comes to describing any form of computation.
One thing this post did not discuss is the enormous effort required to explain to the management why number PRs has increased and number of lines changes, which in their view, means explosion of productivity, yet one engineer is destroying the team's momentum.
> 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.
It's not clear to me what "the middle class" is supposed to be here. All engineers exist on some spectrum between "good" and "bad" and it's pointless to try to identify the exact markings, but we all know good engineers and bad engineers.
So AI isn't really doing anything but giving sharper tools to both groups.
So, as it was before, we simply need to set expectations and remove those who cannot adapt and meet expectations... You know, the way it's always been.
I think it's largely correct that hiring bad engineers is dangerous to the company. But that's always been true, especially those "hack out a prototype, get director applause, and leave it for somebody else to own" people. But management has usually chosen to keep such people around, because they can look good on paper (see how many tickets they closed?).
The question is really a management / business-owner question -- will managers/directors stop hiring yolo-engineers? Will they empower engineers to close PRs simply on complexity/size grounds? Will they fund refactors and simplifications as first-class concern? If not, it will be a problem, and I don't envy the engineers who try to be the glue at such a company.
- but in your diagram titled "Word vectors plotted in semantic space" dont you think you need to add arrows to show where those vectors are actually pointing?
- because i dont get how you arrived at this Using vector arithmetic, you can calculate: woman + (uncle - man) = aunt without seeing the math vector directions
The main thing it's removing is the skills you gain through actual practice, and replacing those with the demand that you subscribe to OpenAI etc to do your job.
But, moreover, the demand your company subscribes. But not your company anymore, because you'll probably be replaced by one engineer (and an AI subscription) who's now trying to do your job and about four or five other jobs.
And this one engineer will become more and more reliant on AI companies, AI companies that'll go for the throat once they've hollowed out all the skills that used to exist in the engineering market.
> - "Why are we doing this here?"
> They send you a link. It's a Claude conversation.
LLMs spared my neck of the woods for now but is this really how PR review looks like these days for an average SWE or its just an example of a Junior in a team?
LLMs are an automated Indian dev-shop. That’s all. The code is poorly thought out, poorly implemented and doesn’t take performance into account. But the code works and you got it for cheap.
That’s my mental model and I’m happy with it
I told my (small) team of developers that they're free to use anything to get them more productive: (company-provided) AI, black magic, WFH to avoid traffic, etc. But I also tell them that every human (including myself) is responsible for their own (direct/indirect through delegation) work so we can't say "a genie did that, not me". So far it's net positive for us with AI.
Perhaps more broadly AI will hollow out "middle intelligence".
We could end up with a gulf between those who use AI for cognitive inquiry vs passive delegation. Those who accelerate learning by asking "help me understand this" vs those who relinquish understanding and analytical thinking to AI to complete their work.
Agree with the article, but good luck convincing upper management about it.
“If it works, don’t fix it” until it doesn’t and we shall see a new wave of software hiring in a year or two.
Every enterprise is talking about AI Transformation, and that great with the right expectations. But those who think AI will just make platforms quick with less people and least experienced engineers, will have to prepare for the deinshitification transformation in a year or two.
I appreciate that the OP puts his finger on the problem. I think he's right. I wish there was more optimism or ideas about how to solve it, though. How do I fight against it as an engineer? Or, how do I become a "good" engineer? It feels like sometimes the only solution people have is effectively "don't use it."
The premise does not make any sense, it is a technical culture problem which you need to enforce. If you let it go wild, yes it will go wilder than ever but this is relatively trivial problem.
IMO The author fails to list the hypothetical person with 13 PRs to review is also failing.
> * The engineer who refuses to change with the times
IMO many of the old ways of software engineering were local maxima. We're still seeking how to hit a new maxima and the journey may take us through zones lower than the previous local maxima.
I use AI heavily, so this isn’t about refusing to change.
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.
It doesn't seem to be happening everywhere, but if you are unfortunate enough to work someplace with a "LinkedIn thought leader" high up on the engineering food chain, there's a really high likelihood that your organization is currently in the throes of an "everyone must be using AI for everything" fever dream.
And boy let me tell you, it is every bit as disastrous as the OP claims. Engineering managers are asking Claude to write up entire initiatives, then they hand off these nebulous AI slop manifestos to the teams where the requirements folks are having Claude shit out tons of superficially plausible Jira tickets. It finally lands on some poor engineer's plate and since these tickets are the technical equivalent of Finnegans Wake, they just end up asking Claude to read all this shit on `ultracode` and draft up a pull request. Which is then peer-reviewed by somebody using Claude.
Anecdotally, the essay is so spot-on. In my last job, I'd regularly have to review +20k-line change PRs from mid/junior devs only to reach a point where I'd have to just shut down the PR and ask for it to be broken apart. Sometimes, the issue would get escalated and I'd have to speak to their management/director chain. More often, they'd realize that if they spent some time trying to understand how to break it apart, the changeset actually needed to be much smaller and I'd come back to a 400 or 500-line PR to review.
In one particular case, a senior teammate of mine went the extra effort to actually explore what the intent of the change is and created a whole new PR for the junior dev that was a simple configuration change of 5 lines instead of the 14k lines they put for review.
This is utterly unsustainable and something will give at some point.
It's very true, you used to have to hire people you knew were not very good just to have warm bodies who could throw together widgets, minor bug fixes, etc. You still had to have a competent developer review what they did, which was annoying, but ultimately a time saver over doing it themselves.
Now the competent developer can just run agents and do the same review process, except it's ~free (relative to human salaries, even outsourced).
So we've got a bimodal distribution going on where the bottom X% of developers have become essentially worthless while the top Y% of developers are now more valuable than ever.
It still should be. Any educator worth their salt should be able to connect the dots on where all of this leads.
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.
The fact that a machine can do something better than humans doesn’t automatically make learning it pointless.
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?
All this mindless droning about societal collapse, destruction of jobs, people moving on is really getting old. Sure people have caused mayhem by following (and enforcing) bad practices which resulted in a toxic workplace, a mix of pissed of client due to constantly failing to reach deadlines, unimaginably bad codebase that was a horror to work with and teammates each defending their own turf. LLMs now allow this deterioration to happen much quicker and more effectively.
On the other hand the problem can also be triaged quicker and rewritten faster. Pretty much every startup I joined had at its core disastrous code written by students and overworked techies. I can totally see this shitty base being the future base all startups. It'll likely need an army of agents or devs to make sense of all the spaghetti being written. I won't be surprised if demand for devs skyrockets after the first generation of spaghetti western code "matures".
I have a theory that Claude regresses to complexity. It’s trained to mimic existing patterns - so the smallest grain of over-engineering or spaghetti-code is like a mind-virus, gradually infecting all future output and self-amplifying until all is spaghetti.
Probably a good thing, we need more people building major mega projects like the Line. Potentially we need AI to mass produce architecture and scale up and out city/county building departments to open the gates to massive buildings in the United States.
Too real. I got DMed by management recently asking if I was anti-AI because I had the lowest spend on the team as the lead, y'know, the one that has to review all the slop my peers are generating.
If the people trying to understand the changes and guard quality are now considered the bottleneck, the answer isn’t that the reviewers need to move faster.
> But once you start storing data there, you can't just remove them. You have to come up with a migration plan, make sure you don't disrupt the system because people are paying to use this every day. You have to think about what you'll do if the migration fails. Make sure you don't end up with orphaned foreign keys. It's just so much harder to fix. Even with the best model you can get.
Migration plan? Just ask Claude when shit hits the fan. You'll make a plan when you need one.
> By the time you've untangled one bad decision, five more have been merged.
I'm slowly (partially ironically/sardonically/nihilistically) adopting a mindset of accelerationism towards the collapse of software development - it was largely done wrong from day 1 and wasn't "real engineering" to a sufficient degree to not lead to the mess that we've been in maybe for the past 20-40 years. The only thing AI did was take away the brakes and press down on the accelerator, we're already headed towards a cliff and have been for a long time.
If the code in airplanes and spaceships was developed with the same degree of care and attention as "good code", you'd see those dropping out of the sky regularly. If they built bridges like we build software, they'd fall apart regularly as well. Good code CANNOT hinge on the opinions of some senior dev, or even a group of them - it must be provably good. And if it must be provable, then these checks must be automatable. Bad code (whatever that means, however you'd manage to classify the difference between AI slop and what you want to see) should be IMPOSSIBLE to get into the system at all, due to those automated checks.
Be it good enough test coverage, automated checks for usability and end to end coverage of the features, project/domain specific lists of architectural rules (think ArchUnit), needing proofs not just tests etc. We will never have that - our OSes are bad, our browsers and other essential software is bad, our programming languages are bad (the fact that unchecked exceptions even exist in languages is a cardinal sin), same for databases and tbh any other class of software you can look at.
This impassioned comment might border on a rant, but my argument is that the past decades aren't the baseline of good code, we'd probably need to spend 10-100x more effort to produce 100-10x less code, but make the existing code bulletproof - there is no reason for more than one OS to exist, no reason for more than one UI framework to exist (or even all of the egregious ways how the web platform was transformed from documents and links to a collection of badly written apps, which eventually infected the desktop with Electron, due to the native GUI development also being severely neglected), no reason for more than one web framework to exist or even more than one programming language to exist in mainstream usage outside of research and looking for the solution to use for the next decade/century of software development. Yes, I'm exaggerating, but the correct answer is probably closer to 1 than to 1000.
Obviously that'd lead to death by comittee and some degree of experimentation is necessary, so hey we end up with a new slopped together library every week and I know nothing and nothing works anyways. I wonder if we had ONE high level programming language, whether over time it would have evolved from C++ to Rust (sans odd parallelism), and if it was based on formal proofs, then migrating between language features could have also been fully automated, alongside enough pushback to any feature deemed not worth it. On the other hand, even with all of the world's developers concentrating effort, something like that might be above our cognitive abilities, so probably not - just too hard to reason abuot.
More like AI is exposing bad engineers faster than it would've been possible earlier. Previously they would simply outsource all their thinking to someone else, now they see massive progress with AI and delude themselves into wishful competence.
As an open source maintainer, I can chime in on this.
With TxtAI, I've seen a large uptick in PRs (https://github.com/neuml/txtai/pulls?q=is%3Apr+is%3Aclosed+s...). While the extreme verbosity of Claude messages and commits is very annoying (plus the constant defending itself on why it's a bug), I do think it's a positive that more people are enabled.
It does require reviewing the PRs. Some can be tricky just like a human. For example I did merge this PR (https://github.com/neuml/txtai/pull/1136) and it would have completely broke search. But a human could also do that.
From an open source standpoint, I say the more the better. You just have to be willing to do the work to review and no not just having AI agents to review what the AI agents are submitting. There still needs to be a human in the loop, if you care about quality.
Ai isn't removing the middle class of software engineering.
Software engineering is evolving, and the middle class (and beginner) is going to have to grow instead of being able to leverage the same skills for longer and longer.
It's so true from some of the other posts that you can outsource your thinking, but you should never outsource your learning and understanding.
While there are bad engineers, I imagine that teams that have evolved alongside AI and have maintained their size and consistency without adjustment may have structural issues. I would argue that team size counts ought to be smaller now than before Claude. Unfortunately this idea could feed an AI-induced layoff trend, but it could instead lead to product diversification instead.
I'm not sure what skill really means, or what's considered bad anymore. AI coding ability and human coding ability are different, and different organizations need different skills. No skill is inherently bad—it just depends on what the organization needs.
I understand that AI writes better code than people like me in many cases. But an industry should still provide opportunities for those people. And sometimes those people create things that are better than AI in certain areas. The problem is when even those opportunities are taken away.
That is an incredibly short sighted view. By acting this way, the industry is essentially selling its future for short term gains. A systemic reduction in the number of people capable of maintaining systems directly correlates with an inevitable collapse in overall software quality.
The perspectives of market advocates often stop at this short sighted level. In reality, their modeling is incredibly simplistic. I will not elaborate at length on their poor modeling here. The short sighted local optimization that only chases the margin of the next quarter is the exact enemy we must guard against the most. (Of course, given the nature of HN, this specific part of the comment will likely be attacked.)
It is not a matter of companies not owing anything; rather, companies are actively committing self sabotage.
Is it truly right to eat tomorrow's seed corn today?
The essence of the software industry is not the 'generation' of code, but the 'maintenance' of it throughout its life cycle. Why is Linux continually maintained, and why is Windows continually maintained? The core of this industry is fundamentally tied to the entire life cycle of a product.
You might be able to fix code with AI. However, under the current LLM structure, can it actually modify projects spanning hundreds of thousands or millions of lines? It cannot. The skill required to partition those architectures is still entirely left to humans. And the ability to define those boundaries is born strictly from experience.
Labeling certain individuals as useless or inadequate inherently destroys the resilience and buffer of the collective as a whole.
Why do humans embrace and care for the vulnerable when society has the capacity to do so? Why do we strive to preserve diversity? It is because, depending on the context, those very traits might prove to be more advantageous. Every human possesses distinct skills, and their unique temperament and proficiency simply manifest depending on the situation they face.
Is it long term pain if a small startup in a very competitive vertical gets to market quicker with code gen and finds market fit? Whether that results in a rewrite or a refactor, that is still a huge win and one that a lot of people will gamble on.
That's only one of the three reasons in the article:
1) Reviewer burden - LLMs can produce a deluge plausible but incorrect code which can overwhelm human reviewers.
2) Safety and Security - Many corporations depend on the JDK so stability is a high priority.
3) Copyright/IP about who owns submissions generated by AI is not settled in law.
The article also goes on to compare the JDK teams policy to GraalVM, also in Oracle which is more similar to the Linux kernel policy, where AI submissions are allowed, but the human submitter is accountable to them, which is reasonable too.
It's not unreasonable, in my opinion, for the JDK team to limit AI contributions based on their stated priorities, just like how other teams might not require those same restrictions.
Oracle banned AI code from a public project they maintain and backport/share with a commercial product because they're a very litigious company, anticipating future legal cases.
It strongly argues against a position that many people including myself have taken, that all code will soon be AI code and the only people still writing code by hand are those who haven’t gotten the memo. (I don’t mean to rule out the possibility that Oracle, despite their involvement in AI infrastructure, is just being dumb and the lawyers made them create a policy that’s not compatible with the modern practice of software development.)
Just look at how they bragged for a year now about how AI built entire apps with a single prompt.
And now that code is being watermarked by AI, suddenly they’re artists, painstakingly prompting, crafting, to get just the right code; the watermark is unethical even!
AI psychosis is real, and even some of the smartest people I know how succumbed to it.
Are LLMs rewarding experienced developers with tons of productivity gains? Yes.
Are LLMs actively degrading their expertise of understanding code? Also yes.
This article has made the implicit assumption that the top quartile of engineers are immune from skill decline. They're not. If you're an engineer who increasingly outsources the planning, writing, and analysis of code to an LLM, you're losing your ability to plan, write, and analyze code.
All of this is to say--senior engineers who have fully adopted AI tools are blowing smoke up their asses to dodge the reality of their own obsolescence. The senior engineers can talk about productivity all day, but they're only marginally closer to understanding a complex system that was written by LLMs than the "middle class" of engineers are.
You reading this--yes you--get over yourself. Your skills are depreciating too.
A pattern I have noticed is you get way better results if you just have one skilled senior engineer coding everything with AI vs a lot of people.
Having large teams in the age of AI is pointless. It slows things down and spreads accountability too thin.
When you have one good engineer doing many things, a lot of stuff lives in their head and they know what to look for in their own PRs. Also, people tend to like their own AI slop, but not others. So overall you will have at least an engineer who is satisfied with the codebase vs a lot of people who either have some gripe about something someone else did, or just don’t care at all.
That means you have to put way more trust in a single individual, but if it’s the right individual you propel the organization further ahead than a team of mediocre engineers or senior engineers limited in what they can accomplish.
Wait till we realize that nobody is buying the software we vibe code anyway.
We've seen this game before, with the Dot Bomb and 9/11. A lot of you have 6 figure jobs that will simply be gone next year after the election, never to return.
That winter lasted about 5 years until 2007 when the iPhone and social media sites like Facebook went mainstream. This winter won't end. Or more accurately, it is the end.
Maybe we should stop debating whether we're in a crisis and start looking at the 5-10 year endgame of the Singularity. We're entering the eventuality that many of us have predicted since the arrival of the internet 30+ years ago, that prices will get lower but nobody will have any money to buy anything anyway. The feeling that we're doing something wrong with our lives will continue to intensify. We'll try so hard, and get so far, but in the end, it doesn't even matter.
I don't know about the rest of you, but I'm turning my attention away from trying to play the job game with AI. I'm looking instead at how we can provide time/money/resources to the middle class after capitalism can no longer provide them.
A conservative friend of mine just read the Communist Manifesto by Karl Marx, which I didn't see coming, especially since he beat me to it. In the neurodivergent spirit of not being able to do anything alone, what if we all read it?
I'm predicting that it stops just short of what full automation can provide. Loosely the evolution of economics goes: hunter-gatherer -> agrarian- > feudalist -> capitalist -> socialist -> communist. And now solarpunk (or something).
The working class is looking forward to the next chapter, but the capitalist class is looking backward to neofeudalism.
Those two directions can't coexist, so what does the future hold? Well, it's always darkest before dawn:
"It's easier to imagine the end of the world than the end of capitalism." - Mark Fisher.
If the endgame of capitalism is that it inevitably eats itself, then the game now isn't how to get more money and do nothing with it, but instead how to start doing something with no money.
I should add that even if I'm exploring anti-capitalist futures, that doesn't make me socialist. I don't like the 6 hour daily work requirement of many socialist societies. I think we can do better than that and get closer to 0, so that we can shrug off wage slavery and finally get real work done.
This is extrapolating several steps beyond anything we actually know.
Whether people will buy AI-generated software is a different question. The problem I’m describing already exists inside businesses with paying customers.
I’m talking about established teams working on products that already have users and make money, where AI lets individual engineers introduce changes faster than the rest of the team can properly understand and review them.
There was an old truism of "acid fascism" that went like this: "LSD makes smart people smarter and stupid people jump out of windows". This is like that.
I hate that framing because it glosses over what makes AI distinct from other technology. Pretty much anything can be used as a tool, that’s not an interesting aspect of AI. However standard tools do not take decisions on behalf of the user, they do not apply judgement. They come with assumptions and constraints that make some decisions more likely to be made. But the whole thing about LLMs is that they apply judgement and take decisions. When you use an LLM you delegate both aspects to it with very little overview or control.
I don’t think it’s “just a tool”, it’s something that directly compete with the role of humans in a system, by design
If you go back in time and imagine yourself in 1950, would you have said that about computers in general? Yes their decisions are the result of pre programmed heuristics, but to the operator that can feel as opaque as AI. In fact in the early days of computing AI was used to refer to a broader swath of what we now call heuristics and machine learning.
Is a very sophisticated computer driven adaptive control system making decisions for the user? Arguably yes. If your car has a bunch of assist tech you are not driving. You are commanding a nonlinear control system.
AI today is quantitatively far beyond these systems but internally it is still just a giant decision table. It’s just a differentiable table that can be automatically programmed by back propagation at what would be unimaginable scale for manual implementation.
As soon as you put a machine between you and the target action that is more complex than what you can hold in your head and that has multiple layers or feedback loops, you are ceding fine grained direct control in favor of a simpler abstract control surface.
I will change my mind a little if I start seeing evidence of genuine volition, but as of now I suspect that’s a property of life not intelligence. One interesting result of AI when viewed as an experiment is: I think it proves that life and intelligence are separate phenomena and that consciousness and intelligence may actually be unrelated.
I have the hypothesis that consciousness (and therefore true volition) is a property of life. You have to be metabolic and tied in some intimate way to thermodynamics and the arrow of time. Solid state electronics doesn’t have this property. It’s unrelated to intelligence. A bacterium may be conscious.
>If you go back in time and imagine yourself in 1950, would you have said that about computers in general?
I'm not the parent, but personally, no, I don't believe so.
I always appreciate the "it's like past changes" thought when things change, but in my opinion, this one simply isn't. It's notably different both quantitatively and, critically, qualitatively, than all previous increments in computers/software. This is much more lateral than punch cards -> assembly -> compilers -> frameworks.
Economics would have always created this downward pressure on demand for software engineers regardless, either companies would replace the number of engineers they need with AI, or with low paid offshored workers.
I don't know what kind of company has got a large codebase and it's taking 20,000 loc pr's expecting that shit to be sustainable, but I work AI first and at the most PR's are touching 12 to 15 files, with the more radical ones sitting at 30. They are still human-reviewable. They are still the kind of change you can revert back to original without breaking all the rest... there are ways of doing this stuff, dear luddites.
I was wondering how anyone could reach the token limit of a 200$/month Claude subscription. I never did on a 20$ one, and I'm parallelizing Claude to the absolute limit of what I can reasonably keep in mind. And I do that day and night, on week-end too with open-source. Now I'm absolutely convinced that it's by doing crap architectures and design that require 200k token of context before adding a single checkbox. If you apply good design principle and course correct the AI in real time before it commits to really stupid way to fix things (i.e. you don't ask it or let it do things that would make zero sense if you had to do it yourself), then the vibe coding cost way less and is way faster and easier to reason about.
> The engineer opening a 25,000-line PR should have stopped the agent long before it got there.
So many A car is simply a faster horse arguments being made here.
The “You must review every line of code” camp are going to be in for a seriously bad time when Claude/Grok/etc starts writing machine code, and they absolutely will and you will look like a crazy person the same way as those who said we can’t trust compilers back in the 1970s.
Breaking up code into small reviewable pieces is obsolete advice from legacy software engineering. We will probably be reviewing prompts or functional simulations as a form of review. Which brings me to the point that a Senior engineer in 5 years will look absolutely nothing like a Senior engineer in 2019.
> The “You must review every line of code” camp are going to be in for a seriously bad time when Claude/Grok/etc starts writing machine code, and they absolutely will and you will look like a crazy person the same way as those who said we can’t trust compilers back in the 1970s.
I'm working on this right now, will have a release probably in a week or two. Not machine code but it's essentially a custom assembler/compiler pipeline (close enough) that an LLM can operate via the CLI (you can do it too, it's just way slower) and it emits native asm optimized chunks that can then be inserted back into cpp (working on a rust et al impl). The results are _obscenely_ good. It's outright outperforming gcc vis-a-vis by a MONSTROUS margin, and it's not even close. As in, gcc can do abour 3-4 cyc/byte (arbitrary workloads on a wide variety of tests) and my tool does it in 0.5 cyc/byte if not better. It outright emits kernels that run at a flat 4 IPC for more or less _anything_. You can then have an LLM convert it back into high level C++ intrinsics (not always, gcc doesn't always expose all the levers needed to do so) if you wish. The one downside is that you need to provide fairly accurate cpu arch maps (ie agner fog instruction port/latency tables) for the tool to work right, which is what i'm focusing on right now.
I do have a genuine question though: what value are you adding at that point?
If you don’t understand the system, don’t know what the code is doing and you’re mostly prompting an LLM to make the decisions and implementation for you, what exactly is your contribution?
The ability to operate the tool isn’t much of a moat if everyone else has access to the same tool.
I don’t review assembly produced by a compiler because the compiler isn’t deciding what my system should do. It’s translating a program whose semantics were already specified. More importantly, that translation is deterministic.
A compiler takes a human-specified program and translates it into another representation while preserving its semantics.
If in five years I can give an agent a complete specification and reliably verify the resulting machine code against it, then sure, reviewing code may become obsolete and I’d happily stop doing it.
Also, keeping changes small isn’t just about making individual lines readable. It limits blast radius, makes behaviour easier to reason about, isolates mistakes, makes changes easier to revert and so many other things. None of those properties suddenly become obsolete because code generation got faster.
Do you think it's impossible for someone to have a 25K line PR / diff but not know what's going on in the system?
I ask because I've pushed some of this to the limit in my own testing and when I get the right building blocks / primitives in place in the repo, I'm able to get plans written in a way where I don't just describe what I want but specifically mention outcomes, verifications, constraints, etc. that utlimately describe the shape of my system and my intent.
My plan is my understanding of my system and the changes I'm making, and the execution of that plan (e.g. with subagents), verified against my spec, is the code itself.
With the correct building blocks, I've found that frontier models can write code in fairly predictable ways that lets me maintain my understanding and confidence in pretty large PRs.
I think perhaps the quoted part of your post seems to imply it's not possible / isn't phrased with that nuance?
For the vast majority of 25K-line PRs, especially AI-generated ones, I would bet money that the person opening it does not actually understand all of it.
If you genuinely understand the resulting system, then that's fine. That’s not the behaviour I’m criticising.
> bad engineers were always a liability
This part of the article hits home for me. With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization. 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 am still a firm believer in garbage in -> garbage out, AI is only as good as the abstractions and contracts you put in place for it. I don't subscribe to the idea that AI generated code is fundamentally bad, just that people lack the right skills today to wrangle agents into writing good code.
Earlier in the year I put together a talk for my company on what the future of architecture & design means for us in the career, I'm very proud of it and will share here in case folks have their own thoughts to share on the topic: https://youtu.be/SIZrt9Rt05Q?si=W57eirniWmoSFeBu
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.
But how many of those bootcamp people actually went on to get software jobs? One of the big criticisms of that whole phenomenon that I recall is that people were graduating them and then were unable or unprepared to actually get a job in the industry?
So how many people "learned to code" and then ended up back on non-software related careers?
The whole "learn to code" and software bootcamp craze always baffled me. Like what other profession markets themselves as "Hey, our job is so easy that any schmuck off the street can enter the career with 4 months of training." Practically every other job I can think of at a similar salary level has entrance requirements (e.g. grad school admissions exams), extensive and expensive training, a lengthy apprenticeship period and follow on licensure exams.
And more directly, I believe good software engineering is really hard. I think it takes a certain mindset to begin with that many people just do not and will never possess, and it takes years of experience to get a good sense of what works and what doesn't, especially with respect to the entire relationship between code, business, people and teams. Yet we constantly see all this devaluation of the practice of software engineering ("code was always the easy part" - bull-fucking-shit), often times by our own practitioners of the craft.
I mean, the obvious thing is that the "learn to code quick, code bootcamps!" drive was driven by connected people who were, as they are now, attempting to drive down the cost of software development.
Management types really really really loathe software developers for making good money, and have spent decades now jumping at any advertisement that suggests it can undercut the salary of your current crop of engineers.
Devaluing software developers has always been the point. Whether you take the cynical view of "They resent us for being expensive" or the apathetic view of "Capitalism simply wants to eliminate any and every cost by definition"
> Call me a gatekeeper if you want but, we ended up with a lot of people that just can't do the job.
Increasingly I am of the opinion that software engineering aught to be a licensed profession, similar to civil engineers, medical professionals, or lawyers. A board of peers to hold you accountable and a license that can be revoked at any time. Additionally legislation could be written to require such licensed individuals in safety critical roles.
I suspect the debate around AI assistance tools would be quite different if there was greater accountability for programmers and a constant threat of losing a license.
If you brick millions of machines impacting hospitals and airports, you should probably never be trusted to write code again.
https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_ou...
> software engineering aught to be a licensed profession
Only in certain industries, where outcomes can hurt people in any way. There's opportunity to engineer software in just about every industry, but I don't think a widget vendor that wants to connect to a WMS should be compelled to hire licensed anything. Of course, licensed engineers should cost more too.
Credentialing lowers the skill floor and increase every other kind of friction.
Civil engineering or medicine is hardly a desirable career model to follow.
Btw doctors make mistakes that kill people all the time. It’s a top 3 cause of death in the US.
"One bad programmer can easily create two new jobs a year."
-John Cook
In my previous job the entire DevOps team were terminators from the gym. I don't know when or how they were attracted to software, and why. There's so many other jobs they could spend time on and be successful rather than writing yamls.
Or it’s just the largely self-taught intrinsically curious autodidact developers and engineers have always been 10x and the “average” person in it for the paycheck is really what a 1xer has always actually been.
I think the industry highly skewed towards the former back in the 90s (and earlier!) when I first entered it. There certainly were vast differences between the best and the worst, but nothing like the gigantic gulf there is today between say a competent kernel driver developer who can get code mainstreamed into Linux vs. a boot camp style disinterested frontend dev who leet coded and brute forced themselves into a FAANG job.
Working closely with other white collar “generic” jobs and the folks who just show up each day and are not interested in the fundamentals at all make me believe this is kind of the baseline for most industries.
Most folks are in it for the money and are happy to just be good enough to not be fired. Since most middle management is utterly incompetent at performance management the results tend to not be great for pretty much the entire corporate white collar industries. A stellar manager though really stands out in such situations, but they are so rare many won’t work for or with one their entire career.
I also have a suspicion that people’s microdistributions of talents is underappreciated. Some people are good architects and average at algorithms. Some people are unusually good at debugging or QA. Some can spin out whole systems at an impressive speed that may not be a great long term fit for the larger system.
And most businesses aren’t managed in a way that’s interested in adapting to the microshapes of personnel.
I think this is one of the beauties of AI -- filling in the gaps to help people make their microtalents shine.
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.
When I worked at a particular fruit company in Cupertino, my boss had been asked repeatedly by the developer teams to provide a tour of the data center we'd recently finished building out, which housed the servers their code ran on.
He gave them a lengthy, grueling, hyper-detailed tour of the entire facility, encompassing the HVAC systems, electrical systems, network and computing systems, finishing with about 20 minutes where he had them stand inside a hot aisle that he was just outside of, giving a fantastic soliloquy on the importance of code efficiency, and the consequences of ignoring it. It was hilarious to watch from the comfort of the cold aisle, knowing full well what he was doing.
What did the software engineers hope to learn from this tour?
The scale of a cloud datacenter is pretty awesome to witness. I had the opportunity to visit a large cloud company’s data center years ago, it was immense in scale and (mostly) very well thought out.
What was he doing? Showing them that bad code will make them feel hotter?
Busy servers generate more heat. Inefficient code makes servers busier. There’s a real physical outcome for bad performance code at scale.
But you don’t really want lots of idle or underused servers, aside from burst capacity management. So if they universally and consistently wrote more efficient code I’d expect a smaller datacenter. Full of still busy servers but just less of them.
He was showing how complex and expensive a data center is and giving them real-world visceral experience that inefficient code has real-world implications.
Maybe he got PTSD from being a former tour guide and this was his time for vengeance.
Exactly. For most of my career, bad engineers (or juniors who were earnestly learning) would struggle to even create output that compiled, let alone ran. And it would take them a long time to implement something poorly. So the blast radius from their incompetence would be limited. Today, a bad engineer can churn out ten thousand lines of garbage that actually compiles and runs, before my first cup of coffee. If not on a tight leash, they'll sink the whole codebase or inundate every senior person with garbage code review requests. The blast radius is unlimited!
> Today, a bad engineer can churn out ten thousand lines of garbage that actually compiles and runs, before my first cup of coffee. If not on a tight leash, they'll sink the whole codebase or inundate every senior person with garbage code review requests. The blast radius is unlimited!
The term for that is "10x AI engineer." Anyone who has anything negative to say about such people is just jealous of their insane productivity and speed.
The supposed “10x engineer” may simply be someone stealing productivity from everyone around them.
You measure the output of one person while ignoring the cost they impose on their team.
If I generate 10 PRs in a day but three engineers now have to spend the next two days reviewing them, figuring out what I changed, correcting bad assumptions, debugging regressions and explaining why half of it needs to be redone, I haven’t become 10x more productive. I’ve just moved the work onto other people.
Worse, I’m consuming the time of the people who are usually the hardest to replace and whose attention is already scarce.
That’s why PR count, lines changed or features “completed” are terrible measures of productivity. You can make your own numbers look incredible while reducing the throughput of the entire team.
FYI, your comment showed up as [dead] like you were banned until I vouched for it, but I don't see any reason for that. Just thought I'd let you know in case you want to follow up.
Thanks for letting me know. I had no idea. I’ll follow up with the moderators.
> You can make your own numbers look incredible while reducing the throughput of the entire team.
Taken how some companies award promotions and bonus this is actually a double win. You not only improve your own numbers but also make this of your competition worse! /s
If your company has bad engineers cranking out 10,000 line PRs your engineering culture and product was already bad, I guarantee it.
It's not the whole culture and product, it's specific teams that do it. And trying to push back on teams that are "producing" is not a simple task.
Sadly AI also amplifies both the good and the bad managers and tech leads. If you have managers who fail to set a clear direction or tech leads who fail to define a good framework for developers to operate within then AI just means the poorly directed developer effort goes further in the wrong direction faster. Meanwhile teams with well-specified goals and better structure and processes can exploit the benefits of AI tools much more effectively.
In the before times, a small dedicated team could hold back against bad engineering culture and intentional enshittification. Now the balance has changed.
> 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.
Sometimes this can be a death by a thousand cuts. Any individual change may not impact performance to a noticeable degree but when they're pumping out a 10x increase in commits it can be a slow decline.
Just look at how they're merging ~300 commits a week into bun.
https://github.com/oven-sh/bun/graphs/commit-activity
That really sounds like the kind of people who will complain in university about being forced to study calculus.
Natural consequence: Then they never grasped the concept of computational complexity.
O(n) Vs O(n²)? They have n, what's the difference? Python is fast enough. The only thing that matters is shipping features fast! Features! Our competitor will have this next week, we need to write code fast, everything else is a matter of adding more compute, which we will pay with revenue!
As a side note; There is plenty of useful math that many people need (or would benefit from) in the real world. Much math curricula is arguably poorly aligned to needs, as it emerged from various historical flukes of design-by-committee. Popular math curricula is not perfect by any means. I recommend looking at high school or college textbooks and considering whether it is well prioritized.
In principle I agree with you.
The missing part of mathematics education, IMO, would be to focus more into developing the intuition of what something means, instead of the current focus on getting some (numeric) results.
computational complexity was never part of calculus. Calculus is the math of continuous change.
You don’t learn Big-O in Calculus because it requires CS algorithmic concepts.
But the core question of “how does this behave as N -> \infty?” is asymptotic behavior (ie: limits) which were developed for calculus and are very much part of the foundational calculus canon.
I should add that text to the rant at my last paragraph!
The actual issue is not the "bad" engineers but the bad organization. While people are allowed to push and merge whatever crap is generated there is no point to do otherwise. Even if you do care about performance, "good" code your teammates don't and close more tickets and are better by many metrics.
If you are closing one ticket per week with "good" code but your teammate does three with "bad" code - it's actually you are a bad employee. Also they may say you are a toxic one.
A hackathon for performance improvement screams to me "you'll be re-interviewing for your own job." I don't foresee this going well for the company. Best case scenario: you wildfire churn all the chaff engineers which limits the company's throughput until they're rehired... with no expectation the new hires will be any better. You also lose A LOT of domain experience and are self-inflicting brain drain.
I'd try and push for some "lunch and learn" meeting where the engineers get lunch catered and in exchange sit in on a meeting where you explain your point of view. Without monetary incentive it'll be hard to change the culture, but not impossible (and food goes a long way in greasing the wheels).
> A hackathon for performance improvement screams to me "you'll be re-interviewing for your own job."
Not necessarily, great engineers do also ship temporary code they didn't have the time to trim.
Our process is of 1) make it work, 2) make it right and 3) make it fast; not necessarily that engineer had time for the 3rd step.
they meant application performance
If your company has sketchy process and minimal checks on the software quality, of course it naturally follows that they hire bad engineers as well. fortunately, that also opens up an opportunity to be a emergency leader with an eye towards promotion.
> If your company has sketchy process and minimal checks on the software quality, of course it naturally follows that they hire bad engineers as well. fortunately, that also opens up an opportunity to be a emergency leader with an eye towards promotion.
AI disease is encouraging "sketchy process and minimal checks on the software quality." QA has been eliminated from my team, and the QA engineers that are left have been declared to be developers now.
Gotta move fast, and I guess making sure the stuff we ship works was "slowing us down."
More like developers are now testers and nobody is doing QA.
> a emergency leader with an eye towards promotion
i've gone this route a few times in my career, it's very stressful and involves angry/panicked people and many all nighters. Also, the glory fades fast. would not recommend.
Also you don't get the money. Why pay for a job already done
The bigger issue (I find) is that the pipeline for finding those engineers is completely fucked.
Hiring pipelines that tested the wrong thing have existed for years but the problem is magnified 10x when you test for something that weakly correlates with ability at best which an AI can do better than a human.
This is leading to stuff like incompetent junior-level engineers being hired as principals.
My company's hiring process is basically: Can you code a product quickly with AI? Can you understand the generated code?
That's basically it. It is surprising hard to find people that can do both, but engineers are becoming much, much better at the first gate while flaming out on the second.
>be a emergency leader with an eye towards promotion..
You assume those people haven't already left, been kicked out, or were hired to begin with. We're not in a rational job market right now.
Do you have SLO/SLAs defined? Are you monitoring performance? CPU usage? Cost increases?
You should have plenty of data to review regularly and push back on any teams that are causing problems. That's a process problem and you need a process for it.
Trace the increase back to specific deployments, call out those teams, and make them fix their shit.
Yes to all, but it's just me responsible for monitoring performance/cost. I either push back or fix it myself, but I am behind. So this is an attempt to give/push more ownership to the teams.
The handling of backpressure is such a good example to distinguish bad from good engineering. A good implementation even presents all the typical "clean" code indicators: DRY, KISS etc.
Mind sharing where you're at?
Sounds like bad management to me
My company got rid of line management. I now report to a director with over 20 reports and barely any time for career development. Our performance reviews are AI generated and we’re losing engineers. The industry has gone completely insane.
This has less to do with bad engineers than bad policies and procedures. You don't performance test before shipping to prod? you get what you get.
Startups have limited resources, we prioritize the best we can. As a staff engineer it's my responsibility to bring this to my company, but it's not an overnight process.
why wouldn't you use those limited resources to test things before they go to production, instead of creating more crappy things that go to production?
From this argument, it sounds like your company is making a rational choice to go with what you’re seeing. Even if you don’t like it.
> > 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.
It's all about the process and the organization. No one is pushing for quality, everyone needs more features.
>>a rapid decline in software quality
It's hard to expect anything else if budget for QA teams is reallocated to cover llm bills.
> With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.
I think the real pain though is that AI also often removes the feedback loop between "good" engineers and "bad" engineers. A lot of "good" engineers started as "bad" engineers that learned, sometimes the hard way and sometimes with patient mentorship, how to be better engineers. Patient mentorship becomes harder as code reviews become less personal. "The Hard Way" becomes harder when the consequences get divorced from actions. For a bad engineer it becomes "Claude broke Production" more often than "I broke Production" and learning mostly ceases.
We're starting to recognize how many junior developers AI is replacing, making the pipeline to senior developers harder (if not disappearing), but we also maybe aren't focusing enough on how much we are also losing the pipeline from "bad" to "good" engineers.
> 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.
I agree. Why is everyone so hard on everyone else? Look at the outages Anthropic and OpenAI have had. They aren't hiring stupid people but they can't seem to go a week without major platform instability. And you can't even argue that it's because of high load because all of these engineers have worked at Facebook, Meta, etc. They are seasoned veterans that should be able to build resilient systems.
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?
>> Egotistically, I don't even mind, it's just the salary hit that would be the main issue.
This is whare I am right now. Even senior positions have dropped 50-60K in range so I've effectively priced myself out of a lateral move because I would be taking a massive hit in salary for the same role I'm doing now. I'm currently at a company that continues to lay people off in lieu of offshore talent and AI. I'm stuck in a weird state of purgatory.
>> Should I just apply for a managerial role and in the cover letter state management is my intended path for growth?
I know many of my friends in senior dev roles have put their resume in Claude and said they were interested in moving into a management role and had Claude revamp their resume into something that was more management focused. Three of them were hired quite quickly not only based on their dev backgrounds with mentoring, training and light management of junior devs, but having enough emerging AI skills they said helped them close the deal.
Interesting. Thanks for that last anecdote. I feel you on the weird state of purgatory. I'm confident we'll find a path forward, though. Gotta keep your head up
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.
> 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.
The easiest way is to actually review the prompt input, put it through a LLM to catch the typical missing steps and automatically forward the result as review comment to the MR.
Let the LLM wars start!
> 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.
A good engineer, without LLM assistance, will still produce great stuff.
Yes, but much more slowly. And if they realize halfway through implementation that there is a better way to do it, but they are under pressure to deliver, they wont have time to rewrite it and will live with the consequences of that decision forever
> And if they realize halfway through implementation that there is a better way to do it, but they are under pressure to deliver, they wont have time to rewrite it and will live with the consequences of that decision forever
I've never really seen that. What I've seen is the much pragmatic take of marking the source code with a few comments to highlight the problematic areas and then goes on with the implementation. Refactoring can always be done later when the first batch of value has been extracted.
There's always tradeoffs to balance and perfection is something you inch towards, not something you get done in one go.
"Slow is smooth, smooth is fast."
...as Mickey Mouse was fond of telling me as I waiting for the ride at Disney World. Or it was my drill instructor. can't remember which.
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.
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.
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.
In retrospect, the golden age was the pre-internet era. Some rose-colored glasses maybe, but as I remember it:
Paying for software was the norm, so it was more clear what the "product" was, and software writers had a direct incentive to write better software.
Updates could not be pushed out so you had to be pretty sure your code worked before you shipped it. Having to ship physical media to all your customers for a bug fix was very expensive. Any new release was a big deal, so you had to put some real thought into what features it should contain.
Significant amounts of your development time were not spent trying to work around browser bugs, or differences in browsers, or supporting random old browsers that your customers still use for <reasons>.
Stack churn was much slower. The feeling of constantly trying to keep up with a treadmill was much less.
Users, while often not technology experts, were a much more competent slice of people than the general public who showed up when they got internet service and a computer at home.
The only ads were in print in trade magazines or publications like Computer Shopper. Yes, people actually used to buy a magazine that was nothing but ads.
You're right about those things, but you're forgetting that we had no source control, and almost all software was closed source. You took what you were given and you liked it, and you developed strong attachments to particular versions of software which you clung to well beyond its use-by date (like Python 2.7). MS-DOS 3.3 forever!
I started using SCCS in the late 80s, then RCS, then CSV, then subversion, and finally git.
We had version control in the 70s with SCSS and then RCS. They were primitive, but a lot of software were only a few files.
In the 80s, source control was like networking. Yes some orgs had it (mostly academia) but the rest of us just had a precious floppy that we copied the known-good source onto.
We had an own good-releases directory in our svn repository! That's when you realize old habits are hard to change.
Going to CompUSA and looking at the back of the box for not only video games, but spreadsheet and translation software, too; was awesome. As a kid I always wondered about the adults who needed such software as the back of the Deus Ex or Shogun Total War boxes captured my imagination.
Since it sounds like you built software during that era, thanks. Thanks for the memories.
I also consider myself a fairly good pragmatic software engineer. I have led small (3 engineers), medium (15), and large (100+) teams.
To me, the best time was late 90s, early 2000s. We had a lot of autonomy. People would just trusted that we knew what and how to build it. I could focus on building a great product. Overtime, we lost control, to the point that we now work based on jira tickets made by managers or product owners with one tenth of the experience that we have.
I definitely hear about segments of the industry being like that, but FAANG and adjacent generally isn't. Engineers are expected to display ownership of a problem space (scope depending on seniority), navigate ambiguity, and manage their own time.
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.
> 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.
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.
Alternatively, cutting out labor just results in mass poverty except for the moneyed few, and a new era of technofeudalism.
It seems pretty clear that the current crop of executives strongly prefer the latter scenario.
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.
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!
Totally agree with your framing here, but that is also what I fundamentally consider "good" code -- it's code that solves the problem that your customers/business needs without making it _harder_ to solve the next problem.
There are valid situations where the best code you can write is code you never look at and throw out the next month; there are equally valid situations where the best code is well thought through and reasoned abstractions for an area you expect to become core to the business in the near future.
Thanks for the wording on your first sentence there. I've been trying to figure out a way to get that thought expressed succinctly.
I think with AI coding, what we call "good" code changes. Lots of abstractions really only exist to help load the context into the human brain so that they can solve the next problem. If an agent can just search and find all the places to make a change, or to duplicate code with small changes for the next problem, is that bad? Does is just feel bad because that's not what we're used to?
We use structured looping instead of gotos because that makes sense to us, but the compiler still turns it into jumps in assembly. If our interaction is now at a higher layer, do we need good "code" or do we just need good "architecture"?
I don't know, but it's just something I've been thinking about lately.
Using context always means there's less for something else, whether you're a human or a machine. Abstractions that localize reasoning and help load the context into a human brain are ideal for machines and humans alike.
I tend to find that this perspective comes from people working on relatively small or isolated projects.
On a large system, the customer being happy today isn’t enough. You need other engineers to be able to understand the system.
Have you ever been on call and been woken up in the middle of the night to fix a production incident in a system you didn’t write?
If everything you build is small, isolated and easy to replace (basically fire-and-forget), then yeah... who cares? Ship the ugly thing, get paid and move on.
If you’re going to be working on something for the next 5+ years, you should definitely spend some time thinking about what you’re doing.
This is a great point. I find myself in the middle, where I appreciate and look up to past coworkers who were way better than me at attention-to-detail, but I have a tendency to focus on delivering actual results quickly with maintainable and easy to read code. A lot of engineering teams go into their own world on adhering to best practices with no eye on inefficiencies in the process that causes days of delay because it makes them feel better. I definitely believe in shift-left (findings bugs early saves a lot more time than finding them in production). I believe in balancing fast delivery with quality/process.
If you're writing CRUD, there's no excuse not to write it competently since you're not solving a new problem
In my experience, those that can’t understand design in the small (code level) don’t understand it in the large (sw or systems architecture) either.
Doing the right thing for the customer is independent from good design and good code. It’s a problem of requirements and project management. This is an excuse some poor programmers use, that they can’t write good code, but at least they fulfilled the customer requirements :D
"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.
> 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.
They’ll care when nothing works, nobody seems able to fix it, building new features takes forever and every change breaks something somewhere else.
This was already happening before. But now, a lot more companies that previously might have taken many years to reach an unmaintainable state can now get there in just a few months.
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.
I don't agree here. Yes Claude is great at following patterns, and for very standard tasks (e.g. "add this HTTP handler" which can copy existing patterns for database transaction management, session management, authentication, etc etc) it does great! The problem is that when you do something that doesn't quite fit int an existing pattern, Claude will optimize for solving the task at hand, producing code that doesn't use a sensible architecture. Doing things like checking user credentials or establishing a database connection deep in domain logic.
If you're a good dev, you can totally prompt Claude to not do this and correct itself, that's not an issue. The issue is that bad devs won't even notice this is happening in the first place.
Strong disagree. A lot of AI development still requires good engineers to keep tight leash on it so I'm seeing more bad developers create a feature until we need to iterate on said feature and we find AI did such a bad job that it becomes extremely difficult to do so.
AI is very good at making the bad dev's PR look plausible and be green in CI. And thus, merged.
If those bad engineers are in a very well defined box. Give bad engineers greenfield and watch it implode
A bad developer with any current frontier model will happily produce syntactically correct code that is unreadable, in a spaghetti architecture, and write an elaborate test suite that tests all of the wrong things.
Less sloppy in that it's clean and consistent looking but much more sloppy in the AI good looking non-sense way.
Just like compiler-generated machine code, then.
Jury is still out here
> AI tends to write less sloppy code than bad devs, and test/validate it more rigorously
I've often had it test and benchmark against the wrong things = no test.
It also writes over-engineered code. So yes sort, maybe.
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.
Great talk
This is great.
We now need to talk about the 10xBad engineer.
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.
Despite the title this article doesn't seem to be saying anything about the "middle class".
What is A&D? Shouldn't it have been defined in your comment?
Fair point! I edited my comment, A&D -> Architecture & Design
What about the video's title?
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?
The difficulty of producing code WAS one of the circuit breakers.
We had tests, CI, code review, QA, architectural reviews, etc. None of those disappeared. But they were designed for a world where producing such a large amount of change was impossible.
Tests don’t solve that. Tests can tell you that the behaviours you thought to test still work. How many times have you had a completely green CI with 100% coverage and still shipped a bug?
Trust actually does work that way though, the implicit and collective fuzzy agreement of “having my name on it”. Of course that ambiguity needs enforced automated checks, but reputation and one’s own integrity is not for nothing.
Generative AI breaks that agreement. It took me over a year to realize my previous CTO actually didn’t care too much about the system design he shipped . And the expectation was actually to just throw it away, have AI reimplement “what wasn’t working”. Use AI to ship, AI to learn what shipped, and AI to fix what shipped.
I quit because of it. Hell is working on other people’s AI code.
At different times in recent history, you could have also said:
> Hell is working on other people's NoSQL code.
> Hell is working on other people's Python slop code.
> Hell is working on other people's enterprise Java code.
> Hell is working on other people's Windows Forms/GUI Builder code.
To quote Jean-Paul Sartre: Hell is other people.
We had a dedicated QA team and an extensive test base... which we fired to reduce headcount, and we've trimmed back because we don't have the hardware resources to run those tests sufficiently expeditiously.
Secondarily, the business itself is also driving the throughput increases by demanding more volume, but there is no accountability to them for asking for throughput at the expense of quality. They may also deny the engineering time to work on things that would stabilize quality that supports faster delivery because features earn money more directly than developing quality processes.
This isn't coming solely from engineers wanting to produce more stuff faster.
Quality assurance and test plans don't catch slop. They just test your code. It can't prove the absence of bugs.
In general, the way we still do it is: some basic static analysis finding anti-patterns, but the meat of it is, and always will be, code review. Except you can't review code at the pace AI generates it.
Where I work someone is still responsible for the output. We expect developers to examine the code the LLM produces before burdening someone else with it.
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.
What you’ve described solves a different problem. You’ve put a lot of effort into making sure generated code conforms to your standards. That’s all good.
But do the people still understand what the system is doing and why?
You can have code that perfectly follows every standard and passes every test while gradually building a system nobody has a mental model of.
> an engineer only has to take a cursory look at the code
If that means you’ve automated away checking syntax and implementation, great. But we already had that before. If it means nobody needs to understand the change anymore, then this is exactly the risk I'm talking about in the article.
I think of it more as "the automation of the stackoverflow engineer". In enterprise software, there has always just been a non-negotiable large volume of code that was required to be written. This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code and punch every hiccup into google along the way. This hand off is no longer necessary as that same senior can just kick off an agent and have it handle the implementation for them.
I've heard some refer to this as a "nature is healing" scenario for the industry where if you only signed up for a high paycheck and didn't care to think critically about any of the work you're doing then this will be painful because that previously manual process has been automated. The floor of what's necessary to be considered valuable has been raised.
>This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code and punch every hiccup into google along the way.
This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
What tends to happen is that the EMs and PMs look at who’s free and give that person the task. This means that sometimes you get a senior leading a simple project and sometimes you get a junior leading/designing a complex project (usually with help from a very minorly technical PM).
Then the senior/staff/principal (often on a different “special” team) gets pulled in at the last minute to rescue the project.
If your company is highly product driven, you’ll often find that the juniors end up leaving projects more often than not because they will tell the PM exactly what they want to hear.
>This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
>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.
> There's also a spectrum of hard-to-easy in enterprise software but it's much more narrow than engineering code bases.
I'm not going to bang this drum too much, because it's been done to death for well over a decade, but lines-of-business supported by CRUD apps are rarely simple from an engineering perspective. Much of that engineering is in the decisions made outside the codebase, or spread across multiple codebases. If you're looking for the one obviously brilliant line of code to tip your fedora to while sipping your snifter of wine, you're not gonna find it. In fact, "clever" code like that is rightfully and instantly rejected as cowboy code.
By your reasoning, civil engineering isn't "real" engineering like aerospace cuz they don't build things that go really really fast and shoot out fire and stuff. Also, there's like too many responsibilities delegated out. Like, man, I only wanna talk to the guys who put the rockets on the thing. Everyone else are just overpaid slackers that smooth talked their way! They're gonna get replaced by AI! Mark my words!
>, but lines-of-business supported by CRUD apps are rarely simple from an engineering perspective.
You misread my comment as some dig at CRUD LOB enterprise coders. I used to work on enterprise ERP code with 20000+ tables. Yes, I agree it definitely wasn't simple.
Instead, I was responding to a very specific observation the gp made: he saw that both senior and junior devs were interchangeable when randomly assigning the next JIRA ticket.
That can only happen in a situation where the JIRA tickets are similar enough in complexity that the difference in skills between your senior and junior devs are irrelevant when the work is assigned.
Maybe some enterprise software teams can work like that. However, none of the engineering-heavy type of codebases can treat seniors and juniors interchangeably.
All engineers should be spending more time "planning" than "doing".
Even before LLMs, the coding tasks were less than 50% of the time spent on all my Jira boards in the past 15 years. It makes perfect sense that they are assigned based on available capacity. By the time the coding begins, it's already too late to worry about implementation.
You're right that small tasks are trivial enough to be assigned to anyone. That's the point. That's how it feels to work on the "good" projects regardless of complexity. Planning a complex project should result in more tasks, not harder tasks. Your epics and stories can vary in points, but your tasks should not. You want to keep them as low as you can with the time you have to plan.
If assigning to a senior produces better code, you're not spending enough time planning ahead.
> 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.
That's great and all, but that's a small minority of all software written. I'd love to work on projects like that but ultimately I have to pay the bills. Many software engineers are in the same boat I am.
Now I guess I'm just up shit creek because I built a career on SAAS work that was available instead of holding out hope I could get in at my dream job working on game engines or some other non-SAAS product?
Sorry if I sound bitter. I'm variations tired of hearing variations "If you only worked in SAAS you were always close to meaningless and now we've automated you so you don't deserve to earn anything anymore". Feels like every day.
Nor have I seen this "punch every hiccup into google" approach. Most errors are things that (a) you've seen before if you have any significant experience and (b) have a pretty obvious cause if you simply read the error message and look at your code.
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'm more likely to have several tabs of the libraries/language docs open than opening Google. And when I do, it would be just a faster way to get to the docs. After a while in a project, my history and bookmarks list is much more useful than a web engine. If it goes into months and years, it's mostly tweaking the code to solve some bugs, meaning a lot of reading of source code.
Oh I'd say its real. Years ago I worked as that senior who divvied up the work to a team of 4 mid-level engineers in that exact fashion (they were mostly Latin American contractors with limited english). We actually shipped some good stuff too!
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.
I'm there now. I have a team of low level engineers in Hyderabad and Bengaluru which can be useful but I have to spend a lot of time writing very detailed specifications and instructions to walk them through what has to be done. There are plenty of instances I can point to where it would have been faster for me to implement the solution myself, by hand, no Claude. Now bring Claude into the mix and I do not really have any use for these engineers at all aside from providing operational support during IST.
We're not too much an AI-friendly company yet, so we don't officially have Claude access, but I can tell with certainty that several of my Indian teammates are using Claude anyway. I'm pretty familiar with the style of code it creates. And the comments are decidedly better English, which is a big giveaway itself.
> This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
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.
>This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
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.
> If your company is highly product driven, you’ll often find that the juniors end up lea[d]ing projects more often than not because they will tell the PM exactly what they want to hear
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've never thought about it this way before but this definitely mirrors my experience
> but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice
I've seen a twist - not juniors but just offshore engineers.
> I’ve worked at a lot of places over 20 years
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.
While the picture painted here is viceral... I think the reality is closer to this..
Before AI, most big software was desgined and originally writen by a few key (founder-esq) architects. But they can only add functionality at human speed, so the team grows, and the quality of engineer drops as the functionality footprint grows. Eventually the functionality is much bigger, but most of it was written by a much lower quality engineer, and thus the code (even if functionally correct) is less efficient and less clean, and the big refactors a talented architect would have done never happened, so it just got bigger and bigger and more unweildy and bug prone and inflexible - until some new talented architects see the waste and build a startup to displace it.
With AI, big software can be entirely written by 1-3 people, plus alot of agent usage. Which means it can be refactored more, and the design kept cleaner. But this only happens if those senior architects are actually paying attention and controlling the design. If the agents are heavily automated and subtasaking and controlling the design, then nothing much changed, because the agents themselves are no better than the "stackoverflow engineer".
Again, this ignores the second order effect of entirely gutting the personnel pipeline that is required to create new senior devs...
So without a training pipeline to provide experience to jr. Devs, in 15 years we will be hurting for senior devs to replace all the graybeards. Kind of like the fortran crisis of the last decade or so.... Just across an entire industry that supports every other industry....
I think that’s a completely different problem.
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.
It's true that developing junior devs is challenging (but it always was), but that's not what this is about: This is about the kind of not-that-good, mid-ass programmers who make up the silent bulk of the industry. The ones who have 20 years of experience, but who you still wouldn't trust to write fizzbuzz.
Those people are doomed. Which is fine in a lot of ways, but will be devastating for their economic prospects.
Yeah. Technology and social change has done this all over the economy. E.g. from my dad's field, there's not enough public health people with field experience to replace the folks who are retiring. We have plenty of entry level people who can't get a job, but then there's a gaping hole in the pipeline between them and the graybeards who are retiring.
also who knows if prolonged ai development for years actually doesn't atrophy your coding muscles so to speak such that you are fully reliant on ai programming to get things done
by then we'll have an mfc, instead of trying to get llms to write code our prompts will compile and execute efficiently. after that inversion "programming" becomes "using language to describe some processing" it's just writing. knowing a computer language of old helps but not necessarily
> Kind of like the fortran crisis of the last decade or so....
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.
> 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.
Most jobs involving Fortran I see are not looking for a programmer, software developer, etc. They're looking for a PhD scientist in whatever scientific/engineering domain they're in who can work on Fortran code. They almost exclusively want domain experts, excluding most juniors anyway.
Pay them and they will. The problem with many people bemoaning the lack of Fortran and COBOL developers is that they are not willing to admit that the code they "need" to maintain isn't actually valuable enough to be worth paying what that maintenance costs.
It's like complaining that no mechanics work on carburetors anymore. Well some do, but they are expensive and not worth it to keep your old hoopty running. Might be worth it if you have a show-quality 1960's era muscle car.
It also ignores the effects of having a critical tool in the software pipeline controlled by a large corporation. That is an absolute sea change from the years when you could (and some of us did) run most of our software development on open tools.
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?
I think that smart companies (don't laugh, a few exist) will still hire juniors. Fewer, more carefully selected, but still some.
The StackOverflow devs being replaced were never going to become real senior developers no matter how much time was given to them. There is an entire cohort of people who were told to go to college for programming because it was an easy way to make good money, who did what they were told while having zero interest in it and never touching a line of code outside of work/school hours. Those people were never going to understand actual programming, all they were doing was copy-pasting code for a paycheck. Does it suck for them that they're being replaced by automated copypasting bots, yep. But frankly speaking nobody should've ever been paid 6-figure salaries to copy paste snippets from SO and jam JS library legos together in the first place.
They'll become managers and PMs and TPMs instead.
I have been a software engineer for 8 years and not once I have had a jira ticket handed over to me by a senior engineer.
I have worked in startups before and currently work at bkng, and have friends at uber. Everywhere it is expected that the engineers will create their own tickets and refine them with the team. If you are in a product facing team, your PM could even help you with a PRD but I have not seen one in the last few years.
By contrast I have not worked anywhere that engineers originated tickets. And thankfully, only one place that used Jira (but the engineers didn't interact with it).
Tickets came from the product side, after being evaluated and prioritized. Engineers got involved with estimating effort (in "points") and doing the actual implementation of course.
you're one of the lucky ones.
usually in most when engineers tend to create their own tickets - it's for useless shit like improve x, clean up y etc.
very few people have worked in places with high agency - where you work with a higher up & create a feature/product line that has customer impact. startups are one of the few places I can think of with high agency.
My last job was like that, it was miserable having no agency. The whole team was from fang companies and were all ok with the tell me what to do dynamic.
Do you think it's acceptable to do the work of multiple full time positions? I can't imagine it's very sustainable, nor healthy for you (both body and soul).
> This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code
I wish this were the extent of it nowadays. But for whatever reason, I've seen multiple really promising engineers get a hold of AI tools, and just outsource all of their thinking to it.
The self-infantalization is so bad that I was pair programming with a guy one day (partly to see how he was using AI) and watched him ask Claude if it makes sense to do X for every single decision.
I get using it as a form of linting... But you'll never learn how to be an independent developer if you constantly outsource your decision making. And it's disappointing too, because he was developing so rapidly as an engineer before Copilot came out.
I agree the time it takes to go from planning to deployed is condensing. I'm not sure the hand off is no longer necessary (though it admittedly often feels like it). Perhaps it means we need better ways of planning and collaborating faster and on larger features? So you still end up with a hand off, but it looks different, is maybe more detailed, or spans a wider implementation than we previously might?
I think AI is getting pretty good at generating the tickets as well. Not amazing, but it feels like ticket generation today is where code generation was a year ago.
I wonder if there's an agent harness that would work well for requirements gathering.
Not really in my experience. I’d much rather have just the prompt rather than the seven paragraph slop
That assumes you're the one that's implementing it. If the agents get good enough at figuring out specs, I'd expect you could just pass it along to the next agent for implementation -- vibe coding today, vibe speccing tomorrow.
> I've heard some refer to this as a "nature is healing" scenario for the industry where if you only signed up for a high paycheck and didn't care to think critically about any of the work you're doing then this will be painful because that previously manual process has been automated. The floor of what's necessary to be considered valuable has been raised.
I feel like this is a bit of cope.
Right now you still need to have some skill to guide these things correctly to produce cohesive and functional products, but at the rate we've seen them improve I question how long this will remain true.
what is so 'hard thinking' about building a crud app
Nobody is getting paid significant money just to build a simple CRUD app. Even before AI. Companies pay experienced engineers because the supposedly simple CRUD sits inside a messy real system with years of business rules, constraints, integrations and bad decisions have consequences.
The complexity I have seen in supposedly simple CRUD apps is amazing, especially what some less experienced people do.
... And Django and React removed ("stole the jobs from under") the engineers handcrafting html and jQuery web pages/apps.
If you stopped learning during JQuery's heyday, You deserved to have your job stolen. This is not the same as watching AI ruin software platforms.
Django? Django is older than jQuery…
This blog post illustrates the importance of NEVER outsourcing your critical thinking or outsourcing decision-making to an LLM. And to never take shortcuts with learning. Learning is hard, but learning things properly allows you to understand what is happening and allows you to ask the right questions about whether the changes an agent wants to make are the changes that will best serve the goals of the project (without creating an unwieldy level of tech debt in the future).
Personally speaking (and I'd love to hear others' takes on this): when using an LLM for work-related and development tasks, I never use the "full-auto" mode, and I never manually approve of something that I don't understand. When I don't understand something an agent wants to do, I go on a side-quest to learn more about said thing and to educate myself first. This takes extra time, but I feel that it's the right thing to do, so I can at least approve/deny/redirect from a more informed position, rather than flying blind and hoping for the best.
In addition to what the author discusses, I think skill-atrophy, stagnation due to complacency (i.e.: "why grow and learn if an agent can do it" mindset), and cognitive laziness are additional risks that come with overrelying on LLMs. Humans were meant to think. LLMs are a tool.
> In addition to what the author discusses, I think skill-atrophy, stagnation due to complacency (i.e.: "why grow and learn if an agent can do it" mindset), and cognitive laziness are additional risks that come with overrelying on LLMs. Humans were meant to think. LLMs are a tool.
I know it's a cliche but the old IBM adage holds very true today
Machines should work, people should think
Maybe that's part of the problem I have with LLMs writing code. It would be nice if they just did the work, but there's a lot of underlying thinking and decision making with software work that is being offloaded any time you have the LLM do it
It seems like those decisions are being handwaved off as "not important" nowadays. Just let the LLM make those choices! But that is not sitting right with me for whatever reason. Something I should think about I guess
The decisions are important, but the understanding is that you define them as constraints. Which is what a segment of the software community, the upper class if you will, has always believed you should do, even before LLMs were a thing. The LLM simply becomes a constraint solver: machines do the work, people do the thinking.
This is the challenge of the middle class developer. They aren't accustomed to working with constraint thinking and they're past the junior stage where one is expected to still be shaping their thinking so they are struggling to find a fit.
> They aren't accustomed to working with constraint thinking
That's one way to frame it I guess
I would frame it as "they have been abused by AGILE and impatient PMs into never actually taking time to do constraint based thinking or design"
It is impossible to think about constraints, or really do any proper engineering, if you are constantly "sprinting"
Edit: I also don't personally like engineering based on constraints. It feels like constructing a building based on where walls aren't allowed to go. I get that defining constraints and letting the software go is where a lot of useful emergent behavior lives, but I struggle a lot to think that way. Maybe I'm not wired right for software in the end
I have witnessed first hand this and must say is a disaster, the person that came up with a fix to an issue that I didn't understand tried everything to convince me that the automated fix works.
Indeed the fix did work, but when I asked him to explain me the problem and the fix he started to use the prompt to get answers.
At that point I just let it go, the only thing that I mentioned later on is that I'm ok with pushing that to prod if that was ordered to me but I'm not responsible for it.
I prefer to keep the bug live until I fully understand the problem, reproduce it, come up with a solution and maybe just maybe perform a check against what a computer generated.
Please note that the bug came from a real human code base but being complex and not familiar with that part of the code (moreover the code was handed to us without any type of support/documentation) rendered me in a weak position where I couldn't come up with a solution so far.
How can someone trust so much a computer generated hotfix without fully understanding a problem is what still baffles me.
Still resisting to use any aided coding, no LLM is not going to steal the capacity to use my brain. The day I'm forced to used these tools, the day I quit.
Between AI and competing against the world with H-1B, it's really never been harder to get an entry or mid-level software engineering job.
Which means our pipeline to senior engineer is completely broken.
For some reason people never mention this, but aren't there also much more people graduating with CS degrees than ever before?
Pretty much no other engineering field made sense to go into for about a decade. Even kids who did go EE, Mech E, or even Chem E ended up taking software jobs. The pay, benefits, and work/life balance of SWE just absolutely obliterates everything else. Or did at least
Exactly why it's got to be broken now
Exactly this. Went into physics but the academic landscape is hell so shipped off to SWE.
And how do you think people go from fresh graduates to senior devs?
Degrees take 4 years. It's a very laggy indicator.
Right. CS Enrollments dropped 8% this year. High schoolers got the message.
People can switch majors.
But despite me saying that, I think it's going to take longer than four years. It takes a while for people to realize that a dream is dead.
Some companies hire junior devs to adopt AI-first practices to then drag their seniors in the same direction.
This is a reliable recipe for turning your systems into an absolute clusterfuck.
should be a fun decade :)
Juniors to push the accelerator, seniors to pump the brakes. It could work.
I think the field is basically over as a long term career unless you are truly exceptional. It will become very easy to build most software, and the upper end will be filled with the top people in the country/from abroad.
Wages are certainly going down for most software roles
> It will become very easy to build most software
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?
My non technical wife asked ai to brush up the photo for her cv.
Ai did that with whatever cli tools were available and what it would write itself.
Ai is not a faster horse. It is a phase shift.
We won't see a gas station clerk write photoshop because we won't need a photoshop.
The majority of artists abhor AI, this is a particularly bad example.
Why ask such extreme stuff? Why not ask about the solo entrepreneur who creates a convincing iOS app without a programming background? Advantage the problem on the side of ML and look for winning scenarios today.
because this comment is responding to: "I think the field is basically over as a long term career unless you are truly exceptional. It will become very easy to build most software"
photoshop, paypal, and many more companies etc. have software of vast complexity that cannot be reproduced or maintained today solely with llms, ipso facto you still need software developers or some similar role to build and maintain the complexity of _yesterday_
some guy shipping an iOS app to zero users doesn't change that. although i think it is good we can have more bespoke software.
And today the line for amateur capability is being drawn at eager entrepreneur making an app on the back of Supabase and Lovable. The fact that iOS apps have zero users owes far more to sales and marketing than to software, so maybe that's where we should be putting our focus?
What can a mid level person do? Instead of a consultancy loaning out a team of 3-4 people, it might just be one person now. That could mean a lot of downsizing.
One thing mid level people wouldn't be counted on to do was create Photoshop or Paypal. The original thread is about top level pros being the ones who stay in the industry, right? That sounds about right if we're moving the conversation over to Photoshop and Paypal.
this is a more reasonable argument IMO, but i would still disagree that that means only the top level pros stay for a few reasons (although it might happen / is already happening in the short term):
- if it is true that AI enhances our abilities it just means the goal posts move of what was expected for each level
- the complexity ceiling will rise for the level a superstar or a company is capable of maintaining, meaning there will still be stratified complexities for the mid levels of old to handle, it might just be higher than before
- counter intuitively but time and again increased software creation more often than not increases demand for more software rather than decreases
if the world decides it has no more problems to solve with software, then we are in trouble. i don't think that is happening anytime soon.
You aren’t getting it. They can pay their engineers half what they used to, you don’t need the same level of skill to build photoshop. Yes, you need a bunch of engineers, but they will be driving coding agents, not writing code by hand. They can be hired and fired for cheap
Until the VC subsidies stop and the human devs are half the cost of the claude tokens lol
https://en.wikipedia.org/wiki/Moore%27s_law
Moore's Law covers transistors, not LLMs.
It won't be photoshop then. It will be shitty, buggy clunky app that costed a (major) fraction to develop but it will also earn a fraction. Companies like MS can afford this ie with Office suite but patience of markets and customers can allow them to go only so far, if ie Excel becomes semi-useless thats the end of Office and big cash cow for M$ (I'd say about time, that monopoly is not good for consumers at all).
This is in a way the same argument that all companies will use just boxed (albeit customized) software. In reality many, ie banks run their own custom software and for good reasons. Wake me up (in retirement) when any major bank decides to run their finances, regulatory stuff and transactions on llm-generated stuff made by underpaid devs like you describe.
This is cope, ai coding agents will follow the path of self driving cars. They will be watched with extreme caution, but will slowly but surely expand outwards. Eventually manually writing code will be considered a dangerous/bug introducing act
Every time I see people say this I think: show me the money?
If its so good why aren't you rich?
Why would anyone get rich doing something easy?
Because the companies everyone claims are now obsolete are making a lot of money still doing the supposedly obsolete things?
In the "iceberg" of boring company systems I see working day to day I actually think delivery of production software has been slowed down. The cost of "writing" code went down a bit, while validation costs positively exploded.
There are definitely more apps developed these days but I haven't seen anything much vibe coded which actually seems to have staying power. Everything is prototype quality.
Now you can make a prototype without understanding what's going on internally or why the prototype wasn't good enough!
the future is already here, its just not evenly distributed
See this is the big issue I've been seeing. The only vibe coded product I can think of off the top of my head that's succeeding at all is Bun, and maybe I'm behind the times but it feels like Bun's success is mostly being pushed by Anthropic; I've yet to see much other than Claude Code use it.
All fields are basically over as a long term career besides perhaps prostitutes and even there I'm not entirely sure. But the questions of how soon and by how much matter a lot. Being early is the same as being wrong a clever guy once said.
I hear you, but just to pedantic.. prostitution is certainly not a long term career either.. never has been. After 35, you're not going to find work as a sex worker..
no programming is verifiable, and the major LLM companies are focused on it. its the first domino to fall by probably 5+ years
If you believe that I've got a halting problem oracle to sell to you.
I think this is true.
A lot of AI believers (me too fwiw) seem to forget it’s a lot harder to ‘close the loop’ on non-code projects. I think this is because they are usually coders.
That's what all AI believers get it wrong about programming. Code doesn't create products, humans do.
Is it really that simple ? A programming function that has set inputs and determinstic outputs is rather verifyable. A ten million lines code base is not easily verifyable. Knowing whether an agent is improving when it's working on a huge codebase is not that easy - it could easily start hurting code quality without it being clear in any output.
> no programming is verifiable, and the major LLM companies are focused on it. its the first domino to fall by probably 5+ years
Which is kinda proof they're populated by sociopaths with extremely little empathy. The people who are building that stuff are programmers, and if they had a tiny bit of functioning empathy they'd stop or slow down or at least be unenthusiastic.
And we're not talking about very high level empathy here, but the very basic kind of thinking about the effects on someone very much like yourself.
I agree. And I would remove the basically. I give it five years before essentially just a few very senior people are managing the whole cycle. Downward pressure on wages is just gonna keep ratcheting up.
nah the world needs more software - it's just the delivery mechanism that's different.
we are entering the world of smaller service firms (1 - 3 people) - where technical chops will even get paid more. the age of cookie-cutter apps is over.
Only if you run out of things to write. Is your back log ever empty?
My backlog is less empty than ever - it just happens to be overflowing with whispy Claude-written tickets for functionality that somebody else's Claude suggested after summarizing some other Claude-infused Slack chat.
ofcourse not, but they can pay someone 80k a year to work on the backlog, whereas maybe they used to pay 175k. its not about work going down, its the skill set needed to complete the work is lower than ever, and they need less people than ever
they won't even need that as agents talk to their own lanes in some Linear project management workflow that your sales team agents are connected. The entire system is going to end up agentic and even the CEO will be out of work unless they are founders and owners of the company. We'll all have our own business this way. Or it all collapses. Time will tell.
i think this is farther off, much sooner is just the subjugation of technical workers to be low skill drivers of LLMs
color me skeptical that the CEO or anyone non-technical is ever going to prompt their way out of a major incident when all the AI chickens come home to roost.
Maintenance will be forever. Tax laws change annually, so the payroll app will never stop being updated.
I don't accept that argument. As I see it, laws should be structured as data rather than code, using a clean non-Turing-Complete DSL for any embedded logic and calculations. Maybe there would still be occasional situations when new software features are needed, but it should be a rare occurrence rather than on every new change.
People just need to add/subtract an input box and update the tax rates. They don't need an ontology of taxes and goods.
> laws should be
You are comparing what it is with what should be.
I'm hopeful that software will be applied in new areas where it was too costly before, with AI help it will be possible. Software will be cheaper, even more prevalent, lower quality in since respects, but SW engineering will still be a viable career.
There are really a ton of fields where people have done an absolutely terrible job of properly using the advantages of software, even pre AI. Like, even today there are people manually drawing footprints in PCB design software, manually determining what pins carry differential signals, manually forgetting to swap RX and TX lines.. except for the functions they absolutely had to have a computer do, they forgot to move out all the drudgery and footguns and continue operating in "PDF space". It's embarrassing for a profession that is supposedly made of engineers.
PDF space is still more advanced than the people typing into "word processors" however. Making software to emulate letters was such a massive mistake for the trajectory of computing, it let people effortlessly "adopt computers" by making a digital facsimile of their terrible analog processes. Only with AI we now have the ability to digest all this unstructured mess.
No one said there won't be work to be done, just that fewer people will be doing it.
If the work to be done is infinite, why would there necessarily be fewer people doing it?
Because most companies aren't software driven, they sell physical products and software is a cost center.
There is a budget and when it is gone, no contractors until next budget round.
it could mean they are not completely out of automation opportunities, and will lose to more innovative players if won't invest into software. The end state of these companies is grid of cheap robots controlled by software.
Exactly, because the amount of people on bench due to robots doesn't scale with the amount of customer opportunities.
There are only so much customers to chose from and all of them have finite budgets.
The exponential growth curve only exists in MBA books.
In case of productivity surplus, exponential demand can be easily created by government: e.g. they print N trillions dollars, and say we spend it on some (hopefully useful) mega project(s): fusion, carbon capture, give nice home to everyone, fully verifiable, glitch free, hyper optimized software, etc. It will immediately create lots of demand, supply chains, customers, etc.
You can see current AI hype as example, and its government didn't step in and printed N trillions yet.
Sure, and I have a bridge to sell, to the same government.
In a few years, it just might.
If maintenance and security is fully automated and for small changes or a small feature you will only dump some spec document into your agent platform, for sure.
> In a few years, it just might.
If you're in a product company and your development backlog is empty, run. That company is about to go out of business.
Just another 6 months bro, only another funding bro, I promise, all devs will be replaced bro
I have stupid question here. Why they sell tokens instead of AI generated full application and AI fixes to your code without you needing a single dev?
Because selling shovels is more profitable than digging holes themselves.
Wait.
Yes, when the project budget runs out and contractor team has to leave.
Fascinating how using immigrants as a scapegoat penetrates people minds so easily at all levels of society and education.
It's not a scapegoat, it's basic economics that wages are determined by supply and demand; increasing the supply decreases wages. It's also basic economics that this ultimately reduces costs to consumers, but that doesn't make it any less painful for the workers whose wages face downward pressure due to increased competition from labor force growth.
Never heard the words "basic economics" used outside of strawman political arguments. To think that H-1B developers can meaningfully shift the supply to the point that is felt by other people it's very shortsighted. The job market has been very difficult for years with vastly more supply than demand and its due to plenty economic, financial and political reasons. Interest rates itself affect it way more than any H-1B developer could ever do it. If you were to actually sit down and look deeply into it and look at the data, I'm sure that H-1B would be a small percentage of the problem and you would get fired up about so many other things.
But that's difficult and time consuming, if anything it's advanced economics and requires effort to decode what's happening. What it's very easy to do is getting angry at a group of people and to feel deep unfairness about it, then think that if that group of people were to leave, the problem would improve or be solved. That's exactly the kind of thought that seems to be so pervasive at all levels and yes, it is a scapegoat. Especially since that the only merit someone has over H-1B is to (by pure chance) having being born in a different place. I really feel that many people complaining against H-1B wouldn't even qualify for it if they were born somewhere else.
What if the new entry level is what we consider senior today? Isn't it possible today to obtain entry/mid level skills with LLMs? I wonder if things will shift more in that direction.
People have been fretting about 'foreigners' taking their jobs for decades and it never really happened. This is all about LLM's.
I mean, think about it; just a few short years ago there was a very strong market for software engineers, despite outsourcing and immigration being very much part of the landscape.
Orrrrrr... it could be a complex combination of outsourcing, an over-reliance on degrees, LLMs, a lack of "apprenticeship" mentoring, etc etc etc.
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.
I'd also throw in hiring practice. Whatever we're doing (across the board) to find candidates seems....less ideal.
> outsourcing, an over-reliance on degrees, LLMs, a lack of "apprenticeship" mentoring,
Which of those things changed (along with higher interest rates) in the past few years though? All the other variables did not change. They were present 5 years ago and present 10 years ago too. To me that's indicative that those factors are not the cause of a soft market for software engineers in 2026.
Are you seriously suggesting that ten years of a systemic failure to mentor the new generation hasn't had an impact on the culture of mentorship?
Are you saying that precise thing changed 10 years ago and hasn't always kind of been with us?
I am talking about the weak market for software engineers right now and what caused it.
Erm, no. I'm saying that the entire industry failure to cultivate a wide spirit of mentorship is biting everyone's ass.
I mean that could also be true, but it is not - IMO - the cause of the fairly sudden weak market for software engineers.
IMO it is and I've been saying it for more than ten years that it would catch up with the industry. And it is now. The LLM shit is just a mask over the larger problem.
The front fell off because the base was never built to support a shakeup of the industry. There's so little support, now and for as long as I can remember, for people to fail gracefully in the field. It's just up up up. And now that programmers are finding their jobs to be a little more precarious, maybe folk will start supporting mentorship as a practice.
This isn't just a "market" problem. It's a problem of people not teaching others skills that help them thrive inside AND outside of work.
My job was just taken by Cognizant, which is technically American, so I guess you're technically right!
have you been inside any big tech company? lots of orgs are > 80% foreign.
Yeah my new VP is from a certain country in the eastern hemisphere, and the interviews I've conducted for US-based candidates oddly enough have been 100% of engineers from that same country (say 30 or so in the last 2 years).
I hope one day there will be huge class action lawsuits and prosecutions given how clearly obvious this issue is.
That's not actually true; people have been complaining about this for decades, and it's never been the zero-sum game that they claim it is.
I mean, I wrote this 12 years ago in response to similar discussions on this same site, and in the intervening years, we had a great market for software engineers: https://journal.dedasys.com/2014/12/29/people-places-and-job...
What has changed is 1) the zero interest rate environment went away and 2) LLM's.
ive worked at multiple FAANG, almost always been the only american on a team of 10. theres some huge push by corporations to deny it to justify shipping in more foreign labor.
There are 100K H1-Bs a year and 4 million grads a year in the US. Anyone who thinks H1-Bs are actually contributing to their inability to find a job is a moron.
But those H1Bs all come for a very narrow set of work - mostly software development or other adjacent roles. So your 4 million figure that counts all graduates in all fields doesn't make sense when we talk about tech.
There are around 100k U.S CS graduates . You're telling me 100k H1-Bs don't make any impact on them?
You're counting only CS bachelors, in reality there's 400K graduates a year in software engineering fields.
There's also only 60,000 H1-Bs a year for private companies.
Lastly the majority of H1-Bs doesn't go to software engineering jobs, it's around 30-50%.
There's also basically no US company hiring juniors via H1-Bs, so yeah, I'm saying it doesn't make any meaningful impact.
30K H1-Bs versus 400K grads...
> There's also only 60,000 H1-Bs a year for private companies.
Actually, more like over 80,000. They have a separate pool for people with advanced degrees (MS or higher) in tech fields.
Agree with everything else.
The way you handled those numbers makes me think you have leadership potential, perhaps even U.S presidency material
-85,000 NEW visas granted each year, not including renewals - The mass majority of those are going into the tech/software - there are only around ~100k CS graduates each year - H1B workers will take much lower salaries and benefits than their US citizen counterparts.
And H-1Bs are easier to overwork and abuse because the threat of deportation and the dangling carrot of citizenship are very powerful motivators that don't exist with US citizens.
have you been inside a big tech company? there arent many american fresh grads working there, its mostly foreign
Spend some time processing tech job applications and you’ll realize you’re wrong
Take a walk through South Lake or San Francisco and he'll realize he's wrong.
Agree with the article the way I think of it is basically like before AI good engineers put in effort either currently or over cumulated years of experience.
A bad engineer has been lazy for years and will never change.
You likely have experience with this already first hand. Ever had a lazy day and just hit "yes" "continue" on the AI over and over? I've had to revert entire days of work because I was so burnt out I didn't put effort into the design.
A good rule of thumb though is if an AI can't solve the bug and fixing it creates more you have a bad abstraction and architecture that needs a gutting and rebuild from near scratch.
>AI makes projects with weak engineering culture fail much faster.
>There used to be a time when people sat down and talked about how they'd do something. Now they can just prompt an agent for a few hours and open a PR.
>The most tragic aspect of this way of working is that, to the untrained eye, it works.
>If you pull the branch and test it, you'll probably get something somewhat functional. So what do they do? They keep going. Again and again. Until the project reaches a point where no one knows how anything works.
Isn't this the opposite of failing faster, it lets people who would have never made it past the first few hurdles and give up get deep in and then the false hope that they can then prompt their way out of whatever mess resulting in deeper and deeper spaghetti.
But now they can now move so fast that nobody has a realistic chance to stop them before the damage compounds. They get into a much deeper mess much faster.
We always talk about damage, what's the damage here?
You deploy an application that ostensibly has the desired capabilities but it fails at scale, or the architecture is not extensible to add new capabilities or fix bugs. Those are expensive mistakes and in safety-critical domains could be deadly.
The thing is I've worked on plenty of code like this written by humans. AI just accelerates the process and puts this type of code within reach of more people. It could be seen as a step backwards in good software engineering practices we've painfully learned over the last two decades. I see it as a cycle repeating itself in a new iteration, with the hope that we'll end up with still better tools and processes in another few years. But I agree it can and will result in real harm in the meantime.
A giant pile of unmaintainable, brittle code nobody understands. At some point, even LLMs struggle to make changes without introducing bugs.
Code that accidentally ships every 100th order out for free... exploits releasing customer PID and causing regulatory nightmares... self-driving cars that reboot at 70mph... The only limit is your imagination!
For example, doing a marketing push assuming that the app works, and then having it fail in trivial ways at release.
Waste of time and therefore money is a big one.
The next decade of software consulting will be defined by repairing the Big Ball of Mud https://www.laputan.org/mud/
> Now they can just prompt an agent for a few hours and open a PR.
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??
Now the question is - no one was born good or best engineer/programmer/scientist. Often it was a long path of sleepless nights, daily grinding, failing million times, doing dumb mistakes along the way, the usual package of suffering sometimes called "experience". What is the path now for the next generation of good or best engineers? There will be no opportunities/budget to do the same anymore.
"The underlying purpose of AI is to allow wealth to access skill, while removing from the skilled the ability to access wealth"
AI gives the skilled more ability than ever before to create wealth; they can realize an idea by themselves and a few hundred dollars of LLM spending, that would previously have been out of reach for anyone lacking the capital to hire 5-10 people.
That's not an interesting question, it'll be the same path as before but somewhat longer.
> You were never expected to understand every service and every database. But at least someone did and would explain it to you.
I agree with most of this except this. Think there’s some rose tinted glasses here or I’ve got bad luck over time.
Life before ai was bad as well. There wasn’t any one to explain to you anything! You had to figure it out yourself. The people either already left or was busy with something else.
No one wrote tests (to my standard). Most of the ops works was skipped. Docs were just not there. Nobody linted properly. Just bad mannnn
+1
the vpn is called dev-test-prod and some containers are stored in a dev subscription, but still used in production. Some intangible network error forces you to use the production cluster for testing (the bucket is at least called test).
I feel this kind of setup is invariant everywhere I go to do engineering. Fable level intelligence has no effect!
If there is any positive to be had from this, it's that we finally started documenting the codebases for AI as we should have always done it for other teammates.
It’s just the typical BS where a Hacker News wants to feel smarter than they are
From the title I thought this post would be about something completely different. The post is about splitting the world into "good" and "bad" engineers with an emphasis on the bad engineer. Ok but what does that have to do with the middle class? The post leaves the best part out.
What I thought the post would be about is the dissolution of the White Collar Kitchen Brigade The kitchen is run by the Chef but it needs the Sous Chef, Line Cooks, Kitchen Hands to operate.
Many software engineers have made a good living acting as the sous chefs and line cooks underneath the rockstar chefs, but with AI companies are inclined to turn the whole kitchen over to the top dog and their AI crew and the ordinary human crew is slowly being churned out.
Technology has been doing this for decades. I think a lot of our "K shaped economy" discourse is about the bifurcation of the upper middle class creating downwardly mobile educated young people. Nobody in my wife's immediate family finished college. She and all of her cousins are quite indisputably better off than their parents. My father in law drove a forklift at a soup factory. My sister in law is studying to be a nurse. It's a big step up. But the "white collar" middle class has become very winner-take-all. To use an example from my field, if your dad was a partner at a regional law firm, that path probably isn't open to you. Technology enabled consolidation and scaling, so you don't need lawyers in every city in the U.S. to be able to handle legal work there. Lawyers at national firms serving Wall Street clients are making more money than ever, but the drop below that has become pretty precipitous. The same has happened to small businesses all over the country competing with Amazon, etc. It's had a huge impact on the petit bourgeoisie.
Of course, this is economically efficient. Nobody is going to give up Amazon same-day-delivery so that some local small business owner's kids can live better than the median person.
Interesting article, and it makes a lot of salient points.
I think I can agree with most of it while also arguing that I don't think good code has ever had an honest measurement of quality. From an end user perspective, the end product either works or doesn't. Working terribly is the same thing as doesn't work and working well is the same as works.
What AI changes is the actual code part. The actual code lines output by AI is identical to or better than the best programmers. The systems design, architecture, QA, integration into existing legacy systems, to just name a few, is where the strengths and skillset lies.
In order to be a good engineer, you have to be a systems thinker. AI or no AI does not change that. The entire picture has to be taken in to account, and I think this is going to obliterate the vast majority of engineers who cannot or don't want to think about systems. It's no longer about putting on your headphones and outputting code. It's about having to interact with other humans, systems, architectures, organizations, and an API or MCP is not going to help with that.
I truly do feel bad for terrible older aged engineers, and the young new grads. I think it's unfair that a lot of new grads were told that CS was a great career, only for them to start their freshman year before AI, and then graduate when AI coding is in full use at nearly every workplace.
> Fixing it would require such a colossal amount of work that it would be impossible to even start justifying it to anyone in management.
Bad news: by delegating the thinking to somebody else (Claude) you have become the management.
This is exactly how I feel about my job now. I'm the new manager. But honestly claude is better than any team of developers I've ever had working under me. It does exactly what I ask it to, in 10 minutes instead of 3 weeks. And apparently we can't afford a development team now anyway...
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.
Exactly this for me too. I don't know how to feel about this overall honestly, I'm able to do so much more but now I barely get to write any code. It's weird.
A manager isn’t normally the person deciding how the software should be architected or implemented. Their job is largely priorities, people, coordination and resource allocation.
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.
Nooo. But seriously, that does appear to be the end result on most of my recent sessions. The time I spend is on correcting, adjusting.. dare I say managing the process as opposed to actively editing every aspect of it.
I think it is less about junior/mid engineers, and more just about the kinds of work inexperienced/cheap developers are often doing: assembly line, JIRA-ticket-taker type development.
This is especially impacting Indian tech workers in the US [0] since these are often the types of roles that InfoSys and other foreign tech consulting firms are staffing. The new $100,000 fee to sponsor an H1B visa has made it difficult to justify hiring foreign tech workers when most of the time they are just going to be using American LLMs to do their work anyway.
[0] https://thefederal.com/category/news/h1b-visa-indian-tech-wo...
I’d expect that layer of the industry to shrink substantially.
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.
What's with people using the number "0" for their first reference? I have only ever seen that practice here at Hacker News.
See https://en.wikipedia.org/wiki/Zero-based_numbering, e.g. “computer programmers might use zeroth in situations where others might use first”.
Lots of (most?) programming languages are 0-indexed so it feels natural for software developers and our ilk.
Not really. 0-based indexing is different from counting and starting with 0 in a counting context is weird. Would you ever say a set has zero elements when it actually contains a single element?
Hey everyone! I found the COBOL developer!
Look, stupid companies who use A.I. to generate their code will simply fail. Companies that use bright engineers to engineer their product and write code (and pay them accordingly) will thrive and thrash the competition.
Darwinism in action.
I don't believe A.I. will change much, but it will lead to winners and losers, that's certain. Lessons will be learned, A.I. will remain but play a minor role, just like IntelliSense and ReSharper.
People need to understand that when things break management will hold you accountable, not the A.I. If you can't fix it you'll be out of a job. So you'd better make sure that you understand the generated code and clean it up before putting it in production because you'll be maintaining it.
I think the worst part is that some companies may be okay with it. They will pay attention only when it's messed up beyond repair. And it’s possible that fixing it will be a task for more advanced models, not humans. Do they win or lose at the end of this martingale? I am not sure
> Good engineers have become more valuable because AI lets them move much faster. They don't need as many people around them just to do the implementation work anymore.
This would be true if the goal was to get good working code faster. But the actual goal is to get any code faster. So, in reality, it doesn’t matter whether you are a good or a bad engineer. It just amplified how good you are at manipulating the hiring process with your fine tuned resume and how smoothly you can talk your way through.
I got a person from my small team fired before the sommer holidays. Not that I wanted to, but he didn't deliver the quality that I was expecting from a thinking human with an engineering degree.
Adding AI to the mix just made things worse. I'm still finding issues in the codebase/documentation that I need to review, test and fix.
The replacement is being trained. I made sure that, while I expect them to use LLM supported development .. they own their contribution.
This is going to be a fun ride.
People should realize that programming is not a liability. Programming per se is the actual creation of detailed knowledge by writing.
You get a task, how does it interact with all other invariants? What are the implications on data flow, processing and user workflows? You can rarely answer those questions beforehand, you step on them during programming as the formal language forces you to take them into account sooner or later.
If you outsource this knowledge-building you’re losing the steering ability when stuff hits the fan. You lose the ability to navigate the code properly in order to identify bug or violations of invariants.
LLM optimize locally, that’s their nature. Invariants are often implicitly scattered around the whole code base. Explaining them to the LLM is much more tedious than just to write the code in the first place. At least for me as I have much better expression-ability in Code than in natural language when it comes to describing any form of computation.
It baffles me that someone can just send a PR without knowing the gist of how it works and why it’s done this way.
If you can’t answer this basic question then why tf do we even need you around?
One thing this post did not discuss is the enormous effort required to explain to the management why number PRs has increased and number of lines changes, which in their view, means explosion of productivity, yet one engineer is destroying the team's momentum.
I tried to touch on that with this part:
> 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.
It's not clear to me what "the middle class" is supposed to be here. All engineers exist on some spectrum between "good" and "bad" and it's pointless to try to identify the exact markings, but we all know good engineers and bad engineers.
So AI isn't really doing anything but giving sharper tools to both groups.
So, as it was before, we simply need to set expectations and remove those who cannot adapt and meet expectations... You know, the way it's always been.
So why is AI the problem here?
Rubbish article, waste of my time.
No confirmation for the title, rubbish arguments and logic.
> Good engineers have become more valuable because AI lets them move much faster.
Bad prediction. This is likely another AI marketing article.
I think that piece is half right and half wrong.
I think it's largely correct that hiring bad engineers is dangerous to the company. But that's always been true, especially those "hack out a prototype, get director applause, and leave it for somebody else to own" people. But management has usually chosen to keep such people around, because they can look good on paper (see how many tickets they closed?).
The question is really a management / business-owner question -- will managers/directors stop hiring yolo-engineers? Will they empower engineers to close PRs simply on complexity/size grounds? Will they fund refactors and simplifications as first-class concern? If not, it will be a problem, and I don't envy the engineers who try to be the glue at such a company.
- unrelated but from your blog
- you have a very nice article on how llms work here https://blog.florianherrengt.com/how-llms-work.html
- but in your diagram titled "Word vectors plotted in semantic space" dont you think you need to add arrows to show where those vectors are actually pointing?
- because i dont get how you arrived at this Using vector arithmetic, you can calculate: woman + (uncle - man) = aunt without seeing the math vector directions
I saw close some companies getting completely lost with AI code
All of this is my fault.
I decided to start learning programming about 6 years ago as a possible new career path. The universe was not going to have that so AI was created.
I came on the market right as the Covid hiring boom ended and started to fall apart. Fun times.
The main thing it's removing is the skills you gain through actual practice, and replacing those with the demand that you subscribe to OpenAI etc to do your job.
But, moreover, the demand your company subscribes. But not your company anymore, because you'll probably be replaced by one engineer (and an AI subscription) who's now trying to do your job and about four or five other jobs.
And this one engineer will become more and more reliant on AI companies, AI companies that'll go for the throat once they've hollowed out all the skills that used to exist in the engineering market.
> - "Why are we doing this here?" > They send you a link. It's a Claude conversation.
LLMs spared my neck of the woods for now but is this really how PR review looks like these days for an average SWE or its just an example of a Junior in a team?
LLMs are an automated Indian dev-shop. That’s all. The code is poorly thought out, poorly implemented and doesn’t take performance into account. But the code works and you got it for cheap. That’s my mental model and I’m happy with it
I told my (small) team of developers that they're free to use anything to get them more productive: (company-provided) AI, black magic, WFH to avoid traffic, etc. But I also tell them that every human (including myself) is responsible for their own (direct/indirect through delegation) work so we can't say "a genie did that, not me". So far it's net positive for us with AI.
Perhaps more broadly AI will hollow out "middle intelligence".
We could end up with a gulf between those who use AI for cognitive inquiry vs passive delegation. Those who accelerate learning by asking "help me understand this" vs those who relinquish understanding and analytical thinking to AI to complete their work.
maybe the middle class never belonged there to begin with ?
Agree with the article, but good luck convincing upper management about it.
“If it works, don’t fix it” until it doesn’t and we shall see a new wave of software hiring in a year or two.
Every enterprise is talking about AI Transformation, and that great with the right expectations. But those who think AI will just make platforms quick with less people and least experienced engineers, will have to prepare for the deinshitification transformation in a year or two.
I appreciate that the OP puts his finger on the problem. I think he's right. I wish there was more optimism or ideas about how to solve it, though. How do I fight against it as an engineer? Or, how do I become a "good" engineer? It feels like sometimes the only solution people have is effectively "don't use it."
So, blame the engineers now? Most likely they were forced by a manager to push more PRs faster else piped.
This subheading popped out at me:
> The new AI economy
I don't know if this phrasing is intentional, but it gives me a chuckle. The dotcom boom was called "the new economy" about 26-28 years ago.
Writing code was never the job. Creating value was the job -- coding was just how to implement that goal.
I shudder to think of anyone in the industry this would be mind-opening to
"Creating value", "making money", etc. are meaningless
The premise does not make any sense, it is a technical culture problem which you need to enforce. If you let it go wild, yes it will go wilder than ever but this is relatively trivial problem.
> In the story above, everyone is failing:
IMO The author fails to list the hypothetical person with 13 PRs to review is also failing.
> * The engineer who refuses to change with the times
IMO many of the old ways of software engineering were local maxima. We're still seeking how to hit a new maxima and the journey may take us through zones lower than the previous local maxima.
I use AI heavily, so this isn’t about refusing to change.
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.
> * The engineer who refuses to change with the times
There is plenty of software in existence where being incorrect, even once, can spell disaster.
Everything about the picture being painted in the article is anathema to keeping such systems safe and reliable.
it seems not just the 'middle', but also the 'lower' classes are getting removed
Lord, this hits close to home.
It doesn't seem to be happening everywhere, but if you are unfortunate enough to work someplace with a "LinkedIn thought leader" high up on the engineering food chain, there's a really high likelihood that your organization is currently in the throes of an "everyone must be using AI for everything" fever dream.
And boy let me tell you, it is every bit as disastrous as the OP claims. Engineering managers are asking Claude to write up entire initiatives, then they hand off these nebulous AI slop manifestos to the teams where the requirements folks are having Claude shit out tons of superficially plausible Jira tickets. It finally lands on some poor engineer's plate and since these tickets are the technical equivalent of Finnegans Wake, they just end up asking Claude to read all this shit on `ultracode` and draft up a pull request. Which is then peer-reviewed by somebody using Claude.
I wish I were exaggerating.
Anecdotally, the essay is so spot-on. In my last job, I'd regularly have to review +20k-line change PRs from mid/junior devs only to reach a point where I'd have to just shut down the PR and ask for it to be broken apart. Sometimes, the issue would get escalated and I'd have to speak to their management/director chain. More often, they'd realize that if they spent some time trying to understand how to break it apart, the changeset actually needed to be much smaller and I'd come back to a 400 or 500-line PR to review.
In one particular case, a senior teammate of mine went the extra effort to actually explore what the intent of the change is and created a whole new PR for the junior dev that was a simple configuration change of 5 lines instead of the 14k lines they put for review.
This is utterly unsustainable and something will give at some point.
It's very true, you used to have to hire people you knew were not very good just to have warm bodies who could throw together widgets, minor bug fixes, etc. You still had to have a competent developer review what they did, which was annoying, but ultimately a time saver over doing it themselves.
Now the competent developer can just run agents and do the same review process, except it's ~free (relative to human salaries, even outsourced).
So we've got a bimodal distribution going on where the bottom X% of developers have become essentially worthless while the top Y% of developers are now more valuable than ever.
Well now you have lousy developers generating 1000 line PRs for their lousy colleague to approve while neither of them understand the code.
It wasn't that long ago that many were demanding writing code be a required subject in elementary school.
It still should be. Any educator worth their salt should be able to connect the dots on where all of this leads.
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
The fact that a machine can do something better than humans doesn’t automatically make learning it pointless.
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?
All this mindless droning about societal collapse, destruction of jobs, people moving on is really getting old. Sure people have caused mayhem by following (and enforcing) bad practices which resulted in a toxic workplace, a mix of pissed of client due to constantly failing to reach deadlines, unimaginably bad codebase that was a horror to work with and teammates each defending their own turf. LLMs now allow this deterioration to happen much quicker and more effectively.
On the other hand the problem can also be triaged quicker and rewritten faster. Pretty much every startup I joined had at its core disastrous code written by students and overworked techies. I can totally see this shitty base being the future base all startups. It'll likely need an army of agents or devs to make sense of all the spaghetti being written. I won't be surprised if demand for devs skyrockets after the first generation of spaghetti western code "matures".
At the same time, it also brings very low level "vibecoder" to the pool
I wrote about this before. I don't think the vibecoders will have a job for a long time. At best, it will be minimum wage.
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
2026 is starting to slow time there emergency and 2027 will clean. Unfortunately they still contribute to overwhelm socials media with there content.
Nice first name btw
I have a theory that Claude regresses to complexity. It’s trained to mimic existing patterns - so the smallest grain of over-engineering or spaghetti-code is like a mind-virus, gradually infecting all future output and self-amplifying until all is spaghetti.
Probably a good thing, we need more people building major mega projects like the Line. Potentially we need AI to mass produce architecture and scale up and out city/county building departments to open the gates to massive buildings in the United States.
"You can't afford bad engineers anymore"
You never could.
Agreed. But it’s the difference between crashing at 30 km/h (19 mph) and crashing at 200 km/h (124 mph).
AI massively increases the speed and scale at which bad engineers can do damage while fixing it is still slow, difficult work.
AI generated code is the new "lines of code" metric used by middle management.
Actually "AI spending" is the new "lines of code" metric.
Too real. I got DMed by management recently asking if I was anti-AI because I had the lowest spend on the team as the lead, y'know, the one that has to review all the slop my peers are generating.
That is rough, and downright embarrassing. What is happening in this industry?
Great idea to include a link to Hacker News on your blog!
This is really well written. I deal with the exact same issues almost daily. Senior engineers who want to guard quality are becoming a bottleneck.
If the people trying to understand the changes and guard quality are now considered the bottleneck, the answer isn’t that the reviewers need to move faster.
I wasn't saying that either
> But once you start storing data there, you can't just remove them. You have to come up with a migration plan, make sure you don't disrupt the system because people are paying to use this every day. You have to think about what you'll do if the migration fails. Make sure you don't end up with orphaned foreign keys. It's just so much harder to fix. Even with the best model you can get.
Migration plan? Just ask Claude when shit hits the fan. You'll make a plan when you need one.
> By the time you've untangled one bad decision, five more have been merged.
I'm slowly (partially ironically/sardonically/nihilistically) adopting a mindset of accelerationism towards the collapse of software development - it was largely done wrong from day 1 and wasn't "real engineering" to a sufficient degree to not lead to the mess that we've been in maybe for the past 20-40 years. The only thing AI did was take away the brakes and press down on the accelerator, we're already headed towards a cliff and have been for a long time.
If the code in airplanes and spaceships was developed with the same degree of care and attention as "good code", you'd see those dropping out of the sky regularly. If they built bridges like we build software, they'd fall apart regularly as well. Good code CANNOT hinge on the opinions of some senior dev, or even a group of them - it must be provably good. And if it must be provable, then these checks must be automatable. Bad code (whatever that means, however you'd manage to classify the difference between AI slop and what you want to see) should be IMPOSSIBLE to get into the system at all, due to those automated checks.
Be it good enough test coverage, automated checks for usability and end to end coverage of the features, project/domain specific lists of architectural rules (think ArchUnit), needing proofs not just tests etc. We will never have that - our OSes are bad, our browsers and other essential software is bad, our programming languages are bad (the fact that unchecked exceptions even exist in languages is a cardinal sin), same for databases and tbh any other class of software you can look at.
This impassioned comment might border on a rant, but my argument is that the past decades aren't the baseline of good code, we'd probably need to spend 10-100x more effort to produce 100-10x less code, but make the existing code bulletproof - there is no reason for more than one OS to exist, no reason for more than one UI framework to exist (or even all of the egregious ways how the web platform was transformed from documents and links to a collection of badly written apps, which eventually infected the desktop with Electron, due to the native GUI development also being severely neglected), no reason for more than one web framework to exist or even more than one programming language to exist in mainstream usage outside of research and looking for the solution to use for the next decade/century of software development. Yes, I'm exaggerating, but the correct answer is probably closer to 1 than to 1000.
Obviously that'd lead to death by comittee and some degree of experimentation is necessary, so hey we end up with a new slopped together library every week and I know nothing and nothing works anyways. I wonder if we had ONE high level programming language, whether over time it would have evolved from C++ to Rust (sans odd parallelism), and if it was based on formal proofs, then migrating between language features could have also been fully automated, alongside enough pushback to any feature deemed not worth it. On the other hand, even with all of the world's developers concentrating effort, something like that might be above our cognitive abilities, so probably not - just too hard to reason abuot.
More like AI is exposing bad engineers faster than it would've been possible earlier. Previously they would simply outsource all their thinking to someone else, now they see massive progress with AI and delude themselves into wishful competence.
As an open source maintainer, I can chime in on this.
With TxtAI, I've seen a large uptick in PRs (https://github.com/neuml/txtai/pulls?q=is%3Apr+is%3Aclosed+s...). While the extreme verbosity of Claude messages and commits is very annoying (plus the constant defending itself on why it's a bug), I do think it's a positive that more people are enabled.
It does require reviewing the PRs. Some can be tricky just like a human. For example I did merge this PR (https://github.com/neuml/txtai/pull/1136) and it would have completely broke search. But a human could also do that.
From an open source standpoint, I say the more the better. You just have to be willing to do the work to review and no not just having AI agents to review what the AI agents are submitting. There still needs to be a human in the loop, if you care about quality.
Ai isn't removing the middle class of software engineering.
Software engineering is evolving, and the middle class (and beginner) is going to have to grow instead of being able to leverage the same skills for longer and longer.
It's so true from some of the other posts that you can outsource your thinking, but you should never outsource your learning and understanding.
While there are bad engineers, I imagine that teams that have evolved alongside AI and have maintained their size and consistency without adjustment may have structural issues. I would argue that team size counts ought to be smaller now than before Claude. Unfortunately this idea could feed an AI-induced layoff trend, but it could instead lead to product diversification instead.
"There are also people who essentially make it harder for everyone else. And now anyone can produce more code in a day than they used to in a year."
That is the "democratization" that AI shills speak of:
https://xcancel.com/dhh/status/2087538364580835804#m
Once a CEO with a snowboard-optimized brain gave you a board seat, there is no way back.
I'm not sure what skill really means, or what's considered bad anymore. AI coding ability and human coding ability are different, and different organizations need different skills. No skill is inherently bad—it just depends on what the organization needs.
I understand that AI writes better code than people like me in many cases. But an industry should still provide opportunities for those people. And sometimes those people create things that are better than AI in certain areas. The problem is when even those opportunities are taken away.
The industry doesn’t really owe people opportunities. Even if you think it should, that’s not how companies are going to behave.
That is an incredibly short sighted view. By acting this way, the industry is essentially selling its future for short term gains. A systemic reduction in the number of people capable of maintaining systems directly correlates with an inevitable collapse in overall software quality.
The perspectives of market advocates often stop at this short sighted level. In reality, their modeling is incredibly simplistic. I will not elaborate at length on their poor modeling here. The short sighted local optimization that only chases the margin of the next quarter is the exact enemy we must guard against the most. (Of course, given the nature of HN, this specific part of the comment will likely be attacked.)
It is not a matter of companies not owing anything; rather, companies are actively committing self sabotage.
Is it truly right to eat tomorrow's seed corn today?
The essence of the software industry is not the 'generation' of code, but the 'maintenance' of it throughout its life cycle. Why is Linux continually maintained, and why is Windows continually maintained? The core of this industry is fundamentally tied to the entire life cycle of a product.
You might be able to fix code with AI. However, under the current LLM structure, can it actually modify projects spanning hundreds of thousands or millions of lines? It cannot. The skill required to partition those architectures is still entirely left to humans. And the ability to define those boundaries is born strictly from experience.
Labeling certain individuals as useless or inadequate inherently destroys the resilience and buffer of the collective as a whole.
Why do humans embrace and care for the vulnerable when society has the capacity to do so? Why do we strive to preserve diversity? It is because, depending on the context, those very traits might prove to be more advantageous. Every human possesses distinct skills, and their unique temperament and proficiency simply manifest depending on the situation they face.
In the words of Admiral Ackbar, "It's a trap".
Any apparent short term gain is really a prescription for long term pain.
Ignore what AI fanboys say and instead look at what they do.
https://northeasttimes.com/2026/08/07/oracle-bans-ai-code-fr...
Is it long term pain if a small startup in a very competitive vertical gets to market quicker with code gen and finds market fit? Whether that results in a rewrite or a refactor, that is still a huge win and one that a lot of people will gamble on.
Do you have examples? Ideally a startup that isn’t itself selling AI to other AI companies
Debt is debt. Some of it is absolutely worth taking on.
I don’t have any issue with intentional debt when you understand the trade-off and have a clear payoff plan.
Oracle banned AI code for copyright reasons, you cannot interpret that as a assessment of the practical output of the models.
That's only one of the three reasons in the article: 1) Reviewer burden - LLMs can produce a deluge plausible but incorrect code which can overwhelm human reviewers. 2) Safety and Security - Many corporations depend on the JDK so stability is a high priority. 3) Copyright/IP about who owns submissions generated by AI is not settled in law.
The article also goes on to compare the JDK teams policy to GraalVM, also in Oracle which is more similar to the Linux kernel policy, where AI submissions are allowed, but the human submitter is accountable to them, which is reasonable too.
It's not unreasonable, in my opinion, for the JDK team to limit AI contributions based on their stated priorities, just like how other teams might not require those same restrictions.
Oracle banned AI code from a public project they maintain and backport/share with a commercial product because they're a very litigious company, anticipating future legal cases.
It strongly argues against a position that many people including myself have taken, that all code will soon be AI code and the only people still writing code by hand are those who haven’t gotten the memo. (I don’t mean to rule out the possibility that Oracle, despite their involvement in AI infrastructure, is just being dumb and the lawyers made them create a policy that’s not compatible with the modern practice of software development.)
Just look at how they bragged for a year now about how AI built entire apps with a single prompt.
And now that code is being watermarked by AI, suddenly they’re artists, painstakingly prompting, crafting, to get just the right code; the watermark is unethical even!
AI psychosis is real, and even some of the smartest people I know how succumbed to it.
This blog conflates productivity with expertise.
Are LLMs rewarding experienced developers with tons of productivity gains? Yes.
Are LLMs actively degrading their expertise of understanding code? Also yes.
This article has made the implicit assumption that the top quartile of engineers are immune from skill decline. They're not. If you're an engineer who increasingly outsources the planning, writing, and analysis of code to an LLM, you're losing your ability to plan, write, and analyze code.
All of this is to say--senior engineers who have fully adopted AI tools are blowing smoke up their asses to dodge the reality of their own obsolescence. The senior engineers can talk about productivity all day, but they're only marginally closer to understanding a complex system that was written by LLMs than the "middle class" of engineers are.
You reading this--yes you--get over yourself. Your skills are depreciating too.
Very good article.
But it does cover the case where someone makes it to the top if he/she is junior. Who experience is gained?
Maybe I ask too much from a short article.
A pattern I have noticed is you get way better results if you just have one skilled senior engineer coding everything with AI vs a lot of people.
Having large teams in the age of AI is pointless. It slows things down and spreads accountability too thin.
When you have one good engineer doing many things, a lot of stuff lives in their head and they know what to look for in their own PRs. Also, people tend to like their own AI slop, but not others. So overall you will have at least an engineer who is satisfied with the codebase vs a lot of people who either have some gripe about something someone else did, or just don’t care at all.
That means you have to put way more trust in a single individual, but if it’s the right individual you propel the organization further ahead than a team of mediocre engineers or senior engineers limited in what they can accomplish.
Wait till we realize that nobody is buying the software we vibe code anyway.
We've seen this game before, with the Dot Bomb and 9/11. A lot of you have 6 figure jobs that will simply be gone next year after the election, never to return.
That winter lasted about 5 years until 2007 when the iPhone and social media sites like Facebook went mainstream. This winter won't end. Or more accurately, it is the end.
Maybe we should stop debating whether we're in a crisis and start looking at the 5-10 year endgame of the Singularity. We're entering the eventuality that many of us have predicted since the arrival of the internet 30+ years ago, that prices will get lower but nobody will have any money to buy anything anyway. The feeling that we're doing something wrong with our lives will continue to intensify. We'll try so hard, and get so far, but in the end, it doesn't even matter.
I don't know about the rest of you, but I'm turning my attention away from trying to play the job game with AI. I'm looking instead at how we can provide time/money/resources to the middle class after capitalism can no longer provide them.
A conservative friend of mine just read the Communist Manifesto by Karl Marx, which I didn't see coming, especially since he beat me to it. In the neurodivergent spirit of not being able to do anything alone, what if we all read it?
https://oll.libertyfund.org/pages/marx-manifesto
https://www.marxists.org/archive/marx/works/download/pdf/Man...
I'm predicting that it stops just short of what full automation can provide. Loosely the evolution of economics goes: hunter-gatherer -> agrarian- > feudalist -> capitalist -> socialist -> communist. And now solarpunk (or something).
The working class is looking forward to the next chapter, but the capitalist class is looking backward to neofeudalism.
Those two directions can't coexist, so what does the future hold? Well, it's always darkest before dawn:
"It's easier to imagine the end of the world than the end of capitalism." - Mark Fisher.
https://www.youtube.com/watch?v=aCgkLICTskQ Mark Fisher: The Slow Cancellation of the Future
https://www.scribd.com/document/835022535/Mark-Fisher-The-Sl... (transcript)
https://goodscienceproject.org/articles/the-slow-cancellatio...
https://mediationsjournal.org/articles/end-of-world
If the endgame of capitalism is that it inevitably eats itself, then the game now isn't how to get more money and do nothing with it, but instead how to start doing something with no money.
I should add that even if I'm exploring anti-capitalist futures, that doesn't make me socialist. I don't like the 6 hour daily work requirement of many socialist societies. I think we can do better than that and get closer to 0, so that we can shrug off wage slavery and finally get real work done.
This is extrapolating several steps beyond anything we actually know.
Whether people will buy AI-generated software is a different question. The problem I’m describing already exists inside businesses with paying customers.
I’m talking about established teams working on products that already have users and make money, where AI lets individual engineers introduce changes faster than the rest of the team can properly understand and review them.
AI gives more leverage to exceptional people, its an amplifier not an extender
Right, it's a multiplier only if we define bad engineers as negative numbers, and "bad" as "most".
I know what you mean, but the amplifier could genuinely work both ways ( magnify bad and good outcomes ).
There was an old truism of "acid fascism" that went like this: "LSD makes smart people smarter and stupid people jump out of windows". This is like that.
Maybe
That is true of all tools. AI is a tool. A tool provides leverage. It does not make a bad craftsperson good.
I hate that framing because it glosses over what makes AI distinct from other technology. Pretty much anything can be used as a tool, that’s not an interesting aspect of AI. However standard tools do not take decisions on behalf of the user, they do not apply judgement. They come with assumptions and constraints that make some decisions more likely to be made. But the whole thing about LLMs is that they apply judgement and take decisions. When you use an LLM you delegate both aspects to it with very little overview or control.
I don’t think it’s “just a tool”, it’s something that directly compete with the role of humans in a system, by design
If you go back in time and imagine yourself in 1950, would you have said that about computers in general? Yes their decisions are the result of pre programmed heuristics, but to the operator that can feel as opaque as AI. In fact in the early days of computing AI was used to refer to a broader swath of what we now call heuristics and machine learning.
Is a very sophisticated computer driven adaptive control system making decisions for the user? Arguably yes. If your car has a bunch of assist tech you are not driving. You are commanding a nonlinear control system.
AI today is quantitatively far beyond these systems but internally it is still just a giant decision table. It’s just a differentiable table that can be automatically programmed by back propagation at what would be unimaginable scale for manual implementation.
As soon as you put a machine between you and the target action that is more complex than what you can hold in your head and that has multiple layers or feedback loops, you are ceding fine grained direct control in favor of a simpler abstract control surface.
I will change my mind a little if I start seeing evidence of genuine volition, but as of now I suspect that’s a property of life not intelligence. One interesting result of AI when viewed as an experiment is: I think it proves that life and intelligence are separate phenomena and that consciousness and intelligence may actually be unrelated.
I have the hypothesis that consciousness (and therefore true volition) is a property of life. You have to be metabolic and tied in some intimate way to thermodynamics and the arrow of time. Solid state electronics doesn’t have this property. It’s unrelated to intelligence. A bacterium may be conscious.
>If you go back in time and imagine yourself in 1950, would you have said that about computers in general?
I'm not the parent, but personally, no, I don't believe so.
I always appreciate the "it's like past changes" thought when things change, but in my opinion, this one simply isn't. It's notably different both quantitatively and, critically, qualitatively, than all previous increments in computers/software. This is much more lateral than punch cards -> assembly -> compilers -> frameworks.
Ai is a tool in the same way an employee is a tool. very unlike a hammer.
right but we have never seen a tool like this
https://en.wikipedia.org/wiki/Timeline_of_historic_invention...
Economics would have always created this downward pressure on demand for software engineers regardless, either companies would replace the number of engineers they need with AI, or with low paid offshored workers.
I don't know what kind of company has got a large codebase and it's taking 20,000 loc pr's expecting that shit to be sustainable, but I work AI first and at the most PR's are touching 12 to 15 files, with the more radical ones sitting at 30. They are still human-reviewable. They are still the kind of change you can revert back to original without breaking all the rest... there are ways of doing this stuff, dear luddites.
I was wondering how anyone could reach the token limit of a 200$/month Claude subscription. I never did on a 20$ one, and I'm parallelizing Claude to the absolute limit of what I can reasonably keep in mind. And I do that day and night, on week-end too with open-source. Now I'm absolutely convinced that it's by doing crap architectures and design that require 200k token of context before adding a single checkbox. If you apply good design principle and course correct the AI in real time before it commits to really stupid way to fix things (i.e. you don't ask it or let it do things that would make zero sense if you had to do it yourself), then the vibe coding cost way less and is way faster and easier to reason about.
I’m hardly a Luddite and you’re basically making my point.
You’re deliberately constraining the output so changes stay small, human-reviewable and reversible. That’s good engineering culture.
It isn’t all or nothing. I use AI heavily but that doesn’t mean I have to pretend there aren’t serious problems with how it’s being used.
> The engineer opening a 25,000-line PR should have stopped the agent long before it got there.
So many A car is simply a faster horse arguments being made here.
The “You must review every line of code” camp are going to be in for a seriously bad time when Claude/Grok/etc starts writing machine code, and they absolutely will and you will look like a crazy person the same way as those who said we can’t trust compilers back in the 1970s.
Breaking up code into small reviewable pieces is obsolete advice from legacy software engineering. We will probably be reviewing prompts or functional simulations as a form of review. Which brings me to the point that a Senior engineer in 5 years will look absolutely nothing like a Senior engineer in 2019.
> The “You must review every line of code” camp are going to be in for a seriously bad time when Claude/Grok/etc starts writing machine code, and they absolutely will and you will look like a crazy person the same way as those who said we can’t trust compilers back in the 1970s.
I'm working on this right now, will have a release probably in a week or two. Not machine code but it's essentially a custom assembler/compiler pipeline (close enough) that an LLM can operate via the CLI (you can do it too, it's just way slower) and it emits native asm optimized chunks that can then be inserted back into cpp (working on a rust et al impl). The results are _obscenely_ good. It's outright outperforming gcc vis-a-vis by a MONSTROUS margin, and it's not even close. As in, gcc can do abour 3-4 cyc/byte (arbitrary workloads on a wide variety of tests) and my tool does it in 0.5 cyc/byte if not better. It outright emits kernels that run at a flat 4 IPC for more or less _anything_. You can then have an LLM convert it back into high level C++ intrinsics (not always, gcc doesn't always expose all the levers needed to do so) if you wish. The one downside is that you need to provide fairly accurate cpu arch maps (ie agner fog instruction port/latency tables) for the tool to work right, which is what i'm focusing on right now.
I do have a genuine question though: what value are you adding at that point?
If you don’t understand the system, don’t know what the code is doing and you’re mostly prompting an LLM to make the decisions and implementation for you, what exactly is your contribution?
The ability to operate the tool isn’t much of a moat if everyone else has access to the same tool.
I don’t review assembly produced by a compiler because the compiler isn’t deciding what my system should do. It’s translating a program whose semantics were already specified. More importantly, that translation is deterministic.
A compiler takes a human-specified program and translates it into another representation while preserving its semantics.
If in five years I can give an agent a complete specification and reliably verify the resulting machine code against it, then sure, reviewing code may become obsolete and I’d happily stop doing it.
Also, keeping changes small isn’t just about making individual lines readable. It limits blast radius, makes behaviour easier to reason about, isolates mistakes, makes changes easier to revert and so many other things. None of those properties suddenly become obsolete because code generation got faster.
Do you think it's impossible for someone to have a 25K line PR / diff but not know what's going on in the system?
I ask because I've pushed some of this to the limit in my own testing and when I get the right building blocks / primitives in place in the repo, I'm able to get plans written in a way where I don't just describe what I want but specifically mention outcomes, verifications, constraints, etc. that utlimately describe the shape of my system and my intent.
My plan is my understanding of my system and the changes I'm making, and the execution of that plan (e.g. with subagents), verified against my spec, is the code itself.
With the correct building blocks, I've found that frontier models can write code in fairly predictable ways that lets me maintain my understanding and confidence in pretty large PRs.
I think perhaps the quoted part of your post seems to imply it's not possible / isn't phrased with that nuance?
For the vast majority of 25K-line PRs, especially AI-generated ones, I would bet money that the person opening it does not actually understand all of it.
If you genuinely understand the resulting system, then that's fine. That’s not the behaviour I’m criticising.