Serguey Asael Shinder: Code that must not ship should not depend on someone remembering to remove it
Every project I have worked on had at least one of these: a page that dumps internal state, an endpoint that resets a user's data, a view that lists every component on one screen so a designer can check spacing. They are useful, they are written in a hurry, and the plan for each is the same — "we'll take it out before release".
That plan is a memory, and memory is the weakest control we have. It fails quietly. Nobody gets an error when the debug page ships; it just sits there until a scanner, a curious user or a penetration tester finds it. And the person who wrote it has often moved on by then.
What works better is to make "development only" a property the code carries, and let the build or the runtime act on it. Vaadin's new @Route(developmentOnly = true), released this week in Flow 25.3.4, is a clean example of the idea: the route is simply not registered in production mode, and its frontend dependencies stay out of the production bundle. Nobody has to remember anything at release time; the decision was made when the view was written, next to the code it concerns.

The same principle shows up in many forms:
- Profiles and build-time exclusion. A Spring bean that exists only under a
devprofile, a Maven module that is never part of the production artifact. The production build cannot include what it was never given. - A test that fails if it ships. If something must never reach production, write a check that runs against the production artifact and fails when the thing is present. It is crude and it works.
- Defaults that are safe when forgotten. If a flag enables a dangerous tool, its absence must mean "off". A forgotten setting should leave you in the safe state, not the convenient one.
None of this replaces review. It changes what review has to catch. "Did anyone remember to delete the debug page?" is a question a reviewer misses at five in the evening before a release. "Is this new view marked development-only?" is a question that can be asked once, when the view is added, and then answered by the machine every time after.
I find this a useful test for any piece of temporary code: if removing it before release depends on a person remembering, it is not temporary — it is permanent code with a good intention attached.