At HBSGI, a healthcare company building an EDI claims processing platform, the specification I worked from for the ANSI 837/835/997 claims submission system exceeded 800 pages. That was not bureaucracy. Every page described a behavior, a constraint, or an edge case that would produce a wrong output — an incorrect claim, a rejected submission, a compliance failure — if a developer filled it in by assumption.
Eight hundred pages was what a correct specification looked like for that problem. The specification was long because the problem had real edge cases, and those edge cases had real consequences.
Most enterprise software specifications are not 800 pages. Most would fit in 20. The problem is not that requirements documents need to be longer. It is that enterprise software systems are complex enough that the gaps in a vague specification get filled somehow — and in AI-assisted development, they get filled by the AI’s training data rather than by the development team’s judgment.
sequenceDiagram participant B as Business Stakeholder participant S as Specification participant A as AI Coding Tool Note over B,S: Requirements gathering B->>S: Documents known requirements B-->>S: Leaves edge cases undefined Note over S,A: Development begins A->>S: Reads specification A-->>A: Encounters undefined behavior A->>A: Fills gap with training default Note over A: Code ships with hidden assumption B->>A: Discovers unexpected behavior A-->>B: Behavior was unspecified B->>S: Retroactive clarification Note over B,S: Rework cycle begins
The Gap-Filling Problem
Human developers, faced with a specification gap, typically ask. They surface the ambiguity to a product manager, a business analyst, or a stakeholder and get clarification before writing code. The gap becomes visible before it becomes embedded.
AI tools do not ask. They generate. A specification that says “the system should process customer orders efficiently” produces code that processes orders according to whatever pattern the AI’s training data suggests is appropriate for the context. Whether that pattern matches your specific data volumes, your existing infrastructure, or your organization’s integration constraints is not determined by the specification — it is determined by what the AI has seen before.
This creates a category of decision that is harder to audit than either an explicit design choice or a documented human judgment: the implicit AI default. The code works. It may perform well. The assumption embedded in it may be wrong in ways that only appear at scale, under edge cases, or at the integration points where the assumption meets a system with different expectations.
What the HBSGI Specification Demonstrates
The 800-page HIPAA EDI specification I worked from at HBSGI was not just long — it was precise about what mattered. The precision existed because the consequences of imprecision were concrete and traceable. A payment field formatted incorrectly would cause a rejection. A rejection had a defined remediation path. The remediation path had defined timing. The timing had financial consequences that the client could calculate.
The specification had to be that precise because the cost of assumption was that specific.
Enterprise software problems often have real edge cases with real consequences. The specification does not need to be 800 pages to capture them. But it does need to be more specific than “the system should handle X” — because the AI will handle X, and how it does so is not a detail that can be evaluated post-hoc without significant rework.
The Two Categories of Specification Gap
Specification gaps in enterprise software fall into two categories that AI handles differently.
Under-specified behavior. What the system should do in circumstances the requirements document didn’t address — edge cases, error conditions, boundary values. AI tools fill these gaps with defaults that reflect common solutions to similar problems. Catching these requires testing against the real edge cases, which requires knowing what the real edge cases are, which requires understanding the business domain well enough to anticipate them.
Under-specified constraints. What the system must NOT do — for performance, security, compliance, or integration reasons — that was never written down because the development team was assumed to know it. AI tools don’t know that your security team requires specific session token handling unless it’s specified. They don’t know about rate limits on a third-party API unless those constraints are documented. They don’t know which regulatory requirements apply to this specific data type unless the requirements call them out explicitly.
Both categories produce code that passes a surface review and fails a contextual one. The first category is typically caught in testing if the test coverage is adequate. The second category is often not caught until deployment — or until a security review, a compliance audit, or an integration failure surfaces it.
The Work Before the Prompt
The effective intervention is not a longer requirements document. It is specificity in the right places.
The categories most likely to produce AI-generated gaps in enterprise software:
Integration contracts. What does the system send to each external service, what does it receive, and what are the edge cases for each interaction? If the integration contract is not specified, the AI generates one based on typical usage patterns — which may differ from your specific external system’s behavior in production.
Security and compliance rules. What data is being handled, and what are the explicit constraints on storage, transmission, and access? If these are not specified, the AI generates code that appears compliant while potentially not meeting the specific requirements that apply to your domain and jurisdiction.
Architecture constraints. Which patterns does this system use, and which are explicitly off-limits? If the architecture is not specified, the AI generates what works in isolation — which may not fit the existing system’s structure or the team’s established conventions.
The work is the same work that good enterprise software development has always required: precise problem definition before implementation begins. The urgency is new. When AI fills in what’s missing, it does so at code-generation speed, and the result is embedded in the codebase before the gap becomes visible.
