Dinner-Table-Driven Development

The Gap

I’m an American software engineer. Victor is a retired Colombian telecommunications engineer. He only speaks Spanish. I only speak English. For eight years, we’ve been family. I married his daughter Valentina, and we’ve made it work the way families do - someone translates, someone gestures, someone laughs at the wrong moment and hopes nobody noticed.

I grew up as the monolingual kid in a multilingual world. It’s a long story, but the people I grew up with came from all over. English was always the common thread.

My Colombian family and I figured it out - gestures, pointing at things, Valentina repeating herself in two directions at once. Victor and I can get through a grocery run on context and goodwill. But real conversation - the kind where someone’s being funny or telling a story that only works if you catch the timing - has always needed someone in the middle. When nobody’s available, one of us just sits there. Sometimes it’s Victor. Sometimes it’s me. Eight years of that.

Wedding Morning

Less than two weeks ago, Valentina’s sister Andrea got married at a beautiful cabin in the woods outside DC. Most of the guests spoke Spanish; the rest were partners who didn’t. Saturday morning, Andrea and the wedding party were gone - hair, makeup, stress - and Victor and I were handed a list of errands. No one had time to translate. We were on our own.

At work I push AI pipelines pretty hard. I know what these tools are capable of. Standing there looking at the day ahead, I thought, I can build something that works great for just us. Not a research project. Just: we need to communicate today.

I built a prototype. It worked - we used it all morning, errand logistics and all, actually talking without someone in the middle. Then I told Victor I was going to brush my teeth, and the prototype decided dental hygiene constituted medical advice. It refused. We were in our suits, and the only thing left to translate was “let’s get out of here.” That was the moment: I didn’t need a wrapper around someone else’s AI. I needed my own pipeline - one that wouldn’t have opinions about your morning routine.

I started building Óyeme on the plane home - hear me in Spanish. A single utterance flows through three services in about two seconds. One transcribes, another translates, a third speaks. Some fun engineering problems in the seams. We hosted her parents in Salt Lake for the week after the wedding - the perfect test environment - real users, real conversations, every day.

Team

Óyeme has an in-app development board. It’s bilingual - you dictate a feature idea or a bug report in your language, and the app translates it for everyone. When something goes wrong, Sandra or Victor use their phone to dictate what happened and how it should work instead. It goes through a little cleanup and creates a translation for me to hear and see. That submission kicks off the pipeline described below.

Valentina explained the pipeline to Victor and Sandra early on. Your ideas can become features. The app can turn what you submitted into a task, write the code, and build a new version - all before you finish dinner. Sandra turned out to be the most prolific contributor on the development board. More submissions than anyone, including me. It stopped being my project pretty fast.

The family speaks Costeño - Colombian coastal Spanish, heavy on slang, dropped consonants, and phrasing that throws off general-purpose translators. Separately, there’s a family_glossary in the database: names, places, pets, inside jokes - the proper nouns and family-specific terms the translator should always preserve verbatim. We maintain it ourselves through an enrollment flow, and it gets injected into every translation prompt.

Pipeline

This is the part that made me rethink what “development” means. An idea Victor or Sandra dictates into their phone - in Spanish, while eating, mid-conversation - can become a merged pull request without me writing a single line of code. Not a feature request that sits in a backlog. A PR, with a branch, a diff, a preview deploy. I review every PR before it ships - I just tap into the agent session from my phone, steer it if it needs work, or merge it if it’s good. The whole thing runs in the cloud. But the path from “Victor thinks the translation was too formal” to “here’s a PR that adjusts the system prompt register” is fully autonomous.

The architecture.

The trigger. When a new idea lands in the ideas table, a database trigger fires an HTTP POST to the app’s /api/pipeline/trigger endpoint. The endpoint validates the request and kicks off the intake routine. (In practice, I’ve toggled this to require manual approval; some ideas need human triage first. Victor’s throughput is higher than you’d expect.)

The intake routine. This is a Claude Code routine, a headless Claude session that runs on Anthropic’s infrastructure. It receives the raw idea (in whatever language the user submitted it) and does five things:

1. Reads the entire codebase (CLAUDE.md, the file tree, persona definitions)
2. Checks for duplicate issues via the GitHub API
3. Reads the files most likely to be affected by the idea
4. Refines the raw idea into a structured GitHub issue spec (user story, acceptance criteria, affected files, scope boundaries, persona context)
5. Creates the issue and fires the build routine

The build routine. Another Claude Code routine, also headless. It picks up the structured issue and does the actual implementation:

1. Research: deep-reads every file in the spec’s affected areas, checks git history, identifies edge cases, and posts a research comment on the issue with its implementation plan
2. Build: creates a feature branch, implements the changes with conventional commits, and opens a PR
3. Verify: runs npm run build. If it fails after three attempts, it posts the build output as an issue comment and stops

When I merge a PR, a GitHub webhook updates the idea’s status on the board in real time. Victor can watch his idea go from “building” to “done” without refreshing the page.

Goodbye Dinner

Mesa mode came later in Salt Lake. Everyone talks, the app sorts out who said what, and each person gets their own translation. Everyone has to slow down a little, which at a Colombian dinner table is an ongoing negotiation. Text-only for now - five competing TTS streams through a single phone speaker is a problem we haven’t solved yet.

The night before they left, we made the kind of dinner you put effort into when you don’t know when you’ll all be at the same table again. The phone sat in the center running mesa mode. Victor told a story and I caught the punchline without waiting for someone to turn to me and explain it.

Loop

We’re building a way for the app to learn from corrections mid-conversation - no menu, no typing, just talk to it.

The thing about building software with your family is that the feedback is honest in a way no product review process will ever be. Victor doesn’t know what a sprint is, but in this case he doesn’t really need to. He knows the app said “camel” when he meant “hard work,” and he’s going to tell the app. Then I’ll have a PR to review before we clear the table.

I expected to build a useful tool and feel good about solving a family problem. What I didn’t expect was that my in-laws would become my most engaged collaborators - that Sandra would outpace me on the development board, that Victor would help shape the most-used mode, that the whole family would talk to the app about the app like it’s a slightly slow dinner guest who means well.

For eight years, Victor and I have communicated through other people. This past week, we had real conversations - not logistics, but the kind where you’re both laughing and nobody needs to explain the joke. The better it gets, the more we talk. The more we talk, the better it gets.