After 7 months of Vibe Coding, I have come to certain conclusions. In this series of posts, I will talk about this experience, how it reshaped relations, expecations, learnings. AI is here to stay and vibe is just part of it, but we better wise up, otherwise we can lose the benefits of it.

In this first post, a blunt “Vibe manifesto” is presented as a prelude to the series of posts.

Preamble

We use AI. We’re not going back. But we’ve seen what happens when vibing becomes the only way to go — when speed eats clarity, when tools replace judgment, when nobody owns the mess. This is a manifesto for teams that want to move fast without losing the ability to move altogether.

The Principles

1. The AI is not an oracle.

It’s a tool with no context. We don’t validate human expertise by checking with this or that LLM. We don’t end debates with “but the LLM says so.” The AI hasn’t sat in our meetings, doesn’t know our users, and can’t see our codebase. We treat its output as input, not as verdict.

2. Someone must own every decision.

“The AI suggested it” is not a defense. If it’s in the code, someone chose to put it there. We name that person. We build the muscle of standing behind choices; even when we’re uncertain, even when we used AI to get there.

3. We name things before we build them.

No endpoint gets written until we can explain the concept it represents. What is this entity? How does it relate to others? What’s in scope, what’s not? If we can’t answer these questions, we’re not ready to build. The AI can help us explore, but we define the domain.

4. Demos are not estimates.

The fact that someone built a sample app in an afternoon tells us nothing about production timelines. We don’t let the speed of prototypes set expectations for real systems. We estimate based on what we’re actually building, including the parts that aren’t visible in a demo (infrastructure, security, testing, DevExp, etc). In the end of the day, the demo is just a demo and building serious products demand serious trade-offs.

5. Clarity is not overhead. It’s the product.

Well-defined concepts, bounded contexts, documented decisions; these aren’t “old school” or “waterfall.” They’re the only reason we’ll be able to iterate six months from now. We pay the cost of clarity upfront because the cost of confusion compounds. Clarity starts with product thinking, product people, and only then it ends in code.

6. Business people must know what they’re asking for.

If requirements are vibed, the implementation will be vibed. We don’t accept “just make it work” as a spec. We push back; kindly, but firmly; until we have definitions we can build against. Pretty much as if we were to implement it by hand line-by-line. The alternative is building something nobody can explain or extend. The business dies.

7. Speed now, speed later.

We measure velocity in months, not days. A team that ships fast today but drowns in bugs next quarter didn’t actually move fast. We optimize for sustainable pace. We know that the fastest teams are the ones that can still ship cleanly a year in. Vibe speed is not impact. It’s a mirage.

8. The AI amplifies what’s already there.

Clear thinking becomes clearer. Confusion becomes faster confusion. We don’t use AI to bypass the hard work, we use it to accelerate the problem space exploration, bounce ideas on hyphothesis, and save time with boilerplate code. If we don’t know what we’re doing, AI will just make us go faster to the wrong place.

9. Keep spec quality bar high.

Features don’t enter development until concepts are defined. Not exhaustive specs, but at least clear enough that an engineer could explain the entities to a new hire without having to ask AI how that subsystem works. This is the gate, enforced by engineering.

10. Extensibility always on.

Before launching a vibed feature, ask: “If we need to add X in three months, what would that take?” If the answer is “rewrite,” you’re not done. This forces a conversation about foundations.

Closing

This isn’t about slowing down. It’s about staying fast—next month, next quarter, next year. This is about the good old software engineering practices as safe-guards for the AI era. Vibe if you want. But vibe with care.

This series of posts express my sole opinion and not the opinion of any employer.