Vibecoding was bad. But now, AI-assisted coding seems...fine?
Nothing sparks more heated discussions than asking coders about best practices. The other day, someone I follow on LinkedIn shared his weekend AI experiment to build an app. As usual, "passionate" coders threw virtual stones, saying he didn't follow the right approach, engineering practices, or the latest spec workflow.
To turn the conversation around, he asked for our unpopular opinions about AI-assisted coding.
To avoid burying mine in a comment, here they are:
#1. Use AI as a calculator.
Only useful if you know what you're doing. Otherwise, it's just a cool toy.
#2. Don't let AI touch code directly.
That's my go-to rule for coding with AI.
Unproductive? Maybe. But it forces me to decompose problems and validates AI-generated code.
#3. Use AI for opposite tasks.
This is my most recent rule:
If I write code, AI reviews it. If AI generates it, I review it.
According to a recent Sonar survey, only 48% of respondents always check AI-assisted code before committing. #yolo, right? By reviewing, I'm already in the top 50%.
#4. AI is like a semi-autonomous car.
You trust it to steer, but you never take your hand off the wheel. Otherwise, AI could be a sloppy junior coder with bad memory.
AI alone won't make you a great coder. It only amplifies the skills you already have. That's why I wrote Street-Smart Coding—because you need more than syntax to stand out.
Top comments (2)
Sure, never use code that you don't understand.
Personally, the best use of IA for me is to summarize documentation. Many times, docs are lacking a tutorial, so you don't know where to start. Other times, docs are lacking a reference, so you can't go deep once you grasp the basics. IA will even scan forums in order to let you know specific answers, or even build up a starting up tutorial.
About code written by IA, I personally limit it to really mechanic tasks, those things boring that make you lose a lot of time. Because when you review the code the AI gives you, you can only review and correct it (many times deleting redundant steps), if you really understand it.
Those two are good ideas. Documentation is always a pain...to read and write.
Great guideline here. Thanks for sharing it.