@[sibasispadhi] Partly, yes. The earlier you catch it, the cheaper it is, so push as much as you can into those phases.
Unit tests catch logic errors in seconds. Integration tests catch broken contracts between services in minutes. Both should run on every change.
But they have a limit with AI-generated code. When the same AI writes the code and the tests, the tests often confirm the code's own assumptions. Everything passes, and it's still wrong. The failures I worry about most are the ones tests rarely cover: odd production data, real load, slow dependencies, and config differences between environments.
A few things move more of that earlier:
Write tests from the spec, not from the code. A human should own the test intent, even if AI helps write them.
Property-based and contract tests. They probe edge cases nobody thought to list.
Load tests against production-like data in staging. This catches the "works on my fixtures" problem.
Mutation testing. It shows whether your tests would notice if the code were wrong.
So I'd think of it as layers, each with a different speed: seconds for unit tests, minutes for integration, hours for staging, and a canary release plus telemetry for whatever slips through. Tests shrink the window, and observability covers what they miss.
