Con IA, el profesional mediocre se nota más (y es peligroso)

La IA no convierte a nadie en buen profesional. Lo hace más rápido en lo que ya es. Lo comprobé la semana pasada: quise conectar agentes de IA al sistema de gestión de una empresa cercana y descubrí que AWS iba a apagar su servidor en seis días, que sus documentos vivían en una carpeta temporal y que el respaldo diario generaba archivos vacíos. Varias empresas externas pasaron por ese código y ninguna lo vio.

Siempre creí que cualquier informático con IA iba a ser casi un dios. Alguien capaz de sacar el trabajo de un equipo entero, varias cosas al mismo tiempo.

Lo de hacer el trabajo de un equipo entero, lo confirmé. Lo de que cualquiera se vuelve bueno, no. Con IA se puede hacer muchísimo trabajo en paralelo, pero eso no convierte a nadie en bueno. El bueno sigue siendo bueno. El “meh” sigue siendo “meh”. Y el mediocre se vuelve un peligro, porque ahora produce más rápido el mismo descuido.

Lo encontré por casualidad

El martes 29 de septiembre de 2026 quería hacer algo simple: un MCP, que es un conector para que agentes de IA puedan usar un sistema, para el sistema de gestión de una empresa cercana. Cotizaciones, clientes, stock. Ayudar con el día a día.

Para conectarlo tuve que mirar cómo estaba montado el sistema. Ahí empezó todo.

El servidor que lo corre era una máquina EC2 (un servidor virtual de AWS) sobre una imagen de Ubuntu 16.04 de octubre de 2016. AWS tenía programado apagarla el lunes 5 de octubre por hardware degradado.

La base de datos, un MySQL 8.0 en RDS, se quedó sin soporte estándar el 31 de julio. La alerta decía que podía dejar de funcionar en cualquier momento si no se pagaba el soporte extendido. No se había pagado.

Y ese mismo martes vi que la base de datos y el acceso SSH del servidor estaban abiertos a todo internet. Los cerré esa tarde.

El sistema que sostiene la empresa tenía fecha de muerte y nadie lo sabía.

El plan “fácil”

Lo primero que pensé fue: esto sale rápido. Migro la aplicación a contenedores en ECS, la base de datos a Aurora Serverless v2, y queda escalable, con poco esfuerzo de mantención y años de vida por delante.

No podía estar más equivocado.

Este sistema tiene historia conmigo. Lo partí yo entre 2011 y 2012, como un sistema de cotizaciones e inventario, en una época en que ningún SaaS cubría lo que la empresa necesitaba. Con los años creció hasta volverse su CRM y ERP, y hace unos diez años empezó a facturar. Hoy existen alternativas mejores, que no hay que mantener y que dan soporte premium. Pero esa es otra conversación.

Corre en Yii2, un framework de PHP al que le tengo un respeto enorme. Entre 2012 y 2017 escribí doce artículos sobre Yii en este blog, desde cómo correrlo en Amazon hasta cómo autenticar una API REST. Cuando se sabe usar, funciona increíble. El problema es que en los últimos seis años nadie que pasó por ese código se dio el tiempo de entender lo que estaba haciendo.

Lo que encontré: código fuera de Git, documentos en /tmp y backups vacíos

Cada día salía un conejo nuevo del sombrero, y cada uno peor. Estos son los que más me dolieron.

El código de producción no estaba en Git. El último commit era de noviembre de 2020. En el servidor había 319 archivos PHP modificados y 93 nuevos que no existían en ningún repositorio. Seis años de cambios vivían solo en esa máquina. Si AWS la apagaba, se perdían.

Los documentos de la empresa vivían en /tmp. 212.869 archivos, casi 20 GB: 36 mil PDF, 21 mil XML tributarios y 154 mil imágenes y diseños. Cotizaciones, facturas, fichas. La carpeta temporal del servidor era, en la práctica, el archivo de la empresa. Con el disco al 92%.

El respaldo diario no respaldaba nada. Encontré 401 archivos de backup de 0 bytes. El script buscaba una base de datos local que no existía y una librería de compresión que no estaba instalada. Nunca revisó si había funcionado, y los errores se mandaban a un correo que el servidor no podía enviar.

Todos entraban con la misma llave. El servidor se administraba con una sola llave SSH, creada en 2012, con permisos de administrador. La usaron todos los de TI y todos los desarrolladores que pasaron en los últimos diez años. Cualquiera de ellos podía seguir entrando al código y a la base de datos. Esto fue lo que más me enojó. Ya la revoqué. La única máquina que todavía la usa es el servidor de contingencia, que ya no acepta conexiones desde internet y que espero eliminar esta semana.

Debug encendido en producción y un phpinfo() público mostrando la configuración del servidor a quien quisiera verla.

Facturación con doble emisión. El módulo informa éxito aunque falle el registro interno, y un reintento puede volver a emitir un documento que el proveedor de facturación ya aceptó. Las personas que usan el sistema me confirmaron que a veces pasaba. Es muy poco probable, pero pasa. Y un doble clic creaba dos cotizaciones.

Doce scripts sueltos conectados directo a la base de datos, fuera del framework y con credenciales escritas en el código. Los descubrí cuando intenté apagar la base vieja y no pude.

Terminé la semana con 131 issues abiertos entre dos repositorios y un inventario de 316 activos que nadie había documentado.

Los que cobraron por esto

Por este código pasaron varias empresas externas, algunas reconocidas. Desarrollo, “continuidad operacional”, soporte. Cobraban precio de mercado de un buen desarrollador.

Ninguna vio esto. O lo vio y se hizo la idiota. No sé qué es peor.

En junio escribí que al mediocre lo identificas en la primera semana. Acá pasaron seis años sin que nadie lo hiciera. Y quien lo detectó no fue alguien de la empresa: yo no trabajo ahí, no estuve en esos seis años y sigo sin estar. Me metí para ayudar.

Estoy molesto y no lo voy a esconder. Hacer las cosas bien no es difícil. Un commit, un backup que alguien verifica, no guardar facturas en /tmp. No hace falta ser un genio, solo querer hacerlo bien. Y les pagaron para eso.

Me tuve que comer el orgullo

Desde el miércoles le dediqué todo el tiempo que pude. El plan de migrar todo a ECS no alcanzó.

Cómo quedó:

• La base de datos está en Aurora Serverless v2, verificada contra la original: 176 tablas y 5,8 millones de filas. Privada, cifrada, con backup automático y soporte hasta 2028.
• El panel de administración corre en contenedores en ECS.
• El sitio y la facturación quedaron en una copia del servidor viejo, restaurada desde una imagen, con los archivos respaldados, debug apagado y las tareas programadas arregladas. Menos mediocre que antes. No es lo que yo quería.

¿Por qué no terminé la migración? Porque la versión nueva del frontend tiene bugs, y no voy a poner en producción algo que factura sin que una persona lo haya probado. La decisión correcta era respaldar todo, estabilizar y arreglar con calma diez años de deuda técnica.

Lo que hizo la IA, y lo que no

Partí con OpenCode y GPT Sol 6.0. El 1 de octubre me cambié a Sol 6.1, primero en OpenCode y esa misma tarde en Codex. En siete días le escribí 787 prompts.

Sin IA esto no se hacía en una semana. No había documentación ni inventario, el código no respetaba MVC y había cosas hardcodeadas por todos lados. La IA me ayudó a reconstruir cómo funcionaba el sistema leyendo código e infraestructura, auditoría por auditoría. Terminé con 35.

Sol 6.1 lo sentí lento y al principio culpé al modelo. Después vi que los servicios estaban saturados, y el domingo además llegué al tope semanal del plan. Aun así hizo un muy buen trabajo.

Pero la IA no decidió nada de lo importante. No decidió cerrar la base de datos abierta, ni dejar el sitio en la máquina vieja, ni abandonar mi plan original. Eso fue criterio.

Con lo que me quedo

La IA no te hace bueno. Te hace más rápido en lo que ya eres.

Si eres cuidadoso, en una semana haces lo que nadie hizo en seis años. Si eres negligente, produces el mismo descuido a una velocidad que antes no existía. Y un sistema que factura, con los documentos en /tmp y sin backup, puede quebrar una empresa sin que nadie se entere hasta el día que se apaga la máquina.

Yo me di cuenta por suerte. Quería hacer un MCP. Eso es lo que más me duele: que una empresa haya seguido funcionando hasta hoy no dependió de los que cobraban por cuidarla, sino de que alguien de afuera pasara por ahí.

Si alguien te mantiene un sistema, hoy pregúntale tres cosas: dónde está el código que corre en producción, cuándo fue la última vez que restauró un backup y dónde se guardan los archivos. Si no te responde con seguridad, tienes el mismo problema que yo tenía ese martes.