Constraints & Guardrails
Set explicit rules, what to use, what to avoid, and what not to touch, so the model stays inside safe, correct bounds.
TL;DR
- Constraints are the rules the output must obey; list them explicitly as bullets.
- Use positive rules (what to use), negative rules (what to avoid), and scope rules (what not to touch).
- Guardrails prevent the common failure modes: new dependencies, broken APIs, and out-of-scope edits.
Kinds Of Rule
PositiveName what the code should use so it fits your stack.
- use the existing `logger`
- use zod for validationNegativeName what to avoid so the model stops reaching for it.
- do not add new dependencies
- do not use `any`ScopeBound what the change may touch and when it is done.
- only edit src/cart
- stop when tests passCommon Guardrails
DependenciesLock the toolbox to prevent surprise packages in your tree.
- no new dependencies
- prefer stdlibPublic APIProtect interfaces other code relies on from silent changes.
- do not change exported signatures
- keep return types stableStyle & PatternsKeep new code consistent with the project's conventions.
- named exports only
- match existing error handlingWrite Them Well
Bullet, Do Not BuryA labeled list is followed more reliably than rules hidden in a sentence.
Constraints:
- rule 1
- rule 2Be ConcreteName the specific thing, not a vague principle.
"no new deps" > "keep it lightweight"PrioritizeLead with the rules that matter most for correctness and safety.
Safety + correctness first,
style last.Verify The Rules Held
Check ImportsScan for any dependency the model slipped in against your 'no new deps' rule.
git diff package.json # should be emptyCheck ScopeConfirm the diff only touches files you allowed.
git status # only src/cart changed?Restate If IgnoredIf a rule was dropped, repeat it near your next instruction.
"Reminder: no new dependencies.
Remove the added package."Tips
- Keep a reusable guardrail block ('no new deps, no API changes, match existing style') for routine edits.
- State scope limits for agents explicitly: which directories are in bounds and which are off-limits.
Warnings
- Rules buried in prose get missed; a bulleted 'Constraints:' list is followed far more reliably.
- Too many constraints can box the model into awkward code; keep the list to what truly matters.
In Practice
A constraints block you can paste onto routine edit requests. It encodes the rules that prevent the most common AI mistakes, then you verify they held in the diff.
- The task is stated first, then the constraints as an explicit bulleted list.
- Positive, negative, and scope rules each appear so nothing is ambiguous.
- A stopping condition tells an agent when the work is complete.
- After the change, a quick diff check confirms the guardrails were respected.
Task: add retry-with-backoff to the fetchJson helper.
Constraints:
- use the built-in fetch; no new dependencies
- do not change fetchJson's signature or return type
- only edit src/lib/http.ts
- max 3 retries, exponential backoff, respect an
AbortSignal if one is passed
- match the existing error-handling style in the file
Output: the updated function only.
Stop after the function; do not touch callers.
# Then verify:
# git diff package.json (empty)
# git status (only http.ts)FAQ
Context tells the model what is true (your types, versions, data). A constraint tells it what the output must or must not do (no new dependencies, do not change the public API). Context informs; constraints bound.
Both, used together. Positive rules steer toward your stack ('use the existing logger'); negative rules rule out tempting wrong answers ('do not add a logging library'). A negative rule is especially useful when the model keeps reaching for something you want avoided.
Give an explicit scope guardrail: name the directories or files it may change and say the rest is off-limits. Add a stopping condition so it does not keep going once the goal is met.
If you over-constrain, yes. Forcing too many rules can produce contorted code or make the model ignore some of them. List the constraints that matter for correctness, safety, and fit, and drop the rest.