El Ciclo de vida de desarrollo de agentes ha llegado a Cloudflare

Los responsables de los equipos de ingeniería pasaron las últimas décadas ideando formas para que muchos programadores trabajen juntos en una base de código compartida. Este trabajo se remonta a todo el "Ciclo de vida del desarrollo de sistemas" (RAND, 1975), hoy en día comúnmente referido como el "Ciclo de vida del desarrollo de software" (SDLC), que define las siguientes fases:

• Plan
• Diseño
• Implementación
• Prueba
• Aplicación
• Mantenimiento
• Retiro

La IA ha hecho que el paso que anteriormente era el más lento y caro, la implementación, sea el más rápido y económico. Eso, a su vez, ha tenido un impacto en la fase posterior: sobrecarga a las personas responsables de todos los demás pasos en el SDLC. Esto abarca desde los responsables del mantenimiento de software de código abierto, bombardeados con miles de solicitudes de extracción y problemas, hasta los ingenieros de producción que intentan evitar que la producción colapse a medida que el ritmo de entrega de software aumenta exponencialmente.

Todos estamos tratando de salvar nuestros sistemas, nuestros clientes y a nosotros mismos del desorden.

La respuesta, paradójicamente, es capacitar a los agentes para que hagan más. ¡Es lo justo! Jamás dejarías que un ingeniero de tu equipo escribiera código, esperando que otra persona lo validara, lo fusionara, lo implementara, mantuviera el sistema en producción y clasificara los errores que llegaran. Pero eso es lo que la mayoría de las empresas están haciendo ahora mismo con los agentes. Los modelos han mejorado notablemente y los agentes operan durante acciones de tiempo más largas, capaces de asumir tareas mucho más grandes. Pero aún no se utilizan de manera uniforme a lo largo del SDLC.

Cloudflare trata a los agentes como si fueran nuestros clientes. Pueden comprar dominios, crear cuentas temporales y utilizar toda la API de Cloudflare. Sabemos que los agentes necesitan las API y las herramientas para poder gestionar todo el ciclo de vida del desarrollo de software (SDLC) en nombre de nuestros clientes, no solo el inicio.

Y así, hoy presentamos el inicio de un nuevo conjunto de herramientas que permiten a los agentes ir más allá de solo generar código y asumir más del SDLC. Compartimos lo que hemos construido y aprendido al tratar de resolver esto por nosotros mismos:

• @cloudflare/ci: una nueva forma de ejecutar CI/CD en millones de repositorios, que puede autorrecuperarse y crear agentes para realizar tareas mucho más complejas, construido sobre Cloudflare Workflows.
• Rastreos de OpenTelemetry en el entorno de desarrollo local : esta función, integrada en Wrangler y el complemento Cloudflare Vite, brinda a los agentes la misma observabilidad que tienen en producción.
• Presentamos Cloudflare Agents y Agent Traces: un nuevo espacio para observar, mantener y mejorar agentes, centrado en los rastreos de OpenTelemetry de los agentes.
• Cómo Cloudflare aplica estándares de ingeniería usando IA: nuestra propia experiencia aplica las mejores prácticas en todos los repositorios y especificaciones de nuestros productos y sistemas.
• Cómo construimos una fábrica de software para reducir a cero el conteo de problemas en GitHub de Astro: nuestra propia experiencia desarrolló sistemas para clasificar, reproducir, verificar y solucionar automáticamente problemas para un proyecto de código abierto grande y en crecimiento.

Sin embargo, aquí hay algo más grande. Cuando miramos el SDLC, incluso con la mejor automatización, sus suposiciones no se adaptan al volumen de código que los agentes pueden escribir ni al ritmo al que los equipos de software deben avanzar para ser competitivos Pensamos que es hora 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, todos están hablando sobre construir "fábricas de software" — sistemas impulsados por agentes que reciben información y de manera autónoma construyen, mejoran, implementan y gestionan software. Toma una entrada, ya sea un error de producción, un informe de error de un cliente o una idea para una nueva función, y delega la tarea completamente en un agente.

Incluso con agentes, la mayoría de los proyectos de software están limitados por pasos que requieren intervención humana. El ser humano instruye a los agentes, indicándoles que continúen, pidiendo a los agentes que apliquen la retroalimentación de una revisión de código, supervisando constantemente a muchos agentes y dándoles instrucciones. En la mayoría de los equipos de software, los humanos aún gestionan cada paso en el modelo SDLC; el único cambio es que delegan tareas dentro de cada paso a un agente.

Así que el sueño detrás de las fábricas de software es: ¿qué pasaría si reinventaras este enfoque y construyeras una fábrica para todo el proceso de creación de software? ¿Cómo podemos dedicar más tiempo humano a las cosas que realmente requieren inspiración, gusto y juicio humanos? Nos dejaría más tiempo para diseñar, hablar con los clientes y soñar en grande.

Una fábrica de software tiene que gestionar los mismos pasos en el SDLC, pero exige mucho más de la plataforma sobre la que está construida. Porque cuando entregas las llaves y dejas que el agente conduzca, cada paso manual que antes dependía de un humano debe adaptarse para ser:

• Programable: "ClickOps" fue una mala práctica para los humanos, pero es un obstáculo para los agentes. Todas las operaciones necesitan API que los agentes puedan llamar, depurar y en las que puedan confiar.
• Escalable horizontalmente: las implementaciones de vista previa eran un elemento agradable cuando las personas miraban la pantalla mientras construían o tomaban el control manualmente de un servidor de prueba para detectar problemas antes de la producción. Para que los agentes conduzcan, cada agente debe tener su propia vista previa que coincida con la producción.
• Reproducible: ¿qué sucede si hay un error que solo puedes reproducir al simular 4G en un iPhone 15? ¿O desde una IP en un cierto país? Las herramientas típicas de pruebas unitarias y de integración no van a ayudar aquí.
• 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 el caso de los agentes. Necesitas un evento que desencadene la acción de un agente.
• Atómico: cada cambio debe ser independientemente comprobable, posible, observable y reversible sin afectar el 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. No hay manera de que permitas a un agente hacer eso, pero sin la capacidad de escalar y obtener más permisos, ¿cómo puede hacer su trabajo?
• Con conocimiento autogestionable: las personas aprenden de la experiencia. La primera semana de envío o la primera rotación de guardia, los humanos son lentos y necesitan seguir los pasos de otra persona, pero luego mejoran y aceleran. Los agentes también necesitan maneras de aprender de la experiencia.

Necesitamos algo nuevo si vamos a hacer que las fábricas de software sean seguras para usar en producción real de software. Las fábricas de software enfrentan el mismo desafío que otros sistemas autónomos, como los autos autónomos: el desafío de pasar de funcionar exitosamente el 80 % del tiempo a alcanzar un número de nueves más allá del 99 %.

Para dar a los agentes las claves para manejar el SDLC, no puedes darles un auto diseñado para humanos

Un vehículo autónomo está equipado con sensores y tecnología que un automóvil regular no tiene. Sensores Lidar, cámaras, sistemas de cómputo sólidos para ejecutar inferencias y conectividad a un sistema de comando central que puede tomar el control de forma remota si es necesario.

Para que un vehículo autónomo sea un 80 % bueno como un humano al conducir, probablemente no necesitemos todo esto. Hace 10 años, los vehículos autónomos llegaron al 80 % de la capacidad de la conducción humana. Pero ese no es el estándar a alcanzar: el estándar es ser mucho mejor y más seguro que un conductor humano. Eso es lo que esperamos cuando entregamos las llaves a una máquina, para sentirnos seguros tomando una siesta conduciendo por la una autopista a 100 km/h. Y es por eso que los vehículos autónomos tienen tecnología diseñada específicamente para la conducción autónoma: es lo que genera confianza y maneja los casos extremos que no se pueden prever con antelación.

Lo mismo ocurre con el software de conducción autónoma. Pregúntate: ¿por qué aún no has dejado que tu agente apruebe y fusione automáticamente sus propias solicitudes de extracción en los servicios de producción? Cuanto más importantes sean las consecuencias de lo que construyes, más larga seguramente será tu lista de razones.

Cuando comienzas a desglosar no solo todas las cosas que pueden salir catastróficamente mal en este proceso, sino también las que son necesarias para construir lo correcto para los clientes, resulta notablemente complejo. No se ajusta a una serie lineal de pasos en un archivo YAML de GitHub Actions, y va mucho más allá de ejecutar pruebas automatizadas tradicionales. Incluso un pequeño cambio en un panel puede abarcar roles, especializaciones y estructuras organizacionales, y los cambios subjetivos son los más difíciles de probar y delegar. La mayoría de estas cosas probablemente no son parte de tu canalización CI/CD en absoluto hoy. Pero deberás 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 dirijan todo el proceso, necesitamos una mejor manera de gestionar esta serie dinámica de pasos. Creemos que la respuesta es un flujo de trabajo, con la capacidad de generar 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 de forma gradual, y gestionar todo lo necesario para una implementación segura.

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

Cloudflare Workflows te permite encadenar múltiples pasos, reintentar automáticamente las tareas fallidas y mantener el estado durante minutos, horas o incluso semanas. Están diseñados para codificar procesos empresariales complejos y dinámicos en un programa lógico y bien conformado. Esta publicación de blog detalla por qué Cloudflare 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 de forma dinámica y pueden generar agentes u otros flujos de trabajo. Este ejemplo muestra un flujo de trabajo que revisa los nuevos datos del día anterior. El flujo de trabajo tiene control total sobre cuándo y cómo se le solicita al agente, y puede trasladar contexto entre los 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 };
    });

    // ...
  }
}

Una vez que ves este patrón y crees que los flujos de trabajo son eficientes, como Cloudflare, empiezas a preguntarte: ¿qué más podría gestionar un flujo de trabajo por mí? ¿Qué otros pasos con limitaciones humanas podría delegar a esta combinación de flujo de trabajo y agentes Flue?

El ciclo completo de ADLC, en la plataforma de Cloudflare

Con Workflows y su capacidad de gestionar pasos complejos, y Artifacts como la capa de almacenamiento para el código, al observar las etapas del SDLC, todo lo que un agente necesita para manejar el proceso completo de construir, enviar y mantener software, está en Cloudflare:

Primitivas para construir tu fábrica de software

En este momento, las personas a la vanguardia están construyendo las fábricas de software del futuro. Eventualmente, las fábricas de software se convertirán, al igual que los agentes y la inteligencia artificial, en la forma normal en que las personas construyen software. Pero para la mayoría de las personas y organizaciones, todavía no estamos en ese punto.

Queremos cambiar eso.

Para hacerlo, las preguntas que nos hemos planteado son: ¿cómo podemos hacer las cosas simples y accesibles para que todos en Internet puedan beneficiarse de un cambio de paradigma como este? ¿Y cuáles son las primitivas de la capa base que podemos abrir a todos, desde la startup más pequeña hasta las plataformas más grandes del mundo?

En este caso, creemos que las primitivas están aquí. Hay más por hacer para conectarlos, para seguir construyendo nuestra propia fábrica de software y aprender de ella, pero ahora, hoy, estamos listos para que construyas tu máquina que construye la máquina, en Cloudflare. Comienza con @cloudflare/ci, crea un agente y observa cuánta parte del SDLC puedes automatizar.