Google Play with Putty: What Multiplayer Vibe Coding Actually Means

Google just made vibe coding multiplayer. I think this might be where building software goes next.

I have not tried Play with Putty. I do not have access yet, and Google is currently sending people to a waitlist. So this is not a review.

It is me looking at a very early experiment and thinking about what it could change.

What Google Play with Putty is

Google describes Play with Putty ↗ as a Google Labs research experiment where teams can build tools and websites together in real time.

I first came across the announcement through Pasquale Pillitteri’s article about Play with Putty ↗. His explanation made the difference easy to see.

Normal vibe coding is one person describing what they want and an AI building it. Play with Putty brings several people into a shared workspace so they can shape the same thing together.

That sounds like a small addition. I do not think it is.

The LinesFly scenario I cannot stop thinking about

Imagine I am building a new LinesFly feature with an actual store owner sitting in the workspace with me.

I ask them to walk me through what happens when the store gets busy. Where does the current process fall apart? What does the employee behind the counter need to see? What does the customer keep asking?

Today, I would listen, take notes, turn their feedback into prompts, build the feature, test it, and show it to them later. Then they would explain what I misunderstood, and I would go back through the loop again.

Now imagine that conversation happening while both of us can see the product change.

The store owner says, “That button needs to be available before we call the next person.” We change it. They try the workflow. They realize the real problem is one step earlier. We change that too.

We are not discussing an abstract feature anymore. We are looking at the same thing and shaping it together.

Feedback stops being a handoff

That can fundamentally change how small products get built with clients.

The usual process has several handoffs. The person who understands the problem explains it to someone else. That person writes it down. Someone translates it into a product requirement. Someone else turns it into code. Then everybody waits to see whether the result matches the original problem.

A lot gets lost between those steps.

With multiplayer vibe coding, the feedback can happen inside the build. The person who lives with the problem can point at the screen, explain what is wrong, and see the next version appear while the conversation is still happening.

That does not mean every suggestion should become a feature. Somebody still has to make decisions. But it could remove a lot of the translation that slows small builds down.

Vibe coding is surprisingly solitary

I have spent the last few weeks building several software products with AI. One thing I did not expect is how lonely the work can feel.

It is one person talking to one agent, with a couple of sub-agents in the background at most.

Nobody around you knows why you keep going back to the computer. Nobody knows what you are checking on your phone. You are excited because a workflow finally works, but the only other thing in the room that understands what happened is the AI that helped you build it.

I tend to like working alone. Even I notice it.

Software was already collaborative. The code was the gate.

A traditional software team usually brings together people who understand different parts of the problem.

The business owner understands what needs to work. Someone understands the customer. Someone has product or UX experience. Someone understands operations. Someone else understands the code.

They all put in their two cents, but only a few people can directly change the product.

Now imagine those people participating in one workspace. The operations person can show where the workflow breaks. The designer can shape what the interaction should feel like. The business owner can keep the group focused on the actual problem. AI handles more of the translation into code.

The barrier drops again.

First, AI made it possible for someone like me to build working software without becoming a programmer. Multiplayer vibe coding could make it easier for people with different experiences to participate directly in the build.

This could be a real opportunity for custom software

I do not want to turn LinesFly into a completely different product for every store. That would be difficult to maintain, and it would pull the product in too many directions.

But the opportunity is obvious for someone who wants to build custom software for clients or small businesses.

A consultant could sit with a business owner and build the internal tool around the way that business actually works. A nonprofit leader could shape a reporting workflow with the person building it. A school team could work through a tool with the teachers who will actually use it.

Not a six-month process where the client sees the result after every major decision has already been made. A working session where the client can see the thing become real and correct the assumptions while they are still cheap to change.

That is highly customized software with the client’s input happening in real time.

I still have a lot of questions

Play with Putty is a research experiment, and I am still outside the waitlist looking in.

I do not know how it handles two people giving conflicting instructions. I do not know what permissions, version history, undo controls, deployment options, or production safeguards will look like. I do not know whether it will be useful for a real software product or mostly fun for smaller tools and websites.

Those details matter.

But the direction is interesting even if this specific experiment never becomes the final product.

Google is pointing at a version of software creation where people do not just request a tool and wait for somebody else to make it. They help shape it while it is becoming real.

I will probably keep doing most of my building alone. That part suits me. But bringing the right person into the workspace for one feature, one workflow, or one important decision?

I can absolutely see the value in that.

A few quick questions