🧭Framing a project with an LLM
The skill that changes everything. Before writing a single line of code, you turn a fuzzy idea into a crisp spec, by talking it through with an LLM. 80% of the outcome is decided right here.
If you only read one guide on this whole site, make it this one.
The machine, Linux, the agent, the models: that’s tooling. You learn it in a weekend. What separates a project that lands from a project that spirals is never the power of the mini-PC or the model you use. It’s the quality of the framing up front. A superpowered agent let loose on a fuzzy idea produces a ton of code… that doesn’t do what you wanted. An average agent guided by a crisp spec produces exactly the right thing.
Why an LLM is the perfect tool for framing
You could write your spec alone, in a corner. But an LLM is a formidable thinking partner before it’s an executor. It doesn’t get tired, doesn’t judge your dumb questions, and above all: it surfaces the blind spots. You describe your idea, it asks you the twenty questions you didn’t see coming. It’s a free framing interview, on demand.
The classic trap is to skip this step: open the agent and type “build me a task-management app.” The agent will guess. It’ll guess the tech stack, the storage, the auth, the design, and it’ll guess wrong, because you didn’t tell it. Then you’ll spend three hours fixing its assumptions. Framing is replacing assumptions with decisions.
The full loop
Framing isn’t an isolated step: it’s the first link in a loop you’ll repeat on every project.
Brief
An idea in two sentences
Scoping
Spec it out with the LLM
Memory
CLAUDE.md + memory files
Build
The agent codes, you steer
Review
Tests, security, second opinion
Deploy
Tunnel, go live
↻ and we loop back: each round refines the scope and the memory.
Step by step: from fuzzy idea to spec
Open a conversation with an LLM (the web interface, or your agent in chat mode) separate from your code project. Here, we don’t code. We think.
Drop the raw brief, in two sentences
Don’t try to be precise yet. Let the idea out as it is:
“I want a little dashboard that gathers the week’s movie releases, with posters and ratings, accessible from my phone.”
That’s enough to get started. The LLM will do the rest of the clarification work.
Ask it to interview you, not to answer
The magic sentence:
“Before proposing anything, ask me all the questions needed to frame this project: use cases, users, technical constraints, what’s explicitly out of scope. One question at a time if needed.”
That’s the key inversion. You don’t want it to code. You want it to pull the decisions out of your head.
Answer, and let the real constraints emerge
“For whom?” → just you, or the team? “Where does the data come from?” “Does it need to work offline too?” “How many simultaneous users?” Each answer closes a door the agent would otherwise have opened at random.
Have it draft the spec
Once the interview is done:
“Synthesize all that into a structured spec: objective, users, features (prioritized), tech stack, what’s out of scope for v1, and the risks.”
You get a document. Reread it. Fix it. It’s your spec, not its.
Break it into deliverable milestones
The last move: “Break this into 3 to 5 milestones, each deliverable and testable independently, from simplest to most complete.” You’ve got your roadmap. The agent will tackle milestone 1, not the whole project at once.
What a good spec contains
Whatever the format, aim for these sections. This is what turns “build an app” into something an agent executes without guessing:
- The objective in one sentence. If you can’t say it in one sentence, the project isn’t ripe.
- The users and their real use. “Me, from my couch, on my phone” is a spec. “People” is not.
- The features, prioritized. What’s in v1, what waits. Prioritization is the hard decision.
- The tech stack and constraints. Language, framework, where it runs, offline or not, budget.
- What’s out of scope, explicitly. The most underrated section. Writing “no authentication in v1, no multi-user” stops the agent from building a Rube Goldberg machine.
- The risks and unknowns. The things you’re not sure about. The agent can help you resolve them first.
The framing pitfalls
From spec to living project
The framing doesn’t die once the code is rolling. Your spec becomes the bedrock of the project’s memory. Concretely:
- You drop the spec (or its summary) into the project’s
CLAUDE.md/AGENTS.md. The agent rereads it at every session, see Memory files. - At each delivered milestone, you go back to the spec: what changed, what you learned, what you’re deferring. That’s the ”↻ back around” of the diagram.
- The repeated decisions (“we always use this lib,” “we never touch that folder”) crystallize into rules in memory, and you stop repeating them.