Articulo
De bocetos a arquitectura: como uso la IA como dialogo de decisiones
En vez de pedir codigo desde el minuto uno, uso la IA como sparring para tensionar supuestos: flujo, interaccion, datos, modelo relacional y sincronizacion.
Empece con algo que, sobre el papel, parece suficiente para arrancar: unas pantallas generadas por IA. No eran un producto, ni un estudio de UX, ni un diseno definitivo. Eran un punto de partida visual para pensar.
La primera pregunta importante fue precisamente esa: estoy mirando una app o estoy mirando una inspiracion que puede confundir mas que ayudar?
Ese fue el tono del proceso desde el minuto uno: no pedir codigo, sino poner a prueba supuestos. En vez de saltar directamente a implementar, empece a usar la IA como sparring tecnico.
1) Del se ve bien al que flujo real hay detras?
Lo primero que chocaba era que en un mismo conjunto de pantallas se mezclaban conceptos: tarjetas sueltas, listas, lecciones con subniveles, estados, metricas. Todo a la vez.
Eso suele pasar cuando se parte desde UI: visualmente se entiende, pero conceptualmente no esta resuelto.
La idea que se impuso no fue mas funcionalidad, sino menos friccion: una estructura pequena y estable, con jerarquia minima que se sostenga con el tiempo.
- Tiene sentido tener tantos niveles?
- Que jerarquia usarias para que el usuario no se pierda?
- Si el usuario necesita orden, no hay que decorarlo con capas: hay que definir pocas piezas y que encajen siempre.
2) Interaccion: cuando lo guay compite con lo claro
Una vez el flujo conceptual empezo a tomar forma, aparecio una duda que parece pequena pero cambia la experiencia: como navega el usuario durante el estudio?
La tension real era moderna vs clara: gestos de arrastre, swipes para marcar resultado, flip por tap o por gesto, etc.
En experiencias de estudio, el usuario no quiere aprender una UI; quiere concentrarse. La decision fue reservar el gesto para la accion mas natural (voltear) y usar botones para la parte que exige intencion (evaluar).
- Que se entiende sin explicar nada?
- Que reduce errores?
- Que se siente sereno y no juego?
3) El salto de madurez: persistencia y export/import
Hasta aqui, todo podia seguir siendo diseno. El salto real llego con una pregunta basica que se olvida en prototipos: si esto se ejecuta en web, que pasa con los datos? Se pierde todo al refrescar?
Ese momento subio el nivel: ya no era UX, era sistema. Empezamos a hablar de donde viven realmente los datos y como se guardan sin depender de la red.
Aparecio la idea de exportar/importar como cinturon de seguridad: no como sustituto del cloud, sino como herramienta de control para probar sin miedo.
- Persistencia local en web.
- Que tecnologias encajan con movil y navegador.
- Como evitar perderlo todo por accidente.
4) Cercano al final: modelo de datos relacional desde el principio
En esa fase mi interes ya no era lo mas rapido. Era lo que no me obligue a rehacer todo.
Por eso insisti en pensar en entidades y relaciones desde el principio: aunque el storage local sea distinto, el pensamiento relacional reduce arrepentimiento cuando luego hay backend serio y analitica.
- Entidades con IDs.
- Relaciones claras.
- Timestamps.
- Borrado logico (soft delete).
- Historial de cambios.
5) Backend y sincronizacion: el V1 ya es diseno distribuido
Despues llego la decision que convierte cualquier app en sistema real: sincronizacion. No queria depender de exportar/importar para cambiar de dispositivo; queria entrar y seguir.
Sync no es un endpoint. Es una estrategia de datos: como marcas cambios, como resuelves conflictos, como borras sin romper y como haces sincronizacion incremental.
El enfoque inicial fue pragmatico: timestamps + soft delete + last-write-wins. No es la solucion mas academica, pero es una base estable que funciona y permite evolucionar.
- Dos mundos: todo en nube vs offline-first con sync.
- Offline-first aguanta mala red, viajes y sesiones cortas.
- Last-write-wins como base simple para conflictos.
6) Operacion: administrar la base de datos sin exponerla
Cuando decidi alojar la base de datos en mi servidor aparecio una pregunta operativa: como la administro sin abrir puertos peligrosos?
Este es el punto donde muchos prototipos fallan: disenan arquitectura, pero no el dia a dia. Y ese dia a dia es lo que diferencia funciona en mi maquina de puedo mantenerlo sin miedo.
- No exponer el puerto de la base de datos.
- Usar tuneles SSH o VPN.
- Administrar con herramientas cliente.
- Disenar backups desde el inicio.
7) Decision log en conversacion (ADR en la practica)
Si tuviera que resumir el patron, no es pregunte y me respondieron. Es un bucle de propuesta, opciones, presion en el punto debil y decision por trade-offs.
Esto se parece mucho a lo que en ingenieria se formaliza como decision logs (ADR): capturar contexto, opciones y consecuencias. Aqui lo hicimos conversando, pero el espiritu es el mismo.
- 1. Yo proponia una idea.
- 2. La IA devolvia opciones y consecuencias.
- 3. Yo apretaba en el siguiente punto debil.
- 4. La decision salia despues de comparar trade-offs.
La IA no me dio la solucion. Me ayudo a acelerar lo mas valioso: el analisis de decisiones.
La calidad no vino de escribir rapido, sino de insistir con las preguntas correctas: que flujo es real, que interaccion reduce friccion, donde viven los datos, que modelo evita rehacer, como sincronizo sin complicarme y como opero el sistema en produccion.
Si iteras asi, la implementacion llega con el terreno preparado. Y cuando por fin le pidas a una IA construye, ya no estas improvisando: estas ejecutando un plan.