Desarrollo
Claude Code demuestra que los agentes de IA son más ingeniería que magia


Escritor y editor
12 min
Una descripción del trabajo de Claude Code, como esta, todavía puede sonar a ciencia ficción para algunas personas: le das una tarea al sistema y este lee tu base de código, edita archivos, ejecuta comandos, llama a herramientas externas, delega trabajo a subagentes, lleva un registro del contexto y comprueba si sus propios cambios realmente funcionaron. La documentación de Anthropic, por su parte, presenta Claude Code de manera más sucinta como una herramienta de codificación agéntica que lee una base de código, edita archivos, ejecuta comandos y se integra con herramientas de desarrollo en la terminal, los IDE, el escritorio y el navegador.
Esa descripción es correcta, pero podríamos decir que es solo una parte de la historia. Captura lo que ve el usuario, no el tipo de sistema que debe existir por debajo para que esas acciones puedan realizarse de forma segura en un entorno real de ingeniería. La distinción importa porque las herramientas de codificación agéntica están entrando en flujos de trabajo en los que los errores no se limitan a malas sugerencias de autocompletado. Pueden afectar archivos, pruebas, pipelines de compilación, tickets, entornos en la nube y, cada vez más, sistemas sensibles desde el punto de vista de la seguridad.
Un artículo académico reciente, "Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems", de Liu et al., ofrece una oportunidad útil para mirar más allá de la superficie del producto. Los autores analizaron el código fuente TypeScript de Claude Code v2.1.88, disponible públicamente (después de una filtración de alrededor de 500.000 líneas de código fuente propietario), y compararon su arquitectura con la de OpenClaw, un sistema de agentes de código abierto diseñado para un contexto de despliegue diferente. (Al redactar este post, la versión de Claude Code era la 2.1.140.)
Su observación central cabe en una sola línea: el ciclo principal del agente es pequeño, pero el armazón que lo rodea es grande. Según el resumen, el núcleo es un ciclo while que llama al modelo, ejecuta herramientas y se repite; sin embargo, la mayor parte de la implementación reside en las capas alrededor de ese ciclo (sistemas de permisos, gestión del contexto, extensibilidad, orquestación de subagentes y almacenamiento de sesiones).
Ese hallazgo ha circulado en línea de forma más llamativa y viral: "98 % de Claude Code no es IA". La afirmación va en la dirección correcta, pero, formulada así, puede resultar engañosa. El artículo reporta que un análisis comunitario del código extraído estimó que solo cerca del 1,6 % de la base de código correspondía a lógica de decisión de IA, mientras que el resto constituía infraestructura operativa. Eso no implica que la IA no sea importante. Significa que el razonamiento del modelo resulta útil solo cuando está rodeado por un sistema cuidadosamente diseñado que decide qué puede ver, qué puede tocar, qué debe preguntar antes de hacer, cómo se recupera de los errores y cómo mantiene la coherencia en una tarea larga.
Para los analistas de seguridad, esto es un recordatorio de revisar los sistemas de agentes como sistemas de software, no como chatbots con acceso a archivos. Para los desarrolladores de software, es un recordatorio de que la "codificación con IA" sigue siendo ingeniería de software, con preocupaciones conocidas como: estado, permisos, pruebas, observabilidad y reversión. Para los ejecutivos, es un recordatorio de que el valor estratégico de la adopción de IA dependerá menos de dejar que los modelos actúen libremente y más de construir las condiciones operativas bajo las cuales sus acciones sigan siendo útiles, auditables y seguras.
Qué son las herramientas de codificación agéntica
Los primeros asistentes de codificación potenciados por IA ayudaban sobre todo en el momento de escribir código. Las herramientas de autocompletado sugerían líneas o funciones, y las herramientas basadas en chat respondían preguntas y generaban fragmentos. Las herramientas de codificación agéntica van más allá. No se limitan a sugerir; actúan. Pueden inspeccionar un repositorio, buscar archivos relevantes, ejecutar una suite de pruebas, editar múltiples archivos, leer los resultados, ajustar el plan y seguir avanzando hasta llegar a un punto de parada plausible.
La documentación de Claude Code describe esto como un ciclo agéntico con tres fases superpuestas: reunir contexto, tomar acción y verificar resultados. La corrección de un bug puede recorrer repetidamente las tres. El modelo decide qué hacer con base en lo aprendido en el paso anterior, mientras que el usuario conserva la libertad de interrumpir y orientar. A grandes rasgos, podemos hablar de una arquitectura de dos capas: modelos que razonan y herramientas que actúan, con Claude Code como el armazón agéntico que proporciona esas herramientas, gestiona el contexto y ejecuta el ambiente.
Esta división es clave para entender el artículo de Liu et al. Claude Code no es un modelo flotando libremente por tu máquina. El modelo no accede directamente al sistema de archivos, no ejecuta comandos de shell ni realiza solicitudes de red. En cambio, emite solicitudes estructuradas de uso de herramientas. El armazón las analiza, verifica permisos, despacha las acciones aprobadas a herramientas y devuelve los resultados a la siguiente llamada al modelo. El artículo resalta esta separación como un límite de seguridad: el razonamiento y la aplicación de controles viven en rutas de código distintas, de modo que lo que el modelo "quiere" hacer no es lo mismo que aquello para lo cual tiene permiso.
Una analogía útil no es la de un robot con manos, sino la de un experto sentado en una sala de control. El experto propone acciones. La sala de control contiene pantallas, herramientas, listas de verificación, cerraduras, registros y operadores. El experto importa, pero la sala de control determina qué puede ocurrir.

Un agente de codificación no es solo un modelo. El modelo es un punto de decisión dentro de un andamiaje de ingeniería más amplio que controla contexto, permisos, ejecución, recuperación y auditabilidad.
La afirmación viral: mayormente cierta, pero fácil de malinterpretar
El video que, en parte, me motivó a escribir este post hacía varias afirmaciones: que la "parte de IA" de Claude Code es pequeña; que el núcleo es esencialmente un ciclo que llama a un modelo; que el resto consiste en permisos, herramientas, compresión de contexto y sistemas de recuperación; y que los ganadores en la IA agéntica se diferenciarán por la infraestructura y no solo por la elección del modelo.
El artículo de Liu et al. respalda en gran medida esa interpretación. Dice que el análisis a nivel de código fuente identificó un ciclo central simple rodeado de subsistemas de seguridad, extensibilidad, gestión de contexto, delegación y persistencia. También reporta un sistema de permisos con siete modos y un clasificador de machine learning, un pipeline de compactación de contexto de cinco capas, cuatro mecanismos de extensibilidad y un almacenamiento de sesiones orientado a la adición.
Aun así, "98 % no es IA" puede inducir a confusión si se toma de forma demasiado literal. El modelo sigue siendo el lugar donde se realizan la interpretación de la tarea, la comprensión del código, la planificación y la selección de herramientas. Si se elimina el modelo, el armazón se convierte en una carcasa sofisticada de reglas, esquemas y registros. Si se elimina el armazón, el modelo es un consultor conversador sin una forma confiable de actuar. La lección que enseña Claude Code no es que el modelo sea trivial; es que la utilidad del modelo depende de la arquitectura no-modelo que lo envuelve.
Además, los investigadores citan una encuesta interna de Anthropic realizada a 132 ingenieros e investigadores, según la cual aproximadamente el 27 % de las tareas en las que se utilizó Claude Code eran tareas que no se habrían intentado sin la herramienta. Ese es, tal vez, el argumento más sólido en contra de interpretar que "el 98 % no es IA" significa que "el modelo no importa": la arquitectura permite flujos de trabajo cualitativamente nuevos, no solo versiones más rápidas de los ya existentes.
Esto no sorprendería a alguien que haya construido sistemas de producción. Una base de datos no es valiosa porque su optimizador de consultas sea brillante; es valiosa porque el almacenamiento, la indexación, las transacciones, los permisos, los respaldos y la observabilidad funcionan en conjunto. Una aplicación segura no es segura porque una función de autenticación hace su trabajo; es segura porque identidad, autorización, validación, logging, monitoreo y recuperación operan de forma coordinada. La IA agéntica sigue el mismo patrón.
El armazón es donde se negocia la confianza
Para los equipos de seguridad, la parte más interesante de Claude Code bien podría ser su sistema de permisos. Según Liu y sus colegas, las solicitudes de herramientas pasan por un modelo deny-first: las reglas de denegación prevalecen sobre las reglas de pregunta, las reglas de pregunta prevalecen sobre las reglas de autorización, y las acciones desconocidas se escalan en lugar de permitirse silenciosamente. El artículo identifica hasta siete modos de permiso: plan, default, accept edits, auto, don't ask, bypass permissions y un modo bubble interno para la escalación de subagentes.
La documentación orientada al usuario presenta una versión más simple de la misma idea. Claude Code permite que los usuarios alternen entre modos de permiso como Default, Auto-accept edits, Plan mode y Auto mode. También permite autorizar comandos específicos en la configuración, como comandos de pruebas de confianza.
Esto importa porque, en la práctica, los humanos no son máquinas confiables para verificar permisos. Los investigadores citan un hallazgo propio de Anthropic según el cual los usuarios aprobaron aproximadamente el 93 % de las solicitudes de permiso, lo que sugiere que esas solicitudes a menudo se convierten en rituales más que en revisiones significativas. Un control al que los usuarios casi siempre dicen que sí no es realmente un control; se parece más a un reductor de velocidad. El equipo de ingeniería de Anthropic calcula que el uso de entornos aislados (sandboxing) redujo la frecuencia de las solicitudes de permiso en aproximadamente un 84 %, lo que replantea el problema en términos de factores humanos: la respuesta arquitectónica ante una aprobación poco fiable consiste, ante todo, en reducir el número de decisiones que deben tomar las personas. Por eso, los sistemas de agentes útiles necesitan defensas en capas: herramientas prefiltradas, evaluación de reglas, modos de permiso, clasificadores, hooks, sandboxing, no restauración de permisos obsoletos y registros de sesión.
Para los analistas de seguridad, eso amplía el objetivo de revisión mucho más allá de "¿El modelo rechaza prompts malos?" Este también debe cubrir dónde empieza la confianza, qué herramientas puede ver el modelo, si las reglas de denegación se comportan de manera determinística, si los permisos sobreviven a los límites de sesión, si los comandos de shell se ejecutan en un sandbox, si los hooks pueden modificar las entradas de las herramientas y si los conectores externos amplían silenciosamente la superficie de ataque.
El contexto es un recurso escaso
Una segunda gran lección es la gestión del contexto. Claude Code puede parecer que "entiende toda la base de código", y la documentación dice que puede trabajar entre archivos porque ve el proyecto del usuario, la terminal, el estado de Git, las instrucciones de CLAUDE.md, la memoria automática y las extensiones configuradas. Pero ningún modelo lleva literalmente una organización de ingeniería completa en la cabeza. Cada llamada al modelo tiene una ventana de contexto, y esa ventana se llena con instrucciones, contenido de archivos, salidas de comandos, mensajes anteriores, esquemas de herramientas, memoria y resúmenes.
El artículo explica que el mayor desafío de Claude Code es gestionar su "espacio de memoria" o contexto, que es limitado. Para evitar el desperdicio de este recurso, el sistema utiliza varios trucos: carga las instrucciones del proyecto solo cuando es absolutamente necesario, oculta los detalles técnicos sobre las herramientas hasta que se utilizan realmente, solicita a los subagentes resúmenes breves en lugar de informes extensos y establece "presupuestos de datos" para los resultados de las herramientas. También aplica cinco estrategias de reducción de contexto antes de las llamadas al modelo, partiendo de la premisa de que ningún método de compactación por sí solo puede manejar todo tipo de presión de contexto. Además, cada capa funciona con una relación costo-beneficio diferente, y las capas iniciales, que son más económicas, se ejecutan antes que las más costosas.
Mientras tanto, Anthropic lo dice de forma más plana: a medida que el contexto se llena, Claude Code borra primero salidas antiguas de herramientas y resume la conversación si es necesario; las reglas persistentes deberían ubicarse en CLAUDE.md en lugar de dejarse en los primeros turnos de la conversación, porque las instrucciones detalladas de momentos anteriores de una sesión pueden perderse. Las definiciones de herramientas MCP se aplazan por defecto, y los subagentes tienen sus propios contextos nuevos, de modo que su trabajo no sobrecarga la conversación principal.
Nada de esto es realmente una novedad de Claude Code, sino una confirmación. Como mencionamos en nuestro post anterior sobre desarrollo de software en la era agéntica, los agentes CLI ya "tratan el contexto como un recurso escaso", usando búsquedas dirigidas para encontrar los archivos que necesitan, leyendo solo lo relevante y gestionando la ventana de contexto con precisión. Lo que agrega el artículo es una mirada detallada a cómo termina viéndose esa disciplina una vez está conectada a un agente de producción real.
Para los desarrolladores, la conclusión práctica es dejar de tratar a un agente de codificación como a un colega que todo lo ve. Trátalo, más bien, como a un colega con una memoria de trabajo muy grande, pero aun así limitada. Pon las reglas duraderas del proyecto en archivos versionados. Dale pruebas, ejemplos y restricciones. Pídele que explore antes de implementar cuando la tarea sea compleja. Haz que la verificación forme parte del prompt. La respuesta del modelo solo podrá ser tan buena como el contexto operativo que el armazón logre ensamblar en el momento en que se le pregunta.
Para los ejecutivos, la gestión del contexto también es una preocupación de costos y de gobernanza. El trabajo de IA de larga duración consume tokens, llamadas a herramientas y atención humana. Si se espera que los agentes operen sobre grandes bases de código, los equipos necesitan convenciones sobre qué debería entrar en la memoria persistente, qué debería pertenecer a las instrucciones del proyecto, qué debería recuperarse bajo demanda y qué nunca debería exponerse al agente.
Las herramientas hacen el trabajo; el modelo elige entre ellas
El modelo de Claude Code no edita archivos con manos invisibles. Usa herramientas. El artículo reporta hasta 54 herramientas integradas, con 19 incluidas siempre y 35 incluidas condicionalmente según feature flags, variables de entorno y tipo de usuario. Luego, esas herramientas integradas se combinan con herramientas proporcionadas por MCP y la superficie de acción resultante se filtra, deduplica y moldea antes de que el modelo la vea.
Ese detalle ayuda a explicar comentarios como los que afirman que los agentes no son más que otra herramienta que añadir a un proyecto y que toda solución real a los problemas sigue siendo una solución de ingeniería integral. Hay algo de cierto en esto, aunque está subestimando al modelo. Los agentes de IA no son solo una herramienta en el mismo sentido en que grep lo es; son motores de razonamiento flexibles que pueden decidir qué herramientas usar, en qué orden y con base en qué retroalimentación. Pero aun así necesitan la maquinaria de software tradicional detrás de ellos para hacer cualquier cosa de manera confiable.
Las extensiones de Claude Code ilustran el mismo punto. Los usuarios pueden conectar servicios externos mediante MCP, guardar instrucciones de proyecto en CLAUDE.md, crear skills para flujos de trabajo repetibles y usar hooks para ejecutar comandos antes o después de acciones de Claude Code. El producto también soporta subagentes y agentes personalizados para trabajo delegado. Los investigadores mapean estos mecanismos en una visión más arquitectónica: los servidores MCP agregan herramientas externas, los plugins empaquetan componentes, las skills inyectan instrucciones específicas de dominio y los hooks interceptan eventos del ciclo de vida.
En otras palabras, el "agente" no es una sola cosa. Es una composición de llamadas al modelo, esquemas de herramientas, verificaciones de permisos, archivos, salidas de comandos, prompts, hooks, memorias, resúmenes y registros. La inteligencia del modelo es real, pero la confiabilidad del producto proviene de cómo se componen esas piezas.
Por qué esto importa para AppSec
Para la seguridad de aplicaciones (AppSec), el cambio más importante es pasar de la detección a la acción. Una herramienta que solo puede identificar una vulnerabilidad todavía deja la remediación, la validación y el despliegue en manos de humanos. Un agente de codificación podría hacer más: inspeccionar la ruta vulnerable del código, escribir un parche, ejecutar pruebas, actualizar dependencias, producir un pull request y documentar el razonamiento. Eso lo hace poderoso, pero también riesgoso.
Antes habíamos planteado un punto relacionado. En nuestra discusión sobre Claude Mythos, argumentamos que el descubrimiento de vulnerabilidades impulsado por IA no acaba con la ciberseguridad; acelera tendencias que ya estaban en marcha, mientras deja la remediación como un desafío complejo y dependiente del contexto. Claude Code encaja en ese panorama más amplio. Puede acelerar los flujos de trabajo de remediación, pero solo cuando sus acciones están restringidas, revisadas y verificadas.
Por lo tanto, los equipos de seguridad deberían evaluar las herramientas de codificación agéntica mediante varias preguntas: ¿Puede la herramienta rendir cuentas de qué archivos leyó, qué comandos ejecutó y por qué? ¿Puede restringirse a una planificación de solo lectura antes de hacer cualquier cambio? ¿Los comandos peligrosos se deniegan por defecto? ¿Los servicios externos conectados mediante MCP se revisan como parte del modelo de amenazas? ¿Hay registros de sesión disponibles para auditoría? ¿Los cambios pueden revertirse? ¿Las correcciones generadas se prueban contra casos relevantes para la explotación, y no solo contra pruebas unitarias happy-path? ¿La organización puede definir políticas centralmente, en lugar de dejar que el juicio local de cada desarrollador cargue con todo el peso?
Esas preguntas no son anti-IA. Son las condiciones bajo las cuales la asistencia de IA se vuelve útil en el trabajo de seguridad. En programas maduros de AppSec, el objetivo no es dejar que los agentes "hagan seguridad" por sí solos; es ubicarlos dentro de procesos que ya saben manejar evidencia, riesgo, reproducibilidad y responsabilidad.
¿Qué deberían sacar en claro los líderes de la cifra del 98 %?
La cifra del 98 % es útil sobre todo porque desplaza la conversación sobre hacia dónde debería ir la inversión. Si las empresas suponen que la adopción de la IA agéntica consiste principalmente en comprar acceso al mejor modelo, subestimarán el trabajo requerido. El modelo es un componente. El sistema que lo rodea es lo que determina si el modelo puede actuar de una forma segura, medible y alineada con los objetivos de la organización.
Por eso, una estrategia seria de adopción tiene que incluir ingeniería para el armazón: políticas de permisos, sandboxing, registros aprobados de herramientas, gobernanza de contexto, configuraciones seguras de MCP, logs de auditoría, rutas de reversión, integración con CI, suites de evaluación y procedimientos de revisión humana. También debe incluir entrenamiento para que los usuarios no solo "escriban mejores prompts", sino para que supervisen mejor: que definan restricciones, proporcionen objetivos de verificación, inspeccionen diffs, entiendan modos de falla y sepan cuándo no delegar. Esto es, en muchos sentidos, el mismo cambio que describimos en nuestro post anterior sobre desarrollo agéntico: el ingeniero convirtiéndose en un orquestador que supervisa múltiples agentes, define objetivos de alto nivel, resuelve conflictos entre ellos y revisa los pull requests resultantes, en lugar de ser un programador inclinado sobre cada línea.
Aquí es donde se vuelve importante otro comentario que vi en redes sociales. Decía algo como "cualquiera que se sorprenda por esto claramente no entendía los fundamentos de los agentes de IA desde el principio". Comentarios como ese son duros, pero la idea de fondo es razonable. En la literatura sobre agentes, el modelo ha sido durante mucho tiempo solo una pieza de un ciclo que incluye planificación, memoria y uso de herramientas. Lo que Claude Code hace visible es una versión de producción notable de esa idea. La parte glamorosa es la respuesta del modelo; la parte difícil es todo lo que se requiere antes y después.
El riesgo no resuelto: puede que la gente aprenda menos mientras hace más
El artículo de Liu et al. no es incondicionalmente entusiasta. Plantea una preocupación sobre la capacidad humana a largo plazo. Claude Code puede aumentar la productividad a corto plazo, pero los autores señalan que su arquitectura ofrece mecanismos limitados que apoyan explícitamente la mejora humana a largo plazo, una comprensión más profunda y la coherencia sostenida de la base de código. Consideran esto un criterio de evaluación más que un valor fundamental del diseño.
Esa preocupación no debería descartarse. Si los desarrolladores se apoyan en agentes para navegar por bases de código, realizar cambios y corregir pruebas, pueden entregar más rápido mientras entienden menos. Si los analistas de seguridad dependen de agentes para priorizar hallazgos y proponer correcciones, pueden procesar más alertas, pero pierden el hábito de la investigación manual profunda. Y si los ejecutivos miden solo el throughput, pueden pasar por alto un deterioro gradual de la coherencia de la base de código, de la calidad de la revisión o del desarrollo del talento junior.
La respuesta no es rechazar las herramientas agénticas. Es diseñar flujos de trabajo que preserven el aprendizaje. Exige que los agentes produzcan explicaciones concisas de cada cambio; pide pruebas antes de las correcciones; usa el modo plan para el trabajo complejo; haz que los revisores inspeccionen no solo si las pruebas pasan, sino también si el agente respetó la arquitectura, los modelos de amenazas y las restricciones de mantenibilidad, y trata el resultado del agente como un borrador que debe ganarse la confianza con evidencia.
Un buen agente de codificación debería hacer que los profesionales sean más capaces, no solo que estén más ocupados en un nivel más alto de abstracción.
Conclusión: el futuro pertenece al armazón
Claude Code es impresionante, en parte, porque su modelo es potente. Pero la lección más profunda del artículo citado es que los agentes de producción tienen éxito o fracasan según la infraestructura que rodea el modelo. El ciclo puede ser simple; el sistema no lo es.
Para los desarrolladores, la conclusión práctica es usar herramientas de codificación agéntica como colaboradores en un flujo de trabajo de ingeniería, no como sustitutos autónomos. Los analistas de seguridad tienen una tarea arquitectónica por hacer: evaluar permisos, herramientas, contexto, memoria, conectores y registros, y no solo el comportamiento de rechazo del modelo. Y para los ejecutivos, la pregunta es estratégica: las empresas que más provecho saquen de los agentes de IA serán las que inviertan en el armazón, las políticas y la cultura de verificación que los rodean.
La siguiente fase de adopción de la IA no estará definida por una competencia entre humanos y agentes. Estará definida por qué tan bien las organizaciones diseñen el espacio en el que humanos, modelos y sistemas de software trabajan juntos. El ejemplo de Claude Code fue muy valioso aquí porque muestra cuánta ingeniería debe haber en su lugar antes de que un agente pueda actuar de forma responsable. En conclusión, los agentes de IA útiles son más ingeniería que magia.
Empieza ya con la solución de seguridad de IA de Fluid Attacks
Suscríbete a nuestro boletín
Mantente al día sobre nuestros próximos eventos y los últimos blog posts, advisories y otros recursos interesantes.
Otros posts



















