Think Before You Code
What I Learned By Not Writing a Single Line of Code
A few weeks ago, I wrote about how vibe coding isn’t as easy as it’s cracked up to be. I’d been watching how-to videos in which accomplished developers gloated about using apps to write code and raking in thousands of dollars for their efforts.
So, I took a shot at it. The result was nothing to write home about, but I did post an article about how difficult the reality looks to a non-techie. Writing code, it turns out, is the easy part. Knowing what to do with it — what environment it needs, how the pieces connect, how it eventually makes money — that is where most non-developers get lost.
I decided to revisit that experience. Perhaps I could make more progress with a little more experience and deeper insights I also had a real problem to work on.
A Challenge Accepted
A developer friend wanted help getting his photo editing app into the Apple App Store. I had ChatGPT write a framework for that task. It produced beautifully written engineering spec — a complete blueprint for building an App Store submission wizard. It covered everything. Database schema, rules engine, API routes, validation logic, export formats. It was an impressive answer; it took all of ten minutes to create. I barely understood a word.
I had received feedback from my friend that my approach was wrong. I was not entirely sure why, so I brought the feedback to Claude and asked it to explain what was missing.
Claude figured it out immediately.
The problem was not the quality of the spec. The problem was how I got there. I had used AI to skip straight to the answer, bypassing the entire learning process. The spec was excellent, but it was not mine. I could not explain it, defend it, or build on it. Claude identified that gap without me having to articulate it myself.
Redirecting the Effort
Then Claude did something that changed how the whole conversation went. Instead of handing me a polished list of technical prompts to copy, it told me to ask questions in my own language. Not dev-speak. Not techie talk. Just the curious questions a non-developer would ask when trying to understand something for the first time.
I was a neophyte, Claude treated me like one.
My questions were imprecise, but to the point. What information do I need to collect from my friend? Where do his answers get stored? Is that Apple’s server or mine? How does the form actually get built? Who writes the validation rules? What is actually in a submission package? Am I ready to submit after validation or is something still missing?
One question led naturally to the next. Each answer provided me with more information. Misconceptions got corrected in real time. I asked if I was missing anything, and Claude filled in the steps. Concepts I had never encountered before — rules engines, front-end versus back-end validation, local versus hosted databases — suddenly made sense. I learned through conversation rather than having them handed to me.
I remembered when I was a child struggling with my grade school homework. I would ask my father for an answer. He refused to provide it, saying’ “If I tell you the answer, you’ll never learn how to find it yourself.” I howled, but father knows best.
By the end of the conversation with Claude we had not built an app. We had not written a single line of code. What we had produced was a sequence of plain English questions that any non-developer could use to guide an AI conversation toward a complete understanding of what needs to be built.
Steps and Sequences
The sequence of questions I created with Claude is the first step in a three-step process:
Step 1: The question sequence: Plain English questions asked in natural order that build understanding from the ground up. This is what we created together in our conversation.
Step 2: The spec sheet: The question sequence, when fed to Claude or any capable AI, generates a detailed technical specification — the blueprint that tells a developer exactly what to build, how it should work, and what rules it should follow.
Step 3: The app: The spec sheet gets handed to a developer or fed back into an AI coding tool to build the application.
Some people try to jump straight to step 3. I had already made that mistake once by having AI generate the spec for me without understanding it. The feedback I received pointed me back to step 1 where the building starts.
Process Precedes Product
Here is what struck me most. The engineering spec I started with and the understanding I arrived at through questions describe the same application. The difference is that one was handed to me and one I earned. I could defend every decision in the question-based version because I worked through the reasoning that produced it.
When it comes to developing work with vibe coding, the code is almost beside the point. Understanding why you need a rules engine, what a database actually does, where your server fits in, and how the front end and back end communicate — that is the real work.
You do not need to speak like a developer to get there. You just need to ask questions in your own words and follow the thread of logic wherever it leads.
Claude did not build my app. Claude identified my real problem, told me to trust my own voice, and then walked me through a conversation that produced the foundation every app actually starts from — not the code, not even the spec, but the questions that make the spec possible. That is step one. And it turns out that is the step most people skip.
The journey started with glib techies on YouTube bragging about the money they were making using vibe coding. They made it look easy. What they didn’t say was that the easy money only comes after you’ve finished doing the hard work.
My friend looked over my work I and told me there is more to it before I’ve solved the challenge. The app must be configured for the iPhone and a database. A local server is needed for a Mac. The app needs to be tested.
I’ll write plain language prompts for Claude. The replies will not just explain what needs to be built — they will start building it.
Getting Ready for Prime Time
My thought is to sell the app. These are the next steps in that process, and even if I complete them, creating a product and bringing it to market is far more complicated than vibe coding. The danger of letting AI do the work lies in the illusion that the result is a finished product. Thinking along with Claude gave me control of the process.
I am not a developer, and the wizard I designed requires real development work to actually build and debug. Deploying it in a public space and collecting fees requires infrastructure and adds legal and compliance issues. Then there is the sales and marketing dimension – how do I find customers? Perhaps I can apply the same Q and A process to accomplish these tasks, perhaps not. All this is for another day.
Copyright © 2026 Insight Media, All Rights Reserved
You are spot on with this post, and it is an insightful look into the process of using an AI agent to create code with you, not just for you. As someone who started out as a software developer, I find AI agents like Claude Code to be amazing tools. They let me take my ideas from something floating around in my head to prototype very quickly. However, what comes out is still a prototype, not a completely finished project.
I can do a tremendous amount of debugging with an AI agent, create unit tests, run playwright browser tests, but that still doesn't make it a finished product. A finished product still needs a human with a creative touch to review the design language that the application should use. A finished project needs to be tested and reviewed thoroughly by a large number of humans that are going to use whatever I built differently than an AI agent can synthesize from material it as found in its training library.
Agentic AI orchestration and skill systems can help solve some of the challenges that have traditionally been the domain of human testers and debuggers, but not all of them. At least not yet. To me, the ability to create a program with an AI agent still feels akin to magic as someone who has spent years of their life agonizing over lines of code. Contrary to what others feel, I don't find these AI agents terrifying nor do I find them to be a threat. They are tools that let me express my ideas more easily. I am able to focus more on the product than the act of producing the product, and in business this is extremely valuable.
I am excited to see where this all ends up. The ride isn't over yet by any means.