The Paradox of Speed
Why Slowing Down May Be an Optimal Strategy
When I started coding with LLMs, it felt like magic. I don't say that lightly. As someone who was non-technical, but who had plenty of ideas, it was astounding to see how my ideas could be spun up into very simple web apps.
What really shook me was designing some simple apps using V0. Created by Vercel, V0 was (and remains) a quick and easy way to build the front-ends of web apps.
V0 has now expanded into full-stack development, but the revelation for me was seeing decently-designed applications from a simple prompt or two.
Granted, the backend logic wasn't there. These apps couldn't do much. But they inspired me to keep building and refining my prompting skills.
Then I "graduated" to Cursor. I had used other IDEs before (like VS Code), but the chat feature in Cursor was a game-changer. While I rely on it to write a good amount of my code, I also use it as a personalized tutor. Instead of reading random Stack Overflow posts or trying to search for a key paragraph in lengthy documentation, I can just chat with Cursor. Usually, it gives a pretty decent answer (or, at least, enough of an answer for me to learn more by myself).
All of this is great. That said, one of the things that frustrates me about LLM coding agents is their speed.
If you'd like to get these posts two days earlier, feel free to sign up for my personal newsletter. Thanks so much in advance!
On one hand, it's pretty stunning how quickly you can get a web or mobile app built these days. All you need to do is give Cursor an idea that you have and it's off to the races.
Oftentimes, you'll quickly get something that starts to run. More often, however, you'll get something that may work but has plenty of bugs under the surface. Trying to fix these bugs often becomes a nightmare (I can speak from experience).
It's the paradox that I'm constantly thinking about. It's also why I haven't yet tried Claude Code. Sitting in my seat, I would rather take things slower and truly understand what is going on in the codebase rather than vibe-coding a brittle app in a few hours. While it may take me much longer to ship, I'm more confident in the final work product. Maybe it's the former lawyer in me…
So what does this all mean? Yes, speed is essential when shipping products. It's something that's always at the top of my mind. That said, speed shouldn't come at the expense of quality. Personally, I'd rather rein in Cursor with task managers and a robust testing framework before haphazardly building something.
It goes without saying, but we're all trying to figure this out. Especially for someone who wasn't the most technical before tools like Cursor emerged, it's helpful for me to take it slow and learn as much as I can. But that may not be the case for you. The only way is to try, make mistakes, and alter your strategy from there.
What I Found Interesting This Week
Six Weeks of Claude Code: Speaking of Claude Code, this blog post is an interesting reflection on how Claude Code has helped the writer become much more efficient. If you have used it (or are thinking of using it), you'll find some key takeaways that can help you get more out of this widely-discussed tool. But like the author says, it's better to find one tool that you like and stick with it. It's all too tempting to try the next greatest LLM or coding app. It's better to spend less time focused on the tools and more time building what you actually want to build.
Prompt of the Week
I was revisiting Atomic Habits a few days ago and was trying to think of ways to better incorporate lessons from the book in my life. As a test, I tried asking ChatGPT. The prompt below was pretty good in helping me develop a plan.
"Imagine that you are an expert in James Clear's book Atomic Habits. From what you know about me, I want you to develop a seven-day action plan to implement the most relevant takeaways from the book. Keep it actionable and make it a realistic plan that I can execute, considering my busy schedule and already-existing commitments."