2026-09-10
Software Orchestrator Series · Part 4 of 6
Requirements Are Engineering: Directing AI Without Losing the Fundamentals
The skill that separates useful AI work from confident guesswork is specifying what must be true. That is requirements engineering, not prompting magic.
Editor's Note: This post is part of The Software Orchestrator Framework. For the foundational principles and vocabulary that make this method possible, start with Phase 1: The Foundation.
The useful frame for "prompting" is not conversation craft. It is requirements engineering. When you ask a model to produce work, what you are really doing is specifying what must be true, what must not happen, and how you will know the result is correct. Done well, that is a professional skill. Done casually, it produces confident, plausible output that fails where it matters.
What Must Be True, What Must Not Happen
Every useful request carries two kinds of constraints:
- Symbolic constraints — hard rules the output must obey. "Never commit secrets." "This function must not raise on empty input." "Follow the existing module boundaries."
- Context — facts the model needs to draft correctly. "The service is in TypeScript; migrations live under
migrations/; errors are returned, not thrown."
The failure modes come from leaving either out. Leave out the rules and the output is unconstrained. Leave out the context and it is ungrounded — perfectly formatted for a system that does not exist.
Weak Versus Precise
| Weak | Precise |
|---|---|
| "Write a backup script" | "A backup script that: (1) checks disk space first, (2) verifies the backup before deleting anything, (3) exits non-zero and alerts on any failure, (4) is safe to re-run" |
| "Improve this service" | "Refactor this service so calls to the customer API go through the existing client module, keep the public interface unchanged, and all existing tests still pass" |
| "Add validation" | "Reject payloads that are missing required fields or exceed 10 KB, returning the documented error shape" |
The pattern is the same each time: intent, constraints, and a testable definition of done.
Codify It Where It Lasts
A requirements discipline only pays off if it is not rebuilt in every session. Teams that do this well codify the durable parts in the repository:
- The rules that never change — non-negotiable constraints for every change.
- The context — architecture, conventions, and state that any contributor needs.
- The automation — the gates that verify output regardless of who or what produced it.
Any assistant can read those; none of them owns them. The repository is where the structure lives.
Keep the Engineer in the Loop
No matter how precise the requirements, the output still needs a senior pair of eyes and real gates. Requirements reduce the search space; they do not remove the need for verification. Treat the result like a pull request from a capable junior: review the logic, check the security, and only approve what you understand and can defend.
Next in the Series
Requirements are the communication discipline. The structures around them — architecture before code, and quality enforced by gates — are the next two posts in the series.