The most successful startup I’ve worked with shipped their MVP in 6 weeks.
The least successful one spent 4 months writing specs for a product that never launched.
Here’s what I’ve learned after helping dozens of teams transition from traditional planning to AI-powered development: writing-first culture made sense when building was expensive and slow. Now it’s just bureaucracy.
I celebrate another revolution around the great big ball of fire today. This was a big year for me: I founded my first product startup, all solo.
I’m doing something really hard but I realize I’ve never written down my guiding principles about why I do this. This article is mostly a reminder for me: on what it takes to achieve greatness.
Here’s what I’ve learned so far:
My favorite view of San Francisco: the legendary Dolores Park MUNI StationContinue Reading →
Every developer I know has the same frustrating ritual. Open Claude Code or Cursor and ask it to do a task. The AI gives you generic code, sometimes useful (but usually not). You correct it. It apologizes. You explain again, with additional context.
Rinse, repeat, until you want to throw your laptop out the window.
David Cramer from Sentry recently shared his AI workflow where he maintains manual rules files to give LLMs context. Solid approach, but it feels like too much copy-pasting. It’s 2025, and machines can do a better job of remembering things.
It’s funny how we’ve built the most powerful reasoning systems in human history, then lobotomized them by making them forget everything after each conversation. My question: is there a better way?
This is part of my “AI in SF” series, where I share real AI engineering workflows from San Francisco startups. I recently interviewed engineers from Parabola (they’re hiring btw, more on that at the end). Here’s a technique to teach AI to learn from your mistakes.
You know that feeling when you leave the same code review comment for the third time this month? “Hey, we use relative imports here, not absolute ones.” Or “Remember to handle both null and empty string cases.” Or “This should use our ORM helper, not raw SQL.”
Your team agrees it’s important. People follow it for some time. But three weeks later, nothing’s changed, and you’re still leaving the same comments.
I recently interviewed C.J. and Zach from Parabola (a Series B data automation company) about how they use AI in their engineering workflow. They shared a simple approach that’s replaced most of their linter rules: teaching Cursor to remember code review feedback permanently.
This is a part of my “AI in SF” series, where I share real AI engineering workflows of SF startups. I recently interviewed an engineer from Pallet (they’re hiring - more on that at the end). Here’s an insight that will make your AI-generated code better.
Most developers use Cursor like expensive autocomplete. They let it generate whatever code it wants, fight with inconsistent outputs, and spend more time debugging AI mistakes than they save.
There’s a better way. During my interview with Vidhur from Pallet, I learned about a simple technique that made their AI-generated code dramatically better: the “gold standard” file approach.
Social media is full of people showing off their perfect little demo apps claiming AI is revolutionary, meanwhile, AI keeps suggesting fixes for files that don’t exist or rewrites working code into broken messes.
Does that sound familiar?
Here’s the thing — the “vibe coders” are not wrong about AI being powerful. They’re just not dealing with what you’re dealing with.
You’re working on a real codebase, with real dependencies, real business logic, and real users. Real codebases are messy.
I spent ten years of my life running a development agency, and Cursor has legitimately saved me weeks of work, but only after I stopped expecting it to just “figure things out.” Now, I’m going to share with you the workflow that made Cursor work for me on complex projects.
