Hi there!

Welcome to the 35th edition of Work in Beta.

In this edition we talk about what vibe coding actually means, the difference between a prototype, an MVP and production, which of those you can now build on your own, and how to tell when your idea has stopped being a one-person job.

Somebody on your team built an app and shared it in the group chat. Then somebody else did. Your social media feed has been full of people vibe coding things over a weekend.

You wonder if it is that easy and you should get onto the bandwagon now? Or does this look better from the outside than it truly is?

The honest answer is that both are true. So the useful question isn't whether vibe coding works. It's what are you building with it?

Before AI, building applications and products required one to learn how to code. Vibe coding shifted this part.

Now, you can describe what you want in plain English to AI. AI writes the code. You see the screen it produces, and you review it the way you'd review anything else - a report, an email, a presentation. Does it look right, and does it do what you asked. You say what's wrong and it updates. You go around again. You never touch or see the code.

Say you run marketing, and every week somebody asks how the ad campaigns are doing. Each time, you go and pull the numbers together. You want a dashboard instead: one page that shows every campaign, what it cost, and what it brought in. So, you vibe-code it. A screen comes back with the numbers laid out. Now, you improve it by asking to add cost per lead beside each campaign, highlighting anything where the number went up from last month, and it does. You now have a dashboard to visualise ad spend and you can share it with anyone in the company.

In February 2025, Andrej Karpathy, who helped found OpenAI and ran AI at Tesla, coined the term - "vibe coding".

The next question in your mind would be: how can you get started? AI platforms like ChatGPT, Claude, Gemini can help you vibe code. Then there are specialist tools that are built solely for vibe coding - Lovable, Replit and Bolt - for a first build they're more or less interchangeable. Tools like Claude Code or Codex are more capable but they also expect you to be willing to poke around in technical territory. A lot of tech teams use these for coding.

Our suggestion: pick whichever tool somebody near you already uses, because being able to ask a colleague why something broke beats any feature comparison.

Sounds exciting, right? But is a page you put together in fifteen minutes actually worth anything?

Software gets built in stages, and each stage has a name. Your tech team uses these words all the time, and almost nobody stops to define them, so they get used interchangeably. What you build with vibe coding would also fall under one of these.

These three stages existed long before AI, and they work like a ladder: each step sits further from the idea and closer to something other people depend on. What changed is who can climb the first rung, and sometimes the second one too. Building even a prototype used to need an engineer, which is why most ideas died in a document.

So the first rung is now yours outright, and often the second one as well. Being able to vibe code a prototype or the MVP yourself offers a few real advantages.

It proves the idea. Arguing for something in a document is slow, hard to visualise, and it can take a long time to get a decision. A thing people can view and play around with helps validate your hypothesis better and faster.

Ideas get built that could never make it to the priority list before. An engineer's time is expensive, so small things never reach anyone's list. The Verge reported on Jeff Rothblum, a government-affairs specialist losing 75-hour weeks to committee forms scattered across dozens of websites. So he vibe coded it himself: something that collects the links and deadlines and fills the forms in for him to check before anything gets submitted.

You hand over something better. Until now, you'd write down what you wanted and hand engineering a document. It always carried assumptions you never noticed making, so weeks went into questions: what happens in this case, what about the exception you didn't mention. If your build does eventually reach production, you're handing over a working prototype instead, with the important flows already settled. They build on yours rather than start from scratch.

What if you want to build something that is production grade and has to be used by many people? Should you build it yourself? At this stage a different set of things start to matter, none of which you have ever had to think about: who's allowed to see what, keeping one person's records away from another, what happens when a service your app depends on stops working, is your app secure, whether there's a copy to restore from when something gets deleted by mistake, and who fixes it at 11pm.

And you could vibe code every one of them. Ask for a login and you get a login. Ask for user accounts, permissions, a database, and AI will build all of it without complaint. What appears on your screen will look correct.

The question is whether it is correct, and that is not something you can answer by looking. Take Sign-in. Your app shows a login page, you type a password, you see your own information. It works. But whether that same app stops a different user from reaching your information is a separate rule, written somewhere you will never see. An app that gets that rule right and an app that gets it badly wrong look identical from where you're standing.

And if you can't see what's missing, you wouldn't know it is wrong. The Register reported a Lovable-built app that exposed 18,697 user records, and every screen kept working normally the entire time.

It's the same problem we wrote about in AI Wants a Gold Star. That's the Problem.. There, AI agreed with whatever you brought it and you came away feeling right. Here, it hands you a screen that looks right and you come away feeling done. Both times, the confidence arrives without the evidence.

Security is only half of it. The other half is that you can't tell how far along you are either.

In Lovable's own case study of Elora Health, a nutrition specialist with no coding background felt close to finished after week one, and then spent three hours a day, for a month, discovering how much was actually still left to do. He wasn't wrong about what he had built. He was wrong about how much was missing.

So how do you know when it's fine to keep going on your own, and when it isn't? Not by looking at the app. You look at who else is affected if it goes wrong.

If it is for you only, keep vibe coding. Anything that lives on your own machine, is used by you and maybe a couple of colleagues, and holds nothing you'd mind losing sits here. Build it, use it, and keep improving it for as long as it's useful.

If other people's information goes into it, ask before you share it. Once a colleague's details or a customer's records are stored inside your build, spend thirty minutes with whoever handles IT or security before anyone else uses it. They can see the part you can't: can one person reach another person's information, what happens if a service it depends on goes down, and is there a copy to restore from.

If it's headed for production, that's a handover, not a conversation. Production means real users, real data, possibly money, and something that has to keep working while you're asleep. No amount of advice turns that into a solo job. It needs somebody who owns it as their actual work, and bringing that person in is what any sensible team would do.

Here is how it could look.

You are not going to become a developer, and that was never the offer.

What's actually on the table is something far more useful. You can vibe code the first version of your own idea now, without waiting for anyone. The first rung is yours. Often the second one too.

The one thing you still cannot do is judge it by looking, because the parts that decide whether other people can rely on it are not on the screen. So keep vibe coding for as long as the thing is only yours. And when it stops being only yours, when other people's information goes into it and it has to be secure, don't take a screen that looks right as proof that it is.

Most professionals know AI can do more for them. The gap isn’t awareness - it’s knowing where to start, what to change, and how to make it stick.

That’s what we work on through Work in Beta.

For individuals, we run working sessions, not teaching sessions. You bring a real problem from your actual work; we build the solution with you, live. You’re borrowing our learning curve instead of grinding through your own. You walk out with something that works and the muscle to keep going. When you get stuck later, we’re a message away.

You probably have a version of at least one of these:

Bring that. We’ll build it with you.

For organizations, AI adoption is a people problem, not a technology problem. Your teams have the tools, what’s missing is the translation layer between AI capability and daily work. Which processes to redesign, which habits to break, how to build genuine fluency, not just awareness. We help close that gap through hands-on training, process redesign, and deep adoption engagements. Not advisory, forward-deployed.

If any of this resonates, email us at [email protected] / [email protected] and we will figure out how to work together.

You can reply to this newsletter email if you want to share something specific with us. Have a great week ahead and see you again next week!

-Sonali & PD