One of the most frustrating AI coding failures is when the model can prove that something works, but it has proved the wrong thing.
Imagine I ask an AI agent to build a feature that uploads large videos to YouTube. The requirement is not vague. I want it to handle files in the two to four gigabyte range. However, if I pass that directly into a coding agent, there is a very real chance it will build a test using a 4.5MB sample file, pass the test, and confidently tell me the upload works.
Technically, something uploaded. Practically, the requirement was not proven.
That gap is exactly why I built Feature Design Pre-flight.
In a previous article, Clarify Before Build handled the first stage by turning vague requirements into a shared contract. Feature Design Pre-flight takes that contract and turns it into concrete engineering requirements that an AI agent can actually implement and prove.
The Problem Is Shallow Proof
Just like humans, large language models generally take the easiest path to a working-looking answer unless the workflow forces them to do otherwise. That is not because they are lazy. It is because the solution requirements don’t define the outcome effectively.
If I say upload a file, the model can choose a small file. If I say make the UI robust, it can render something that looks fine on the default screen size. If I say support authentication, it can wire a happy path without proving role boundaries, expired sessions, or permission failures. If I say production ready, it can assume that passing one narrow test is enough.
What Feature Design Preflight does is takes these statements and defines clear passing and failing outcomes.
Requirements Need Numbers And Outcomes
Feature Design Pre-flight forces requirements to become specific enough to test. If the requirement is a four gigabyte upload, the skill does not allow a 4.5MB test. It ensures that whatever test is used is auditably proven to be effective.
Each test traces back to the thing it proves. For instance, if a feature has five important requirements, there should be evidence for each one, and this work should be documented, proven, and stand up to an audit.
The Skill Maps The Impact Before Code
Another major failure mode is local implementation. The AI agent changes one file, makes the immediate test pass, and misses the rest of the system.
Feature Design Pre-flight is meant to trace the impact before implementation starts. If a feature touches authentication, it identifies the routes, pages, middleware, data stores, roles, and tests that depend on that authentication model. If a feature changes upload behavior, it captures file size limits, storage, background jobs, retries, timeouts, cleanup, error states, user messages, and observability.
This approach is critical as your codebase increases. New features affect old tests, stale docs, assumptions in another module, or forgotten workflows.
The skill does not magically remove that complexity, but it makes the model look for it before writing code. That alone changes the quality of the output.
Test Design Comes Before Implementation
The bigger idea here is applying test-driven development to the entire feature workflow.
In a perfect world, before a single line of code is written, you should have a proof plan that considers: