Stub
Why it matters
The risk is the stub that is never replaced. It is sharper when an AI coding agent writes the code. A model will readily produce something that looks finished while quietly returning a fixed value or skipping the hard part. The screen loads, no error appears and the work is reported as done. A feature that appears to work while doing nothing is worse than one that visibly fails, because nobody knows to fix it. A stub found by a customer is a very expensive discovery.
How to apply it
- Mark every stub clearly in the code, for example with a comment that says it is a placeholder, so it cannot pass for finished work.
- Log each stub as a ticket the moment it is created, so it stays visible until replaced.
- Never call a feature shipped just because it renders without an error. Run the real feature on the real surface.
- Ask the AI agent directly which parts are stubbed or faked, and have it list them.
- Treat a stub found late in review as a blocker for release, not a note for later.
What it is
When a developer builds a feature, some pieces are not ready. Rather than stop, a stub is put in their place. A stub of a payment function might always answer "success". A stub of a search page might show three fixed results. The surrounding code can then be written and tested without waiting.
Used on purpose, stubs are a normal and useful tool. They let a structure be sketched, a flow demonstrated or a part tested alone before every piece exists.
