Agenci AI w zespole deweloperskim

Czym to się różni od wdrożenia agentów AI

Ta strona nie jest o agentach, którzy obsługują procesy biznesowe firmy — czytają zgłoszenia, uzupełniają CRM, przygotowują oferty. O nich piszemy na stronie o wdrożeniu agentów AI, do której prowadzi link powyżej, i tam projekt zaczyna się od uprawnień w systemach firmy. Tu chodzi o agentów kodujących — Claude Code, GitHub Copilot, Cursor i podobne — w rękach programistów: o to, żeby ich użycie w Twoim repozytorium przestało zależeć od tego, kto akurat siedzi przy klawiaturze, a stało się procesem, który zespół powtarza, przegląda i mierzy.

Dla kogo jest ta usługa

Dla CTO, szefa inżynierii albo właściciela software house'u, który już płaci za narzędzia agentowe, a widzi jedno z trzech:

• użycie jest nierówne — dwie osoby robią z agentem połowę roboty, reszta go nie dotyka albo używa po cichu, na prywatnych kontach;
• dyscyplina przeglądu słabnie — zmian jest więcej, a czytających je nie przybyło, więc do głównej gałęzi trafia kod, którego nikt nie rozumie;
• w dojrzałej bazie kodu agent więcej psuje, niż pomaga — bo nie zna konwencji, nie uruchamia testów i nie wie, czego mu nie wolno.

Wspólny mianownik: narzędzie jest, procesu nie ma. Ten proces budujemy razem z zespołem: reguły w repozytorium, bramki i przegląd.

Co dostajesz

• Instrukcje repozytorium i umiejętności agenta — CLAUDE.md, reguły i umiejętności (tzw. skills) dopasowane do konwencji Twojego kodu. Instrukcja to nie zabezpieczenie, dlatego obok niej:
• konfigurację środowiska i uprawnień — co agent może czytać, uruchamiać i zmieniać, a czego nigdy; sekrety poza jego zasięgiem;
• zatwierdzony dostęp do narzędzi — z serwerem MCP tylko wtedy, gdy w procesie naprawdę brakuje integracji; jak taką budujemy, opisaliśmy na stronie o połączeniu asystenta AI z Twoim systemem (MCP);
• szablony zadań dla uzgodnionej rodziny zadań — co agent dostaje na wejściu i co ma oddać;
• testy i bramki CI, które każda zmiana napisana z agentem musi przejść;
• wymagania przeglądu — co przeglądający sprawdza w takiej zmianie i czego nie wolno mu przepuścić;
• przykłady zaakceptowanych zmian z Twojego repozytorium jako wzorzec;
• zapis tego, co zadziałało, a co nie, i dlaczego;
• praktykę zespołu na prawdziwych zadaniach z backlogu — nie na ćwiczeniach.

Jak pracujemy

• Jedno repozytorium, jeden zespół. Nie „wdrożenie AI w dziale IT”, tylko miejsce, w którym da się zmierzyć przed i po.
• Jedna rodzina zadań — testy do istniejącego kodu, ograniczona funkcja, odtwarzalny błąd, wąska aktualizacja zależności. Coś, co wraca co tydzień, a nie jednorazowa migracja.
• Narzędzie dopasowane do zespołu. Pracujemy na tym, które już licencjonujesz, a jeśli wybór jest otwarty, pomagamy wybrać to, które pasuje do Twojego kodu i sposobu pracy.
• Na prawdziwym backlogu. Pierwsze zadania robimy razem, kolejne robi zespół, a my przeglądamy. Kończymy, gdy zespół powtarza proces bez nas.

Etapy, konkretny rezultat na końcu każdego z nich i podział decyzji są takie same jak w każdym naszym projekcie — opisaliśmy je w metodyce wdrożenia. Sam proces w repozytorium bywa też jednym z etapów szerszego wdrożenia AI w firmie.

Odbiór i miary

Odbieramy, gdy:

• zespół powtarza proces bez nas w każdej sesji;
• zmiany spełniają uzgodnione reguły przeglądu i testów;
• żaden sekret nie trafił do promptu, dziennika ani zmiany;
• niepowodzenia agenta są widoczne — w CI, w przeglądzie, w dzienniku — a nie ukryte w scalonym kodzie.

Mierzymy cztery rzeczy, przed i po: czas od podjęcia zadania do scalenia (lead time), czas przeglądającego na zmianę, odsetek poprawek po przeglądzie i liczbę błędów, które wyszły na produkcję. Nie mierzymy wygenerowanych linii kodu — ta liczba rośnie także wtedy, gdy zespół pracuje gorzej.

Nauka w trakcie wdrożenia

Zespół uczy się pracy z agentem w ramach wdrożenia: na Twoim kodzie, na Twoich zadaniach, z regułami, bramkami i przeglądem, które zostają w repozytorium. Dzięki temu nauka od razu przekłada się na codzienną pracę i kończy się procesem, a nie slajdami. Tak samo prowadzimy szkolenia w każdym wdrożeniu AI. Pozostałe zasady naszej pracy znajdziesz w naszych standardach.

Jak przygotowujemy repozytorium i zespół

• Najpierw stabilny build i testy. Jeżeli proces budowania projektu (build) jest niestabilny, brakuje testów albo nikt nie odpowiada za część kodu, porządkujemy to najpierw, w osobnym, wycenianym etapie prac inżynierskich. Dzięki temu agent przyspiesza dobrą pracę, a nie narastanie długu technicznego.
• Przegląd kodu zostaje u ludzi. Agent przygotowuje zmianę, a o jej scaleniu decyduje przeglądający z Twojego zespołu.
• Podział pracy ustalamy razem. Wspólnie decydujemy, które zadania pisze agent, a które zostają ludziom.
• Narzędzie dobieramy do zespołu. Pomagamy wybrać to, które pasuje do Twojego kodu, i pracujemy na licencjach, które już masz.
• Agent pracuje z dala od produkcji i sekretów. Dostaje tylko to, czego potrzebuje do zadania.

Gdzie trafia kod

Agent kodujący wysyła fragmenty kodu do dostawcy modelu. Na jakich warunkach, jak długo są przechowywane, czym różnią się konta firmowe od prywatnych i co z serwerami MCP — opisaliśmy na przykładzie Claude Code w firmie; porównanie planów i warunków innych narzędzi jest w tekście o Copilocie, ChatGPT i Claude w firmie. Konto firmowe, nie prywatne, jest warunkiem startu. Podział ról przy danych osobowych — a repozytorium ma ich więcej, niż się wydaje — opisaliśmy na stronie o bezpieczeństwie i RODO.

Zakres i cena

Najczęstsze pytania

Jak zespół uczy się pracy z Claude Code albo Copilotem?

W trakcie wdrożenia, na prawdziwych zadaniach z backlogu. Wdrażamy proces w jednym repozytorium: instrukcje i uprawnienia agenta, szablony zadań, testy i bramki CI, wymagania przeglądu oraz praktykę zespołu na prawdziwej pracy. Zespół uczy się na własnym kodzie, a po projekcie zostaje proces w repozytorium, z którego korzystają także osoby dołączające później.

Z którymi narzędziami pracujecie?

Z tymi, które Twój zespół już licencjonuje albo zamierza licencjonować — najczęściej Claude Code, GitHub Copilot, Cursor lub Codex. Jeżeli wybór jest jeszcze otwarty, pomagamy dobrać narzędzie do Twojego kodu i sposobu pracy zespołu, a w tekście o Copilocie, ChatGPT i Claude w firmie opisaliśmy, czym różnią się plany i warunki. Serwer MCP podłączamy tam, gdzie w procesie brakuje integracji z Twoimi systemami.

Ile to trwa i ile kosztuje?

Zakres i cenę ustalamy po obejrzeniu repozytorium — procesu budowania projektu (builda), testów, CI i sposobu przeglądu — oraz po wybraniu jednej rodziny zadań z Twojego backlogu. Wycena jest za etap w stałym zakresie i stałej cenie: jeden zespół, jedno repozytorium, jedna rodzina zadań, uzgodnione miary przed i po. Pierwszy etap zwykle liczy się w tygodniach. Licencje narzędzi i zużycie modeli są poza wyceną.

Jak dbacie o jakość kodu pisanego z agentem?

Proces zaczyna się od reguł przeglądu, testów i bramek CI, a nie od promptów. Zmiana napisana z agentem przechodzi te same bramki co każda inna, a przeglądający dostaje listę tego, co w takiej zmianie sprawdza. Jakość mierzymy przed i po: odsetkiem poprawek po przeglądzie i liczbą błędów, które wyszły na produkcję. Jeżeli któraś z tych miar się pogarsza, poprawiamy proces, zanim rozszerzymy go na kolejne zadania — niezależnie od tego, ile kodu powstało.

Co z bezpieczeństwem kodu i sekretów?

Trzy warunki są nienegocjowalne: konto firmowe, nie prywatne; reguły, które zabraniają agentowi czytać sekrety i dane oraz uruchamiać polecenia poza dozwolonym zakresem; oraz brak dostępu do produkcji. Agent kodujący wysyła fragmenty kodu do dostawcy modelu — na jakich warunkach, jak długo są przechowywane i co z serwerami MCP, opisaliśmy na przykładzie Claude Code w firmie. Podział ról przy danych osobowych jest na stronie o bezpieczeństwie i RODO.