El Ciclo de Vida de Desarrollo de Agentes ha llegado a Cloudflare

Durante las últimas décadas, los directores de ingeniería han tratado de encontrar estrategias para que muchos programadores puedan trabajar juntos en una base de código compartida. Este trabajo se remonta al marco “Ciclo de Vida del Desarrollo de Sistemas” (RAND, 1975), hoy conocido comúnmente como el “Ciclo de Vida del Desarrollo de Software” (SDLC), que define las siguientes fases:

• Planificación
• Diseño
• Implementación
• Prueba
• Despliegue
• Mantenimiento
• Retirada

Con la IA, la implementación, que anteriormente era el paso más lento y costoso, es ahora el más rápido y barato. Eso, a su vez, ha tenido repercusiones a lo largo del proceso: la sobrecarga de las personas encargadas de todos los demás pasos del SDLC, desde los responsables del mantenimiento del código abierto, bombardeado con miles de solicitudes de extracción y problemas, hasta los ingenieros de producción que intentan evitar que caiga la producción mientras se multiplica el índice de entrega de software.

Todos intentamos evitar la mediocridad para nuestros sistemas, nuestros clientes y nosotros mismos.

La respuesta, paradójicamente, es permitir que los agentes puedan hacer más. ¡Es lo más lógico! Nunca permitirías que un ingeniero de tu equipo escribiera código mientras esperas que otra persona lo valide, lo fusione, lo despliegue, se encargue del buscapersonas en producción y gestione los errores entrantes. No obstante, eso es lo que la mayoría de las empresas hacen actualmente con los agentes. Los modelos han mejorado notablemente, y los agentes operan durante horizontes temporales más amplios, y pueden asumir tareas mucho mayores. Pero aún no se utilizan de manera uniforme en todo el SDLC.

Cloudflare trata a los agentes como nuestros clientes. Pueden comprar dominios, crear cuentas temporales y utilizar toda la API de Cloudflare. Sabemos que los agentes necesitan las API y herramientas que les permitan gestionar todo el SDLC en nombre de nuestros clientes, no solo su comienzo.

Por este motivo, hoy presentamos el inicio de un nuevo conjunto de herramientas que permiten a los agentes ir más allá de simplemente generar el código para asumir más tareas del SDLC. Te contamos lo que hemos desarrollado y qué hemos aprendido al intentar resolver esta cuestión para nosotros mismos:

• @cloudflare/ci: esta nueva función, basada en Cloudflare Workflows, permite ejecutar CI/CD en millones de repositorios, ofrece recuperación automática y puede iniciar agentes para realizar tareas mucho más complejas.
• Rastreos de OpenTelemetry en el entorno de desarrollo local: esta función, integrada en Wrangler y el complemento Cloudflare Vite, ofrece a los agentes la misma observabilidad que tienen en producción.
• Presentamos Cloudflare Agents y Agent Traces: un nuevo espacio para la observación, el mantenimiento y la mejora de agentes, centrado en los rastreos de OpenTelemetry de los agentes.
• Cómo Cloudflare aplica estándares de ingeniería utilizando IA: nuestra propia experiencia aplicando las prácticas recomendadas en todos los repositorios y especificaciones de nuestros productos y sistemas.
• Cómo hemos creado una fábrica de software para reducir a cero el número de problemas en GitHub de Astro: nuestra propia experiencia de desarrollo de sistemas para la clasificación, reproducción, verificación y resolución automáticas de problemas para un proyecto de código abierto grande y en crecimiento.

Sin embargo, aquí encontramos algo más importante. Cuando observamos el SDLC, incluso con la mejor automatización, sus suposiciones no se adaptan al volumen de código que los agentes pueden escribir y al ritmo al que los equipos de software deben avanzar para ser competitivos. Creemos que ha llegado el momento de reemplazar el SDLC por el ADLC: el Ciclo de Vida de Desarrollo de Agentes.

El SDLC es para equipos de software. El ADLC es para fábricas de software.

En este momento, todo el mundo habla sobre cómo crear “fábricas de software” (sistemas basados en agentes a los que se proporcionan ciertos datos y que de forma autónoma desarrollan, mejoran, despliegan y gestionan software. Toma una información de entrada específica, ya sea un error de producción, un informe de error de un cliente o una idea para una nueva función, y delégala por completo a un agente.

Incluso con los agentes, la mayoría de los proyectos de software se ven limitados por pasos que requieren intervención humana. Los humanos dan instrucciones a los agentes, les indican que continúen, les ordenan que apliquen comentarios de una revisión de código, vigilan constantemente un gran número de ellos y les dan instrucciones. En la mayoría de los equipos de software, los humanos todavía gestionan cada uno de los pasos del modelo del SDLC. La única diferencia es la delegación de tareas a un agente dentro de cada paso.

De esta forma, el sueño que impulsa las fábricas de software es: ¿y si reinventaras este enfoque y crearas una fábrica para todo el proceso de desarrollo de software? ¿Cómo podemos dedicar más tiempo humano a los aspectos que realmente requieren la inspiración, el buen gusto y el criterio de los humanos? Nos dejaría más tiempo para diseñar, hablar con los clientes y soñar en grande.

Una fábrica de software debe gestionar los mismos pasos del SDLC, pero exige mucho más de la plataforma en la que se basa. Porque cuando transfieres el control al agente y le dejas que tome las riendas, cada paso manual que antes dependía de una persona debe adaptarse para ser:

• Programático: "ClickOps" era una práctica inadecuada para los humanos, pero es inutil para los agentes. Cada operación necesita API a las que los agentes puedan llamar, que puedan depurar y en las que puedan confiar.
• Escalable horizontalmente: las implementaciones de vista previa eran una función adicional pero prescindible cuando las personas miraban la pantalla mientras realizaban tareas de desarrollo o tomaban el control manualmente de un servidor de preproducción para detectar problemas antes del paso a producción. Para que los agentes tomen las riendas, cada agente debe tener su propia vista previa que coincida con el entorno de producción.
• Reproducible: ¿qué sucede si hay un error que solo puedes reproducir al simular 4G en un iPhone 15? ¿O desde una dirección IP en un país específico? En este caso, las herramientas típicas de pruebas unitarias y de integración no serán útiles.
• Basado en notificaciones push en tiempo real: depender de que unas personas miren el panel de control adecuado nunca ha sido la mejor forma de comprobar si todo funcionaba correctamente, pero esta estrategia no sirve en absoluto en el caso de los agentes. Necesitas un evento que desencadene la acción de un agente.
• Atómico: cada cambio se debe poder comprobar, lanzar, observar y revertir de forma independientemente, sin que afecte a ningún comportamiento no relacionado.
• Basado en permisos: aunque sabes que probablemente no deberías, actualmente concedes a algunos ingenieros de confianza las llaves SSH de acceso a producción por si las cosas realmente se complican. De ninguna forma se lo permitirías a un agente. Sin embargo, si un agente no tiene capacidad para escalar y obtener más permisos, ¿cómo puede llevar a cabo su trabajo?
• Automejora: las personas aprenden de la experiencia. Durante su primera semana de incorporación o su primera rotación de guardia, las personas son lentas y necesitan seguir los pasos de algún compañero, pero luego su trabajo mejora y se acelera. De la misma forma, los agentes necesitan maneras de aprender de la experiencia.

Necesitamos algo nuevo si queremos que las fábricas de software sean seguras para utilizar con software de entornos de producción reales. Las fábricas de software afrontan el mismo desafío que otros sistemas autónomos, como los coches autónomos: cómo pasar de un funcionamiento correcto el 80 % del tiempo a un porcentaje superior al 99 %.

Para transferir a los agentes el control del SDLC, no les puedes entregar un vehículo diseñado para las personas

Un vehículo autónomo está cargado con sensores y tecnología que un coche normal no tiene, como sensores Lidar, cámaras y un potente sistema de cómputo para ejecutar inferencias, así como conectividad a un sistema de comando central que puede tomar el control de forma remota si es necesario.

Para que la eficacia de la conducción de un vehículo autónomo alcance el 80 % de la eficacia de la conducción humana, probablemente no necesitemos toda esta tecnología. Hace 10 años que la eficacia de la conducción autónoma alcanzó el 80 % de la de la conducción humana. Pero ese no es el estándar que queremos lograr: el objetivo es que sea mucho mejor y más segura que la conducción humana. Eso es lo que esperamos cuando entregamos el control a una máquina, y poder sentirnos seguros al echar una siesta mientras conducimos por la AP-7 a 100 km/h. Por este motivo, los vehículos autónomos cuentan con tecnología diseñada específicamente para la conducción autónoma; es lo que genera confianza y responde a las imprevisibles situaciones extremas.

Lo mismo ocurre con el software autónomo. Pregúntate, ¿por qué aún no has dejado que tu agente apruebe automáticamente y fusione sus propias solicitudes de extracción con tus servicios de producción? Cuanto mayor importancia tenga lo que estés desarrollando, más larga será casi con toda seguridad tu lista de razones.

Cuando empiezas a desentrañar no solo todas las cosas que pueden salir catastróficamente mal en este proceso, sino también las que son necesarias para desarrollar la solución adecuada para los clientes, resulta especialmente complejo. No encaja en un conjunto lineal de pasos de un archivo YAML de GitHub Actions, y va mucho más allá de ejecutar las pruebas automatizadas tradicionales. Incluso un pequeño cambio en un panel de control puede abarcar roles, especializaciones y estructuras organizativas, y los cambios subjetivos son los más difíciles de probar y delegar. Actualmente, es posible que la mayoría de estas cosas no formen parte en absoluto de tu canalización de CI/CD. Pero deberá incluirlas, si quieres que se sigan realizando, mientras transfieres el control total a los agentes que dirigen la fábrica de software.

Para permitir que los agentes gestionen todo el proceso, necesitamos mejorar la estrategia de orquestación de esta serie dinámica de pasos. Creemos que la respuesta es un flujo de trabajo, con la capacidad de iniciar contenedores, agentes y navegadores. Un flujo de trabajo que puede establecer indicadores de funciones y activarlas para un usuario de prueba, investigar los registros y rastreos, observar las métricas de producción a medida que un cambio se implementa gradualmente, y llevar a cabo todo lo necesario para una implementación segura.

Una canalización de CI/CD es solo un flujo de trabajo. Pero un flujo de trabajo puede ser mucho más que una canalización de CI/CD.

Cloudflare Workflows te permite encadenar varios pasos, volver a intentar automáticamente las tareas fallidas y mantener el estado durante minutos, horas o incluso semanas. Esta solución está diseñada para codificar los procesos empresariales complejos y dinámicos en un programa lógico fácilmente entendible. Esta publicación del blog explica por qué Workflows, junto con Artifacts, simplifica radicalmente la definición y activación de las canalizaciones de CI/CD. Por ejemplo:

import { CIWorkflow } from `@cloudflare/ci`

const deps: CiRunnerResult = await ci.runner({
      name: 'install',
      command: 'bun install --frozen-lockfile',
      cache: { inputs: ['package.json', 'bun.lock'] },
    });

    await Promise.all([
      deps.runner({ name: 'lint', command: 'bun run lint' }),
      deps.runner({ name: 'test', command: 'bun run test' }),
      deps.runner({ name: 'typecheck', command: 'bun run typecheck' }),
      deps.runner({ name: 'build', command: 'bun run build' }),
    ]);

    await deps.runner({
      name: 'deploy',
      command: 'bun wrangler deploy',
      cloudflareCredentials: {
        accountId: this.env.CLOUDFLARE_DEPLOY_ACCOUNT_ID,
      },
    });

Los flujos de trabajo van más allá de una serie de pasos lineales. Se pueden definir dinámicamente y pueden generar agentes u otros flujos de trabajo. Este ejemplo muestra un flujo de trabajo que revisa los datos nuevos del día anterior. El flujo de trabajo tiene el control total sobre cuándo y cómo se dan las instrucciones al agente, y puede transmitir el contexto entre pasos:

import { WorkflowEntrypoint, type WorkflowEvent, type WorkflowStep } from 'cloudflare:workers';
import { init } from '@flue/runtime';
import { Reviewer } from './agents/reviewer.ts';
import { collectFindings } from './shared/nightly.ts';

type Params = { date: string };

export class NightlyReview extends WorkflowEntrypoint {
  async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
    const findings = await step.do('collect findings', () => collectFindings(event.payload.date));

    const agent = init(Reviewer, { id: `nightly-${event.payload.date}` });

    const receipt = await step.do('dispatch review', () =>
      agent.dispatch(`Review these findings:\n${findings}`),
    );

    const review = await step.do('read review', async () => {
      const reply = await agent.read(receipt);
      return { text: reply.text, data: reply.data };
    });

    // ...
  }
}

Cuando observas este patrón, y crees tan firmemente en los flujos de trabajo como Cloudflare, comienzas a preguntarte: ¿qué más podría gestionar un flujo de trabajo por mí? ¿Qué otros pasos limitados por los humanos podría delegar a esta combinación de flujo de trabajo y agentes Flue?

Todo el ADLC, en la plataforma de Cloudflare

Si consideras las etapas del SDLC, todo lo que un agente necesita para gestionar el proceso completo de desarrollo, implementación y mantenimiento de software lo encuentras en Cloudflare, con Workflows, que puede orquestar pasos complejos, y Artifacts como la capa de almacenamiento para el código:

Primitivas para crear tu fábrica de software

En este momento, las personas en la vanguardia de la innovación están creando las fábricas de software del futuro. Con el tiempo, las fábricas de software serán, al igual que los agentes y la IA, el método habitual de desarrollo de software. Pero la mayoría de las personas y organizaciones aún no hemos llegado a ese punto.

Queremos que deje de ser así.

Para ello, nos hemos planteado algunas preguntas: ¿cómo podemos simplificar y hacer accesible todos los recursos para que todos los usuarios en Internet se beneficien de un cambio de paradigma como este? ¿Cuáles son las primitivas de la capa base que podemos poner a disposición de todos los usuarios, desde la startup más pequeña hasta las mayores plataformas del mundo?

En este caso, pensamos que las primitivas ya las tenemos aquí. Quedan cosas por hacer para conectarlas, para seguir creando nuestra propia fábrica de software y aprender de ella. Sin embargo, ahora mismo ya estamos listos para que desarrolles tu maquinaria que desarrollará la maquinaría, en Cloudflare. Comienza con @cloudflare/ci, desarrolla un agente y descubre cuánto del SDLC puedes automatizar.