Harness Unscripted London 2026: stare al passo con lo sviluppo del software, alla velocità dell'IA

Gli assistenti di coding possono generare codice rapidamente, ma i team devono comunque compilarlo, esaminarlo, testarlo, proteggerlo, approvarlo, distribuirlo e gestirlo in produzione. Harness ha citato una ricerca che evidenzia un aumento del 180% del volume di codice, a fronte di un incremento del 30% del software rilasciato. Si tratta di dati citati da Harness, non di benchmark indipendenti, ma la tendenza è facile da riconoscere. Quando arriva più codice, ma le code per le revisioni, il triage della sicurezza e l’approvazione delle modifiche rimangono le stesse, il risultato è soprattutto un aumento dei tempi di attesa.

Bansal ha descritto due approcci che non reggono: lasciare che gli agenti di coding portino il software direttamente in produzione oppure mantenere processi ad alta intensità di intervento umano, aggiungendo personale ogni volta che aumentano i volumi. La posizione di Harness è mantenere i controlli e automatizzare le attività che li supportano, così da far crescere la capacità di gestione al ritmo delle modifiche, anziché in proporzione al numero di persone.

Harness sta estendendo le proprie competenze nell’ambito CI/CD con quattro famiglie di agenti:

Due idee hanno guidato le demo. Lo SDLC Knowledge Graph è un livello dinamico che collega repository, build, servizi, ambienti, incidenti, costi, vulnerabilità e policy, perché un agente non può determinare il reale raggio d’impatto di una modifica basandosi soltanto su un repository di codice. Gli agenti operativi trasformano le fasi della pipeline in agenti specializzati, che operano all’interno del modello di policy e di gestione delle identità già esistente nella pipeline. Nell’esempio dal vivo, un agente ha analizzato un job CI non riuscito, preparato una correzione e rieseguito la pipeline.

Bansal ha sostenuto che individuare un numero maggiore di vulnerabilità non serve a molto se la prioritizzazione e la remediation non riescono a tenere il passo. Ha citato un aumento di dieci volte delle vulnerabilità rilevate, attribuito alla loro individuazione tramite modelli di frontiera nell’ambito del Project Glasswing, e un tempo di sei ore prima del primo exploit. Poiché nessuno dei due dati è stato accompagnato da una metodologia completa, è meglio considerarli come esempi della pressione esistente, non come valori universalmente applicabili.

Il keynote si è concluso con un focus sui costi. Harness ha sottolineato che una spesa elevata per l’IA non è di per sé una prova di ritorno sull’investimento e ha mostrato come sia possibile ricondurre i consumi al codice rilasciato o alle transazioni aziendali gestite dagli agenti in fase di runtime. La metrica davvero importante è il costo per miglioramento rilasciato o per risultato conseguito.

Il takeaway più utile si può riassumere in una domanda: se domani il volume delle modifiche raddoppiasse, quale controllo cederebbe per primo e come ve ne accorgereste? Per la maggior parte dei team, la risposta si trova nelle code di revisione, negli arretrati della sicurezza o nelle approvazioni che si rendono necessarie perché nessuno ha raccolto dati sufficienti per decidere con sicurezza.