Sé programar, pero no sabía nada de este reloj: una app GPS en ~7 conversaciones con una IA

Hoy tengo un reloj en la muñeca que hace exactamente lo que quería: graba mis rutas en la moto y en la montaña, me deja marcar puntos importantes con el botón físico sin sacarme los guantes, y me entrega cada ruta como archivo GPX para revivirla en el mapa.

Aclaración desde el arranque, porque acá todo el mundo es developer: sí sé programar. Llevo años escribiendo código en otras plataformas. Lo que NO tenía era la menor idea de este dominio: el SDK de Zepp OS, los caprichos del firmware, los límites físicos de un wearable. Y eso cambió todo el tipo de conversación que tuve con la IA.

El problema nunca fue el lenguaje

Cuando quise una app propia para mi reloj (grabar rutas, marcar puntos, exportar GPX), miré el camino clásico: SDK, JavaScript con módulos raros, emulador, certificados, QRs de developer. Nada de eso es difícil para alguien que programa — es largo y desconocido. El costo real no era programar la app: era estudiar una plataforma entera para una app que quizás use yo solo.

Así que invertí el flujo. En vez de primero estudiar la plataforma y después construir, fui directo a un loop de vibe coding donde el reloj en la muñeca era el único test de integración que importaba.

El flujo: describir, escanear, andar, repetir

El ciclo completo era simple de contar y adictivo de correr:

1. Describir el comportamiento en palabras de persona: "quiero marcar puntos con el botón, sin sacarme los guantes".
2. El agente escribe o ajusta el código y me devuelve un QR.
3. Escanear el QR con el teléfono: la nueva versión se instala en el reloj en un minuto. Sin cables, sin IDEs, sin builds manuales.
4. Andar. Salir con la app viva al contexto real: moto, guantes, sol en la pantalla, señal de verdad.
5. Volver con observaciones, no con hipótesis: "el check verde parpadea pero no hace nada", "esta pantalla no la miro nunca", "no me acuerdo qué hace este botón".
6. Y otra vuelta.

Cada vuelta terminaba en el reloj, no en el editor. El laboratorio era la vida real: la lluvia, el sol, los guantes, la prisa.

Y acá está lo que más me sorprendió: tras unas siete vueltas funcionó, y las specs que pedí el primer día seguían intactas. Ninguna iteración cambió la idea; todas cambiaron la implementación. No hubo feature creep, no hubo "lo hacemos genérico por si acaso". La spec la sostenía yo, y el código se ajustaba a ella — no al revés. Eso, en un proyecto de software, es una genialidad que se da pocas veces: el producto final es el que describiste, solo que ahora anda.

En esas vueltas aparecieron cosas que nunca estaban en el brief original: rótulos en el borde de la pantalla a la altura de cada botón físico (copiado del patrón de los relojes de aventura tipo Garmin), una lista de rutas de tarjetas que se frenan centradas como las apps nativas, un diálogo de salida propio (el del firmware se dibuja pero sus botones no responden — bug descubierto caminando, no leyendo), y la mejor decisión de todas: borrar una función de geocerca cuando me detuve a preguntar para qué servía. Borrar features también es iterar.

Mi rol: QA y specification, con un reloj en la muñeca

Terminé haciendo un trabajo que no sabía que existía con ese nombre: parte specification developer (escribir la spec en lenguaje humano y defenderla contra el feature creep), parte QA (romperla en la calle y reportar con precisión: qué pasó, dónde, con guantes o sin ellos).

Programé menos y dirigí más. Lo que sé de programar no se volvió inútil — cambió de rol. Me sirvió para acotar pedidos, pensar casos raros ("¿y si borro la ruta mientras graba?"), leer el código que llegaba con ojo crítico y describir síntomas exactos en vez de "no funciona". Pero ni mis años ni la IA vimos venir lo que el reloj me enseñó andando.

Lo que descubrí del reloj (y no estaba en ningún tutorial que yo fuera a leer)

El reloj no quiere que le hagas ciertas cosas, y saberlo temprano ahorra semanas:

• Las apps normales no pueden usar el GPS en segundo plano; si la pantalla se apaga, el sistema congela la app.
• Por eso, mientras graba, la app mantiene la pantalla encendida con trucos específicos de la plataforma.
• El brillo de pantalla no se puede fijar por software en este firmware: se fija a mano en ajustes.
• El reloj no tiene internet: para exportar, la ruta pasa por la app del teléfono y sale como enlace con el GPX.

Este es, para mí, el verdadero valor del ciclo: cada límite de plataforma fue una observación de la calle, no una semana de foros.

El resultado

Una app (le pusimos TrailHacker) que:

• Graba rutas con modo ahorro de batería (días de grabación con intervalos largos)
• Marca waypoints con el botón físico, sin mirar la pantalla
• Exporta cada ruta como GPX vía QR para abrir en gpx.studio, Google My Maps o Strava
• Se maneja completa con los 4 botones físicos, con rótulos en pantalla
• Tiene lista deslizable de rutas, confirmaciones donde importa y diagnóstico de señal cuando el GPS no engancha

Funciona en mi reloj. Eso es lo que cuenta.

Lo que me llevo de esta experiencia

• El cuello de botella era el dominio, no el lenguaje. Años de programar no me decían que este firmware congela la app al apagarse la pantalla. La IA amortiguó exactamente esa parte: comprimió "aprender un SDK de nicho" en conversaciones con mi reloj puesto.
• Las vueltas no son overhead: son el método. Cada observación de la calle valió más que una semana de documentación. Y las specs intactas al final del ciclo son la prueba de que el loop funciona bien: itera la implementación, no la idea.
• Preguntar "¿esto para qué sirve?" vale oro. La app mejoró más borrando una función que agregando tres.

El software como debería ser

Y acá está, creo, la puerta a algo más grande. Casi todo el software que existe se construye al revés: alguien adivina qué necesitan miles de usuarios, y los features se negocián con métricas. Este camino es el opuesto: una sola persona que sabe exactamente qué problema tiene y cómo lo quiere resuelto, con las herramientas para hacérselo.

La métrica también cambia. No es "¿lo van a usar mil personas?" ni "¿escala?". Es: ¿me funciona a mí? Si la respuesta es sí, el software ya cumplió su trabajo. Que le sirva a otro, que esté pulido, que se publique — todo eso es añadidura. La app de mi reloj no compite con nada ni con nadie: compite con la versión de ayer de sí misma y con mis ganas de usarla.

Creo que vamos a ver muchísimo software así: pequeño, rarísimo, perfectamente ajustado a una persona. El que te sigue a vos y no al mercado.

¿Esto es programar? Es programar con un traductor de dominio al lado y un laboratorio en la muñeca. La próxima vez que un SDK raro te frene una idea, probá el camino corto: describir, escanear, andar. Y sobre todo, preguntale a tu propia app qué parte no tiene sentido. ¿Vos qué le pedirías a tu reloj?