slowlp
← Blog
Method 2026.06.11 · 9 min read

You Don't Need to Code to Build an App

What non-developers actually need to get right, from a 10-year developer who builds with natural language

Method

You Don’t Need to Code to Build an App

What non-developers actually need to get right, from a 10-year developer who builds with natural language


“Non-developers can build apps with AI now” — you hear it everywhere. What you don’t hear is anyone properly explaining how.

I’ve been a developer for ten years. I can write code just fine, and yet these days a large share of my work happens through natural-language instructions. My stock portfolio app, the automation tools that run this knowledge wiki — all of it. Coming over to the natural-language side as someone who knows code, I can see what non-developers genuinely need to get right and what they can safely ignore. That’s the lens for this post.


Why this became possible

Here’s how it used to work. A person had an idea in their head, and it had to be translated into code — a formal language — before a computer could run it. The people who could do that translation were called developers, which is why no developer meant no app.

Now AI handles that implementation part. You say what you want in plain language, and AI turns it into code. In short: this became possible because AI took over the implementation.

There’s one more shift. Today’s AI is smart enough that you can just figure things out as you go, asking questions along the way. Even if your instructions are clumsy, it comes back with “there are two ways to do this — which do you prefer?” You don’t need a perfect spec up front; you narrow things down through conversation.

Even tools and automation get built in natural language. The commands that run my knowledge wiki — /digest, /capture — aren’t program code. They’re natural-language instructions written in markdown. A non-developer can read them, edit them, and write new ones.


What you still have to get right

So does an app just fall out when you talk? No. You can skip the code, but not the way of working. Here are six things I’ve settled on from doing this myself.

Be specific in your instructions

When AI wrote code for me, it often went somewhere I didn’t intend. At first I thought “this AI is being weird” — then I looked again and realized my instructions were vague. I hadn’t conveyed my intent precisely, so the AI filled the gaps its own way.

“Make it pretty” is not an instruction. Say what you want so a scene forms — background color, whitespace, mood. One line that paints the scene can drive the entire design direction.

Nail down requirements first

If you decide things while building, the AI wobbles with you. Before you start, write down just this much: who the app is for, which features are must-haves, and what you can live without. It doesn’t need to be a grand spec. A few lines of notes will do, and those few lines become the reference point for every instruction that follows.

State your policies precisely

If requirements are “what to build,” policies are “what happens in which case.” Can people use it without signing up? Can a mistaken post be deleted? Does deleting really erase it? If you don’t say, the AI decides for you. The problem comes when its call differs from your intent — and the later you find out, the more it costs to fix.

Keep documents current and findable

AI only ever sees “right now.” It doesn’t remember why you decided something last week. That’s why, as work piles up, the picture in your head and the actual product drift apart.

So record decisions and rules in documents, and when things change, change the documents too. Explaining everything verbally each time doesn’t scale; put it in a file and the AI will find and read it every time. One warning: a stale document is worse than none. When the docs and reality disagree, the AI trusts the docs and marches off in the wrong direction.

Always verify

You don’t need to read code to verify. Run the thing, look at the screen, click the buttons, see whether it behaves as intended.

When the AI says “done,” don’t just take its word. Work that piles up unverified becomes very hard to unwind later — you won’t know where it first went wrong.

Set a target version and finish it

Decide what the core feature is and what goes in and out of the first version (MVP) — then actually finish that version. Building with AI makes adding features so easy that you drift sideways: “could it do this? let’s try that too.” You end up with everything half-built and nothing finished. Expansion comes after the first version ships.


The limits

Up to a prototype or MVP, it’s genuinely fast.

But finishing is hard. Several factors stack up. AI sometimes fabricates plausible-sounding things that don’t exist (hallucination). As work accumulates, one part stops matching another (consistency). And as the project grows, you hit the limit of how much the AI can read and hold at once. So the final stretch — polishing details, handling edge cases — takes long.

That’s true for developers too. Whatever you build with, review is always part of the job.

In this series I’ll share, one piece at a time, what it takes to close that gap — the things I’ve learned to watch for while building with agents.

Agent Engineering series 1 / 7 View all →
COMMENTS