Large language models are most useful as collaborators in a controlled loop, not as vending machines for finished truth. A single clever prompt can produce a good answer. A repeatable workflow can produce work you understand, verify, and reuse.
The core loop is:
frame → inspect → propose → test → critique → revise → preserve
Each turn should reduce uncertainty or create an artifact. If the conversation only becomes longer, iteration is not helping.
1. Frame the outcome
Begin with the result and the acceptance test.
Weak:
Help me improve this project.
Stronger:
Reduce the checkout failure rate without changing payment providers. First inspect the current flow and logs. Propose the smallest fix, add a regression test, and report the exact evidence that it passes.
A strong frame includes:
- the desired outcome;
- the available evidence;
- constraints and boundaries;
- what may be changed;
- what “done” means.
You do not need a ceremonial mega-prompt. You need a clear contract.
2. Give context in layers
More context is not always better. Irrelevant material consumes attention and can bury the important instruction.
Use progressive disclosure:
- Give the objective, constraints, and a map of the available material.
- Let the model identify what it needs.
- Provide the relevant files, examples, logs, or sources.
- Summarize established decisions as the conversation grows.
For a codebase, start with the repository instructions, tree, entry points, tests, and exact failure. For an argument, start with the thesis, audience, evidence, and strongest objection.
3. Separate observation from proposal
Ask the model to distinguish:
- what it directly observed;
- what it inferred;
- what it recommends;
- what remains unknown.
This simple discipline reduces confident invention. It also makes review faster because you can challenge the inference without re-litigating the evidence.
A useful prompt is:
List the facts supported by the supplied material, then your inferences, then the decisions that still require judgment.
4. Decompose by risk, not by arbitrary size
A good task boundary has one coherent purpose and one verification method.
For example, improving a web article might split into:
- identify the reader's search intent;
- check current facts against primary sources;
- rewrite the opening and structure;
- add internal links and metadata;
- build and inspect the generated page.
Do not decompose so aggressively that every step loses context. Do separate high-risk claims—security, finance, legal advice, destructive operations—from ordinary prose or formatting.
5. Use examples to define quality
Models respond well to concrete contrast. Provide:
- one example that matches your voice;
- one result you dislike and why;
- a schema or template for structured output;
- edge cases that must survive.
Examples are especially powerful for tone. “Make it engaging” is vague. “Lead with the answer, keep my direct first-person voice, remove filler, and make the strongest objection explicit” is testable.
6. Make the model use tools
When the answer depends on current state, the model should inspect current state.
Useful tools include:
- repository search and tests;
- calculators and scripts;
- primary-source web research;
- browser inspection;
- databases and logs;
- linters, compilers, and validators.
Tool output is evidence, not an oracle. A passing unit test may miss the end-to-end flow. A search result may be outdated. Ask what the tool actually proved.
7. Build verification into the request
The model's first draft is a hypothesis. Verification turns it into a result.
For factual writing:
- cite primary sources near the claim;
- label speculation;
- check dates, names, and numerical examples;
- ask for the strongest counterargument.
For software:
- run the narrow regression;
- run the affected package tests;
- build the product;
- inspect the generated artifact;
- review the diff;
- distinguish an environment failure from a product defect.
For analysis:
- recompute important numbers independently;
- test sensitivity to assumptions;
- look for selection bias and missing denominators.
8. Invite adversarial review
“Check your work” is weaker than assigning a specific attack.
Try:
- What would make this conclusion false?
- Which sentence overstates the evidence?
- Find the first step that can cause data loss.
- Argue the strongest opposing case.
- Identify the assumption on which the recommendation depends most.
- Show me a counterexample.
A useful collaborator should be allowed to disagree with the initial plan.
9. Control hallucination without strangling creativity
Use different modes deliberately.
In exploration mode, permit options, analogies, and speculative connections. In execution mode, narrow the claims:
Do not invent commands, sources, file contents, or test results. If evidence is absent, say what must be checked.
Creativity generates candidates. Evidence selects among them.
10. Maintain a compact working state
Long conversations accumulate obsolete plans and contradictory drafts. Periodically restate:
- current objective;
- decisions made;
- files or artifacts changed;
- tests passed;
- remaining uncertainty;
- next action.
This is more useful than dumping the full transcript back into the model. It creates a portable handoff for a future session or another person.
11. A reusable iterative prompt
Adapt this skeleton:
Outcome: [what should exist when finished]
Audience: [who will use it]
Evidence: [files, data, sources, logs]
Constraints: [behavior to preserve, risks, style, budget]
Process: inspect first; separate facts from inferences; propose the smallest coherent change; implement only within scope.
Verification: [tests, calculations, browser flow, citations]
Handoff: summarize the result, unresolved risks, and exact next step.
The bracketed fields matter more than polished prompt prose.
12. Know when to stop iterating
Stop when the acceptance criteria are met and another turn is unlikely to change the decision. Endless refinement can lower quality by reintroducing errors or sanding away the author's voice.
A good stopping rule is:
- the intended user can complete the task;
- factual claims are appropriately supported;
- known risks are visible;
- tests match the likely failure modes;
- the artifact is clearer than the conversation that produced it.
The larger lesson
Working well with an LLM resembles good management, editing, and scientific practice. Define the objective. Supply relevant evidence. Make uncertainty visible. Test outputs against reality. Preserve what future work needs.
The model contributes speed, breadth, and tireless revision. The human remains responsible for purpose, risk, and the decision to ship.