You can spot AI-generated work from a mile away because it lacks the intentional decisions that make products feel right.
You definitely can where someone has just vibe coded a thing in a weekend. When someone has actually taken a lot of care to use AI to build something well, using many iterations of small steps to create code that's basically what they'd have written themselves and to integrate good UX driven by industry-standard libraries (e.g. shadcn, daisy), then it looks pretty much exactly like any other MVP app... because that's what it is.
For all the praise I give to Claude, I still use it as a fast version of what I would do myself:
- Looking at compiler errors and fixing them. Looking at program output and fixing errors.
- Looking for documentation on the internet. This used to be a skill in itself: Do I need the reference work (language spec), a stackoverflow, or an article?
- Typing out changes quickly. This goes a little bit deeper than just typing or using traditional "change all instances of this name"-tools, but its essence is that to edit a program, you often have to make a bunch of changes to different documents that preserver referential integrity.
All these things can be amazingly faster due to the agent being able to mix the three legs.
However, it doesn't save you from knowing what needs to be done. If you couldn't in principle type out the whole thing yourself, AI will not help you much. It's very good at confidently suggesting the wrong path and taking you there. It also makes bad choices that you can spot as it is writing out changes, and it's useful to just tell it "hey why'd you do that?" as it writes things. If you don't keep it in line, it veers off.
The benefit for me is the level of thinking it allows me. If I'm working on a high-level change, and I write a low-level bug, I will have to use my attention on figuring this out before coming back to my original context. The window of time during the day where I can attempt a series of low-level edits that satisfy a high-level objective is narrow. With AI, I can steer the AI when I'm doing other things. I can do it late at night, or when I'm on a call. I'm also not stuck "between save points" since I can always make AI finish off whatever it was doing.
Agents have gotten better but I believe improvements will be costly from now on. Still, I fondly remember the first interactions and to a degree they still hold true:
Me: Hello AI, could you implement a solution for <problem>?
AI: Of course! Here you are: plonk.
Me: Is that a good solution?
AI: Absolutely not! Don't you dare solve it like this, you should do plonk...
As will Stack Overflow code if you don't actually research before blindly pasting "solutions" from there. It's just a higher chance of being an issue with LLMs. Always treat an LLM like a Junior, and if you don't think you can maintain the code without the LLM, you shouldn't accept the solution. Don't cut corners for speed.
If you say you want to have a retro terminal where you can talk to ChatGPT, instead of telling you to use an LLM CLI in a terminal with a retro theme applied, LLMs will just build you a 500K-line terminal client from scratch uncritically. Even if you ask it to make architectural decisions, it will just riff off of your bad idea. And if you ask for critique, it will tell you bad ideas are good and good ideas are bad. We all have stories about arguing with LLMs until they tell us "Okay actually you're right, I was wrong because I think whatever my training data tells me to think."
8 comments
[ 3.1 ms ] story [ 29.2 ms ] threadYou definitely can where someone has just vibe coded a thing in a weekend. When someone has actually taken a lot of care to use AI to build something well, using many iterations of small steps to create code that's basically what they'd have written themselves and to integrate good UX driven by industry-standard libraries (e.g. shadcn, daisy), then it looks pretty much exactly like any other MVP app... because that's what it is.
- Looking at compiler errors and fixing them. Looking at program output and fixing errors.
- Looking for documentation on the internet. This used to be a skill in itself: Do I need the reference work (language spec), a stackoverflow, or an article?
- Typing out changes quickly. This goes a little bit deeper than just typing or using traditional "change all instances of this name"-tools, but its essence is that to edit a program, you often have to make a bunch of changes to different documents that preserver referential integrity.
All these things can be amazingly faster due to the agent being able to mix the three legs.
However, it doesn't save you from knowing what needs to be done. If you couldn't in principle type out the whole thing yourself, AI will not help you much. It's very good at confidently suggesting the wrong path and taking you there. It also makes bad choices that you can spot as it is writing out changes, and it's useful to just tell it "hey why'd you do that?" as it writes things. If you don't keep it in line, it veers off.
The benefit for me is the level of thinking it allows me. If I'm working on a high-level change, and I write a low-level bug, I will have to use my attention on figuring this out before coming back to my original context. The window of time during the day where I can attempt a series of low-level edits that satisfy a high-level objective is narrow. With AI, I can steer the AI when I'm doing other things. I can do it late at night, or when I'm on a call. I'm also not stuck "between save points" since I can always make AI finish off whatever it was doing.
Me: Hello AI, could you implement a solution for <problem>?
AI: Of course! Here you are: plonk.
Me: Is that a good solution?
AI: Absolutely not! Don't you dare solve it like this, you should do plonk...
Much less countless kids right now talking to these things for hours a day on their parent’s credit card