Lessons from 48 hours of vibe coding

And why every Engineering Manager should try it

For years, I wanted to build side projects. Like real web apps with real users. But with my limited frontend skills, the idea felt intimidating. Until 2025.

What changed?

AI coding assistants! They’re here and evolving fast. They now feel like pair programming with an eager junior engineer. Lately, I’d been watching some cool demo videos. But last weekend, I decided to stop watching and start building.

I dove into what Andrej Karpathy calls “vibe coding” — AI-assisted development using only prompts.

I’ll share what I learned and why every engineering manager should try it.

But first, the question where everyone gets stuck at:

Which AI Assistant Should I Use?

There are tons of coding assistants—Cursor, Bolt, Lovable, Replit. This video does a great job comparing them. But honestly? Just pick one and start. Getting stuck picking your tool is worse than using a suboptimal one.

I chose Replit because
✔ Browser-based (no local setup)
✔ Built-in databases
✔ One-click deployments

I started with the free plan, loved it, and upgraded to the paid plan ($180/year). Impulse buy? We’ll see.

This is NOT a sponsored post, but if you use my referral link and get a paid plan (Replit Core), I get $10 in Replit credits.

---

What I learned from 48 hours of vibe coding

As an example for reference in this post, I created a simple landing page (with just a single prompt):

1. Updating an App is Harder Than Creating One

Creating a new app: 2 minutes, 1 prompt.
Making updates: 3 hours, 20 prompts, $10 in credits burned.

It may seem magical how in my example it created a full landing page with just one simple prompt. But come to think of it, I didn’t play any role in the design. What if I want different font, layout, image, etc.? You spend a lot of time doing the little details, one prompt at a time.

AI also struggles with debugging issues. It often loops through “fixes” trying random things, hoping one of them will work. It reminded me of how I coded in college projects. “Let’s add more print() statements!!”

It’s even worse when the issue is a configuration problem, like a broken database connection.

Key Takeaways:

• Set realistic expectations. Don’t expect magic (yet), which is where most people are getting frustrated. Working on a large existing project isn’t gonna go as smooth.

• The output is only as good as your prompt. It's very easy to be lazy with AI. “Oh, it'll figure it out.” Then you spend hours trying to get the app close to your vision.

• You play the product owner. AI can code, but you need to play the role of the “glue”. Thinking about design, user experience, branding, scaling up, etc.

2. You Go Farther with Technical Knowledge

AI assistants are not fully autonomous. At best they’re good at writing code on a fresh project. But it struggles as the project grows.

That’s where having technical skills comes handy. The more technical context you have, the faster you can make progress with AI.

• You can spot issues faster. “Oh, that’s a broken DB schema.”

• You can ask smarter questions. “Is this variable initialized correctly?”

• You can skip unnecessary prompts. Why waste credits tweaking a font when you can edit the code directly?

Key Takeaways:

• Pay attention to what the Agent is doing. The code structure, dependencies, file diffs, etc. Review the code in the editor and build your understanding.

• Apply your technical skills. Even if you’re like me where you mostly know backend and infra stuff, you can use that knowledge to guide the agent.

3. AI Output is Non-Deterministic

Same prompt. Different results.

Remember the “ReadingBooks” landing page above? I took that and added a bunch of features. In the process, I broke everything. No problem, I thought I’d just start over.

I spun up a new project, entered the same exact prompt, and… got something totally different. It felt like hiring two different developers and giving them the same vague instructions. The results varied wildly.

Key Takeaways:

• Back up your prompts. I didn’t realize how much detail I lost until I had to rewrite them.

• Be specific. Prompt engineering is the new debugging. Use ChatGPT to refine your prompts.

• Save your code. Push it to GitHub or copy snippets. You may need them later.

4. Dev and Prod Environments Blur Together

Replit makes deploying easy, maybe too easy.

I built and tested my app, then deployed to prod in five minutes. YOLO.

I assumed my dev environment was separate. It wasn’t. I only realized this after test data from dev started showing up in the live app.

Key Takeaways:

• Use a real database. Replit’s built-in DB is fine for experiments, but I wouldn’t trust it for production. Use Supabase or another external DB.

• Use feature flags. Separate dev and prod configurations with environment variables.

• Monitor resource usage. AI-assisted coding burns credits fast. Keep an eye on memory and CPU consumption for live apps.

---

The Takeaway: EMs Should Try This

In 48 hours, I learned more about web development than I had in 10 years of watching from the sidelines.

But more than that, I learned how to work with AI coding assistants.

Before trying, I thought, “It’s just natural language prompts, right?”
Wrong.

You don’t truly understand these tools until you:
✅ Build something real
✅ Debug with them
✅ See where they shine and where they fail

In the future, who knows you might manage AI agents alongside human engineers.
“Congrats! Your team now has 4 senior devs and 2 AI agents.”

This space is moving fast. Don’t ignore it. Start vibe coding today.

---

What did I build?

• A lot of half-baked apps that are not ready for sharing.

• Landing page for this blog (and a waitlist for some magical futuristic tools): https://emdiary.co

---