AI gave me 20 hours back each week, but I'm still not shipping faster¶
AI has compressed time in my life. This time compression has unlocked a lot, but perhaps not in the ways you'd expect.
Nothing you don't already know, right?
The Productivity Gains Are Real. The time savings compound in ways that still surprise me:
- Code Generation: With Cursor/Claude Code, what took 2 hours now takes 20 minutes
- UI Prototyping: V0/Loveable let me skip Figma entirely, concept to interactive UI in under an hour
- Documentation: PRDs, technical specs, API docs, all generated and refined 10x faster
- Research: Competitor analysis, technical architecture decisions, library evaluations, compressed from days to hours
Where the Compressed Time Goes¶
That reclaimed time splits into two buckets that matter deeply to me:
As a Father:
- I pick up my son from pre-school
- We play soccer in the backyard
- I'm actually present during bedtime, not mentally debugging production issues
As a Technical Founder:
- I spend real time with customers, understanding their actual problems
- I dive deeper into GTM strategies instead of just shipping features
- I think more about users and less about implementation details
- I can afford to experiment with ideas that might fail
The founder benefits are transformative. When you're not drowning in implementation details, you can actually think about the business.
The Intelligence Paradox¶
But here's the uncomfortable truth: AI hasn't made me smarter. It's made me faster, but getting to production still takes forever.
Let me break down the reality:
Testing¶
Unit tests are fine, AI can write those well. But end-to-end test cases with multiple systems integrating together? That's where things fall apart. Some might call it a skill issue or context engineering problem, but I might as well write the test cases myself. The mental model required to verify complex integrations still lives entirely in my head.
Business Logic Limitations¶
The code quality for business logic is... okay. Just okay. It's functional but rarely optimal. I still need to create mental proofs to verify it works in the broader system context. The amount of time it takes me to write a prompt with all the context is a lot, might as well start writing code. I'm proficient in writing code, so I just start doing it. What I'm trying to say is that putting thoughts from my head into code is faster than giving AI all the context in a prompt.
Design Coherence Gap¶
V0 and Loveable are incredible for prototyping, but the design language is all over the place. Components don't speak the same product language. There's a lack of reusability that makes production deployment painful. You get a working prototype fast, but making it production-ready requires manual, thoughtful work.
The Over-Engineering Problem¶
AI-generated PRDs tend to over-specify. Engineers end up more confused, not less. O3 and Gemini do a decent job, but they still need heavy editing to provide actual clarity. It's like having an eager intern who writes novels when you need haikus.
Performance at Scale¶
I'm still spending significant time optimizing data models, applying the right indexes, dealing with scale issues. AI can suggest indexes, sure. But understanding query patterns, anticipating growth, making trade-offs between read and write performance remains a human problem.
The Production Gap¶
All these limitations point to one reality: while AI has given me time leverage through compression, getting to actual production still takes longer than it should.
One day this will change. GPT-5 will arrive, and Twitter/X will explode with another round of "developers are doomed" discourse. But the reality, particularly in enterprise environments with dense business logic and complex data models, is that there's still a mountain of work in the trenches.
The Evolution I'm Still Learning¶
Beyond AI writing code, there's another pattern I've noticed in myself and other engineers: the constant temptation to write everything from scratch. It feels safe. It feels like control.
But just like how we evolved to use open source, leveraging the collective intelligence of developers worldwide, we need to make the same leap with AI-generated code. Reading code, whether from team members, open source libraries, or AI, and building a mental model around it is a skill. And I'll admit, I haven't fully evolved yet. I'm still learning.
I've become a better programmer over the years by reading open source code and learning from the collective intelligence of others. Take a bloated library like LangChain. My instinct says writing a token text splitter myself would be easy. But when I actually read their implementation, the inputs, outputs, test cases, I realize they've thought through edge cases I haven't even imagined.
The value isn't in rolling something from scratch. It's in delivering customer value. There's no pride in reinventing wheels when you could be solving actual problems.
The skill lies in making trade-offs:
- When to use existing solutions
- When to write from scratch
- When to fork and modify
- When to wrap and abstract
With AI, it's the same evolution. The code is there, generated in seconds. My job is to read it, vet it, understand it, and adapt it to my specific needs and problems. Just like with open source, I need to leverage this collective knowledge, except now it's the collective knowledge of AI trained on millions of code repositories.
I'd rather have this problem, too much compressed time and not enough production readiness, than the old problem of never having enough time at all.
The future isn't about AI replacing us. It's about learning when to leverage AI for time compression and when to apply human intelligence for the complex, nuanced work that still defines great software. And just like my journey with open source, this evolution takes time.
I'm still learning. We all are.
Subscribe
Honest takes on AI, startups, and digital health—delivered to your inbox.
Your privacy is paramount. Expect content once or twice a month. Unsubscribe anytime if you don't like it.
Get Email Updates