Para no ser devorado por el código escrito por IA, debes empezar por aislar la arquitectura
TuBrief 편집팀
2026년 7월 7일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
La velocidad a la que la IA generativa escupe código es aterradora. Sin embargo, los ingenieros senior y los líderes técnicos enfrentan un problema real diferente: la sobrecarga cognitiva que surge al validar y conectar al sistema existente el código que la máquina generó en un segundo. El informe DORA 2025 de Google Cloud indica que, si bien la adopción de la IA aumenta la frecuencia de despliegue, también incrementa la inestabilidad del sistema. Esto significa que los humanos están pasando las noches reparando los "agujeros" que se abren tras copiar y pegar código ciegamente. El método manual de leer y depurar línea por línea es incapaz de seguir este ritmo. Para evitar que el código se convierta en basura, es necesario construir desde el principio un entorno arquitectónico que no confíe en la lógica generada por la IA y automatizar la validación.
El código propuesto por la IA desconoce el contexto del negocio. Aunque parezca correcto, a menudo rompe reglas sutiles del dominio. Por ello, la lógica generada por la IA debe tratarse como un sistema externo que puede fallar en cualquier momento. Esta es la razón por la que, desde la fase de diseño, se debe implementar una capa anticorrupción (Anticorruption Layer) que defina interfaces de abstracción claras, evitando que agentes contaminantes entren en el dominio existente.
Simplemente separar la arquitectura de software no es suficiente. Existe un riesgo constante de que el código de la IA importe librerías maliciosas o manipule el sistema de archivos local. El ejemplo de Stripe al diseñar Minions, su sistema de agentes autónomos, es revelador: ejecutan el código de la IA en máquinas virtuales independientes aisladas de la máquina anfitriona y bloquean el acceso a la red a nivel de protocolo. Para proteger el entorno de producción, es necesario introducir controles de nivel de kernel dentro de los pipelines de CI/CD.
Debemos construir un entorno de ejecución de "confianza cero" que mantenga el código no verificado encerrado, impidiendo que salga. La reducción en los tiempos de respuesta ante fallos del sistema es un beneficio adicional que llega como consecuencia.
Es peligroso que los desarrolladores verifiquen visualmente cientos de líneas de código generadas por IA. Cuando el cerebro se agota, actúa un sesgo de automatización que hace pasar por bueno cualquier código que parezca funcional. Los defectos en la lógica generada por la máquina no deben ser detectados por humanos, sino por código de pruebas ejecutable. Antes de ordenar a la IA que escriba el código de implementación real, hay que invertir el orden y exigirle que cree primero los casos de prueba que definan las especificaciones de funcionamiento. Es una regla obligatoria definir cinco categorías: flujo normal, condiciones de borde, manejo de excepciones, entradas anómalas y escenarios de recuperación de fallos.
La cobertura de código (line coverage) obtenida mediante prompts manuales no es muy alta. Según datos operativos de agentes de DeepBlue, la cobertura de pruebas de líneas obtenida por ingenieros humanos interactuando con IA alcanzó solo un 32% en promedio. Por el contrario, cuando se combinó el análisis estático del código fuente y el build en sandbox de tiempo de ejecución con agentes de prueba automatizados, se obtuvo un 81% promedio de cobertura de pruebas de regresión sin intervención humana. La estructura donde una máquina supervisa a otra es mucho más rigurosa.
Para lógicas donde no es posible realizar comparaciones uno a uno, como traducciones de lenguaje natural u objetos JSON dinámicos, se aplica la técnica LLM-as-a-Judge. Se despliegan frameworks como AgentProctor en la infraestructura de pruebas y se inyectan plantillas de criterios de evaluación al modelo de decisión. Si el modelo de decisión determina cuantitativamente que el código devuelto no vulnera las restricciones de seguridad y se establecen barreras (guardrails) que bloqueen el build en caso de incumplimiento, se elimina el sufrimiento humano de tener que examinar el código crudo.
A medida que aumenta el código escrito por máquinas, se acumula deuda cognitiva en el sistema. Se llega a una situación extraña donde el código funciona, pero nadie sabe por qué. Dado que las herramientas de IA se enfocan solo en resolver problemas locales inmediatos, generan costos masivos cuando llega el momento de refactorizar todo el sistema meses después. Para preservar la intención de diseño oculta detrás del código base, se debe adoptar el proceso de Agent Decision Records como estándar del equipo. Consiste en documentar en un formato legible por máquinas por qué se eligió cierta estructura y qué alternativas se descartaron.
Como no se puede confiar en la memoria humana, el proceso de dejar constancia de que la IA escribió el código también debe ser integrado en el pipeline automatizado. Al usar herramientas como la librería de extensión git-ai, se pueden registrar notas de contribución del agente en la ruta de metadatos independiente refs/notes/ai sin ensuciar el cuerpo de los mensajes de commit. Los pasos para construir el pipeline de Git son claros:
pre-commit hooks en el entorno de desarrollo local y en el repositorio del servidor CI.AI-Footprint: model=gpt-4o) y la información del coautor.Al acumular estos metadatos, es posible extraer estadísticas de la cadena de suministro en tiempo real para saber qué versión del modelo de IA generó de forma masiva ciertos fallos o vulnerabilidades de seguridad en el futuro. Es un mecanismo de seguridad para evitar el infierno de tener que revisar decenas de miles de líneas de código sin documentación de traspaso.
Si el código generado indiscriminadamente comienza a acumularse en la cola de pull requests, la revisión manual de código se paraliza. Para mantener la productividad, el proceso de revisión debe dividirse en puertas de retroalimentación determinista centradas en la máquina y una evaluación de impacto estructural centrada en el humano. La alternativa es implementar una puerta de garantía de calidad de 3 niveles que funcione en cuanto el código se suba al entorno de CI.
Primero, se establece una puerta de linting de ultra alta velocidad que determina en menos de 5 segundos la validez de la estructura sintáctica y la concordancia de las type hints. Si se filtra aquí, el rechazo es inmediato. Segundo, se realizan pruebas de impacto selectivas que ejecutan rápidamente solo las pruebas unitarias que están dentro del radio de influencia de los archivos modificados (alrededor del 2%). Tercero, se ejecuta un bucle de autocorrección automatizada donde, en caso de fallo en las pruebas, se devuelve al agente el error stack como contexto para que lo corrija él mismo hasta un máximo de 2 veces.
Solo los fragmentos de código limpios que superan este bucle de autocorrección aparecen en la pantalla de un desarrollador senior humano. El revisor humano ya no pierde tiempo buscando erratas o señalando convenciones. El tiempo del ingeniero senior debe emplearse únicamente en el control macroscópico: revisar si los límites del dominio se han roto debido al acoplamiento directo entre componentes, confirmar si se ha reflejado la contrapresión (backpressure) para proteger la capa de persistencia inferior durante aumentos repentinos de tráfico, y analizar la estructura del sistema y la eficiencia de la infraestructura, como la sobrecarga de rendimiento del N+1 en SQL. Es la única forma de proteger el sistema de producción en medio del torrente de código que se aproxima.