Empecemos por lo honesto: la IA democratizó el prototipado. Hoy cualquier persona con una tarjeta de crédito y una tarde libre puede abrir un chat, pedirle a un modelo que escriba un CRUD con login y dashboard, y tenerlo corriendo antes de la cena. Eso es real. Y, en buena medida, es una noticia excelente.
Significa que las ideas se pueden probar sin pedir un presupuesto. Que un equipo de operaciones puede hacer su propia herramienta interna en lugar de esperar seis meses al área de sistemas. Que un fundador puede validar un flujo con tres clientes antes de buscar inversión. Eso mueve al mundo hacia adelante.
La pregunta interesante no es si la IA sirve — sirve. Es qué pasa después de la tarde del prototipo.
Donde se rompe la ilusión
La distancia entre un prototipo que funciona en la demo y un sistema que una empresa puede operar durante años es enorme. No un poco más grande. Enorme.
El prototipo se rompe cuando lo usan dos personas a la vez. Cuando alguien intenta inyectar SQL por un campo. Cuando el disco se llena. Cuando hay que migrar la base de datos sin apagar el servicio. Cuando un usuario necesita permisos que otro no tiene. Cuando el cliente pide un reporte que requiere leer tres años de historia. Cuando hay que auditar quién hizo qué y a qué hora. Cuando una integración de pagos responde lento y todo lo demás se atora. Cuando alguien activa una regla de compliance que obliga a borrar datos personales en 30 días.
Nada de eso aparece en el prompt que te armó el CRUD. Y nada de eso es opcional si el sistema va a sostener trabajo real.
Hay una frase que usamos internamente: un prototipo se juzga por lo que hace; un producto se juzga por lo que no hace mal cuando nadie está mirando. Son dos disciplinas distintas.
La IA multiplica lo que ya eres
Es tentador pensar en la IA como un reemplazo de criterio. No lo es — ni lo será pronto. Es un multiplicador de fuerza.
Si quien la dirige entiende arquitectura, la IA le acelera la arquitectura. Si quien la dirige no entiende concurrencia, la IA le acelera los bugs de concurrencia. Si quien la dirige no conoce el dominio del negocio, la IA le acelera la cantidad de suposiciones incorrectas codificadas en forma de feature.
Un modelo grande escribe un try/catch perfecto. Lo que no hace es decidir qué errores vale la pena capturar, cuáles hay que propagar y cuáles son síntoma de que la arquitectura está mal. Esa decisión no está en los pesos del modelo; está en haber vivido el incidente.
El valor del orquestador
El trabajo que sigue siendo escaso — y creemos que va a volverse más escaso, no menos — es el de quien dirige. Quien decide:
- Qué no construir. Casi la mitad del valor que entregamos a clientes es talarles la lista de features.
- Qué abstraer y qué dejar duplicado. Abstracciones prematuras envejecen peor que código repetido.
- Cuándo borrar código. El código que no existe no tiene bugs.
- Cuándo decirle no al cliente, con argumentos, sin perder la relación.
- Cómo particionar los datos desde el principio para no pagarlo al triplicar usuarios.
- Cuándo usar SQL, cuándo un documento, cuándo un SaaS ya resuelve el 90% y no hay que construir nada.
El LLM no toma ninguna de esas decisiones. Las ejecuta rápido después de que alguien con criterio las tomó.
Lo que se rompe a los seis meses
Cuando alguien salta el oficio — construye un sistema completo con IA sin alguien experimentado leyendo y dirigiendo — las grietas no aparecen el día del lanzamiento. Aparecen a los seis o doce meses. Es por eso que son tan caras: cuando aparecen, ya hay usuarios, datos y dependencia operativa.
El guion es siempre parecido. Un incidente de producción que nadie puede diagnosticar porque no hay logs estructurados ni nadie entiende el flujo real. Un cambio pequeño — “solo agrégame un campo” — que rompe diez cosas porque toda la lógica está entrelazada. Un login comprometido porque el manejo de sesiones era lo que generó el bot la primera iteración y nadie lo revisó. Performance que se degrada sin explicación porque las consultas no están indexadas y nadie previó lo que pasaría al llegar a 100 mil registros. Una integración que dejó de funcionar porque el proveedor deprecó un endpoint y el código lo usa en ocho lugares, no en uno.
Ninguno de estos problemas es culpa de la IA. Son los problemas normales de construir software. Solo que antes alguien con canas los veía venir y ahora muchas veces no hay nadie mirando.
Qué vende realmente una agencia con experiencia
Si uno mira por encima, parece que una agencia vende horas de código. Si uno mira con cuidado, vende otra cosa: juicios.
Cuáles problemas vale la pena automatizar y cuáles se resuelven mejor cambiando un proceso. Qué stack va a sobrevivir tres años de cambios y cuál va a estar abandonado en seis meses. Cómo escribir pruebas que realmente atrapen regresiones — no pruebas que suban la cobertura a 80% y no prueben nada útil. Cuándo parar de iterar en una feature porque ya está suficientemente buena. Cuándo decir “esto no necesita software, necesita que dos equipos se pongan de acuerdo en una junta”.
Experiencia, en este oficio, no es haber leído qué podría romperse. Es haber visto qué se rompe en producción, a qué hora, y qué se siente estar del otro lado del teléfono. Eso no se sustituye con prompts.
Cómo usamos la IA en Calaverita
Para que no suene a que estamos contra la herramienta: no lo estamos, la usamos todo el tiempo. Aceleramos bootstrapping, escribimos tests, generamos migraciones, exploramos diseños, leemos logs a velocidad imposible. Es genuinamente más productivo.
La regla, sin embargo, es simple: nunca dejamos entrar a producción código que nadie haya leído con criterio. La IA acelera; el criterio decide. El código generado se revisa, se cuestiona, se borra cuando sobra, se reemplaza cuando hace suposiciones que no aplican al dominio. El resultado son entregas más rápidas sin sacrificar la durabilidad — que es, al final, lo que nos paga el cliente.
No usamos la IA para escribir menos; la usamos para pensar mejor con menos fricción. Es una distinción sutil y hace toda la diferencia.
Una regla honesta para cerrar
Si el sistema que está pensando construir tiene que sostener dinero, datos sensibles, o el trabajo diario de más de tres personas, la pregunta útil no es “¿puede la IA construirlo?”. La respuesta es obvia: una parte sí, una parte no, y nadie lo sabe por adelantado.
La pregunta útil es otra: ¿quién se va a parar frente al incidente del miércoles a las 3 de la mañana? Alguien lo va a tener que hacer. Y esa persona — o ese equipo — necesita haber estado ahí antes. Necesita reconocer el olor a fuga de memoria, el patrón de un índice que falta, la forma en que un bug reportado por el usuario significa otra cosa distinta a lo que dice.
Esa experiencia no se prototipa en una tarde. Se acumula proyecto por proyecto, incidente por incidente, decisión por decisión. La IA la hace más productiva. No la reemplaza.
TL;DR — la IA bajó a cero el costo de prototipar y no bajó nada el costo de operar. Construir con un LLM es barato; sostener lo construido durante años no lo es. La agencia que sigue valiendo la pena es la que pone criterio antes que volumen — la que decide qué no se construye, lee el código que el modelo escribió, y se queda cuando algo sale mal. Si su proyecto tiene consecuencias reales, contrate a alguien que ya haya visto las consecuencias.