Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

robenglander.com

Post reply on HN
Print view View original

81–90 of 119 posts

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

#81

Post by dwoldrich »

mvpmvh wrote: post #44
anilakar wrote: post #39

Earlier quoted context omitted.

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

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

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

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

#82

Post by staticassertion »

sega_sai wrote: post #32

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 c…

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.

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

#84

Post by j3k3 »

zer00eyz wrote: post #74
j3k3 wrote: post #27

Earlier quoted context omitted.

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…

> 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 progr…

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.

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

#85

Post by retrodaredevil »

ffsm8 wrote: post #72
tyleo wrote: 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.

> Ive known people at every company who add copious null checks rather than understanding things and fixing them properly. ynow "defensive programming" is a thing, yeah? Sorry mate, but that statement I'd expect from juniors, which are also often the one's claiming their own technical superiority over others

Adding null checks where they aren't needed means adding branching complexity. It means handling cases that may never need to be handled. Doing all that makes it harder to understand "could this variable ever be null?" If you can't answer that question, it is now harder to write code in the future, often leading to even more unnecessary null checks.

I've seen legacy code bases during code review where someone will ask "should we have a null check there?" and often no-one knows the answer. The solution is to use nullability annotations IMO.

It's easy to just say "oh this is just something a junior would say", but come on, have an actual discussion about it rather than implying anyone who has that opinion is inexperienced.

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

#86

Post by __MatrixMan__ »

j3k3 wrote: post #57
__MatrixMan__ wrote: post #46

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. Now that I can bootstrap a for-this-feature test harness in a day instead of a week, I'm catching much subtler bugs. I…

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.

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.

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

#87

Post by carlosjobim »

staticassertion wrote: post #75
carlosjobim wrote: post #73

Earlier quoted context omitted.

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.

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 employe…

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.

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

#88

Post by staticassertion »

carlosjobim wrote: post #87
staticassertion wrote: post #75

Earlier quoted context omitted.

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 employe…

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.

Right... I mean, no engineer is going to tell you that customers care about unit tests, so I think you're arguing against a straw man here. What engineers will tell you is that bugs cost money, support costs money, etc, and that unit tests are one of the ways we cheaply reduce those costs in order to solve problems, which is what we're in the business of doing.

We are all very aware of the fact that customers pay us... it seems totally strange to be that you think we wouldn't be aware of this fact. I suspect this is where the disconnect comes in, much to the point of the article - you seem to think that engineers just write tests and code, but the article points out how silly that is, we spend most of our time thinking about our customers, features, user experience, and how to match that to the technology choices that will allow us to build, maintain, and support systems that meet customer expectations.

I think people outside of engineering might be very confused about this, strangely, but engineers do a ton of product work, support work, etc, and our job is to match that to the right technology choices.

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

#89

Post by roncesvalles »

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

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

#90

Post by 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.

Post reply on HN