alt Hacker News> used javascript events for mouseover CSS effects rather than using the :hover selector, which is a totally unscalable way of writing mouseovers
It's good he gave an example because I frequently encounter these "fragility" arguments at work and it invariably turns out to be a giant F nothingburger. This was way before AI as well. Some type of people just cannot see the forest for the trees and this is a good example of that.
No mention of where this mouse handling took place but in my experience It Just Does Not Matter, but let's say it does. Let's say it's some super important bit of UX that suffers terribly from this approach.
I understand, I'm a dev. I'm familiar with how little things can matter. So sure, the mouseovers are implemented in a strange way. It causes issues in practice and not just in theory (which is IME 1% of cases), well, redo them. You think that takes more than an hour? If so, I question your ability to function in this job. Actually, document how mouseovers should be handled because apparently it's so important. This will never happen again. Think about the process, think about how you can prevent this. Don't focus on tiny little instances in time causes by tiny specific human beings, focus on the general, the universals. Everything you wrote shows me you are severely incapable of doing that. The fact you even focus on mouseovers and not on bigger issues shows me you have a questionable ability to allocate your scarce - it's scarce in all of us - cognitive capital.
Your fragility points all can be handled by skilled use of AI tooling. It's really F easy as well. "AI writes overly complex code", really? That's your point? Come on. Tell it not to. Instruct it, shape the process. Define your terms, document your ideal code style. I guarantee you it's better at it than you are once it knows what you want.
In my practical experience your points are all false:
1) Our AI-driven products have less incidents 2) They are (way) easier to reason about 3) I don't even know what point 3 is going on about because devs famously only look at code and don't think about the end-user at all resulting in famous dev UIs 4) They all have a (much) better user experience, we're talking orders of magnitude like a different - more capable - company produced them
Sure, I hear ya'll geniuses shouting in unison our devs suck and you all could have done this in 5 seconds and are so, so superior, but guess what? Even if what you say is true, and it's not, you are few and far away and out of reach for us lowly regular businesses.
Replies
> It causes issues in practice and not just in theory (which is IME 1% of cases), well, redo them
You often find issues “in practice” when your users find them. User trust is a limited resource that does not currently scale with LLM code generation rates.
> Tell it not to. Instruct it, shape the process. Define your terms, document your ideal code style. I guarantee you it's better at it than you are once it knows what you want.
I (somewhat, it will choose its own path at odd times) agree, but the rate that it generates code dwarfs mine, so it’s generating issues “in practice” at levels I could never reach. AI + human is going to beat either in isolation in all cases, and I don’t see this ever changing until they can read our minds.
At my company, we have a “10x” AI team that doesn’t read the code. They had a lot of clout until they launched and were reprimanded for a staggering number of issues ranging from technical bugs to weird UX choices.
I’m not sure if their issues were caused by not reading the code or not knowing what they don’t know. Based on personal experience, if I stopped reading the code it would cause similar issues in my app, so I still read the code.
> hear ya'll geniuses shouting in unison our devs suck
The software world is huge. I’ve worked with devs who spent their whole careers in relational dbs and never heard of isolation levels. Entire modes of failure they don’t even know exist. I imagine they’d see code and claim it’s great where others would see the holes. And both could be right: there are business domains where it doesn’t actually matter.
The range of takes on LLMs is downstream of this diversity.
I agree with a lot of your points but I think you undersell the problem with the "1%" cases.
The problem isn't fixing it. The problem is detecting it's a problem in the first place.
Stack this with dozens of over "1%" cases and you're in for a world of hurt.
So yes it doesn't matter. But it also does.
This reminds me a bit of security at our company. "Technically I don't need to escape that because it's just an integer." My response always is: technically you don't have to, but technically every dev who reads it needs to check that its an integer. Make the code obviously correct.