Give It The Constraint You Are Embarrassed By

A pattern I noticed in my own prompts, and then in everyone else's once I knew to look for it.

We describe the system we would like to have. The legacy table nobody will let us touch, the deploy that takes forty minutes, the one endpoint that has to stay synchronous because a partner integration polls it - those get left out. Partly it is brevity. Mostly it is that writing them down feels like admitting something.

So you get advice for a codebase you do not have.

Now I write a CONSTRAINTS block and put the embarrassing things in it first:

`
CONSTRAINTS - all of these are fixed. Do not propose changing them.

• Postgres 12. Upgrading is not on the roadmap this year.

• The orders table has no created_at index and is 40M rows.

• Deploys are manual and take 40 minutes. No blue/green.

• One team of four. Nobody has run Kafka in production.

• The /invoice endpoint must stay synchronous - a partner polls it.

Given only the above, ...
`

"Do not propose changing them" is not optional. Without that line you get an answer that opens with "first, upgrade Postgres", which is not advice, it is a description of a different problem.

The answers change completely. Not tone - substance. The "obviously use a queue" recommendation becomes a two-phase approach with a synchronous escape hatch, because the constraint that the invoice path cannot move is now visible instead of implied.

The side effect I did not expect: writing the block is a useful exercise on its own. Half the time I get partway through listing constraints and realise which one is actually the problem. That has happened often enough that I now write it before I have decided whether I am even going to send the prompt.

The rule: if you would be slightly reluctant to say it out loud in an interview, it belongs in the prompt.