I’ve had a really fun time using Codex/Claude to build whatever software I want. Early this year, the SaaS-pocalypse drawdown in software stocks was justified by the notion that many of those companies weren’t going to exist because, in the near future, you could ask Claude to make whatever software you wanted. I think the valuation drawdown was probably overblown, but I can’t deny that I’ve spent the last six months asking Codex/Claude for some kind of weird software and watching it make whatever I asked for.

There are two proverbs which describe a similar behavior but result in polar opposite consequences and ultimately have very different morals:

Without a worry

At this point in time, Vibe Coding is probably even past the hype cycle. Just describing to cursor what you want to do and having the editor generally get it right has been extremely liberating for me and many people. My drive to build things in software had waned, mainly because setting up new projects tended to be a lot of busywork. But with Cursor those pieces of busywork are now hyper automated. I don’t have to worry about being derailed due to e.g. updated interfaces to libraries, I can just tell Cursor to “fix it” and continue my main quest.

I was listening to the most recent episode of Acquired about the founding story of Facebook/Meta, where they discussed a trip that Mark Zuckerberg took to Silicon Valley during the Christmas break just before he started writing the first code for Facebook. David (the podcast host) describes it briefly as

I got LLaVA to run on iOS by re-running training using TinyLlama as the base model and llama.cpp for inference. The UI is janky, but I learned a lot getting it to run on device. While there are a lot of projects that run various LLMs on mobile, I think there are only a few that allow images as an input (and I think there weren’t any when I started on this project). Check it out on GitHub. A huge shout out to the author of the llava example in the llama.cpp project, as well as the author of the llama.swiftui (and of course, llama.cpp in general).

In the past, I’ve been guilty of assuming that I understand someone’s problem. “Got it, what about if you….” I’ve said, cutting the other person off mid-sentence while silently congratulating myself for saving the other person from the burden of speaking their mind. I cringe when I think about times when I’ve done this, and I try not to do this any more.

A simple mushroom based bolognese, with lots of depth.

Adam Ragusea’s Roasted Tomato Sauce is a super simple and quick recipe to make a tomato sauce that takes no effort at all. The only thing to watch out for is burning yourself. As someone who rarely uses a kitchen towel to grasp pans, this one has burned me a couple times (literally).

Jacque Pépin’s Chili con Carne minus the carne. This recipe’s almost comically easy.

I stole this from Bon Appetit. Super delicious, comforting, very forgiving, with a silky texture that is unlike other pasta recipes I’ve made (probably due to the crushed chickpeas).

When I’m learning a new language, I tend to take a very dumb approach (and I don’t mean that in some enlightened way). I’ll usually try out a tutorial or two, but if the language is similar to another language that I know, I’ll basically just start coding without investing a lot of time learning the language features. This leads me to often googling how to do extremely basic things. Stuff like ‘python iterate over dict’. ‘javascript get object keys’. ‘elixir keyword list to map’. In the past, I’ve felt extremely adept at finding exactly what I need, but recently I’ve noticed that it’s been taking me longer and longer to really find the answers I’m looking for.

Programming Languages are created in order to solve problems. This might seem obvious, but I don’t think it is as obvious as it seems. Some languages are focused on working with statistical and numerical data. Some are focused on ease of learning and usage. Others are focused on making it easier to write performant code. There are languages that attempt to work for all usecases and problems. But languages that are crafted to focus on a set of specific problems feel more powerful.

There are tons of posts on the internet about how to write code. There are blogs emphasizing readability when writing code. There are plenty of essays, even books about how to write code that is easy to extend and add functionality. While I think emphasizing readability and adding functionality are important qualities of writing scalable code, I think there’s not as much stuff out there about how to write code that’s easy to debug. I’m hoping to write more of these, but here’s one lesson I’ve learned on making code easier to untangle and debug.