If there is an organizational mandate to vibecode, we should treat that as a real constraint and engineer around it. As engineers we must learn to read the room and deliver. It does not make sense to force reliability culture onto a startup that needs speed, PMF, users, and market timing. Similarly you cannot bring startup-level tolerance for chaos onto systems where correctness and reliability are the product.
Using LLMs and vibecoding are very different; latter means "assume code does not exists, there is no such thing as code". This does not have to be true while using LLMs mindfully.
With vibecoding, we tend to offload our understanding of the codebase to a language model with a small, lossy working memory to gain velocity. That may be a good tradeoff in some contexts. If you are a startup, worrying about understanding every part of the codebase is probably the last thing on your list. The code might not exist in six months.
But that tradeoff does not apply everywhere.
For infrastructure like databases, kernels, schedulers, load balancers, or payment systems, you cannot afford to NOT know what the code is doing. Code is not cheap or disposable. It encodes years of operational knowledge, failure modes, and edge cases. If the team stops understanding it, the system becomes unsafe even though you keep padding numbers to your test coverage.
As we move on I think the engineering split may shift from domains (frontend, backend, mobile, systems) toward reliability budgets. Can this product afford one million lines of generated code in a week? Can this system afford the team NOT reading every line of a nondeterministic, hallucination-prone model's output? And more importantly: can this team afford the operational cost of debugging code nobody fully understood when it landed?