Premature Success

Also known as

Premature success, the agentic era's "works on my machine".

Context

The unit tests pass, curl returns 200, the build succeeds. The agent declares the feature done and takes the next task.

Problem

Yet nobody has run the user scenario end to end. Checks of individual functions and of the endpoint can miss a bug in how data passes between the interface and the server.

Why people do it

• Passing tests look like sufficient proof, even though they cover only the cases they were given.
• Setting up the environment and an end-to-end scenario takes extra time.
• The agent extends the success of individual checks to the whole feature.
• The team treats passing tests as the definition of done without checking whether the tests themselves are complete.

Consequences

• ➖ A user or a demo is the first to hit the integration failure.
• ➖ The status in the feature list does not match the product's behavior.
• ➖ You have to re-check the agent's reports by hand.
• ➖ Several missed integration bugs make later diagnosis harder.

Signs

• The report has no end-to-end check result.
• "Verified" means "the unit tests passed".
• Nobody has opened the application since the implementation.
• The feature is shown for the first time at the demo.

A better way

Include the user scenario in the feedback loop. The agent should walk through it via the real interface and save the result. In the feature list, tie the status to this check. Unit tests and TDD continue to protect individual pieces of behavior.

Example

Before:

The feature is done, all 14 tests pass.

After:

Run the schedule end to end: create it through the UI, wait for the report email, and attach screenshots

Related patterns and anti-patterns

• Feedback Loop ties readiness to evidence from verification.
• Feature List stores the statuses of verified scenarios.
• TDD with an Agent helps verify individual behavior before implementation.
• Vibe Coding describes a similar loss of control when accepting unverified code.