How I build software
without writing code

Most people's relationship with AI looks like this: open ChatGPT, type a vague question, get a vague answer, feel underwhelmed.

Or they watch someone on YouTube ship an app on Lovable in 20 minutes and assume that's what “building with AI” looks like.

Platforms like Lovable, Replit, and Bolt have done something genuinely useful. They've made the idea of building software feel accessible. But there's a ceiling. You're working inside someone else's constraints, with someone else's defaults, producing something that looks and feels like everything else shipped on those platforms.

What I'm talking about is different. A blank canvas. A terminal. An AI agent that writes production code to your specification, with no wrapper, no template, no guardrails you didn't choose.

The output doesn't feel like an MVP. It feels like something you'd be proud to ship on day one.

The skill gap between “I used a builder tool” and “I built this” isn't technical. It's articulation.

Here's what nobody tells you about working with AI: the most valuable skill isn't prompt engineering or knowing how to code. It's knowing your domain deeply enough to describe what needs to exist.

Every operator, founder, and business owner carries years of accumulated knowledge. Pricing decisions, customer patterns, workflow bottlenecks, edge cases. Most of it feels so obvious to you that you'd never think to write it down.

But a machine doesn't have your intuition. It needs all of it made explicit. And the process of making it explicit, through conversation, through dictation, through being pushed with clarifying questions, is where the real breakthroughs happen. You discover things about your own business that you didn't know you knew.

AI is an autonomous driver. Extraordinarily capable, but it needs a map. Your job isn't to write code. Your job is to describe the destination so precisely that the route becomes obvious.

A task estimated at 30 hours by a traditional developer? The AI can execute the build in 30 minutes. But getting to that point means you've probably spent 3 hours hashing out the spec, running initial tests, realising where you didn't want to go, and refining until the map is precise enough that the builder barely needs to ask questions.

That's still a fraction of the traditional timeline. But the time compression doesn't come from AI being fast at typing code. It comes from front-loading the thinking.

The spec is the work. The build is the output.

I call this the Articulation Method. Not because the name matters, but because the skill does. The entire approach rests on one ability: describing what you want to exist with enough precision that an AI can build it.

Every project starts with a single document. I call it the master spec. It's a living file that captures everything the AI needs to know: what we're building, why, the constraints, the design system, the tone of voice, the technical decisions, what “done” looks like.

This isn't a brief you write once and hand over. It evolves. As you build, you learn things about your own requirements that you couldn't have known at the start. Those learnings feed back into the master spec, making every subsequent build faster and more precise.

From the master spec, you derive sub-specs. Each one covers a specific feature, page, or component. A sub-spec inherits the context of the master, so you're never re-explaining your design system or business logic, but adds the granular detail needed for that particular piece of work.

The loop looks like this: master spec governs the project. Sub-specs get spun off for execution. Execution surfaces questions and edge cases. Those feed back into the master. The master gets sharper. The next sub-spec benefits.

This is what makes the method compound. Your first sub-spec might take an hour to refine. By your fifth, the master spec is so rich with context that new features practically write themselves.

Once you trust the method, you stop working sequentially.

One Claude Chat session refines a spec for a new feature. Another is ideating on a completely different problem. Two Claude Code terminals are building different components of the same project simultaneously. A third is running tests on yesterday's build.

You become the conductor, not the player. Your job is editorial: reading output, making decisions, feeding context between streams. The AI does the building. You do the thinking.

This isn't a theoretical workflow. On any given evening, I have four Claude instances running. Two Chat sessions with different project contexts loaded. Two Code terminals executing against different sub-specs. The master spec keeps everything aligned.

You don't need to become a developer. But you should understand the building blocks well enough to have an opinion about what you're building on.

For most of what I build, and what I see other operators and founders needing, the stack looks roughly the same:

This isn't a beginner stack. It's a production stack, the same tools that well-funded startups use. The difference is you're building on it with AI instead of a team of engineers.

Don't let AI push you toward a safe MVP that feels dated the moment you ship it. Start with tools that scale. The build effort is roughly the same either way. The AI doesn't care whether it's writing code for a toy or for production.