Rozwój Microsoft Copilot Cowork: dziewięciu inżynierów, 1 211 pull requestów i wąskie gardło weryfikacji

Microsoft podaje, że 21 października dziewięciu inżynierów scaliło 1 211 pull requestów podczas rozwoju Copilot Cowork, a agenci napisali większość kodu. Pull request proponuje zmiany do przeglądu przed ich integracją. To rozróżnienie ma znaczenie: nagłówek mierzy scalone zmiany, podczas gdy produktywność zależy również od ich użyteczności, niezawodności i obciążenia związanego z utrzymaniem.

Opublikowany 2 listopada opis prac inżynieryjnych przedstawia zespół zmieniający sposób specyfikowania, przeglądania i eksploatowania oprogramowania. Jego główne napięcie wynika z rosnącej zdolności do implementacji przy ograniczonej zdolności do weryfikacji. Generowanie większej liczby zmian tworzy wartość tylko wtedy, gdy organizacja potrafi ustalić, które z nich powinny trafić do użytkowników.

Badania Anthropic dotyczące agentów oraz badania Google nad dostarczaniem oprogramowania dostarczają użytecznych punktów odniesienia, nie potwierdzając jednak niezależnie wyników Microsoftu. Oba kierują uwagę na systemy otaczające narzędzia AI. Dla liderów inżynierii presja przenosi się na praktyki przeglądu, architekturę i rozliczalność, gdy produkcję kodu coraz łatwiej skalować.

Co faktycznie mierzy kamień milowy rozwoju Copilot Cowork

Według relacji Microsoftu o inżynierii Copilot Cowork zespół backendowy osiągnął tę dzienną liczbę po rozpoczęciu prac w styczniu. Inżynierowie zachowali odpowiedzialność za wymagania i decyzje o wyższym ryzyku. Zautomatyzowane kontrole i agenci recenzujący analizowali zmiany. Microsoft opisuje także wrażliwą zmianę, w której ludzcy recenzenci wykryli cztery blokujące problemy pominięte przez agentów recenzujących.

Scalony pull request rejestruje zaakceptowane działanie; jego wartość biznesowa nadal wymaga odrębnych dowodów.

Organizacja może podzielić funkcję na wiele zmian albo połączyć powiązane prace w większe zgłoszenie. Oba podejścia zmieniają liczbę. Żadne z nich nie określa, jaką wartość dla klienta przyniosła praca. Porównywanie zespołów wyłącznie na podstawie sum może więc premiować różnice w sposobie pakowania pracy, a nie w wynikach inżynieryjnych.

Mniejsze zmiany mogą ułatwiać przegląd, ponieważ każda propozycja stawia węższe pytanie. Jednak zbiór indywidualnie zrozumiałych zmian nadal może wywołać nieoczekiwany łączny efekt. Właściwą jednostką oceny bywa wtedy wydanie, przepływ pracy klienta lub usługa w czasie.

Rozważmy hipotetycznego asystenta planowania, który odczytuje prośbę, sprawdza dostępność i przygotowuje zaproszenie na spotkanie. Każdy komponent może przejść własne testy, podczas gdy cały przepływ pracy nieprawidłowo obsługuje anulowanie. Liczenie udanych zmian komponentów pominęłoby rzeczywisty problem klienta.

Przykład ten pokazuje, dlaczego kamień milowy zasługuje na uwagę, nie stając się uniwersalnym celem. Liczba wskazuje na wyjątkowo intensywny proces integracji. Nie ujawnia znormalizowanej miary złożoności funkcji, korzyści dla klienta ani wysiłku potrzebnego do utrzymania powstałego systemu.

Znaczenie ma także czas. Ta relacja opisuje model operacyjny wyłaniający się w toku długotrwałego rozwoju, a nie krótką demonstrację generowanego kodu. Czytelnicy powinni oceniać jej twierdzenia jako firmowe studium przypadku dotyczące produkcji, ze wszystkimi ograniczeniami kontekstu i selekcji, które wiążą się z tym formatem.

Inżynieria Copilot Cowork stawia zatem pytanie zarządcze wykraczające poza szybkość kodowania: jakie dowody powinny uzasadniać zaakceptowanie zmiany? Różne odpowiedzi oznaczają różne potrzeby kadrowe. Zespół kładący nacisk na lokalne wyniki testów zorganizuje się inaczej niż zespół wymagający przeglądu bezpieczeństwa, dowodów operacyjnych i kontroli wyników dla klientów.

Dzienna suma nie może odpowiedzieć na to pytanie w odniesieniu do innej organizacji. Utrudnia jednak dalsze odkładanie pytania. Gdy implementacja się rozszerza, słabe kryteria akceptacji stają się ograniczeniem operacyjnym, a nie okazjonalną niedogodnością.

Dla nabywców to rozróżnienie jest równie praktyczne. Tempo rozwoju dostawcy opisuje jego zdolność do zmieniania produktu. Nabywca nadal potrzebuje dowodów, że te zmiany usprawniają przepływy pracy, od których zależą pracownicy.

Liderzy inżynierii stoją przed problemem zdolności weryfikacyjnej

Gdy zdolność do implementacji rośnie, rzadkim zasobem staje się uzasadniona pewność co do tego, co trafia do produkcji.

Pewność ma kilka źródeł: precyzyjne wymaganie, znaczące testy, świadomy przegląd oraz dowody z działającej usługi. Źródła te odpowiadają na różne pytania. Test może potwierdzić oczekiwane zachowanie dla wybranych danych wejściowych, nie potwierdzając, że samo wymaganie służy klientowi.

Badanie Google dotyczące wspomaganego przez AI rozwoju oprogramowania oferuje szersze porównanie. Wyniki DORA z 2025 roku wiążą wdrażanie AI ze zwiększoną przepustowością dostarczania, jednocześnie podkreślając znaczenie otaczającej organizacji. Badanie opisuje AI jako czynnik wzmacniający istniejące mocne i słabe strony.

Ta perspektywa wspiera ostrożną interpretację kamienia milowego Microsoftu. Zespół z jasnym przypisaniem odpowiedzialności i niezawodnymi mechanizmami kontroli wydań ma gdzie skierować dodatkową zdolność implementacyjną. Zespół z nierozstrzygniętymi zakresami odpowiedzialności może natomiast gromadzić więcej propozycji, których nikt nie potrafi z przekonaniem zatwierdzić.

Presja spada więc przede wszystkim na menedżerów inżynierii i zespoły platformowe. To oni określają, kto odpowiada za kryteria akceptacji, które zmiany wymagają uwagi specjalistów oraz jak można wycofać wydanie. Decyzje te stają się bardziej istotne, gdy propozycje napływają szybciej.

Specjaliści ds. bezpieczeństwa mierzą się z pokrewnym problemem alokacji. Przeglądanie każdej zmiany z jednakową intensywnością pochłania uwagę niezależnie od ryzyka. Przeglądanie wyłącznie oczywistych plików związanych z bezpieczeństwem pomija zachowania wprowadzone gdzie indziej. Trudność polega na powiązaniu zmian z uprawnieniami, danymi i działaniami klientów, na które wpływają.

Menedżerowie produktu również dziedziczą większą odpowiedzialność. Niejednoznaczne prośby stają się kosztowne, gdy oprogramowanie można wyprodukować, zanim ujawnią się rozbieżności. Dopracowana implementacja może wytworzyć impet wokół źle zrozumianego wymagania, czyniąc korektę politycznie trudniejszą, nawet gdy zmiana kodu pozostaje technicznie prosta.

W tym miejscu organizacje powinny odróżniać czekanie od koniecznego namysłu. Część opóźnień wynika z braku informacji lub przeciążenia recenzenta. Inne opóźnienia chronią nieodwracalną decyzję. Traktowanie obu jako marnotrawstwa zachęca zespoły do usuwania zabezpieczeń tylko dlatego, że spowalniają wskaźnik na pulpicie.

Użyteczną odpowiedzią zarządczą jest zbadanie, gdzie w procesie pojawia się niepewność. Jeśli recenzenci wielokrotnie pytają, co funkcja powinna robić, wymaganie wymaga dopracowania. Jeśli wielokrotnie kwestionują skutki wdrożenia, proces wydawania potrzebuje lepszej widoczności.

To diagnozy organizacyjne, a nie argumenty za nieograniczonym procesem. Każda dodatkowa kontrola ma koszt. Standardem powinno być to, czy odpowiada ona na istotne pytanie, którego inna kontrola nie rozstrzyga.

Historia rozwoju Copilot Cowork uwidacznia ten kompromis w wyjątkowy sposób. Liderzy inżynierii muszą teraz wyjaśnić, jak będą rozszerzać zdolność weryfikacyjną wraz ze zdolnością implementacyjną. Zakup dostępu do agenta programistycznego nie rozwiązuje tej decyzji operacyjnej.

Dla nabywców korporacyjnych odpowiadające temu pytanie dotyczy jakości zmian. Szybsze wydania stają się użyteczne, gdy pracownicy doświadczają mniej przerw, wyraźniejszych uprawnień i bardziej niezawodnego wykonywania zadań. Sama częstotliwość wydań pozostawia te wyniki nierozstrzygnięte.

Migracja Copilot Cowork do Rust oddziela język od architektury

Microsoft informuje, że migracja Copilot Cowork do Rust skróciła medianę czasu odpowiedzi w pierwszej turze z 7,9 sekundy do 2,7 sekundy w okresie porównawczym. Przypisuje także część poprawy przeniesieniu pętli agenta i nie przedstawia twierdzenia dotyczącego kosztu pojedynczej tury.

Migracja może usprawnić usługę, nie dowodząc, że język programowania spowodował każdą poprawę.

Środowisko wykonawcze to mechanizm oprogramowania, który realizuje pracę aplikacji. Przeniesienie tego mechanizmu między językami może zmienić zarządzanie pamięcią, harmonogramowanie, wdrażanie i zachowanie podczas uruchamiania. Jeśli kilka elementów zmienia się jednocześnie, wynikowy pomiar odzwierciedla ich łączny efekt.

Rozróżnienie to ma znaczenie, ponieważ debaty o językach programowania często redukują projekt architektoniczny do prostego pojedynku. Takie ujęcie tworzy zwięzły nagłówek, ale stanowi słabą podstawę decyzji inwestycyjnej innego zespołu. Istotne pytanie dotyczy mechanizmu, który rozwiązuje jego własne wąskie gardło.

Garantowane współbieżności przez Rust stanowią konkretny punkt odniesienia technicznego. Współbieżność oznacza, że odrębne części programu mogą niezależnie czynić postępy. Rust wykorzystuje zasady własności i sprawdzanie typów, aby wykrywać wiele błędów pamięci i współbieżności przed wykonaniem programu.

Te gwarancje mają ograniczenia. Nie potwierdzają, że odpowiedź zawiera właściwe informacje biznesowe, że operacja ma uprawnienie ani że użytkownicy otrzymują zdarzenia w oczekiwanej kolejności. Bezpieczeństwo języka i poprawność aplikacji pokrywają się tylko częściowo.

Usługa planowania ilustruje tę różnicę. Jej kod może bezpiecznie obsługiwać pamięć, wybierając jednocześnie niewłaściwy kalendarz. Jej zadania mogą wykonywać się bez wyścigu danych, a mimo to wysłać zaproszenie przed zatwierdzeniem. Gwarancja na poziomie języka nie może zastąpić brakującej reguły produktowej.

Dowody dotyczące migracji wymagają więc kilku warstw. Jedna dotyczy wykorzystania zasobów i czasu odpowiedzi. Kolejna dotyczy zachowania przy realistycznym ruchu. Następna dotyczy tego, czy zamiennik zachowuje zobowiązania, które wcześniej były ukryte.

Kontrolowane porównanie idealnie utrzymywałoby stałe obciążenie i warunki infrastrukturalne, dokumentując jednocześnie oceniane zmiany. Migracje produkcyjne rzadko zapewniają idealne rozdzielenie eksperymentalne. To ograniczenie powinno kształtować atrybucję, a nie usuwać użyteczne pomiary operacyjne.

Dla deweloperów czytających relację o migracji Copilot Cowork do Rust praktyczna implikacja ma charakter analityczny. Przed uogólnieniem wyniku należy określić, czy właściwy problem dotyczy harmonogramowania wykonania, narzutu uruchamiania, zachowania pamięci czy projektu aplikacji.

Dla nabywców sam język zazwyczaj ma mniejsze znaczenie niż wynik działania usługi. Szybsze początkowe odpowiedzi są wartościowe, ale nie potwierdzają szybszego ukończenia całego zadania. System może zacząć odpowiadać wcześniej, a mimo to potrzebować więcej czasu na dostarczenie poprawnego rezultatu.

To samo rozróżnienie dotyczy ekonomii. Poprawa opóźnień nie potwierdza automatycznie niższego kosztu operacyjnego. Na wyliczenie wpływają wykorzystanie infrastruktury, wywołania modeli, ponowne próby i praca wsparcia.

To czyni migrację użytecznym studium przypadku dotyczącym atrybucji. Pokazuje, dlaczego wynik inżynieryjny powinien zachować kontekst architektoniczny, gdy staje się publicznym twierdzeniem o wydajności.

Przegląd przez agentów potrzebuje niezależnej podstawy zaufania

Dodanie recenzentów zwiększa pewność tylko wtedy, gdy ich kontrole dostarczają użytecznych i wystarczająco niezależnych dowodów.

Agent AI to system oparty na modelu, który wybiera działania i wykorzystuje narzędzia do realizacji celu. Recenzent agenta może przeanalizować proponowaną zmianę, wskazać wątpliwości i zażądać poprawek. Jego ocena nadal pozostaje wynikiem wymagającym ewaluacji, zwłaszcza gdy agent tworzący dostarczył znaczną część towarzyszącego wyjaśnienia.

Wzorce przepływów pracy agentów Anthropic opisują systemy oddzielające generowanie od oceny. Firma zaleca proste projekty, jasne kryteria oceny i dodatkową złożoność tylko wtedy, gdy poprawia ona rezultaty. Stanowi to użyteczny punkt odniesienia dla rosnącej roli zautomatyzowanej recenzji.

Ewaluator ma łatwiejsze zadanie, gdy sukces można zaobserwować bezpośrednio. Obliczenie numeryczne można sprawdzić względem niezależnego wyliczenia. Przepływ pracy wrażliwy na uprawnienia wymaga innego rodzaju dowodów, ponieważ właściwe działanie zależy od tożsamości, polityki i kontekstu.

Głównym zagrożeniem jest wspólne nieporozumienie. Autor i recenzent mogą się zgadzać, ponieważ obaj w ten sam sposób zinterpretowali niejednoznaczne wymaganie. Ich zgodność nie rozstrzyga tej niejednoznaczności. Osobny model lub prompt pomaga tylko wtedy, gdy wnosi istotną różnicę w zakresie dowodów lub rozumowania.

Testy mają podobne ograniczenie. Test napisany równolegle z implementacją może odtwarzać założenia implementacji. Jego zaliczenie potwierdza spójność między tymi artefaktami. Niekoniecznie potwierdza jednak zgodność z zamierzonym zachowaniem.

Niezależne dowody mogą pochodzić z istniejącego kontraktu, zaobserwowanego zachowania, zatwierdzonego wymagania lub starannie dobranego przypadku błędu. Właściwe źródło zależy od zmiany. Istotne rozróżnienie dotyczy tego, czy dowody mogą podważyć implementację.

Rozważmy zautomatyzowaną kontrolę, która zgłasza sukces mimo że nie otrzymała żadnych istotnych danych wejściowych. Jej wynik przypomina udaną inspekcję, lecz nie zawiera informacji o proponowanej zmianie. Widoczny symbol powodzenia staje się mylący, gdy użytkownicy nie mogą określić, co kontrola faktycznie zbadała.

Dlatego jakości recenzji nie można sprowadzić do liczby przydzielonych agentów. Niewielki zestaw kontroli o odrębnych celach może zapewnić większą pewność niż powtarzane, szerokie recenzje. Celem jest objęcie istotnych trybów awarii bez tworzenia nieczytelnego strumienia komentarzy.

Zaangażowanie ludzi również potrzebuje konkretnej roli. Poproszenie kogoś o zatwierdzenie zmiany bez czasu lub kontekstu tworzy jedynie pozorny nadzór. Skuteczna recenzja wymaga jasnej decyzji, istotnych dowodów i uprawnienia do odrzucenia propozycji.

W przypadku rozwoju Copilot Cowork szersza lekcja dotyczy relacji między automatyzacją a odpowiedzialnością. Szybsza automatyczna informacja zwrotna może wspierać ludzki osąd, ale organizacja nadal potrzebuje wyraźnej podstawy do akceptowania ryzyka.

Podstawa ta powinna pozostać zrozumiała po odejściu pierwotnych autorów z rozmowy. Przeszukiwalny zapis wymagań i decyzji pomaga przyszłym recenzentom odtworzyć intencję. Zespoły zarządzające tym kontekstem mogą korzystać z przeszukiwalnej bazy wiedzy, nie traktując przechowywanych dokumentów jako dowodu, że oprogramowanie działa poprawnie.

Badania produktywności komplikują nagłówek dotyczący pull requestów

Studium przypadku Microsoftu i niezależne badania produktywności mierzą różne rzeczy, więc ich ustalenia nie mogą zastępować siebie nawzajem.

Eksperyment METR dotyczący produktywności programistów stanowi użyteczną przeciwwagę. W badaniu z początku 2025 roku 16 doświadczonych programistów open source wykonało 246 zadań. Dopuszczenie AI wydłużyło czas realizacji o 19% w tych warunkach, mimo że uczestnicy uważali, iż narzędzia im pomagają.

Wynik ten dotyczy konkretnych programistów, repozytoriów, zadań i narzędzi. Nie dowodzi, że AI spowalnia każdy zespół inżynieryjny. Nie może też bezpośrednio ocenić późniejszego przepływu pracy zorganizowanego wokół wielu współbieżnych agentów.

METR później jeszcze bardziej doprecyzował ten obraz. W lutowej aktualizacji eksperymentu produktywności z 2026 roku opisano problemy z doborem próby oraz trudności w mierzeniu czasu, gdy programiści korzystali z agentów równocześnie. Badacze uznali nowsze wyniki za niewiarygodne do precyzyjnego oszacowania obecnego efektu.

Łącznie źródła te wskazują na problem pomiarowy, a nie uniwersalny werdykt. Czas realizacji zadań, scalone zmiany i deklarowana użyteczność mogą zmieniać się w różny sposób. Rzetelna ocena określa, który wynik ma znaczenie, zanim zinterpretuje rezultat.

Dla pojedynczego programisty narzędzie może ograniczać nieprzyjemną pracę bez skracania czasu jej trwania. Dla organizacji może poszerzać zakres możliwych projektów bez zmniejszania nakładu na utrzymanie. Te korzyści zasługują na uwzględnienie, lecz wymagają trafnych określeń.

Zespół może też realizować więcej pracy, ponieważ wybiera mniejsze zadania. Może to poprawić dostarczanie rezultatów przez ograniczenie oczekiwania i niepewności. Może również zawyżać wskaźniki aktywności, podczas gdy poważne problemy klientów pozostają nierozwiązane. Sama liczba nie pozwala rozróżnić tych wyjaśnień.

Znaczenie ma także scenariusz kontrfaktyczny. Ocena produktywności wymaga pewnego opisu tego, co wydarzyłoby się bez narzędzia lub procesu. Udane wydanie dowodzi, że zespół coś dostarczył. Nie dowodzi niezależnie skali przyspieszenia przypisywalnego AI.

Publiczna relacja Microsoftu dostarcza przykładu operacyjnego, a nie randomizowanego porównania. Taki format może ujawnić użyteczne mechanizmy i tryby awarii. Nie potrafi jednak wyizolować każdego wkładu wynikającego z doświadczenia programistów, infrastruktury, wsparcia organizacyjnego i możliwości modelu.

Ta sama ostrożność dotyczy konkurentów. Wskazówki architektoniczne Anthropic wyjaśniają podejście projektowe, podczas gdy badania Google opisują szersze wzorce. Żadne z nich nie ustala, który dostawca zapewnia najlepszy wynik dla konkretnego obciążenia przedsiębiorstwa.

Dla liderów inżynieryjnych wniosek jest taki, by opierać się pokusie przekształcania zapadającej w pamięć liczby w formułę zatrudnienia. Decyzje dotyczące liczebności zespołu wymagają dowodów na trwałą zdolność dostarczania, jakość, obciążenie wsparcia oraz pracę pozostającą poza mierzonym procesem.

Ta historia pozostawia również otwarte pytanie ekonomiczne. Całkowity koszt zaakceptowanej pracy obejmuje generowanie, ocenę, infrastrukturę, ludzką uwagę oraz poprawki po wydaniu. Większa aktywność implementacyjna może współistnieć zarówno z lepszą, jak i gorszą ekonomiką.

Rozwój Copilot Cowork należy zatem oceniać jako konkretny przykład zreorganizowanej pracy. Jego najsilniejszym wkładem jest skłanianie do zadawania lepszych pytań o dowody, a nie dostarczanie uniwersalnego przelicznika między inżynierami a agentami.

Trzy sygnały ułatwią ocenę modelu rozwoju

Kolejne użyteczne dowody dotyczą trwałych rezultatów, powtarzalnej weryfikacji oraz pełnego kosztu zaakceptowanej pracy.

Pierwszym sygnałem jest kontynuacja łącząca aktywność rozwojową z niezawodnością produkcyjną. W nadchodzących miesiącach ujawnienie awarii wydań, wycofań zmian lub powtarzających się problemów klientów pomogłoby czytelnikom zinterpretować liczbę scalonych zmian.

Poprawa niezawodności przy jednoczesnym utrzymaniu tempa dostarczania wzmocniłaby argument za modelem operacyjnym. Rosnący nakład pracy naprawczej go skomplikowałby. Każdy z tych wyników dostarczyłby większej wartości decyzyjnej niż kolejny odosobniony zapis aktywności.

Porównanie powinno wykorzystywać spójne definicje. Zmiana praktyk raportowania może sprawić, że usługa będzie wyglądała na zdrowszą, nie zmieniając jej zachowania. Czytelnicy powinni zwracać uwagę na stabilne okno pomiarowe i jasne wyjaśnienie, co jest uznawane za awarię.

Drugim sygnałem są dowody, że praktyki weryfikacyjne przenoszą się poza pierwotny zespół. Udokumentowana ewaluacja, odtwarzalna konfiguracja testowa lub porównywalny przypadek produkcyjny pomogłyby odróżnić podejście szeroko użyteczne od wyniku zależnego od nietypowych warunków.

Replikacja nie wymaga, by inny zespół osiągnął ten sam dzienny wynik. Wymaga wykazania, że dodatkowe możliwości implementacyjne prowadzą do zaakceptowanych rezultatów bez przytłaczania recenzji i operacji. Różne obciążenia powinny rozsądnie prowadzić do różnych poziomów aktywności.

Jeśli inne zespoły odtworzą korzyści przy odmiennych ograniczeniach, argument stanie się bardziej ogólny. Jeśli sukces zależy silnie od wyspecjalizowanej infrastruktury lub skoncentrowanej wiedzy eksperckiej, jego zastosowanie stanie się węższe. Nadal byłaby to użyteczna informacja dla nabywców i liderów inżynieryjnych.

Trzecim sygnałem jest wiarygodne ujęcie ekonomiczne. Koszt na pomyślnie zrealizowane zadanie klienta połączyłby zmiany inżynieryjne z rzeczywistością operacyjną produktu. Ujawniłby również, czy ponowne próby i praca korygująca pochłaniają pozorne zyski wydajności.

Użyteczne ujawnienie wyjaśniałoby, jakie koszty wchodzą do kalkulacji. Wykluczenie recenzji lub infrastruktury odpowiadałoby na węższe pytanie. Uwzględnienie ich pomogłoby organizacjom porównać to podejście z obecnym procesem.

Są to priorytety obserwacji, a nie zapowiedziane zobowiązania dotyczące raportowania. Microsoft nie obiecał każdego z omówionych tu pomiarów. Ich brak pozostawiłby części sprawy nierozstrzygnięte, zamiast automatycznie potwierdzać porażkę.

Dla nabywców korporacyjnych natychmiastowym działaniem jest poproszenie dostawców o dowody powiązane z rzeczywistym przepływem pracy. Wybierz zadanie wykonywane przez pracowników, zdefiniuj akceptowalny rezultat i sprawdź, jak system obsługuje wyjątki. Oddziel aktywność rozwojową od sukcesu klienta.

Dla liderów inżynieryjnych oceniających rozwój Copilot Cowork ten kamień milowy powinien posłużyć do wyostrzenia pytań stojących za własnymi decyzjami adopcyjnymi. Określ, co wasz zespół ma trudność zweryfikować, gdzie ginie intencja oraz które rezultaty uzasadniają dodatkową automatyzację. Porównuj zaakceptowaną pracę w znaczącym okresie, uwzględniając wysiłek potrzebny do jej skorygowania. Czytaj źródłową relację inżynieryjną obok badań produktywności, ponieważ odpowiadają na różne pytania. Następnie sprawdź, czy organizacja potrafi wyjaśnić, dlaczego zmiana zasługuje na wydanie. Gdy skalowanie implementacji staje się łatwiejsze, wyjaśnienie to staje się kluczową odpowiedzialnością inżynieryjną. Jakie dowody przekonałyby wasz zespół, że większa ilość wygenerowanego kodu stała się bardziej niezawodnym oprogramowaniem?