I've shared my thoughts on AI coding in a few recent YouTube videos, and it seems quite a few of you resonate with 'AI Hell'.
I doubt I'm the first person to coin this term, but it's what I describe as the trap developers fall into when they use AI incorrectly.
For completely new devs, it's especially risky.
If you're learning your first programming language, AI will feel like magic.
It can write full programs for you that will work (for a while).
If you have some coding experience and are learning a new language, this will feel even more efficient.
When I first started learning Go, I was able to build out the backend for what would become Creator Kiwi's API.
I had tons of helper functions and utilities to build out a REST API.
I had database models that were generated from Go structs and storage methods that let me interact with that database.
For a couple of months I made a ton of progress and felt like I learned a lot about Go.
However, it got to a point where I realized I didn't understand most of what I was writing. I would simply tell AI to write a function or copy an example from somewhere else in the code.
I had tricked myself into thinking I understood this language.
I stopped using AI when writing Go code for a while and retaught myself the language.
After a couple of months I could understand why the AI told me to write what it did and add new functionality without referencing anything or asking a model for help.
I've only recently started using AI more as I'm writing backends, but that's only because I have a much higher level understanding where reviewing AI output is quick for me.
I'm not telling the API to implement a feature, I'm describing the exact architecture and methods I need.
At this point AI is simply writing the code faster than I can. I'm just telling it what I was going to write anyway.
That's what makes spot-checking much easier.
You get into trouble when you ask an AI to write something you don't understand.
This creates complex spaghetti code that's a nightmare to debug.
Almost certainly it will need to be rewritten from scratch if you care about your future sanity.
To know what code needs to be written, some amount of planning is required.
Most devs that vibe with the idea of "ship fast" or "move fast and break things" assume that implies you shouldn't plan.
I think it's the opposite.
Planning helps you move quicker.
When you know every API route you need and the exact flow a user goes through, writing the code is the easy part.
Every time I jump into a new project without thinking about it beforehand, I regret it.
I shipped my first commercial app SLOWLY because I didn't plan the feature set that would make up my MVP.
I just sat down every day and started coding.
Once you find a project management workflow that you're comfortable with, there comes the point that you need to release all that code you wrote (assuming it's not a one-off side project).
Even though I work alone on Creator Kiwi, I work on separate git branches for every feature and open pull requests on GitHub once I'm done.
AI has been surprisingly good at reviewing code.
Every time I've opened a PR it's found a serious bug I completely missed.
It's like having a second eye on your code from a senior developer.
Currently, I use Cubic to review every PR and Coderabbit to review my commits locally.
Coderabbit has a VS Code extension that can start a free review after any of your commits. They also have a CLI that I'll be testing soon.
Ensuring that I understand the code AI produces is my top priority. I made a full video talking about my approach.
20 gradient wallpapers
20 gradient wallpapers
I forgot to mention it last week, but I just dropped a new set of wallpapers based on the Creator Kiwi design system.
Have a great week.
Cole
P.S. If you found this letter helpful, please consider sharing it with a friend :)
Sign up to receive more insights on building digital products.