Hay algo que está pasando en el sector tecnológico que muy pocos quieren decir en voz alta.
Hoy, cualquier persona con acceso a un modelo de lenguaje y suficiente paciencia para escribir prompts puede construir una aplicación que funciona. Que pasa los tests básicos. Que cumple los requisitos del cliente en la demo. Que se despliega y responde.
Y eso, en apariencia, parece suficiente.
El problema aparece después. Cuando los usuarios reales llegan. Cuando el volumen se multiplica por diez. Cuando alguien con intención maliciosa busca una entrada. Cuando un auditor pregunta cómo se están tratando los datos personales. Cuando el sistema que «funcionaba» empieza a comportarse de formas que nadie anticipó porque nadie tenía la base para anticiparlas.
Ahí es donde la diferencia entre un ingeniero senior y alguien que sabe escribir prompts se hace visible. Y es una diferencia que puede costar muy caro.
El espejismo de la aplicación que «funciona»
Cuando evaluamos si una aplicación funciona, solemos mirar lo evidente: ¿responde a las peticiones? ¿devuelve los datos correctos? ¿la interfaz se ve bien?
Esos son los requisitos superficiales. Los que se ven en una demo, los que el cliente puede validar sin conocimiento técnico, los que una IA puede implementar correctamente siguiendo instrucciones precisas.
Pero por debajo de esa superficie hay una capa de requisitos que no aparecen en ningún briefing y que sin embargo determinan si una aplicación es viable en producción real:
¿Cómo se comporta bajo concurrencia? ¿Qué pasa cuando cien usuarios hacen la misma operación al mismo tiempo? ¿Hay race conditions? ¿Los locks están bien definidos? ¿La base de datos aguanta la carga o empieza a generar deadlocks?
¿Escala cuando el volumen se multiplica? Una arquitectura que funciona perfectamente con cien usuarios puede colapsar con diez mil. No porque esté mal construida en lo superficial, sino porque las decisiones de diseño que parecían razonables a pequeña escala no sostienen el crecimiento.
¿Es segura? No en el sentido de «tiene contraseñas», sino en el sentido real: ¿está protegida contra inyección SQL? ¿Los endpoints validan correctamente los inputs? ¿Los tokens de autenticación tienen el ciclo de vida adecuado? ¿Las dependencias tienen vulnerabilidades conocidas?
¿Cumple el RGPD y la normativa aplicable? El tratamiento de datos personales no es un detalle legal que se añade al final. Es una decisión de arquitectura que afecta a cómo se almacenan los datos, durante cuánto tiempo, quién tiene acceso, cómo se gestionan las solicitudes de eliminación, cómo se documentan los tratamientos.
Ninguno de estos requisitos aparece en la demo. Todos ellos aparecen en producción.
Por qué la IA no puede suplir esta base
Un modelo de lenguaje puede generar código correcto para un caso concreto. Lo que no puede hacer es tener en cuenta todo lo que no está explícitamente en el prompt.
Y el problema es que los requisitos no funcionales — resiliencia, seguridad, escalabilidad, cumplimiento normativo — raramente están en el prompt. No porque el que los escribe sea negligente, sino porque para incluirlos hay que saber que existen, entender sus implicaciones y saber cómo se traducen en decisiones de arquitectura concretas.
Ese conocimiento no se adquiere leyendo documentación. Se adquiere después de años de haber visto sistemas fallar bajo carga, de haber resuelto incidentes de seguridad a las tres de la madrugada, de haber tenido que explicar a un DPO por qué ciertos datos se estaban procesando de una forma que no cumplía con la normativa.
Es conocimiento encarnado en experiencia real. Y no hay prompt que lo reemplace.
Lo que aporta el ingeniero senior que la IA no tiene
Cuando un ingeniero senior trabaja con IA, no le pide que diseñe la arquitectura. Le pide que le ayude a explorar alternativas dentro de un marco que él ya entiende.
La diferencia es fundamental.
El ingeniero senior llega a la conversación con la IA con un conjunto de restricciones implícitas que guían cada decisión: sabe que este sistema va a necesitar escalar, que ese endpoint va a ser un vector de ataque potencial, que aquella decisión de modelo de datos va a crear problemas de rendimiento en seis meses, que el tratamiento de esos datos requiere una base legal explícita.
Esas restricciones no están escritas en ningún sitio. Están en su cabeza, construidas a lo largo de años de haber tomado decisiones técnicas y haber visto sus consecuencias.
Cuando alguien sin esa base usa la IA para construir lo mismo, genera código que parece equivalente pero que carece de esa capa invisible de consideraciones. El resultado funciona. Hasta que deja de funcionar.
El coste real de construir sin base técnica
No estoy hablando de casos hipotéticos. En los últimos dos años, con la democratización de las herramientas de IA para desarrollo, estamos viendo un patrón que se repite:
Equipos pequeños o individuos construyen sistemas que resuelven un problema real, los despliegan, empiezan a crecer, y en algún punto entre los primeros mil y los primeros diez mil usuarios algo se rompe de una forma que no es fácil de reparar.
A veces es un problema de rendimiento que requiere rediseñar la capa de datos desde cero. A veces es una vulnerabilidad de seguridad que expone datos de usuarios. A veces es una auditoría de cumplimiento que determina que el tratamiento de datos personales no tiene la base legal adecuada y que el sistema no puede seguir operando como está.
El coste de resolver estos problemas una vez que el sistema está en producción es órdenes de magnitud mayor que el coste de haberlos contemplado desde el diseño.
Y la ironía es que para haberlos contemplado desde el diseño no hacía falta necesariamente más tiempo. Hacía falta más base técnica.
Cómo usar la IA con la base técnica adecuada
La IA amplifica lo que ya sabes. Esa es su naturaleza.
Si tu base técnica incluye años de experiencia diseñando sistemas resilientes, la IA te ayuda a llegar más rápido a arquitecturas que ya sabes evaluar. Si tu base técnica no incluye esa experiencia, la IA te ayuda a llegar más rápido a arquitecturas que parecen correctas pero que tienen problemas que no sabes detectar.
El ingeniero senior que trabaja con IA bien tiene una práctica concreta: antes de aceptar cualquier decisión de diseño generada o sugerida por un modelo, la pasa por un checklist mental que ha construido con la experiencia:
¿Cómo se comporta esto bajo carga concurrente? ¿Qué pasa cuando esto falla? ¿Cuál es la superficie de ataque de esta decisión? ¿Cómo afecta esto al tratamiento de datos personales? ¿Esta decisión escala o me va a crear un problema en seis meses?
Esas preguntas no las hace la IA sola. Las hace el ingeniero que sabe que tiene que hacerlas.
Conclusión: la base técnica no es un punto de partida, es una ventaja competitiva
En un mundo donde cualquiera puede construir una aplicación que funciona, la ventaja competitiva del ingeniero senior no está en la velocidad de implementación. Está en la capacidad de construir sistemas que siguen funcionando cuando las condiciones cambian.
Resiliencia bajo concurrencia. Escalabilidad real. Seguridad que va más allá de los vectores obvios. Cumplimiento normativo integrado en el diseño.
Esos no son detalles técnicos. Son la diferencia entre un sistema que sobrevive al éxito y uno que colapsa justo cuando más lo necesita.
La IA ha democratizado la capacidad de construir. Lo que no ha democratizado es la capacidad de construir bien.
Y esa diferencia, en producción real, vale más que nunca
Llevo años tomando decisiones técnicas en entornos reales y aprendiendo de las que salieron mal. Cada semana comparto lo que voy viendo sobre arquitectura, IA y carrera técnica — sin filtros y sin los titulares que ya lees en todos sitios.
Si te quedas con ganas de más, nos vemos en la newsletter