From Vibes to Viable

Why Vibe Coding Belongs in Every Job at Blank Metal

It started with a simple problem: we needed a resourcing tool. Fast.

With tons of work in the pipeline at Blank Metal, the question "who’s going to work on this?" was becoming a daily, sometimes hourly question. So we did what any reasonable person would do in 2025—We started vibe coding.

What is Vibe Coding?

Let me back up. When we say "vibe coding," we're talking about using AI tools to build real software without necessarily being a "real" developer. It's coding by conversation, by intuition, by describing what you want rather than knowing exactly how to implement it.

We have a simple but ambitious idea of getting work done at Blank Metal: democratize the ability to solve problems with software. Built on an understanding that custom software has never been easier or cheaper to build, we want to build and use it in as many places as we can.

This isn’t just for developers or technical people. We think anyone who sees a problem and has an idea for fixing it should be able to bring their idea to life.

We think there’s good business return here too…if we’re GREAT at doing this, we’ll swap high licensing fees with low compute costs to spend a lot less on operations than is typical for services companies like ours. But that will only work if vibe coding can produce great tools quickly.

From Quick Fix to Production Tool

Week one looked like this: we spent maybe 4-5 hours building a resource management web application. Simple inputs—what’s the project, who's on it, how many weeks, what's the allocation percentage, and the status of the project. Nothing fancy, but it worked. More importantly, it blew the alternative of a spreadsheet out of the water, which would have taken roughly the same amount of effort and been a management nightmare down the road. We know because we’ve run past businesses that way.

We deployed our new web app immediately. Why? Because perfect is the enemy of done, and we needed something NOW.

Over the next month we kept tweaking it, pushing changes straight to production. No version control. No tests. Just pure, unbridled iteration. It was super liberating to be able to move so fast, and to go from a product thought to a feature in production in minutes.

Then reality hit.

When "Move Fast" Meets "Don't Break Things"

The first signal that we needed to re-think our workflow came when our CTO ran security tests on the application code (also via AI, by the way). We knew that vibe coding platforms weren’t likely to prioritize security and best practices the same way our engineers would, and the scans proved it out: there were some things that had to be addressed.

Our quick and functional solution suddenly looked less like innovation and more like a potential liability. The good news is that the same tools that sped up feature development fixed the errors just as fast.

But, it got us thinking: How do we make vibe coding production-ready while staying true to our vision? We needed to plan out our work in a way that matches the right level of effort with the stage of the things we’re working on.

The Three Stages of Vibe Coding Maturity

Through trial, error, more than a few git conflicts, and a few very exciting conversations we've adopted a workflow with three distinct stages to get from idea to scale at Blank Metal.

Stage 1: The Solo Vibe Coder

One person, one problem, one project. It's beautiful in its simplicity. The solo vibe coder is the product manager, product owner and engineer. They can iterate fast, deploy instantly, and build surprisingly complex solutions without touching traditional development tools. Solutions that can demonstrate an idea, or better yet be used by small groups of people in their actual, day-to-day work to bring immediate value.

Even a lightly-trained vibe coder armed with the right prompts and simple safeguards can improve the quality of their output, which expands the set of use cases where vibe coding is viable.

Perfect for: Personal tools, team tools, prototypes, proofs-of-concept
Limits: Won’t work when SOC2 is required, and you need to be sure that the vibe coder is trained up enough to protect your data, even if it’s not super sensitive.

Stage 2: Vibe Coder + Engineer Partner

Once a solo vibe coder has a solution that needs to handle sensitive data or what they’ve built is becoming a mission-critical tool, it's time to level up. This is where a vibe coder partners with an engineer to add the scaffolding needed for production—proper version control, security reviews, unit testing, code quality standards, data best practices, and deployment pipelines.

It’s best if the engineer becomes a collaborator early in the process so they can help the vibe coder put quality into their work from the start. At the very least engineers should be last mile support before the changes make their way to production. Full disclosure, this slows things down. Instead of going from idea to production in an hour, the vibe coder will have to wait for a pull request to get reviewed and approved…but if you set expectations right this can still happen in hours, not days.

Perfect for: Tools with multiple users, customer-facing features, anything requiring compliance
Limits: Allocating the right time for engineering partners, and not making their job the worst form of babysitting. No thanks.

Stage 3: The Vibe Coding Team

When you’re at the point where you need more done than just one person has time to get to, it’s time to get multiple vibe coders and engineers working together on the same codebase. This is where things get really interesting—and really complex. You need all the processes of traditional software development, but they need to remain accessible to people who only just learned what a pull request means.

Now the last mile gets a little more difficult and time consuming. After all, AI can produce A LOT of code…and therefore a lot of merge conflicts. A lot of AI tools working at once makes this problem exponentially bigger. It’s at this stage where you need to run some ceremonies to talk about what the priorities are, what everyone is working on, and some rules of the road (like definition of done, PR approval & merge rights, linting standards, deployment schedules, etc). The agile ways of working will help minimize overlap, point people in the right direction, and enable the right conversations throughout the work.

Perfect for: Teams that are used to collaborating on software anyway
Limits: Patience…engineers will spend time coaching, teaching and fixing work they’d never have created that way in the first place, and vibe coders will have to slow down and learn some new concepts in order to get back to the velocity they will have grown to love.

The Hard Lessons (So You Don't Have to Learn Them)

After four months of work to make vibe coding work for us on applications that run our business, we have a few recommendations for anyone heading down this path.

Infrastructure Choices Matter—But They're Often Invisible

The vibe coding tool made a bunch of infrastructure decisions for us. Suddenly we were using Neon for our database, Drizzle as our ORM, and a dozen other tools a lot of us had never heard of. When you vibe code, you're not just accepting the AI's code suggestions—you're accepting an entire ecosystem.

There are a lot of vibe coding tools and we’re trying them all. Vercel, Lovable, Replit, Cursor, Windsurf, Firebase Studio, Claude Artifacts…they all have their own tools, perspectives, and opinions that are important to understand when making apps that matter.

Lesson: Understand what infrastructure you're buying into, even if you didn't explicitly choose it.

Naming Things Remains A Sneaky and Tricky Problem

Our AI decided to call potential projects "projects," then when we added the idea of “booked” projects, it called them "actual_projects." This naming confusion cascaded through the entire codebase. When the vibe coder would say "update the resource heatmap in the project list," the AI knew exactly what we meant. When an engineering colleague joined, those words were gibberish. Well, maybe not gibberish, but not very helpful when figuring out what a line of code did.

Lesson: Establish a clear vocabulary upfront and tell the Vibe coding tool to use your names in data and code. Consider creating prompt templates to use across projects with pre-defined naming conventions.

Git Conflicts Are the Vibe Killer

Nothing stops the flow of vibe coding quite like a merge conflict. For someone who's been happily describing features and watching them appear, suddenly staring at <<<<<<< HEAD markers feels like being ejected from the Matrix. If you can train vibe coders to manage the scope of work they take on at one time, the end-of-the-line tasks will get easier and go faster.

Lesson: Commit small, commit often, and invest in tools or processes that can help resolve conflicts without diving into code.

Guardrails Enable Freedom

Counterintuitively, the more constraints we added—linting rules, type checking, required tests—the easier vibe coding became. Good guardrails mean the AI makes fewer mistakes and vibe coders spend less time debugging.

Lesson: Front-load your standards. It's much easier to start with guardrails than to add them later.

The Bottom Line

A year ago, it would have taken many months and many developers to build our production application. Today, we’re maintaining one that our entire team uses every day and we’ve spent less than 80 total hours on it. That's the power of vibe coding.

And, the tools are getting better, the patterns are becoming clearer, and the gap between idea and implementation is shrinking.

We’re bullish on this way of working, but we’re also realistic. Production software has requirements—security, scalability, maintainability—that can't be hand-waved away. The trick is building bridges between the accessibility of vibe coding and the rigor of professional software development.

Is vibe coding ready to build your next billion-dollar platform? Probably not.

Is it ready to solve that annoying problem your team faces every day? Absolutely.

And that's where the revolution starts—not with grand proclamations about the future of software, but with regular people solving real problems, one vibe at a time.