Vibe coding from the back of an Uber

We built Sesori because the laptop is not always where an AI coding session needs your attention. Code still gets written there, but the thinking and back-and-forth—“try this, no try that”—can happen away from the desk.

This is a field note on what that looked like in practice. We tried the workflow from the back of an Uber on the way to SFO.

The setup

A normal Monday afternoon. We had an open OpenCode session running against a small TypeScript repo on a MacBook plugged in at the office. Before leaving, we ran:

sesori-bridge

That was the whole setup. The Bridge picks up the open session and connects to the relay. The phone, signed into the same account, sees the session appear without a QR code or a copied token.

Things we wanted to do on the phone, in rough order:

• Read the diff the assistant had just produced
• Ask it to extract a helper function out of a longer file
• Approve the change and run the test suite
• Realize we’d named the helper poorly and rename it
• Watch the test pass

All of that happened in one continuous AI session: the same session that started on the desktop. There was no second copy of the code or mobile sandbox.

What broke (and what didn’t)

The Uber’s Wi-Fi did not exist. The cell signal was usable in some blocks and gone for thirty seconds at a time in others. The session remained usable because the Bridge kept the local AI session running while the phone was offline. When the phone reconnected, the Bridge had buffered the response and the app filled in the gap.

The thing that did feel a little off was the rename. We dictated the new name out loud, the assistant heard it, but the diff that came back used the old name in one place — a comment we’d missed. Easy to fix from the phone, but a reminder that voice is not yet a perfect substitute for the careful read-through you’d do at a desk.

A small log line we found ourselves checking more than once during the trip:

[bridge] session 0xa1f3 keepalive ok · 2 messages buffered

That buffered count made the experience feel solid. Ordinary session payloads are opaque to the relay, while readable session state exists at the endpoints that need it. The phone is a window into work already happening on the laptop.

Where this goes next

We are still a long way from “phone-first development.” The keyboard wins for much of the work, and a 6-inch screen is not the right canvas for reviewing a 400-line refactor. But using a phone to steer an AI session that lives on your machine is a workflow we found genuinely useful after a couple of weeks.

The Bridge source is available under the FSL-1.1-ALv2 license. For setup and the broader workflow, read the OpenCode mobile guide.