Programmazione agentica: una tavola rotonda con i leader del settore

Ciao a tutti.

In questi ultimi due giorni, hai sentito parlare molti Googler di Android.

Quindi, abbiamo pensato che sarebbe stato bello concludere la conferenza ascoltando alcune persone esterne, della community, della community di sviluppatori Android.

Parleremo di programmazione agentica e del suo impatto nel mondo reale.

Inizieremo con il presentarci.

Mi chiamo Ben e sono un Android DevRel.

Mi avete già sentito parlare una volta durante questa conferenza, ma passiamo al panel.

Ciao!

Mi chiamo Vinay e mi occupo delle iniziative relative agli strumenti AI di Databricks.

Sono felice di essere qui.

Ciao, sono Luis Artola.

Lavoro per Google Maps.

Guido team che utilizzano l'AI per creare esperienze basate su agenti e migliorare il ciclo di sviluppo del software.

Ciao, sono Annyce Davis.

Lavoro presso Ford.

Guido alcuni team di ingegneri che sviluppano i nostri prodotti per gli abbonamenti e la fidelizzazione.

Ciao a tutti.

Sono Ty Smith.

Lavoro in Uber e supporto i nostri sviluppatori.

È così da molto tempo.

Negli ultimi due anni, l'attenzione si è concentrata su questo nuovo entusiasmante periodo che stiamo vivendo con gli strumenti AI.

Ciao a tutti.

Sono Kaushik Gopal.

Lavoro come Principal Engineer presso Instacart e ho avviato questo podcast sullo sviluppo Android chiamato Fragmented.

Oggi, come ha detto Ty, abbiamo cambiato un po' le strategie e, come sapete, parliamo di sviluppo dell'AI.

Okay.

Abbiamo 30 minuti.

Penso che il tempo volerà, quindi passeremo direttamente alle domande più difficili.

Noi di Android DevRel abbiamo sempre detto di voler rendere più semplice e veloce la creazione di app.

Ora è arrivata l'AI e, come ci avete sentito dire, "È davvero così.

Riteniamo che sia più veloce e facile creare app."

Ma voglio fare una domanda: stiamo davvero rilasciando app più velocemente o stiamo solo generando un sacco di codice che non porta da nessuna parte?

Andiamo, Vinay.

Ok.

Sì, ci guardiamo tutti.

Fantastico.

Quindi, se guardi solo i numeri, vediamo sicuramente che l'output in termini di PR, in termini di righe di codice, abbiamo visto un'accelerazione massiccia e, di conseguenza, stiamo anche affrontando sfide di scalabilità quando si tratta anche di cose come dove stiamo archiviando il nostro codice, giusto?

Quindi questa accelerazione è molto reale.

Ciò che non è ovvio è l'impatto sui risultati e penso che l'intero settore stia cercando di capire quale sia la metrica giusta per i risultati, come sapere l'impatto sui profitti.

Ma sicuramente lo vedo in azione.

Penso che abbiamo rilasciato più codice negli ultimi sei mesi che nel periodo precedente, e anche in questo caso, manterrò l'ambiguità, ma come un periodo di tempo molto lungo.

Di conseguenza, penso che la nostra strategia sia cambiata anche per quanto riguarda il modo di misurare la produttività, giusto?

Perché ci sono vari modi di vederla.

Stiamo cercando di capire come aumentare la mediana, giusto?

Perché se si guardano i valori anomali e la mediana, c'è un delta da 5x a 10x tra queste due categorie di persone e il nostro obiettivo è alzare il livello, alzare la mediana e rendere queste persone produttive quanto i loro colleghi che vediamo essere produttivi.

Vediamo una combinazione di ruoli.

Alcuni si muovono molto più velocemente.

Ci sono persone che hanno un centinaio di PR al giorno e che stanno facendo un lavoro incredibile.

Ma questo è un tipo di spazio in cui operano.

Forse sono più ex-novo o hanno più dimestichezza con gli strumenti.

Vediamo anche persone che sono molto più, sai, nel brownfield o nel lavoro sulla piattaforma, e supportano un tipo di lavoro diverso che forse non è così accelerato perché devono dedicare più tempo al giudizio umano e assicurarsi che le cose non si rompano.

La combinazione di questi due elementi è molto più veloce di prima, ma penso che l'argomento davvero interessante per noi sia: anche se stiamo spedendo di più, l'azienda sta effettivamente spedendo di più agli utenti finali?

Questo è un ambito in cui abbiamo investito nell'ultimo anno per capire se stiamo rilasciando funzionalità più velocemente, non solo codice.

I primi segnali dicono di sì, ma l'aspetto è stato molto diverso rispetto ai semplici PR.

Penso che ciò che è successo sia che, molto chiaramente, le persone stanno rilasciando molto di più, sai, il numero di PR, i conteggi sono, sai, aumentati.

Ma penso che anche in questo momento molti pensino: "Come possiamo prendere l'AI e questo strumento che abbiamo e potenziare i processi esistenti?"

molto utile.

Ad esempio, gran parte del modo in cui spedivamo il codice prima sembra che abbiamo sempre pensato a un essere umano come a qualcuno che avrebbe guidato tutto questo fino alla produzione.

Ma penso che quello che stiamo vedendo ora sia un po' come dire: "Sì, funziona".

Stiamo spedendo altri prodotti.

Ma ci stiamo imbattendo in ogni singolo collo di bottiglia che altrimenti non avremmo visto in un mondo precedente, giusto?

Perché non abbiamo mai riscontrato questi problemi in passato, ma ora stiamo potenziando una parte di un ciclo in più fasi e penso che sia qui che la cosa si fa interessante, ovvero: "Ok.

Stiamo offrendo di più, ma ora è come un fiume in piena di effetti."

Quindi, stiamo affrontando altre sfide.

Questo è un punto molto interessante, perché se ci pensi, ci sono molti passaggi diversi, ma da una prospettiva di alto livello, puoi raggrupparli in tre fasi, giusto?

C'è la programmazione, che è chiaramente in fase di accelerazione.

C'è l'idoneità alla produzione, che include una serie di aspetti come quelli legali, la privacy e tutto ciò che ti consente di lanciare un prodotto, e poi c'è il lancio, giusto?

Inoltre, la spedizione ha un significato diverso a seconda di dove ti trovi, giusto?

Se hai un prodotto completamente lato server, probabilmente la spedizione significa un processo più semplificato, mentre quando spedisci qualcosa che va al consumatore, giusto, come ottenere questo risultato nella sperimentazione è solo come la metà di un percorso, giusto?

Devi comunque fare molti esperimenti e misurazioni, ed è qui che si ricollega a ciò che dicevi, ovvero che ti sembra di essere in un'area metropolitana, in autostrada, e di avere un choke point, e poi inizi ad accelerare e pensi: "Sì, fantastico.

Sto andando molto veloce", ma poi si raggiunge il choke point successivo.

E ciò che l'AI sta rendendo molto evidente è che i punti di attrito sono più chiari e alcuni di questi non hanno nulla a che fare con la programmazione o la tecnologia.

Riguarda i processi, le persone e il modo in cui li ottimizzi con l'AI.

È una sfida davvero interessante su come semplificare l'intero processo.

Un modo interessante in cui stiamo pensando un po' allo spazio è: quanta autonomia ha la persona o il team nel distribuirlo completamente?

Quindi, se guardiamo all'interno, ci sono molti team che magari stanno creando strumenti interni o cose che non vengono spedite al cliente.

Le spedizioni sono molto più veloci, giusto?

Hanno la piena facoltà di distribuire immediatamente i prodotti ai loro clienti.

Se hai un prodotto esterno che deve ancora essere sottoposto a sperimentazione con un utente o, ad esempio, ai tempi di implementazione dell'app store o, ad esempio, alla collaborazione con il design e il prodotto, tutti questi altri colli di bottiglia si sommano e le persone che scrivono il codice hanno molto meno potere di agire rapidamente.

Quindi, si scontrano con gli altri colli di bottiglia del sistema.

Per questo motivo, penso che suddividere questi aspetti in due aree diverse metta davvero in evidenza i punti in cui i processi aziendali potrebbero essere migliorati.

Sì, sono d'accordo e onestamente penso che l'engineering non sia mai stato il collo di bottiglia.

Lo dico da anni.

Il team di ingegneria ha un modo di fare le cose molto rigido e la domanda dell'azienda era sempre: "Qual è il problema?"

Riceverai 10 risposte diverse.

E poi: "Ok.

Ora, traduciamo questo concetto in alcune soluzioni con il prodotto.

Ora, riflettiamo un attimo su questo.

Oh, parliamo un po' di design.

Calciala lì."

Quando arriva al team di ingegneria, sappiamo più o meno cosa dobbiamo fare.

Poi, proviamo ad andare su Stack Overflow, copiamo e incolliamo alcune cose e pubblichiamo il prodotto.

Quindi, con l'AI, i maggiori miglioramenti in termini di velocità si registrano proprio nell'ambito della conformità.

Quelle cose in cui abbiamo sempre voluto modernizzare XYZ o abbiamo sempre voluto eseguire rapidamente l'upgrade della versione di Spring Boot.

Lo stiamo facendo molto velocemente.

Ma per quanto riguarda l'effettiva distribuzione delle funzionalità, non posso dire di aver visto un miglioramento significativo.

Quindi, avete tutti accennato al fatto che forse il collo di bottiglia si è spostato e vi state scontrando con questi processi che prima non erano un collo di bottiglia, ma ora lo sono.

Tuttavia, questi processi probabilmente derivano da lezioni apprese con fatica in passato, giusto?

Quindi, senti la pressione di dover cambiare queste cose? Penso che la più ovvia sia la revisione del codice.

Qual è il futuro della revisione del codice?

Cosa stiamo facendo attualmente?

Quindi sì, mi piacerebbe saperlo.

Questo ci riporta al punto che ho sollevato prima.

Penso che molti di questi colli di bottiglia siano dovuti al fatto che abbiamo pensato a cose come… Se avessi una bacchetta magica, per così dire, e potessi reinventare l'ingegneria del software e avessi l'AI oggi, useremmo molte delle stesse cose? Faremmo le stesse cose?

Ad esempio, la revisione del codice era necessaria perché avevamo bisogno di un essere umano per approvare le cose, per fare quel controllo incrociato finale.

Penso che anche questo stia cambiando, ad esempio, il modo in cui pensiamo alle revisioni del codice ora è che forse dovremmo essere aperti all'idea che, se stai rifattorizzando il nome o stai cercando di rifattorizzare il codice e sai di avere ottimi test, che tutti hanno chiaramente.

Abbiamo l'AI per scriverle, va bene.

No, tipo, sai, farai un lavoro molto migliore di quell'agente?

Non so, forse non vale la pena dedicare tempo alla revisione.

D'altra parte, se stai per rilasciare un bug e, sai, ricevi una chiamata dal tuo CEO che ti dice, "Ehi, questa cosa ci sta costando X dollari", forse dovresti identificare aree e sistemi in cui, "Ehi, questa è un'area critica.

Questa non è un'area critica" e poi prova a ripensare.

Non credo che sia così che operiamo oggi, giusto?

Oggi, invece, è più un: "Ehi, c'è una PR.

Sono l'ingegnere.

Sono concentrato su questa cosa.

Aumenterà.

Chiedo a Vinay di fare una revisione del codice nel cuore della notte, perché voglio solo che questa cosa venga unita."

Invece, forse dovremmo ripensare a molte di queste.

Sono pienamente d'accordo e penso alla revisione del codice come a un problema di verifica. Con questo intendo dire che, in un mondo in cui ho piena fiducia nella mia capacità di verificare qualcosa, continuerei a rivedere il 100% delle mie PR?

Probabilmente no, giusto?

Le revisioni del codice hanno quindi due scopi.

Uno è ovviamente verificare che stiamo facendo la cosa giusta e il secondo è l'istruzione, giusto?

Ad esempio, le persone intorno a te sanno cosa stai facendo e se sono d'accordo o meno con la tua decisione.

Quindi, esiste sicuramente una categoria di lavoro che dovremmo sentirci a nostro agio nell'accelerare e assicurarci che venga integrata nel codice e persino nelle release.

Ora, questo potrebbe non applicarsi al 100% dei casi, ma penso che sia un numero molto alto, a due cifre, a cui dovrebbe applicarsi.

E penso che ci stiamo preparando ad apportare queste modifiche e tutti noi, come community, dobbiamo assicurarci che i nostri sistemi siano pronti, perché sta arrivando.

Non c'è modo di evitarlo.

La parte superiore della canalizzazione è molto ampia e presenta varie piattaforme che ti consentono di creare più PR.

E la tua velocità è pari a quella del passaggio più lento del processo.

Per molti team, questo significa revisioni del codice e i team che si muovono più velocemente hanno onestamente capito e accettato questa realtà.

Sì, e se siamo onesti con noi stessi, direi che il 70% delle PR che ho visto mi sembra buono.

Se cercassimo in tutte le codebase del mondo, i commenti alle PR sarebbero solo "looks good to me", LGTM, ovunque.

In parte, come professionisti dell'ingegneria, a volte ci diamo più credito di quanto meritiamo.

Ci sembra davvero di essere lì.

"Hanno utilizzato il pattern Command?"

No, diciamo solo: "Ok.

Sì, mi sembra tutto a posto."

Allora perché non posso far fare questo a un agente?

Penso davvero che questo sia il futuro che ci aspetta, in cui ci si chiede: "Cosa mi sembra buono?", "Quali sono le caratteristiche, quali sono i comportamenti che mi hanno fatto sentire così?".

And then like let's make sure that the agent looks for the same thing.

Oppure, d'altro canto, prova anche a pensare a modi diversi di recensire, giusto?

Ad esempio, conosco persone che su Twitter dicono questo, giusto?

Ad esempio, quando verifichi una PR, chiedi ai tuoi agenti di visualizzarla in un modo diverso, giusto?

Hey, mostrami un prima.

Mostrami un dopo.

Mostrami i test che hai scritto, invece di rivedere il codice riga per riga.

Ma mette in discussione… Volevi dire qualcosa, Luis?

No, penso che sia un argomento che fa riflettere, giusto?

In questo modo, arriveremo a un punto in cui ti sentirai davvero a tuo agio nel lasciare che i CL, come i PR, vengano eseguiti senza l'intervento umano.

Quindi, farò un po' l'avvocato del diavolo e voglio dire che quando parliamo di attrito, penso che ci sia la tendenza a pensare che l'attrito sia negativo, ma esiste un attrito positivo e uno negativo.

E penso che le recensioni rientrino ancora nella categoria degli attriti positivi.

Si tratta di capire come renderlo meno oneroso per gli sviluppatori, giusto?

A volte non si tratta di come migliorare o rendere più efficiente la revisione in quel momento.

Si tratta di come rendere più preciso lo sviluppo a monte con l'AI, giusto?

Perché se ti limiti a… A seconda di come usi l'AI, ad esempio input validi producono output migliori, ma input scadenti producono risultati davvero scadenti, giusto?

Quindi, non credo che per arrivare a questo stato finale interessante, si debba migliorare in modo olistico il processo con l'AI fin dall'inizio, utilizzando l'AI per comprendere meglio l'architettura, per avere specifiche davvero solide con, sai, meno sforzo da parte degli sviluppatori, in modo che il codice prodotto sia di qualità superiore.

Di conseguenza, le revisioni sono meno problematiche per gli sviluppatori.

Penso che lo stato finale di questo processo, che non dovrebbe essere così controverso, sia che la maggior parte delle persone si renderà conto che tutto questo codice finirà per essere pubblicato senza revisione umana.

Penso che nel frattempo ci troviamo in una situazione in evoluzione in cui i modelli stanno migliorando e siamo meno preoccupati che commettano un errore tecnico, ma più preoccupati che commettano un errore aziendale o che il problema sia il giudizio o l'ideazione che ne è derivata.

Anche questo aspetto viene preso in considerazione nel segnale, quindi è consigliabile separarlo durante la fase di revisione.

Ad esempio, dovremmo fare una revisione riga per riga nella PR o rivedere l'intento che, sai, stanno cercando di portare avanti?

Stiamo pensando di farlo in diversi modi.

La prima è: come possiamo fornire informazioni più pertinenti all'utente in modo che possa iniziare a dare priorità a queste informazioni?

L'altra è: quali sono le aree più sicure in cui possiamo sperimentare e muoverci più velocemente in questo tipo di programmi?

Come diceva Kaushik, non tutte le aree richiedono lo stesso livello di rigore.

Possiamo identificarlo e iniziare a lasciarne andare alcuni più velocemente, riducendo il rischio e mantenendo, ad esempio, le aree più orientate alla conformità o, ad esempio, molto fondamentali con un attrito maggiore fino a quando non arriviamo davvero al punto di fidarci non solo dei modelli, ma anche degli input che li alimentano

Erano le decisioni giuste.

Ad esempio, rifattorizzare un nuovo modulo Android nell'app Uber potrebbe andare bene.

Offre corse gratuite a tutti gli sviluppatori Android, probabilmente vuole controllare quel codice.

Dovrò verificare con il nostro CEO.

Mi dispiace, Kaushik.

Ma penso anche che questo sia un problema risolto.

Abbiamo già i flag di funzionalità.

Abbiamo già il deployment blu/verde.

Abbiamo già molti degli elementi necessari.

La sfida è che siamo stati troppo impegnati per farlo davvero.

Abbiamo già il monitoraggio del comportamento.

Abbiamo tutti questi dati, ma sono in tutti questi sistemi diversi.

Monitoriamo già gli incidenti.

Abbiamo così tanti dati, ma metterli tutti insieme in un'unica traccia completa è il pezzo che manca.

Una volta capito come funziona questo tipo di servizio di contesto di ingegneria in tutte queste diverse aziende, non dobbiamo più preoccuparci perché, anche se la PR viene semplicemente unita, è sicura.

Perché sappiamo che è protetto da un flag di funzionalità.

Abbiamo il deployment blu/verde.

Abbiamo implementato tutte le funzionalità di osservabilità.

In questo modo, potrai dire con sicurezza: "Oh, mettilo nella pipeline".

Se succede qualcosa di brutto, abbiamo tutte queste guardie e questi cancelli lungo il percorso.

Penso che anche la velocità di risposta sia molto importante, giusto?

Se, ad esempio, prendiamo Android, se stai apportando una modifica in Android e questa deve essere distribuita tramite il Play Store e poi implementata per i tuoi consumatori, la tua capacità di applicare immediatamente un hotfix è davvero limitata rispetto a se stai facendo qualcosa che ha un deployment interno con osservabilità interna e un agente che se ne occupa immediatamente, hai molte più opportunità di muoverti più velocemente.

Quindi, una delle domande che avevo per voi è che c'è anche questo problema: c'è del lavoro da fare su queste app, ma poi ci sono queste app greenfield che sono più facili, poi ci sono queste app brownfield e poi c'è questo momento in cui hai bisogno di tempo per inserire molti di questi controlli, in modo da poter proliferare l'uso dell'AI.

So che molti di voi lavorano su app di grandi dimensioni, giusto?

Quindi, mi piacerebbe sapere cosa ne pensi.

È una cosa del tipo: "Ehi, CEO, dammi tre mesi per preparare questa app per l'AI" o, non so, si tratta di aggiungerla ogni giorno?

Sì.

In ogni caso, non lo fanno mai.

Non credo.

La maggior parte delle aziende non avrà mai questo lusso.

Penso che dobbiamo dedicargli lo stesso tempo che dedicavamo al debito tecnologico, ad esempio il 20% del tempo, e di questo il 5% per migliorare un prompt.

E poi anche capire cosa fa il prompt e migliorare il contesto.

Come abbiamo già detto, penso che il motivo principale sia che gli ingegneri non capiscono ancora come funziona.

Sembra ancora molto magico e mistico, quindi non lo configurano e non lo ottimizzano nel modo in cui potrebbero ottenere il massimo valore ed efficienza.

Quindi, penso che debba esserci un punto in cui i leader dicono: "Cosa dobbiamo fare per migliorare il nostro team in modo che possa capire come funziona e poi possiamo ottenere di più?"

È anche una continuazione.

Poiché sta cambiando così rapidamente, se, ad esempio, chiedessi a un team di dedicare una settimana in questo momento per imparare le ultime novità e metterle in pratica, e poi non avessero tempo per continuare a imparare o sperimentare, e ci sentissimo l'anno prossimo, sarebbero significativamente indietro rispetto alle nuove funzionalità.

Quindi, è necessario che tutto questo, sai, è un po' come costruire l'aereo mentre lo pilotiamo, dove mettiamo i guardrail, impariamo e ci adattiamo man mano che le cose accadono, e i team devono rimanere aggiornati.

E nelle grandi organizzazioni ci sono team come alcuni dei nostri che cercano di distillare alcune di queste informazioni e renderle, sai, un po' più comprensibili e digeribili.

Ma è una sfida per tutti nel settore in questo momento.

Mi piacerebbe variare un po'.

Molti di voi lavorano nell'infrastruttura per sviluppatori.

Migliaia di PR, la tua infrastruttura di test, i tuoi server, tutto si sta sciogliendo?

E mi piacerebbe sentire qualche storia di battaglia.

Ty?

Sì.

Sono in fiamme.

Il mio CI piange per s- piange i miei pianti mi fa piangere ogni notte.

Al momento, quasi tutti i nostri team di infrastruttura per sviluppatori stanno affrontando problemi di scalabilità nel calcolo e problemi di efficienza.

Ci sono, sai, codici rossi in corso.

Notano questo enorme aumento del volume.

Stiamo apportando modifiche all'architettura con gli agenti.

Stiamo cercando di fare cose come espandere il più rapidamente possibile la nostra esecuzione e memorizzazione nella cache delle build remote con Bazel, esaminando cose come, ad esempio, come deve essere sempre verde tutto il ramo principale o se possiamo iniziare a correggere in avanti con gli agenti in determinate aree, esaminando il volume proveniente dagli ingegneri, cercando di fare cose come l'auto-riparazione della CI o come i Feedback Loop più bassi, e tutti i team stanno investendo attivamente in tutto questo per cercare di stare al passo con la crescita mantenendo un certo livello di efficienza.

Ma è estremamente difficile.

Sì, sono d'accordo con tutto ciò che ha detto Ty, ma penso che ci costringa anche a riflettere e a chiederci onestamente se siamo pronti a decuplicare i nostri sforzi da questo momento in poi.

Per la maggior parte delle persone, la risposta è probabilmente no.

Di conseguenza, quando pensiamo al futuro, cerchiamo intenzionalmente di abbinare la nostra ambizione alla scalabilità che l'infrastruttura può supportare.

E una cosa che l'AI ha fatto è che ci ha reso tutti più ambiziosi perché abbiamo già visto quel salto significativo, e quindi stiamo onestamente ripensando ai nostri sistemi.

Esatto, pensiamo a quale altro sistema si romperà o prevediamo che si romperà e cosa possiamo fare per anticiparlo in modo che non sia una sorpresa.

In realtà, stiamo cercando di evitare sorprese.

Esatto, finché abbiamo la sensazione di avere il controllo, siamo tutti contenti.

Nel momento in cui ci imbattiamo in una sorpresa, so che si tratta di una brutta notizia per tutti.

molto utile.

Questo è un buon momento per riflettere, guardare indietro, fare un audit e capire cosa si romperà dopo, perché succederà.

È inevitabile.

Vogliamo solo anticipare i tempi.

Ho sentito una citazione interessante del CEO di Inflow.

Ha spiegato che questa è la cronologia che Google ha impiegato per arrivare, non so, ai miliardi di righe di codice che ha ora e, sai, ci sono voluti circa 20 anni, e con l'accelerazione di questo, molte delle nostre aziende guarderanno a una scala simile in un numero ridotto di anni, in base all'accelerazione dell'AI.

E non credo che tutte le aziende siano pronte ad avere un'infrastruttura di livello Google per lo sviluppo.

A questo proposito, le vostre aziende implementano un qualche tipo di limite di spesa?

Ad esempio, come gestisci il fatto che alcuni sviluppatori ora consumano token per tutto, sai, usando sempre il miglior modello possibile.

Ad esempio, hai trovato delle strategie o è meglio lasciarli liberi perché la sperimentazione porta a risultati interessanti?

Direi che l'anno scorso è stato l'anno della sperimentazione.

Fai tutto.

E forse anche la prima metà di quest'anno è stata solo un utilizzo ragionevole.

E ora, da settembre, abbiamo i limiti di token.

Quindi, abbiamo dei limiti per gli sviluppatori sull'utilizzo dei token.

Poi abbiamo la strumentazione, che consente di capire se le sessioni sono buone e sane.

Cosa significa avere una sessione integra?

Hai questo numero di turni per sessione?

Che cos'è un turno?

Quindi, stiamo davvero cercando di utilizzare gli strumenti anche per istruire gli sviluppatori.

Penso che questo sia solo un primo passo.

Sai, devi sapere di avere un problema prima di poterlo risolvere.

Quindi, almeno vedere questo non è senza costi.

Prima, sembrava davvero che l'AI fosse senza costi.

E le persone lo usavano.

Vorrei dire "Cambia il mio branch" e sentirmi rispondere "Nessun problema, Annyce, lo cambio io per te, 5 $", giusto?

Quindi, ora siamo arrivati al punto in cui potresti pensare: "Ok, potrei semplicemente andare alla riga di comando e farlo da me, giusto?"

Quindi penso che inizieremo a formare davvero gli ingegneri sul costo effettivo.

Più che altro, non mi limiterei ad avviare istanze ECS e poi lasciarle lì.

Forse quando AWS è stato lanciato per la prima volta, abbiamo pensato: "Sì, posso spendere la mia istanza".

E stavamo facendo spendere un sacco di soldi all'azienda.

Penso che la stessa cosa stia accadendo ora con i token.

Penso che i limiti pratici offrano anche opportunità davvero interessanti, giusto?

Perché se pensi a come, all'inizio, abbiamo iniziato a utilizzare gli LLM, davi loro tutto, giusto?

Esaminavano il codice, capivano cosa fare e facevano magie per te, giusto?

Ma questo ha un costo.

E in realtà siamo… sai, il settore se ne sta rendendo conto.

Questo costringe gli sviluppatori e le organizzazioni a pensare a come ottimizzare questo aspetto, giusto?

Perché? Ti faccio un esempio concreto: se hai un generatore che produce componenti dell'interfaccia utente e questi devono essere conformi a una struttura specifica, a test delle unità e cose del genere, perché dovresti far generare tutto questo al volo dai modelli, se puoi effettivamente fargli generare uno strumento deterministico che può semplicemente crearlo per te?

Quindi, ci sono molte opportunità per utilizzare i limiti di token e di utilizzo a tuo vantaggio e diventare effettivamente più efficace.

Sì, e in linea con questi temi, abbiamo assolutamente introdotto dei limiti, almeno, come sai, in Instacart.

Ma penso che l'obiettivo non sia necessariamente limitare l'uso dell'AI, ma portare una sorta di igiene o, come dici tu, introspezione, giusto?

Ad esempio, quando è preferibile utilizzare determinati modelli rispetto ad altri.

Sai, probabilmente non hai bisogno di Fable o Astra per sapere l'ora o cambiare un branch Git.

molto utile.

Probabilmente puoi dedicare un po' di tempo alla scrittura di uno script, che sarà sempre senza costi.

In questo modo non vengono sprecati token.

molto utile.

Quindi, penso che se puoi aggiungere un vincolo, questo non deve necessariamente limitare l'uso, ma piuttosto aiutarti a pensare oltre, invece di buttare tutto dentro.

molto utile.

Mi piace quello che hai detto, l'anno scorso è stato l'anno della sperimentazione.

Quest'anno, invece, ci si chiede come utilizzarla in modo efficace.

Sì.

Anche le storie qui ci rispecchiano molto.

Soprattutto passando da una maggiore sperimentazione a, sai, un insieme equilibrato di efficienza e responsabilità.

Questo risultato è il frutto di una serie di investimenti.

Ci sono aspetti come la formazione degli sviluppatori e la visibilità.

Ad esempio, come diceva Annyce, con informazioni e costi della sessione di attività.

Investimenti in impostazioni predefinite sicure che, ad esempio, aiutano a evitare interazioni inutili, assicurandosi che le competenze che utilizzano siano efficienti, cercando regressioni e cose del genere.

e di assumersi la responsabilità dei costi che stanno sostenendo.

Quindi, come sai, abbiamo dei limiti di token.

Quando uno sviluppatore li raggiunge, può fare clic su un pulsante, inserire una giustificazione e il suo responsabile può approvare.

Quindi, se c'è un ottimo lavoro in corso, vogliamo che lo portino a termine.

Ma, sai, se magari stanno facendo qualcosa di più dispendioso o sperimentale, non potrebbero giustificare al loro manager il motivo per cui, sai, dovrebbero spendere soldi per questo, quindi li aiuta anche a tenere sotto controllo questo aspetto.

Questo non solo evita di fare lavoro inutile, ma permette di valutare se il modello scelto è quello giusto.

È il peso giusto?

Ovviamente, il costo di questi token ha iniziato a diminuire con la pressione competitiva.

Ma in generale, il fatto che i nostri ingegneri ci pensino e siano buoni amministratori del denaro che diamo loro è, credo, l'approccio giusto e sano in questo momento.

A lungo termine, l'obiettivo è quello di eliminare completamente questa decisione.

molto utile.

Vuoi un routing automatico del modello e cose del genere, in modo che non debbano mai pensarci.

Nel frattempo, questo è uno stato integro.

Sì.

Penso che gran parte della nostra attenzione sia stata rivolta a cose come il router del modello, in modo da togliere questa decisione allo sviluppatore e cercare di mappare l'attività al modello.

Ma si tratta anche di avere i giusti sistemi di allarme.

Pertanto, consideriamo i limiti di token in diversi modi.

Non vogliamo mai bloccare lo sviluppatore.

Tuttavia, vogliamo assicurarci che ci siano momenti in cui possiamo fare una pausa e assicurarci che il budget venga speso nelle aree giuste e nel modo giusto.

Ad esempio, esistono dei limiti giornalieri, che fungono da semplice sistema di sicurezza che uno sviluppatore può sbloccare autonomamente.

Tutto ciò che devono fare è andare sul portale, fare clic su un pulsante e dire: "Ehi, non è successo nulla di sorprendente.

Ho il controllo."

molto utile.

E questa è solo una semplice leva, perché tutti eseguono loop e questi loop possono essere eseguiti durante la notte e non vogliamo che questo comporti un costo.

Quindi, questo è molto ragionevole.

D'altra parte, vogliamo anche assicurarci che i nostri sviluppatori abbiano a disposizione i modelli migliori.

Tuttavia, per questa categoria di modelli, abbiamo creato un budget di frontiera.

Pertanto, è stato impostato un budget mensile.

È abbastanza alto.

Non sei stato bloccato.

Se hai bisogno di sbloccare l'accesso, esiste una procedura di eccezione.

Viene inviata al tuo responsabile.

È un momento in cui descrivi ciò che stai facendo.

Inoltre, non siamo noi i responsabili delle decisioni in qualità di team della piattaforma, perché queste decisioni dovrebbero essere prese vicino al luogo in cui si svolge il lavoro.

Per quanto riguarda l'utilizzo del modello pionieristico, anche in questo caso offriamo la massima flessibilità con un limite massimo.

Il motivo per cui funziona è che, in ultima analisi, questo approccio introduce la prevedibilità nel processo.

molto utile.

Vogliamo assicurarci che, quando pianifichiamo la spesa per i token, e questa è una sfida per tutti, abbiamo tenuto conto di ciò che avevamo pianificato e queste leve ci consentono di farlo.

Sai cosa trovo affascinante in queste conversazioni?

Penso che sia perché tutti noi lavoriamo in aziende.

E così, le aziende.

Pertanto, dobbiamo pagare per ogni singolo token.

molto utile.

Ma c'è un'intera parte di internet in cui le persone utilizzano i prezzi degli abbonamenti.

Per loro, quindi, il calcolo è molto diverso.

molto utile.

Ma penso che sia solo una questione di tempo prima che tutti si trovino nella stessa situazione in cui bisogna iniziare a pensare a ogni singolo token.

Ed è allora che, sai, probabilmente si verificherà un cambiamento in termini di maggiore responsabilità, come dobbiamo fare ora nelle aziende.

Oppure lavori in un lab all'avanguardia con un budget illimitato.

E poi continui a operare e, sai, a creare molti di questi modi di lavorare davvero entusiasmanti, come quelli nativi dell'AI, che sono ovunque su Twitter.

Tutte le nostre aziende vogliono rispecchiare questo aspetto, ma non pensano di voler spendere i token che…

Abbiamo persone che lavorano in Google qui.

Sono molto curiosə.

Come funziona?

Qual è il budget di Google?

Vuoi rispondere tu, Luis?

Non credo di essere la persona giusta per parlare degli aspetti economici.

Google è un'azienda molto grande con molte organizzazioni diverse.

Ma questo ci porta alla conclusione perfetta, perché siamo in perfetto orario.

È stato comodo.

Salvato dalla campana.

Questa è una moderazione di serie A, gente.

Le persone che si occupano di PR sono…

Quindi, grazie ai nostri esperti e grazie per aver partecipato all'ADS.