Taming the dragon: a practical path for vibecoding internal tools

The other day I was on a call with several non-developers, and they were genuinely excited about the possibility of building their own tools to make their work easier, faster, and better. Some of them are already experimenting and building things.

At the same time, they also feel — or have heard — that these tools are very unlikely to ever be deployed. And, as things stand today, they are probably right.

For apps vibecoded by normies to make it to production, they must meet clear standards for safety, maintainability, and scalability. That part is non-negotiable for the tech side of the organization.

So the situation is essentially this:

1. Non-devs want to build the tools that make them more effective and help organizations grow.
2. Techies need to protect the systems and the data, so the core business remains operational, compliant, and maintainable.

Both sides are right. The challenge is finding a path that enables innovation without creating chaos.

I have been thinking about how to help non-developers build useful tools in a safe way, and I think the key principle is simple:

The earlier problems are caught, the easier and cheaper they are to solve.

Basically, this is the old story of order and chaos, the one that usually asks for a hero: someone who breaks the ancient rules of the village, goes out into the dark, faces the dragon, steals the treasure, comes back transformed, and gets the hottest girl. What is the point of facing death if not to get the hot girl.

But this time, this story is not about solo heroes. It is about the tribe, and about having a plan.

Not having a plan means heroes going into the dark with no map, no training, and no support, and probably fucking it up so badly that the dragon burns the whole village to the ground, including the hot girl.

Having a plan means building a system that casts light into the shadows early, finds patterns in the chaos, and makes it possible to move forward safely.

With that in mind, here is a practical and feasible plan that almost any organization can follow, maybe with some adaptations to its own circumstances.

The rule is simple: this plan is about discovery and about building the foundations layer by layer. You only move to the next step if the previous one proves useful. If not, you stop and reevaluate.

The plan

1. Create a space for vibecoders

Create a shared space where non-technical people can show what they are building, exchange tips and tricks, and ask for guidance when they run into technical decisions whose implications they may not fully understand.

Developers can join voluntarily to offer advice and help steer projects toward approaches that are more likely to be safe, maintainable, and eventually deployable.

It can be a Slack channel, a Teams space, or whatever best suits your organization.

Success looks like: the space is active, focused, and useful both for vibecoders and for developers, who get to better understand vibecoders’ needs and recurring problems.

2. Consolidate learnings into shared guidance

Over time, the recurring patterns from those interactions can be documented for both humans and agents.

This guidance could include things like:

• recommended stack choices
• clear dos and don’ts for acceptable projects
• common mistakes and pitfalls
• tools and practices that make collaboration between vibecoders and developers easier

Success looks like: the documentation genuinely helps people build more safely and efficiently.

3. Vibecoder babysitting

Encourage the most active developers and vibecoders to pair regularly and help bring the most promising projects closer to production readiness.

The point is simple: catch problems early, guide technical decisions before they become expensive, and help people cross the gap between “interesting prototype” and “something we could actually ship.”

Success looks like: some vibecoded tools become useful enough to deliver value and solid enough to be considered deployable.

4. Build safe, predictable infrastructure for vibecoded apps

Vibecoders should not deploy to random cloud providers of their choice. Their apps should not be deployed to the production cluster either, which must remain focused on the core business. And infrastructure or platform teams should not be burdened with manually provisioning and deploying one-off apps, each with different requirements.

Instead, you need a deployment model that is simple, predictable, repeatable, and safe.

This will likely include shared building blocks such as:

• databases / collections / data sources
• authentication support
• file storage for uploads
• email and communication capabilities, likely restricted and controlled

Success looks like: a cost-effective platform, both in infrastructure cost and ops time, that makes vibecoded apps easier to build and safer to operate.

5. A babysitting team

If vibecoded tools become widespread, it may eventually make sense to have a dedicated team or function responsible for helping vibecoders build and for maintaining the resulting tools.

Do not dump these responsibilities randomly onto existing teams whose contexts are already big and complex enough.

Success looks like: vibecoders become more effective, existing tools continue to evolve, and operational ownership remains clear.

Conclusion

I hope more and more organizations take this opportunity seriously, because those that do not will not survive.

The treasure we are going after is even better than a mountain of gold to become obscenely rich. It is an incredible source of power to build the wildest of our dreams.

I have no doubt that this is as huge and transcendental as taming fire was for prehistoric humans.

If you need help with this mission, drop me a line.