GitHub udostępnił ogólnie dwie ważne funkcje przeglądu kodu Copilot: umiejętności agentów i kontekst serwera Model Context Protocol. Wpis w dzienniku zmian opublikowany 29 lipca informuje, że funkcje są teraz dostępne dla użytkowników Copilot Pro, Pro+, Business i Enterprise.

Zmiana jest węższa niż wprowadzenie nowego modelu, ale może mieć większe znaczenie dla zespołów inżynierskich próbujących sprawić, by przegląd AI był przydatny w prawdziwych repozytoriach. Przegląd kodu drugiego pilota może teraz opierać się na niestandardowych instrukcjach przeglądu przechowywanych w repozytorium lub organizacji i może pobierać kontekst tylko do odczytu z systemów zewnętrznych za pośrednictwem serwerów MCP. W praktyce oznacza to, że przegląd sztucznej inteligencji można kształtować na podstawie reguł architektury zespołu, oczekiwań dotyczących bezpieczeństwa, konwencji wewnętrznych, danych dotyczących zgłoszeń, dokumentacji i wpisów w katalogu usług bez konieczności tworzenia przez każdy zespół samodzielnego bota recenzującego.

Co się zmieniło w przeglądzie kodu Copilot

Umiejętności agenta to mechanizm GitHuba umożliwiający przeglądanie kodu Copilot bardziej szczegółowe instrukcje niż ogólny monit. Zespoły definiują te umiejętności w plikach SKILL.md w pliku .github/skills. Pliki mogą znajdować się na poziomie repozytorium lub organizacji, dzięki czemu zespół platformy może publikować wspólne wytyczne, a poszczególne projekty mogą dodawać reguły lokalne.

To ma znaczenie, ponieważ jakość przeglądu kodu często zależy od kontekstu, który nie jest oczywisty na podstawie różnicy. Recenzent może potrzebować wiedzieć, że usługa korzysta z określonego wzorca ponawiania prób, że migracja bazy danych musi być zgodna z produkcyjnym elementem Runbook lub że interfejs API dostępny dla klienta musi zachować zgodność wsteczną. Umiejętności agenta zapewniają zespołom własną ścieżkę GitHub do kodowania kontekstu na potrzeby zachowania Copilota podczas przeglądu.

Drugi element to obsługa serwerów MCP. Przegląd kodu Copilot może łączyć się z serwerami MCP w celu pobrania kontekstu zewnętrznego z systemów innych firm lub systemów wewnętrznych. GitHub wyraźnie wskazuje źródła, takie jak narzędzia do śledzenia problemów, systemy dokumentacji i katalogi usług. Dzięki temu przegląd kodu staje się bardziej połączonym przepływem pracy agenta: przegląd może uwzględnić żądanie ściągnięcia oraz otaczające go informacje o produkcie i działaniu.

GitHub twierdzi, że wywołania narzędzi MCP wykonywane podczas przeglądu kodu Copilot są ograniczone do dostępu tylko do odczytu. To ograniczenie jest istotne. Asystent przeglądu, który może sprawdzić zgłoszenie lub dokument serwisowy, jest znacznie łatwiejszy w zarządzaniu niż asystent, który może modyfikować problemy, aktualizować metadane produkcyjne lub uruchamiać przepływy pracy podczas przeglądu.

Dlaczego jest to ważne dla zespołów inżynierskich

Większość narzędzi do przeglądu kodu AI boryka się z tym samym problemem: potrafią odczytać różnice, ale nie rozumieją automatycznie organizacji. Mogą sygnalizować powierzchowne problemy ze stylem, pomijając ryzyko specyficzne dla projektu. Mogą też sugerować zmiany, które naruszają wewnętrzne standardy, ponieważ standardy te istnieją w rozproszonych dokumentach, wątkach na Slacku, katalogach usług i wiedzy plemiennej.

Posunięcie GitHuba to krok w kierunku uświadomienia infrastruktury podczas przeglądu sztucznej inteligencji. Żądanie ściągnięcia, które dotyka ścieżki uwierzytelniania, można sprawdzić, uzyskując dostęp do oczekiwań zespołu w zakresie bezpieczeństwa. Zmiany w zależności od usługi można sprawdzić w odniesieniu do własności usługi i dokumentacji. Zmiana interfejsu użytkownika powiązana z problemem może zostać zinterpretowana na podstawie kryteriów akceptacji problemu.

W przypadku indywidualnych programistów natychmiastowym efektem będą prawdopodobnie bardziej ukierunkowane komentarze w recenzjach i mniej ogólnych sugestii. Dla menedżerów inżynierów i zespołów zajmujących się platformami większą wartością jest standaryzacja. Zamiast prosić każdego recenzenta o zapamiętanie każdej wewnętrznej reguły, zespoły mogą raz zakodować podstawowy kontekst recenzji i zastosować go w repozytoriach.

Istnieje również obciążenie konserwacyjne. Umiejętności przechowywane w Markdown są łatwiejsze do przyjęcia niż niestandardowa automatyzacja, ale nadal potrzebują właścicieli. Jeśli instrukcje staną się nieaktualne, Copilot może odziedziczyć nieaktualne założenia. Jeśli będą zbyt szerokie, recenzje mogą stać się głośne. Jeżeli są zbyt nakazowe, mogą zniechęcać do stosowania uzasadnionych wyjątków. Ta funkcja nie eliminuje zarządzania recenzjami; zapewnia zespołom nową przestrzeń, na której należy zarządzać zarządzaniem.

MCP przechodzi od historii protokołu do powierzchni produktu

To ogłoszenie różni się od ostatnich zmian w samej specyfikacji MCP. Aktualizacja GitHub z 29 lipca dotyczy dostępności produktów w ramach przeglądu kodu Copilot, a nie wersji protokołu. To rozróżnienie ma znaczenie, ponieważ wdrożenie w przedsiębiorstwach często przyspiesza, gdy protokół staje się częścią powszechnie używanego przepływu pracy programistów.

MCP było omawiane głównie jako element łączący narzędzia agenta: sposób, w jaki systemy AI mogą łączyć się z kontekstem zewnętrznym i możliwościami za pośrednictwem wspólnego interfejsu. Ogólna wersja GitHuba pokazuje, że protokół staje się częścią codziennego obszaru dostarczania oprogramowania, w tym przeglądu żądań ściągnięcia.

Ta zmiana zwiększy oczekiwania w stosunku do infrastruktury obsługującej MCP. Zespoły łączące przepływy pracy recenzji z systemami wewnętrznymi będą musiały wziąć pod uwagę uwierzytelnianie, rejestrowanie, zakres dostępu, opisy narzędzi, niezawodność serwera i ścieżki audytu. Wywołania narzędzi tylko do odczytu zmniejszają ryzyko, ale nie eliminują potrzeby zrozumienia, jakie dane może zobaczyć system AI i jak ten kontekst wpływa na rekomendacje.

W tym miejscu ogłoszenie nawiązuje do szerszego rynku bram API AI. Ponieważ przepływy pracy agentów rozprzestrzeniają się pomiędzy dostawcami modeli, środowiskami IDE, hostami kodu i wewnętrznymi systemami danych, zespoły potrzebują wyraźniejszej kontroli nad używanymi modelami i narzędziami, do jakich kluczy mają dostęp i w jaki sposób przypisywane jest użycie. Platformy takie jak Model Gate są odpowiednie, gdy organizacje chcą scentralizowanego zarządzania kluczami API, analityki wykorzystania sztucznej inteligencji, routingu modeli, widoczności rozliczeń i zarządzania interfejsem API zespołu w wielu usługach AI. Wersja GitHuba wzmacnia ten sam schemat działania: funkcje AI nie są już izolowanymi oknami czatu; są to połączone elementy przepływu pracy.

Praktyczne konsekwencje i pytania otwarte

W przypadku klientów GitHub kolejnym praktycznym krokiem jest podjęcie decyzji, gdzie powinny znajdować się umiejętności agenta i kto powinien je utrzymywać. Umiejętności na poziomie repozytorium mogą działać w przypadku wyspecjalizowanych systemów. Umiejętności na poziomie organizacji lepiej odpowiadają wspólnym regułom, takim jak praktyki bezpiecznego kodowania, konwencje rejestrowania, standardy dostępności lub zasady zależności.

Zespoły rozważające połączenia MCP powinny zacząć od źródeł kontekstowych niskiego ryzyka. Katalogi dokumentacji i usług są naturalnymi pierwszymi kandydatami. Narzędzia do śledzenia problemów mogą być przydatne, ale mogą zawierać wrażliwe informacje o klientach lub incydentach, dlatego przed podłączeniem ich do przeglądu kodu należy sprawdzić granice dostępu. Ograniczenie tylko do odczytu pomaga, ale widoczność jest nadal formą dostępu.

Pozostają nierozwiązane szczegóły, które zespoły będą musiały przetestować we własnych środowiskach. Dziennik zmian GitHub potwierdza ogólną dostępność umiejętności agentów i kontekstu MCP, ale jakość recenzji w świecie rzeczywistym będzie zależeć od tego, jak dobrze napisane są umiejętności, które serwery MCP są połączone i jak Copilot nadaje priorytet konkurencyjnym fragmentom kontekstu. Z ogłoszenia nie wynika jeszcze jasno, w jaki sposób zespoły będą mierzyć, czy te przeglądy redukują defekty, przyspieszają cykle przeglądów, czy po prostu przenoszą prace związane z przeglądami na utrzymywanie instrukcji.

Kierunek jest jednak jasny. Przegląd kodu AI staje się konfigurowalny, kontekstowy i połączony z systemami korporacyjnymi. To czyni go bardziej użytecznym, ale także poważniejszym pod względem operacyjnym. Zespoły, które odniosą największe korzyści, to te, które traktują kontekst agenta jako część swojej platformy inżynieryjnej, a nie jako jednorazowy monit.