honestly makes me want to learn haskell and find a company that focuses on it.
I'm so tired (so incredibly tired) of all the ai slop I've seen, just in my company, and the ai-bros frothing at the mouth about the next terminal to run their agents and how it's making them "so much faster"; even a comment yesterday (with supporting sentiment) that having to do something without ai was tediously slow.
The problem is that the _generation_ part is fast. So people only remember that. They don't remember the time taken to craft a good prompt that gets to a reasonable output. They don't remember the time wasted in PR over swathes of comments. They don't remember the days I spent having to unfuck the project from aigen code that literally broke checkout. They got their little dopamine hit, and moved on.
I use ai - claude, to be specific - as an "interactive stack-overflow", to ask questions about the code, and to help me learn how to be better. I still firmly believe that the biggest problem with ai-gen adoption is that the people who think they're getting the most out of it are the same people who don't understand what it output, so are unable to push back when it does something stupid.
I have to push back _regularly_. Like at least 30-50% of the time.
The tools are only useful (imo) when an expert can verify the results - even in cases where I wasn't sure of the actual workings of the code (eg getting Claude to use the typescript ast to do clever linting or type-file generation), I can verify via tests - the box can remain black if I can verify the output. The average vibe-coder verifies nothing directly - it launches, so it's good, right? Oh, how did our checkout screen end up infinitely putting-and-polling at two endpoints? No problem - give it to a real engineer to solve it.
I'm with Linus on this - ai is a _tool_. And much like how we wouldn't allow shit code from any other tool (ide, compiler, linter, whatever) to sift into prod, we should be on top of what we're using this tool for - not putting the onus on someone else to clean up the garbage. AI codegen is most dangerous in the hands of people who have no idea what it's doing - they're firmly stuck in the initial Dunning-Krueger peak, unaware of just what a mess they've made.
Not to mention duplication - literally just had to ask someone to refactor so that we're not sending two components which are 90% the same to the client, but rather pulling out the 90% core into a mixin. Code is so over-commented, it simply _has_ to be ai-gen. But I also can't call it out, because now it's dev egos in the mix too.
The one golden hope I'm leaning on is that eventually everything will implode, people will see the light, and go back to using a tool as a tool, instead of just trusting the bag of words to do it right. In particular, I've learned that ai is to be incorporated in some ingestion pipeline where the final result has financial implications. That's going to be hilarious when it makes a proper goof.
davydm•39m ago
I'm so tired (so incredibly tired) of all the ai slop I've seen, just in my company, and the ai-bros frothing at the mouth about the next terminal to run their agents and how it's making them "so much faster"; even a comment yesterday (with supporting sentiment) that having to do something without ai was tediously slow. The problem is that the _generation_ part is fast. So people only remember that. They don't remember the time taken to craft a good prompt that gets to a reasonable output. They don't remember the time wasted in PR over swathes of comments. They don't remember the days I spent having to unfuck the project from aigen code that literally broke checkout. They got their little dopamine hit, and moved on.
I use ai - claude, to be specific - as an "interactive stack-overflow", to ask questions about the code, and to help me learn how to be better. I still firmly believe that the biggest problem with ai-gen adoption is that the people who think they're getting the most out of it are the same people who don't understand what it output, so are unable to push back when it does something stupid.
I have to push back _regularly_. Like at least 30-50% of the time.
The tools are only useful (imo) when an expert can verify the results - even in cases where I wasn't sure of the actual workings of the code (eg getting Claude to use the typescript ast to do clever linting or type-file generation), I can verify via tests - the box can remain black if I can verify the output. The average vibe-coder verifies nothing directly - it launches, so it's good, right? Oh, how did our checkout screen end up infinitely putting-and-polling at two endpoints? No problem - give it to a real engineer to solve it.
I'm with Linus on this - ai is a _tool_. And much like how we wouldn't allow shit code from any other tool (ide, compiler, linter, whatever) to sift into prod, we should be on top of what we're using this tool for - not putting the onus on someone else to clean up the garbage. AI codegen is most dangerous in the hands of people who have no idea what it's doing - they're firmly stuck in the initial Dunning-Krueger peak, unaware of just what a mess they've made.
Not to mention duplication - literally just had to ask someone to refactor so that we're not sending two components which are 90% the same to the client, but rather pulling out the 90% core into a mixin. Code is so over-commented, it simply _has_ to be ai-gen. But I also can't call it out, because now it's dev egos in the mix too.
The one golden hope I'm leaning on is that eventually everything will implode, people will see the light, and go back to using a tool as a tool, instead of just trusting the bag of words to do it right. In particular, I've learned that ai is to be incorporated in some ingestion pipeline where the final result has financial implications. That's going to be hilarious when it makes a proper goof.