The Skill Nobody Talks About When It Comes to Building With AI

There's a conversation that dominates the AI building space right now, and it's mostly about tools.

Claude vs GPT. Cursor vs Copilot. Replit vs Bolt. Which one is smarter, cheaper, faster, more reliable.

I spent six months in that conversation. Trying things, switching things, looking for the tool that would finally produce what I imagined.

Then I had a realization that felt embarrassing in hindsight: the tools were fine. They were all fine. The problem was me — specifically, my inability to describe what I wanted clearly enough for the AI to build it.

What "unclear" actually looks like

When I say "I want to add login to my app," I feel like I've been clear. I've named the feature.

But here's what I haven't told the AI:

• What kind of login? Email and password? Google OAuth? Magic link?
• What should happen after a successful login? Where does the user go?
• Do I have existing auth infrastructure, or are we starting from scratch?
• What should happen if the login fails?
• What page does the user come from, and what's the URL they land on?

Every single one of those blanks gets filled by the AI using its own defaults. A developer who builds login systems every day has developed good defaults over years of real-world feedback. The AI's defaults are generic — they're technically correct, but they're not yours.

The result is output that's always almost-right. Close enough to be frustrating. Far enough from what you actually wanted to require an afternoon of corrections.

Brief-first: the approach that fixed it for me

I started writing a short brief before every AI request. Four parts:

What I'm building — one specific thing, described specifically enough to hand to a contractor. Not "a login page" but "an email/password login form that, on success, redirects to /dashboard. On failure, shows an inline error message without clearing the form."

What I already have — my stack, existing files, anything the AI should build on top of rather than around. If Supabase is set up, I say so. If there's already a client at lib/supabaseClient.ts, I say where it is.

What it should NOT do — explicit constraints, and this is the most important part. "Don't change any files outside what I mentioned. Don't install new packages. Don't add features I didn't ask for." Without this, the AI will be helpfully thorough in ways that create new problems.

What success looks like — the exact thing I'll test when it's done. "I can enter my email and password, click Login, and land on /dashboard. If I enter wrong credentials, I see 'Invalid email or password' without losing what I typed."

The unexpected benefit

The first time I sat down to write a brief for a feature I thought would take thirty minutes, the brief itself took fifteen minutes. Partway through, I realized I hadn't thought through two edge cases.

Those edge cases would have cost me hours to discover and fix in the AI's output. Finding them in my own thinking instead — before I typed a single prompt — was the most productive fifteen minutes I'd spent all week.

The brief isn't overhead on top of the work. It is the work. The AI handles implementation. You handle thinking. The faster you think, the faster everything goes.

This is what Briefli automates — it guides you through the brief with a short interview, asks the questions you'd otherwise skip, and produces a structured prompt you can paste into any AI coding tool. The thinking still happens. It just happens faster, guided by the right questions.

Start a free interview →