Can you build software with AI if you can't code?
Yes. I built a working app in one day without looking at the code once. The skill it took wasn't coding — it was describing, deciding, and checking.
Yes. One morning I got annoyed trying to save a bookmark. By that afternoon a working app was running on my desk — one that catches my ideas, organizes them, and shows them to me until I decide what to do with each one. I’ve been in technology for over twenty years, and here’s the part that should get your attention: I never saw the code.
Not because I couldn’t read it. Because I didn’t need to. The idea, the design, the trade-offs, the building, the testing — all of it happened as a conversation with my AI. I’ve started calling that skill conversational engineering, because it is a skill, and it isn’t typing code.
What does building software with AI actually look like?
It looks like a conversation that starts with questions, one at a time. I described the problem in plain English: I want to keep track of ideas so they don’t get lost, but I don’t want to be nagged about them — a sticky note that waits, not a to-do list that guilts.
The AI didn’t start building. It asked me one question: “Where do you want to bump into these ideas?” I answered. It asked the next one. Within a few exchanges we’d uncovered something I hadn’t said out loud — I never open organizing apps, no matter how good they are, so the answer had to live somewhere I already look. That one admission shaped the whole product.
Nobody typed code. We were still doing engineering — the real kind, which is mostly deciding things in the right order.
Who makes the decisions — you or the AI?
You do. Every fork in the road came to me as a choice, not a lecture. Should this be a page pinned to my desktop or its own app? Should ideas live in one file or many? What happens when I hit “snooze”? Each time, the AI laid out two or three options with honest trade-offs and a recommendation. My job was judgment: pick one, push back, or say “let’s talk this one through.” Sometimes I overruled the recommendation. It was my product, not the AI’s.
Why write everything down before building?
Because the written record is the AI’s memory. Before any building started, the whole design went into a written plan: every decision, every trade-off, every “later, not now.” That document meant any future work session — the next day, next month, even with a different AI — could pick up exactly where we left off.
Your AI collaborator’s memory resets between conversations. A business owner already knows the fix for that: it’s a standard operating procedure. AI collaboration runs on the same discipline.
How do you know the AI built it right?
You check the work against reality, not just the AI’s word. From the plan, the AI built the app — mapped the steps, wrote the code, wrote 36 automated tests, and checked its own work in a real browser. One bug only showed up live: the tests passed, but the page broke in the browser. It got caught precisely because “verify it for real” was part of the process, not an afterthought.
I reviewed outcomes, not keystrokes.
What happens when the first version is wrong?
You talk it through again — that’s the process, not a failure of it. Version one wasn’t broken. It was wrong. I’d asked for the board on my desktop wallpaper, and living with it for a day taught me that wallpaper hides behind your windows: visible exactly when you’re not working. Flawless on paper, missed in practice.
So we went back to the conversation. What I’d learned, what the real requirement was (it was never “a dashboard” — it was when the dashboard shows up), and what to change. The redesign went into the written plan, ready for the next build session.
Describe, decide, build, live with it, correct. Software has always worked this way. The difference is that the loop used to take a team and a quarter. It took me a day, alone, in plain English.
What does this mean for your business?
It means the skill that matters now isn’t technical — it’s the one you already use with your best contractor. Describe what you actually want. Answer honest questions. Make the calls only you can make. Insist things get written down. Check the work against reality.
You probably don’t need a desktop idea board. But the same pattern gets you a better intake form, a follow-up message that actually goes out, or an SOP your team will use. If you can run a business, you already have the raw material.
The tools finally speak your language. The question is what you’ll say to them.