Vibe coding

Andrej Karpathy coined the term in a post on X on 2 February 2025. He described a way of working where you talk to an AI coding tool, accept its suggestions, run the result and paste errors back in, and stop caring much about the code itself. He framed it as fine for throwaway weekend projects. The phrase spread fast, and Collins Dictionary named it its Word of the Year for 2025.

Today “vibe coding” is used more loosely for any product built mostly by prompting tools such as Cursor, Lovable, Bolt, v0 or Replit. The common thread is that working output arrives quickly and nobody has fully read or designed what sits underneath.

Why it matters for a SaaS product

Vibe coding lowers the cost of a first version close to zero, which is good for founders testing an idea. The catch shows up when real users arrive. AI-built prototypes usually cover the happy path, the demo flow, and skip what a product needs: empty, loading and error states, permissions, validation, auth and consistent UI. Each screen is generated on its own, so styles and components drift. The result is technical debt that nobody chose on purpose, and it slows every feature after it.

How DesignMe handles it

We do this as AI MVP cleanup, and we work with products built in Cursor, Lovable, Bolt, v0, Replit, Claude, ChatGPT or a mix of AI and hand-written code. We do not rewrite by default. Week one is an audit of the product, flows, frontend, backend logic and integrations, ending in a risk list and cleanup priorities. Then we map the core flows and missing states, bring the UI back into one component system, fill backend gaps such as auth, validation and error handling, and finish with QA and handoff notes. Some parts are kept, some refactored, and some rebuilt properly in React, Next.js and Tailwind.

Example

Say a founder builds a scheduling app in Lovable over two weekends and signs ten pilot customers. It demos well, but there is no way to recover a deleted booking, admins and users see the same screens, and three different button styles exist. A review keeps the data model, rebuilds the booking flow with proper states and permissions, and replaces the generated styles with one set of components.

Common mistakes

• Shipping the demo. A prototype that only works on the happy path is not ready for paying users.
• Rewriting everything. Much AI-generated code is usable. Audit first, then decide what to keep.
• No one owns the code. If nobody on the team can explain how auth works, that is the first fix.
• Prompting for more features. Adding screens on a shaky base makes the cleanup bigger, not smaller.