CODING USE CASES
Generate a feature, review a pull request, or plan a repository-wide refactor. Open the workflow that matches the change you need to make.
Production recipe
| What to measure | What to record |
|---|---|
| Patch correctness on your repository | Result, latency, token use, and reason for accepting or rejecting the output |
| Tool-call reliability | Result, latency, token use, and reason for accepting or rejecting the output |
| Latency for iterative work | Result, latency, token use, and reason for accepting or rejecting the output |
| Cost per accepted change | Result, latency, token use, and reason for accepting or rejecting the output |
Generate a feature, review a pull request, or plan a repository-wide refactor. Open the workflow that matches the change you need to make.
Use real requirements, repository conventions, build commands, and review rules. A useful result must work in your codebase, not only look plausible in a response.
Include retries, tool calls, validation, escalation, and manual correction. Compare the total cost of results your application can actually accept, not token price alone.
Start with the highest-volume or highest-risk workflow for which you already have representative inputs and a clear definition of success.
Start with the recommended model and one fallback. Add another only if neither meets the required quality, latency, or cost boundary.
Use the same inputs, context, tools, output limits, validation rules, and stopping conditions for every model.
Compare a primary route and fallback using the same application inputs and validation rules.
