Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Constraint

Pattern

A reusable solution you can apply to your work.

Understand This First

  • Application – constraints bound the application’s design space.

Context

This is a strategic pattern. Every Application operates within limits that aren’t up for negotiation. Time, money, platform, regulation, performance thresholds, compatibility requirements: these are constraints. Unlike requirements, which describe what the system must do, constraints describe what the design must respect.

Constraints shape the solution space before a single line of code is written. In agentic coding workflows, they are especially important to state up front, because an AI agent will happily generate a solution that violates any constraint you forget to mention.

Problem

How do you make the non-negotiable boundaries of a project visible so that every design decision respects them?

Constraints are easy to overlook because they often feel obvious to the person who knows about them. The developer who knows the app must run on iOS doesn’t think to mention it. The product manager who knows the launch date is fixed doesn’t write it down. The result is wasted work: elegant solutions that can’t ship because they violate a boundary nobody made explicit.

Forces

  • Constraints limit freedom, which feels restrictive, but ignoring them leads to solutions that can’t be used.
  • Some constraints are hard (regulatory compliance, physics) and some are soft (budget, timeline), but both shape the design.
  • Too many constraints make the problem unsolvable. Too few leave the solution space dangerously open.
  • Constraints interact: a tight deadline combined with a small team rules out approaches that either constraint alone would allow.

Solution

Identify and document constraints early. Separate them from requirements and wishlist items. For each constraint, name its source (regulation, budget, existing infrastructure, user expectations) and whether it is truly fixed or potentially negotiable.

Common categories of constraint include:

  • Time — deadlines, release windows, development velocity
  • Budget — money, team size, infrastructure costs
  • Platform — target OS, browser support, hardware limitations
  • Regulation — privacy laws, accessibility standards, industry rules
  • Compatibility — existing APIs, data formats, legacy systems
  • Performance — latency ceilings, throughput floors, resource limits

When working with an AI agent, list your constraints explicitly in the project context. An agent that knows “this must work offline” or “we can’t use any GPL-licensed dependencies” will generate fundamentally different solutions than one operating without those boundaries.

Warning

Unstated constraints are invisible constraints. An AI agent has no way to infer that your company prohibits certain open-source licenses or that your deployment target lacks network access. If you don’t say it, it doesn’t exist in the agent’s world.

How It Plays Out

A developer asks an agent to build a data visualization dashboard. The agent produces a beautiful React application that calls a cloud API for chart rendering. But the project’s constraint — never stated — is that the dashboard must run in an air-gapped environment with no internet access. The entire approach must be scrapped.

Had the developer listed “must run offline with no external network calls” as a constraint, the agent would have chosen a client-side charting library from the start. The constraint didn’t make the problem harder. It made the solution space smaller and clearer.

Example Prompt

“This dashboard must run in an air-gapped environment with no internet access. Use a client-side charting library that works entirely offline. No CDN links, no external API calls.”

Consequences

Explicit constraints prevent wasted work and narrow the design space to viable solutions. They also support better tradeoff decisions, because you can see which options are actually available before weighing their merits.

The cost is the discipline of identifying constraints before you feel ready. You may also discover that your constraints contradict each other: the budget is too small for the timeline, or the platform can’t support the required performance. Discovering this early is painful but far cheaper than discovering it after building.

  • Depends on: Application — constraints bound the application’s design space.
  • Refines: Requirement — some requirements are really constraints in disguise.
  • Enables: Tradeoff — constraints determine which tradeoffs are available.
  • Contrasts with: Judgment — constraints are fixed; judgment operates in the space they leave open.
  • Enables: Invariant — invariants are often derived from constraints.