AI dla CTO: agenci kodujący, którzy się opłacają, i AI w twoich produktach

Zarząd chce zobaczyć, że AI wymiernie przyspiesza inżynierię, przy koszcie, który potrafisz wytłumaczyć. W tworzeniu oprogramowania szefowie IT widzą największy potencjał AI: 83% w badaniu Lünendonk z 2026 roku, przed cyberbezpieczeństwem (80%). Bitkom ustalił w 2026 roku, że 42% firm już używa AI w IT albo w pracy specjalistów IT, a 36% to planuje, a prezes Bitkom powiedział, że AI może przejmować zadania, które dotąd wykonywali programiści.

Zadanie wykracza poza twoje własne zespoły. W badaniu Bitkom z 2026 roku 20% użytkowników AI wbudowuje AI we własne produkty i usługi, wobec wcześniejszych 12%. W badaniu Lünendonk z 2026 roku o agentowej AI szefowie IT oczekują, że agenci pomogą w modernizacji starszych systemów: automatyczna analiza i dokumentacja (98%), budowa warstw API (97%), generowanie testów (96%), migracja baz danych (94%) i migracja kodu (72%).

• Wzrost produktywności, który wytrzyma weryfikację, mierzony na scalonych zmianach, a nie na ankietach czy liczbie tokenów.
• Wydatki na zespół, które są widoczne, ograniczone limitem i wyjaśnione jako koszt scalonej zmiany.
• Kod i dane, które trafiają tylko tam, gdzie pozwala twoja polityka.
• Obciążenie code review, które nie zjada zysku.
• Funkcje AI w twoich produktach testowane przed każdym wydaniem, na platformie wspólnej dla twoich zespołów.

Padają ze strony zarządu, bezpieczeństwa, zespołów platformowych, twoich programistów i forów inżynierskich. Przejście GitHub Copilota na rozliczanie za użycie 1 czerwca 2026 roku sprawiło, że kilka z nich stało się pilniejszych.

• Od administratorów na forach inżynierskich: „Czy twój zarząd wie, że firma płaci za każdy zużyty token?”
• Od zarządu: „Wdrożyliśmy GitHub Copilota. Jak udowodnimy, że pomaga?”
• Od bezpieczeństwa i działu prawnego: „Dokąd trafia nasz kod podczas inferencji i jaka jest polityka przechowywania danych?”
• Od zespołów platformowych: „Czy możemy kontrolować, jakich modeli używa każdy zespół? Czy możemy ustawić limity wydatków?”
• Od doświadczonych programistów: „Jeśli spędzasz więcej czasu na przeglądaniu i poprawianiu kodu z AI, niż zajęłoby ci samodzielne pisanie, to co właściwie robi dla ciebie AI?”
• Od kolegów z branż regulowanych: „Jak regulowane organizacje faktycznie pozwalają inżynierom korzystać z Claude Code albo Copilota?”

Zrób pomiar wyjściowy, zanim zaczniesz skalować, i postaw bramę, zanim zaczniesz mierzyć w wielu zespołach. W tej kolejności każdą decyzję da się cofnąć, dopóki dane jej nie potwierdzą.

• Po pierwsze pomiar wyjściowy dla każdego zespołu: koszt, scalone zmiany, czas code review, poprawki i nieudane buildy CI, na podstawie repozytoriów i rozliczeń.
• Po drugie, dokąd może trafiać kod, osobno dla każdej klasy repozytoriów: usługa dostawcy z pisemnymi zasadami przechowywania, modele na twoim własnym koncie w chmurze, takie jak Amazon Bedrock albo Azure OpenAI, albo modele open-weight na własnych serwerach dla najbardziej wrażliwego kodu.
• Po trzecie jedna brama dla całego ruchu agentów, na przykład LiteLLM: klucze dla zespołów, dozwolone modele dla zespołów, budżety, routing i logi pokazujące, dokąd trafiło każde zapytanie.
• Po czwarte narzędzia: jedno albo kilka, wybrane na podstawie dowodów. Oceniaj narzędzia, modele i ustawienia na własnych scalonych zmianach z ukrytymi testami, a nie na benchmarkach dostawców.
• Po piąte harness: instrukcje, polecenia, uprawnienia i kontrole, na których opierają się agenci kodujący, trzymane w systemie kontroli wersji i testowane na typowych zadaniach przy każdej zmianie.
• Po szóste wdrożenie zespół po zespole, z ochroną gałęzi, zasadami review dla zmian pisanych przez agentów i szkoleniami na twoich własnych repozytoriach.

Funkcje AI w produkcie, takie jak asystent na twojej dokumentacji, wyszukiwanie w portalu klienta, agent przygotowujący sprawy serwisowe albo interfejs głosowy na maszynie, wymagają tej samej dyscypliny co każde inne wydanie, a do tego testów dla odpowiedzi, które mogą się różnić. Evale, czyli powtarzalne testy systemu AI na stałych przypadkach, wyznaczają próg jakości przed wydaniem i są uruchamiane ponownie po każdej zmianie modelu, promptu albo danych.

Pod spodem jest jedna platforma dla produktów i narzędzi wewnętrznych: brama, uruchamianie modeli na własnych GPU tam, gdzie wymaga tego wolumen albo dane, wyszukiwanie z uprawnieniami, tracing, monitorowanie oraz CI/CD dla promptów i modeli. Od 2 sierpnia 2026 roku artykuł 50 AI Act wymaga informowania użytkowników, że rozmawiają z systemem AI. Jeśli produkt selekcjonuje albo szereguje kandydatów do pracy lub ocenia zdolność kredytową osób fizycznych, jest według załącznika III AI Act systemem wysokiego ryzyka, z obowiązkami od 2 grudnia 2027 roku, takimi jak zarządzanie ryzykiem, dokumentacja i nadzór człowieka. Takich decyzji nie budujemy tak, by działały bez ludzi.

• Próg akceptacji dla każdej funkcji, ustalony z product managementem na przypadkach od prawdziwych użytkowników.
• Budżet kosztu i opóźnienia na zapytanie, żeby funkcja pozostała opłacalna przy dużej skali.
• Testy regresji, które blokują wydanie, gdy jakość spada po zmianie modelu.
• Uruchamianie modeli dopasowane do wolumenu: na początku API dostawcy, własne GPU, gdy wolumen albo dane sprawiają, że to się opłaca.

Większość tych ryzyk najpierw widać jako liczbę: rachunek, kolejkę do code review, nieudany build. Każde ma kontrolę, którą da się zmierzyć.

• Rachunki za tokeny, które zaskakują finanse. Budżety na zespół w bramie, rozsądne domyślne modele, kierowanie prostych zadań do tańszych modeli i cache, raportowane jako koszt scalonej zmiany.
• Kod wypływający z firmy. Pisemne zasady przechowywania od każdego dostawcy, modele na własnym koncie w chmurze albo na własnych serwerach dla wrażliwych repozytoriów i logi bramy pokazujące, dokąd trafiło każde zapytanie.
• Code review staje się wąskim gardłem. Czas review i poprawki są mierzone dla każdego zespołu, zadania są dzielone na mniejsze, a kontrole w harnessie wyłapują typowe błędy, zanim spojrzy na nie człowiek.
• Agenci, którzy mogą za dużo. Uprawnienia w harnessie, ochrona gałęzi, skanowanie sekretów i uruchamianie w piaskownicy ograniczają, czego agent może dotknąć.
• Aktualizacje narzędzi i modeli, które psują pracę. Nowe wersje są odtwarzane na niedawno scalonych zmianach, zanim trafią do zespołów.
• Zmieniające się role w twoich zespołach. 32% firm spodziewa się, że AI ograniczy liczbę stanowisk w IT, 61% oczekuje zniknięcia rutynowych zadań, a 55% zniknięcia klasycznych zadań na start kariery (Bitkom, 2026). Raportujemy według zespołu, zadania i modelu, nigdy nie oceniamy pojedynczych osób i nie tworzymy rankingów programistów według zużycia tokenów.

Inżynierowie pytają wprost: „Can you please share how you measured that productivity gap that's real?”, czyli jak zmierzono tę rzekomo prawdziwą różnicę w produktywności. Żądaj od każdego dostawcy, także od nas, dowodów tego rodzaju.

• Wyniki na twoich własnych scalonych zmianach, sprawdzone ukrytymi testami.
• Koszt i nakład na review każdej zaakceptowanej zmiany, przed i po.
• Pisemne zasady przechowywania danych i trenowania dla każdego używanego endpointu modelu.
• Limity wydatków na zespół egzekwowane technicznie, na przykład w bramie.
• Harness, konfiguracja i testy przekazane w twoim systemie kontroli wersji i działające bez dostawcy.
• Dla AI w produktach raport z evali względem uzgodnionego progu i te same evale uruchamiane w CI.

Zacznij od bezpłatnego przeglądu wykorzystania AI. Wyślij wybrane eksporty użycia i rozliczeń z Copilota, Claude Code, Codexa, Cursora albo swojej bramy, a dostaniesz jedną stronę o tym, na co idą wydatki, co zmienić najpierw i co mierzyć dalej. Nie wymaga to dostępu do twoich systemów.

Dla jednego zespołu przegląd kosztów agentów kodujących idzie głębiej, aż do kosztu scalonej zmiany przed i po. Jeśli chodzi o AI w twoich produktach albo wspólną platformę, przynieś przypadek na bezpłatną 30-minutową rozmowę z inżynierem.