Escalate upwards, challenge the policy, cite this as an example. Also cite things like https://arxiv.org/abs/2511.04427 : "transient increase in project-level development velocity, along with a substantial and persistent increase in static analysis warnings and code complexity".

If the policy doesn't change, find a new company.

Now, all that said: it would also be a good idea to have better testing infrastructure that actually tests the services in concert and not just individually. That testing infrastructure will be useful for the humans who take over from the vibe coding and start cleaning up the mess.

Some todos that come to my mind:

- Review more thoroughly.

- 'Vibe code' some unit tests

- Document and communicate the things that are in team members heads that should be openly shared

My strategy is to have a central spec, typically protobuf or openapi, and every service has a make target to generate code from that. The dependencies stop being in someone's head and start being in the spec. I had this pattern long before coding agents because it helps human devs, too.

The benefit is that my CI process can deterministically check if a) someone changed the spec or b) the service code doesn't compile or lint when built against the freshly generated code. This is a hard, enforced gate. If it fails, either it needs manual review or it gets sent back to the coding agent to fix automatically, so humans don't waste time looking at trivial issues.

The agents can move as fast as they want within a single service. The spec gate catches cross-service breakage before it deploys.