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.
In this guide
Guide checked 3 months ago: some commands may have changed. Let us know if so.
In short
Framing means turning a fuzzy idea into a spec before writing a single line of code, by asking an LLM to interview you instead of answering: a one-sentence goal, users, prioritized features, tech stack, explicit out-of-scope and risks, then a split into 3 to 5 shippable milestones. Use the best model within reach for this conversation, for example Claude Opus 5.5 or Claude Sonnet 5.5 at Anthropic. The spec then becomes the foundation of the project's memory file (CLAUDE.md or AGENTS.md).
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
Which model for framing?
Framing calls for reasoning and a smooth conversation, far more than for code-writing speed. So use the best model you have access to: a framing discussion uses little, and it’s where a model’s quality pays off most.
- At Anthropic, Claude Opus 5.5 is the default choice. Claude Sonnet 5.5 is right on its heels (the two are tied at the top of Quelle IA’s overall ranking, September 28, 2026 edition) at half the API price: plenty for a small project. Claude Fable 5.1, the most capable and most expensive of the lineup, is for the really thorny framing jobs. Claude Haiku 4.5, fast and cheap, is better suited to small repetitive tasks than to deep thinking.
- Elsewhere, GPT-6 Astra (OpenAI) plays in the same league as the best Claude models; at Google, the newest Gemini 3.8 Flash is level with version 3.7 in Quelle IA’s overall ranking (89.7 vs 89.9 in the September 28, 2026 edition), and Gemini 4 Argon is already listed, with a provisional score.
- Locally, it’s possible, but the gap shows on this kind of open-ended thinking: on a machine with 128 GB or less, the best model you can install at home tops out at 82.4 on Quelle IA’s score, versus 99.9 for Claude Opus 5.5 (local models ranking, in French).
To compare for yourself, Quelle IA’s overall ranking (in French) lists models with their margin of error and price, and Find my model (in French) points you in four questions (task, budget, open weights, memory).
Step by step: from fuzzy idea to spec
Open a conversation with an LLM, preferably separate from your code project: the web interface does the job very well. If you’d rather stay in your agent, switch it to plan mode, where it reads and proposes without changing anything: Shift + Tab until plan mode shows, or /plan, in Claude Code; Tab to switch to the plan agent in OpenCode. Here, we don’t code. We think.
0 of 5 steps done Your ticks stay in this browser.
-
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.
All the commands in this guide
Frequently asked questions
Why not just ask the agent to code the app right away?
Because it will guess everything you have not told it: the tech stack, storage, authentication, design. And it will guess wrong. You then spend hours correcting its assumptions. Framing first means replacing those assumptions with decisions.
Should I frame in my coding agent or in a separate chat?
Preferably in a conversation separate from the code project, and an LLM's web interface does the job very well. If you would rather stay in your agent, switch it to plan mode, where it reads and suggests without changing anything: Shift + Tab or /plan in Claude Code, Tab to switch to the plan agent in OpenCode.
Can I frame a project with a local model?
It is possible, but the gap shows on this kind of open-ended thinking. On a machine with 128 GB or less, the best model you can install at home tops out at 82.4 on the Quelle IA score, against 99.9 for Claude Opus 5.5. Since a framing conversation uses little, this is where a top online model pays off best.
Why write down what is out of scope?
An agent wants to please: without a clear limit, it adds authentication, a dark mode, a REST API or end-to-end tests to a script you run alone twice a month. Writing for example 'no authentication in v1, no multi-user' keeps it from building an overengineered monster. Every out-of-scope line saves you from untangling code you do not need.
Which mistakes should I avoid when framing a project?
There are four classic ones. Running a vague brief too fast, letting the scope swell with one 'while we are at it' after another, specifying every detail before the first milestone, and drifting into code by debating variable names. Interview first, freeze the v1 scope and frame the skeleton, leaving the details to come with use.
Terms in this guide: LinuxAgentLLMAPIOpen-weight modelClaude CodeOpenCode
Spotted a mistake?
A command stopped working, a price changed?
Tools change every month. Tell me what is wrong in this chapter and I will fix it and update its date.
