Don't worry -- soon after that, there will be high demand for human coders as companies scramble to hire to rewrite all the buggy and vuln-ridden AI-hallucinated software. We're on the verge of two revolutions in tech, not one.
I shared your view a year ago. Hell half my posts here on HN are arguing against the annoying hype. Today I make heavy use of AI and my code quality has gone up, not down. It's better tested, better factored, with better error handling covering more edge cases
AI code is only buggy if no-one is guiding or reviewing it
I'm not sure how long we'll need someone in the middle to actually review the code
I view AI like a gas pedal. For an experienced driver it can really help. For someone new, straight into a wall. For some code you go straight for hours and barely touch the steering wheel. For some code it's all wheel and too much gas is a mistake.
That said, we will need less coders overall. Just like you don't need human drafters or calculators in the same way. It will cut the bottom out of the industry, and entry level will be expected operate like a senior from 10 years ago.
>> Most workers, and most work days, are just drudgery. Answering emails. Writing up quarterly plans. Reviewing metrics. Building applications that do something with data.
Yes. Those jobs are going to disappear. If your role's primary value is shuffling paper around an org, or putting minor edits on something before forwarding, your job is going to disappear to AI in the next 1-3 years.
Or AI-initiated human process optimization in the next 2-5 years, which I think is an underappreciated second wave.
To define that: if we 10x or 100x the productivity of certain roles, won't companies look at the remaining unaccelerated human speedbumps and ask "Is it really that important we have a person do that? Because it's now costing us substantial latency and throughput of the process as a whole."
And in many cases they'll likely conclude that no, it's not critical that a human be involved at that point. So poof those jobs as well.
As a result, we'll have many fewer humans being much more productive.
Tbd on whether that produces enough surplus (and equal allocation of it) to balance out the job losses.
If there are no people, there won't be a need for managers to exist either. Who/What are the managers going to manage? The office air?
Eventually whoever that is running the business has to be smart enough to figure out everything, and the margin for error will be small in a economic environment where every one is already poor and can't spend to buy your things.
I remember the days of socialist India. If everyone is poor its impossible to do the good things like research, development, innovation. The reason is simple, with no one having money to buy your things, you will never make profits to invest in them.
I think new devs could probably get use of it as a replacement for SO or Google. But if they slam on it and think they can vibe code a whole app, they are going to have a bad time.
But NOS may be better. It might make you faster but it doesn't make you better.
That works because you are a senior developer who knows how to properly use the AI tools. What 10 years from now? What happens when senior devs are retiring and we do t have replacements since we replaced junior devs with AI?
Well I'd probably consider myself a materialist but I'm not sure I'd agree. The evidence to me seems that it can really only come from two places: additional compute or new breakthroughs in AI learning. Compute's coming, certainly, but that only has the potential to improve things if it's added in conjunction with a commensurate AI breakthrough. I think the trend in improvement for transformer could be logistic, not exponential, like a lot of the snake-oil salesman like to state. And while there's plenty of evidence for compute there isn't much for the AI breakthrough that leads to an exponential jump, and if it does exist it's a trade secret, so until we know we don't know.
> I'm not sure how long we'll need someone in the middle to actually review the code
Always will, it's a question of how many people we need, not if. Well, until AGI (which I'm very bearish on in the near or even intermediate term) or some other monumental shift
I am senior developer and have easily and successfully avoided using Llm development these last few years. Nothing has changed for me and my team mates who do use it are slower than me and often don’t know what the Pr actually does.
You chose to invest in the downward career slope. That’s why your opinion has changed. If you continued to resist it you wouldn’t be looking to remove yourself from the auditing/coding position.
How is investing in something that improves my productivity and output quality a downward career slope? Continuing to use a hand saw when there are power tools available seems like the downward slope..
If AI gets to a point where I'm fully able to be removed from auditing/coding positions.. well there won't be any coding positions left for anyone
> often don’t know what the Pr actually does
this is on them for being lazy. I thoroughly review the code AI produces. I don't commit it if I don't understand it
Analogizing AI to power tools is like analogizing building an IKEA bookshelf to outsourcing the job to a TaskRabbit.
Power tools automate manual hand movements, but you still need to follow the manual and know what fits where. Or you can spend money on a contractor from TaskRabbit to do it for you, perhaps badly.
LLMs make it faster to generate code, sure. Automating boilerplate code isn't too unlike using a drill to fit a screw.
But witting software writ large still requires thinking, something that the companies providing these services are heavily incentivized to remove.
> How is investing in something that improves my productivity and output quality a downward career slope?
> I'm not sure how long we'll need someone in the middle to actually review the code
You don’t think relying on a system you yourself are predicting will replace you isn’t investing in a downward slope. Wait until you find out Llms are helping suppress your wages.
> this is on them for being lazy.
Just like you gave into Llms you became lazy about writing code. That is the trend with Llms, to do less work as you’ve been pointing out.
Not using LLMs doesn't make them go away. Whether they suppress wages or replace anyone is completely out of my control. Avoiding them just means I'd be producing below my potential
> you became lazy about writing code
I haven't, though. I still do the same amount of work except now I get more done. Now more of my energy goes into architecture, testing, specs, making sure it's built well instead of the lower level wiring things together
I use them for their perfect memory and as a creativity buddy, not for them to think for me
I have no goal to make them go away. My goal is to not use them because I don’t have to. Using Llms removes your agency to not use them. You become more reliant on using them.
> and successfully avoided using Llm development these last few years.
I'm not sure that's much of an achievement, to be honest. If you tried it and it turned out to be not useful for you, fine, I'm on your side. But refusing to try for the sake of it seems backwards. I mean, then why use CI, version control and those fancy IDEs anyway? Notepad is a perfectly cromulent text editor (and what is code, if not text, anyway?) and my local build.bat and deploy.bat do their job nicely and quickly.
Poetry is text too. It is a misleading categorization.
> I mean, then why use CI, version control and those fancy IDEs anyway?
CI, version control, and IDEs do not think for you.
Resisting using LLMs to do the code that you know perfectly well how to do is like resisting using maps to tell you to make "now make a left turn" to travel from A to B, when you have gone from A to B a zillion fucking times. It is perfectly sensible, specially if you want to retain your skills and mental acuity.
Anecdotally, I know individuals (ok, Dad /g) who can no longer negotiate even the most simple routes without the stupid map thing walking them through all the turns. Routes that were taken for years without these gizmos now require the gizmo.
This is an unfortunate 'experiment' we are conducting in this field. The actual lasting results (or damages) are unknown as of yet. We have some idea though.
I used to be like you and then I decided to get up to speed on where things stand a couple of months ago.
I hate using it but I can write issues in gitlab, send them to aider, and it will spit out working solutions complete with test coverage.
Right now I think I'm maybe still faster just writing things myself but this feels incredibly tenuous. I'm certain that in a year vibe driven development will be faster.
There is no programmer's union. When the industry decides it's time to get rid of developers because vibe coding is faster than mid level developers, there is no counter.
The only developers left will be either true 100x geniuses or vibe coders. I'm not the former so I am trying to make sure I can become the latter long enough to last a few extra years.
Regardless of how much you personally want to resist, this is what is going to happen.
He's essentially saying that it's a complete guess how long the job of a programmer exists, and when it will change over to essentially product manager, of which you'll need a lot less.
While we engineers understand how to judge and evaluate AI solutions, I am not sure Business Owners (BO) care.
BO's are ok with a certain percentage of bugs/rework/inefficiency/instability. And the tradeoff of eliminating (or marginalizing) Engineering may be worth the increased percentage of unfavorable outcomes.
> I'm overjoyed that you only encountered serious "engineers".
Nowhere did I say this. At all. I said I havent heard 'works on my machine' said by serious engineers. That does not mean that I have ONLY met serious engineers.
Precisely. Businesses are okay with bugs if it helps them enter a market faster or stave off competition. Bug fixes are mostly considered maintainancd which is outsourced or "cost-optimized"
Probably depends on BO/stakeholder as well. B2B solution that has a low risk of killing anyone? Maybe fuck it, let the model have its way.
Technology that controls software that keeps people alive, controls infrastructure, etc., uhhhh I don't think so. I guess we're just waiting for the first news story of someone's pacemaker going haywire and shocking them to death because the monitoring code was vibed through to production.
B2B AI LLM vibe-SaaS that has a 10% chance to become profitable and a 10% chance to gift away all money invested into the business ever while leaving founders on the receiving end of 100 lawsuits.
> Isn't the sector for software that is life-critical really small?
I think it's large. Think about the software that goes into something like air travel - ATC, weather tracking, the actual control software for the aircraft... I am aware that nothing is perfect, but I'd at least like to know that a person wrote those things who could be held accountable.
This exactly. Instead of adding Adobe adding AI features to Acrobat that I don't want or need, I would like it to fix the fact that it still can't convert a DOCX to a PDF without messing up the tabs.
The lack of devs that understand the domain knowledge and the codebase will be the main issue.
I would say that the current capabilities of genAI is like a junior dev, sometimes even a mid-level. But one main difference is that a dev is slowly learning and improving and at some point will become a senior dev and also domain specialist.
If there is a codebase created by genAI, then it’s equivalent as if all devs left the company, so no one knows why some piece of code was created in a certain way, if it was part of the business logic or some implementation detail
I wonder if the codebase will be understandable at all.
You can most often “get used” to a codebase because they authors tend to stick to the same patterns in many ways, and they are somewhat coherent across time. After a bit you can kinda guess in what file is a feature implemented etc etc.
Will this still be true with ai doing most of the work?
Claude is really good about documenting what it has done. I’ve also had some good luck with “I’m interested in this part of the codebase please explain it to me”
And “this part is not working let’s diagnose”
I’ve been doing a lot of productionization of nontechnical vibecoding. And I provide a lot of feedback on best practices (one of which is to ask “is this best practices for security and data protection?”)
That being said there’s no replacement for a real knowledgeable human software engineer.
The rate at which AI is capable of producing code is intractable for humans to deal with. Right now the bottleneck is human reviewers. If AI ever becomes effective at generating provably correct code, it's joever.
It's also likely that there are thousands who aren't hustle-culture oriented who have been looking for so long that they don't even count as unemployed anymore.
The proofs are not meant for human consumption. It's for the AI to know to try again rather than spit out hallucinations. Of course there's a leap of faith somewhere here.
nah, just throw more hardware at it. never rewrite buggy code, increase processing power is the winner almost always. That's one of the things that is nice about opensource. You can't hide the crap code unless the users don't care at all.
Why not? Seems to match the trend of tech innovation creating more demand for tech.
The reality is lots of software problems can’t be solved with the level of “intelligence” LLMs have. And if they could, it wouldn’t be just software in danger - it’d be every human profession. Even the physical ones, since AI would quickly figure out how to build machinery to automate those.
The industry might evolve to "AI Please rewrite the faulty code and redeploy, eating the cost of inefficiencies as business expense, instead of hiring back to the Full Software Engineering Employment Levels".
Because it's just cope. Look at the current reality. Are companies rushing to fix bad or even buggy code written by human devs? No, not in most cases. In most cases, if a piece of code "works", it is left the hell alone. And that's the thing about AI code: it does work. The quality is irrelevant in the overwhelming majority of cases (especially if it's other AIs that are adding to it, which is the case more and more often).
> The quality is irrelevant in the overwhelming majority of cases
Software quality is especially important in safety critical applications.
We should not expect an LLM trained solely on formally-verified code to produce formally-verified code. I don't think that also training on specs and hateful training material will fix that.
So then we're back to the original software engineering objectives of writing better SAST, DAST, Formal Method, side channel, and fuzzing tools for software quality assurance.
I've been to birthday parties that employed more people than "safety critical" software development. We're talking about 99.99% of the software development jobs evaporating.
> Is formal verification a required course or curriculum competency for any Computer Science or Software Engineering / Computer Engineering degree programs?
> Is there a certification for formal methods? Something like for Engineer status in other industries?
I love love love Claude Code. It's my weapon of choice. However, we're still a ways off.
The most recent thing I did prior to typing this comment was have it look at a cosmosdb integration and recommend changes to my CosmosClientOptions to reduce CPU, based on a few exceptions I'm seeing.
It recommended 5 changes to 5 settings, and every single one of them was outside of the allowed range for those 5 settings. I told it as much, and asked nicely (always nicely, I don't want to be on the Singularity's naughty list) to try again, those aren't valid values. It came back with 4/5 values within the allowed scope, one still outside of the scope, and 2 of the 4 that were accurate were the same values that I already have configured.
Not there yet. Better every day, but definitely not there.
