Kodowanie oparte na agentach: panel dyskusyjny z liderami branży

Cześć wszystkim.

W ciągu ostatnich 2 dni usłyszeliście wiele od pracowników Google zajmujących się Androidem.

Pomyśleliśmy, że byłoby miło zakończyć konferencję, słuchając osób z zewnątrz, ze społeczności deweloperów Androida.

Porozmawiamy o kodowaniu agentowym i jego wpływie na rzeczywistość.

Zacznijmy od przedstawienia się.

Nazywam się Ben i pracuję w zespole Android DevRel.

Już raz zabierałem głos podczas tej konferencji, ale przejdźmy do panelu.

Cześć.

Nazywam się Vinay i zajmuję się narzędziami AI w Databricks.

Cieszę się, że tu jestem.

Cześć, nazywam się Luis Artola.

Pracuję w zespole Map Google.

Kieruję zespołami, które używają AI do tworzenia rozwiązań opartych na agentach i ulepszania cyklu tworzenia oprogramowania.

Cześć, nazywam się Annyce Davis.

Pracuję w firmie Ford.

Kieruję kilkoma zespołami inżynierów, którzy opracowują nasze usługi subskrypcji i programów lojalnościowych.

Cześć.

Nazywam się Ty Smith.

Pracuję w Uberze i wspieram naszych deweloperów.

Od bardzo dawna są to urządzenia mobilne.

W ciągu ostatnich kilku lat skupialiśmy się na tym nowym, ekscytującym okresie, w którym się znajdujemy, związanym z narzędziami AI.

Cześć.

Nazywam się Kaushik Gopal.

Pracuję jako główny inżynier w Instacart i prowadzę podcast o tworzeniu aplikacji na Androida o nazwie Fragmented.

Obecnie, jak powiedział Ty, nieco zmieniliśmy strategię i mówimy o rozwoju AI.

OK.

Mamy 30 minut.

Myślę, że czas szybko minie, więc od razu przejdziemy do trudnych pytań.

W Android DevRel zawsze mówiliśmy, że chcemy, aby tworzenie aplikacji było szybsze i łatwiejsze.

Teraz pojawiła się sztuczna inteligencja i słyszeliście, jak mówiliśmy: „To prawda.

Uważamy, że tworzenie aplikacji jest teraz szybsze i łatwiejsze”.

But I want to put it out there, are we actually shipping apps faster, or are we just generating a whole bunch of code that sort of goes nowhere?

Zaczynajmy, Vinay.

OK.

Tak, wszyscy patrzymy na siebie.

Fantastycznie.

Jeśli spojrzymy na same liczby, to zdecydowanie widzimy, że wyniki pod względem PR-ów i linii kodu znacznie przyspieszyły. W rezultacie napotykamy też wyzwania związane ze skalowaniem, nawet jeśli chodzi o takie kwestie jak miejsce przechowywania kodu.

To przyspieszenie jest bardzo realne.

Nie jest jednak oczywiste, jak wpływa to na wyniki. Myślę, że cała branża próbuje ustalić, jakie są odpowiednie dane dotyczące wyników i jak dowiedzieć się, jak wpływają one na wyniki finansowe.

Ale zdecydowanie widzę, jak to działa.

Myślę, że w ciągu ostatnich 6 miesięcy wprowadziliśmy więcej kodu niż w poprzednim, bardzo długim okresie.

W rezultacie zmieniła się nasza strategia dotycząca mierzenia produktywności.

Można to bowiem rozumieć na różne sposoby.

We are trying to figure out how to raise the median, right?

Gdy spojrzymy na wartości odstające i medianę, między tymi 2 kategoriami osób jest różnica od 5 do 10 razy. Skupiamy się na podniesieniu dolnej granicy i mediany, aby te osoby były tak samo produktywne jak ich współpracownicy.

Widzimy kombinację ról.

Niektóre osoby poruszają się znacznie szybciej.

Są osoby, które mają 100 PR-ów dziennie i wykonują niesamowitą pracę.

Ale to jest rodzaj przestrzeni, w której działają.

That's maybe more greenfield, or they're more kind of fluent with the tools.

Widzimy też osoby, które zajmują się bardziej pracą na platformie lub w środowisku brownfield i wspierają inny rodzaj pracy, który może nie być tak przyspieszony, ponieważ muszą poświęcać więcej czasu na ocenę i upewnianie się, że nic się nie zepsuje.

Połączenie tych 2 czynników sprawia, że proces jest znacznie szybszy niż wcześniej. Myślę jednak, że naprawdę interesującą kwestią jest to, czy mimo że dostarczamy więcej, firma faktycznie dostarcza więcej użytkownikom końcowym.

W ciągu ostatniego roku inwestowaliśmy w ten obszar, aby dowiedzieć się, czy szybciej wprowadzamy funkcje, a nie tylko szybciej dostarczamy kod.

Wczesne sygnały wskazują, że tak, ale wygląda to zupełnie inaczej niż w przypadku samych PR-ów.

Myślę, że to, co się stało, jest bardzo wyraźne: ludzie wysyłają znacznie więcej, na przykład liczba PR-ów, liczba wzrosła.

Ale myślę, że nawet teraz wiele osób zastanawia się, jak wykorzystać AI i to narzędzie, które mamy, aby przyspieszyć istniejące procesy.

Zgadza się?

Like, a lot of how we used to ship code before feels like we always thought of like a human as like someone who would shepherd this all the way to production.

Myślę jednak, że teraz widzimy, że to działa.

Wysyłamy więcej.

Ale napotykamy wszystkie wąskie gardła, których wcześniej nie widzieliśmy, prawda?

Wcześniej nie mieliśmy takich problemów, ale teraz przyspieszamy jeden z etapów wieloetapowego cyklu i myślę, że to jest właśnie interesujące.

Teraz dostarczamy więcej, ale jest to jak strumień efektów”.

Pojawiają się więc inne wyzwania.

To bardzo ciekawa kwestia, bo gdy się nad tym zastanowić, jest wiele różnych kroków, ale z ogólnej perspektywy można je podzielić na 3 etapy, prawda?

Jest kodowanie, które wyraźnie przyspiesza.

Gotowość do wdrożenia wersji produkcyjnej obejmuje wiele kwestii, takich jak aspekty prawne i prywatność, oraz rzeczy, które pozwalają na wprowadzenie produktu na rynek, a potem następuje premiera, prawda?

Dostawa oznacza różne rzeczy w zależności od lokalizacji.

Jeśli masz produkt działający całkowicie po stronie serwera, dostawa oznacza prawdopodobnie bardziej usprawniony proces, natomiast gdy dostarczasz coś, co trafia do konsumenta, to eksperymentowanie jest dopiero w połowie drogi, prawda?

Nadal trzeba przeprowadzać wiele eksperymentów i pomiarów. To wiąże się z tym, o czym mówiłeś – czujesz się, jakbyś był w obszarze metropolitalnym, na autostradzie, i nagle trafiasz na wąskie przejście, a potem zaczynasz przyspieszać i myślisz: „Tak, świetnie.

„Idzie mi naprawdę szybko”, ale teraz trafiasz na kolejne wąskie przejście.

AI wyraźnie pokazuje, że punkty tarcia są bardziej widoczne, a niektóre z nich nie mają nic wspólnego z kodowaniem ani technologią.

Chodzi o procesy i ludzi oraz o to, jak można je optymalizować za pomocą AI.

To naprawdę ciekawe wyzwanie, jak usprawnić cały proces.

Jednym z ciekawych aspektów, które bierzemy pod uwagę, jest to, jak duży wpływ na ostateczny kształt produktu ma osoba lub zespół.

Jeśli spojrzymy na nasze wewnętrzne działania, zobaczymy, że wiele zespołów tworzy narzędzia wewnętrzne lub rzeczy, które nie są dostarczane klientom.

Są wysyłane znacznie szybciej, prawda?

Mają pełną swobodę, aby natychmiast przekazać te informacje klientom.

Jeśli masz produkt zewnętrzny, który nadal musi przejść testy z użytkownikiem, albo, no wiesz, czas wdrażania w sklepie z aplikacjami, albo, no wiesz, współpracę z zespołem projektowym i produktowym, wszystkie te inne wąskie gardła się sumują, a osoby piszące kod mają znacznie mniejsze możliwości szybkiego działania.

Dlatego napotykają inne wąskie gardła w systemie.

Myślę, że podział na te 2 obszary naprawdę pokazuje, gdzie można ulepszyć procesy biznesowe.

Zgadzam się. Moim zdaniem inżynieria nigdy nie była wąskim gardłem.

Mówię to od lat.

Inżynierowie mają bardzo uporządkowany sposób działania, a ze strony biznesowej zawsze pojawiało się pytanie: „Na czym polega problem?”.

Otrzymasz 10 różnych odpowiedzi.

A potem: „OK.

Teraz przełóżmy to na rozwiązania z użyciem produktu.

Zastanówmy się nad tym przez chwilę.

Porozmawiajmy trochę o wyglądzie.

Kopnij ją tam”.

Zanim trafi do inżynierów, mniej więcej wiemy, co musimy zrobić.

Następnie próbujemy wejść na Stack Overflow, skopiować i wkleić kilka rzeczy i wysłać to dalej.

Dzięki AI największe przyspieszenie widzę w obszarze zgodności.

Te rzeczy, w których zawsze chcieliśmy zmodernizować XYZ lub szybko uaktualnić wersję Spring Boot.

Robimy to bardzo szybko.

Jeśli chodzi o funkcje, nie zauważyłem znaczącej poprawy.

Wszyscy wspomnieliście, że wąskie gardło mogło się przesunąć i że napotykacie procesy, które kiedyś nie były wąskim gardłem, ale teraz nim są.

Jednak te procesy prawdopodobnie powstały na podstawie trudnych doświadczeń z przeszłości, prawda?

Czy czujesz presję, aby je zmienić? Myślę, że najbardziej oczywistym przykładem jest weryfikacja kodu.

Jak według nas będzie wyglądać przyszłość weryfikacji kodu?

Co robimy obecnie?

Chętnie się dowiem.

To wraca do tego, o czym mówiłem.

Myślę, że wiele z tych wąskich gardeł wynika z tego, że gdybyśmy mieli magiczną różdżkę i mogli na nowo wymyślić inżynierię oprogramowania, mając do dyspozycji AI, czy robilibyśmy to samo?

Na przykład weryfikacja kodu była potrzebna, ponieważ potrzebowaliśmy człowieka, który by to sprawdził, czyli przeprowadził ostateczną kontrolę krzyżową.

Myślę, że to też się zmienia. Na przykład sposób, w jaki myślimy teraz o inspekcjach kodu, może powinien być otwarty na pomysł, że jeśli refaktoryzujesz nazwę lub próbujesz refaktoryzować kod i wiesz, że masz świetne testy, które każdy oczywiście ma.

Mamy AI, która je napisze, więc nie ma problemu.

Nie, chodzi mi o to, czy wykonasz to zadanie lepiej niż ten agent.

Nie wiem, może nie warto poświęcać czasu na sprawdzanie tego.

Z drugiej strony, jeśli wypuścisz błąd i zadzwoni do Ciebie dyrektor generalny, mówiąc: „Hej, to nas kosztuje X dolarów”, możesz zidentyfikować obszary i systemy, które są krytyczne.

To nie jest obszar krytyczny”, a następnie spróbuj ponownie wygenerować obraz.

Nie sądzę, żebyśmy tak dziś działali, prawda?

Dzisiaj jest tak: „Hej, jest PR.

Jestem inżynierem.

Skupiam się na tym.

Będzie rosła.

Proszę Vinaya o inspekcję kodu w środku nocy, bo chcę już scalić kod”.

Może powinniśmy przemyśleć wiele z nich.

Zgadzam się z tym i uważam, że weryfikacja kodu to problem związany z weryfikacją. Mam na myśli to, że w świecie, w którym mam pełne zaufanie do swojej zdolności do weryfikacji, czy nadal weryfikowałbym 100% moich PR-ów?

Raczej nie, prawda?

Weryfikacja kodu ma więc 2 cele.

Jednym z nich jest oczywiście sprawdzenie, czy robimy to, co trzeba, a drugim – edukacja, prawda?

Na przykład ludzie wokół Ciebie wiedzą, co robisz, i mogą się z tym zgadzać lub nie.

Istnieje więc kategoria pracy, którą powinniśmy bez obaw przyspieszać i dbać o to, aby trafiała do kodu, a nawet do wersji.

Może nie dotyczy to wszystkich przypadków, ale myślę, że jest to bardzo wysoka, dwucyfrowa liczba przypadków, których powinno to dotyczyć.

Myślę, że przygotowujemy się do wprowadzenia tych zmian i wszyscy jako społeczność musimy zadbać o to, aby nasze systemy były na nie gotowe, ponieważ nadchodzą.

Nie da się tego uniknąć.

Góra lejka jest bardzo szeroka i obejmuje różne platformy, co pozwala na tworzenie większej liczby PR-ów.

A cały proces jest tak szybki, jak jego najwolniejszy etap.

Dla wielu zespołów oznacza to inspekcje kodu, a zespoły, które działają szybciej, zrozumiały i zaakceptowały tę rzeczywistość.

Tak, i jeśli mamy być ze sobą szczere, to powiedziałabym, że 70% PR-ów, które widziałam, wygląda dobrze.

Gdybyśmy przeszukali wszystkie bazy kodu na świecie, komentarze do PR byłyby tylko takie: „looks good to me”, LGTM, wszędzie.

Częściowo wynika to z tego, że jako inżynierowie czasami przypisujemy sobie więcej zasług, niż nam się należy.

Myślimy, że jesteśmy na dobrej drodze.

„Czy użyli wzorca polecenia?”.

Nie, po prostu mówimy: „OK.

Tak, wygląda dobrze”.

Dlaczego więc nie mogę zlecić tego agentowi?

Myślę, że tak będzie wyglądać przyszłość. Będziemy się zastanawiać, co nam się podoba, jakie są cechy i zachowania, które sprawiają, że tak się czujemy.

Upewnijmy się, że agent szuka tego samego.

Możesz też pomyśleć o różnych sposobach sprawdzania.

Znam osoby, które na Twitterze mówią takie rzeczy:

Where it's like maybe when you verify a PR now, get your agents to do like visualize it in a different way, right?

Hej, pokaż mi, jak było wcześniej.

Pokaż mi, jak to wygląda po.

Pokaż mi napisane przez Ciebie testy, a nie kod, który sprawdzasz wiersz po wierszu.

Ale to wyzwanie… Chciałeś coś powiedzieć, Luis?

Nie, myślę, że to daje do myślenia, prawda?

W ten sposób dojdziemy do momentu, w którym będziesz czuć się komfortowo, pozwalając na zatwierdzanie CL-ów lub PR-ów bez interwencji człowieka.

Będę trochę adwokatem diabła i powiem, że gdy mówimy o tarciu, mamy tendencję do myślenia, że tarcie jest złe, ale jest dobre i złe tarcie.

Moim zdaniem opinie nadal należą do kategorii „dobrych utrudnień”.

Chodzi o to, jak sprawić, aby było to mniej uciążliwe dla deweloperów, prawda?

Czasami nie chodzi o to, jak możemy ulepszyć lub usprawnić ten proces w danym momencie.

Chodzi o to, jak można wykorzystać AI do precyzyjniejszego rozwoju na wcześniejszym etapie.

Bo jeśli po prostu… W zależności od tego, jak używasz AI, dobre dane wejściowe dają lepsze wyniki, a złe dane wejściowe dają naprawdę kiepskie wyniki, prawda?

Myślę, że aby osiągnąć ten atrakcyjny stan końcowy, musimy całościowo ulepszyć proces za pomocą AI od samego początku. AI może pomóc nam lepiej zrozumieć architekturę i stworzyć naprawdę solidne specyfikacje przy mniejszym wysiłku ze strony deweloperów, dzięki czemu kod, który generuje, będzie wyższej jakości.

Dzięki temu proces sprawdzania jest mniej uciążliwy dla deweloperów.

Myślę, że ostateczny stan, który nie byłby tak kontrowersyjny, jest taki, że większość osób widzi, że cały ten kod będzie ostatecznie lądował bez weryfikacji przez człowieka.

Myślę, że w międzyczasie jesteśmy w sytuacji, w której modele stają się coraz lepsze i mniej martwimy się, że popełnią błąd techniczny, a bardziej, że popełnią błąd biznesowy lub że problemem będzie ocena lub pomysł, który się w nich pojawił.

To również jest sygnał, który należy oddzielić na etapie sprawdzania.

Czy powinniśmy sprawdzać każdą linijkę w PR, czy raczej skupić się na intencji, którą chcą przekazać?

Myślimy o tym na kilka różnych sposobów.

Po pierwsze, jak możemy dostarczać użytkownikom bardziej trafne informacje, aby mogli zacząć ustalać priorytety?

Drugie pytanie brzmi: jakie są bezpieczniejsze obszary, w których możemy eksperymentować i szybciej się rozwijać w ramach tego rodzaju programów?

Jak powiedział Kaushik, nie wszystkie obszary wymagają takiego samego rygoru.

Możemy to zidentyfikować i zacząć szybciej udostępniać niektóre funkcje, zmniejszając ryzyko, a jednocześnie zachowując obszary, które są bardziej zorientowane na zgodność z przepisami lub są bardzo podstawowe, z większymi utrudnieniami, dopóki nie dojdziemy do momentu, w którym będziemy ufać nie tylko modelom, ale też danym wejściowym, które do nich trafiają.

były właściwe.

Na przykład refaktoryzacja nowego modułu Androida w aplikacji Uber może być w porządku.

Przejazdy bez opłat dla wszystkich deweloperów aplikacji na Androida. Lepiej sprawdź ten kod.

Muszę to sprawdzić z naszym dyrektorem generalnym.

Przykro mi, Kaushik.

Myślę jednak, że ten problem został już rozwiązany.

Mamy już flagi funkcji.

Mamy już wdrożenie metodą blue-green.

Mamy już wiele elementów.

Problem polega na tym, że byliśmy zbyt zajęci, żeby się tym zająć.

Korzystamy już ze śledzenia zachowań.

Mamy wszystkie te dane, ale są one rozproszone w różnych systemach.

Śledzimy już incydenty.

Mamy tak dużo danych, ale brakuje nam możliwości zebrania ich wszystkich w jednym miejscu, aby uzyskać pełny obraz.

Gdy w końcu dowiemy się, jak wygląda taka usługa kontekstu inżynieryjnego we wszystkich tych firmach, nie będziemy musieli się już martwić, ponieważ nawet jeśli PR zostanie scalony, będzie bezpieczny.

Wiemy, że mamy to za flagą funkcji.

Mamy wdrożenie metodą blue-green.

Mamy wszystkie funkcje dostrzegalności.

Możesz wtedy z pełnym przekonaniem powiedzieć: „Dodaj to do potoku”.

Jeśli coś pójdzie nie tak, mamy po drodze wszystkie te zabezpieczenia i bramki.

Myślę, że szybkość odpowiedzi też jest bardzo ważna, prawda?

Jeśli na przykład wprowadzasz zmianę w Androidzie, która musi zostać udostępniona w Sklepie Play, a następnie wdrożona u użytkowników, możliwość natychmiastowego wprowadzenia poprawki jest bardzo ograniczona. Jeśli jednak robisz coś, co ma wewnętrzne wdrożenie z wewnętrzną dostrzegalnością i agentem, który natychmiast się tym zajmuje, masz o wiele więcej możliwości szybszego działania.

Jedno z moich pytań dotyczy tego, że trzeba wykonać pewne działania w tych aplikacjach, ale są też aplikacje typu greenfield, które są łatwiejsze, i aplikacje typu brownfield. W pewnym momencie trzeba poświęcić czas na przeprowadzenie wielu kontroli, aby móc rozszerzyć wykorzystanie AI.

Wiem, że wielu z Was pracuje nad ogromnymi aplikacjami.

Jakie jest Twoje podejście do tej kwestii?

Czy to wygląda tak: „Hej, prezesie, daj mi 3 miesiące, żebym mógł przygotować tę aplikację na AI”, czy raczej dodajesz coś codziennie?

Tak.

I tak nigdy tego nie robią.

Raczej nie.

Większość firm nigdy nie będzie miała takiego luksusu.

Myślę, że musimy poświęcić temu tyle samo uwagi, co długowi technologicznemu, czyli np. 20% czasu na to, a 5% na ulepszanie prompta.

Następnie zrozumieć, co robi prompt, i ulepszyć kontekst.

Jak już wspominaliśmy, wielu inżynierów nadal nie rozumie, jak to działa.

Wciąż wydaje się to bardzo magiczne i mistyczne, więc nie konfigurują i nie dostrajają go w sposób, który pozwoliłby im uzyskać lepszą wartość i wydajność.

Myślę, że musi nadejść moment, w którym liderzy zadadzą sobie pytanie: „Co musimy zrobić, aby podnieść poziom naszego zespołu, żeby zrozumiał, jak to działa, i żebyśmy mogli osiągnąć więcej?”.

To także kontynuacja.

Ponieważ zmiany zachodzą tak szybko, gdybym poprosił zespół o poświęcenie tygodnia w tej chwili na poznanie najnowszych i najlepszych rozwiązań oraz zastosowanie ich w praktyce, a potem nie mieliby czasu na dalszą naukę i eksperymentowanie, to w przyszłym roku bylibyśmy daleko w tyle za nowymi możliwościami.

Dlatego musimy działać na bieżąco, czyli budować samolot w trakcie lotu. Wprowadzamy zabezpieczenia, uczymy się i dostosowujemy do sytuacji, a zespoły muszą być na bieżąco.

W dużych organizacjach są zespoły, które starają się wyodrębnić niektóre z tych informacji i uczynić je bardziej zrozumiałymi i przystępnymi.

Jest to jednak obecnie wyzwanie dla wszystkich w branży.

Chcę trochę urozmaicić ten proces.

Wielu z Was pracuje w infrastrukturze deweloperskiej.

Tysiące PR-ów, czy Twoja infrastruktura testowa, serwery, wszystko się topi?

Chętnie posłucham też opowieści o bitwach.

Ty?

Tak.

Idą jak burza.

Mój CI płacze, gdy s- płacze, gdy płaczę przed snem każdej nocy.

Praktycznie wszystkie nasze zespoły zajmujące się infrastrukturą dla deweloperów borykają się obecnie z problemami ze skalowaniem i wydajnością obliczeniową.

Wiesz, mamy tu czerwone alarmy.

Zauważają ogromny wzrost liczby konwersji.

Wprowadzamy zmiany w architekturze agentów.

Staramy się jak najszybciej rozszerzyć zdalne wykonywanie kompilacji i buforowanie za pomocą Bazela. Zastanawiamy się, czy cała gałąź główna musi być zawsze zielona, czy możemy zacząć wprowadzać poprawki z agentami w niektórych obszarach. Analizujemy też liczbę zgłoszeń od inżynierów i staramy się wprowadzać takie rozwiązania jak samonaprawiająca się CI czy krótsze pętle informacji zwrotnych. Wszystkie zespoły aktywnie inwestują w te obszary, aby nadążyć za wzrostem, zachowując przy tym pewien poziom wydajności.

ale jest to niezwykle trudne.

Zgadzam się ze wszystkim, co powiedział Ty. Myślę, że to również zmusza nas do refleksji i szczerego pytania, czy jesteśmy gotowi na 10-krotny wzrost od tego momentu.

Większość osób prawdopodobnie odpowie, że nie.

W związku z tym, myśląc o przyszłości, staramy się celowo dopasować nasze ambicje do skali, którą może obsłużyć infrastruktura.

AI sprawiła, że wszyscy staliśmy się bardziej ambitni, ponieważ już zauważyliśmy znaczący skok, więc szczerze mówiąc, zmieniamy nasze systemy.

Zastanawiamy się, jaki inny system może się zepsuć, i co możemy zrobić, aby temu zapobiec, żeby nie było to dla nas zaskoczeniem.

W rzeczywistości staramy się unikać niespodzianek.

Tak, dopóki czujemy, że mamy kontrolę, wszyscy są zadowoleni.

Gdy tylko pojawia się niespodzianka, wiem, że to zła wiadomość dla wszystkich.

Zgadza się?

To dobry moment, aby się zastanowić, spojrzeć wstecz, przeprowadzić audyt i ustalić, co może się zepsuć w następnej kolejności, bo na pewno coś się wydarzy.

To nieuniknione.

Chcemy tylko wyprzedzić sytuację.

Słyszałem ciekawy cytat z wypowiedzi prezesa firmy Inflow.

Opisywała, że Google potrzebowało około 20 lat, aby osiągnąć miliard linii kodu, które ma obecnie, a przy obecnym tempie rozwoju wiele naszych firm osiągnie podobną skalę w ciągu zaledwie kilku lat dzięki przyspieszeniu rozwoju AI.

Nie sądzę, aby wszystkie firmy były gotowe na infrastrukturę na poziomie Google do celów programistycznych.

W związku z tym czy Twoje firmy stosują jakiś limit wydatków?

Jak radzicie sobie z tym, że niektórzy deweloperzy zużywają teraz tokeny na wszystko, czyli cały czas korzystają z najlepszego możliwego modelu?

Czy masz jakieś sprawdzone strategie, czy lepiej dać im wolną rękę, bo eksperymentowanie przynosi świetne rezultaty?

Ubiegły rok był rokiem eksperymentów.

Wykonaj wszystkie czynności.

A nawet w pierwszej połowie tego roku, wystarczyło używać go rozsądnie.

Od września obowiązują limity tokenów.

Dlatego deweloperzy mają limity wykorzystania tokenów.

Mamy też instrumentację, dzięki której można sprawdzić, czy sesje są dobre i zdrowe.

Co oznacza, że sesja jest prawidłowa?

Czy masz tyle etapów na sesję?

Czym jest tura?

Staramy się więc używać narzędzi, aby edukować deweloperów.

Myślę, że to dopiero pierwszy krok.

Wiesz, musisz wiedzieć, że masz problem, zanim będziesz mógł go rozwiązać.

Dzięki temu widzą, że nie jest to bezpłatne.

Wcześniej wydawało się, że AI jest bezpłatna.

Ludzie po prostu z niego korzystali.

Chciałabym, żeby można było powiedzieć „Zmień moją gałąź”, a system odpowiadałby „Nie ma problemu, Annyce, zmienię tę gałąź za 5 USD”.

Teraz dochodzimy do momentu, w którym możesz pomyśleć: „Mogę po prostu przejść do wiersza poleceń i zrobić to samodzielnie, prawda?”.

Myślę, że zaczniemy edukować inżynierów w zakresie rzeczywistych kosztów.

More so like I wouldn't just spin up ECS instances and just like run away from them.

Może gdy AWS pojawił się po raz pierwszy, pomyśleliśmy: „Tak, mogę wydać własną instancję”.

I kosztowaliśmy firmę mnóstwo pieniędzy.

Myślę, że to samo dzieje się teraz z tokenami.

Myślę, że praktyczne ograniczenia dają też naprawdę ciekawe możliwości.

Bo gdy pomyślisz o tym, jak na początku zaczęliśmy używać LLM, to rzucaliśmy im wszystko, prawda?

Analizowały kod, znajdowały rozwiązania i robiły za Ciebie różne rzeczy.

To jednak wiązało się z kosztami.

Branża zaczyna to dostrzegać.

And that actually is forcing developers to think about and organizations to think about, how can you optimize that, right?

Dlaczego? Podam konkretny przykład: jeśli masz generator, który tworzy komponenty interfejsu, i muszą one być zgodne z określoną strukturą, testami jednostkowymi i innymi wymaganiami, dlaczego modele miałyby generować to na bieżąco, skoro możesz mieć deterministyczne narzędzie, które może to dla Ciebie utworzyć?

Istnieje więc wiele możliwości wykorzystania limitów tokenów i użycia na swoją korzyść i zwiększenia efektywności.

Tak, i w tym kontekście wprowadziliśmy limity, przynajmniej w Instacart.

Myślę jednak, że celem niekoniecznie jest ograniczenie korzystania z AI, ale wprowadzenie pewnej higieny lub, jak mówisz, introspekcji, prawda?

Na przykład kiedy warto używać określonych modeli, a kiedy innych.

Nie potrzebujesz Fable ani Astry, żeby sprawdzić godzinę czy zmienić gałąź Git.

Zgadza się?

Możesz poświęcić trochę czasu na napisanie skryptu, który będzie bezpłatny na zawsze.

Nie marnujesz tokenów.

Zgadza się?

Myślę, że jeśli dodasz jakieś ograniczenie, nie musi ono koniecznie ograniczać użycia, ale może pomóc Ci myśleć nieszablonowo, a nie tylko rzucać wszystko na jedną kartę.

Zgadza się?

Zgadzam się z tym, co powiedziałeś – ubiegły rok był rokiem eksperymentów.

W tym roku zastanawiamy się, jak skutecznie z niej korzystać.

Tak.

Te historie również bardzo do nas przemawiają.

Zwłaszcza gdy przechodzimy od eksperymentowania do zrównoważonego połączenia wydajności i odpowiedzialności.

Pochodzą one z różnych inwestycji.

Są to na przykład szkolenia dla deweloperów i widoczność.

Annyce wspominała o koszcie i informacjach o aktywnej sesji.

Inwestycje w bezpieczne ustawienia domyślne, które pomagają unikać niepotrzebnych interakcji, zapewniając, że używane umiejętności są skuteczne i nie powodują regresji.

oraz zapewniając odpowiedzialność za ponoszone koszty.

Mamy limity tokenów.

Gdy deweloper osiągnie te limity, może jednym kliknięciem przesłać uzasadnienie, a jego menedżer może je zatwierdzić.

Jeśli więc ktoś wykonuje świetną pracę, chcemy, aby inni się o tym dowiedzieli.

But, you know, if they're maybe doing something more wasteful or experimental, they couldn't justify to their manager why, you know, why they should be spending money on that, then it helps them kind of keep that in check as well.

Dzięki temu nie tylko nie musimy wykonywać pracy, ale możemy też sprawdzić, czy wybraliśmy właściwy model.

Czy to jest odpowiednia waga?

Oczywiście koszt tych tokenów zaczął spadać pod wpływem presji konkurencyjnej.

Ogólnie rzecz biorąc, to, że nasi inżynierowie myślą o tym, jak dobrze zarządzać pieniędzmi, które im przekazujemy, jest moim zdaniem właściwym i zdrowym podejściem.

W dłuższej perspektywie chcemy całkowicie zdjąć z nich ten obowiązek.

Zgadza się?

Chcesz, aby kierowanie do odpowiedniego modelu i inne podobne funkcje działały automatycznie, bez konieczności zastanawiania się nad nimi.

Tymczasem jest to stan prawidłowy.

Tak.

Myślę, że skupiliśmy się na takich rozwiązaniach jak router modeli, dzięki któremu deweloper nie musi podejmować decyzji, a zadanie jest mapowane na odpowiedni model.

Chodzi też o to, aby mieć odpowiednie pułapki.

Limity tokenów rozpatrujemy na kilka sposobów.

Nigdy nie chcemy blokować dewelopera.

Chcemy jednak mieć pewność, że są momenty, w których możemy się zatrzymać i upewnić, że środki są wydawane na właściwe obszary i we właściwy sposób.

Dlatego wprowadziliśmy na przykład limity dzienne, które deweloper może samodzielnie odblokować.

Wystarczy, że wejdą na portal, klikną przycisk i powiedzą: „Hej, nic zaskakującego się nie wydarzyło.

Mam wszystko pod kontrolą”.

Zgadza się?

To tylko jedna prosta dźwignia, ponieważ wszyscy korzystają z pętli, które mogą działać przez całą noc, a nie chcemy, aby generowały koszty.

To bardzo rozsądne.

Z drugiej strony chcemy też zapewnić naszym deweloperom dostęp do najlepszych modeli.

Jednak w przypadku tej kategorii modeli utworzyliśmy budżet graniczny.

Dlatego obowiązuje budżet miesięczny.

Jest wystarczająco wysoki.

Nie masz blokady.

Jeśli chcesz, aby Twoje konto zostało odblokowane, możesz skorzystać z procedury wyjątku.

Trafia do Twojego menedżera.

To moment, w którym opisujesz, co robisz.

Jako zespół platformy nie podejmujemy decyzji, ponieważ powinny być one podejmowane tam, gdzie wykonywana jest praca.

Jeśli chodzi o korzystanie z modelu granicznego, zapewniamy pełną elastyczność z limitem.

To działa, ponieważ ostatecznie zapewnia przewidywalność procesu.

Zgadza się?

Chcemy mieć pewność, że podczas planowania budżetu na tokeny, co jest wyzwaniem dla wszystkich, uwzględniliśmy to, co planowaliśmy, a te dźwignie nam to umożliwiają.

Wiesz, co mnie fascynuje w tych rozmowach?

Myślę, że to dlatego, że wszyscy pracujemy w firmach.

I wreszcie – firmy.

Dlatego musimy płacić za każdy token.

Zgadza się?

Ale jest też cała strona internetu, na której ludzie korzystają z subskrypcji.

Dla nich to zupełnie inna kalkulacja.

Zgadza się?

Myślę jednak, że to tylko kwestia czasu, zanim wszyscy znajdą się w tej samej sytuacji, w której trzeba będzie myśleć o każdym tokenie.

Wtedy prawdopodobnie trzeba będzie zacząć działać w bardziej odpowiedzialny sposób, tak jak musimy to robić teraz w firmach.

Możesz też pracować w laboratorium, które ma nieograniczony budżet.

A potem po prostu kontynuujesz pracę i tworzysz wiele z tych naprawdę ekscytujących, opartych na AI sposobów pracy, o których jest głośno na Twitterze.

Wszystkie nasze firmy chcą to odzwierciedlić, ale nie chcą wydawać tokenów, które…

Są tu osoby, które pracują w Google.

Jestem bardzo ciekawy.

Jak to działa?

Jaki jest budżet od Google?

Luis, chcesz odpowiedzieć?

Nie sądzę, żebym był odpowiednią osobą do rozmowy o aspektach ekonomicznych.

Google to bardzo duża firma z wieloma różnymi organizacjami.

To idealne podsumowanie, bo właśnie kończy nam się czas.

To było wygodne.

Uratował Cię dzwonek.

To jest moderowanie na najwyższym poziomie.

Pracownicy działu PR są…

Dziękuję naszym panelistom i dziękuję za przybycie na ADS.