Desarrollo Guiado por la Mesa

La Brecha

Soy un ingeniero de software estadounidense. Victor es un ingeniero de telecomunicaciones colombiano jubilado. Él solo habla español. Yo solo hablo inglés.

Llevamos ocho años siendo familia. Me casé con su hija Valentina y nos hemos arreglado como lo hacen las familias — alguien traduce, alguien hace gestos, alguien se ríe en el momento equivocado y espera que nadie se haya dado cuenta.

Crecí siendo el niño monolingüe en un mundo multilingüe. Es una historia larga, pero la gente con la que crecí venía de todas partes. El inglés siempre fue el hilo común.

Victor y yo nos podemos arreglar para una ida al mercado con contexto y buena voluntad. Pero una conversación de verdad — esa donde alguien está siendo gracioso o contando una historia que solo funciona si captas el momento — siempre ha necesitado a alguien en el medio. Cuando no hay nadie disponible, uno de los dos simplemente se queda ahí. A veces es Victor. A veces soy yo. Ocho años de eso.

La Mañana de la Boda

Hace menos de dos semanas, Andrea, la hermana de Valentina, se casó en una cabaña hermosa en el bosque a las afueras de DC. La mayoría de los invitados hablaban español; el resto eran parejas que no. El sábado por la mañana, Andrea y el grupo de la boda ya no estaban — peinado, maquillaje, estrés — y a Victor y a mí nos pasaron una lista de mandados. Nadie tenía tiempo de traducir. Estábamos solos.

En mi trabajo presiono bastante los pipelines de IA. Sé de lo que son capaces estas herramientas. Parado ahí mirando el día por delante, pensé: puedo construir algo que funcione bien para nosotros dos. No un proyecto de investigación. Solo: necesitamos comunicarnos hoy. Construí un prototipo.

Funcionó — lo usamos toda la mañana, logística de mandados y todo, hablando de verdad sin alguien en el medio. Entonces le dije a Victor que me iba a cepillar los dientes, y el prototipo decidió que la higiene dental constituía consejo médico. Se negó. Estábamos en nuestros trajes, y lo único que quedaba por traducir era “salgamos de aquí”.

Ese fue el momento: no necesitaba un envoltorio alrededor de la IA de otra persona. Necesitaba mi propio pipeline — uno que no tuviera opiniones sobre tu rutina matutina.

Empecé a construir Óyeme — hear me en español — en el vuelo de regreso. Una sola frase fluye por tres servicios en pocos segundos. Uno transcribe, otro traduce, un tercero habla. Algunos problemas de ingeniería interesantes en las costuras.

Recibimos a sus papás en Salt Lake la semana después de la boda — el entorno de prueba perfecto — usuarios reales, conversaciones reales, todos los días.

Equipo

Óyeme tiene un tablero de desarrollo dentro de la app. Es multilingüe — dictas una idea para una función o un reporte de error en tu idioma, y la app lo traduce para todos.

Cuando algo sale mal, Sandra o Victor usan su teléfono para dictar qué pasó y cómo debería funcionar en cambio. Pasa por una pequeña limpieza y crea una traducción para que yo la escuche y la vea. Esa entrega arranca el pipeline que se describe abajo.

Valentina le explicó el pipeline a Victor y a Sandra desde temprano. Sus ideas pueden convertirse en funciones. La app puede convertir lo que enviaron en una tarea, escribir el código y construir una nueva versión — todo antes de que terminen la cena.

Sandra resultó ser la contribuyente más prolífica del tablero de desarrollo. Más entregas que cualquiera, yo incluido. Dejó de ser mi proyecto bastante rápido.

La familia habla costeño — español caribeño colombiano, cargado de jerga, consonantes que se caen, y giros que despistan a los traductores de propósito general.

Aparte, hay un family_glossary en la base de datos: nombres, lugares, mascotas, chistes internos — los nombres propios y los términos específicos de la familia que el traductor siempre debe preservar tal cual. Lo mantenemos nosotros mismos a través de un flujo de inscripción, y se inyecta en cada prompt de traducción.

Pipeline

Esta es la parte que me hizo replantear qué significa “desarrollo”.

Una idea que Victor o Sandra dicta en su teléfono — en español, mientras comen, a media conversación — puede convertirse en un pull request mergeado sin que yo escriba una sola línea de código. No una solicitud de función que se queda en un backlog. Un PR, con una rama, un diff, un deploy de preview.

Reviso cada PR antes de que salga — simplemente entro a la sesión del agente desde mi teléfono, lo guío si necesita trabajo, o lo mergeo si está bien.

Todo el sistema corre en la nube. Pero el camino de “a Victor le pareció que la traducción fue muy formal” a “aquí hay un PR que ajusta el registro del system prompt” es totalmente autónomo.

La arquitectura:

development board (phone)
 ↓ 
Database INSERT
 ↓ 
Database webhook → /api/pipeline/trigger 
 ↓ 
Intake Routine (Claude Code, headless) 
 ↓ 
GitHub Issue (structured spec) 
 ↓ 
Build Routine (Claude Code, headless)
 ↓ 
Pull Request + Preview Deploy
 ↓ 
Logan & fam reviews from phone (merge or steer)
 ↓ 
pr-merge webhook → idea status = "done"

El trigger:

Cuando una idea nueva aterriza en la tabla ideas, un trigger de la base de datos dispara un HTTP POST al endpoint /api/pipeline/trigger de la app. El endpoint valida la solicitud y arranca la rutina de intake. (En la práctica, lo tengo configurado para requerir aprobación manual; algunas ideas necesitan triage humano primero. El throughput de Victor es más alto de lo que uno esperaría.)

La rutina de intake:

Esta es una Claude Code Routine, una sesión headless de Claude que corre en la infraestructura de Anthropic. Recibe la idea cruda (en el idioma que el usuario haya enviado) y hace cinco cosas:

1. Lee el codebase entero (CLAUDE.md, el árbol de archivos, las definiciones de personas)
2. Busca issues duplicados vía la API de GitHub
3. Lee los archivos que más probablemente se vean afectados por la idea
4. Refina la idea cruda en una spec estructurada para el issue de GitHub (user story, criterios de aceptación, archivos afectados, límites de scope, contexto de persona)
5. Crea el issue y dispara la build routine

La build routine:

Otra Claude Code Routine, también headless. Recoge el issue estructurado y hace la implementación de verdad:

1. Research: lee a fondo cada archivo en las áreas afectadas por la spec, revisa el historial de git, identifica casos borde, y publica un comentario de research en el issue con su plan de implementación
2. Build: crea una rama de feature, implementa los cambios con commits convencionales, y abre un PR
3. Verify: corre npm run build. Si falla después de tres intentos, publica la salida del build como comentario del issue y se detiene

Cuando mergeo un PR, un webhook de GitHub actualiza el estado de la idea en el tablero en tiempo real. Victor puede ver cómo su idea pasa de “building” a “done” sin refrescar la página.

La Cena de Despedida

El modo mesa llegó más tarde en Salt Lake. Todos hablan, la app organiza quién dijo qué, y cada persona recibe su propia traducción. Todo el mundo tiene que bajar un poquito la velocidad, lo cual en una mesa colombiana es una negociación constante. Solo texto por ahora — cinco streams de TTS compitiendo por un solo parlante de teléfono es un problema que aún no hemos resuelto.

La noche antes de que se fueran, hicimos esa cena en la que uno se esmera cuando no sabe cuándo volverán a estar todos en la misma mesa. El teléfono quedó en el centro corriendo el modo mesa. Victor contó una historia y yo cacé el remate sin esperar a que alguien se voltee a explicármelo.

Loop

Estamos construyendo una manera de que la app aprenda de las correcciones a media conversación — sin menú, sin escribir, solo hablándole.

Lo de construir software con tu familia es que el feedback es honesto de una manera que ningún proceso de product review va a igualar. Victor no sabe qué es un sprint, pero en este caso realmente no le hace falta. Cuando vea que la app dijo “camello” cuando él quiso decir “trabajo duro” — se lo va a decir a la app — y eso no va a volver a pasar.

Esperaba construir una herramienta útil y sentirme bien por resolver un problema familiar. Lo que no esperaba era que mis suegros se convirtieran en mis colaboradores más comprometidos — que Sandra me ganara en el tablero de desarrollo, que Victor ayudara a darle forma al modo más usado, que toda la familia le hablara a la app sobre la app como si fuera un invitado a cenar un poco lento que tiene buenas intenciones.

Por ocho años, Victor y yo nos hemos comunicado a través de otras personas. Esta semana pasada, tuvimos conversaciones de verdad — no logística, sino del tipo donde los dos se ríen y nadie tiene que explicar el chiste. Mientras mejor funciona, más hablamos. Mientras más hablamos, mejor funciona.