SwipeShip: Tinder for Vibecoding [Free + Open Source]
SwipeShip: Tinder for Vibecoding [Free + Open Source]
By Justin Wetch
GITHUB REPO: https://github.com/justinwetch/SwipeShip
SwipeShip is a tiny iPhone remote for vibecoding. When your AI coding agent hits a taste question, a card appears on your phone. You swipe yes or no, optionally drop a comment, and the agent keeps building. The whole interaction is as easy as swiping on Tinder.
The first real test of it was using SwipeShip to build SwipeShip.
Codex was working on the project and hit a decision: structure this as a Codex Plugin or find a way to integrate slash commands? A card appeared on my iPhone. I swiped yes. Codex got structured JSON back and kept going.
That is an oddly meta sentence, I know. It is also the exact kind of thing that happens when you build tools for tools. What I want to talk about is not the recursion. It is what the swipe felt like.
It felt silly for about two seconds. Then it felt obvious.
The taste problem
Agents have gotten good enough that the bottleneck is no longer "can the model do it." The bottleneck is taste. Direction. The thousand small choices that separate a project with a point of view from another piece of generic AI slop output.
Most of the difference between interesting work and slop lives at this layer. Should this be local-first? Should pairing use a QR code? Should the Codex side be an MCP server, a plugin, or some made-up slash command? Should the README promise a roadmap or stay honest about being a prototype? Each question is small. The aggregate is the personality of the thing.
A model with no input on these will average toward the median of its training data, which is exactly what slop is. A model with a person making the calls produces something that bears the signature of an actual mind.
The friction has been the surface. The model is sitting in a terminal asking a human to make a product call, and the chat is already doing too many jobs: transcript, command center, planning space, error log. Dropping a taste question into that mess turns a one-bit decision into more work than it should be, and the natural response is to wave the model through with "yeah whatever, do what makes sense." That is the moment taste leaks out of the project.
So I put the question on my phone.
Why a phone
Computers are where work piles up. The phone is where tiny choices already live. The device is extremely good at quick binary judgment, and a surprising amount of agent work is exactly that, once you give it the right surface.
Putting a decision card on the phone separates the moment from the mess. It also changes the emotional texture in a way that sounds minor until you try it. A swipeable card on your phone makes the product decision split immediately legible and fun to interact with. A prompt in the terminal feels like more work.
How it works
Three pieces: a SwiftUI iPhone app, a local Node bridge, and an MCP server Codex can call from a normal session.
Codex calls a tool called request_swipe_decision. The bridge sends a card to the paired iPhone over WebSocket. You swipe, optionally add a comment, and the bridge returns something boring on purpose:
{ "decision": "yes", "comment": "Keep it local-first for the alpha." }The contract is deliberately narrow. If the model can ask anything in any shape, the phone becomes another chat app, which defeats the entire point. I want the agent to stop at the moments where human judgment is genuinely useful, package the question cleanly, and get out of the way.
SwipeShip is local-first for the alpha because the shape of the interaction should be visible. The bridge is a little machine you can inspect. If something breaks, you can usually see where.
Control surfaces for human judgment
AI coding tools have spent enormous energy on bigger context windows, smarter editing, more capable agents. But there's another layer starting to appear that matters just as much: control surfaces for human judgment. The little surfaces where taste enters the system. A card on a phone. A hardware button. A menu bar approval. A watch tap.
The more competent agents get, the more these surfaces become the actual product. If the model is bad, you supervise everything. If the model is good, the whole job changes. You stop micromanaging the code and start steering taste, direction, and constraints at exactly the right moments, with as little friction as possible between intent and signal. The agents that produce interesting work, rather than competent slop, will be the ones whose humans had clean ways to keep pouring themselves in.
SwipeShip is one experiment in that direction. It is a little ridiculous. It is also, in my experience, useful.