Constraints Before Code Generation

Reliable AI code starts by limiting what the agent is allowed to assume.

A common response to unreliable AI-generated code is to add more tests, linters, reviews and CI gates. All of these are necessary, but they address only the later part of the problem.

A good harness should also reduce what the agent is free to guess. The domain model establishes the language, API contracts define accepted and rejected cases, state transitions describe legal behavior, and database constraints protect important invariants. Authorization, retries, idempotency and partial failures also need explicit treatment rather than being discovered during generation.

Once this shape exists, AI can be useful for drafting adapters, fixtures, boilerplate and routine implementation. Review becomes more focused because we are no longer asking whether the result looks generally plausible. We are checking whether it satisfies decisions that were made deliberately.

The real danger is plausible code that quietly introduces assumptions nobody intended. When tests are added only afterwards, some of those assumptions may already have spread across the implementation.

For me, the harness is therefore not only a safety net around generated code. It is part of the design process that limits the space in which the agent is allowed to operate.