← Back to Thoughts
Essay
Feb 2026

Why I stopped writing code and started writing prompts

The shift from traditional development to AI-assisted creation changed how I think about building things. Here's what I learned after 6 months of going all-in.

Six months ago, I made a decision that felt radical at the time: I stopped writing code the traditional way. No more boilerplate. No more Stack Overflow rabbit holes. Instead, I started writing prompts — describing what I wanted to build in plain English and letting AI do the heavy lifting.

The shift wasn't instant. The first few weeks felt like learning a new language. I had to unlearn the instinct to jump straight into an IDE and instead spend time thinking about what I actually wanted. Ironically, this made me a better builder. When you have to articulate your intent clearly enough for an AI to understand, you end up with a much sharper vision of the end product.

There's a common misconception that working with AI means giving up control. In my experience, the opposite is true. When I was writing code by hand, I'd often settle for 'good enough' because the cost of iteration was too high. Rewriting a component meant hours of work. But with prompts, iteration is cheap. I can describe a variation, see the result in seconds, and decide whether to keep it or try something else. This dramatically raised my quality bar.

The mental model shift is subtle but profound. Traditional coding is bottom-up: you start with syntax, build functions, compose them into features. Prompt-driven development is top-down: you start with the outcome you want and work backward. You describe the user experience, the edge cases, the constraints — and then let the AI figure out the implementation details. It's like the difference between painting stroke by stroke and describing a scene to a skilled artist.

One thing that surprised me was how much better my documentation became. When your primary interface is natural language, you naturally create a paper trail of intent. Every prompt is a mini-spec. Every conversation is a design document. I found myself spending less time writing docs because the development process itself was generating them.

Of course, this approach has its challenges. The biggest one is debugging. When something goes wrong in AI-generated code, you can't just trace through your own logic — because it's not your logic. You have to develop a different kind of intuition. I've learned to read AI-generated code like I'd read a colleague's pull request: with fresh eyes, checking assumptions, questioning patterns that seem unusual.

Another challenge is the temptation to over-delegate. Not every problem is best solved with a prompt. Sometimes you need to understand the underlying system deeply, and that means getting your hands dirty with the actual code. The skill is knowing when to prompt and when to code — and that boundary shifts as the tools get better.

I've also noticed that this way of working changes team dynamics. In a traditional engineering team, seniority is often correlated with coding speed and pattern recognition. In a prompt-driven workflow, the most valuable skill is the ability to think clearly about problems and communicate that thinking effectively. Junior engineers who are strong communicators can suddenly punch way above their weight.

The tools are evolving fast. Six months ago, I was mostly generating isolated functions and components. Now I'm describing entire features — including the tests, the error handling, the accessibility considerations — in a single conversation. The ceiling keeps rising, and I find myself spending more time on product thinking and less on implementation details.

Looking back, the biggest change isn't in how I build things — it's in what I choose to build. When the cost of creation drops dramatically, you can afford to experiment more. I've built and thrown away more prototypes in the last six months than in the previous three years. Most of them went nowhere, but the ones that worked were ideas I never would have pursued if each one required weeks of traditional development.

If you're on the fence about making this shift, my advice is simple: start small. Pick a side project. Commit to building it entirely through prompts for two weeks. You'll be frustrated at first, but push through it. The mental model clicks eventually, and when it does, you won't want to go back.