Comment by simonw
16 hours ago
An idea that's beginning to solidify for me is that AI tools make software development harder.
It's harder because they dramatically raise the bar for what's possible to do. An individual developer can take on significantly more challenging projects now, because the ultimate constraint has always been time and AI can help you get more done in the time available.
But the stuff you can get done with that time is a whole lot harder. You have to understand lots more things, and get radically outside your pre-AI comfort zone.
It used to be acceptable to spend several days refactoring a codebase, or figuring out how to ship a small feature because it's in a part of the system you hadn't worked in before or involved learning a new library in order to build it.
Coding agents mean you can climb those curves a whole lot faster, but you still need to climb them - and the volume of information coming your way is much higher.
If you're worried about non-technical vibe coders taking your job, the correct response is to be much better at building software than those vibe coders. That means you need more skill, more ambition, and more experience. It's hard!
From that perspective, development has always been harder since I started. I left college with a copy of K&R and remembering courses that applied to real life immediately, because data structures and such were just what we had. In my first job, I ended up writing a code generator to help serialize a large number of data structures, straight from a compiler design class.. which right now you don't need to know a thing about, because serialization and languages with introspection are everywhere. The knowledge you need to be a professional engineer just kept going up through the last 30 years, while most of the basics became far less relevant, because the libraries just did it.
AI raises the bar again, as its probably at least as good as me, if not better, at anything I learned in college. I've spent years living off of random trivia from the last 30 years, as I saw computing grow with me. How do you know this?! Because everything built on top of it didn't exist when I was your age, so I had to learn it! But well, nowadays the AI is better at that trivia too.
The world moves, we do what we can with what we kno. It's not just programming, but what innovation and automation has done to the vast majority of things humans have done to be productive for each other since humans are people. We'll have to cope, like the guy that bred oxes to pull the plows.
So in essence: it got harder because the easier parts have been solved for?
> If you're worried about non-technical vibe coders taking your job, the correct response is to be much better at building software than those vibe coders. That means you need more skill, more ambition, and more experience. It's hard!
This is a false fear. The real risk isn't that some 19 year-old vibe coder is going to replace you, it's that there's simply less need for more experienced engineers. The market is shrinking.
Also, even if the premise behind the SaaSpocalypse is naive and oversimplified (companies aren't going to replace all their SaaSes with internally vibe-coded replacements), it looks reasonable that net-net AI will have a negative impact on the value of software.
> The real risk isn't that some 19 year-old vibe coder is going to replace you, it's that there's simply less need for more experienced engineers. The market is shrinking.
That last sentence is verifiably false if you look at SWE job postings and their recovery since 2022.
It’s also a poor take in general, buying very much into the narrative propagated primarily by OpenAI and, especially, Anthropic, who nonetheless continue to hire large numbers of SWEs while paying double the market rate.
> That last sentence is verifiably false if you look at SWE job postings and their recovery since 2022.
Source?
https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE
And it's probably worse than it looks because phantom job postings are a real thing.
> ...who nonetheless continue to hire large numbers of SWEs while paying double the market rate.
Tech companies have laid off over 200,000 people since the beginning of 2025. Even putting aside the fact that (from what I understand) over half of Anthropic and OpenAI's employees are in non-engineering roles, if you assumed every employee was an engineer, Anthropic and OpenAI could triple their staffing levels and it still wouldn't even fill a quarter of the void.
> That last sentence is verifiably false if you look at SWE job postings and their recovery since 2022.
Do you take into account recent layoffs of Meta (8k people), Block (4k people) and others?
I worry this is looking at where the ball is now instead of where it's going. The recent disproof of an Erdos conjecture should put to rest the idea that LLMs will reach a skill ceiling before they reach superintelligence.
I believe we are headed for a world of superintelligent AI where LLMs are much better at logical thinking than humans, the same way that chess engines are much better at chess than humans.
In that world there's really nothing humans can offer in terms of logical thinking other than their humanity itself. An 8 year old with Stockfish can beat Magnus Carlsen, and an 8 year old with Codex (and daddy's credit card) will be able to beat me at software engineering.
I don't buy that at all.
It doesn't matter how great the LLMs get, the act of creating software using them will still require a great deal of skill.
Most people just don't think in terms of software.
Try asking a non-developer in your life what their dream software would be for their work, or their hobby. If they don't have what Nilay Patel calls "software brain" I'd be surprised if they came up with something actionable.
(For more on software brain see "THE PEOPLE DO NOT YEARN FOR AUTOMATION", which makes the point I"m making here but much, much better: https://www.theverge.com/podcast/917029/software-brain-ai-ba...)
You could give a non-developer the smartest LLM in the world and they wouldn't be able to create GitHub with it, because creating GitHub requires an enormous amount of understanding of what software developers need from a cloud source control tool.
Sure, you can argue that the LLM "knows" what GitHub needs already and can guide their human-user to that, but why would a human-user who doesn't understand the domain ask an LLM to do that in the first place?
> Try asking a non-developer in your life what their dream software would be for their work, or their hobby. If they don't have what Nilay Patel calls "software brain" I'd be surprised if they came up with something actionable.
I've posted this in numerous comments because I think it bears repeating: there are tech-savvy non-developers who are actually building and shipping stuff with AI. I personally know a few who have been successful in acquiring initial customers.
You can say "but their apps won't scale", "their apps aren't secure", etc. and you might be right but these criticisms ignore the fact that most human-built software suffers from issues around scalability, security, etc. What AI in the hands of a relatively tech-savvy person is capable of is building functional, usable applications that are pretty decent compared to what you might get if you paid an experienced contractor tens of thousands of dollars to build.
A whole generation of young people has grown up with the internet, smartphones, etc. They might not be trained software engineers or have a "software brain" but in many cases they probably have a better intuitive sense for digital product design than a 30 or 40-something engineer who has been staring at an IDE for the past decade(s).
19 replies →
I personally don't see that much sense worrying about this scenario because if it comes true then it doesn't really matter what I do.
If building software (and even programming, as the basis for it) was just an expression of logical thinking, we would have cornered it long time ago IMO.
But then again, logic is really a lot more discrete and well defined and easily expressed with traditional computing than LLMs are (which are probabilistic systems instead and as such require large knowledge bases).
We can observe that at a couple hundred billion parameters they behave similarly to a point (in the sense that they can produce similar results), but the challenge is really in understanding the problem's multifaceted structure and competing needs and priorities.
Are you confident in putting a timeline on this prediction?
One of the reasons I'm increasingly skeptical of this prediction is that I've now lived past a few of the dates I heard people put on the achievement of this level of superintelligence in previous years.
Chess and proofs only work as comparisons to the extent that you can find parts of your job that share their key property: A solution is sought to a problem that can be stated with relatively little information.
What prompt would someone have used to get a superhuman coding agent to output the Linux kernel or GTA5?
Before you accuse me of moving the goalposts, that's not my point: The examples are there to help think about what humans would still need to do to build complex projects even if the coding itself was perfectly reliable.
Both the Linux kernel and GTA5 contain a large amount of incompressible information; humans thought long and hard about how to design them, i.e. about what that thing they were building was even supposed to be.
You don't understand, Claude 69 will be able to one-shot GTA6. You NEED to buy into the fearmongering and anxiety.
> In that world there's really nothing humans can offer in terms of logical thinking other than their humanity itself.
By your logic anyone who's not in the top 10% of intelligence can't offer anything. The world keeps spinning.
> An 8 year old with Stockfish can beat Magnus Carlsen, and an 8 year old with Codex (and daddy's credit card) will be able to beat me at software engineering.
That's just nonsense, nobody will work with 8 year old (it's illegal, to start with). Go touch grass.
That's true but in a way it's also more fun and engaging because the tedious stuff just gets worked through leaving you to think about the bigger picture items.
Though I'll say I don't buy the stuff about AI "democratizing" development since making it much more capital-intensive kind of has the opposite effect for anybody doing dev work at home.
That's a roundabout way of saying it makes software development easier. Perhaps even a 180.
But yes - once it's that easy you have to step up your ambitions.
Maybe it makes software development easier, but a career as a professional software engineer harder.
I hope that after a short period of delusional expectations and layoffs from employers we're at least left with a more consistently competent set of professionals in our industry. Some people have imposter syndrome. Others are actually just imposters.
2 replies →
[dead]
> If you're worried about non-technical vibe coders taking your job
I'm not worried about non-technical vibe coders taking my job. I'm worried about psychotic VCs and CEOs putting me on the street in the name of "optimization" of "lower value human capital".
I had the same thought recently, I've had it happen to myself.
I've been working on something relatively large and greenfield recently.
A big chunk of my time is spent thinking about the hard parts. The raw information processing rate needed to keep up with the state of the project is high.
It feels almost like mental athleticism, whereas coding used to be a rather chill activity.
developers now are expected to randomly jump around projects and ship without friction. For employers it means they can move us around like pawns. Lot of companies have not reorged themselves to this new type of workforce thats much more malleable.
it used to be that i pay your due at some enterpise and learn some corner of codebase really well and become go to person. that would give you job security.
Working in silos like this has always been an anti pattern though. You end up being employed for 10 years but only have 1 year of actual development experience. Just turning-the-crank and going home was always risky because one day you get laid off and realize you’re 10 years behind the competition.
What I found comfort it in was turning the crank and then using extra time to upskill in various other things (including non software dev domains). Things that weren’t immediately useful to my employer and I never would have been directly assigned, but did pay off after sometime.
Now I’m basically expected to do what my boss wants me to do every minute of the day, it’s gotten much more micromanaged.
As opposed to what? You seriously think that shipping 10 years, instead of turning-the-crank and going home, will save you from the interviewing gauntlet?
I cynically predict that some of the new practices being hyped could easily end up worse...
Before: "I learned very little this year, because I was placed in charge of the same stuff, and I've already learned most of what I could from tinkering with that code, stepping through its architecture, and dealing with those recurring problems."
Soon: "I learned very little this year, because I don't deeply interact with anything, I just pull the lever on the babbling slot-machine until I get lucky and things seems to quiet down."
So what enables job security now?
Your dad owning the company?
Let them attempt to use ai to build business critical systems and when they waste tens amd hundreds of millions they can rehire master builders who know what they're doing
1 reply →
If you can move humans around like pawns, then by definition, they have no job security.
Being a really good engineer - the kind of engineer you can assign a feature to and they promptly turn around a robust, maintainable, secure and well documented implementation.
6 replies →
> developers now are expected to randomly jump around projects and ship without friction
This describes the expectation my managers had of me at every software job I've had, and I've been doing this for a decade and a half
It's definitely not a new thing since LLMs came around, if that is what you were implying
> It's definitely not a new thing since LLMs came around, if that is what you were implying
It is on a scale that it is required now. Previously you could say "it'll take me a week to decipher the mess", now they can just say "can't you use an agent to make it fast?".
> it used to be that i pay your due at some enterpise and learn some corner of codebase really well and become go to person. that would give you job security.I
I had the displeasure of working with those types. One of them replies to any question or challenge to a technical problem emerging from the PRs they posted with variants of "I've worked here for over a decade, this is how we do things". And then proceeds to argue things like defensive programming is a code smell because it means developers don't trust themselves.
I cannot envision any healthy, effective engineering environment where developers don't periodically switch between projects.
You will never beat the vibe coders.
The vibe coders have a key advantage you don’t: they don’t give a fuck.
They blow through a task and move onto the next one. Management sees this as progress, and the vibe coders are rewarded.
When shit breaks later on down the line, and fires have to be put out and things rewritten, the vibe coders do NOT get the blame. They do NOT get punished. Most engineering teams operate on a blameless culture. If code was approved for production, then it should have been good enough. Vibe coders will keep on doing what they do, and skilled experts will be left cleaning up their messes.
For anyone who actually cares, it’s over. You are not steering development anymore.
This will invariably be a problem in organizations where tokens, lines of code, PR count etc are the metrics - which happens to be in most places. I do not know if there are metrics or rewards for maintainable code, OR penalty for write code that breaks down and causes product incidents down the line. By then those engineers would have been promoted and moved on to better things.
> You are not steering development anymore.
This hasn't been the case for at least a decade. Long before LLMs.
That might be true in the short-term, but I'd be very surprised to see that hold for the long-term.
We've had plenty of technology trends in the past that have promised faster development but has later turned out to have problems. Organizations that stick around learn lessons about what works and what doesn't.
If in a year's time organizations aren't feeling severe downsides from all of the unreviewed vibe-coded junk they put into production then maybe the vibe-coders were right. I'll believe that when I see it.
If the vibe coders are right I would give at least 90% of the credit to all the well made libraries, rules, and best practices that developers have built up over the decades. That’s what is embedded into LLMs and what might be the saving grace of slop code bases in the future.
4 replies →
The problem is downsides are random and not well understood. Sometimes by luck, an organization might not encounter any significant downsides. These kind of survivor case studies will perpetuate the myth that vibe coding is good enough.
The vibe coders aren’t “right”, they just get lucky.
Who approved the vibe coders’ PRs?
Other vibe coders?
Another vibe coder and Claude?
It’s all just vibe coders high fiving each other and saying LGTM.
Here’s a secret: I haven’t really bothered reviewing any PRs since September of last year or so. I just click approve and don’t even read it. It has been way less stressful for me.
Do bugs get through? Sure. But someone will just come in and vibe it out anyway. And I have yet to see a vibe coder or anyone who approved their flawed work get any repercussions. So yea, it doesn’t matter.
No one’s going to come after you asking “why did you approve this shitty PR?” And if they do you can forward it to the author and ask why they wrote a shitty PR. But that just doesn’t happen. It doesn’t matter.
> The vibe coders have a key advantage you don’t: they don’t give a fuck. They blow through a task and move onto the next one. Management sees this as progress, and the vibe coders are rewarded.
This is a complete unrealistic assessment. Who do you think vibecoders are? They are yesterday's software developers using today's tools.
The people who manually write their PRs are also not giving a fuck when they break production code with spaghetti code that later has to be thrown out and rewritten. They are the same people.
The key difference is that now their output volume is much greater, and they iterate much faster. They roll out plenty of bullshit, but it also hits the fan much faster and triggers fixes at a higher rate.
People hate on vibecoders because they do exactly what your average developer does but at a much higher rate.
[flagged]
Not really. The primary stopper was never time or effort. It was need (and wisdom). If a project was important enough, you’d do it. If it’s not, it falls on the wayside.
Now with LLM tools, what you got is a slew of projects their creators aren’t even interested in. It’s theater.
There's just no way this can be true. Every project I've committed to has been a bet made with incomplete information. Sometimes it pans out, sometimes it doesn't. Every time I've made one of those bets, I've had to shoulder the opportunity cost of 2-3 other 1/8th-finished but promising projects I could have driven to completion instead. Not having that opportunity cost anymore wildly changes the dynamics of what I build.
This weekend I'm playing with a SwiftUI MusicKit player (everything I'm doing lately has been Swift/SwiftUI, itself a radical change from just a couple months ago when everything was a TUI, and then a few months back from that and all the way back to 1993, when everything was a CLI) with a Responses API hookup that turns the player into an agent, with tool calls to let the model see what I've been playing. "Keep a continuous queue of music playing while I'm working in the wood shop".
Worked a treat. I'm genuinely interested in where I can take this. I have a real problem, one that's been annoying me since ~2000, which is that I "own" a lot of music but find myself stuck in an epicycle of the same 200 songs. Problem solved-ish. I never, ever, in a million years, would have built anything like this before.
It's really hard to sell me on the idea that nothing profound has changed here in terms of the projects we now pick up. Go build an operating system. I'm serious! Claude will practically one-shot it. Mine has smoltcp hooked up to a Rust virtio-net driver Claude pulled out of its butt.
> This weekend I'm playing with a SwiftUI MusicKit player[…]"Keep a continuous queue of music playing while I'm working in the wood shop"
> I have a real problem, one that's been annoying me since ~2000, which is that I "own" a lot of music but find myself stuck in an epicycle of the same 200 songs.
What’s the algorithm there? How is it different from queueing up your whole library and shuffling it?
> Go build an operating system. I'm serious! Claude will practically one-shot it.
Why would I want this? If I wanted to learn how an operating systems is built, there’s xv6 and the OSTEP book (and I’ve already gone through both) And I’ve been going through OpenBSD code, for a few questions that I had (usb audio and related code, usb mass storage and related code,…). Why would I ever wanted a generated project when there’s plenty out there to learn from.
That’s the trick - always stay hard!