Il ciclo di vita dello sviluppo degli agenti è arrivato su Cloudflare

Negli ultimi decenni, i responsabili tecnici si sono dedicati a trovare soluzioni che consentissero a numerosi programmatori di collaborare su una base di codice condivisa. Questo lavoro risale addirittura al "Systems Development Lifecycle" (RAND, 1975), oggi comunemente noto come "ciclo di vita dello sviluppo del software (SDLC)", che definisce le seguenti fasi:

• Pianificazione
• Progettazione
• Implementazione
• Test
• Distribuzione
• Mantenimento
• Ritiro

L'intelligenza artificiale ha trasformato la fase che prima era la più lenta e costosa, ovvero l'implementazione, nella più rapida ed economica. Ciò, a sua volta, ha avuto un impatto a valle: ha sovraccaricato le persone responsabili di tutte le altre fasi del ciclo di vita dello sviluppo del software (SDLC). Si va dai manutentori open source bombardati da migliaia di richieste e problemi pull, agli ingegneri di produzione che cercano di evitare che la produzione fallisca mentre il tasso di consegna del software aumenta di ordini di grandezza.

Stiamo tutti cercando di salvare i nostri sistemi, i nostri clienti e noi stessi dalla negligenza.

La risposta, paradossalmente, è dare agli agenti più potere di azione. È giusto così! Non permetteresti mai a un ingegnere del tuo team di scrivere codice aspettandoti che qualcun altro lo convalidi, lo integri, lo distribuisca, lo gestisca in produzione e si occupi della risoluzione dei bug. Ma è quello che la maggior parte delle aziende sta facendo ora con gli agenti. I modelli sono migliorati notevolmente e gli agenti operano su orizzonti temporali più lunghi, essendo in grado di affrontare compiti molto più complessi. Ma non sono ancora utilizzati in modo uniforme lungo tutto il ciclo di vita dello sviluppo del software.

Cloudflare tratta gli agenti come i nostri clienti. Possono acquistare domini, creare account temporanei e utilizzare l'intera API di Cloudflare. Sappiamo che gli agenti hanno bisogno di API e strumenti per poter gestire l'intero ciclo di vita dello sviluppo del software per conto dei nostri clienti, e non solo la fase iniziale.

Oggi presentiamo quindi l'inizio di una nuova serie di strumenti che consentiranno agli agenti di andare oltre la semplice generazione di codice e di assumere un ruolo più attivo nel ciclo di vita dello sviluppo del software (SDLC). Stiamo condividendo ciò che abbiamo creato e imparato cercando di risolvere questo problema per conto nostro:

• @cloudflare/ci, un nuovo modo per eseguire CI/CD su milioni di repository, in grado di autoripararsi e generare agenti per svolgere attività molto più complesse, basato su Cloudflare Workflows.
• Tracce OpenTelemetry in ambiente di sviluppo locale, offrendo agli agenti la stessa osservabilità disponibile in produzione, integrata in Wrangler e nel plugin Cloudflare Vite.
• Presentazione di Cloudflare Agents e Agent Traces: una nuova piattaforma per osservare, gestire e migliorare gli agenti, incentrata sulle tracce OpenTelemetry provenienti dagli agenti.
• Come Cloudflare applica gli standard di ingegneria utilizzando l'IA: la nostra esperienza nell'applicazione delle best practice in tutti i repository e le specifiche dei nostri prodotti e sistemi.
• Come abbiamo creato una software factory per azzerare il numero di problemi di Astro su GitHub: la nostra esperienza nella creazione di sistemi per analizzare, riprodurre, verificare e risolvere automaticamente i problemi di un progetto open source di grandi dimensioni e in continua crescita.

C'è però qualcosa di più importante in gioco. Analizzando il ciclo di vita dello sviluppo del software (SDLC), anche con la migliore automazione, i suoi presupposti non sono scalabili rispetto al volume di codice che gli agenti possono scrivere e alla velocità con cui i team di sviluppo software devono operare per essere competitivi. Riteniamo sia giunto il momento di sostituire l'SDLC con l'ADLC, ovvero il ciclo di vita dello sviluppo degli agenti.

L'SDLC è per i team software. L'ADLC è per le fabbriche di software.

In questo momento, tutti stanno parlando di costruire "fabbriche di software": sistemi basati su agenti che prendono gli input e costruiscono, migliorano, distribuiscono e gestiscono autonomamente il software. Prendi un input, che si tratti di un errore di produzione, una segnalazione di bug da parte di un cliente o un'idea per una nuova funzionalità, e delegalo interamente a un agente.

Anche con l'ausilio di agenti, la maggior parte dei progetti software è vincolata da fasi di intervento umano. Gli operatori umani sollecitano gli agenti, li incoraggiano a proseguire, li istruiscono ad applicare il feedback ricevuto durante una revisione del codice, supervisionano costantemente molti agenti e forniscono loro istruzioni. Nella maggior parte dei team di sviluppo software, le persone gestiscono ancora ogni fase del modello SDLC: l'unica differenza è che all'interno di ogni fase vengono delegati compiti a un agente.

E così il sogno alla base delle software factory diventa: e se si ripensasse questo approccio e si costruisse una fabbrica per l'intero processo di sviluppo del software? Come possiamo dedicare più tempo umano alle cose che richiedono davvero ispirazione, gusto e giudizio umani? Ci lascerebbe più tempo per progettare, per parlare con i clienti e per sognare in grande.

Una software factory deve gestire le stesse fasi del ciclo di vita dello sviluppo del software, ma richiede molto di più dalla piattaforma su cui è costruita. Perché quando consegni le chiavi e lasci guidare l'agente, ogni passaggio manuale che prima si basava su un operatore umano deve essere adattato per essere:

• Programmatico: il "ClickOps" era una cattiva prassi per gli operatori umani, ma è inaccettabile per gli agenti. Ogni singola operazione necessita di API che gli agenti possano richiamare, sottoporre a debug e su cui possano fare affidamento.
• Scalabile orizzontalmente: le implementazioni di anteprima erano un'opzione desiderabile quando gli utenti fissavano lo schermo durante la compilazione o prendevano manualmente il controllo di un server di staging per individuare i problemi prima della produzione. Affinché gli agenti possano guidare, ogni agente deve avere la propria anteprima che corrisponde alla produzione.
• Riproducibile: cosa succede se c'è un bug che puoi riprodurre solo simulando il 4G su un iPhone 15? O da un IP di un determinato paese? I tipici strumenti di test unitari e di integrazione non saranno d'aiuto in questo caso.
• Basato su notifiche push, in tempo reale: affidarsi agli operatori umani per controllare il pannello di controllo corretto è sempre stato un metodo inadeguato per capire se le cose funzionano, ma con gli agenti questo sistema fallisce completamente. Affinché un agente svolga un'azione, è necessario un evento che lo attivi.
• Atomico: ogni modifica deve essere testabile, rilasciabile, osservabile e reversibile in modo indipendente, senza influenzare comportamenti non correlati.
• Autorizzato: sai che probabilmente non dovresti, ma oggi dai a qualche ingegnere fidato le chiavi per accedere tramite SSH all'ambiente di produzione nel caso in cui le cose dovessero andare davvero male. Non si può permettere a un agente di fare una cosa del genere, ma senza la possibilità di inoltrare la richiesta e ottenere maggiori autorizzazioni, come può svolgere il suo lavoro?
• Auto-miglioramento: le persone imparano dall'esperienza. Durante la prima settimana di lavoro o il primo turno di reperibilità, gli operatori umani sono lenti e hanno bisogno di affiancare qualcun altro, ma poi migliorano e diventano più veloci. Anche gli agenti hanno bisogno di modi per imparare dall'esperienza.

Abbiamo bisogno di qualcosa di nuovo se vogliamo rendere le software factory sicure da utilizzare per software di produzione reale. Le software factory si trovano ad affrontare la stessa sfida di altri sistemi autonomi come le auto a guida autonoma: la sfida di passare da un funzionamento corretto nell'80% dei casi a un tasso di successo superiore al 99%.

Per dare agli agenti le chiavi per guidare il ciclo di vita dello sviluppo del software, non puoi dare loro un'auto progettata per gli esseri umani.

Un veicolo autonomo è carico di sensori e tecnologia che una normale auto non ha. Sensori Lidar, telecamere, potenti unità di calcolo per eseguire inferenze e connettività a un sistema di comando centrale che può intervenire da remoto se necessario.

Perché un veicolo autonomo raggiunga l'80% delle prestazioni di un essere umano alla guida, probabilmente non abbiamo bisogno di tutto questo. La guida autonoma ha raggiunto circa l'80% delle prestazioni umane già 10 anni fa. Ma questo non è l'obiettivo da raggiungere: l'obiettivo è essere molto migliori e più sicuri di un guidatore umano. Questo è ciò che ci aspettiamo quando consegniamo le chiavi a una macchina, per sentirci sicuri di fare un pisolino mentre guidiamo sulla Highway 101 a 96 km/h. Ed è per questo che i veicoli autonomi dispongono di una tecnologia creata appositamente per la guida autonoma: è ciò che crea fiducia e gestisce i casi limite che non possono essere progettati in anticipo.

Lo stesso vale per il software di guida autonoma. Chiediti: perché non hai ancora lasciato che il tuo agente approvi e unisca automaticamente le sue richieste di pull ai tuoi servizi di produzione? Più alta è la posta in gioco di ciò che costruisci, più lunga sarà quasi certamente la tua lista di motivazioni.

Quando si iniziano ad analizzare non solo tutti gli aspetti che possono andare storti in questo processo, ma anche quelli necessari per realizzare il prodotto giusto per i clienti, la complessità è davvero notevole. Non si adatta a una sequenza lineare di passaggi in un file YAML Actions di GitHub e va ben oltre l'esecuzione di test automatizzati tradizionali. Anche una piccola modifica a un pannello di controllo può avere ripercussioni su ruoli, specializzazioni e strutture organizzative, e le modifiche soggettive sono le più difficili da testare e da delegare. Probabilmente la maggior parte di queste cose al momento non fa parte della tua pipeline CI/CD. Ma dovranno esserlo, se si vuole che si verifichino ancora, pur lasciando il pieno controllo agli agenti che gestiscono la software factory.

Per permettere agli agenti di guidare l'intero processo, abbiamo bisogno di un modo migliore per orchestrare questa serie dinamica di passaggi. Riteniamo che si tratti di un flusso di lavoro, con la capacità di generare container, agenti e browser. Un flusso di lavoro in grado di impostare flag di funzionalità e abilitarli per un utente di test, analizzare log e tracce, osservare le metriche di produzione durante il rilascio graduale di una modifica e svolgere tutte le altre attività necessarie per una distribuzione sicura.

Una pipeline CI/CD è semplicemente un flusso di lavoro. Ma un flusso di lavoro può essere molto più di una pipeline CI/CD.

Cloudflare Workflows ti permette di concatenare più passaggi, riprovare automaticamente le attività non riuscite e mantenere lo stato per minuti, ore o persino settimane. È progettato per codificare processi aziendali complessi e dinamici in un programma logico e facilmente comprensibile. Questo post del blog spiega perché i flussi di lavoro, insieme agli artefatti, semplificano notevolmente la definizione e l'attivazione delle pipeline CI/CD. Ad esempio:

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,
      },
    });

I flussi di lavoro vanno oltre una serie di passaggi lineari. Possono essere definiti dinamicamente e possono generare agenti o altri flussi di lavoro. Questo esempio mostra un flusso di lavoro che esamina i nuovi dati del giorno precedente. Il flusso ha il pieno controllo su quando e come viene richiesto all'agente di intervenire e può trasmettere il contesto tra le diverse fasi:

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 volta individuato questo schema, e dopo essere stati "sommersi dal flusso di lavoro" come Cloudflare, si inizia a chiedersi: cos'altro potrei gestire con un flusso di lavoro? Quali altri passaggi critici dovuti all'intervento umano potrei delegare a questa combinazione di flusso di lavoro e agenti Flue?

L'intero ADLC, sulla stack di Cloudflare

Con i flussi di lavoro in grado di orchestrare passaggi complessi e gli artefatti come livello di archiviazione per il codice, quando si osservano le fasi del SDLC, tutto ciò di cui un agente ha bisogno per gestire l'intero processo di costruzione, distribuzione e manutenzione del software è su Cloudflare:

Primitive per costruire la tua software factory

In questo momento, coloro che sono all'avanguardia stanno costruendo le software factory del futuro. Alla fine le software factory diventeranno, proprio come gli agenti e l'IA, il modo normale in cui le persone costruiranno il software. Ma per la maggior parte delle persone e delle organizzazioni, non ci siamo ancora arrivati.

Vogliamo cambiare questa situazione.

Per raggiungere questo obiettivo, ci siamo posti le seguenti domande: come possiamo semplificare e rendere accessibili le cose in modo che chiunque su Internet possa beneficiare di un cambio di paradigma come questo? E quali sono le primitive di base che possiamo rendere accessibili a tutti, dalle startup più piccole alle piattaforme più grandi del mondo?

In questo caso, pensiamo che le primitive siano già qui. C'è ancora molto da fare per connetterle, per continuare a costruire la nostra software factory e imparare da essa, ma ora, oggi stesso, siamo pronti perché tu possa costruire la tua macchina che costruisce la macchina, su Cloudflare. Inizia con @cloudflare/ci, crea un agente e scopri quanta parte del ciclo di vita dello sviluppo del software è possibile automatizzare.