Shipping fast and thinking slow

As a product minded person and engineer, I've always been obsessed with the idea of speed.

Whether that manifest in the form of learning funny rune combinations for (vim motions) or emacs, never looked into that; ricing our terminal experience with tools like fzf, ripgrep, zoxide, bat or even just learning the keyboard shortcuts for our IDEs, we want to be fast.

But even though we want to be fast, we also want to be smart. In the past these two things were not mutually exclusive. Being fast was being smarter, in some sense. When you learned that new shortcut in vim, or that new CLI tool, you could write your code, navigate your codebase, or even ship faster. And every part of this aided one thing: your understanding of the code and the problem at hand.

However, with the popularization of AI and large language models, this has changed. Now we can generate code, and even entire applications, with a single prompt. Even if you don't understand what you're really trying to solve in the first place, you can just prompt the AI "hey, what would be a cool feature to implement" or "how could we flesh this out?"

This is powerful, we think. Before I had to design the database schema for the specific business problem. Wanted to make a notes app? Understand file storage versus database schemas was essential. I had to sit there, design the tables, look at the relations, figure out what a join is, figure out if even a relational database model was the correct idea, go look at that NoSQL vs SQL blog post. And then implement that in the backend, implement the frontend, see how your initial design sucks in terms of UX and refactor it just the way you wanted. See how your component that you thought was generalizable and super perfect is actually a nuisance in terms of architecture and rewrite it. That taught me the architectural principles I use to build with AI today.

Now I can just hop into codex, say, "hey I want to make a notes app" and it'll do it for me. I don't have to think about any of that previous stuff I thought about. I just get a result, the final notes app. It's usable. The UX kind of sucks, I wanted it to be kind of different. But i'm okay with it, don't be ungrateful for the plate in front of you, right? You could be doing other things instead of fleshing out the thing you just developed. The desire to be more productive creeps in, and I leave it, I lose the taste I had before. Maybe this part is just a consequence of being more busy, not being a bored high school student and getting a job, but even at work I see this pattern. Get the result, it's "okay", not the way you truly wanted it, but good enough, accept it as if it were a guilt PR, and move on.

Yeah, that was fast.But did I understand the engineering process? No. I just got a result. And that result is not the same as understanding.

So the solution? I think code more with hand, at least in your free time. You can still see your architecture fall apart, still experiment with agents, and designing products, but slow down.