Primero utilizaron ChatGPT para reducir costes. Luego nos contrataron para limpiar la deuda técnica AI

Philip Tihonovich

29 de mayo de 2025 10 minutos de lectura

Le sorprendería saber cuántas empresas lo hacen ya.

Como indican los informes de toda la industria, ahora hay un sector especializado cada vez mayor de ingenieros que se dedican a corregir los errores de código generados por el AI.

El patrón se ha vuelto notablemente consistente. Las empresas recurren a ChatGPT para generar scripts de migración, integraciones o funciones completas, con la esperanza de ahorrar tiempo y reducir costes. Al fin y al cabo, la tecnología parece rápida y accesible.

Entonces los sistemas fallan.

Y nos llaman.

Últimamente, recibimos cada vez más peticiones de este tipo. No para lanzar un nuevo producto, sino para desenmarañar cualquier lío que haya quedado después de que alguien confiara un modelo de lenguaje a su código de producción.

En este punto, está empezando a parecer su propio nicho de la industria. Arreglar los fallos generados por el AI es ahora un servicio facturable. Y en algunos casos, muy caro.

Informe 2024 de GitClear confirma lo que hemos visto con los clientes: Las herramientas de codificación AI aceleran la entrega, pero también alimentan la duplicación, reducen la reutilización e inflan los costes de mantenimiento a largo plazo.

En un caso, un cliente acudió a nosotros después de que una migración generada por AI dejara caer datos críticos de un cliente. Invertimos 30 horas recuperando lo que se perdió, reescribiendo la lógica desde cero y limpiando el pipeline. Lo irónico es que habría sido más barato que un desarrollador veterano lo hubiera escrito a la antigua usanza.

Que quede claro, sin embargo, que no estamos "en contra del AI". Nosotros también lo utilizamos. Y es útil en el contexto adecuado, con los guardarraíles adecuados. Pero lo que me frustra de la excesiva confianza en el AI y sus implicaciones generalizadas -y probablemente a usted también- es el pensamiento mágico. La idea de que un modelo lingüístico puede sustituir al verdadero trabajo de ingeniería.

No se puede. Y como dice el refrán, la prueba está en el pudín. Cuando las empresas pretenden lo contrario, acaban pagando a alguien como nosotros para que lo limpie.

¿Cómo es uno de estos trabajos de limpieza? Esto es lo que los AI-afficionados no te cuentan en cuanto a tiempo perdido y dinero malgastado.

Cómo es una solicitud típica

El mensaje suele llegar así:

"Oye, ¿puedes echar un vistazo a un microservicio que hemos construido? Usamos ChatGPT para generar la primera versión. La empujamos a staging, y ahora nuestra cola RabbitMQ está completamente inundada".

Siempre empieza por algo pequeño. Una tarea que parecía demasiado aburrida o lenta. Algo como analizar un CSV, reescribir un cron job o cablear un simple webhook. Así que se la entregan a un modelo lingüístico y esperan lo mejor.

Pero aquí está la cosa: los síntomas aparecen mucho más tarde. A veces días después. Y cuando lo hacen, rara vez es obvio que la causa de fondo sea el código generado por AI. Simplemente parece que... algo falla.

"No se puede externalizar el pensamiento arquitectónico a un modelo lingüístico. AI puede acelerar las cosas, pero siguen haciendo falta ingenieros para construir sistemas que no se vengan abajo bajo presión."

Dmitry Nazarevich

Director Técnico

Tras una docena de estos casos, empiezan a surgir patrones:

Sin pruebas. En absoluto. Ni siquiera una afirmación de "hola mundo". Sólo crudo, código especulativo que nunca se ejercitó correctamente.
Desconocimiento de los límites del sistema. Hemos visto scripts ChatGPT que consultan tres microservicios de forma sincrónica, ignoran los tiempos de espera y hacen explotar toda la cadena de llamadas al primer fallo.
Uso indebido de las transacciones. Un cliente utilizó SQL generado por AI con transacciones anidadas dentro de un servicio Node.js utilizando Knex. Funcionó, hasta que dejó de hacerlo y la mitad de las escrituras fallaron silenciosamente.
Sutiles condiciones de carrera. Especialmente en bases de código multihilo o asíncronas. El tipo de errores que no aparecen en desarrollo pero que destrozan la producción a escala.

Y por supuesto, cuando todo se derrumba, el AI no te deja un comentario diciendo: "Por cierto, estoy adivinando aquí".

Esa parte corre de tu cuenta.

Caso 1: El script de migración que dejó caer silenciosamente datos de clientes

Este vino de una empresa de tecnología financiera de rápido crecimiento.

Estaban desplegando una nueva versión de su modelo de datos de clientes, dividiendo un gran campo JSONB en Postgres en múltiples tablas normalizadas. Algo bastante estándar. Pero con plazos ajustados y pocas manos, uno de los desarrolladores decidió "acelerar las cosas" pidiendo a ChatGPT que generara un script de migración.

A primera vista tenía buena pinta. El script analizaba el JSON, extraía la información de contacto y la insertaba en un nuevo archivo user_contacts mesa.

Así que lo ejecutaron.

Sin simulacro. Sin copia de seguridad. Directamente a la puesta en escena, que, como resulta, estaba compartiendo datos con la producción a través de una réplica.

Unas horas más tarde, el servicio de atención al cliente empezó a recibir correos electrónicos. Los usuarios no recibían notificaciones de pago. A otros les faltaban números de teléfono en sus perfiles. Fue entonces cuando nos llamaron.

Qué salió mal

Rastreamos el problema hasta el script. Hizo la extracción básica, pero hizo tres suposiciones fatales:

No manejaba NULL o claves que faltan dentro de la estructura JSON.
Insertaba registros parciales sin validación.
Utilizaba ON CONFLICT DO NOTHING, por lo que cualquier inserción fallida se ignoraba silenciosamente.

Resultado: sobre 18% de los datos de contacto se perdió o se corrompió. No hay registros. No hay mensajes de error. Sólo pérdida de datos silenciosa.

Lo que costó arreglar

Asignamos un pequeño equipo para desenredar el embrollo. Esto es lo que hicimos:

Diagnóstico y replicación (4 horas) Volvimos a crear el script en un entorno aislado y lo ejecutamos contra una instantánea de la base de datos. Así confirmamos el problema y localizamos exactamente lo que faltaba.
Auditoría forense de datos (8 horas) Comparamos el estado roto con las copias de seguridad, identificamos todos los registros con datos faltantes o parciales y los cotejamos con los registros de eventos para rastrear qué inserciones fallaron y por qué.
Reescribir la lógica de migración (12 horas) Volvimos a escribir todo el script en Python, añadimos una lógica de validación completa, creamos un mecanismo de reversión y lo integramos en el proceso CI del cliente. Esta vez, incluía pruebas y soporte de ejecución en seco.
Recuperación manual de datos (6 horas) Algunos registros no se podían recuperar de las copias de seguridad. Extrajimos los campos que faltaban de sistemas externos (sus API de CRM y proveedor de correo electrónico) y restauramos manualmente el resto.

Tiempo total: 30 horas de ingeniería

Dos ingenieros, tres días. Coste para el cliente: unos $4,500 in service fees.

But the bigger hit came from customer fallout. Failed notifications led to missed payments and churn. The client told us they spent at least $10,000 on support tickets, SLA compensation, and goodwill credits over that one botched script.

The ironic thing is that a senior developer could’ve written the correct migration in maybe four hours. But the promise of AI speed ended up costing them two weeks of cleanup and reputation damage.

Arreglamos lo que ChatGPT rompía y construimos lo que no podía.

Caso 2: El cliente API que ignoró los límites de tarifa y rompió la producción

Ésta procede de una startup de tecnología jurídica que crea una plataforma de gestión de documentos para bufetes de abogados. Una de sus características principales era la integración con un servicio gubernamental de notificaciones electrónicas: una API REST de terceros con OAuth 2.0 y una limitación estricta de la velocidad: 50 solicitudes por minuto, sin excepciones.

En lugar de asignar la integración a un desarrollador de backend experimentado, alguien del equipo decidió hacer un prototipo con ChatGPT. Introdujeron la especificación OpenAPI, pidieron un cliente Python y obtuvieron un script de aspecto limpio con requests, lógica de reintento mediante tenacity, y actualización de fichas.

Parecía sólido sobre el papel. Así que lo enviaron.

Qué salió mal

Al principio, todo parecía ir bien. El cliente gestionaba correctamente las solicitudes individuales, pasaba la autenticación e incluso reintentaba en caso de fallo. Pero durante el uso real, especialmente bajo carga, la plataforma empezó a comportarse de forma impredecible.

Esto es lo que ocurrió en realidad:

No se respetan los límites de las tarifas. El código generado no leía ni interpretaba X-RateLimit-Remaining o Retry-After cabeceras. Seguía enviando peticiones a ciegas.
Los reintentos empeoraron las cosas. Cuando empezaron a llegar los errores 429, el decorador de tenacidad los reintentó automáticamente. Sin jitter. Sin colas. Sólo una avalancha de solicitudes de seguimiento.
El proveedor de la API bloqueó temporalmente su IP. Durante 3 horas, nadie en la plataforma pudo sincronizar documentos. Sin registros, sin alertas. Sólo un fallo silencioso.

Esto no era un arreglo de una línea. Era un malentendido de cómo se comportan los sistemas de producción. Y es un gran ejemplo de lo que los LLM no saben; no porque estén estropeados, sino porque no tienen conciencia del tiempo de ejecución.

Deja de parchear código generado por AI en prod - tráenos antes de que se rompa.

Cómo lo arreglamos

Rastrear y aislar el fallo (6 horas) Añadimos middleware para inspeccionar el tráfico saliente y confirmamos la avalancha de peticiones durante los picos de uso. También recreamos el fallo en la puesta en escena para comprender plenamente el patrón desencadenante.
Reconstruir el cliente API (10 horas) Reescribimos el cliente utilizando httpx.AsyncClient, ha implementado un acelerador basado en semáforos, ha añadido un backoff exponencial con jitter y ha gestionado correctamente Retry-After y cabeceras de límite de velocidad.
Prueba de esfuerzo y validación (6 horas) Simulamos el uso en el mundo real con miles de peticiones simultáneas utilizando Locust, probamos la limitación de velocidad en diferentes escenarios de ráfagas y confirmamos que no se producían 429s bajo carga sostenida.
Añadir supervisión y alerta (4 horas) Configuramos métricas Prometheus personalizadas para realizar un seguimiento del uso de la API por minuto y añadimos alertas para notificar al equipo si se acercaban a los umbrales de tasa.

Tiempo total: 26 horas

Dos ingenieros, repartidos en dos días y medio. Coste para el cliente: unos $3,900.

El mayor problema es que su principal cliente, un bufete de abogados con expedientes urgentes, perdió dos plazos de presentación ante los tribunales debido a la interrupción. El cliente tuvo que controlar los daños y ofrecer un descuento para mantener la cuenta.

Todo porque un modelo de lenguaje no entendía la diferencia entre "código de trabajo" y "código listo para producción". Y sin más, otra capa de deuda técnica AI se añadió silenciosamente a la pila.

Por qué sigue ocurriendo esto

The scary part isn’t that these things go wrong. It’s how predictable it’s all becoming.

Every one of these incidents follows the same pattern. A developer asks ChatGPT for a code snippet. It returns something that works just well enough not to throw errors. They wire it into the system, maybe clean it up a little, and ship it, assuming that if it compiles and runs, it must be safe.

But here’s the catch: Large language models don’t know your system.
They don’t know how your services interact.
They don’t know your latency budget, your deployment pipeline, your observability setup, or your production traffic patterns.

They generate the most likely-looking code based on patterns in their training data. That’s all. There’s no awareness. No guarantees. No intuition for system design.

And the output often reflects that:

Código que funciona una vez, pero falla bajo carga
Sin programación defensiva ni sistemas de seguridad
Escasa comprensión de las limitaciones del mundo real, como los límites de velocidad, los tiempos de espera o la coherencia final.
Cero sentido de la intención arquitectónica

Lo peor es que el código parece correcto. Es sintácticamente limpio. Pasa linters. Incluso podría ser cubierto por una prueba básica. Pero le falta la única cosa que realmente importa: el contexto.

Por eso estos fallos no aparecen de inmediato. Esperan a los despliegues del viernes por la noche, a las ventanas de alto tráfico, a los raros casos límite. Esa es la naturaleza de la deuda técnica AI - es invisible hasta que rompe algo crítico.

Cuando AI realmente ayuda

As we mentioned earlier, we use AI too. Pretty much every engineer on our team has a Copilot-like setup running locally. It’s fast, helpful, and honestly, a great way to skip the boring parts.

But here’s the difference: nothing makes it into the main branch without going through a senior engineer, and in most cases, a CI pipeline that knows what to look for.

LLMs are great at:

plantillas de andamiaje para nuevos servicios o puntos finales de API,
generar cobertura de pruebas para la lógica existente,
ayudar en la refactorización repetitiva de grandes bases de código,
convertir simples scripts de shell en plantillas de infraestructura como código,
o incluso comparando enfoques algorítmicos que ya entendemos.

Lo que son no bueno es el diseño. O el contexto. O los valores predeterminados seguros.

Por eso hemos creado nuestros flujos de trabajo para tratar los resultados de LLM como sugerencias, no como fuentes de verdad. Esto es lo que ocurre en la práctica:

Etiquetamos todos los commits generados por AI para facilitar su seguimiento y revisión.
Nuestros editores tienen avisos en línea, pero con ganchos pre-commit forzados que bloquean cualquier cosa sin pruebas o documentación.
Nuestro CI incluye reglas de análisis estático que detectan patrones inseguros que hemos visto antes en LLMs: cosas como reintentos no protegidos, tiempos de espera no cubiertos, análisis JSON ingenuo o manejo SQL inseguro.
Cada pull request con código generado por LLM pasa por una revisión humana obligatoria, normalmente por alguien de alto nivel que entiende la lógica del dominio y la superficie de riesgo.

Bien utilizado, ahorra tiempo. Si se usa a ciegas, es una bomba de relojería.

Lo que recomendamos a los CTO

We’re not here to tell you to ban AI tools. That ship has sailed.

But giving a language model commit access? That’s just asking for trouble.

Here’s what we recommend instead:

1. Tratar a los LLM como herramientas, no como ingenieros

Deja que te ayuden con el código repetitivo. Que propongan soluciones. Pero no les confíes decisiones críticas. Cualquier código generado por AI debe ser revisado por un ingeniero senior, sin excepciones.

2. Hacer trazable el código generado por LLM

Ya sean etiquetas de confirmación, metadatos o comentarios en el código, dejar claro qué piezas proceden del AI. Esto facilita la posterior auditoría, depuración y comprensión del perfil de riesgo.

3. Definir una política de generación

Decidan en equipo dónde es aceptable utilizar LLM y dónde no. ¿Boilerplate? Claro. ¿Flujos de autenticación? Tal vez. ¿Sistemas transaccionales? Absolutamente no sin revisión. Explicitar la política y parte de sus normas de ingeniería.

4. Añadir supervisión a nivel de DevOps

Si dejas que el código generado por AI entre en producción, tienes que asumir que algo se romperá en algún momento. Añade comprobaciones sintéticas. Monitores de límite de velocidad. Seguimiento de dependencias. Hacer visible lo invisible, especialmente cuando el autor original no es humano.

5. Construir para la recuperabilidad

Los mayores fallos provocados por el AI que hemos visto no provenían de código "malo". Procedían de errores silenciosos -falta de datos, colas rotas, tormentas de reintentos- que pasaban desapercibidos durante horas. Invierta en la observabilidad, la lógica de retroceso y las reversiones. Especialmente si dejas que ChatGPT escriba las migraciones.

En resumen, AI puede ahorrar tiempo a su equipo, pero no puede asumir la responsabilidad.

Sigue siendo un trabajo humano.

Reflexiones finales: AI ≠ ingenieros de software

AI can help you move faster. But it can’t think for you.

It doesn’t understand your architecture. It doesn’t know what “done” means in your context. And it definitely doesn’t care if your data pipeline silently breaks on a Friday night.

That’s why, as CTOs, we need to stay focused on system resilience, not just speed.

It’s tempting to let AI handle the boring parts. And sometimes that’s fine. But every shortcut comes with a tradeoff. When AI-generated code slips through unchecked, it often becomes AI technical debt. The kind you don’t see until your ops team is firefighting in production.

If you’ve already run into that wall, you’re not alone. We’ve helped teams recover from everything from broken migrations to API disasters. We don’t just refactor code. We help refactor the thinking behind it.

Because in the end, that’s what actually makes systems reliable.

Philip Tikhanovich

Jefe del Departamento de Python, Big Data, ML/DS/AI

Philip aporta un enfoque nítido a todo lo relacionado con los datos y el AI. Él es quien hace las preguntas correctas desde el principio, establece una sólida visión técnica y se asegura de que no solo construyamos sistemas inteligentes, sino los correctos, para obtener un valor empresarial real.

Seguir leyendo

Índice

Contáctenos

Reservar una llamada o rellene el siguiente formulario y nos pondremos en contacto con usted cuando hayamos procesado su solicitud.

Nombre

Empresa

Correo electrónico

Teléfono

Mensaje

Envíenos un mensaje de voz

Adjuntar documentos

Cargar archivo

Puede adjuntar 1 archivo de hasta 2 MB. Formatos de archivo válidos: pdf, jpg, jpeg, png.

Al hacer clic en Enviar, autoriza a Innowise a procesar sus datos personales de acuerdo con nuestra política de privacidad. Política de privacidad para proporcionarle información relevante. Al enviar su número de teléfono, acepta que nos pongamos en contacto con usted a través de llamadas de voz, SMS y aplicaciones de mensajería. Pueden aplicarse tarifas de llamadas, mensajes y datos.

También puede enviarnos su solicitud
a contact@innowise.com

¿Qué pasa después?

Una vez recibida y procesada su solicitud, nos pondremos en contacto con usted para detallarle las necesidades de su proyecto y firmar un acuerdo de confidencialidad. Proyecto y firmaremos un acuerdo de confidencialidad.

Tras examinar sus deseos, necesidades y expectativas, nuestro equipo elaborará una propuesta de proyecto con el alcance del trabajo, el tamaño del equipo, el plazo y los costes estimados con el alcance del trabajo, el tamaño del equipo, el tiempo y las estimaciones de costes.

Concertaremos una reunión con usted para hablar de la oferta y concretar los detalles.

Por último, firmaremos un contrato y empezaremos a trabajar en su proyecto de inmediato.