Microsoft: 9 inżynierów scaliło 1211 pull requestów w projekcie Copilot Cowork

Według Microsoftu 21 października dziewięciu inżynierów scaliło 1211 pull requestów z główną gałęzią backendu Copilot Cowork. Firma opisuje rozwój usługi jako pracę, w której agenci tworzyli większość kodu, a ludzie ustalali wymagania, architekturę i granice bezpieczeństwa oraz decydowali o wdrożeniach (relacja zespołu Microsoftu).

Microsoft osobno podał 4581 pull requestów scalonych w tygodniu rozpoczynającym się 12 października, czyli około 650 dziennie. To inny wynik niż jednodniowy bilans z 21 października.

Jak zespół ograniczał ryzyko pracy agentów

Przed rozpoczęciem pracy zespół wymagał specyfikacji w Markdown, która określała, co zmiana ma robić, jak sprawdzić jej powodzenie i czego nie może zepsuć. Agent mógł przygotować projekt specyfikacji na podstawie ustnego opisu, ale przed implementacją poprawiał go człowiek. Równoległe agenty dostawały osobne kopie repozytorium, każde z jednym zadaniem i przypisaną specyfikacją. Microsoft opisuje skalowanie pracy od jednego agenta, przez pięć, aż do kilkudziesięciu.

Granica bezpieczeństwa miała oddzielać model od danych uwierzytelniających użytkownika. Według opisu Microsoftu model działał w kontenerze bez tych danych, a zaufany host poza nim obsługiwał tożsamość, zasady, zatwierdzanie działań, uruchamianie narzędzi i audyt. Każda operacja w Microsoft 365 przechodziła przez host.

Agenci recenzujący pomagali we wstępnej kontroli zmian, lecz przy krytycznych poprawkach zespół zachował przegląd człowieka. W jednym przypadku dotyczącym wrażliwego obszaru ludzie znaleźli cztery blokujące problemy, które przeoczyli agenci recenzujący. Microsoft podał też, że w próbie ostatnio scalonych pull requestów mediana czasu do użytecznej pierwszej recenzji wyniosła około 4,5 minuty.

Zespół próbował wyłapywać testy, które przechodzą, choć w praktyce niczego nie sprawdzają. Każda kontrola miała raportować liczbę zbadanych plików, a nowa kontrola musiała zawierać test celowo doprowadzający ją do błędu. Taki test pozwala sprawdzić, czy kontrola rzeczywiście wykrywa problem, zamiast tylko zwracać zielony wynik.

Jak Microsoft sprawdzał migrację z Pythona do Rusta

Migracja środowiska uruchomieniowego zakończyła się 10 października 2026 roku, kiedy ostatni klaster przeszedł na Rusta. Dzień wcześniej Microsoft usunął środowisko Python, obejmujące około 8000 plików i 4,9 miliona linii, w tym testy oraz wygenerowany kod.

Aby porównać zachowanie obu implementacji, generatory uruchamiały istniejący kod w Pythonie na określonych zestawach danych i zapisywały wyniki jako pliki JSON, nazywane fixture’ami. Testy w Ruście odtwarzały te wyniki. Microsoft podał, że przygotowano około 430 fixture’ów; test sprawdzał też liczbę przypadków, żeby pusty zestaw nie zaliczył się przez pomyłkę.

Pierwszy zestaw nie uchwycił jednak niejawnej kolejności, w jakiej Python dostarczał pewne zdarzenia. Początkowa wersja w Ruście nie zachowała tej kolejności, a zespół dodał brakujące zachowanie do testów. Microsoft opisał również błąd, przez który pierwsze potwierdzenie odbioru wiadomości w nowym rozwiązaniu trwało około sześć razy dłużej, ponieważ system czekał na zakończenie całego odbioru. Według firmy oba problemy zostały naprawione.

Zmiana obejmowała też porządkowanie struktury projektu. Inwentaryzacja z 20 sierpnia wykazała 86 crate’ów, czyli jednostek organizacji kodu w Ruście, oraz łańcuch zależności sięgający 13 poziomów. Zespół wydzielił cztery role: Contract, Kit, Implementation i Binary. Implementacje mogły korzystać z kontraktów i zestawów narzędzi, ale nie z innych implementacji. Do 7 października liczba wyjątków od tej reguły spadła z 216 do zera, a limit głębokości zależności zmniejszono z 10 do 3. Liczba crate’ów wzrosła do około 176.

Co pokazują pomiary opóźnień

W tym samym 12-godzinnym oknie pod koniec września Microsoft porównał czas od rozpoczęcia pierwszej tury do pojawienia się pierwszego tokena. Podane wartości są pomiarami wewnętrznymi firmy.

p50 to mediana: połowa obserwacji mieściła się w podanym czasie, a połowa go przekraczała. p90 oznacza, że 90 procent obserwacji mieściło się w tej wartości. Microsoft zaznaczył, że wraz ze zmianą języka pętla agenta została przeniesiona poza kontener do usługi w Ruście. Firma przypisała tej zmianie znaczną część poprawy, więc porównanie nie oddziela jej wpływu od wpływu samego języka.

Przed migracją Microsoft odnotował też przestoje pętli zdarzeń w Pythonie sięgające 11,9 sekundy pod obciążeniem. Według firmy 16,7 procent konfiguracji sesji kończyło się po dokładnie 5 sekundach z powodu uruchomienia limitu czasu, a na jednym klastrze w ciągu tygodnia proces Python został zabity 539 razy.

Microsoft nie zmierzył właściwie kosztu pojedynczej tury i nie deklaruje, że migracja obniżyła koszty.

Jak użytkownicy oceniają pracę z kodem

Jeden z uczestników dyskusji o Power Platform opisał korzystanie z agenta Copilot Studio, któremu przekazywał przykłady i instrukcje do pracy nad Logic Apps. Gotowy wynik nadal kopiował ręcznie. Inni uczestnicy sugerowali przechowywanie planów i specyfikacji w plikach Markdown oraz uruchamianie skryptów w VS Code. W tej samej dyskusji pojawiło się ostrzeżenie o możliwie dużym zużyciu przy pracy z Power Platform.

W rozmowie o Copilot Cowork użytkownicy różnili się w ocenie tego, kiedy potrzebna jest orkiestracja wielu kroków. Część uważała, że zwykły Copilot wystarczy do podsumowań lub przygotowania prezentacji, inni wskazywali na potencjał łączenia pracy na dokumentach, poczcie i danych w dłuższy proces.