Twelve years ago, I built the One Hour Build repo to improve how I think about code.
Now that AI can crank out code in minutes, it’s worth remembering that thinking about code still matters.
It’s easy to confuse output with creation. Saying you “wrote” an app because you came up with the prompt is like saying you cooked a burger because you told the chef, “medium rare; extra pickles; no onions.” You didn’t make anything—and just like an undercooked burger, the consequences of poorly made code are dire.
Writing code starts with thinking about it. Skip that, and you won’t be able to debug problems effectively when the code blows up. The recent replacement of software development with “prompt engineering” has convinced a lot of junior devs that typing a well-structured wish into a textbox (“make me a Tetris app that runs in Canvas”) is the same as building software. It’s not.
An LLM cannot tailor its output to the long-term needs of your project or your organization, it can’t consider the needs of your users, and—critically—it cannot be held accountable for the “decisions” it makes. An LLM will happily create a login system with unsafe authentication, letting attackers slip in under the wrong identity—if it means getting to the user’s desired output faster.
Speed is easy; quality is hard. The best engineers are measured by how easily their code can be understood, maintained, and secured.
I’m not anti-AI—it’s great for boilerplate, scaffolding, understanding error messages, and documentation. Hell, I even used it to clean up the punctuation and grammar in this post (the em dashes are mine, thank you very much). The point is to use AI for the rote, boring crap so you can focus on actually writing and understanding your code.
Because when the kitchen catches fire, you can’t put it out by shouting at the chef.