Writing INTENT and CONSTRAINTS

A weak INTENT block looks like a function description in plain English. A strong one looks like the first line of the source file.

Weak intent:

I want a function that removes duplicates while keeping the order.

Strong intent:

Write a Python function dedupe_preserve_order(items: list[str]) -> list[str].

The strong version commits to the language, the function name, the parameter name, the parameter type, and the return type — five decisions in one line. Now the model has nothing left to invent at the API surface.

A good INTENT block answers three questions:

1. What is the signature? Name, parameters with types, return type. Type hints in Python, full TS types in TypeScript, full Go signature with receiver and error return.
2. What does it do at one sentence of resolution? "Remove duplicates while preserving first-seen order" — not "make the list nicer."
3. What are the side effects? Pure function? Mutates input? Reads from disk? Network? If you don't say, the model will assume pure.

CONSTRAINTS is where you encode the things every reviewer cares about that don't fit in the signature. They fall into four buckets:

Bucket	Example constraints
Performance	O(n) time, O(1) extra memory, must finish in under 100ms for n=10,000
Dependencies	No external imports, only stdlib, Python ≥ 3.10, no lodash
Style	Type hints required, no any, snake_case, no nested ternaries
Behaviour	Case-sensitive, raise ValueError on empty input, idempotent

A heuristic: if you can imagine a reviewer commenting "you should have used X" or "this won't scale because Y," then X and Y belong in CONSTRAINTS. Front-load every objection.

Picture the model's decision flow when it reads your INTENT + CONSTRAINTS:

The most important constraint engineers forget is the negative one — the thing the model should NOT do. "No external imports" stops it from reaching for more_itertools. "No regex" stops it from inlining a clever pattern that nobody on your team will read. "No mutation of inputs" stops a side-effect bug. Every "no" you write saves a code review round.

You'll see this principle in action when we look at the matching CONSTRAINTS block for the dedupe function in lesson 5: O(n) time, O(n) memory, preserve first-seen order, case-sensitive, no external imports, type hints required.

Next up: writing the TESTS and FORMAT blocks. :::