Stop Using LLMs to Write Code Faster. Start Using Them to Change What You Build.

You’ve felt it. That little thrill when the LLM spits out a perfect function in seconds. The rush of saving hours of boilerplate. The smug satisfaction of crushing a ticket before lunch. But here’s the uncomfortable truth nobody tells you: the gain from doing what you already know how to do is nothing compared to the gain from redefining what a modern app has to be.

I learned this the hard way building Cloudy—a side project that started as a simple weather dashboard and ended up as something I never would have dared to build two years ago. Not because I suddenly got smarter. Because the LLM didn’t just write my code. It rewired my imagination.

Let me show you what I mean.

When I first started, I treated the LLM like a turbocharged autocomplete. “Write me a Razor page for city search.” It did. Fast. I felt productive. Then I realized: I was building the same old CRUD app, just faster. The mental model of “weather app” I had in my head hadn’t changed. I was still thinking in terms of API calls, caching, and responsive CSS. The LLM was just a faster horse.

So I stopped. I asked a different question: What if this app could do something that wasn’t possible before? I started prompting the LLM for architectural ideas, not just code snippets. “What would a weather app look like if it could predict the probability of rain based on your social calendar?” The LLM didn’t have a perfect answer, but it gave me a starting point. I prototyped three different approaches in an afternoon. That’s the real acceleration: not typing speed, but the speed of exploring what’s buildable.

This is the mental shift that separates the developers who get outsized value from LLMs from the ones who just get faster at the same old stuff. The tool is a conceptual lever, not a typing accelerator. And the biggest risk you face right now isn’t that LLMs will replace you. It’s that you’ll keep building the same apps, just faster, and miss the opportunity to build something that actually matters.

I saw it firsthand. A colleague of mine spent weeks optimizing a caching layer for a dashboard he was building with LLM help. He got the response time down from 200ms to 50ms. Amazing. But the dashboard itself was still solving a problem that had been solved a hundred times before. Meanwhile, another developer used the same LLM to prototype a real-time collaborative document editor that, two days later, uncovered a completely new user need. The first guy optimized a known path. The second guy explored an unknown one. The LLM’s real power is in the second guy’s hands.

This is why the conventional advice—“use LLMs to write unit tests faster” or “generate boilerplate with AI”—is so dangerously incomplete. It trains you to think of the LLM as a productivity tool. But the real leverage is in using it to expand your definition of what a “modern app” can be. The best developers using LLMs aren’t the ones who write the most code. They’re the ones who ask the most provocative questions.

So stop asking, “How can I write this code faster?” Start asking, “What can I build now that I couldn’t before?” Pre-LLM mental models are a cage. The LLM can unlock the door. But you have to walk through. That’s the only acceleration that matters.