Discussion

AI Didn’t Simplify Software Engineering: It Just Made Bad Engineering Easier

groundzeros2015: I’m an AI skeptic and in no sense is it taking my peers job. But it does save me time. I can do research much better than Google, explore a code base, spit out helper functions.

sunir: Simplify? It’s like saying a factory made chair building… what?It’s not simpler. It’s faster and cheaper and more consistent in quality. But way more complex.

yakattak: Anecdotally I have not seen consistency in quality at all.

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

a_void_sky: "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

embedding-shape: [delayed]

agentultra: 100%.There are cases where a unit test or a hundred aren’t sufficient to demonstrate a piece of code is correct. Most software developers don’t seem to know what is sufficient. Those heavily using vibe coding even get the machine to write their tests.Then you get to systems design. What global safety and temporal invariants are necessary to ensure the design is correct? Most developers can’t do more than draw boxes and arrows and cite maxims and “best practices” in their reasoning.Plus you have the Sussman effect: software is often more like a natural science than engineering. There are so many dependencies and layers involved that you spend more time making observations about behaviour than designing for correct behaviours.There could be useful cases for using GenAI as a tool in some process for creating software systems… but I don’t think we should be taking off our thinking caps and letting these tools drive the entire process. They can’t tell you what to specify or what correct means.

qsera: Internet enabled instant to access to all human knowledge as well as instant chit-chat across the globe. Guess what humanity choose to drown itself in?So combine both facts here in context, with human nature, and you ll see where this will go.

woeirua: How many model releases are we away from people like this throwing in the towel? 2? 3?

Sharlin: Compilers made programming faster, cheaper, and more consistent in quality. They are the proper analogy of machine tools and automation in physical industries. Reusable code libraries also made programming faster, cheaper, and more consistent in quality. They are the proper analogy of prefabricated, modular components in physical industries.

staticassertion: > Code Was Never the Hard PartI can't believe this has to be said, but yeah. Code took time, but it was never the hard part.I also think that it is radically understated how much developers contribute to UX and product decisions. We are constantly having to ask "Would users really do that?" because it directly impacts how we design. Product people obviously do this more, but engineers do it as a natural part of their process as well. I can't believe how many people do not seem to know this.Further, in my experience, even the latest models are terrible "experts". Expertise is niche, and niche simply is not represented in a model that has to pack massive amounts of data into a tiny, lossy format. I routinely find that models fail when given novel constraints, for example, and the constraints aren't even that novel - I was writing some lower level code where I needed to ensure things like "a lock is not taken" and "an allocation doesn't occur" because of reentrancy safety, and it ended up being the case that I was better off writing it myself because the model kept drifting over time. I had to move that code to a separate file and basically tell the model "Don't fucking touch that file" because it would often put something in there that wasn't safe. This is with aggressively tuning skills and using modern "make the AI behave" techniques. The model was Opus 4.5, I believe.This isn't the only situation. I recently had a model evaluate the security of a system that I knew to be unsafe. To its credit, Opus 4.6 did much better than previous models I had tried, but it still utterly failed to identify the severity of the issues involved or the proper solutions and as soon as I barely pushed back on it ("I've heard that systems like this can be safe", essentially) it folded completely and told me to ship the completely unsafe version.None of this should be surprising! AI is trained on massive amounts of data, it has to lossily encode all of this into a tiny space. Much of the expertise I've acquired is niche, borne of experience, undocumented, etc. It is unsurprising that a "repeat what I've seen before" machine can not state things it has not seen. It would be surprising if that were not the case.I suppose engineers maybe have not managed to convey this historically? Again, I'm baffled that people don't see to know how much time engineers spend on problems where the code is irrelevant. AI is an incredible accelerator for a number of things but it is hardly "doing my job".AI has mostly helped me ship trivial features that I'd normally have to backburner for the more important work. It has helped me in some security work by helping to write small html/js payloads to demonstrate attacks, but in every single case where I was performing attacks I was the one coming up with the attack path - the AI was useless there. edit: Actually, it wasn't useless, it just found bugs that I didn't really care about because they were sort of trivial. Finding XSS is awesome, I'm glad it would find really simple stuff like that, but I was going for "this feature is flawed" or "this boundary is flawed" and the model utterly failed there.

zer00eyz: "AI" (and calling it that is a stretch) is nothing more than a nail gun.If you gave an experienced house framer a hammer, hand saw and box of nails and a random person off the street a nail gun and powered saw who is going to produce the better house?A confident AI and an unskilled human are just a Dunning-Kruger multiplier.

j3k3: Nicely put.There's this mistake Engineers make when using LLMs and loudly proclaiming its coming for their jobs / is magic... you have a lot of knowledge, experience and skill implicitly that allows for you to get the LLM to produce what you want.Without it... you produce crappy stuff that is inevitably going to get mangled and crushed. As we are seeing with Vibe code projects created by people with no exposure to proper Software Engineering.

arty_prof: In terms of the Tech Debt it is obviously allow to make it a lot. But this is controllable if analysing in depth what AI is doing.I feel I become more like a Product than Software Engineer when reviewing AI code constantly satisfying my needs .And benefits provided by AI are too good. It allows to prototype near to anything in short terms which is superb. Like any tool in right hands can be a dealbreaker.

sunir: My chairs resemble each other. Have you tried ikea?If you are talking about code which isn’t what I said, then we aren’t there yet.

groundzeros2015: It’s a bad analogy because the benefits of industrial machines were predictable processes done efficiently.

sunir: That came later than the beginning. Workhouses came before the loom. You can see this in the progression of quality of things like dinner plates over time.

staticassertion: I think it's easier for good engineers to be good, perhaps. For example, I think property testing is "good" engineering. But I suspect that if you took a survey of developers the vast majority would not actually know what property testing is. So is AI really of any use then for those devs?

tyleo: 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.

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

j3k3: Yeah... nah. As others have said, your analogy does not hold up to scrutiny.

jazz9k: Juniors that are relying too heavily on AI now will pay the price down the line, when they don't even know the fundamentals, because they just copy and pasted it from a prompt.It only means job security for people with actual experience.

lowbloodsugar: > and ensuring that the system remains understandable as it grows in complexity.Feel like only people like this guy, with 4 decades of experience, understand the importance of this.

sega_sai: When I see this: "One of the longest-standing misconceptions about software development is that writing code is the difficult part of the job. It never was." I don't think I can take this seriously.Sure, 'writing code' is not the difficult often, but when you have time constraints, 'writing code' becomes a limiting factor. And we all do not have infinite time in our hands.So AI not only enables something you just could not afford doing in the past, but it also allows to spend more time of 'engineering', or even try multiple approaches, which would have been impossible before.

j3k3: Consistent in quality.. what?

water_badger: So somewhere here there is a 2x2 or something based on these factors:1. Programmers viewing programming through career and job security lens 2. Programmers who love the experience of writing code themselves 3. People who love making stuff 4. People who don't understand AI very well and have knee-jerk cultural / mob reactions against it because that's what's "in" right now in certain circles.It is fun to read old issues of Popular Mechanics on archive.org from 100+ years ago because you can see a lot of the same personality types playing out.At the end of the day, AI is not going anywhere, just like cars, electricity and airplanes never went anywhere. It will obviously be a huge part of how people interact with code and a number of other things going forward.20-30 years from now the majority of the conversations happening this year will seem very quaint! (and a minority, primarily from the "people who love making stuff" quadrant, will seem ahead of their time)

hyperbovine: I’m seeing a real distinction emerge between “software engineering” and “research”. AI is simply amazing for exploratory research — 10x ability to try new ideas, if not more. When I find something that has promise, then I go into SWE mode. That involves understanding all the code the AI wrote, fixing all the dumb mistakes, and using my decades of experience to make it better. AI’s role in this process is a lot more limited, though it can still be useful.

j3k3: Thats because an LLM can access breadth at any given moment that you cannot. That's the advantage it has.E.g. quite often a sound (e.g. music) brings back memories of a time when it was being listened to etc.Our brains need something to 'prompt' (ironic I know) but stuff in the brain to come to the front. But the human is the final judge (or should be) if what is wrong / good quality vs high quality. A taste element is necessary here too.

keeda: Yep, and recent reports from the likes of DORA and DX validate this with data: https://cloud.google.com/blog/products/ai-machine-learning/a...

RobRivera: I'm trying to wrap my head around here.So there are tests that leverage mocks. Those mocks help validate software is performing as desired by enabling tests to see the software behaves as desired in varying contexts.If the software fails, it is because the mocks exposed that under certain inputs, undesired behavior occurs, an assert fails, and a red line flags the test output.Validating that the mocks return the desired output.... Maybe there is a desire that the mocks return a stream of random numbers and the mock validation tests asserts said stream adheres to a particular distribution?Maybe someone in the past pushed a bad mock into prod, that mock validated a test that would have failed given better mock, and a post mortem when the bad software, now pushed into prod, was traced to a bad mock derived a requirement that all mocks must be validated?

anilakar: Agree. Writing code has always been the most time-consuming part that distracts me from actual design. AI just emphasizes the fact that anyone can do the keyboard mashing while reading code is the actual skill that matters.Give the woodcutter a chainsaw instead of an axe and he'll fell ten times more trees. He'll also likely cause more than ten times the collateral damage.

furyofantares: AI Didn't Simplify Blogging: It Just Made Bad Blogging EasierI was hopeful that the title was written like LLM-output ironically, and dismayed to find the whole blog post is annoying LLM output.

polynomial: Robots making fun of us complaining about them.

zackmorris: A -> (expletive) -> BI think we're all in denial about how bad software engineering has gotten. When I look at what's required to publish a web page today vs in 1996, I'm appalled. When someone asks me how to get started, all I can do is look at them and say "I'm so sorry":https://xkcd.com/1168/So "coding was always the hard part". All AI does is obfuscate how the sausage gets made. I don't see it fixing the underlying fallacies that turned academic computer science into for-profit software engineering.Although I still (barely) hold onto hope that some of us may win the internet lottery someday and start fixing the fundamentals. Maybe get back to what we used to have with apps like HyperCard, FileMaker and Microsoft Access but for a modern world where we need more than rolodexes. Back to paradigms where computers work for users instead of the other way around.Until then, at least we have AI to put lipstick on a pig.

__MatrixMan__: Naw, I just yesterday caught something in test that would've made it to prod without AI. It happens all the time.You can't satisfy every single paranoia, eventually you have to deem a risk acceptable and ship it. Which experiments you do run depends on what can be done in what limited time you have. I still throw away 100% of the code that I write within a month of writing it, but now that I can bootstrap a purpose built test harness in a day instead of a week, I'm catching much subtler bugs.It's still on you to be a good engineer.

furyofantares: Well, it's made bad engineering massively easier and good engineering a little easier.So much so that many people who were doing good engineering before have opted to move to doing three times as much bad engineering instead of doing 10% more good engineering.

anilakar: Someone was asked to test untestable code so verifying mock contents was the best they could come up with.

mvpmvh: No. Someone was asked to meet an arbitrary code coverage threshold. I'm dealing with this malicious compliance/weaponized incompetence at $current_job

_pdp_: Put a bad driver in an F1 car and you won't make them a racer. You will just help them crash faster. Put a great driver in that same car, and they become unstoppable.Technology was never equaliser. It just divides more and yes ultimately some developers will get paid a lot more because their skills will be in more demand while other developers will be forced to seek other opportunities.

j3k3: 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 prototype stuff so other individuals in the organisation can critique whether it is a thing of value / worth investing in for production.

a_void_sky: 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 weeksI 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

j3k3: 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.

maplethorpe: I think it depends on your process. Problems that require creative solutions are often solved through the act of doing. It's the act of writing code itself that ignites the pathways and neural connections in my brain. Using AI circumvents that process, and those brain circuits go unused.For this reason, it's not a multiplier for me (unless the number you're multiplying by is 0.5, or something).

nhaehnle: 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.

0xcafefood: 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.

tw-20260303-001: Or it simply made one step over the draft stage faster. It all depends how one uses it.

dwoldrich: 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.

steve_adams_86: # abstract internals for no reason func doThing(x: bool) if (x) return true else return false # make sure our logic works as expected assert(doThing(true)) # ??? # profit It's excellent software engineering because there are tests

carlosjobim: I don't have any idea of what a unit test is, but with AI I can make programs that help me immensely in my real world job.Snobby programmers would never even return an email offering money for their services.

dwoldrich: How will you deal with it? I successfully convinced $big_important_group at $day_job to not implement a policy of failing their builds when code coverage dips below their target threshold > 90%. (Insane target, but that's a different conversation.)I convinced them that if they wanted to treat uncovered lines of code as tech debt, they needed to add an epic stories to their backlog to write tests. And their artificially setting some high target coverage threshold will produce garbage because developers will write do-nothing tests in order to get their work done and not trip the alarms. I argued that failing the builds on code coverage would be unfair because the tech debt created by past developers would unfairly hinder random current-day devs getting their work done.Instead, I recommended they pick their current coverage percentage (it was < 10% at the time) and set the threshold to that simply to prevent backsliding as new code was added. Then, as their backlogged, legit tests were implemented, ratchet up the coverage threshold to the new high water mark. This meant all new code would get tests written for them.And, instead of failing builds, I recommended email blasts to the whole team to indicate there was some recent backsliding in the testing regime and the codebase had grown without accompanying tests. It was not a huge shame event, but good a motivator to the team to keep up the quality. SonarQube was great for long-term tracking of coverage stats.Finally, I argued the coverage tool needed to have very liberal "ignore" rules that were agreed to by all members of the team (including managers). Anything that did not represent testable logic written by the team: generated code, configurations, tests themselves, should not count against their code coverage percentages.

koonsolo: I do agree with you, but don't underestimate the projects where you can actually apply this 10x. For example, I wanted to get some analytics out of my database. What would have been a full weekend project was now done in an hour. So for such things there is a huge speed boost.But once software becomes bigger and more complex, the LLM starts messing up, and the expert has to come in. That basicaly means your months project cannot be done in a week.My personal prediction: plugins and systems that support plugins will become important. Because a plugin can be written at 10x speed. The system itself, not so much.

yubainu: Ultimately, I believe the most important thing is how we effectively utilize AI. We can't and shouldn't entrust everything to AI in any field, not even after AGI is perfected. Sometimes it's important to mass-produce low-quality code, and other times it's important to create beautifully crafted code.

heliumtera: Exactly, a large portion of software development was rejecting code from a intellectually functional human being. AGI is not sufficient to achieve minimum quality code because intelligence was never sufficient

zer00eyz: > As we are seeing with Vibe code projects created by people with no exposure to proper Software Engineering.And I keep seeing products and projects banning AI: "My new house fell down because of the nail gun used, therefore I'm banning nail guns going forward." I understand and sympathize with maintainers and owners and the pressure they are under, but the limitation is going to look ridiculous as we see more progress with the tools.There are whole categories of problems that were creating that we have no solutions for at present: it isn't a crisis it's an opportunity.

j3k3: I personally think its better to be cautious and wait for improvements in tooling to rise. Its not always necessary to be the one to take a risk when there's plenty of others willing to do so, for which the outcomes can then be assessed.

rednafi: [delayed]

staticassertion: It's hard to reconcile "I don't think I can take this seriously" followed by an immediate admission that you agree but that there's some nuance.I think the author's post is far more nuanced that this one sentence that you apparently agree with fundamentally.

staticassertion: It's unclear what point you're even trying to make, other than that AI has been helpful to you. But surely you understand that if you don't know what a unit test is you're probably not in a position to comment on the value of unit testing.> Snobby programmers would never even return an email offering money for their services.Why the would they? I don't respond to the vast majority of emails, and I'm already employed.

carlosjobim: Helpful to me and millions of others. Soon to be billions even.You are employed because somewhere in the pipeline there are paying customers. They don't care about unit tests, they care about having their problems solved. Beware of AI.

j3k3: Change 'good' for 'disciplined'.Problem is.. discipline is hard for humans. Especially when exposed to a thing that at face-value seems like it is really good and correct.

__MatrixMan__: We can cheat on discipline if we design our workflows with more careful thought about incentives.I wound up in a role where I throw away 100% of the code that I write within a few months. My job is about discovering cases where people are operating under false assumptions (typically about how some code will or won't be surprising in context with some dataset), and inform them of the discrepancy. "proofs" would be too strong of a word, but I generate a lot of code that then generates evidence which I then use in an argument.I do try to be disciplined about the code I rely on, but since I have no incentive to sneak through volumes of unreliable code before moving on to the next feature, it's easy to do. When I'm not diligent, the pain comes quickly, and I once again learn to be diligent. At the end of the day I end up looking at a dashboard I had an agent throw together and I decide if the argument I intend to make based on that dashboard is convincing.Also, agent sycophancy isn't really a problem because the agents are only asked to collect and represent the data. They don't know what I'm hoping to see, so it's very uncommon that they end up generating something deceptive. Their incentives are also aligned.I think we can structure much of our work this way (I just lucked into it) where there's no conflict of interest and therefore the need to be disciplined is not in opposition to anything else.

tonyedgecombe: [delayed]

jinko-niwashi: Your "don't fucking touch that file" experience is the exact pattern I kept hitting. After 400+ sessions of full-time pair programming with Claude, I stopped trying to fix it with prompt instructions and started treating it as a permissions problem.The model drifts because nothing structurally prevents it from drifting. Telling it "don't touch X" is negotiating behavior with a probabilistic system — it works until it doesn't. What actually worked: separating the workflow into phases where certain actions literally aren't available. Design phase? Read and propose only. Implementation phase? Edit, but only files in scope.Your security example is even more telling — the model folding under minimal pushback isn't a knowledge gap, it's a sycophancy gradient. No amount of system prompting fixes that. You need the workflow to not ask the model for a judgment call it can't be trusted to hold.

roncesvalles: I think it's easy to forget that the LLM is not a magic oracle. It doesn't give great answers. What you do with the LLM's output determines whether the engineering you produce is good or bad. There are places where you can plonk in the LLM's output as-is and places you can't, or times when you have to keep nudging for a better output, and times when nothing the LLM produces is worth keeping.It makes bad engineering easier because it's easy to fall into the trap of "if the LLM said so, it must be right".

bensyverson: Yeah, seems plausible, or it was just "belt and suspenders." Sure made a lot of pretty green checkmarks.

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.

xg15: > 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 breakthrough, if we found a way to make the hard parts easier and prevent software projects from devolving into balls of chaos and complexity.But not if the only reward for this would be to be laid off.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?

staticassertion: > if we found a way to make the hard parts easier and prevent software projects from devolving into balls of chaos and complexity.I don't really believe this is possible. Or, it's the sort of thing that gets solved at a "product" level. Reality is complicated. People are complicated. The idea that software can exist without complexity feels sort of absurd to me.That said, to your larger point, I think the goal is basically to eliminate the middle class.

neversupervised: 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.

fao_: > 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&#x2F;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."

carlosjobim: You can work with something else if there's no longer any demand for your current skills. If you refuse you should starve.