Two ways to use it, an order of magnitude apart
Oracle mode: paste an error, copy back some code, commit if it runs. Pair mode: state the goal and constraints, give real context, ask for the reasoning, then verify yourself. The first saves minutes and plants landmines; the second turns one generation into reusable experience.
A four-step workflow
- State the goal and constraints: language and version, framework, modules that must not change, performance or compliance limits — write them before asking;
- Provide real context: the full error, relevant code, data structures or interface definitions — not "write me a function";
- Ask for options and evidence: first "likely causes + how to verify", then the concrete change; this cuts fabrication dramatically;
- You verify: run tests, read the diff, check edge cases. The model proposes; you decide.
A reusable prompt template
Role: a backend engineer fluent in Node 20 and PostgreSQL
Task: find why the query below got slow, and give 2 options
Context:
- Table: orders(id, user_id, status, created_at), ~8M rows
- Query: SELECT ... WHERE status = 'paid' ORDER BY created_at DESC LIMIT 20
- Production: p95 rose from 40ms to 900ms
Constraints: no new middleware, no schema change
Output: 3 lines of likely causes first, then options,
each with cost and rollbackFour frequent mistakes
- Error without code: the model can only guess, and the patch will not match your structure;
- Rewrite a large file in one shot: an unreadable diff — split into small verified steps;
- Commit without reading the diff: generated code has the same null, bounds and concurrency bugs;
- Pasting keys or customer data: redact everything unless the environment explicitly allows external use.
What to delegate, and what not to
| Task | Give it to AI | Guardrails |
|---|---|---|
| Explaining errors, finding likely causes | Great fit | Ask for verification steps too |
| Boilerplate, regex, test skeletons | Great fit | Run it before trusting it |
| Comparing designs and trade-offs | Good fit | Require costs, risks and rollback |
| Final code for keys, billing, permissions | Be careful | Human review plus test coverage |
| Conclusions needing current facts | Poor fit | Trust official docs and real checks |
Pairing it with tools on this site
When you ask for structured output, validate it with the JSON tool; when you need to confirm a generated file matches the original, compare hashes; when you are discussing flow or architecture, sketch it on the whiteboard first and write code afterwards.
Try them: JSON formatter, hashing, whiteboard
Turn collaboration into a repeatable loop
- Define the boundary first: write down which files change, how far the change may reach and what acceptance looks like before involving the assistant. Vague boundaries produce oversized output and costlier review.
- Commit in small steps: pause and verify after each small piece rather than generating hundreds of lines at once — problems surface in the first few lines.
- Ask for a plan before code: have it describe the approach and affected callers first; approving the direction catches most wrong turns.
- Outsource verification to tooling: formatting, type checking and tests belong in the pipeline so humans judge behaviour and design instead of machine-checkable details.
- Review your prompting periodically: record prompts and context patterns that worked and reuse them so efficiency compounds.
The assistant excels at producing candidates; humans excel at judging them. Keeping those roles separate is what actually raises throughput.