Addy Osmani: Constraints are the key to shipping agent code

Addy Osmani says code quality in the agent era hinges less on what humans can review and more on the constraints around the system. His proposed “exit gate” approach layers checks for security, performance, cost, and more before anything ships.

Addy Osmani: Constraints are the key to shipping agent code

TL;DR

  • Quality via constraints: Agent-generated code needs harness/environment gates, not only human review of output
  • “Exit gate” model: Only outputs clearing every gate reach SHIP (“production software, good enough to ship”)
  • Constraint categories: correctness, security, performance, accessibility, maintainability, cost efficiency, comprehensibility
  • Example checks: unit/property/mutation; SAST/deps/secrets; perf budgets/load; token/compute budgets
  • Performance constraints: Metrics and budgets flagged as most effective at catching bad agent code
  • Deterministic vs judgment: Blend enforced gates with non-deterministic review; open question which gates must be hard enforced

Addy Osmani argued in a thread on X that software quality for agent-generated code increasingly depends on the “constraints” placed around the system, rather than only on the code an engineer can review by hand. In his telling, once agents can produce more code than people can reasonably read, quality checks need to live in the harness, environment and operating system surrounding the agent.

Osmani’s post paired that argument with a dark diagram titled “Set the constraints around your agents.” The graphic places an “AGENT” in the center and routes output toward a green “SHIP” box labeled “production software, good enough to ship,” with an “exit gate” in between. Around the agent, the ring of checks spans “correctness,” “security,” “performance,” “accessibility,” “maintainability,” “cost efficiency” and “comprehensibility,” with notes such as “unit, property, mutation,” “SAST, deps, secrets,” “perf budget, load,” and “token / compute budget.” The return message is blunt: “only output that clears every gate” should reach production.

In the thread, Osmani highlighted “performance (metrics, budgets)” as the constraint that has caught the most bad agent code for him. He also pointed to a gap in many harnesses, which he said tend to optimize basic correctness while not going far enough on UX and performance. Later, he added that constraints give him confidence that changes meet part of his bar, while more complex or sensitive sections still get manual review.

The discussion around the post quickly turned to where deterministic checks end and human judgment begins. One participant asked whether a single constraint pattern can really scale across teams, given the experience needed to write useful checks. Another pointed to maintainability as a stubborn edge case, noting that correctness, security and speed can be tested, while the wrong abstraction is harder to fail mechanically.

Osmani also responded to a note from Chris Williams, who described “blending non-deterministic and deterministic gates.” Osmani agreed, writing that the “skills carry the non-deterministic half” while the model applies judgment in context. He added that the open question is which gates deserve hard enforcement and which are better left to judgment.

A second graphic attached to the post carried the line “First do it, then do it right, then do it better,” reinforcing the same idea: quick generation is not the endpoint, and agent output only becomes shippable after it clears a set of checks that can resist, in Osmani’s words, “bad work before it becomes somebody elses problem.”

Source: Addy Osmani on X

Continue the conversation on Slack

Did this article spark your interest? Join our community of experts and enthusiasts to dive deeper, ask questions, and share your ideas.

Join our community