Live data from Hacker News

AI didn't simplify software engineering: It just made bad engineering easier

robenglander.com

61–70 of 119 posts

Re: AI didn't simplify software engineering: It just made bad engineering easier

#61
post #16

> Every few years a new tool appears and someone declares that the difficult parts of software engineering have finally been solved, or eliminated. To some it looks convincing. Productivity spikes. Demos look impressive. The industry congratulates itself on a breakthrough. Staff reductions kick in in the hopes that the market will respond positively. As a software engineer, I'd love if the industry had an actual brea…

> So, once again, the old question: If reducing jobs is the only goal, but people are also expected to have jobs to be able to pay for food and housing, what is the end goal here? What is the vision that those companies are trying to realize?

Capitalism is reliant on the underclass (the homeless, the below minimum-wage) to add pressure to the broader class of workers in a way that makes them take jobs that they ordinarily wouldn't (Because they may be e.g. physically/emotionally unsafe, unethical, demeaning), for less money than they deserve and for more hours than they should. This is done in order to ensure that the price of work for companies is low, and that they can always draw upon a needy desperate workforce if required. You either comply with company requirements, or you get fired and hope you have enough runway not to starve. This was written about over a hundred years ago and it's especially true today in the modern form of it. Programmers as a field have just been materially insulated from the modern realities of "your job is timing your bathroom breaks, tracking how many hours you spend looking at the internet, your boss verbally abuses you for being slow, and you aren't making enough money to eat properly".

This is also why many places do de-facto 'cleansings' of homeless people by exterminating their shelter or removing their ability to survive off donations, and why the support that is given for people without the means to survive is not only tedious but almost impossible to get. The majority of workers are supposed to look at that and go "well fuck, glad that's not me!" with a little part of their brain going "if i lost my job and things went badly, that could become me."

This is also why immigration enforcement is a thing — so many modern jobs that nobody else in the western world wants to do are taken by immigrants. The employer won't look too closely at the visa, and in return the person gets work. With the benefit being towards the employer — if the person refuses to do something dangerous to themselves or others, or refuses to produce enough output to sustain the exponential growth at great personal cost, well, then the company can just cut the immigrant loose with no recourse, or outright call the authorities on them so they get deported. Significantly less risky to get people to work in intolerable conditions for illegal wages if there is no hope of them suing you for this.

Back in the 1900s there were international conventions to remove passports. Now? Well, they're a convenient underclass for political manoeuvring. Why would you want people to have freedom of movement if your own citizens could just leave when things get bad, and when the benefits are a free workforce that you don't have to obey workers rights laws about?

Re: AI didn't simplify software engineering: It just made bad engineering easier

#62
post #16

> Every few years a new tool appears and someone declares that the difficult parts of software engineering have finally been solved, or eliminated. To some it looks convincing. Productivity spikes. Demos look impressive. The industry congratulates itself on a breakthrough. Staff reductions kick in in the hopes that the market will respond positively. As a software engineer, I'd love if the industry had an actual brea…

The goal has nothing to do with you being employed. Your job security is a consequence of the ultimate goal to build AGI. And software development salaries and employment will be affected before getting there. In my opinion, we already past the SWE peak as far as yearly salary. Yes there are super devs working on AI making a lot of dough, but I consider that a particular specialty. On average the salary of a new grad SWE in the US is past its peak if you consider how many new grads can’t get a job.

Re: AI didn't simplify software engineering: It just made bad engineering easier

#63
post #38

"Coding was never the hard part. Typing syntax into a machine has always been the least interesting part of building a system." and I think these people are benefitting from it the most, people with expertise, who know their way around and knew what and how to build but did not want to do the grunt work

I think that captures a lot of the LLM debate. There are people who just want an object produced that allows for some outcome to be achieved closer to the present. And there are other people who want to ensure that object that is produced, will be maintainable, not break other parts of the system etc. Neither party is wrong in what they want. I think there should naturally be a split of roles - the former can prototy…

me and my team have wasted so many hours (days) working on some product features which was "definitely going viral" only to be forgotten after a few weeks

I believe if we had something like this we could go to market early and understand the user behaviour to build a more scalable and robust system once we were sure if it was even of worth

Re: AI didn't simplify software engineering: It just made bad engineering easier

#64
post #21

I disagree with the premise. It made all engineering easier. Bad and good. I believe vibe coding has always existed. I've known people at every company who add copious null checks rather than understanding things and fixing them properly. All we see now is copious null checks at scale. On the other hand, I've also seen excellent engineering amplified and features built by experts in days which would have taken weeks.

In corporate app development, I would see tests to check that the mocks return the expected values. Like, what are we even doing here?

You could ask the same thing about tests themselves. And I'm not talking about tests that don't exercise the code in a meaningful manner like your assertions on mocks(?!)

I'm saying you could make the same argument about useful tests themselves. What is testing that the tests are correct?

Uncle Bob would say the production code is testing the tests but only in the limited, one-time, acceptance case where the programmer who watches the test fail, implements code, and then watches it pass (in the ideal test-driven development scenario.)

But what we do all boils down to acceptance. A human user or stakeholder continues to accept the code as correct equals a job well done.

Of course, this is itself a flawed check because humans are flawed and miss things and they don't know what they want anyhow. The Agile Manifesto and Extreme Programming was all about organizing to make course corrections as cheap as possible to accommodate fickle humanity.

> Like, what are we even doing here?

What ARE we doing? A slapdash job on the whole. And, AI is just making slapdash more acceptable and accepted because it is so clever and the boards of directors are busy running this next latest craze into the dirt. "Baffle 'em with bullsh*t" works in every sector of life and lets people get away with all manner of sins.

I think what we SHOULD be doing is plying our craft. We should be using AI as a thinking tool, and not treat it like a replacement for ourselves and our thinking.

Re: AI didn't simplify software engineering: It just made bad engineering easier

#66
post #21

I disagree with the premise. It made all engineering easier. Bad and good. I believe vibe coding has always existed. I've known people at every company who add copious null checks rather than understanding things and fixing them properly. All we see now is copious null checks at scale. On the other hand, I've also seen excellent engineering amplified and features built by experts in days which would have taken weeks.

I believe the article exaggerates to make a point. Yes, good engineering can also be assisted with LLM-based agents, but there is a delta. Good engineering requires that you still pay attention to the result produced by the agent(s). Bad engineering might skip over that part. Therefore, via Amdahl's law, LLM-based agents overall provide more acceleration to bad engineering than they do to good engineering.

The connection to Amdahl's law is totally on point. If you're just using LLMs as a faster way to get _your_ ideas down, but still want to ensure you validate and understand the output, you won't get the mythical 10x improvement so many seem to claim they're getting. And if you do want that 10x speedup, you have to forego the validation and understanding.

Re: AI didn't simplify software engineering: It just made bad engineering easier

#67
post #2

It also made good engineering easier. AI is an amplifier of existing behavior.

I think it depends on your process. Problems that require creative solutions are often solved through the act of doing. For me, it's the act of writing code itself that ignites the pathways and neural connections that I've built up in my brain over the years. Using AI circumvents that process, and those brain circuits go unused.

Re: AI didn't simplify software engineering: It just made bad engineering easier

#68
post #38

Earlier quoted context omitted.

I think that captures a lot of the LLM debate. There are people who just want an object produced that allows for some outcome to be achieved closer to the present. And there are other people who want to ensure that object that is produced, will be maintainable, not break other parts of the system etc. Neither party is wrong in what they want. I think there should naturally be a split of roles - the former can prototy…

me and my team have wasted so many hours (days) working on some product features which was "definitely going viral" only to be forgotten after a few weeks I believe if we had something like this we could go to market early and understand the user behaviour to build a more scalable and robust system once we were sure if it was even of worth

Yeah thats a good example.

The reality is humans are really bad at knowing what is worth investing into.. until the object is there for all to see and critique.

Every idea sounds great until you spend resources getting into the subtleties and nuances.

Re: AI didn't simplify software engineering: It just made bad engineering easier

#69
post #21

I disagree with the premise. It made all engineering easier. Bad and good. I believe vibe coding has always existed. I've known people at every company who add copious null checks rather than understanding things and fixing them properly. All we see now is copious null checks at scale. On the other hand, I've also seen excellent engineering amplified and features built by experts in days which would have taken weeks.

Even if you agree with the OP, there's a large portion of applications where it simply doesn't matter if the quality of the software is good or terrible as long as it sufficiently works.

Yeah, I've seen this too. I like to call them "single-serving apps". I made a flashcard app to study for interviews and one-shot it with Claude Code. I've had it add some features here and there but haven't really looked at the code.

It's just a small CLI app in 3 TypeScript files.

Re: AI didn't simplify software engineering: It just made bad engineering easier

#70
There are some interesting points here, but I think this essay is a little too choppy - e.g. the Aircraft Mechanic comparison is a long bow to draw.

The Visual Basic comparison is more salient. I've seen multiple rounds of "the end of programmers", including RAD tools, offshoring, various bubble-bursts, and now AI. Just because we've heard it before though, doesn't mean it's not true now. AI really is quite a transformative technology. But I do agree these tools have resulted in us having more software, and thus more software problems to manage.

The Alignment/Drift points are also interesting, but I think that this appeals to SWE's belief that that taste/discernment is stopping this happening in pre-AI times.

I buy into the meta-point which is that the engineering role has shifted. Opening the floodgates on code will just reveal bottlenecks elsewhere (especially as AI's ability in coding is three steps ahead and accelerating). Rebuilding that delivery pipeline is the engineering challenge.

Post reply on HN