Is it just me, or are the code generation LLMs we’re all using not that good?

For months, I’ve watched developers praise LLMs while silently cleaning up their messes, afraid to admit how much babysitting they actually need.

I realized that LLMs don’t actually understand codebases — they’re just sophisticated autocomplete tools (with good marketing.)

After two years of frustration watching my AI assistants constantly “forget” where files were located, create duplicates, and use completely incorrect patterns, I finally built what the big AI companies couldn’t — or wouldn’t.

I decided to find out: What if I could make AI actually understand how my codebase works?

Last week, I moved to New York and joined the Recurse Center.

This is after being in San Francisco for a month, staying next to the Embarcadero and attending On Deck Founders.

I’m living in Downtown Brooklyn now, fortunate to find a place that’s just a five minute walk away from the Recurse Center.

It’s been a pleasure to stay in both the cities. Some differences:

AI is incredibly powerful, but it needs guidelines. “Vibe coding” might work initially, but as the project grows, it creates more mistakes than it solves. After fixing countless AI implementations, I’ve distilled it down to three core principles that actually work.

The current wave of AI tools promises to 10x your development speed. What they don’t mention is how they can also 10x your debugging time if implemented poorly. I’m building tools to solve exactly this problem, and I’m sharing some lessons I’ve learned along the way.

I recently moved to NYC since I was accepted by the Recurse Center, and today was my first day at their hub.

The day started by nerding out on the retro computers, hardware labs, and 3d printers they have; followed by the first breakfast bagel of my life. I feel incredibly fortunate to be surrounded out by so many talented programmers and am looking forward to the next three months with my new friends!

Last Tuesday at 1 AM, I was debugging a critical production issue in my AI dev tool. As I dug through layers of functions, I suddenly realized — unlike the new generation of developers, I was grateful that I could actually understand my codebase. That’s when I started thinking more about Karpathy’s recent statements on vibe coding.

For those who missed it, Andrej Karpathy recently shared his thoughts on what he calls “vibe coding” — essentially surrendering code comprehension to AI tools and hoping for the best. His exact words? “I ‘Accept All’ always, I don’t read the diffs anymore.”

I have learnt a lot from Karpathy and use AI tools daily, but there’s a world of difference between augmenting your capabilities and completely surrendering your understanding.

Two days ago, my friend Owen messaged me in a panic. He had built an impressive SaaS app using Bolt, but realized that his OpenAI API key was completely exposed. He was fortunate to have caught it early, but what if this had actually went into production?

Owen isn’t alone. Unfortunately, AI coding assistants often generate functional but insecure code unless explicitly prompted about security concerns.

After walking Owen through securing his application, I realized these lessons could help others. So I compiled this comprehensive security checklist for vibe coders — the same advice that saved Owen’s project.

I also wrote up a “vibe security prompt” at the bottom of the article. Give that to your AI of choice and secure your application!

As a software engineer experimenting with AI for the past 2 years, I’ve tested nearly every AI coding assistant on the market and developed a workflow that consistently delivers results.

Here’s my tried-and-tested method for solo developers looking to leverage AI to make SaaS products.