To, co kiedyś zajmowało nam trzy lata, budujemy teraz w trzy miesiące. I tu zaczyna się trudna część.

W tym roku coś zmieniło się w naszym zespole programistów i wciąż się do tego przyzwyczajam. W ciągu ostatnich trzech miesięcy garstka ludzi w Guardian360 odbudowała naszą platformę Lighthouse i rozszerzyła ją o więcej nowych funkcji, niż kiedyś dostarczaliśmy przez ponad trzy lata. Nie zatrudniliśmy większego zespołu ani nie znaleźliśmy większego budżetu. Wspomagane przez AI tworzenie oprogramowania po prostu usunęło ograniczenie, które kształtowało każdą decyzję o mapie drogowej, jaką kiedykolwiek podjęliśmy: niedobór ludzi i narzędzi.

Brzmi to jak dobra wiadomość i w dużej mierze tak jest. Ujawniło to jednak nowe ograniczenie, i to nie tam, gdzie spodziewałem się je znaleźć. Gdy budowanie przestaje być rzadkie, rzadkie staje się wdrożenie. Nasi partnerzy, dostawcy usług zarządzanych (MSP), którzy dostarczają naszą platformę cyberbezpieczeństwa swoim klientom, nie są w stanie wchłonąć nowych funkcji w tempie, w jakim potrafimy je teraz tworzyć. Zajmują mnie też dwa kolejne pytania. Czy oprogramowanie budowane tak szybko jest rzeczywiście bezpieczne? I czy większa liczba funkcji nie podkopie prostoty, która zawsze nas wyróżniała?

Co się zmienia, gdy budowanie przestaje być wąskim gardłem?

Przez większość historii Guardian360 nasza mapa drogowa była listą rzeczy, które chcieliśmy zbudować, uszeregowanych według tego, na co mogliśmy sobie pozwolić. Partnerzy prosili o pewne funkcje latami, a wielu z nich musiało czekać.

Dziś nasi programiści pracują u boku AI przy generowaniu kodu, testowaniu i dokumentacji. Zaczynaliśmy od Claude, modelu Anthropic, i coraz częściej przenosimy tę pracę do Hermes. Hermes nie jest modelem, lecz warstwą, którą sami zbudowaliśmy. Wykorzystuje duże modele językowe o otwartym kodzie źródłowym, aby zasilać coś, co nazywamy mózgiem firmy, i obsługuje agentów AI, którzy pomagają nam w szerokim zakresie zadań. Hermes oraz modele open source, z których korzysta, działają we własnym klastrze serwerów w Holandii, a to jest kwestią zarówno zasad, jak i praktyki. Claude nigdy nie miał dostępu do danych klientów na naszej platformie, ponieważ nasze umowy partnerskie nie pozwalają, by te dane opuszczały EU. Przenoszenie większej części naszej pracy na infrastrukturę, którą kontrolujemy, kieruje się tą samą logiką.

Nie jesteśmy wcale wyjątkiem. Według raportu Veracode 2026 GenAI Code Security Report, AI generuje obecnie mniej więcej połowę całego zatwierdzanego kodu. Pytanie nie brzmi już, czy zespoły programistyczne korzystają z AI, lecz co stanie się dalej.

Czy oprogramowanie budowane z AI jest rzeczywiście bezpieczne?

To obawa, którą traktuję najpoważniej, i podejrzewam, że będzie to pierwsze pytanie, jakie zada wielu czytelników. Badania dają niewiele powodów do spokoju. Veracode wykazał, że około 44 procent zadań generowania kodu przez AI wprowadzało ryzykowną podatność, przy średnim wskaźniku zaliczenia testów bezpieczeństwa wynoszącym 56 procent, ledwie zmienionym względem 55 procent w pierwszym raporcie. Badanie IOActive z kwietnia 2026 przeanalizowało blisko 20,000 próbek kodu i wykazało, że 31.6 procent próbek wygenerowanych przez AI było w pełni podatnych na wykorzystanie; żaden model nie dał całkowicie bezpiecznego wyniku.

Jeszcze bardziej niepokoi mnie przepaść między postrzeganiem a rzeczywistością. Cloud Security Alliance podaje, że ponad 75 procent programistów w jednym z badań uważało kod generowany przez AI za bezpieczniejszy niż kod pisany przez człowieka, podczas gdy 56 procent przyznało, że często wprowadza on problemy bezpieczeństwa. Szybkość sprawia wrażenie kompetencji. Nią nie jest.

Wniosek IOActive jest taki, że organizacje muszą traktować wynik AI jako niezaufane dane wejściowe i egzekwować obowiązkowy przegląd bezpieczeństwa przed wdrożeniem. Dokładnie tak pracujemy: AI może pisać kod, ale każda zmiana jest przeglądana przez osobę, która ją rozumie, zanim trafi na produkcję. Idziemy teraz o krok dalej, kierując nasze własne testy penetracyjne AI przeciwko sobie, w tym analizę crystal box naszego własnego kodu źródłowego, w której agenci testujący mają pełny dostęp do kodu. Prowadzimy tę analizę z użyciem kilku różnych modeli, aby martwe pola jednego modelu rzadziej pozostawały niezauważone.

Ta sama zasada kształtuje testy penetracyjne AI, które wprowadzamy u naszych partnerów, gdzie AI przeprowadza test, a konsultant partnera go podpisuje. Programiści wydają się podzielać ten instynkt. W badaniu Stack Overflow 2026 Developer Survey blisko połowa respondentów stwierdziła, że ufa wynikom AI, gdy może je zweryfikować, podczas gdy tylko 6.6 procent powierzyłoby AI ważną decyzję.

Dlaczego więcej funkcji nie oznacza automatycznie większej wartości?

Druga obawa jest mniej techniczna, ale równie realna. No Jitter opisał niedawno “powódź funkcji” w oprogramowaniu komunikacyjnym, gdzie dostawcy co roku wypuszczają setki nowych funkcji, a ich przyjęcie przez użytkowników pozostaje w tyle. Wskaźniki Pendo sugerują, że około 80 procent zbudowanych funkcji nigdy nie osiąga znaczącego przyjęcia, a 6.4 procent funkcji generuje 80 procent wszystkich kliknięć. Ten wzorzec istniał na długo przed AI. AI po prostu sprawia, że taniej go powtórzyć.

Guardian360 zawsze starało się oferować platformę, którą MSP może wyjaśnić członkowi zarządu w kilka minut. Każda funkcja, którą dodajemy, utrudnia to. Koszt zbudowania funkcji się załamał; koszt jej zrozumienia nie.

Nasi partnerzy dźwigają już sporo złożoności. Badanie CRN, opublikowane przez dostawcę rozwiązań bezpieczeństwa Coro, wykazało, że MSP zarządzają od 6 do 20 lub więcej dostawcami, aby świadczyć usługi bezpieczeństwa, oceniają integrację między tymi narzędziami zaledwie na 6.2 na 10, a tylko 7 procent jest zadowolonych ze zwrotu z narzędzi bezpieczeństwa. Ostatnią rzeczą, jakiej od nas potrzebują, jest kolejna warstwa złożoności, choćby w najlepszej intencji.

Dokąd przesunęło się wąskie gardło?

Badania DORA firmy Google oferują użyteczną perspektywę. Ich raport z 2025 roku po raz pierwszy wykazał dodatnią zależność między przyjęciem AI a przepustowością dostarczania, ale przyjęcie AI nadal korelowało z niższą stabilnością dostarczania: więcej nieudanych zmian, więcej poprawek i dłuższy czas odtwarzania. DORA stwierdziła również, że AI zwykle odzwierciedla i wzmacnia istniejące cechy organizacyjne, na dobre i na złe.

Rozszerzyłbym tę obserwację poza zespół programistów. Funkcja tworzy wartość dopiero wtedy, gdy partner ją zrozumie, skonfiguruje, wyjaśni klientowi i zbuduje wokół niej usługę. Ten łańcuch działa w ludzkim tempie. AI przyspiesza pierwsze ogniwo, a resztę pozostawia bez zmian, co oznacza, że kolejka po prostu przesuwa się w dół, do naszych partnerów i ich klientów.

Badanie Stack Overflow wskazuje w tym samym kierunku: ludzie ufają temu, co mogą zweryfikować. Partner, który nigdy nie widział działającej funkcji, nie może jej zweryfikować, nie może jej wyjaśnić i nie będzie jej sprzedawał.

Czy powinniśmy po prostu zwolnić?

Niektórzy partnerzy argumentowaliby dokładnie tak: zatrzymajcie się na chwilę, ustabilizujcie, pozwólcie nam nadrobić. To uczciwy argument i częściowo się z nim zgadzam. Dostawca, który wypuszcza nowości szybciej, niż jego kanał jest w stanie nadążyć, optymalizuje dla własnej satysfakcji, a nie dla swoich partnerów.

Jednak sztuczne zwalnianie zmarnowałoby szansę, jaką mali europejscy dostawcy dostają rzadko. Odpowiedzią, jak sądzę, jest dyscyplina, a nie hamowanie. To znaczy decydowanie, czego nie wypuszczać, traktowanie prostoty jako wymagania projektowego, a nie dodatku na końcu, i angażowanie partnerów, zanim funkcja zostanie ukończona, a nie dopiero potem.

Część tej dyscypliny jest wbudowana w samą platformę. Wprowadzamy przestrzenie robocze: zamiast prezentować każdą funkcję na jednym ekranie, grupujemy funkcjonalność według zadań, tak aby partner widział tylko to, czego wymaga bieżąca praca. Interfejs sterowany przez AI idzie o krok dalej. Strony, raporty i nawigacja stają się definicjami zamiast kodem, a agent buduje widok, o który prosi użytkownik, w granicach jego roli. To już nie jest koncepcja. Pokażemy to w działaniu 3 listopada i chcemy od naszych partnerów szczerej informacji zwrotnej, czy rzeczywiście im to pomaga.

Jest też drugi sposób na utrzymanie niskiej złożoności: pozwolić, by platforma wykonywała więcej pracy. Dziś Lighthouse mówi, co można poprawić. W przyszłości będzie to również naprawiać, tam gdzie partner i jego klient na to pozwolą. Każde zadanie, które platforma przejmuje, to zadanie, którego partner nie musi już uczyć się, wyjaśniać ani planować.

Dlaczego otwieramy drzwi centrum sterowania

Logo Guardian360 zawiera latarnię morską, a ta metafora nigdy nie wydawała się trafniejsza. Latarnia morska jest użyteczna tylko wtedy, gdy jej światło dociera do brzegu. Możemy zbudować najjaśniejsze światło na świecie, ale to nasi partnerzy niosą je do swoich klientów.

Dlatego organizujemy “Spojrzenie z centrum sterowania” we wtorek 3 listopada 2026, od 09:30 do 13:00 w Van der Valk Hotel w Woerden. Pokażemy, co zbudowaliśmy, działające na żywo, a nie na slajdach, i damy pierwszy wgląd w to, co Guardian360 dostarczy w 2027 roku. Udział jest bezpłatny, jest miejsce dla około 50 gości, a rejestracja jest otwarta do 30 października. Bardziej niż same pokazy cenię rozmowę. Wolę usłyszeć 3 listopada, że coś jest zbyt złożone, niż odkryć to w danych o przyjęciu rok później.

A więc, co jest teraz Państwa ograniczeniem?

Jeśli budowanie również dla Państwa nie jest już ograniczeniem, a dla wielu MSP ten moment jest bliżej, niż się wydaje, to co nim jest? Dla nas odpowiedź jest jasna. Gdy budowanie przestaje być rzadkie, rzadkie staje się wdrożenie. I tu zaczyna się trudna część, a jest to praca, którą możemy wykonać jedynie wspólnie z naszymi partnerami.

Źródła

Veracode: 2026 GenAI Code Security Report: AI Is Writing More of Your Code but Security Hasn’t Caught Up (July 2026)
IOActive: The Security Gap in AI-Generated Code (April 2026)
Cloud Security Alliance: Vibe Coding Security Debt: AI-Generated Vulnerabilities at Scale (April 2026)
IT Brief UK: Stack Overflow survey finds developers wary of AI tools (October 2026)
Google Cloud / DORA: Announcing the 2025 DORA report: State of AI-assisted Software Development
No Jitter: Vendors ship thousands of features, users adopt dozens (July 2026)
Coro / CRN: Your Tool Stack Is Eating Your Margins (August 2026)
Guardian360: A view from the control room, event 3 November 2026