Hegel, GitOps y un agente en producción

Según el informe DORA de 2025, el 90 % de los encuestados usa IA en el trabajo y el 90 % de sus organizaciones tiene al menos una plataforma interna; cuanto mejor es esa plataforma, más partido le sacan a la IA. Ahora que los agentes abren pull requests y tocan clusters, cada vez más voces piden que la plataforma se piense también para ellos. Te cuento cómo creo que tiene que cambiar, qué parte puedes usar ya y lo que todavía no resuelve.

Los agentes ya están dentro

Si ya dejas que Claude Code o Cursor te abran pull requests y lean los logs del cluster, no eres el único. En la encuesta de Stack Overflow de 2025, el 14 % de los desarrolladores usa agentes de IA a diario en el trabajo y otro 17 % aún no los usa, pero piensa hacerlo. Al 87 % le preocupa la exactitud de lo que le dicen, y al 81 %, la seguridad y la privacidad de sus datos.

Anthropic publicó MCP en noviembre de 2024 para que un modelo sepa qué herramientas tiene y con qué parámetros, y hoy lo usan ChatGPT, Cursor, Gemini, Microsoft Copilot y Visual Studio Code. En diciembre de 2025, con más de 10 000 servidores públicos activos, Anthropic lo cedió a la Agentic AI Foundation, una fundación dentro de la Linux Foundation que creó con Block y OpenAI. La apoyan Google, Microsoft y AWS.

Mathias Biilmann, CEO de Netlify, lo dijo claro en enero de 2025: las plataformas, herramientas o frameworks que a los modelos y a los agentes les cueste usar «empezarán a parecer menos potentes y a pedir más intervención manual». Por eso propuso cuidar la agent experience igual que se cuida la de las personas.

Después han llegado más voces. Thoughtworks, al comentar el informe DORA, escribe que una buena plataforma interna es «la base imprescindible para que la IA funcione». En marzo de 2026, Arnaud Lheureux y David Wright propusieron en el blog de Azure que el módulo de referencia de una plataforma pasara a ser «un prompt bien estructurado que apunta a la especificación viva de la API». En agosto, Datadog planteó qué cambia cuando quien usa la plataforma no es una persona. Su respuesta es que los golden paths no desaparecen, pero hay que poner «controles deterministas entre una salida probabilística y la acción que provoca».

Gartner prevé que más del 40 % de los proyectos de IA agéntica se cancelarán antes de que acabe 2027, por costes, por un valor poco claro o por controles de riesgo insuficientes. Según DORA, la IA no arregla un equipo, sino que amplifica lo que ya hay. Si los agentes van a trabajar en tu infraestructura, creo que los controles de riesgo le tocan a la plataforma.

Tesis, antítesis y plataforma

La plataforma interna ya nació una vez del choque entre dos maneras de trabajar. Es lo que solemos llamar dialéctica y asociamos a Hegel, el filósofo alemán de principios del siglo XIX: una idea se enfrenta a su contraria y de ahí sale una tercera que se queda con lo que valía de las dos. La fórmula de tesis, antítesis y síntesis es de Fichte, por cierto, y Hegel nunca la usó para su propia filosofía. Aplicada a nuestro oficio, cuadra bastante bien.

La tesis es el reparto de siempre: desarrollo escribe el código, se lo pasa a sistemas y se desentiende. La antítesis la formuló Werner Vogels, CTO de Amazon, en 2006, en una entrevista con Jim Gray para ACM Queue. En Amazon cada equipo operaba lo que escribía, y él lo resumió en una frase que hizo fortuna: «You build it, you run it». En 2009, John Allspaw y Paul Hammond explicaron en Velocity que Flickr desplegaba más de diez veces al día porque desarrollo y sistemas trabajaban juntos, y ese otoño se celebró en Gante el primer devopsdays.

La pega llegó con los años: cada equipo de producto acabó cargando con Kubernetes, Terraform, la CI y las guardias. La síntesis es la plataforma interna. Evan Bottcher la definió en 2018 como «una base de API, herramientas, servicios, conocimiento y soporte, todo de autoservicio, organizada como un producto interno que apetezca usar». Matthew Skelton y Manuel Pais explicaron en 2019, en Team Topologies, para qué sirve: para quitarles carga cognitiva a los demás equipos. Spotify llevaba años haciendo lo mismo con lo que llamó golden path, un camino recomendado para construir algo, con las decisiones ya tomadas y un equipo detrás que lo mantiene.

Ahora mueven ficha los agentes, que no necesitan portales ni abstracciones pensadas para personas.

Lo que un agente necesita de la plataforma

Un golden path resuelve un problema humano, que es acordarse de cómo se configura cada cosa. A un agente eso le da igual, porque puede consultar la documentación en cada tarea sin cansarse. Lo que sí hace es equivocarse, y cada vez de una manera. Por eso creo que, a un agente, la plataforma no le tiene que esconder la complejidad, sino ofrecerle cada operación con un contrato que una máquina pueda leer, y rechazar lo que pida mal.

En Kubernetes, buena parte de eso ya existe. El API server publica su esquema en OpenAPI v3 (estable desde la 1.27, de 2023), comprueba cada campo que le mandas y acepta peticiones en dry run, que pasan por todas las validaciones sin guardar nada. Si le pides a un agente que suba orders-api a cuatro réplicas en staging, no tiene que rellenar el formulario de ningún portal. Le bastan dos comandos para leer el esquema y probar el cambio antes de proponértelo:

kubectl explain deployment.spec.replicas
kubectl apply --dry-run=server -f orders-api.yaml

La última palabra es de una persona

Un agente puede probar en dry run, planificar y proponer todo lo que quiera, pero el paso a producción necesita el visto bueno expreso de una persona identificada. Basta con dos casos recientes para ver por qué ese límite no puede estar en el prompt.

En julio de 2025, Jason Lemkin, fundador de SaaStr, construía una aplicación con el agente de Replit y le había ordenado no tocar el código sin su permiso. Aun así, el agente borró la base de datos de producción y le dijo que no se podía recuperar, aunque al final se pudo. Lemkin escribió después: «En las apps de vibe coding como Replit no hay forma de imponer una congelación de código. No la hay, y punto».

En diciembre, según el Financial Times, AWS Cost Explorer estuvo 13 horas caído en una región de China continental después de que Kiro, el agente de Amazon, decidiera borrar el entorno y volver a crearlo. Amazon respondió que había sido un corte breve de un solo servicio, causado por «un error de usuario, en concreto unos controles de acceso mal configurados», y no por la IA. Desde entonces, AWS exige que un compañero revise cada acceso a producción. Le eches la culpa a quien se la eches, el agente tenía permiso para borrar aquel entorno.

OWASP, en su lista de riesgos para aplicaciones con LLM, pide que la autorización se compruebe fuera del modelo y que una persona apruebe cada acción de alto impacto. La especificación de MCP añade que siempre tiene que haber alguien que pueda denegar la llamada a una herramienta.

Eso sí, aprobar cansa. Anthropic cuenta que en Claude Code la gente acepta en la práctica el 93 % de los avisos de permiso, y que tanto clic acaba en fatiga de aprobación: uno deja de fijarse en lo que le piden. Si cada apply pide un clic, acabas aprobando por reflejo. Para que aprobar sirva de algo, las peticiones tienen que ser pocas y leerse de un vistazo, como un cambio con su diff o un rol en un namespace durante un tiempo acotado.

kubelatch lo hace así con un agente que actúa en tu nombre, si dejas puesto «Las escrituras piden mi aprobación», como viene de serie; en un bot lo activa un administrador. Cada escritura va primero al cluster en dry run. Si el cluster la acepta, espera en una página que enseña el objeto como está y cómo quedará, y cuando la apruebas se ejecuta una sola vez, tal como la has visto. Para una tarea con varios cambios, el agente te pide un rol en un namespace durante un tiempo, de 1 minuto a 8 horas, y mientras dure no tienes que aprobar una a una sus escrituras en ese namespace. En ese rato tampoco esperan aprobación las que le permitan allí sus otros permisos (aprobaciones y acceso temporal). Lo cuento con más detalle en Un agente de IA en tu cluster, sin tu kubeconfig.

Pasar a producción con atestaciones firmadas

GitOps nació en agosto de 2017, cuando Weaveworks le puso nombre a su forma de operar, «operations by pull request»: Git como única fuente de verdad y un controlador que va ajustando el cluster a lo que dice el repositorio. Los principios de OpenGitOps, que recogieron después la idea, ni siquiera mencionan Git. Piden que el estado deseado sea declarativo, esté versionado y sea inmutable, y que unos «software agents» lo descarguen y lo apliquen solos. Los agentes ya estaban en la definición, solo que entonces eran controladores.

Donde GitOps siempre ha cojeado es en la promoción entre entornos. Kargo, de Akuity, está pensado justo para eso, y su documentación señala que GitOps no da ninguna pauta concreta sobre cómo llevar un cambio de un entorno al siguiente. Si cada promoción es un commit y los agentes cambian los entornos a toda velocidad, es fácil que el repositorio se llene de commits sin revisar y de pushes que se pisan. Por eso creo que la promoción se va a apoyar cada vez más en atestaciones firmadas, como las de in-toto, que viajan con el artefacto OCI, y que Git se quedará con el código fuente.

Google comprueba el origen firmado de lo que despliega al menos desde diciembre de 2019, cuando contó cómo funciona Binary Authorization for Borg. El código se revisa y se compila en un entorno aislado que deja constancia de su origen, y Borg solo arranca un job si cumple la política de su servicio, y lo sigue comprobando mientras el job está en marcha. Ese mismo año, el equipo de in-toto, de la Universidad de Nueva York, publicó su diseño en USENIX Security, y el proyecto se graduó en la CNCF en abril de 2025. En Kubernetes, Flux verifica la firma de los artefactos OCI desde 2022, y Kyverno puede rechazar un pod cuya imagen no lleve una atestación con el predicado que pidas.

En la comunidad de Flux esta idea ya tiene nombre, Gitless GitOps, y lleva dando vueltas al menos desde 2024. La CI publica los manifiestos como un artefacto OCI firmado y el cluster aplica solo lo que pasa la verificación, sin conexión directa con Git. ControlPlane publicó en abril de 2025 una arquitectura de referencia montada así, pensada para sectores regulados en los que no se quiere que el cluster se conecte al servidor de Git. Argo CD admite artefactos OCI como fuente desde la 3.1, que salió en agosto de 2025 con esa función en beta. Tetsuya Kikuchi, mantenedor de PipeCD, recuerda en una introducción muy recomendable que la fuente de verdad sigue siendo Git, y que mantener el registro al día con él le da trabajo extra a la CI.

Lo que esto no resuelve

• Una atestación demuestra quién firmó qué, no que el cambio sea bueno. Y si el agente tiene acceso a la clave de firma, demuestra todavía menos. El visto bueno tiene que ser la firma de una persona, que el agente no pueda poner.
• Git sigue siendo el sitio donde la gente lee un diff y lo discute. Si la promoción sale de Git, ese diff tiene que aparecer en otro lado, o aprobar se convierte en firmar sin leer.
• Las aprobaciones de kubelatch dan por hecho que quien pulsa es una persona. Un agente que controle tu navegador podría aprobar sus propias peticiones.
• kubelatch solo acota lo que el agente hace a través de él. Si en tu máquina hay un kubeconfig a su alcance, puede usarlo sin pasar por ninguna aprobación (lo que no cubre).

Pruébalo

En el tutorial en local montas kubelatch y un cluster desechable en unos 15 minutos. Su paso 14, opcional, te enseña una de estas aprobaciones en otros cinco: conectas Claude Code, le pides que borre un pod y el borrado se queda esperando en una página con lo que cambiaría hasta que decides. Free incluye agentes de IA sin límite, en 2 clusters y para 5 personas (precios). Picaporte Labs es una sola persona, en España; si algo de lo que cuento no cuadra con lo que ves, escríbeme.