Cómo la IA cambió mi forma de programar (y no fue como esperaba)

Llevo más de 7 años construyendo sistemas para bancos, aseguradoras y empresas en Panamá. He migrado más de 500,000 registros, armado arquitecturas serverless con 45+ Lambdas en producción, y procesado contratos con IA para 15 instituciones financieras. Lo digo no para presumir, sino para dar contexto: no soy alguien que acaba de descubrir la programación. Y aún así, la IA cambió completamente cómo trabajo.

Pero no de la forma que la mayoría piensa.

---

Ya no empiezo por el código

Antes, mi proceso era el clásico: abrir el IDE, crear carpetas, instalar dependencias, empezar a picar código. Pensar la arquitectura en la cabeza mientras avanzaba. Funcionaba, pero era lento — y mucho del tiempo se iba en boilerplate, configuración repetitiva y resolver cosas que ya había resuelto antes en otros proyectos.

Hoy mi primer paso es completamente diferente: escribo documentación antes que una sola línea de código.

Sí, documentación. El dev que antes evitaba documentar ahora lo hace primero. La ironía no me pasa desapercibida.

---

El cambio real: contexto antes de código

El mayor shift no fue pedirle a una IA que escriba código por mí. Fue entender que la calidad del output depende directamente de la calidad del contexto que le das. Si le dices "hazme un CRUD de gastos", te genera código genérico que terminas reescribiendo. Si le das el contexto de tu proyecto, las relaciones entre entidades, las reglas de negocio y los estándares de diseño, el resultado es otro.

Eso me obligó a estructurar lo que antes vivía solo en mi cabeza.

Ahora, antes de tocar código, creo archivos de contexto: qué hace el proyecto, cómo está estructurado, qué decisiones arquitectónicas tomé y por qué, los contratos de API, el sistema de diseño. Le doy a la IA — y a mi yo del futuro — un mapa completo del terreno.

---

La estructura que lo hace funcionar

Antes de escribir una línea de código, mi proyecto ya tiene algo así:

No es sobre tener muchos archivos. Es sobre tener contexto claro y reutilizable. Escribes el una vez y cada prompt que hagas después ya tiene el 80% del contexto resuelto. Los skills evitan que la IA genere código genérico. Los templates de prompts evitan que tú escribas prompts genéricos.

---

Mi flujo actual paso a paso

1. Defino el contexto por escrito. Arquitectura, stack, decisiones técnicas, diseño. Todo en markdown, todo versionado. Esto no es documentación formal para un cliente — es el cerebro del proyecto. 2. Creo skills reutilizables. Templates con patrones que ya sé que funcionan: cómo estructuro un módulo backend, cómo armo un componente frontend, qué validaciones siempre incluyo. Cuando he construido 20+ APIs para bancos, ya sé qué patrón funciona. Lo documento una vez y la IA lo replica consistentemente. 3. Escribo prompts estructurados, no improvisados. En vez de improvisar cada vez, uso templates donde lleno los blancos. El prompt siempre incluye tres cosas: qué existe (contexto), qué necesito (objetivo), y cómo lo quiero (restricciones). Sin eso, la IA adivina. Y adivinar no escala. 4. Itero por módulos completos. Backend primero, frontend después. Cada módulo sale con validaciones, estados de carga, manejo de errores y diseño consistente desde el día uno. No "lo arreglo después" — sale completo o no sale.

---

Los prompts que realmente uso

No voy a darte una lista de prompts mágicos porque no existen. Pero sí hay patrones que funcionan consistentemente:

Para arquitectura (antes de todo): Le doy a la IA el mapa completo — stack, estructura de carpetas, convenciones de naming, restricciones del proyecto. Este es el prompt más importante porque define todo lo que viene después. Para features con contexto: Referencio lo que ya existe. Si ya tengo un módulo de usuarios bien implementado, le digo "sigue ese patrón". La consistencia mata la deuda técnica. Para corrección: Describo el síntoma, doy el contexto del framework y versión, y pido la corrección específica. Nada de "dame 5 alternativas" — necesito la solución. Para validación: Antes de implementar, valido decisiones técnicas. "Estoy pensando en usar X para este caso de uso, ¿qué problema no estoy viendo?" Este tipo de prompt me ha ahorrado semanas de refactorización.

---

Lo que realmente cambió

No es que programe menos. Es que programo diferente. Mi energía va a decisiones de diseño, trade-offs técnicos y validación — las partes que realmente importan. El boilerplate, los patrones repetitivos, la configuración inicial... eso dejó de ser mi problema.

Proyectos que antes tomaban semanas de scaffolding ahora arrancan en horas con una base sólida. No perfecta — siempre hay ajustes — pero consistente, bien estructurada y con estándares desde el inicio.

Cuando trabajé en la migración de 500K+ registros que otros developers no pudieron completar en 8 meses, no fue porque escribí más rápido. Fue porque entendí la arquitectura del problema primero. La IA amplifica exactamente eso: el criterio técnico que ya tienes.

---

La ironía

Para usar bien la IA, tuve que volverme mejor arquitecto. Documentar para la IA me obliga a justificar cada decisión. Y cuando no puedo justificar algo, es señal de que necesito repensarlo.

No puedes delegar lo que no entiendes. Si no sabes por qué elegiste NestJS sobre Express, o por qué usas multi-tenant con schemas separados, la IA tampoco va a tomar esa decisión bien por ti.

La IA no cambió qué construyo. Cambió cómo lo construyo. Y el secreto no está en el prompt perfecto, sino en tener claridad absoluta de lo que quieres antes de pedirlo.

---

¿Necesitas migrar sistemas legacy o arquitectura cloud para tu empresa? Hablemos.