Development System Map
La mayoría de aplicaciones fallan antes de existir.
Fallan en el momento en que alguien decide empezar a construir.
Núcleo
No empiezo una aplicación escribiendo código. Empiezo intentando entender qué sistema estoy a punto de tocar.
La IA no actúa como copiloto creativo. Actúa como instrumento de análisis.
El objetivo no es acelerar, es reducir ruido.
Investigación
Este es el punto de entrada real del sistema. La UI todavía no existe.
Pido a la IA que lea el mercado por mí. Analizo las aplicaciones más conocidas del dominio y fuerzo la extracción de patrones: características relevantes, decisiones repetidas y fricciones reales. No busco respuestas rápidas, busco contexto.
Herramientas habituales: NotebookLM, Gemini o ChatGPT en modo de investigación profunda.
El resultado no es inspiración. Es una lista de características que no puedo ignorar si quiero que el sistema tenga sentido.
Diseño (opcional)
Con esa lista, a veces genero un diseño preliminar. No para validarlo visualmente ni para enamorarme de él, sino para materializar el sistema en espacio.
Uso herramientas como Stitch para generar una UI basada en las características detectadas. Suelen producir diseños limpios, incluso atractivos, pero ese no es el objetivo.
El diseño aquí funciona como mapa, no como destino.
MVP
Cuando el sistema ya está definido, construyo el primer artefacto funcional.
En Google AI Studio introduzco el contexto completo, las características obligatorias y las restricciones reales. Si la aplicación necesita chat, mapas, modelos ligeros u otros componentes del ecosistema Google, este es el momento de integrarlos. Aquí ya trabajo con APIs y claves desde el inicio.
El resultado es un MVP descargable. No es elegante. No es final. Pero funciona.
Desarrollo
El código generado no se acepta tal cual.
Lo importo en Google Antigravity y empiezo a iterar: corregir, simplificar y entender el sistema. En esta fase la IA deja de generar y pasa a actuar como interlocutora técnica. No dicta, acompaña.
Cuando el proyecto empieza a estabilizarse, lo conecto con GitHub. A partir de ahí el sistema adquiere memoria y control de versiones.
Datos y autenticación
Si el sistema necesita usuarios o persistencia, uso Supabase.
No multiplico infraestructura sin motivo. Reutilizo proyectos gratuitos y separo aplicaciones por convención, no por proyecto. Tablas con prefijos o sufijos distintos: usuarios_inversion, usuarios_deporte, activos_inversion, partidos_deporte.
No es una solución académica. Es una solución que escala lo suficiente y reduce coste cognitivo.
Auditoría
Antes de desplegar, asumo que el sistema tiene fallos.
Conecto Codex u otra IA a GitHub y le pido que lea el proyecto como un tercero hostil, buscando vulnerabilidades, malas prácticas y puntos débiles evidentes. El resultado no se discute: se devuelve a Antigravity y se corrige.
Este bucle aporta más valor que cualquier checklist manual.
Despliegue
El despliegue es una consecuencia, no un hito.
Uso Vercel para importar el repositorio desde GitHub, configurar variables de entorno y, si tiene sentido, conectar dominio. Desde ese momento cada commit es un cambio real. El sistema deja de ser local. Empieza a existir.
La IA acelera, sí.
Pero solo funciona bien cuando el sistema ya estaba pensado.El código vino después.
Como siempre.