Why Constraints in AI Development Matter

An AI agent is very good at doing a well-defined thing. It is much less reliable at deciding what the thing should be.

Most of my work with AI is about closing that gap. I decide the architecture, the facts, and the checks first, so the agent has as few choices left as possible.

Short answer: every open decision in a task is a place where an AI agent has to guess. Constraints turn guesses into lookups, and checks catch the guesses that remain. Predictable output comes from the system around the agent, not from a cleverer prompt.

What are constraints in AI development?

Constraints are everything that decides an answer before the agent has to: the architecture, the data model, a source of truth for facts, fixed function contracts, banned words and stop rules, examples to copy, and tests or validators that define done.

I call the practice constrained AI development. A human owns the decisions and the checks, and the agent owns the typing inside them.

It is not a single prompt. It is a set of files that live next to the work and get stricter every time the output misses.

Why does a vague task make AI output less reliable?

A vague task hands the agent dozens of decisions: what to name things, how to handle errors, where logic goes, what “done” means, and which facts are safe to state. The agent fills each gap with the most plausible default, and plausible is not the same as what you meant.

The errors also compound. One wrong early choice shapes every choice after it.

A simple way to see the compounding

This is arithmetic, not a measurement of any model. If each independent decision has a 95% chance of matching what you wanted, the chance that all of them match drops fast:

Open decisions	Chance every one matches
1	95%
5	77%
10	60%
25	28%
50	8%

The fix is not a smarter guesser. It is fewer guesses.

Is that the same thing as hallucination?

Mostly it is not. The common failure from a vague task is a reasonable default that does not match your intent, such as a new error style or a fourth way to format a date.

Invented facts show up when the task needs a fact nobody supplied. The agent fills the slot with something that sounds right, and on a resume or a data sheet that is the worst possible outcome.

What does drift look like in practice?

My resume kit keeps a corrections log, and it reads like a catalog of drift. A quantifier nobody said (“every”, “daily”), a one-time task written as ongoing, two true facts stitched into a new false one, and a number moved to a scope it never belonged to.

None of those were wild inventions. Each was a small, confident guess where a rule did not exist yet.

What has to exist before an AI agent touches the work?

The foundation has to exist first. I plan the stack, the idea, and the architecture well before I reach for an agent, because I need the walls standing before I can control what gets built inside them.

In practice that means a data model, the main contracts, the folder layout, and a written definition of a good result. If I cannot describe the outcome and how I will check it, the agent is not ready to start.

The agent can implement. The design decisions stay with me, along with the review of every change before it is committed.

How does the idea, assumptions, iteration, evaluation loop work?

Every system I build with AI goes around the same loop. I start with an idea, write down the assumptions it rests on, let the agent iterate inside fixed limits, and evaluate the output against a written standard. Each miss in evaluation becomes a new rule, and the loop starts again with a tighter box.

Step 1: Start with the idea and the outcome

Write what the system is for and what a good result looks like, in plain words. For the public data research agent the outcome was a verified list where a blank beats a guess.

Step 2: Write down the assumptions

List what you believe about the sources, the data, and the user. Assumptions written down can be checked. Assumptions left in your head get guessed by the agent instead.

Step 3: Iterate inside the box

Let the agent work within the architecture, the contracts, and the sources of truth. Small tasks keep each diff small enough to review honestly.

Step 4: Evaluate, then turn the miss into a rule

Check the output against the standard with tests, validators, or a line-by-line read. When something misses, do not just fix the output. Add a dated rule, a banned item, or a check so the same miss cannot happen again.

What goes inside the box?

Five kinds of constraint do most of the work. Each one removes a category of decision from the agent.

Sources of truth

One file wins when facts disagree. In the resume kit that is a vetted experience file with a metrics ledger, where every number carries its source and its exact qualifier.

Fixed contracts

On RE/AMP, utilities that touch a database or service take a client and arguments and return a result with data and error. The agent never decides whether to throw or return null.

Banned lists and stop rules

A do-not-claim list, banned words, and hard stops such as “a captcha means stop and tell the human.” Stop rules matter because an agent will otherwise try to work around a roadblock.

Validators and tests

Tests and scripts define done. The content on this site passes a validator that checks title lengths, heading order, banned words, dashes, privacy, and internal links before I review it.

Examples to copy

The agent copies a vetted pattern from the same project instead of inventing one. A new data source file starts as a copy of the most complete one, with the same headings.

Where has this method produced results?

I have used the same loop on four very different systems: a production SaaS codebase, a resume kit, a public data research agent, and the content pipeline behind this site.

Production code on RE/AMP

I lead development on RE/AMP, a multi-tenant SaaS for real estate transactions, and started its codebase in March 2024. Tests are written before generated code, contracts are fixed, and the agent may not introduce a new pattern without stopping to ask.

At one staging checkpoint the suite stood at 726 passing tests across 42 suites. I wrote the method up in Why I Write Tests Before AI Writes Code.

A resume kit that will not invent claims

The AI resume kit turns a person’s confirmed facts into tailored resumes and cover letters. Its rules came from real misses, like a rejection for missing an email instruction in a posting and a fake posting that looked real.

It cannot add a skill, a number, or a result that is not already a verified fact from the person’s own work history. The AI tailors the wording, and the facts stay fixed.

A public data research agent

The public data research agent collects new public records at the source, matches each one to a property, and delivers a verified list with the source of every value. It began as a short prompt for one source and became a skill with a fixed workflow, pluggable source files, and five gates before a source goes live.

The content pipeline behind this site

Every page here started as a markdown file mapped to a Django model, written against length and heading rules, and checked by a validator script. The same script builds the JSON-LD on this page, including each Question and Answer. The full setup is in How This Site’s Content Is Built and Validated.

How do you know a constraint is working?

You know a constraint is working when the same miss stops coming back. I track that in three places: a corrections log of what drifted, test or validator results on every change, and repeat runs that should return the same result.

The strongest check is a fresh session. If a new agent session, given only the files, cannot repeat yesterday’s work, the rules are not finished yet.

When do constraints get in the way?

Constraints get in the way when they are wrong or when the problem is still unknown. A wrong rule produces consistently wrong output, which is why evaluation never stops.

Early exploration also needs room. I prototype loosely to learn the problem, then write the rules once I know what good looks like.

Frequently asked questions

Is constrained AI development just prompt engineering?

No. A prompt is one message. These constraints are files that live with the work: sources of truth, contracts, tests, validators, and logs, and they change every time an evaluation finds a miss.

Does constraining an AI agent slow you down?

It costs time up front and saves it later. Most of the cost is writing the rules once, and most of the savings is not reviewing and undoing the same drift again and again.

Which AI tools do you use?

I work in Claude Code and in Zed with AI assistance, and I also use Claude, ChatGPT, and Gemini. The method does not depend on the tool, because the constraints live in the project files.

Can these constraints be shared with other people?

Yes, if the method is kept apart from the facts. I explain how in How to Write AI Skills Other People Can Reuse.

Can you help my team set this up?

Yes. I build custom applications and data pipelines this way, and I can set up the same structure for an existing project. See custom web applications and data pipelines and automation, or get in touch.

About the author

I am Joshua Hayes, a full-stack developer in Fort Worth, Texas. I lead development on RE/AMP, where I am the largest contributor with 2,500+ of its 5,000+ commits, and I have worked in SEO since 2015.

I hold the Google Analytics Certification and the Google Ads Search Certification. My background is on the about page, and my work history is on the resume.