Things I’ve realized while working with AI (Claude code):
It’s fantastic for very small macros and medium length scripts. Think dev ops stuff, pre-commit hooks, transforming data. Keep it small enough to manually review and something you can run without destroying anything important. This can massively boost your codebase QoL. [Double bonus for not wasting tokens to solve the same problem over and over]
It’s decent-to-good at debugging but not consistent with fixes. It can find some utf encoding edge case that might have taken you 1hr+ but suggest the dumbest bandaid fix you’ve ever seen. Also very good at spinning up unit test suites for basic edge cases.
Due to obvious training bias, it’s pretty good with common libraries and cloud platform infrastructure. It could probably help with writing a complex cron call, debugging regex or fixing an IaC config. On the flip side it won’t bother to use the latest package version or know your niche/new library.
It does better with greenfield because exploring your codebase introduces a ton of bias. It might try to fit in an ugly hack when a refactor to simplify everything is way easier.
It’s absolutely garbage with UI, just throws the most disorganized HTML together that isn’t reactive or reusable. OK enough for ugly internal stuff but God help anyone relying on it for that.
This is setting up to be the biggest rug pull in history. People that buy into it heavily just to save a couple bucks on engineer payroll are going to be fucked when they start ratcheting up the token price.
All in all it can be useful when used with care but will never be a magic bullet.
I’ve got some godawful spaghetti code I don’t understand fully, and it’s pretty good at deciphering that and the bizarre labyrinth of code paths leading around it. But it’s absolutely no guarantee of working code, and in any project larger than a simple crud app, you are going to still need programmers who know about things like memory and databases.
It often needs pointing at a solution you want, because as you pointed out, it’s fond of dumb band-aids. Like yesterday when it was trying to hook into mouse wheel events and create separate threads, when all it needed was an event on the dataset I was using to load a sub-dataset.
This is basically what I discovered as well. I have found that Ai writes code that is complex and “works” (at least most of the time) but it is heavily over engineered and often contains design choices that make expanding functionality effectively impossible without a full refactor.
When I tried having the Ai fix a test failure the Ai would either fix the code, fix the test, or change the test and the code breaking everything else in the chain.
I no longer use vibe coding because it is just faster/better for me to write the code.
Claude can do some medium complicated sites from scratch relatively quickly. The problem is I’ve seen so many of these at work, not just from non-engineers, but from peers too, that they’re easy to spot. AI sites/apps are going to be the new geocities.
But when you want to move beyond the basic thing that impresses the c suites for some reason, it hits a pretty big wall in speed to output and needs a lot more hand holding.
I fear that the c suites don’t really care about quality, just speed and saving money. So while I’m a much better developer than Claude (which is imo the best at the moment), I don’t think that makes my job secure. I have to use the AI, and it’s getting silly/scary religious here about it. We have to talk about how we used AI and how it’s making things better. And to make things worse, I don’t see a company that’s not drinking the Flavor Aid.
It can be useful, and used right, you can do a lot of things faster. But the expectations from the top don’t align with the reality of the product, and us developers are being blamed for the gap.
Things I’ve realized while working with AI (Claude code):
All in all it can be useful when used with care but will never be a magic bullet.
Yeah, fully agree with all that.
I’ve got some godawful spaghetti code I don’t understand fully, and it’s pretty good at deciphering that and the bizarre labyrinth of code paths leading around it. But it’s absolutely no guarantee of working code, and in any project larger than a simple crud app, you are going to still need programmers who know about things like memory and databases.
It often needs pointing at a solution you want, because as you pointed out, it’s fond of dumb band-aids. Like yesterday when it was trying to hook into mouse wheel events and create separate threads, when all it needed was an event on the dataset I was using to load a sub-dataset.
This is pretty spot on from my experience as well. Also, the gap in quality from the Opus models and say GPT is vast.
100% agree on ui code. Really awful output there regardless of model.
This is basically what I discovered as well. I have found that Ai writes code that is complex and “works” (at least most of the time) but it is heavily over engineered and often contains design choices that make expanding functionality effectively impossible without a full refactor.
When I tried having the Ai fix a test failure the Ai would either fix the code, fix the test, or change the test and the code breaking everything else in the chain.
I no longer use vibe coding because it is just faster/better for me to write the code.
But for tiny scripts it is very good.
Claude can do some medium complicated sites from scratch relatively quickly. The problem is I’ve seen so many of these at work, not just from non-engineers, but from peers too, that they’re easy to spot. AI sites/apps are going to be the new geocities.
But when you want to move beyond the basic thing that impresses the c suites for some reason, it hits a pretty big wall in speed to output and needs a lot more hand holding.
I fear that the c suites don’t really care about quality, just speed and saving money. So while I’m a much better developer than Claude (which is imo the best at the moment), I don’t think that makes my job secure. I have to use the AI, and it’s getting silly/scary religious here about it. We have to talk about how we used AI and how it’s making things better. And to make things worse, I don’t see a company that’s not drinking the Flavor Aid.
It can be useful, and used right, you can do a lot of things faster. But the expectations from the top don’t align with the reality of the product, and us developers are being blamed for the gap.