Vibe coding v engineering

There’s a phrase bouncing around tech Twitter right now that makes me twitch every time I see it: vibe coding.

The idea is seductive. Fire up Cursor or Copilot, describe what you want in plain English, and let the machine write your app while you sip an oat milk flat white. Ship it by Friday. Raise by Monday. Post the thread by Wednesday.

And look - I get it. I’ve been there. I’m a designer by trade, not a software engineer. I co-founded Reboxed, a refurbished phone company, and I’ve spent years thinking about products, brands, and user experiences rather than database schemas. So when AI-assisted coding tools started getting genuinely good, I was one of the first people reaching for them. I’m not anti-AI. I’m not some purist gatekeeper telling you to learn C++ before you’re allowed to have an opinion.

But I did just refactor our entire technology stack - backend, middleware, back office, API, the lot - and I can tell you with absolute certainty: the vibes were not what got us there.

The mess we started with

Here’s the thing nobody talks about when they’re showing off their AI-built prototypes. Real businesses aren’t greenfield playgrounds. They’re years of accumulated decisions, workarounds, duct tape, and “we’ll fix that later” moments stacked on top of each other.

Reboxed sells refurbished phones. Sounds simple. It’s not. Behind every handset we sell sits a chain of operations that would make your head spin - grading, diagnostics, pricing, inventory management, fulfilment, returns, warranty tracking, customer service workflows, marketplace integrations. When I joined as co-founder and CPO, we were running all of this on a patchwork of local tools stitched together with prayer and good intentions. A bit of this plugged into a bit of that. Spreadsheets doing jobs that databases should have been doing. Manual processes where automation should have lived.

It worked. Until it didn’t. And when you’re scaling a re-commerce business - where every single unit is unique, with its own condition, its own history, its own margin - “it kind of works” stops being acceptable pretty fast.

So we made the call. We were going to rebuild. Not a facelift. Not a migration. A ground-up rethink of how our entire operation ran.

The bit everyone wants to skip

Here’s where the vibe coders lose me. Because the first thing we did wasn’t open a code editor. It wasn’t fire up an AI tool. It wasn’t even think about the frontend.

We started with the backend. The architecture. The boring stuff.

We sat down and mapped out every single process in our operation. How a phone enters our system. How it gets graded. How pricing is determined. How inventory flows. How orders are fulfilled. How returns come back. How data moves between teams. Every edge case, every exception, every “oh yeah, and sometimes we also have to do this” moment.

That’s not vibes. That’s work. Unglamorous, methodical, sometimes painfully tedious work. But it’s the work that separates a product that looks good in a demo from a product that actually runs a business.

We designed our own API. Built our own middleware layer. Created our own back office system. Not because we wanted to be clever - because we needed something that actually reflected how our operation works, not how some off-the-shelf tool assumed it should work.

And this is the point I keep coming back to: understanding your operation is the architecture. You can’t abstract that away. You can’t prompt-engineer your way to a deep understanding of how your business actually runs. That knowledge lives in conversations with your ops team, in watching someone manually process a return for the fortieth time that day, in the frustration of a customer service agent who can’t find the information they need because it’s trapped in three different systems.

No amount of AI tooling replaces that. Not yet. Probably not ever.

Where AI actually earned its keep

Now - before the vibe coding crowd writes me off as a luddite - let me be clear. AI was absolutely instrumental in what we built. It just wasn’t the starting point. It was the accelerator.

Once we had the architecture nailed down, once we understood the data models and the process flows and the integration points, we used AI to build out prototypes at a pace that would have been unthinkable two years ago. We moved fast. Genuinely fast. But we moved fast in the right direction, because we’d done the thinking first.

There’s a massive difference between speed and velocity. Speed is how fast you’re moving. Velocity is how fast you’re moving toward the right destination. Vibe coding gives you speed. Engineering thinking gives you velocity.

We started with Retool for our internal tooling - built the UI, prototyped the key workflows, tested integrations with our systems. Retool was brilliant for this because it let us put working interfaces in front of our team quickly. Not pixel-perfect, not brand-beautiful, but functional. Usable. Testable. We could watch real people use real tools to do real work and learn from it.

That feedback loop was everything. We weren’t guessing what the back office should look like based on assumptions. We were iterating based on observed behaviour. Ops team says this screen needs three fewer clicks? Done. Customer service says they need the order history and the device history on the same view? Done. Warehouse says the grading flow doesn’t match how they actually move through a device? Redesigned by end of day.

Then, once we’d validated the workflows in Retool and truly understood what we were building, we built it all out properly. Our own platform. Our own codebase. Our own system, designed from the ground up to do exactly what Reboxed needs it to do.

AI helped us write code faster. It helped us scaffold components, debug tricky integrations, generate boilerplate, and explore approaches we might not have considered. But at no point was the AI driving. It was in the passenger seat, being incredibly useful, while someone who understood the business had their hands on the wheel.

The prototype trap

This is the part that worries me about the vibe coding narrative. It conflates prototyping with building. And those are fundamentally different activities.

A prototype is a question. It asks: “Could this work? Does this feel right? Is this the right direction?” Prototypes are meant to be thrown away. They’re disposable by design. And AI is absolutely phenomenal at helping you create prototypes. You can go from idea to clickable thing in hours. That’s genuinely transformative.

But a product - a real product that handles real money, real customer data, real operational complexity - is an answer. It’s a commitment. It has to handle edge cases, failure states, scale, security, performance, maintainability. It has to work when your ops team is processing a thousand devices on a Monday morning and the API is getting hammered and someone’s trying to return a phone that was bought six months ago under a promotion that no longer exists.

Vibes don’t handle that. Architecture does.

And the danger of vibe coding isn’t that it produces bad prototypes. The prototypes are often great. The danger is that founders fall in love with the prototype and try to scale it. They skip the boring middle part - the architecture, the data modelling, the operational understanding - and end up with a system that looks finished but is fundamentally fragile.

I’ve seen it happen. Beautiful frontends sitting on top of spaghetti backends. Impressive demos that fall apart the moment real users do something unexpected. Products that work perfectly for the happy path and catastrophically for everything else.

What I’d actually tell a founder

If you’re building a design-led business - which is what I care about, what I spend most of my time thinking about - here’s the sequence that actually works:

Understand first. Before you write a line of code, before you open any tool, understand the problem space deeply. Talk to users. Talk to your ops team. Map the processes. Find the pain points. This is design work, by the way. Real design work. Not pushing pixels - understanding systems and people.

Architect second. Design the system that reflects your understanding. Data models, API structure, integration points, process flows. This doesn’t have to be perfect - it has to be intentional. You need to make deliberate decisions about how data flows through your business, not let it emerge accidentally from whatever the AI suggested.

Prototype third. Now bring in the AI tools. Use Retool or Cursor or whatever you like to build fast, test fast, learn fast. Put things in front of real users. Get feedback. Iterate. This is where vibe coding shines - in the discovery phase, when you’re still learning what the right answer looks like.

Build fourth. Take everything you’ve learned and build it properly. This is where engineering discipline matters. Clean code, sensible abstractions, proper error handling, documentation, testing. The unsexy stuff that keeps your platform running at 3am when you’re asleep and a customer in another timezone is trying to buy a phone.

The founders who skip steps one and two and jump straight to three and four - or worse, just do three and call it done - are the ones who end up rebuilding everything eighteen months later. Ask me how I know.

The real skill is knowing which mode you’re in

Here’s my actual take, stripped of all the Twitter discourse: vibe coding and engineering aren’t opposites. They’re different modes of working, and the skill is knowing which one you’re in.

When you’re exploring, when you’re in discovery mode, when you don’t yet know what you’re building - vibe away. Let the AI lead. Follow your instincts. Move fast and break things (your own things, not production). This is creative work, and creativity benefits from looseness and intuition.

But when you’re building for real, when people’s livelihoods depend on the system working, when you’re handling real money and real data - that’s engineering mode. That requires rigour, intentionality, and a deep understanding of the problem you’re solving. AI is your best tool in this mode too, but it’s a tool, not a strategy.

The best builders I know switch between these modes fluidly. They can vibe on a Monday and engineer on a Tuesday. They use AI tools aggressively in both modes but they understand the difference between exploring a possibility and committing to a solution.

At Reboxed, we used every AI tool we could get our hands on. We moved faster than any startup our size has a right to. But we also did the work. We understood our operation before we tried to automate it. We designed the architecture before we generated the code. We prototyped with real users before we built for production.

That’s not anti-AI. That’s just good product thinking.

And if your entire technology strategy fits in a Twitter thread about vibes - you might want to think a bit harder about what you’re actually building.