02 - Ocena i bezpieczeństwo / Audyt kodu pisanego przez AI

Audyt kodu pisanego przez AI

23Minds prowadzi niezależny audyt kodu pisanego przez AI i z jej pomocą. Kod dostaje ocenę w czterech wymiarach: poprawność, bezpieczeństwo, utrzymywalność i jakość testów, według kryteriów, które czytacie w całości przed podpisaniem umowy.

Porozmawiajcie z inżynierem Zobaczcie pakiet

Pakiet wejściowyAudyt kodu pisanego przez AI: 1 repozytoriumod 24 000 PLN1 repozytorium · do 4 tygodni od ustalenia zakresuCo zawiera

W skrócie

Kryteria znane przed podpisem

Cztery wymiary oceny i skala 0-4 są na tej stronie, a kryteria składowe z wagami dostajecie przed podpisaniem umowy.

Ustalenia, które da się powtórzyć

Każde ustalenie wskazuje plik, linię, skutek i poprawkę, razem z uzasadnieniem, które da się sprawdzić.

Standard, który zostaje u was

Karta ocen i kryteria zostają w waszym zespole, więc te same kryteria możecie stosować między audytami.

23Minds audytuje kod pisany przez AI dla zespołów, które chcą wiedzieć, w jakim stanie jest ten kod, przed wdrożeniem i po nim.

Rozwiń podsumowanie

Audyt jest niezależny, bo dotyczy kodu, którego zespół 23Minds nie pisał: waszego albo waszego dostawcy. Audyt bierze próbkę plików albo pull requestów z waszego repozytorium, dobraną według ryzyka. Ocenia ją w czterech wymiarach: poprawność, bezpieczeństwo, utrzymywalność, jakość testów. Kończy się raportem z ustaleniami uszeregowanymi według wagi i omówieniem z zespołem. Definicje wymiarów i skala 0-4 są na tej stronie, a kryteria składowe z wagami dostajecie przed podpisaniem umowy, więc wiecie, jak kod będzie oceniany, zanim kupicie. Pakiet wejściowy obejmuje jedno repozytorium; cena zależy od jego wielkości i złożoności, a po ustaleniu zakresu jest stała, z terminem do 4 tygodni od ustalenia zakresu. Badania kodu pisanego przez AI wskazują problemy, których warto szukać w audycie: słabości bezpieczeństwa miało 29,5% fragmentów w Pythonie napisanych przez asystentów w publicznych projektach na GitHubie (Fu i współautorzy, ACM TOSEM 2025), a 22,7% problemów wprowadzonych przez commity autorstwa AI w 6 299 repozytoriach zostało w najnowszej wersji kodu (Liu i współautorzy, 2026).

Dlaczego 23Minds

Dowody, które możecie sprawdzić.

Niezależny, bo audytuje cudzy kod
Audyt dotyczy kodu, którego zespół 23Minds nie pisał: waszego albo waszego dostawcy. Ocena nie zależy od tego, kto go zbudował.
Przyjęte ustalenia obok zgłoszonych
Raport podaje, ile ustaleń przyjął wasz inżynier po weryfikacji, a nie tylko ile ich zgłosiliśmy.
Cena ustalona przed startem
Jedno repozytorium; cena stała po ustaleniu zakresu, bez ukrytych kosztów, do 4 tygodni od jego zatwierdzenia.
System jakości ISO 9001:2015
System zarządzania jakością firmy certyfikuje DNV (nr 10000439701-MSC-RvA-POL). Audyt przebiega w nim jako udokumentowana procedura.

Jak pracujemy

Proces, faza po fazie.

1
1. Zakres i próbka
Ustalamy zakres audytu: które repozytoria, jaki okres PR-ów i, jeśli to wiecie, jakie narzędzia wyprodukowały kod. Przechodzimy razem kryteria i uzgadniamy wagi dla waszego kontekstu.
Tydzień 1
2
2. Ocena
Oceniamy próbkę kodu w czterech wymiarach. Odtwarzamy każde ustalenie, oceniamy każdy wymiar na opublikowanej skali, spisujemy wagę i rekomendowaną poprawkę.
Tydzień 2-3
3
3. Raport i omówienie
Oddajemy pisemny raport, omawiamy najważniejsze ustalenia z kierownictwem i zespołem inżynierskim, zakładamy wpisy w waszym systemie zgłoszeń.
Tydzień 3-4
4
4. Ponowny przegląd po poprawkach (opcjonalnie)
Po 4-8 tygodniach sprawdzamy, czy poprawki usunęły wskazane problemy. Jeśli standard jest spełniony, wystawiamy potwierdzenie zamknięcia ustaleń.
Tydzień 4-8 po raporcie

Jak zacząć

Sposoby rozpoczęcia współpracy, od bezpłatnego do pełnego projektu.

Każda usługa ma bezpłatny pierwszy krok, pakiet wejściowy z pisemnym rezultatem i ceną podaną tutaj oraz pełny projekt albo stałą współpracę, wyceniane po rozmowie wstępnej. Po ustaleniu zakresu cena jest stała, bez ukrytych kosztów.

1
Krok 1 · Bezpłatnie
Rozmowa wstępna z inżynierem
do 60 minut · z inżynierem · bez zobowiązań
Bezpłatnie
Pokaż szczegóły
- Rozmowa wstępna z inżynierem, a jeśli wolicie zacząć sami: samoocena online
- Pisemne podsumowanie rozmowy z propozycją następnego kroku w ciągu jednego dnia roboczego
- Bez zobowiązań i bez prezentacji sprzedażowej
Porozmawiajcie z inżynierem
Polecany
2
Krok 2 · Pakiet wejściowy
Audyt kodu pisanego przez AI: 1 repozytorium
1 repozytorium · do 4 tygodni od ustalenia zakresu
od 24 000 PLN netto
Cena stała po ustaleniu zakresu na rozmowie wstępnej, bez ukrytych kosztów; dopłaty tylko za pozycje z listy Poza zakresem.
Pokaż szczegóły
- Niezależny audyt jednego repozytorium, na próbce dobranej według ryzyka
- Poprawność, bezpieczeństwo, utrzymywalność i jakość testów kodu pisanego przez AI
- Pisemny raport z ustaleniami według wagi
- Sesja omówienia z waszymi inżynierami
- Poza zakresem: Wdrożenie poprawek, testy penetracyjne, audyt infrastruktury, kolejne repozytoria, ponowny audyt po naprawie.
Zapytajcie o ten pakiet
3
Krok 3 · Projekt albo stała współpraca
Pełny zakres, wycena po rozmowie wstępnej
Zakres ustalony po rozmowie · praca w etapach · osobna wycena każdego etapu
od 80 000 PLN netto, wycena po rozmowie wstępnej
Pokaż szczegóły
- Audyt całej platformy, w wielu repozytoriach
- Bramki jakości wpięte w wasze CI
- Ponowny przegląd po wdrożeniu poprawek
Porozmawiajcie o projekcie

Brzmi znajomo?

Problemy, które rozwiązuje ta usługa.

Kod pisany przez AI trafia do repozytorium szybciej, niż ludzie są w stanie go dokładnie przeczytać
Dział zgodności pyta o dowód, że kod pisany z AI spełnia tę samą poprzeczkę co kod pisany ręcznie
Ustalenia z audytów przychodzą jako opinie bez opisanej metody, więc nikt nie umie ich powtórzyć ani podważyć

Pokaż pozostałe problemy (2)

Nowy kod trafia do repozytorium bez testów, które sprawdzałyby jego zachowanie, choć wygląda wiarygodnie
Zespół bezpieczeństwa nie wie, w których częściach kodu skupia się wkład AI

Dla kogo

CTO i szefowie inżynierii, którzy potrzebują zewnętrznego potwierdzenia jakości kodu pisanego z AI
CISO, których zespoły wdrażają kod od AI do systemów produkcyjnych pod nadzorem regulatora
Osoby odpowiedzialne za dostawców, które odbierają kod pisany z AI od firm zewnętrznych
Osoby odpowiedzialne za zgodność, które muszą pokazać audytorowi zakres i szczegółowość przeglądu kodu

Z doświadczenia

Co może pójść nie tak i co z tym robimy.

1. Narzędzie zgłasza wszystko i o niczym nie decydujeCo zostaje u was: karta ocen dla każdego wymiaru na opublikowanej skali 0-4 oraz lista odrzuconych ustaleń z powodem odrzucenia każdego
Co się dzieje
Narzędzia do przeglądu kodu z AI są ustawione na wyłapanie jak najwięcej, więc zgłaszają styl, powtarzają to, co widać w diffie, a do tego komentują pliki, których pull request nie dotknął. Praktycy zgłaszają te same trzy zastrzeżenia: za długie, wychodzi poza zmianę, z pewnością siebie podaje błędne ustalenia. Zespół szybko przestaje czytać, więc poprzeczka, którą narzędzie miało podnieść, opada.
Co z tym robimy
Oceniamy według kryteriów ustalonych przed startem zlecenia i podajemy, ile ustaleń przyjął wasz inżynier po weryfikacji, a nie tylko ile zgłosiliśmy. Każde ustalenie wskazuje plik, linię i skutek. Czego nie umiemy obronić w przeglądzie, wyrzucamy przed oddaniem raportu, a listę wyrzuconych ustaleń dołączamy.
2. Ilość kodu przerasta zdolność przegląduCo zostaje u was: mapa plików uszeregowana według ryzyka, punkt odniesienia dla duplikacji i ponownego użycia oraz jawna lista tego, co zostało poza zakresem
Co się dzieje
Kod przychodzi szybciej, niż ktokolwiek jest w stanie go przeczytać, więc przegląd zamienia się w zatwierdzanie. GitClear zmierzył ten wzorzec na 623 mln zmienionych linii z lat 2023-2026: udział kodu refaktorowanego spada, kopiuj-wklej rośnie, zduplikowanych bloków przybywa. W dniu scalenia nic nie wygląda na zepsute. Koszt pojawia się po miesiącach jako zmiany, które trwają dłużej niż kiedyś, a wtedy nikt nie umie wskazać commita, który to spowodował.
Co z tym robimy
Próbkujemy według ryzyka, a nie według ilości: w granicach ustalonej próbki ścieżki, które obsługują pieniądze, uwierzytelnianie i dane osobowe, czytamy linia po linii, resztę sprawdzamy wzorcami. Duplikację i ponowne użycie kodu między plikami mierzymy na starcie, żeby drugi audyt miał punkt odniesienia. Mówimy wprost, których części nie przeczytaliśmy.
3. Nikt nie podpisuje się pod pochodzeniem koduCo zostaje u was: pisemna polityka wnoszenia kodu pisanego z AI, szablon pull requesta z tą polityką oraz dowód, że zadziałała na dziesięciu prawdziwych scaleniach (w zakresie projektu, nie pakietu wejściowego)
Co się dzieje
Pull request zawiera pracę asystenta, kontraktora i opiekuna repozytorium, a historia commitów pokazuje jednego autora. Ankiety bezpieczeństwa klientów pytają dziś wprost, kto odpowiada za zmianę. Zapisanej odpowiedzi zwykle nie ma.
Co z tym robimy
Sprawdzamy, czy pochodzenie kodu jest w ogóle zapisywane. Proponujemy konwencję oznaczania, która przeżyje rebase i squash. Testujemy ją na prawdziwych pull requestach zamiast na dokumencie polityki. Nie wymagamy ujawnienia, którego narzędzia użyto; wymagamy, żeby zmianę przyjął nazwany człowiek.

Co dostajecie

Rezultaty, które zostają u was.

Pisemny raport z audytu (PDF, ok. 30-60 stron zależnie od zakresu)
Karta ocen dla każdego wymiaru na opublikowanej skali 0-4, z opisem warunków przyznania każdej oceny i wagami uzgodnionymi dla waszego kontekstu
Lista ustaleń według wagi (krytyczne, wysokie, średnie, niskie) z odtworzeniem każdego
Rekomendowana poprawka przy każdym ustaleniu, z fragmentami kodu i odnośnikami do linii
Wpisy w waszym systemie zgłoszeń z ustalonymi priorytetami (Linear, Jira albo GitHub Issues)
Prezentacja dla zarządu z najważniejszymi ustaleniami i planem naprawy

FAQ

Pytania przed rozpoczęciem współpracy.

Pakiet wejściowy dla jednego repozytorium ma cenę od, podaną w cenniku na tej stronie: nakład zależy od wielkości i złożoności kodu, a po ustaleniu zakresu na rozmowie wstępnej cena jest stała, bez ukrytych kosztów. Większy zakres (kilka repozytoriów, cała platforma, bramki jakości w CI) wyceniamy po rozmowie wstępnej, gdy zakres jest jasny.

W czterech wymiarach, każdy z opublikowaną definicją. Poprawność: czy kod robi to, co mówią ticket i testy, razem z przypadkami brzegowymi i ścieżkami błędów. Bezpieczeństwo: czy wprowadza podatności, niebezpieczne ustawienia domyślne, słabą obsługę sekretów albo ryzyko w zależnościach. Utrzymywalność: czy następny inżynier zrozumie, znajdzie i zmieni ten kod bez czytania całego systemu. Jakość testów: czy testy obejmują istotne scenariusze i wykrywają błędne działanie kodu, czy tylko podbijają pokrycie. Każdy wymiar ma nazwane kryteria składowe z wagami dopasowanymi do waszego kodu.

Opublikowana skala 0-4 ze stałymi kotwicami: 0 to defekt blokujący, wydanie musi stanąć; 1 to poważne braki wymagające przeróbki przed wydaniem; 2 to kod, który działa, ale z istotnymi ustaleniami i długiem do zaplanowania; 3 to spełniona poprzeczka z drobnymi ustaleniami; 4 to brak ustaleń w badanej próbce w tym wymiarze. Każda ocena w raporcie wskazuje warunek, na którym została przyznana, więc możecie podważyć pojedynczą ocenę zamiast całego raportu. Kryteria, kryteria składowe i skala nie zmieniają się między zleceniami, więc możecie stosować je do własnych PR-ów między audytami.

Tak. Standardowe NDA, praca na odizolowanej infrastrukturze, a przy szczególnie wrażliwych systemach audyt na miejscu, w waszym biurze. Gdy podlegacie regulacjom (DORA i wytyczne KNF w finansach, RODO w ochronie zdrowia), przed startem ustalamy listę wymagań do sprawdzenia. Wynik wpisujemy do raportu.

Nie. Audyt jest zewnętrznym potwierdzeniem: okresowym, niezależnym i głębszym niż codzienny przegląd. Można go zamawiać cyklicznie, na przykład raz na kwartał, obok własnego procesu.

Tak. Przy pakiecie wejściowym ponowny audyt po naprawie wyceniamy na połowę ceny pakietu; w projekcie ponowny przegląd jest w zakresie. Kończy się potwierdzeniem, które ustalenia zostały zamknięte. Przydaje się do raportu dla zarządu albo przed audytem zewnętrznym.

Wyniki zależą od badanego problemu. W prawdziwych projektach na GitHubie słabości bezpieczeństwa miało 29,5% fragmentów w Pythonie i 24,2% w JavaScripcie napisanych przez asystentów (Fu i współautorzy, ACM TOSEM 2025, 733 fragmenty). W 576 tys. próbek kodu z 16 modeli 19,7% z 2,23 mln odwołań do pakietów wskazywało pakiety, które nie istnieją (Spracklen i współautorzy, USENIX Security 2025). Eksperyment kontrolowany ze 151 uczestnikami nie wykazał systematycznej różnicy w utrzymywalności kodu napisanego z asystentem AI w porównaniu z kodem napisanym bez niego (Borg i współautorzy, ICSME 2025). Audyt sprawdza bezpieczeństwo, zależności, utrzymywalność i testy w uzgodnionej próbce waszego kodu.

Przewodniki

Przewodniki na ten temat.

Źródła

Skąd pochodzą daty i liczby.

Porozmawiajmy o AI w waszej firmie.

Napiszcie, na jakim etapie jesteście. Temat: Audyt kodu pisanego przez AI. Odpowiedź w ciągu jednego dnia roboczego.

Porozmawiajcie z inżynierem

Szczecin - ul. Wawrzyniaka 6WWarszawaZielona GóraKraków

Audyt kodu pisanego przez AI

Kryteria znane przed podpisem

Ustalenia, które da się powtórzyć

Standard, który zostaje u was

Dowody, które możecie sprawdzić.

Proces, faza po fazie.

1. Zakres i próbka

2. Ocena

3. Raport i omówienie

4. Ponowny przegląd po poprawkach (opcjonalnie)

Sposoby rozpoczęcia współpracy, od bezpłatnego do pełnego projektu.

Rozmowa wstępna z inżynierem