From “I Want RVTools on My Mac” to a Working Prototype - Vibe Coding at VMware Explore 2026

Sometimes the best software ideas don’t start with a product strategy.

They start with a simple problem.

“I want RVTools on my MacBook.”

That was the starting point for our team at the VMware {code} Hackathon at VMware Explore Las Vegas 2026.

A simple idea. A few people who had just come together as a team. A limited amount of time.

And Claude Code.

What happened next was a fascinating experiment in what Vibe Coding can mean when you combine human expertise, teamwork and AI-assisted software development.

The VMware {code} AI Hackathon

The event was part of the VMware {code} Hackathon at VMware Explore Las Vegas 2026, built around the idea of using AI throughout the development process.

The format was intentionally different from a traditional software project.

Teams came together, brainstormed ideas and then used AI to design, build, debug and document their projects.

And the time constraint was real.

At 7:30 PM the hackathon started.

At 10:30 PM we had to present.

Three hours.

That’s it.

No lengthy requirements phase.

No six-month roadmap.

No army of developers.

Just an idea, a team and the challenge to turn that idea into something real.

It started with Dale’s MacBook

Our project didn’t start with an abstract discussion about AI or some futuristic technology.

Dale came with a very practical problem.

He wanted to use RVTools on his MacBook.

RVTools has been an incredibly useful tool for VMware administrators for many years. But the traditional application is Windows-based.

So the initial idea was straightforward:

Why not build a multi-platform alternative?

But once we started discussing it, the idea grew.

Why only macOS?

Why not support Windows, macOS and Linux?

And if the application can run on Linux, why not make it possible to run it as a service and provide a web-based interface?

Suddenly, we weren’t just talking about getting RVTools onto a Mac.

We were talking about creating a modern, cross-platform infrastructure assessment tool for VMware administrators.

And we had three hours.

Enter Claude Code

We decided to use Claude Code as our primary AI coding tool.

And this is where our experience became particularly interesting.

We didn’t simply tell Claude Code:

“Build us an RVTools clone.”

Instead, we treated Claude Code as another member of the development team.

We discussed the requirements.

We worked on the architecture.

We created prompts.

Claude Code explored the project and implemented functionality.

We ran the application.

We tested it against a real VMware environment.

We found problems.

We discussed them.

Then we went back to Claude Code and iterated.

The development loop looked something like this:

And that loop could happen remarkably quickly.

The secret weapon wasn’t just Claude Code

One of the most interesting parts of the project is something that is easy to miss when looking at the final repository.

We didn’t just use Claude Code to generate code.

We gave Claude Code context.

At the root of the repository we created a CLAUDE.md file.

Claude Code automatically reads this file when starting a session, allowing us to provide project-specific engineering knowledge up front.

And this wasn’t a generic collection of instructions.

It contained actual knowledge from the project.

Things like:

our Tauri v2 architecture
Rust backend and vanilla JavaScript frontend
VMware REST and SOAP API details
verified vCenter property paths
VMware SOAP response quirks
RVTools sheet and column mappings
vCenter session-management requirements
multiple-vCenter considerations
security requirements
known limitations
lessons learned from an earlier implementation

One rule captures the philosophy particularly well:

Never guess a vCenter API field name or XML shape. Query the live vCenter first and look at the actual response.

That is an important distinction.

We weren’t asking AI to invent a VMware application.

We were giving it domain knowledge and boundaries and then asking it to help us implement the solution.

Turning mistakes into AI memory

Something else was particularly interesting.

The CLAUDE.md file also captured lessons from an earlier implementation.

For example, it documents VMware API pitfalls that had already caused problems and explicitly tells Claude Code not to reproduce those mistakes.

That changes the role of documentation.

Traditionally, documentation is primarily written for humans.

With AI coding agents, project documentation can also become machine-readable engineering context.

A lesson discovered at 8:00 PM can be written down and still influence what the AI does at 9:30 PM.

The project effectively gains a shared memory.

That creates a new feedback loop:

This is, in my opinion, one of the most powerful aspects of AI-assisted development.

Vibe Coding is not “let AI build it”

There is a common misconception about Vibe Coding.

It is sometimes interpreted as:

“Tell AI what you want and let it build everything.”

That wasn’t our experience.

The humans still had to answer the difficult questions.

What problem are we solving?

What does a VMware administrator actually need?

What should the architecture look like?

Which APIs should we use?

Which features matter?

What should we build first?

What can we realistically finish?

And most importantly:

Is the result actually correct?

Claude Code could write code incredibly quickly.

But it didn’t know what our team ultimately wanted.

It didn’t know which compromises we were willing to make.

And it certainly couldn’t replace our understanding of VMware environments.

That’s where the team mattered.

The team became the orchestrator

One of the biggest changes I noticed during the hackathon was how our roles evolved.

Instead of everyone spending the entire evening manually typing code, we spent much more time discussing:

architecture
user experience
VMware functionality
priorities
implementation decisions
and what we should try next

Someone had an idea.

Someone else challenged it.

Another person added a different perspective.

Then we could ask Claude Code to turn that decision into software.

That meant we could get from an abstract idea to something tangible much faster.

And once something was tangible, we could have a much better discussion about it.

That’s a very different development workflow.

Three hours changes the rules

A traditional software project can afford to spend significant time defining requirements before implementation.

A hackathon cannot.

At 7:30 PM we had to start building.

At 10:30 PM we had to present.

That changes the economics of experimentation.

If implementing an idea manually takes half a day, you think carefully before trying it.

If an AI coding agent can create a first version in minutes, you can simply try it.

Does the UI work?

Try it.

Does the architecture work?

Prototype it.

Does the VMware API return what we expect?

Test it.

Doesn’t work?

Change it.

This is where AI-assisted development becomes particularly powerful.

Not necessarily because AI writes code faster than humans.

But because the cost of experimentation becomes dramatically lower.

But speed without discipline is dangerous

There is an obvious downside.

AI makes it incredibly easy to create software.

It also makes it incredibly easy to create too much software.

You can generate:

unnecessary abstractions
unnecessary dependencies
unnecessary features
unnecessary complexity
and large amounts of code nobody has properly reviewed

That’s why Vibe Coding doesn’t eliminate engineering discipline.

I would argue it makes engineering judgment even more important.

Someone has to say:

“We don’t need that.”

Someone has to say:

“That’s the wrong architecture.”

And someone has to say:

“This looks good, but it isn’t actually correct.”

The ability to generate code is becoming cheap.

Good engineering judgment isn’t.

The VMware API doesn’t care about your vibe

This became especially obvious when working against a real vCenter.

AI can generate a perfectly reasonable-looking API call.

It can also be completely wrong.

VMware’s APIs contain plenty of details that aren’t obvious from a quick glance.

Our CLAUDE.md therefore contains explicit instructions not to guess API fields or XML structures and to verify behavior against the live vCenter.

That approach saved us from a lot of potential problems.

It also demonstrates something important about Vibe Coding:

The quality of the result depends heavily on the quality of the context you give the AI and the quality of the validation you perform afterward.

In other words:

Prompting is only half of the job.

Validation is the other half.

From prompting to engineering context

This is where I think the term Vibe Coding needs a little more nuance.

There is a big difference between:

Prompting an AI

and

Engineering with an AI agent.

Prompting is asking for an output.

Engineering with an AI agent means giving it:

project context
architectural boundaries
domain knowledge
constraints
coding standards
examples
test expectations
and feedback

Then allowing the agent to operate within those boundaries.

That’s much closer to how we worked during the hackathon.

Claude Code wasn’t simply generating isolated pieces of code.

It was working inside an evolving project context.

The real multiplier was the team

The most interesting part of the hackathon wasn’t that AI could write code.

We already knew that.

The interesting part was what happened when a team with different experiences could use AI as a shared implementation accelerator.

One person could focus on the VMware side.

Another could think about the user experience.

Someone else could challenge the architecture.

Another person could think about what would make the final demo compelling.

Claude Code helped turn those perspectives into working software.

That made the team faster.

But more importantly, it made the team more willing to experiment.

From “Can we build it?” to “How fast can we try it?”

This is probably the biggest lesson I took away from the event.

For years, software teams often asked:

“Can we build this?”

With AI coding agents, the question increasingly becomes:

“How quickly can we try it?”

That’s a fundamental change.

If experimentation becomes cheaper, teams can explore more ideas.

You can test more approaches.

You can throw away prototypes without feeling that you have wasted days of development.

You can fail faster.

Learn faster.

And ultimately build better things.

What happens when everyone can build?

This is where the potential of Vibe Coding becomes really exciting.

Imagine a team where every person has an AI coding agent.

The VMware expert can prototype an API integration.

The UX person can iterate on a UI.

The automation expert can build workflows.

The developer can refactor the architecture.

The product-minded person can prototype an entirely new user experience.

The bottleneck begins to move.

It moves away from:

“Who has time to write this code?”

and toward:

“Is this idea worth building?”

That’s a profound change.

AI doesn’t replace the team

Our experience certainly didn’t make me think that developers are becoming irrelevant.

Quite the opposite.

The skills that mattered most were:

Context.
Experience.
Architecture.
Creativity.
Communication.
Judgment.
Curiosity.

AI provided:

Speed.
Implementation.
Iteration.
Automation.

Put those together and you get something very interesting.

Humans decide what is worth building.

AI helps build it.

Humans validate whether it is actually good.

And then came the demo

At 10:30 PM, we had to show what we had built.

Only a few hours earlier, we had been discussing the idea.

Now we had a working prototype.

Was it perfect?

No.

Was it finished?

Absolutely not.

But that wasn’t the goal.

The goal was to take an idea and see how far we could get in a single evening.

And the result was much more than a proof of concept for a multi-platform RVTools-like application.

It was a proof of concept for a different way of building software.

From one MacBook to a bigger idea

Looking back, it’s quite funny how this started.

Dale wanted RVTools on his MacBook.

That simple request became:

What if we build a multi-platform application?

Then:

What if it also runs as a Linux service?

Then:

What if the same backend can power a web interface?

Then:

What else could we do with the data?

And eventually the conversation becomes much bigger:

What could infrastructure assessment look like if it were designed today?

What could we do with AI?

How could we make VMware administration more approachable?

How could we turn raw infrastructure data into useful insight?

We didn’t answer all of those questions during the hackathon.

But we created something much more valuable:

a starting point for exploring them.

What I took away from VMware Explore

Looking at the picture of our team, I don’t primarily see the application.

I see a group of people who came together around a simple problem, brought different perspectives to the table and used AI to dramatically accelerate the path from idea to working software.

And that’s what I will remember from the VMware {code} Hackathon.

Not that AI can write code.

We already know that.

What was exciting was seeing what happens when people who understand a problem deeply can use AI to turn their ideas into working software almost immediately.

Three hours earlier, we had an idea.

Three hours later, we had a prototype.

And somewhere in between, we discovered something about the future of software development.

Humans + AI

I don’t think the future is:

AI vs. developers.

I think it’s much more likely to be:

Humans + AI.

Humans bring the problem, the experience, the context and the judgment.

AI brings an incredible ability to turn those decisions into software quickly.

And the better the collaboration between the two becomes, the more powerful the combination will be.

Maybe that’s the real promise of Vibe Coding.