After way too long away from this blog, I’m back (and now with a co-author 🐱)!
So where have I been? Barcelona! Why? I somehow landed a job at Apple as a (Lead) Machine Learning Engineer. Still not entirely sure how that happened, but I’m not complaining.
For the past 4 years, I’ve been working on some pretty interesting stuff around foundation models, search (specifically Spotlight and Siri), and multilinguality. The team was incredible, full of ridiculously smart and genuinely kind people. I got to work on everything from optimizing on-device transformer models to contributing to Apple’s batch inference infrastructure, and even some LLM work spanning pre-training to post-training.
One highlight was getting to present work on improving on-device models to Tim Cook and the AI/ML Leadership at the Steve Jobs Theater, which was both terrifying and surreal. The project focused on making Siri more performant for real-world use cases, which is way harder than it sounds when you’re dealing with the constraints of mobile hardware.
The reason I haven’t posted anything here is pretty simple: Apple is very, very secretive. When your work involves things that might show up in millions of devices, you learn to keep quiet about the details.
But now I’m on a sabbatical and heading to something I’ve wanted to do for a long time: the Recurse Center in NYC for their S2’25 batch! For those who haven’t heard of it, RC is this amazing self-directed programming retreat where you spend 6-12 weeks working on whatever programming projects excite you, surrounded by other curious programmers. No OKRs, no deadlines, just learning and building.
I’m planning to dive deep into high performance AI reasoning algorithms, explore functional programming more seriously, and work on a bunch of other projects I never had the bandwidth for. Most exciting is just being around other people who love programming for the sake of programming.
My thoughts on vibe coding
Speaking of programming, there’s this new trend that’s been making waves called “vibe coding.” The term was coined by Andrej Karpathy and describes a way of programming where you basically let AI generate all your code while you “fully give in to the vibes, embrace exponentials, and forget that the code even exists.”
What is vibe coding, exactly?
The idea is that tools like Cursor with Claude Sonnet are getting so good that you can just describe what you want in natural language, hit “Accept All” on whatever the AI spits out, and somehow end up with working software. When things break, you just copy-paste error messages back into the AI and hope it fixes itself.
I’ll be honest: I’ve tried this approach, and I’m not a fan.
Why I use AI tools (but differently)
Don’t get me wrong, I use AI coding tools every day. GitHub Copilot’s autocomplete is genuinely helpful, and I’ll absolutely ask Claude to help me write regex or debug tricky issues. But there’s a huge difference between using AI as a smart assistant and letting it drive the entire development process.
The problems with pure vibe coding
Here’s what bothers me about pure vibe coding:
1. You lose understanding of your own code. When I write code, even with AI assistance, I’m thinking about architecture, performance implications, edge cases, and how different components interact. With vibe coding, you’re essentially shipping a black box. That’s fine for weekend projects, but terrifying for anything that matters.
2. Debugging becomes a nightmare. When your AI-generated code inevitably breaks in production (and it will), how do you fix it if you don’t understand what it’s doing? Your debugging strategy becomes “ask the AI to fix it and hope for the best.” That’s not engineering, that’s gambling.
3. You don’t actually learn anything. Programming is fundamentally about problem-solving and building mental models of how systems work. If you’re always outsourcing that thinking to AI, you’re not developing those skills. You’re becoming dependent on a tool that might not always be available or might not understand your specific problem.
The reality check
I’ve seen some impressive demos of vibe coding, like Pieter Levels building games entirely through prompting. But when you look closer, these projects often have obvious security issues or work in very narrow, controlled scenarios.
The reality is that most real software development involves understanding existing codebases, working within constraints, collaborating with teams, and making tradeoffs between competing priorities. These are inherently human problems that require understanding context and exercising judgment.
The right way to use AI coding tools
That said, AI coding tools are genuinely transformative when used thoughtfully. The productivity gains from smart autocomplete, code generation for boilerplate, and AI-assisted debugging are real. But there’s a difference between augmenting your programming with AI and replacing your programming with AI.
I think the future is more like what Maximilian Schwarzmueller describes: using AI as a copilot, not a pilot. Let it handle the tedious stuff while you focus on the interesting problems of system design, architecture, and understanding user needs.
My take: Understanding beats vibing
Maybe I’m just old-fashioned, but I believe good software comes from understanding what you’re building and why. Vibe coding might produce working code faster, but I doubt it produces better software or better programmers.
The tools will keep getting better, and the line between “AI assistance” and “AI replacement” will keep shifting. But for now, I’d rather understand my code than vibe with it.