Live data from Hacker News

Why AI hasn't replaced software engineers, and won't

normaltech.ai

41–50 of 386 posts

Re: Why AI hasn't replaced software engineers, and won't

#41
post #3

I have found that the attention moves to thinking about the things I want done and planning, reading and iterating over the specs and other artefacts that will be part of running the agents. I still need to understand the code and iterate over it to get to a usable and maintainable point. I find the problem is we are reaching the top of the slop curve. I will subside because it's impossible to actually do anything us…

I find that it depends a lot on the project.

I'm doing solo mobile app projects, and I have no need to iterate on specs. The bottleneck is QA testing whether it works on the phone.

I don't need to carefully review and understand the implementation. It's not important whether I understand the details of how exactly UICollectionView in Apple's UIKit works.

I see that my implementation works on different physical devices, my tests cover device rotation, and I checked the memory allocations in the Instruments tool.

It has been some months of part-time work on my side, and I will publish this iOS app soon.

Without AI I could not have done it, the scope of the features is too large. The project is around 100k LOC.

It is not true that projects become unmaintainable and abandoned because of agentic engineering, or even vibecoding if you want to call it that.

Re: Why AI hasn't replaced software engineers, and won't

#42

It most certainly will replace software engineers. What's missing is, as the article suggests, the "Delivery" bit. But that's not the realm of software engineers, that's the realm of DevOps/SRE/Cloud engineers. I work as a cloud engineer and have been contacted by multiple non-engineering friends who have now been able to create their pet projects from scratch in different languages and have it running locally, as we…

Yeah, it won't. SWE here with a sidegoal to tackle the deployment side through various means (homelabbing, grabbing sre/cloud/observability tasks at work).

The biggest observable improvement in my post and pre ai development is the ability to tackle two projects at once, if the agent is on track. If not, and I have to do a deep dive to debug, it basically regresses to plain old everything like before.

Re: Why AI hasn't replaced software engineers, and won't

#43
post #18

It most certainly will replace software engineers. What's missing is, as the article suggests, the "Delivery" bit. But that's not the realm of software engineers, that's the realm of DevOps/SRE/Cloud engineers. I work as a cloud engineer and have been contacted by multiple non-engineering friends who have now been able to create their pet projects from scratch in different languages and have it running locally, as we…

In your example, those projects were not the domain of engineering. Your friends couldn't afford expertise and those projects never would have been made before. Therefore, these are net-new projects that replace nothing that came before. This is common in technology, especially software, that improvements in efficiency make software cheaper and expands the total pool of possible software. And, even if one of the "one…

> Therefore, these are net-new projects that replace nothing that came before.

this and on top of that they'll hit a wall and require human intervention sooner or later if those projects are actually productionized.

Re: Why AI hasn't replaced software engineers, and won't

#44
> software development, as a “decide-execute-deliver sandwich”. AI compresses the “execute” layer — the middle of the sandwich — but the other two layers resist automation in a way that will not be overcome by capability improvements alone.

I really struggle to see why improved capabilities cannot deal with those other layers. I do not believe you have substantiated this claim about not being possible as capabilities improve.

> At one end of the pipeline, development teams need to decide what to build.

Developers are not the ones that do this largely. This role is far more on the side of "Product Owner". Sometimes your job covers both, but this is not the majority of the work and does not mostly require SE knowledge - some input usually.

> This layer is hard to automate because it requires thinking about user needs, market signals, organizational priorities, and in some cases regulatory constraints.

Hmm, these are language models that can talk through much of this already - but more importantly none of what is mentioned there requires software engineering. For parts that do (I'm sure someone would come to correct me if I said that there was none or seemed to suggest it is never ever ever relevant) this is a much smaller slice.

> As AI capabilities improve, the kinds of decisions that can be delegated to AI increase over time. But this does not make the “decide” layer thinner — once a decision can be delegated to AI, it is no longer a source of competitive advantage, and the value of human decision-making migrates upward. Software increases in complexity over time, so there is no ceiling to this process.

Now this is rather hidden but a huge leap in logic. The decide layer does get thinner for all the same projects, and then you simply assert that software will get more complex and so this cancels it all out.

A team of 5 may end up being able to ship what a team of 50 used to, and maybe now there are 10 teams outputting more - but is there not a clear limit to this? At some point do we not just need 45 fewer people? That there needs to be some engineers is not the same as needing anywhere near as many as we have.

For a time I think we will see increased output meaning more software, but that tails off as they get better.

> At the other end of the sandwich, human teams need to be accountable for what they deliver.

Why? And if we assume so, why does that need a software engineer?

> It is possible that some day in the future teams will ship mission-critical code without fully testing and understanding it,

You don't need to read code to test it, and people choose to ship products without fully understanding the code all the time. Literally any decision maker who is not a software engineer who knows the entire codebase does this. Companies fully ship systems that are far too complex for any single developer to even understand.

And much of software isn't mission critical. Or at least, if you want to say it is then the mission is low stakes.

> today’s AI is so unreliable that such haphazard practices would represent an existential threat to software teams and their customers.

I'd argue for a bunch of stuff this isn't true, and the whole point of the article is "never even if they get better" which is different.

> A central insight of AI as Normal Technology is that we can collectively choose to keep humans accountable through shared norms, law, and policy.

Sure, we can ban AI writing code, but will we? Is there a huge collective concern for all us high paid engineers being replaced by AI?

Re: Why AI hasn't replaced software engineers, and won't

#45

It most certainly will replace software engineers. What's missing is, as the article suggests, the "Delivery" bit. But that's not the realm of software engineers, that's the realm of DevOps/SRE/Cloud engineers. I work as a cloud engineer and have been contacted by multiple non-engineering friends who have now been able to create their pet projects from scratch in different languages and have it running locally, as we…

LLMs can now quite trivially write Terraform or Ansible code to setup infra, maybe harder for non-engineers to make those prompts for now. But ongoing maintenance and monitoring would require an online agent evaluating signals and deciding when to take what action or prompt the user. Like autoscaling decesions can be already automated and some failover/recovery for simple cases. Probably people releasing hobby projects do not need too much. And then there are things like exe.dev to wrap that and make it simply to give an execution env instead of you and your agent managing your own infra.

Re: Why AI hasn't replaced software engineers, and won't

#46
post #34

"In this essay, we argue that there is enough evidence to reject the narrative that once AI capabilities reach a certain threshold, it will cause mass layoffs." - too late, it already did

The layoffs I’ve seen are those where the CEO claims it’s because of AI.

Re: Why AI hasn't replaced software engineers, and won't

#47

It most certainly will replace software engineers. What's missing is, as the article suggests, the "Delivery" bit. But that's not the realm of software engineers, that's the realm of DevOps/SRE/Cloud engineers. I work as a cloud engineer and have been contacted by multiple non-engineering friends who have now been able to create their pet projects from scratch in different languages and have it running locally, as we…

AI-assisted coding is great, but vibe coding IMO is only good for disposable prototypes.

You're not going to vibe-code a financial app that needs to be maintained indefinitely.

You're also not going to mess with legacy systems.

I think that AI has definitely replaced _some_ engineers, but I don't think your use case is relevant. Your non-engineering friends have created their pet project because they now can, but it's not as if they were going to hire anyone to do it, right? They haven't up until now.

Re: Why AI hasn't replaced software engineers, and won't

#48
post #33
post #10

Earlier quoted context omitted.

> It most certainly will replace software engineers. I would say it will most certainly replace software developers . There is a subtle difference between these terms.

There truly is not. Software engineering is not different in any meaningful way. Sure 30 years ago in waterfall land we were emulating the project management of engineering, with miserably expensive results. But it's all the same now. It's like differentiation between coding and programming, it's different in everyone's head.

If there is no difference, then it is just the result of everyone inflating the term in their CVs/LinkedIn etc.

Software developer typically is the one which builds typical CRUD app, front-end, back-end with database and something around that. Their main job is to make the software to apply clear business requirements on software level, while the software itself is not likely revolutionary. Or they are not the responsible ones to make it revolutionary. They provide code in demand.

Then there are engineers that may apply math problems to software and optimise and develop new algorithms, compilers etc. The software itself might be revolutionary and the business.

Re: Why AI hasn't replaced software engineers, and won't

#49
post #30

I think it's people who were sloppy about programming are more interested in vive-coding. Because now they can make something without the mental rigour needed. Engineering as it should be is play of rigour. Those who value understanding system will continue the human aspect of it

Judging by all the trivial errors made in pre-AI code, many of us are far from rigorous a lot of the time.

It’s like that story about the programmer who wants to send the car down the slope one more time to see if it does the same thing again (or whatever it was). The ephemerality makes iteration possible and appropriate, but also makes rigour less important.

Re: Why AI hasn't replaced software engineers, and won't

#50

It most certainly will replace software engineers. What's missing is, as the article suggests, the "Delivery" bit. But that's not the realm of software engineers, that's the realm of DevOps/SRE/Cloud engineers. I work as a cloud engineer and have been contacted by multiple non-engineering friends who have now been able to create their pet projects from scratch in different languages and have it running locally, as we…

The thought experiment I like to have is imagining my company running without engineers and just LLMs. The thought of my CEO or sales guys sitting down and reading/redirecting LLMs all day is just hilarious. My CEO is highly technical but he has other shit to do. The first thing they'd do is hire someone to do that for them, and the best person for that task is someone who knows how things _should_ be.

Now they'll probably get someone on discount, because our salaries are going to tank due to evaporating demand, but I sincerely doubt it'll be zero-d demand.

What I expect is a 3D printer moment - tons and tons of homebrew / shareware style software coming out, an explosion of boutique code.

I also expect a CNC machine moment - vastly reduced demand for hands-on specialists, and more babysitting of automted processes. But it's those machinists who got those jobs.

We could be looking at a long term suppression (~80% reduction?) in demand though until economic growth produces enough demand to employ ~50M software engineers again, if ever. The cliff is unlikely, I'd guess the unregretted loss will be replaced by AI productivity every year, and some portion of growth will, too.

I also guess that all the AI companies can become massively successful without causing much unemployment just by following Claude's model - charge a certain tangible % of a salary for assisting the worker. https://jodavaho.io/posts/ai-jobpocolypse.html

Post reply on HN