O czym jest ten film
- Kyle Daigle, dyrektor operacyjny GitHuba, odpowiada na pytanie o ostatnie awarie: programiści przyprowadzają na platformę dziesiątki, a nawet setki swoich agentów, którzy wypychają kod w skali, jakiej GitHub nigdy nie widział.
- Skala wzrostu: rok temu mowa była o miliardzie commitów rocznie, dziś GitHub liczy 7–8 miliardów commitów miesięcznie; w tym roku przybyło więcej kontrybucji niż w dwóch poprzednich latach razem wziętych.
- GitHub przebudowuje fundamentalną architekturę: rozdziela przechowywanie kodu od obliczeń, przenosi pliki do magazynu obiektowego i odchodzi od pełnego kworum przy zapisie refów.
- Migracja do Azure ma się zakończyć między styczniem a marcem; około stu klientów z najbardziej obciążonymi monorepami wciąż czeka, bo to najgorsze scenariusze.
- CI i GitHub Actions stają się nowym wąskie gardłem — według Daigle przyszłością są testy bardziej selektywne, „rozwój sterowany dowodem” i pętle weryfikacyjne zamiast pełnych suit testów.
- Pull requesty nie umierają jako zapis transakcyjny pracy, ale Daigle proponuje nowy model wsparcia open source: przekazywanie opiekunom tokenów na realizację konkretnej funkcji zamiast wręczania im „pracy domowej”.
- Copilot Fusion to nie router modeli: tryby kaskadowy i krytykujący składają wynik z wielu modeli, co ma dawać do 77% oszczędności i 40% szybsze odpowiedzi.
- W kwestii npm i bezpieczeństwa łańcucha dostaw GitHub skanuje pakiety w maszynach wirtualnych, analizuje drzewa zależności i buduje „zaporę pakietów”; przyznaje, że modele pomagające w obronie equally służą atakującym.
- GitHub zostaje przy Gicie — dopóki nie pojawi się coś istotnie (nie o 10%) lepszego; architektury takie jak Scion Anthropic to według niego rozwiązania „nie próbujcie tego w domu”.
- Długoterminowy cel: Git, którego nie trzeba znać — system sam miałby ujawniać użytkownikowi tylko te funkcje, których faktycznie potrzebuje.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Planuj pojemność na ruch agentów, nie ludzi
Na czym polega: Jeden programista, który kiedyś wypychał dziesięć commitów dziennie, dziś generuje setkę pięćdziesiąt — bo większość pracy odwalają jego agenci. Pomnożone przez setki milionów kont daje to skok z miliarda commitów rocznie do 7–8 miliardów miesięcznie.
Jak stosować: Przy planowaniu pojemności własnych systemów (CI, repozytoria, rejestry pakietów, API) licz ruch nie „per developer”, lecz „per developer razy liczba agentów”. Monitoruj liczbę pushów i zapytań na konto, a nie tylko liczbę kont.
Na co uważać: Agenci „nie zachowują się jak ludzie” — wyczerpują limity, tarasują kolejki i wyzwalają blokady w miejscach, o których nikt nie pomyślał przy projektowaniu pod człowieka.
2.Rozdziel przechowywanie od obliczeń
Na czym polega: GitHub porzuca model, w którym te same serwery jednocześnie liczą i przechowują kod, a zapis wymaga kworum z blokadą. Kod trafia do magazynu obiektowego, a refy zapisuje się „optymistycznie” — bez czekania na potwierdzenie wszystkich replik.
Jak stosować: Jeśli wasz system blokuje zasoby w oczekiwaniu na spójność, rozważ odwrócenie kolejności: najpierw zapisz dane, a spójność doprowadzaj do stanu docelowego w tle. Dzięki temu każda gałąź działa szybko niezależnie od innych.
Na co uważać: Podejście optymistyczne przenosi ciężar na mechanizm doganiającej replikacji — trzeba mieć sposób na wykrycie i naprawę rozjazdów, zanim zauważy je użytkownik.
3.Monorepo pod dużym ruchem to najgorszy scenariusz
Na czym polega: Klienci GitHuba uwięzieni w najtrudniejszej fazie migracji to niemal wyłącznie wielkie, intensywnie używane monorepa. Przy stałym merge’owaniu do głównej gałęzi odczuwają najdotkliwsze skutki opóźnień — w stopniu, w jakim zwykłe repozytoria ich nie doświadczą.
Jak stosować: Jeśli monorepo w waszej firmie jest bardzo obciążone, licz się z tym, że narzędzia i usługi zewnętrzne będą działać u was wolniej niż na demo. Rozważ podział szczególnie gorących ścieżek albo odciążenie głównej gałęzi.
Na co uważać: Monorepa mają zalety w erze agentów (wspólny kontekst), ale ich słabości w Gicie nasilają się dokładnie wtedy, gdy ruch rośnie — nie planuj migracji „w biegu”.
4.CI to nowe wąskie gardło — przemyśl, czym jest testowanie
Na czym polega: Daigle twierdzi, że po raz pierwszy cała branża musi na nowo zdecydować, jak wyglądać ma testowanie. To nie będzie ten sam zestaw testów co dotąd, ale też nie ich brak — raczej coś pośrodku: silniejsza selekcja, „dowody” zamiast uruchamiania testów jednostkowych albo pętla weryfikacyjna.
Jak stosować: Zamiast dokupywać procesory, audytujcie suitę testów pod kątem tego, co realnie chroni, a co uruchamiane jest „bo zawsze było”. Testujcie zmienione ścieżki, nie wszystko za każdym razem; rozważcie weryfikację efektu pracy agenta zamiast pełnego przebiegu CI.
Na co uważać: Nawet przy nieograniczonych rdzeniach nieograniczone buildy „dognają was w rachunku” — koszt i czas i tak dopadną, selekcja jest konieczna.
5.Pull request zostaje — jako dokument, nie jako brama
Na czym polega: W zamkniętych projektach i firmach PR-y wciąż pełnią funkcję zapisu transakcyjnego: co zrobiono, dlaczego i jak. Można do nich przypinać też „egzhaust” agenta — pełny ślad jego działań — i analizować go później.
Jak stosować: Traktujcie PR jako element audytowalności pracy agentów: zapis intencji, przebiegu i wyniku. W projektach otwartych, jeśli lawina generowanego kodu przerasta możliwości recenzji, świadome zamknięcie przyjmowania PR-ów jest zasadnym wyborem.
Na co uważać: Recenzja pracy agenta, która zajmuje tyle czasu, że w praktyce oznacza przerobienie jej od nowa, nie tworzy wartości — wartość tworzy samo zgłoszenie (issue) z intencją.
6.Wspieraj open source tokenami na konkretną funkcję
Na czym polega: Idea Daigle: zamiast przysyłać opiekunowi projektu gotową robotę do zweryfikowania, przekazujemy mu środki (tokeny) i opis wymagań — on zgadza się (lub nie) na intencję funkcji i wykonuje ją własnym, sprawdzonym systemem.
Jak stosować: Firmy korzystające z open source mogą finansować konkretne, dobrze opisane potrzeby zamiast generować PR-y „na odporność” opiekunów. Dla opiekunów: komunikujcie, jakie wsparcie jest dla was użyteczne.
Na co uważać: Model wymaga rozliczalności (np. tokenów powiązanych z konkretnym zadaniem), żeby nie zamienił się w kolejną formę presji i „zadań domowych” bez pokrycia.
7.Jeden problem, wiele modeli — kaskada i krytyka zamiast routingu
Na czym polega: Copilot Fusion nie wybiera jednego modelu do zadania. W trybie kaskadowym startuje od najtańszego modelu zdolnego do szkicu, samoocenia się i w razie potrzeby awansuje na inteligentniejszy. W trybie krytykującym jeden model pracuje, a drugi sprawdza jego implementację — w pętli.
Jak stosować: Ten wzorzec można odtworzyć we własnych narzędziach: tanie warianty do prostych kroków, eskalacja tylko tam, gdzie samoocena wykrywa rozjazd z intencją użytkownika, plus drugi model jako recenzent. Efekt GitHuba: zwykle 50–60% taniej i 40% szybciej.
Na co uważać: To coś innego niż „auto mode” — kluczem jest samoocena pośrednich rezultatów i mniej tur rozmowy, nie sam wybór modelu na starcie.
8.„Przynieś własną subskrypcję” ma swoją cenę
Na czym polega: Daigle chciałby pozwolić użytkownikom na podpięcie własnych subskrypcji modeli do aplikacji Copilot, ale zastrzega: cały ruch GitHuba przechodzi przez wewnętrzną bramę, która rozdziela zlecenia między dostawców i dzięki temu obniża opóźnienia oraz liczbę błędów. Bezpośrednie użycie cudzej subskrypcji tego poziomu niezawodności nie daje.
Jak stosować: Przy wyborze między „oficjalnym” dostępem przez API a podpinaniem subskrypcji z别的 kanału, liczcie nie tylko cenę tokenów, ale też niezawodność, opóźnienia i ryzyko zerwania umowy.
Na co uważać: Rozwiązania nieoficjalne bywają łamane zmianami po stronie dostawcy — nie budujcie na nich procesów produkcyjnych.
9.Higiena zależności: zapora pakietów zamiast ślepego instalowania
Na czym polega: GitHub skanuje pakiety npm, „rozpakowując” je w maszynach wirtualnych w poszukiwaniu malware, analizuje drzewa zależności (czy pakiet jest realnie używany) i buduje „zaporę pakietów” — mechanizm wpuszczający wyłącznie zaufane lub dojrzale opublikowane pakiety.
Jak stosować: W firmowych rejestrach i pipeline’ach wdrażajcie zasady „nie instalujemy pakietów świeżo opublikowanych, dopóki nie przejdą weryfikacji”. Korzystajcie z analizy drzewa zależności do wycinania martwych pakietów.
Na co uważać: Daigle mówi wprost: każdy model, który pomaga bronić, może służyć też do ataku — automatyzacja obrony nie zwalnia z czujności.
10.Nie zastępuj zależności kodem wygenerowanym „bo AI umie”
Na czym polega: Daigle przypomina, że pomysł „napiszę sam, więc będę bezpieczniejszy” był już wielokrotnie testowany i nigdy nie kończy się tak, jak jego zwolennicy zakładają. Czasem lepiej pobrać gotowy, dojrzały pakiet i pozwolić AI na automatyzację jego instalacji i użycia.
Jak stosować: Przy decyzji „pakiet czy własny kod generowany przez agenta” liczcie całkowity koszt: utrzymanie, poprawki bezpieczeństwa, aktualizacje. Wiele drobnych, własnych implementacji to większa powierzchnia do zabezpieczenia niż jeden zaufany pakiet.
Na co uważać: Na kuszące demonstracje „zbudowałem w trzy godziny i dziesięć milionów tokenów” często istnieje gotowe, utrzymywane narzędzie — sprawdźcie, zanim generujecie.
Redakcyjne tłumaczenie
Wstęp: „Kyle, co się dzieje z GitHubem?”
Prowadzący: Witacie w Syntax. Naszym gościem jest Kyle Daigle, dyrektor operacyjny GitHuba, i zacznę od razu od pytania pierwszego: Kyle, co się dzieje z GitHubem? Awarie i wszystko w tym stylu. Ludzie są wściekli — zaraz sami zobaczycie ich w komentarzach. Gdybym otworzył tę rozmowę czymkolwiek innym, zjedliby nas żywcem. No więc: co się dzieje?
Kyle Daigle: Nie dość, że zjawiają się sami programiści, to każdy przyprowadza ze sobą dziesięć, sto swoich agentów. Takiego wzrostu ruchu nie widziałem przez trzynaście lat w GitHubie. Bo to już nie wygląda tak, że człowiek… Rozmawiałem w weekend z kimś, kto kiedyś pomiędzy meczami juniorów wypychał może osiem, dziesięć commitów. Dziś zdecydowaną większość tej pracy odwalają jego agenci — w ten weekend, przygotowując się do Universe, poszło ich ze sto pięćdziesiąt.
Prowadzący: No proszę.
Kyle Daigle: A teraz pomnóżcie to przez dwadzieścia dwa i pół miliona ludzi. To jest gigant. Musieliśmy naprawić systemy leżące pod spodem — i nie tylko pod kątem skalowania w poziomie i w pionie, bo to już zrobiliśmy. Weszliśmy w obszar, w którym agenci po prostu nie zachowują się jak ludzie. Psują rzeczy w sposób, którego szczerze mówiąc nie przewidzieliśmy, bo ich zachowanie jest zupełnie inne. Zrobiliśmy sporo dobrych inwestycji, dostępność jest dziś znacznie lepsza. Nie idealna — dla jasności. Jeszcze mamy robotę. A teraz rozmawiamy o wymianie całej infrastruktury Gita i o tym, co nam to da. Więc temat będzie żył. Dziękuję za cierpliwość i wsparcie. I szczerze: ludzie piszą do mnie na Twitterze, widzę to, odpowiadam. Kiedy leżymy, to jest po prostu źle. Dla mnie, dla was, dla wszystkich deweloperów. Musimy działać — musimy sprostać oczekiwaniom.
Skala: od miliarda commitów rocznie do 7–8 miliardów miesięcznie
Prowadzący: Dwie rzeczy. Po pierwsze: dorzuć kilka liczb, bo każdy wykres z ostatnich dwóch lat wygląda jak ścięty pod kątem w górę. O ile to urosło?
Kyle Daigle: Rok temu na Universe wychodziłem na scenę i mówiłem: w tym roku zaliczymy miliard commitów, będzie z tego wielka sprawa. Wcześnie w marcu rozmawialiśmy o miliardzie, dwóch miliardach miesięcznie. Dziś jesteśmy w okolicach siedmiu, ośmiu miliardów commitów miesięcznie. To rośnie w zawrotnym tempie. Nie mamy nawet dobrego sposobu, żeby policzyć, ilu agentów działa na platformie. Wiem za to, że nowych użytkowników przybywa szybciej niż zeszłoroczne „jedna osoba na sekundę” — w tym roku to więcej niż jedna na sekundę.
Prowadzący: Kurczę.
Kyle Daigle: Wiem.
Prowadzący: Trudno ogarnąć taką skalę.
Kyle Daigle: Dlatego początkowo prosiłem zespół od eventu: te liczby są niestrawne, może zrzucimy piłeczki ping-pongowe? Bo jak widzisz pięć piłeczek, a obok pięćdziesiąt tysięcy piłeczek, od razu czujesz różnicę. Nie udało się tego zorganizować — w zamian dostaliście na scenie wizualizację zadań Actions.
Prowadzący: Trzeba było poprosić MythBusters, dla porządku.
Kyle Daigle: Cały budżet, który by na to poszedł, wpompowaliśmy w infrastrukturę podziemną.
Prowadzący: Pamiętam, że MythBusters wyłożyli na piłeczki ping-pongowe kupę kasy — więc tym bardziej doceniamy.
Kyle Daigle: Ale taka jest prawda: sami debatujemy wewnętrznie, czy miliard to dużo, czy mało. To jest ogrom. W tym roku na platformę wypycha się więcej kontrybucji niż w dwóch poprzednich latach razem wziętych.
Prowadzący: O matko.
Kyle Daigle: Te liczby są szalone — co cieszy, bo z jednej strony robimy więcej rzeczy, które nas kręcą, naszych projektów z pasji, a z drugiej wchodzą nowi ludzie i próbują swoich sił po raz pierwszy.
Prowadzący (ogłoszenie sponsorowane): A jeśli chcecie widzieć wszystkie błędy w swojej aplikacji, zajrzyjcie na sentry.io/syntax. Nie warto trzymać w produkcji aplikacji, w którą nie macie wglądu — coś może się sypać, a wy nawet o tym nie wiecie. Sami korzystamy z Sentry od lat i narzędzie jest po prostu świetne.
Nowa architektura: cztery miliony rdzeni i rozdział przechowywania od obliczeń
Prowadzący: Infrastruktura przechodzi wielką modernizację. Opowiedz coś więcej — bo to nie jest po prostu „dokładamy komputery”. Dobrze, dokładamy, ale jestem ciekaw technicznych szczegółów. Co konkretnie robicie?
Kyle Daigle: Do systemu wchodzi cztery miliony dodatkowych rdzeni, głównie pod uruchomienia GitHub Actions…
Prowadzący: Sami zaliczyliście czterdzieści pięć miliardów uruchomień Actions.
Kyle Daigle: Zgadza się. Ruch na Actions jest ogromny, bo wszystko, co jest budowane i testowane, ląduje właśnie tam — to duży kawałek inwestycji. Ale w samej infrastrukturze podstawowej robimy dużą zmianę. Dziś przechowywanie i obliczenia siedzą w Gicie razem, a do utrzymania spójności używamy Spokes — naszego systemu replikacji. Wypychając zmiany, musicie dojść do kworum serwerów, zanim uznamy repozytorium za zapisane. Problem w tym, że na czas dochodzenia do kworum trzeba zakładać blokady — a to potrafi wszystko przeraźliwie spowolnić.
Rozdzielamy więc obliczenia od przechowywania. Kod przejdzie do magazynu obiektowego, a refy — czyli wskaźniki Gita na commity i gałęzie — zaczniemy obsługiwać optymistycznie: nie czekamy na pełne kworum, żeby przyjąć refa. Zapisujemy pliki, a z czasem upewniamy się, że ref pojawił się we wszystkich właściwych miejscach. Przynajmniej nic nie stoi w kolejce, czekając na zapis. Da się na to patrzeć także per ref: jeśli ja siedzę na swojej gałęzi, a ty na swojej, dziś obaj czekamy — czeka cała masa. A na poziomie pojedynczych refów mogę powiedzieć: moment, moja gałąź niech działa szybko, twoja też. Jak mówił Peter z OpenClaw, z którym przy tym projekcie współpracujemy, daje nam to ogromną przewagę, bo możemy opowiedzieć o repozytorium znacznie więcej. Może chcecie repo agresywnie odpytywać — dziś jest to trudne właśnie przez te blokady zapisu i odczytu.
I druga sprawa: z kodem da się zrobić znacznie więcej niż wcześniej, łatwiej. Przy agentach mnóstwo firm robi po prostu bardzo płytkie klony — nikomu nie jest potrzebna cała historia, chodzi o same pliki. Z magazynu obiektowego wydamy je dużo sprawniej niż przeszukując zbiór serwerów, które jednocześnie liczą i przechowują kod — a to podejście jest po prostu znacznie droższe obliczeniowo.
(Informacja dodatkowa: OpenClaw to otwartoźródłowy asystent AI działający lokalnie; w rozmowie pojawia się kilkukrotnie, m.in. w kontekście Petera Steinbergera, programisty aktywnie eksperymentującego z agentami.)
Migracja do chmury: cel na styczeń–marzec
Prowadzący: Jak długo trwa taka przebudowa — od planowania do końca?
Kyle Daigle: Nad migracją pracujemy już dłuższy czas… Zacznę od tego, że sednem jest opóźnienie. Od lat działamy we własnych centrach danych — pewnie, część mocy chmurowych bierzemy na runnery Actions i tak dalej — ale żeby skorzystać z nowej infrastruktury, musieliśmy przenieść do chmury, u nas do Azure, praktycznie wszystko. Inaczej przeskok między środowiskami zabija wydajność przy mocno obciążonych repozytoriach. Wiele lat temu mieliśmy centra danych i na wschodnim, i na zachodnim wybrzeżu — w Spokes to koszmar, bo kworum co i rusz zjada czas. Teraz, gdy zmierzamy do pełnej chmury w wielu regionach, cel jest taki, żeby to domknąć w styczniu, lutym i marcu — i wtedy poczujecie pełnię korzyści. Opisaliśmy na blogu stu klientów, którzy wciąż czekają na pełną migrację, bo trafili w najgorsze scenariusze i wymagają od nas dodatkowej pracy. Ale gdy repozytoria — a zdecydowana większość już jest po drugiej stronie — oraz wszystkie usługi się przeniosą, dostaniecie z GitHuba to najlepsze, co możemy dać.
Prowadzący: A ci w najgorszych scenariuszach — to jakie repozytoria? Wielkie? Ruchliwe?
Kyle Daigle: Niesamowicie ruchliwe, wielkie monorepa. Praktycznie wyłącznie. Monorepa mają swoje zalety, zwłaszcza w erze agentów, ale w świecie Gita mają też wyjątkowe słabości. Przy bardzo dużym ruchu — na przykład gdy ciągle merge’ujecie do głównej gałęzi — dostajecie najgorsze z opóźnień, problemy, których zwykłe repozytoria nie zobaczą. Możemy przenieść i tych klientów, ale chcemy to zrobić wtedy, gdy będziemy mogli od razu dać im pełnię korzyści z chmury — a nie przenieść i zostawić z ogromnym ruchem plus opóźnieniami, bo zapytania chodziłyby do dwóch centrów danych.
Prowadzący: No tak. Wiedziałem, że z monorepami są kłopoty.
Kyle Daigle: On po prostu ma urazę do monorep.
CI jako nowe wąskie gardło — jak testować w erze agentów
Prowadzący: Nie mam tego w pytaniach, ale jestem ciekaw. Sporo osób mówi, że CI — Actions czy cokolwiek używacie — to teraz nowe wąskie gardło, bo generować kod można bez końca. Masz na to zdanie?
Kyle Daigle: Jak dotąd każde wąskie gardło dało się czymś zatkać i przeskoczyć. Ale z Actions, szerzej z CI, jest tak: pewnie, można ciągle dokładać procesory, tylko w pewnym momencie nie będziesz chciał — to drogie, zwłaszcza dla użytkownika. I prawda jest taka, że po raz pierwszy wszyscy musimy zdecydować, jak w tej erze ma wyglądać testowanie. To raczej nie będą te same testy co dotychczas. Nie wierzę też, że będzie to brak testów. Najpewniej coś pomiędzy — i to jest naprawdę problem informatyczny, z którym przyjdzie się zmierzyć: zmienić sposób działania, choćby być znacznie bardziej selektywnym. Pokazaliśmy badania GitHub Next nad rozwojem sterowanym dowodem (proof-driven development) — czyli: zamiast uruchamiać testy jednostkowe, wygenerować i policzyć dowód, że praca została wykonana. Albo pętla weryfikacyjna — OpenClaw odchodzi od wszystkich zautomatyzowanych testów właśnie ku takiej pętli. Moim zdaniem będzie to jakaś kombinacja tych podejść, bo inaczej — nawet przy nieograniczonych rdzeniach — nikt rozsądny nie będzie chciał nieograniczonych buildów. Rachunek i tak was dopadnie.
Prowadzący: Widzę to zresztą na własnym sprzęcie, jak ciągłe uruchamianie tych wszystkich sprawdzeń męczy system. Mieliśmy wczoraj spotkanie grupy i nie uwierzycie, jaka część rozmów szła o testach: „jak u was testy?”, „jak to naprawiacie?”. A ja: nie wiem, nie mam odpowiedzi.
Kyle Daigle: Nikt ich jeszcze nie ma.
Czy pull requesty umierają?
Prowadzący: Padło jednak pytanie: czy pull requesty umarły? Sporo osób zamyka możliwość zgłaszania PR-ów — częściowo dlatego, że nie chce chłamu, który się wlewa, a częściowo dlatego, że to po prostu nie pomaga: odpowiedzi w dyskusji też mogę sobie wygenerować. Wartościowe jest samo issue. Jak to widzisz?
Kyle Daigle: Moim zdaniem pull requesty w projektach zamkniętych — czy to open source, w którym po prostu nie przyjmujesz PR-ów, czy w firmie — wciąż mają sens jako zapis transakcyjny: co zrobiono, dlaczego i jak. Można do nich przypinać cały „egzhaust”, czyli pełny ślad działań agenta, i zaglądać do niego później. Natomiast z opiekunami open source rozmawiałem o czymś innym: co, gdyby można było przekazać ci tokeny — „taka funkcja byłaby mi potrzebna, oto luźny opis wymagań” — zamiast wręczać ci pracę domową, za którą jeszcze zapłacisz? Masz moją subskrypcję, idź to zrób. Bo od opiekunów słyszę wciąż to, co przed chwilą powiedziałeś: wiem, jak to zrobić. Mam harness — narzędzie do sterowania agentami — mam cały system. Pozwól mi jedynie zgodzić się na intencję funkcji, albo nie, i pozwól mi ją zrobić, zamiast patrzeć na twoją pracę i kazać agentowi przerabiać ją od nowa albo spędzić tyle czasu na weryfikacji, że w gruncie rzeczy sam ją wykonuję.
Zastanawiam się, czy w nowej erze GitHub nie mógłby tu pośredniczyć — nie w formie bounty ani zbiórek, tylko po prostu: jestem przekonany do tej funkcji, oto token z jednorazowym identyfikatorem, którego użyjesz do zrobienia tej jednej rzeczy. Nowy sposób budowania wspólnego dorobku, który nie polega na wręczaniu nam wszystkim kolejnych zadań domowych.
Prowadzący: I kup sobie coś ładnego przy okazji. Bo to druga strona medalu: w tym samym oddechu opiekunowie open source wołają: „Anthropic, OpenAI, zasponsorujecie nas? Będzie dla nas jakiś pakiet tokenów?”. Ciekawy pomysł — sam na to nie wpadłem.
Aplikacja Copilot i podpinanie własnych subskrypcji
Prowadzący: Aplikacja GitHub Copilot wygląda świetnie, ale każdy z nas trzyma też inne subskrypcje. Czy do aplikacji Copilot kiedykolwiek trafi logowanie przez ChatGPT albo innych dostawców OAuth?
Kyle Daigle: Dla użytkowników indywidualnych — bardzo bym chciał. Próbujemy wymyślić, jak dać wam to, co sam mam: używam wszystkich osobistych agentów pod słońcem i przeciągam swoje subskrypcje do OpenClaw, Hermesa i reszty. Marzy mi się, żeby deweloperzy mogli dać szansę GitHub Copilotowi — a szczerze mówiąc, może i Copilot Fusion — po prostu przynosząc swoje subskrypcje i pozwalając nam nimi zarządzać. Sporo jest jeszcze do przemyślenia: nie tylko czy to wykonalne technicznie, ale jakie są wady dla użytkownika. Cała nasza AI przechodzi przez bramę, którą nazywamy Capier — od Copilot API. To nasz sposób na zarządzanie tym, dokąd idziemy: przez tę bramę mamy niższe opóźnienia i mniej błędów, bo rozdzielamy ruch między różnych dostawców. Przechodząc przez cudzą subskrypcję, nie dalibyśmy rady tego zapewnić — musielibyśmy zawsze łączyć się bezpośrednio, a to odbija się na jakości. Ale chciałbym, żeby istniał pełnoprawny mechanizm: dodaj tę subskrypcję, dodaj kolejną, dodaj kolejną — i używaj.
Copilot Fusion: nie router modeli, a kaskada i krytyka
Prowadzący: W tym samym nurcie — Fusion. Czy to jest router modeli? Słyszeliśmy zresztą, że routery modeli nie działają jakoś spektakularnie. Co sprawia, że Fusion działa?
Kyle Daigle: Pytanie „czy to router” jest podchwytliwe: czy potrafi kierować zadania do konkretnych modeli? Tak. Czy jest routerem? Według mnie — nie. Copilot Fusion używa wielu modeli do wyprodukowania pojedynczego wyniku i robi to na trzy sposoby. Pierwszy: pojedynczy model — zadanie jest tak proste, że idę do jednego. To w gruncie rzeczy zwykłe routowanie według intencji. Potem są dwa tryby: kaskadowy i krytykujący. Kaskada startuje od najniższego modelu, który jej zdaniem wystarczy do realizacji zadania, szkicuje rozwiązanie i sama się ocenia: czy to pokrywa intencję użytkownika? Jeśli nie — awansuje, skacząc do inteligentniejszego modelu, być może z innej rodziny. I może powtarzać to wielokrotnie, dla różnych części zadania, aż wyda końcowy efekt. W ten sposób nie ma sytuacji „zlecam pracę, system losuje model, może trafi, może nie” — każdy z modeli po drodze prowadzi do lepszego wyniku na końcu kaskady. Trzeci tryb, krytykujący: jeden model zabiera się do roboty, drugi sprawdza jego implementację i wchodzą w pętlę — coś, co myślę, każdy z nas robił ręcznie, między rodzinami modeli. Te dwa ostatnie tryby mamy obecnie i to one składają wiele modeli w jeden wynik — a to zbliża nas do idei „fusion”, a nie zwykłego auto-routera, który wybiera intencję, potem model. Stąd wyniki: jesteśmy dwa punkty od Opusa 55 Max, a przy okazji może wyjść do 77% taniej dla GitHuba i klientów — zwykle jesteśmy 50–60% tańsi — i 40% szybciej, bo kaskada i krytyka generują mniej tur. Model nie musi myśleć, myśleć, myśleć i dalej się wysilać — może powiedzieć „pomyliłem się” i eskalować do kolejnego modelu w łańcuchu. To naprawdę fajne, ale zupełnie inne niż tryby auto czy inne routery jeden-do-jednego.
Prowadzący: Czy to działa tylko w aplikacji Copilot, czy da się użyć w innych harnessach?
Kyle Daigle: Wszędzie tam, gdzie używasz harnessu GitHub Copilot — część logiki intencji obsługujemy po stronie klienta, część po stronie serwera i potrzebujemy obu, żeby działało naprawdę dobrze. Czyli we wszystkich tych miejscach: aplikacja Copilot, którą pokazaliśmy dziś na scenie, VS Code, CLI, github.com, agenci w chmurze i tak dalej.
Prowadzący: Miejsc macie sporo.
Kyle Daigle: Ekran na scenie ma chyba z dwadzieścia metrów szerokości, na najdzikszym projektorze, jaki widziałem, i i tak dało się go wszystkim zapełnić. To nie tylko aplikacja — VS Code, aplikacja mobilna, github.com…
Prowadzący: …a i tak nie wszystko się zmieściło, bo wspieracie całą masę integracji zewnętrznych.
Kyle Daigle: W zasadzie tak.
Prowadzący: Nawet tamagotchi sobie założyliście.
Kyle Daigle: Tak, na identyfikatorze konferencyjnym. Świetne.
npm i bezpieczeństwo łańcucha dostaw
Prowadzący: Porozmawiajmy chwilę o npm i ogólnie o łańcuchu dostaw. npm też skrzypi pod tym całym obciążeniem — pewnie dlatego, że to największe miejsce składowania pakietów. Jak widzisz przyszłość zależności i supply chainu?
Kyle Daigle: Wszyscy właśnie przeżywamy miesiąc, który można nazwać festiwalem incydentów bezpieczeństwa — odkrywamy nowe, nieznane dotąd ataki, a npm jest jednym z przykładów rejestru, przez który to wszystko przechodzi. Problem atakujemy bardzo wprost: zainwestowaliśmy w infrastrukturę, która bierze pakiet, rozkłada go w maszynie wirtualnej i przygląda się mu, żeby wykryć potencjalne malware. Poza tym mamy kilka rzeczy, o których nie mówiliśmy w keynocie: potrafimy analizować drzewo zależności pakietu. Gdy Dependabot zastanawia się, czy danego pakietu potrzebujesz i czy go aktualizować, możemy przejrzeć całą ścieżkę i sprawdzić, czy realnie korzystacie z tego pakietu i jego kodu. A dla większości z nas ważniejsza jest dziś zapora pakietów — możliwość wpuszczania wyłącznie pakietów zaufanych albo publikowanych od jakiegoś czasu, zanim zaczniemy ich używać. To obszar, w którym AI pomaga nam wyłapywać problemy na bieżąco. Ale prawda jest taka, że atakujący mają tę samą broń: każdy model do cyberbezpieczeństwa, który nas broni, jest zarazem modelem, który może atakować — i to mocno komplikuje całą robotę. Pracujemy nad tym, żeby dać przede wszystkim opiekunom open source i wydawcom pakietów te same narzędzia, bez przechodzenia przez cały ból oglądania tych modeli w akcji — bo ostatnio bywało naprawdę boleśnie.
Czy AI zastąpi pakiety z npm?
Prowadzący: Czy dojdziemy do miejsca, w którym po prostu potrzebujemy mniej zależności? Jesteśmy programistami JavaScriptu — żeby napisać wielką literę, robimy npm install. Ale wiele osób mówi: nie potrzebuję zależności, po prostu wygeneruję własną wersję. Jak to widzisz?
Kyle Daigle: Odpowiedź na pytanie „czy potrzebuję tych zależności” w postaci „napiszę własny kod i będę bezpieczniejszy” — tę ścieżkę już przeszliśmy. I nigdy nie kończy się tak, jak wszyscy zakładają. Z generowaniem kodu przez AI jest ten kłopot, że własny kawałek oprogramowania jest oddalony o jedno kliknięcie. Z Frankiem i Paulusem z Home Assistant śmiejemy się za każdym razem, gdy ktoś mówi: „zbudowałem narzędziem AI automatyzację świateł, zajęło mi to tylko trzy godziny i dziesięć milionów tokenów”. A ja na to: po prostu pobierzcie Home Assistant. Leży tam i czeka.
Prowadzący: AI zresztą świetnie pisze pliki YAML do Home Assistanta. Dużo lepiej niż ja.
Kyle Daigle: Dlatego uważam, że coś tu da się zrobić, może przez mechanizm umiejętności — czasem po prostu lepiej wziąć gotowy pakiet. Wziąć pakiet i pozwolić AI zautomatyzować jego użycie, instalację albo instalację całej aplikacji. W ten sposób zabezpieczamy mniej punktów końcowych, zamiast przy każdej zmianie algorytmu kompresji czy czymś podobnym pisać własną wersję, każdy we własnym projekcie. To mi się nie wydaje wykonalne.
Prowadzący: A tak w ogóle — GitHub przyciąga całą uwagę, a npm przecież do niego należy. Na froncie npm jest jakoś cicho. Czy npm w ogóle jest waszym priorytetem? Prawie się o nim nie mówi.
Kyle Daigle: Mamy absolutnie ludzi, którzy pracują wyłącznie nad npm i skupieni są na npm. Współpracujemy też z pozostałymi rejestrami pakietów w świecie Microsoftu — oficjalnymi, nieoficjalnymi, wspieranymi przez GitHub albo Microsoft — żeby je zabezpieczać, finansować i po prostu robić robotę. Gdy GitHub przejmował npm, żeby utrzymać go przy życiu, nagle staliśmy się właścicielem pojedynczej technologii i jednego języka. A u nas nie ma znaczenia język, pakiet ani narzędzie — z GitHubem można używać dowolnych. I pewnie dlatego czasem o tym nie mówimy: nasze DNA jest tak otwarte. Ale niczego nie ukrywamy. Trzymamy npm przy życiu i rozwijamy go, jak wspominałem.
Pytania widzów: Scion, Origin, Lure i przyszłość przechowywania kodu
Prowadzący: Zebraliśmy też pytania od widzów, bo komentarzy będzie mnóstwo. Sasha pyta: jakie jest stanowisko GitHuba wobec nowych architektur przechowywania kodu — Scion u Anthropic, Origin u Cursora, Lure u Epica — i jak GitHub widzi przyszłość przechowywania kodu u siebie?
Kyle Daigle: W zasadzie pokazaliśmy właśnie nasze podejście. Ono, choć ma kilka nowych korzyści, ogólnie wpisuje się w schemat: obiekty trzymamy w jednym miejscu, w czymś na kształt magazynu obiektowego. Anthropic, budując Sciona, konsultował się z nami, a przy premierze sami to opisywali: budujemy pod swój konkretny sposób pracy i własną skalę — „nie próbujcie tego w domu”. Możliwe, że gdy wszyscy będziemy robić po trzydzieści tysięcy PR-ów dziennie, takie rozwiązania staną się normą. Ale gdy pytam opiekunów open source i klientów o ulubiony alternatywny system kontroli wersji — GitHub od zawsze też próbuje różnych rzeczy i buduje różne pomysły. Ja jestem nastawiony na ciągłe ulepszanie Gita, dopóki nie pojawi się coś wyraźnie lepszego. I mam na myśli istotnie lepszego, nie o dziesięć procent — dopiero wtedy powiedzielibyśmy: czas rozejrzeć się za opcjami. Bardzo poważnie podchodzimy do zmiany API, z którego korzystają programiści, a GitHub to przecież kawałek internetu. Doskonale pamiętam dzień, w którym zmieniliśmy jedno API i Xbox Media Center tego dnia przestał działać.
Prowadzący: Serio?
Kyle Daigle: Tak. To jeszcze te dobre stare czasy, gdy pracowałem przy API i platformach. To się naprawdę wydarzyło. Więc machnięcie ręką „wyrzucamy API Gita” to dla nas nie jest decyzja od niechcenia.
Prowadzący: To potężna sprawa. I nazwy byście musieli zmienić — nie dalibyście rady zostać przy nazwie GitHub.
Kyle Daigle: Pracuję tam od 2013 roku i nie zliczę zawziętych dyskusji, czy nie powinno być samo „Hub”.
Prowadzący: Rebranding na Hub!
Kyle Daigle: Zostajemy przy GitHubie.
Prowadzący: Ej, nie podoba mi się… Ale tę historię musicie nam kiedyś opowiedzieć w całości, bo co Halloween robimy odcinek ze strasznych opowieści — akurat o takich potworach.
(Informacja dodatkowa: Xbox Media Center, czyli XBMC, to projekt, z którego wywodzi się znany odtwarzacz Kodi.)
Git bez ezoteryki — pod agenty i pod ludzi
Prowadzący: Ryan pyta: co robicie, żeby jeszcze łatwiej doprowadzać do sukcesu z agentami? Git do dziś jest bardzo ustawiony pod człowieka, a branża nie ustaliła jeszcze wzorców kontroli wersji pod rozwój agentowy — zwłaszcza gdy na problem można rzucić cały rój.
Kyle Daigle: W pełni się zgadzam. Aplikacja GitHub Copilot to obecnie nasz główny punkt skupienia, ale mamy też GitHub Desktop, z którego ludzie korzystają od lat. Opowiedziano mi o parze, w której jedna osoba zbudowała aplikację, a druga powiedziała jej: wrzuć to do Gita, życie ci się uprości. I ta osoba od razu wpadła na podejście pod górę pod kątem czterdziestu, dziewięćdziesięciu stopni — tyle trzeba nadrobić, żeby ogarnąć Gita. Chcemy — czy to przez zestaw umiejętności, czy przez doświadczenie aplikacyjne — ujawniać wam stopniowo tylko te funkcje Gita, których naprawdę potrzebujecie, a właściwe wybory robić pod maską. Nie ma dziś powodu znać na co dzień wszystkich ezoterycznych zakamarków Gita, zwłaszcza gdy uczycie się programować albo budowicie projekty poboczne. Mamy na to eksperymenty — na githubnext.com, stronie naszej grupy badawczej, zobaczycie część prac z ostatniego roku. Ale celem jest zdecydowanie to, żeby nie trzeba było wtłaczać w was wszystkich drobiazgów.
Prowadzący: Dokładnie jak kilka lat temu, gdy VS Code dostał przycisk synchronizacji, który po prostu commitował i wypychał albo pobierał zmiany. Nikogo nie obchodzą szczegóły. „Po prostu synchronizuj” — tego chcemy. Zgadzam się.
Zakończenie: chodzi o ludzi
Prowadzący: Coś jeszcze, czego nie ruszyliśmy, a na czym ci zależy? Chcesz, żeby publiczność to usłyszała?
Kyle Daigle: Nie wiem, czy zdążyliście cokolwiek obejść, czy was zamknęli w studiu podcastowym.
Prowadzący: Nie, nie, zdążylismy się rozejść.
Kyle Daigle: To, co jest dla mnie najważniejsze… GitHub zawsze próbuje przesuwać granice tego, czym jest wytwarzanie oprogramowania, ale ostatecznie chodzi o ludzi. O spotykanie programistów i oglądanie tego, co budują. Pewnie, możesz używać stu albo tysiąca agentów, ale gdy rozmawiasz z Peterem o tym, co robi z OpenClaw, o jego wpisach w stylu „czemu nie pozwalają mi tego zrobić” — chodzi o ambicję Petera, o jego pasję. Moja ulubiona rzecz — na pewno krąży już po mediach społecznościowych — to sklep płytowy tutaj, gdzie z mnóstwa projektów open source zrobiliśmy winylowe płyty. To mój punkt czuły: chcemy świętować waszą pracę i pomysły, które za nią stoją, oraz dawać wam moc działania — tak agentycznie, na jaką tylko macie ochotę, bez limitów skali. Bo w czasach, gdy bez przerwy rozmawiamy o tym, który model, który benchmark, o harnessach — i co to w ogóle jest harness — i co z tym wszystkim robić… miło jest po prostu usiąść razem z wami i posłuchać, co was naprawdę kręci, zamiast rozmawiać o naszych młotkach, wkrętakach i gwoździach.
Prowadzący: Wczorajsze spotkanie grupy było niesamowicie orzeźwiające.
Kyle Daigle: Zazdroszczę.
Prowadzący: Ludzie, rozmawiajcie z ludźmi. No i wszystko tutaj zawsze kręci się wokół ludzi. Każdy rok, kiedy przyjeżdżamy, jest świetny — Ashley dba o to, żeby każdy dostał swój pakiet upominków, program GitHub Stars, wszystko dopięte na ostatni guzik. Naprawdę to doceniamy. Wes, przejmujesz sick picks?
(Informacja dodatkowa: „Sick picks” to stały segment Syntax — goście i prowadzący wybierają rzecz, która ostatnio ich zachwyciła, od batonika po gadżet.)
Sick pick: skórzany notes
Prowadzący: Masz teraz w życiu jakieś swoje sick pick? Ryan Dahl, twórca Node.js, wybrał kiedyś puszczanie latawca.
Kyle Daigle: Mam notes w skórzanej oprawie od firmy z Amsterdamu — mogę wysłać link. Naprawdę butikowa robota: piękne, małe skórzane książeczki. Uwielbiam go, bo za każdym razem, gdy go wyciągam, jest jakimś miłym przypomnieniem o świecie realnym i o odrobinie trwałości — nie zaczynam od zera, tylko piszę jak należy. Noszę go ze sobą, a zespół czasem się ze mnie podśmiewa, bo wszyscy dyktują do telefonu albo na laptopie. Ale naprawdę ogromną różnicę robi zatrzymanie się na moment i przelanie myśli na papier — zanim, powiedzmy szczerze, sfotografuję kartkę i wrzucę ją do agenta.
Prowadzący: Pięknie. Dziękujemy bardzo, Kyle.
Prowadzący: Dzięki za czas.
Kyle Daigle: Dziękuję. Cześć!