The Tellenze blog

Tell Your Coding Agent Why the Constraint Exists

A brief can describe the change and still leave its most important decision unstated. Add the reason behind a constraint, then give the agent a concrete way to check it.

· The Tellenze team

One person lifts an ivory cover from an arch model to reveal its teal internal supports while another person inspects the structure.

Imagine asking a coding agent to add a resend button to your application's invitation screen.

The button appears. The email arrives. The tests pass. Then a reviewer asks: “Does resending start the seven-day expiry clock again?”

Nobody put that decision in the brief.

This is an illustrative scenario, but the tension is familiar. A small interface request can conceal a product decision. The person asking for the change knows what “resend” means in this application. The agent sees several technically reasonable ways to implement it.

A useful brief needs one more sentence: why a particular behavior must survive the change.

That sentence gives both the agent and the reviewer something to reason from. It also gives the team a way to notice when an old constraint deserves reconsideration.

The decision hiding inside a button

Suppose this imaginary team has already agreed that an invitation expires seven days after it was created. Sending a reminder must leave that deadline unchanged. Granting someone a fresh invitation is a separate action.

The first brief reads:

Add a resend button to the invitations screen. Show a success message and add tests.

It specifies an interface and asks for verification. It leaves the consequential meaning of the action open.

An implementation could reuse the original invitation. It could generate a replacement. It could call an existing creation helper that silently assigns a new expiry date. All three might look plausible from the request alone.

Now add a constraint:

Resending must preserve the invitation's original expiry time.

Better. But the next contributor may still wonder whether that behavior is a technical limitation or a deliberate decision.

Add its reason:

Resending must preserve the original expiry time because this team treats the invitation as a time-bounded access offer. A reminder must not renew that offer; renewal needs a separate decision.

The extra sentence explains the boundary. It leaves room to choose a sensible implementation while making clear which product choice has already been made.

This is a policy chosen for the example, not a universal rule for invitation systems. Your application might deliberately renew invitations. The brief should state your actual decision and its reason.

Give the reason somewhere to lead

A rationale becomes more useful when it points to something observable.

For our invitation example, a reviewer could check an invitation created on Monday at 10:00 and resent on Thursday at 15:00. Its expiry should still be the following Monday at 10:00. Tests can use a controlled clock so this check stays repeatable.

The brief also needs the relevant neighboring behavior: accepted and revoked invitations cannot be resent, and expired invitations follow the application's existing policy. Otherwise, the agent may preserve the date while accidentally making an old offer usable again.

Anthropic's guidance on evaluating agents recommends clear tasks and checks covering both when behavior should occur and when it should not. It also distinguishes an agent's account of its work from the resulting state. Applied here, “the resend test passed” is useful only if the test examines the behavior the team cares about.

A fuller brief could be:

Outcome: An administrator can remind the recipient of a pending, unexpired invitation from the invitations screen.

Existing decision: Keep the original expiry time. A reminder must not renew the team's time-bounded access offer. Accepted, revoked and expired invitations remain unavailable for this action.

Context: Read the current invitation policy, resend path and relevant tests. Link the policy decision and identify the existing checks before editing.

Verification: With a controlled clock, resend an eligible invitation and check that its stored expiry is unchanged. Check the three ineligible states too, using a test mail sink rather than real recipients.

Boundaries and handoff: Prepare the implementation and evidence for review. Do not change invitation policy or send live emails. If the current behavior contradicts this decision, report the mismatch before changing that behavior.

The important addition is the connection between the reason and the check. The agent has a target, a boundary and a route to evidence.

Leave the engineering choices open

It is tempting to go further: prescribe the helper, the file, the exact sequence of calls and every line of the test.

Sometimes that precision is necessary. A public interface, a compatibility requirement or an established architectural decision may leave little freedom. But a speculative implementation plan can also make a brief brittle. The first repository inspection may reveal a better existing path.

Anthropic's context-engineering article describes a balance between vague guidance and overly rigid instructions. Its practical recommendation is to provide relevant information and let agents retrieve further context through useful references. This is engineering guidance from a model vendor, not proof that one briefing format improves every project.

For a bounded coding change, my suggestion is to explain the product decision firmly and describe the implementation tentatively. “Preserve the expiry because a reminder does not renew access” is stronger direction than “call this helper” when you have not yet checked what that helper does.

Prose alone does not enforce the rule. Application controls and appropriate tests still need to uphold it. The rationale helps someone select and review those checks; it cannot replace them.

There is a tradeoff here too. Explaining every constraint can bury the request in history. Choose the ones a reasonable implementation might violate. Link longer decisions rather than copying whole discussions into the brief.

And keep reasons open to evidence. If the application now uses a different access model, an old rationale may no longer apply. Surface that conflict for a decision. Do not silently remove the rule, or preserve obsolete behavior simply because it was once documented.

Try one sentence before adding another page

Clearer context is worth trying, but it is not an automatic productivity gain.

METR's July 2025 study found that 16 experienced developers took 19% longer with the early-2025 AI tools available to them across 246 tasks in familiar open-source repositories. That finding concerns a particular setting and tool generation.

Its February 2026 update reported that selection effects and measurement problems made the newer experiment an unreliable measure of current productivity impact. Neither study tests the briefing approach proposed here.

So treat this as a small experiment in your own work.

Pick one upcoming change. Write the outcome, then identify the constraint most likely to be mistaken for an implementation detail. Add its reason and one concrete counterexample that would reveal a violation.

Use this compact pattern:

We want [observable outcome].

Preserve [behavior or boundary] because [the decision or risk behind it].

Inspect [current policy, relevant code and evidence].

Check [a normal case and a case that would expose a violation].

Return [the change, evidence and unresolved questions] for [the agreed review or next action].

In Tellenze, the public agent guide recommends keeping the intended outcome, constraints, relevant documents and verification with the original work item. That gives the next reviewer somewhere to inspect the decision behind the change.

Afterward, ask whether review uncovered fewer unstated product decisions. Record any extra briefing time and any rework as well. One task will not establish a general result, but it can show you which sentence the next brief needs.

The most revealing review question may be simple: did we explain why this behavior mattered before asking the agent to change the code?

Further reading