GitHub Universe 2026 oddaje Copilotowi kontrolę nad czymś więcej niż kodem

Podczas GitHub Universe 2026 GitHub rozszerzył możliwości Copilota poza generowanie kodu, stawiając w centrum swoich zapowiedzi koordynowanie agentów i ukończoną pracę nad oprogramowaniem. Aktualizacje z 28 października łączą przestrzeń roboczą aplikacji, orkiestrację modeli i połączone sesje chmurowe. Ich wspólna propozycja jest prosta: programiści powinni kierować pracą bez osobistego zarządzania każdym pośrednim przekazaniem zadań.

Ta propozycja zmienia pytanie konkurencyjne. Wybór między GitHub Copilot a alternatywami, takimi jak Claude Code, coraz częściej obejmuje własność przepływu pracy, obok jakości modeli. Kluczowe napięcie dotyczy skoordynowanego wykonania kontra odpowiedzialne dostarczenie rezultatu. Agent może stworzyć wiarygodną zmianę, jednocześnie pozostawiając recenzentowi odpowiedzialność za ustalenie, czy powinna ona trafić na produkcję.

Zapowiedzi zasługują na uwagę, ponieważ dotyczą pracy między etapami kodowania, gdzie gromadzą się kontekst, zatwierdzenia i nierozstrzygnięte decyzje. Wymagają też ostrożnego rozróżniania. Dostępność produktów różni się między wydaniami, deklaracje dostawcy dotyczące benchmarków wymagają przypisania, a dostarczanie oprogramowania obejmuje obowiązki, które przetrwają automatyzację. GitHub przedstawia połączony system; kupujący nadal potrzebują dowodów na wyniki, jakie ten system zapewnia.

GitHub Universe 2026 łączy elementy dostarczania oprogramowania

Najważniejsza zapowiedź GitHub dotyczy szerszej jednostki pracy: celu, który przechodzi przez kilka narzędzi i decyzji, zanim stanie się zaakceptowanym oprogramowaniem.

W swojej wizji dostarczania oprogramowania GitHub opisuje programistów kierujących pracą, podczas gdy agenci wdrażają i weryfikują zmiany. Firma przedstawiła projekty Copilot, ciągłość sesji, automatyzacje i głębszy przegląd kodu jako powiązane elementy tego podejścia. Jej deklarowany nacisk dotyczy ukończonej pracy.

To ujęcie ma znaczenie, ponieważ wygenerowanie poprawki i ukończenie zadania to różne osiągnięcia. Poprawka zmienia pliki. Ukończenie zadania wymaga zgodności co do zamierzonego zachowania, akceptowalnego ryzyka oraz tego, czy zmiana rozwiązuje pierwotny problem.

Agent AI, czyli oprogramowanie wykorzystujące narzędzia do realizacji zadania, może uczestniczyć w tych etapach. Uczestnictwo nie rozstrzyga automatycznie, kto podejmuje ostateczną decyzję. Prezentacja GitHub utrzymuje odpowiedzialność programistów, nawet jeśli proponowany system zakłada większy zakres pracy wykonawczej.

Aplikacja GitHub Copilot wymaga również wyjaśnienia kwestii czasu. Universe przynosi istotne aktualizacje istniejącego produktu, zamiast oznaczać, że aplikacja pojawiła się po raz pierwszy podczas tego wydarzenia. Wcześniejsze informacje o wydaniach GitHub już omawiały jej możliwości.

Konkretne aktualizacje aplikacji Copilot udostępniają projekty w publicznej wersji zapoznawczej. GitHub twierdzi, że projekty zbierają kontekst, agentów i wyniki wokół pracy obejmującej repozytoria lub szersze działania związane z wydaniem. Repozytoria to wersjonowane zbiory plików i historii, które organizują projekty oprogramowania.

Rozróżnienie między projektem a sesją ma konsekwencje. Sesja zwykle reprezentuje interakcję lub wątek wykonawczy. Projekt daje powiązanej pracy większy kontener, co staje się użyteczne, gdy odrębne zmiany muszą spełniać ten sam cel.

Rozważmy hipotetyczną funkcję obejmującą usługę i jej dokumentację. Każda zmiana może wyglądać rozsądnie samodzielnie, podczas gdy cała funkcja pozostaje niekompletna. Wyzwaniem organizacyjnym jest zachowanie wspólnych wymagań i ustalenie, kiedy połączony rezultat je spełnia.

To jest najsilniejsza interpretacja zapowiedzi GitHub: firma chce uporządkować relacje między zadaniami. Wartość zależy od tego, czy relacje te pozostają widoczne, gdy praca rozgałęzia się, założenia się zmieniają lub ktoś odrzuca proponowany rezultat.

Sama zatłoczona przestrzeń robocza niewiele by osiągnęła. Użyteczny system dostarczania musi rozróżniać pracę rozpoczętą, pracę oczekującą na decyzję oraz pracę, która rzeczywiście spełniła kryteria akceptacji. Te stany niosą różne konsekwencje dla osoby odpowiedzialnej za wydanie.

Liderzy inżynierii dziedziczą inne wąskie gardło

Gdy agenci zwiększają liczbę proponowanych zmian, liderzy inżynierii muszą uważniej obserwować zdolność do podejmowania decyzji na ich temat.

To analityczna konsekwencja kierunku obranego przez GitHub, a nie zmierzony rezultat z jego zapowiedzi. Jeśli łatwiej jest inicjować wykonanie, przegląd i koordynacja zasługują na większą uwagę. Większa aktywność tworzy wartość tylko wtedy, gdy organizacja może udźwignąć jej konsekwencje.

Programiści odczuwają bezpośrednią wersję tej presji. Delegowanie zadania zmienia sposób, w jaki poświęcają uwagę. Muszą opisać cel, dostarczyć istotny kontekst, sprawdzić rezultat i zdecydować, czy praca wymaga korekty.

Niektóre zadania wynagradzają taką wymianę. Inne zawierają niepewność, która ujawnia się dopiero podczas wdrożenia. Agent realizujący luźno określone żądanie może poświęcić wysiłek na rozwiązanie niewłaściwej niejednoznaczności, pozostawiając recenzentowi odtworzenie pierwotnej intencji.

Menedżerowie inżynierii stają przed powiązanym problemem pomiarowym. Liczenie wygenerowanych zmian grozi traktowaniem wyników jako postępu, zanim ktokolwiek oceni ich użyteczność. Liczenie zaakceptowanych zmian jest lepsze, ale nadal pozostawia pytania o przeróbki, utrzymanie i później wykryte defekty.

Znacząca ocena powinna zatem śledzić zadanie poza jego pierwszym pozornym ukończeniem. Czy recenzenci musieli przepisać istotne fragmenty? Czy zmiana wprowadziła dodatkową pracę wsparcia? Czy pierwotny wnioskodawca otrzymał potrzebne zachowanie?

Te pytania są szczególnie istotne, gdy równoległa praca współdzieli zależności. Kilku agentów może robić lokalne postępy, jednocześnie tworząc zbiorowo niezgodne założenia. Obciążenie koordynacyjne pojawia się wtedy podczas integracji, gdy zmiana jednej decyzji wymaga ponownego przeanalizowania pozostałych.

Dla nabywców korporacyjnych uprawnienia stają się częścią oceny produktu. Dostęp ułatwiający demonstrację może być niewłaściwy do rutynowego użycia. System dostarczania potrzebuje granic odpowiadających obowiązkom organizacji, w tym określających, kto może zatwierdzać działania o istotnych konsekwencjach.

Jakość wiedzy tworzy kolejny punkt presji. Dyskusja projektowa może zawierać wstępne sugestie obok zatwierdzonych wymagań. Jeśli oba rodzaje informacji trafią do kontekstu agenta bez rozróżnienia, wynikowa implementacja może być wewnętrznie spójna, lecz organizacyjnie błędna.

W tym miejscu przeszukiwalna baza wiedzy staje się istotna dla przepływu pracy. Inżynierowie potrzebują niezawodnych sposobów odzyskiwania decyzji technicznych i dokumentów, które je wspierają. Wyszukiwanie pomaga zapewnić kontekst; zespół nadal musi określić, które decyzje pozostają wiążące.

GitHub Universe 2026 stawia więc przed liderami inżynierii praktyczne pytanie: gdzie dziś gromadzi się niedokończona praca? Zespoły zmagające się z wdrażaniem mają inne potrzeby niż zespoły zmagające się z niejednoznacznymi specyfikacjami lub przeciążonymi recenzentami.

To rozróżnienie powinno kształtować decyzje zakupowe. System przyspieszający wykonanie rozwiązuje jedno ograniczenie. Jego wartość organizacyjna zależy od tego, czy wykonanie było ograniczeniem powstrzymującym użyteczne oprogramowanie przed dotarciem do użytkowników.

Wyjaśnienie Copilot Fusion: wybór modelu staje się decyzją systemową

Copilot Fusion przenosi powtarzający się wybór programisty do systemu wykonawczego: decyzję o tym, które modele powinny obsługiwać zadanie i jak ich praca powinna ze sobą współdziałać.

Zapowiedź GitHub dotycząca orkiestracji wielu modeli mówi, że Fusion jest ogólnie dostępny. Orkiestracja oznacza koordynowanie modeli i etapów ich wykonania. Programiści wybierają poziom wysiłku, a system określa, jak wykorzystać kwalifikujące się modele.

GitHub opisuje bezpośrednie wykonanie, eskalację po kontroli jakości oraz szkic, po którym następują krytyka i rewizja. Podejścia te odnoszą się do różnych wzorców błędów. Proste żądanie niekoniecznie wymaga takiego samego traktowania jak trudne zadanie debugowania.

Gdy Copilot Fusion wyjaśnimy w ten sposób, jego strategiczne znaczenie staje się wyraźniejsze. GitHub sprzedaje warstwę decyzyjną ponad poszczególnymi modelami. Warstwa ta próbuje zarządzać relacją między jakością odpowiedzi, zużyciem zasobów i pracą potrzebną do uzyskania rezultatu.

Firma informuje, że Fusion Max uzyskał wynik 60 w Artificial Analysis Coding Agent Index. GitHub twierdzi, że był on w granicy dwóch punktów od Claude Code wykorzystującego Opus 5.5 Max. Informuje również o około połowie średniego kosztu API i około 40% krótszym czasie na zadanie.

Są to porównania benchmarków raportowane przez GitHub, a nie niezależnie zweryfikowane oszczędności dla konkretnej organizacji inżynieryjnej. Porównują one zdefiniowaną konfigurację oceny. Nie ustalają całkowitego wysiłku wymaganego do ukończenia i utrzymania dowolnej funkcji klienta.

Wydanie zawiera także wspierającą perspektywę klienta. Główny inżynier oprogramowania AT&T, Hari Pokhrel, twierdzi, że automatyczny wybór ogranicza niepotrzebne użycie bardziej wymagających modeli. Jego relacja opisuje korzyść operacyjną, lecz pozostaje opinią przedstawioną w zapowiedzi GitHub.

Podstawowy mechanizm jest wiarygodny bez zakładania uniwersalnych korzyści. Programista, który wielokrotnie wybiera model, musi przewidywać trudność zadania. Zautomatyzowany selektor dokonuje tej prognozy zamiast niego, wykorzystując informacje dostępne w ramach własnego procesu decyzyjnego.

Taki układ przenosi odpowiedzialność, zamiast eliminować niepewność. System routingu może nie docenić zadania, niepotrzebnie je eskalować lub wybrać podejście generujące dodatkową pracę przy przeglądzie. Kupujący muszą oceniać jego decyzje na podstawie obserwowanych wyników.

Krytyka wprowadza również subtelne ograniczenie. Zgodność między modelami nie potwierdza poprawności, gdy oba opierają się na tym samym błędnym wymaganiu. Przegląd odpowiedzi pomaga tylko wtedy, gdy proces przeglądu potrafi wykryć istotny rodzaj błędu.

Dla zespołów zakupowych wydajność benchmarkowa i dopasowanie do przepływu pracy odpowiadają na odrębne pytania. Benchmark pomaga porównać możliwości w określonych warunkach. Dowody dotyczące przepływu pracy pokazują, czy wybrany system skutecznie obsługuje repozytoria, ograniczenia i oczekiwania organizacji.

Presja konkurencyjna na Claude Code dotyczy zatem czegoś więcej niż pozycji w rankingu. Propozycja GitHub zachęca kupujących do docenienia koordynacji w całym środowisku programistycznym. Konkurencyjne systemy mogą odpowiedzieć własną jakością wykonania, wyborami integracyjnymi i doświadczeniem programistów.

Żadna z dróg nie wygrywa automatycznie. Istotne porównanie obejmuje pełną ścieżkę od żądania do zaakceptowanego rezultatu, w tym wysiłek ludzki wymagany przez każde podejście.

Aplikacja i sesje chmurowe konkurują o własność przepływu pracy

Aplikacja GitHub Copilot ma znaczenie, ponieważ miejsce, w którym programiści koordynują agentów, może stać się miejscem, gdzie gromadzą się decyzje dotyczące rozwoju.

Trwała przestrzeń robocza ma przewagę nad odizolowanymi interakcjami: ludzie mogą wrócić do celu bez odtwarzania całej jego historii. Praktyczne pytanie brzmi, czy zachowuje wystarczająco dużo znaczącego kontekstu, aby umożliwić taki powrót.

Zapowiedź GitHub dotycząca połączonych sesji chmurowych opisuje kontynuowanie tej samej pracy w obsługiwanych interfejsach. Obejmują one internet, urządzenia mobilne, edytor, aplikację i wiersz poleceń. Firma twierdzi, że sesje chmurowe korzystają z izolowanych środowisk wykonawczych, a migawki umożliwiają późniejsze wznowienie.

Ta funkcja odpowiada na znany koszt przerwania pracy. Programista nie powinien musieć ponownie wyjaśniać prowadzonego dochodzenia tylko dlatego, że odchodzi od biurka. Zachowanie sesji może również pomóc odróżnić trwające wykonanie od nowej próby z podobnymi instrukcjami.

Ciągłość sesji i ciągłość organizacyjna pozostają jednak odrębnymi kwestiami. Utrzymanie rozmowy w całości nie oznacza, że jej wymagania są aktualne. Zadanie można pomyślnie wznowić, opierając się jednocześnie na decyzji, która gdzie indziej uległa zmianie.

Interfejs musi więc zapewniać więcej niż pamięć. Ludzie muszą móc sprawdzić, co agent zrozumiał, co zmienił i jakie nierozstrzygnięte założenia pozostają. Historia kompletna pod względem technicznym może nadal być trudna do przejrzenia.

Stwarza to strategiczną szansę dla GitHub. Jeśli programiści rutynowo rozpoczynają pracę, nadzorują wykonanie i analizują wyniki we wspólnym środowisku, środowisko to zyskuje wpływ na ich nawyki. Własność przepływu pracy rośnie dzięki powtarzalnej użyteczności.

Tworzy to również otwarcie dla konkurencji. Programiści mogą preferować innego agenta, jeśli jego model interakcji ułatwia zrozumienie trudnej pracy. Szerokość integracji traci wartość, gdy wynikowa przestrzeń robocza zaciemnia rozumowanie niezbędne do podjęcia istotnej decyzji.

Badania Anthropic nad agentami programistycznymi pokazują, dlaczego konkurencja wykracza poza generowanie kodu. Firma bada rzeczywiste sesje Claude Code jako pracę interaktywną. Jej analiza jest badaniem prowadzonym przez dostawcę, lecz sama koncentracja odzwierciedla uwagę poświęcaną temu, jak ludzie korzystają z agentów.

Odpowiedzią GitHub jest uczynienie koordynacji funkcją platformy. Pytanie dla użytkowników brzmi, czy taka koordynacja ogranicza ich własne obciążenie związane z pilnowaniem spraw. Wspólna lista sesji pomaga tylko wtedy, gdy jej zawartość pokazuje, co wymaga uwagi.

Wyobraźmy sobie hipotetyczne dochodzenie, które zaczyna się od błędu produkcyjnego, a kończy proponowaną łatką. Przydatny zapis obejmuje zaobserwowaną awarię, roboczą hipotezę, sprawdzone dowody i pozostałą niepewność.

Jeśli te elementy pozostają połączone, inny inżynier może ocenić proponowany wynik przy mniejszej potrzebie odtwarzania kontekstu. Jeśli znikają w długiej historii rozmowy, organizacja zachowała dane, ale nie zachowała praktycznego zrozumienia.

To właśnie jest rywalizacja o przepływ pracy stojąca za zapowiedziami produktów. Programiści potrzebują środowisk, które pomagają im kierować pracą i ją oceniać. Najsilniejszy interfejs ułatwi wykonywanie odpowiedzialności, gdy realizacja pracy stanie się bardziej rozproszona.

Zaliczane testy nadal pozostawiają decyzję opiekunowi projektu

Ujęcie ukończonej pracy przez GitHub podnosi standard dowodów: akceptowalna łatka musi spełniać oczekiwania, których automatyczne kontrole nie zawsze wychwytują.

Pull request, czyli proponowana zmiana kodu przesłana do przeglądu, może przejść testy, a mimo to wymagać poprawek. Testy reprezentują wybrane oczekiwania. Opiekunowie projektów oceniają również zgodność, łatwość utrzymania, konwencje projektu oraz to, czy proponowane rozwiązanie odpowiada rzeczywistej potrzebie.

Niezależne badania nadają temu rozróżnieniu konkretną treść. W opublikowanym w marcu 2026 r. badaniu przeglądów prowadzonych przez opiekunów projektów METR zbadał łatki wcześniejszych agentów programistycznych. Badacze stwierdzili, że po uwzględnieniu szumu związanego z przeglądem mniej więcej połowa łatek przechodzących testy nie zostałaby zaakceptowana przez opiekunów.

Notatka badawcza dotyczyła starszych agentów i określonego środowiska benchmarkowego. Nie oceniano w niej wydań Universe ani Copilot Fusion. METR zastrzega również, że agenci nie mieli zwykłej możliwości poprawienia swoich zgłoszeń na podstawie opinii recenzentów.

Te ograniczenia mają znaczenie. Wyniki nie wyznaczają trwałego pułapu użyteczności agentów. Pokazują, dlaczego przejście automatycznych kontroli benchmarku nie może być traktowane jako równoważne akceptacji w działającym projekcie programistycznym.

Daje to niezależną, sceptyczną perspektywę na szerszą narrację o dostarczaniu oprogramowania. GitHub podkreśla ukończoną pracę, podczas gdy badania nad opiekunami projektów pokazują, że ukończenie zależy od wybranego oceniającego. Różni oceniający mogą dojść do istotnie odmiennych wniosków.

Wniosek operacyjny jest taki, by zdefiniować ukończenie przed jego mierzeniem. Zespół może uznać zadanie za zakończone, gdy testy przejdą pomyślnie, gdy recenzent je zatwierdzi albo gdy użytkownicy otrzymają zamierzone zachowanie. Każda definicja opisuje inną granicę.

W przypadku wewnętrznej zmiany o niskim ryzyku automatyczne kontrole i krótki przegląd mogą zapewnić wystarczającą pewność. Zmiana dotycząca autoryzacji lub trwałych danych tworzy inne obowiązki. Wymagany wysiłek przeglądowy wynika z konsekwencji, a nie z wygody delegowania.

Istnieje również problem sprzężenia zwrotnego. Jeśli automatyzacja uczy się na podstawie rezultatów, sygnał wyniku musi odzwierciedlać to, co organizacja ceni. Zatwierdzenie zapisane przed późniejszym defektem może sprawić, że wadliwe podejście będzie wyglądało na udane.

To spostrzeżenie jest wnioskiem dotyczącym adaptacyjnych przepływów pracy, a nie ustaleniem na temat implementacji GitHub. Wskazuje pytanie, które kupujący powinni zadać: które wyniki wpływają na przyszłe zachowanie i w jaki sposób uwzględniane są późniejsze korekty?

Zaangażowanie człowieka nie rozwiązuje automatycznie każdego problemu. Recenzenci mogą przeoczyć defekty lub zbyt szybko zaakceptować wiarygodnie brzmiące wyjaśnienia. System zbudowany wokół zatwierdzania nadal musi udostępniać podstawowe dowody w stopniu wystarczającym do sensownej analizy.

Produktywna odpowiedź nie polega ani na bezwarunkowej nieufności, ani na automatycznej akceptacji. Zespoły potrzebują granicy przeglądu dopasowanej do zadania. Potrzebują także zapisu, który łączy zgłoszenie, działania agenta, wykonane kontrole i decyzję o akceptacji.

Wizja dostarczania oprogramowania GitHub staje się wartościowa, gdy wzmacnia ten łańcuch. Sama szybsza realizacja nie może potwierdzić, że organizacja osiągnęła właściwy punkt końcowy.

Obserwuj zaakceptowaną pracę, wyniki routingu i niezawodność operacyjną

Kolejne dowody powinny pokazać, czy połączeni agenci zmniejszają całkowity wysiłek potrzebny do dostarczania akceptowalnego oprogramowania.

Pierwszym sygnałem wartym obserwowania jest zaakceptowana praca z wersji podglądowej projects. Przydatne raporty śledziłyby zadania aż do przeglądu, w tym prośby o korekty oraz pracę porzuconą przed akceptacją. Prezentacje premierowe pokazują zamierzone zachowanie; powtarzalne użycie ujawnia nawracające trudności.

Silniejszy wynik oznaczałby mniej przekazań pracy bez zwiększenia liczby poprawek. Wspierałoby to argument GitHub, że koordynacja zasługuje na własną warstwę produktu. Doniesienia o dodatkowym nadzorze lub rozproszonym kontekście osłabiłyby ten argument dla dotkniętych nim przepływów pracy.

Porównanie wymaga sensownego punktu wyjścia. Zespół już stosujący zdyscyplinowane specyfikacje i automatyczne kontrole różni się od zespołu, który wprowadza te praktyki razem z Copilot. Nie można przypisać całej poprawy agentowi, gdy zmienia się również otaczający proces.

Drugim sygnałem jest zachowanie routingu poza głównym benchmarkiem. Wartość Fusion zależy od tego, jak wybór modelu wpływa na kompletne zadania. Oceny powinny uwzględniać nieudane próby, ponowne wykonania i czas poświęcany przez ludzi na przeglądanie wyników.

Dowody na stałą jakość przy niższym całkowitym wysiłku wzmocniłyby argument za zautomatyzowaną orkiestracją. Droższa eskalacja nie jest z natury porażką, jeśli prowadzi do lepszego, zaakceptowanego rezultatu. Tanie wykonanie staje się mniej atrakcyjne, gdy wielokrotnie przerzuca pracę z powrotem na ludzi.

Klienci muszą też rozumieć zróżnicowanie. Rutynowe zmiany, nieznane systemy i niejednoznaczne zgłoszenia stawiają agentowi odmienne wymagania. Średni wynik może ukrywać przepływ pracy, który działa dobrze w jednej kategorii, a słabo w innej.

Trzecim sygnałem jest niezawodność operacyjna w kontynuowanych sesjach. Programiści potrzebują dowodów, że praca zostaje wznowiona ze zrozumiałym stanem i odpowiednimi uprawnieniami. Połączone środowisko powinno pozostawać czytelne, gdy wykonanie zostaje wstrzymane, kończy się niepowodzeniem lub przenosi między interfejsami.

Niezawodność obejmuje wiedzę o tym, co już się wydarzyło. Jeśli sesja zostaje wznowiona po częściowej zmianie, programista potrzebuje wystarczających informacji, by uniknąć zduplikowanych lub sprzecznych działań. Zachowanie podczas odzyskiwania ma znaczenie, ponieważ praca nad oprogramowaniem rzadko przebiega bez przerw.

Te obserwacje należy rozpatrywać łącznie. Wysoka akceptacja zadań przy uciążliwym nadzorze opowiada inną historię niż wysoka akceptacja z jasnymi decyzjami i ograniczoną liczbą poprawek. Wartość systemu wynika z tego połączenia.

Dla czytelników oceniających GitHub Universe 2026 punktem wyjścia powinien być ograniczony przepływ pracy, którego kryteria ukończenia zespół już rozumie. Zapiszcie pierwotne zgłoszenie, wysiłek poświęcony na przegląd oraz korekty potrzebne przed akceptacją. Porównajcie te obserwacje z istniejącym procesem, uwzględniając pracę koordynacyjną, która rzadko pojawia się w benchmarku programistycznym.

Skupcie ocenę na użytecznych rezultatach, a nie aktywności. Krótsza rozmowa, szybsza odpowiedź lub większa liczba proponowanych zmian mogą być zachęcające, nie dowodzą jednak lepszego dostarczania oprogramowania. Zapytajcie, czy odpowiedzialny inżynier rozumie wynik, czy potrzeba zgłaszającego została spełniona i czy późniejsza praca ujawnia ukryte koszty. Wykorzystajcie te dowody, aby zdecydować, które obowiązki delegować w następnej kolejności. Która część obecnego przepływu pracy najbardziej skorzystałaby na lepszej koordynacji i jaki obserwowalny rezultat przekonałby Was, że uległa poprawie?