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
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.
> 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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
>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.
> 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.
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.
> 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 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.
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).
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.
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
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?
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.
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 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.
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.
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?
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.
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.
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.
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.
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.
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
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.
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?
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.
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.
> 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
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
> 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
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.
> 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.
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!
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.
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.
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.
> 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.
Jury is still out here
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.
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.
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.
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.
What is A&D? Shouldn't it have been defined in your comment?
Fair point! I edited my comment, A&D -> Architecture & Design
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.
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.
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.
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.
>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.
> 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.
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.
> 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 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.
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).
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....
[delayed]
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.
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
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?
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 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 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.
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.
... And Django and React removed ("stole the jobs from under") the engineers handcrafting html and jQuery web pages/apps.
Django? Django is older than jQuery…
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.
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?
the future is already here, its just not evenly distributed
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.
no programming is verifiable, and the major LLM companies are focused on it. its the first domino to fall by probably 5+ years
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.
Only if you run out of things to write. Is your back log ever empty?
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.
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.
Yes, when the project budget runs out and contractor team has to leave.
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.
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.
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
And how do you think people go from fresh graduates to senior devs?
Degrees take 4 years. It's a very laggy indicator.
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.
Juniors to push the accelerator, seniors to pump the brakes. It could work.
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.
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...
The way you handled those numbers makes me think you have leadership potential, perhaps even U.S presidency material
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
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.
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).
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.
> 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
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.
>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.
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??
It wasn't that long ago that many were demanding writing code be a required subject in elementary school.
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...
What's with people using the number "0" for their first reference? I have only ever seen that practice here at Hacker News.
Lots of (most?) programming languages are 0-indexed so it feels natural for software developers and our ilk.
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.
> 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.
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.
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.
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.
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.
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.
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?
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.
> 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 saw close some companies getting completely lost with AI code
So, blame the engineers now? Most likely they were forced by a manager to push more PRs faster else piped.
Great idea to include a link to Hacker News on your blog!
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.
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.
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.
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.
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.
"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.
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
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.
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
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.
> 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.