Bezpieczny rozwój wspierany przez AI
AI potrafi dziś wygenerować dużą część kodu, a przy odpowiednim rodzaju pracy przyspiesza rozwój wielokrotnie. Działający prototyp to jednak jeszcze nie system, na którym może stać firma. Przygotujemy środowisko, w którym możecie szybko rozwijać z agentami AI, a niezweryfikowana zmiana nie trafi prosto na produkcję.
Trzy tryby współpracy
Różnią się tym, ile rozwoju robicie wy, a ile my. Między trybami można przechodzić także w trakcie projektu.
Przedstawiacie problem, proces lub potrzebę biznesową. Wykonujemy analizę, projektujemy architekturę, dobieramy technologie, budujemy aplikację, testujemy ją, wdrażamy oraz zgodnie z ustaleniami rozwijamy i utrzymujemy.
Trzymamy architekturę, model danych i bezpieczeństwa, infrastrukturę oraz krytyczne części systemu. Wasz zespół tworzy wybrane funkcje, również z pomocą agentów AI. Wszystkie zmiany przechodzą te same testy i to samo review.
Rozwijacie w większości sami. My przygotujemy bezpieczny szkielet aplikacji, zasady dla agentów AI, automatyczne testy, izolowane środowisko preview i proces wydań. W zamówionym zakresie dokładamy code review, rozwiązywanie konfliktów lub utrzymanie produkcji.
Pełny rozwój na zamówienie nigdzie nie znika. Pozostałe dwa tryby to dodatek, a nie zamiennik.
AI przyspiesza rozwój, ale nie ponosi odpowiedzialności
Używamy agentów AI na co dzień i mówimy o tym otwarcie. Każdy ich wynik oceniamy jednak w kontekście konkretnego projektu. AI nie zna waszych procesów, historii danych ani tego, co się stanie, gdy pęknie integracja z sąsiednim systemem.
Analiza i rozpoznanie techniczne, implementacja, tworzenie i rozszerzanie testów, code review, szukanie błędów, dokumentacja oraz, tam gdzie ma to sens, migracje i refaktoryzacja.
Architekturę, decyzje techniczne, model bezpieczeństwa, review i jakość powstałego kodu, zakres testów oraz ocenę, czy zmiana jest gotowa na produkcję.
AI nie jest tanim zamiennikiem juniora ani samodzielnym dostawcą. To mocne narzędzie w rękach senior developera. Nie twierdzimy, że AI nigdy się nie myli. Twierdzimy, że jej wynik nie trafia na produkcję bez kontroli.
Co dla was przygotujemy
Zakres ustalamy według projektu i poziomu ryzyka. Poniższe punkty to klocki, a nie obowiązkowy pakiet.
- Stabilny szkielet architektoniczny aplikacji
- Model danych i bezpieczeństwa
- Repozytorium i strategię gałęzi
- Instrukcje i bariery dla agentów AI
- Konwencje rozwoju i strukturę projektu
- Automatyczne testy i quality gates
- Izolowane środowisko testowe lub preview
- Pipeline CI/CD
- Wersjonowane obrazy Docker lub inne artefakty wydania
- Kontrolowane wdrożenie, monitoring i kopie zapasowe
Opcjonalnie z nadzorem seniora, code review, własnym rozwojem i zarządzaniem infrastrukturą.
Jak wygląda droga zmiany na produkcję
Konkretny kształt zależy od projektu. Zasada pozostaje ta sama: na produkcję nie trafia nic, co nie przeszło testów i akceptacji.
Do gałęzi głównej nikt nie pushuje bezpośrednio. Ani wy, ani programista, ani agent AI.
Każde zadanie lub uruchomienie agenta ma własną gałąź. Mniejszą zmianę łatwiej ocenić i cofnąć.
Zmiana trafia jako pull request z opisem tego, co się zmienia i dlaczego.
Nad każdym pull requestem uruchamiają się testy, analiza statyczna i uzgodnione kontrole.
Otwieracie zmianę i sprawdzacie ją na osobnej wersji aplikacji, a nie na produkcyjnych danych.
Po waszych testach i akceptacji powstaje niezmienny artefakt wydania, zwykle wersjonowany obraz Docker.
Na produkcję trafia dokładnie ten artefakt, który przeszedł testy i akceptację. Nic nie jest po drodze przepakowywane.
Nie promujemy jednego uniwersalnego modelu gałęzi. Przy mniejszym projekcie sensowny jest prostszy przepływ, przy systemie z wrażliwymi danymi bardziej rygorystyczny.
Co się dzieje przy konflikcie zmian
Gdy nad projektem pracuje jednocześnie kilka osób i agentów, konflikty się pojawią. Nie obiecujemy, że narzędzie zawsze je rozwiąże. Obiecujemy, że nie zostaną rozwiązane po cichu i źle.
Dwie zmiany w tym samym miejscu kodu, które nie są ze sobą powiązane znaczeniowo. Taki konflikt może spróbować rozwiązać agent AI. Po scaleniu muszą ponownie przejść wszystkie istotne testy.
Zmiany dotykają tej samej logiki biznesowej, modelu danych, migracji, uprawnień lub architektury. Kod scala się bez błędu, ale wynik robi coś innego, niż zakładano. To ocenia i akceptuje senior developer.
Rozwiązywanie konfliktów i stały nadzór seniora można zamówić w ramach pakietu serwisowego. Gałęzi produkcyjnej nie da się ominąć bezpośrednim pushem agenta AI.
Wdrożenie, wersje i powrót
W zależności od zakresu projektu możecie dostać prosty interfejs, w którym sterujecie wdrożeniami bez znajomości Gita i serwerów:
- Otworzycie testową wersję aplikacji
- Zobaczycie stan automatycznych kontroli i testów
- Zaakceptujecie konkretne wydanie
- Wdrożycie zaakceptowany artefakt na produkcję
- Przywrócicie poprzednią zgodną wersję
Przy odpowiednio zaprojektowanych systemach można bezpiecznie przywrócić poprzednią zgodną wersję aplikacji. Właśnie dlatego wdraża się niezmienny artefakt: dokładnie wiadomo, do czego wracamy.
Powrót zależy od zgodności zmian w bazie danych, od integracji zewnętrznych, od operacji nieodwracalnych i od charakteru konkretnego wydania. Dlatego zmiany bazodanowe i nieodwracalne obsługujemy osobną procedurą migracji i odtwarzania.
Bezpieczeństwo i niezawodność
Bezpieczeństwo to nie kontrola doklejona do gotowej aplikacji. Zakres działań odpowiada ryzyku projektu i uzgodnionemu zakresowi usługi. Wewnętrzne narzędzie dla pięciu osób wymaga czegoś innego niż system z danymi osobowymi tysięcy klientów.
Projekt uwierzytelniania i uprawnień, rozdzielenie ról i tenantów, praca z sekretami oraz bezpieczne środowisko testowe bez produkcyjnych danych.
Zarządzanie zależnościami, automatyczna analiza statyczna, kontrola znanych podatności, secret scanning i kontrola kontenerów.
Testy scenariuszy aplikacyjnych i API, stały automatyczny security scanning, a po uzgodnieniu również test penetracyjny.
Monitoring, logowanie i alerty, kopie zapasowe i odtwarzanie, projekt infrastruktury oraz konsultacje bezpiecznego użycia AI w rozwoju.
Nie twierdzimy, że wszystkie te kontrole są automatycznie częścią każdego projektu. To, co konkretnie wdrażamy, zawsze jest w ofercie.
Po co są automatyczne testy
Testy to nie marketingowa liczba pokrycia kodu. Mają chronić scenariusze, których awaria naprawdę zaboli:
- Logowanie i zarządzanie kontami
- Uprawnienia i widoczność danych
- Pracę z ważnymi danymi
- Kluczowe reguły biznesowe
- Integracje z systemami wokół
- Migracje bazy danych
- Podstawowe przepływy użytkownika
- Smoke test po wdrożeniu
Zakres testów odpowiada projektowi. Nie obiecujemy z góry konkretnego procentu pokrycia kodu. Wysoka liczba sama w sobie nie oznacza, że aplikacja jest w porządku.
Testy penetracyjne
Testy penetracyjne wykonujemy, ale nie są automatyczną częścią każdego projektu.
- Mogą być częścią dostarczenia bezpiecznego szkieletu, jeśli są wyraźnie w ofercie
- Można je zamówić osobno w dowolnym momencie za dopłatą
- Zakres testu zawsze definiujemy z wyprzedzeniem
- Obok nich oferujemy stały automatyczny security scanning
Automatycznego skanu podatności nie nazywamy testem penetracyjnym. Skan szuka znanych podatności z bazy, a test penetracyjny to ukierunkowana praca człowieka.
Kto prowadzi infrastrukturę
Mamy trzy warianty i żaden nie jest obowiązkowy. Wybieramy według waszych zasad wewnętrznych i tego, gdzie dane muszą pozostać.
Aplikację prowadzimy we własnej infrastrukturze Docker, razem z monitoringiem, kopiami i aktualizacjami. Serwerami nie musicie się zajmować.
System działa u was lub u waszego dostawcy chmury. Utrzymanie i konserwację zgodnie z ustaleniami zapewniamy my.
Przekazujemy dokumentację, proces wydań i konfigurację. Utrzymanie zostaje u was, a my pozostajemy dostępni do rozwoju i konsultacji.
Jakich modeli AI używamy
Nie używamy jednego modelu do wszystkiego. Zależnie od rodzaju zadania wybieramy odpowiedni model chmurowy lub uruchamiany lokalnie - inny do długich zadań agentowych, inny do szybkiej implementacji, przeglądu kodu czy pomocniczego przetwarzania danych. Z modeli chmurowych pracujemy obecnie na przykład z Claude i OpenAI GPT-5.6.
Do wybranych zadań pomocniczych, o niskiej latencji lub wrażliwych danych możemy sięgnąć po modele open-weight uruchamiane lokalnie, na przykład z rodzin Qwen, Gemma, GPT-OSS lub Llama. Zależnie od projektu działają w naszej infrastrukturze albo u was. Nie używamy ich w każdym projekcie, a do najbardziej wymagających zadań pozostają mocniejsze modele chmurowe. Lokalne uruchomienie samo w sobie nie jest też gwarancją bezpieczeństwa - nadal wymaga poprawnie ustawionych dostępów, izolacji, logowania, aktualizacji i zasad pracy z danymi.
Listę traktujcie jako aktualny stan narzędzi, a nie trwałe zobowiązanie technologiczne. Modele zmieniają się szybko, a powodem współpracy powinien być sposób pracy, nie nazwa modelu.
Częste pytania o rozwój wspierany przez AI
Czy zastąpicie programistów sztuczną inteligencją?
Co się stanie, gdy zmiany stworzone przez AI wejdą w konflikt?
Czy test penetracyjny jest częścią każdego projektu?
Czy możemy wrócić do poprzedniej wersji, gdy coś się zepsuje?
Czy z AI mogą rozwijać także osoby, które nie są programistami?
Czy to znaczy, że nie robicie już pełnego rozwoju na zamówienie?
Czy używacie także lokalnych modeli AI?
Napiszcie, a przejdziemy przez wasz zamiar, procesy i to, ile rozwoju chcecie zatrzymać u siebie. Konsultacja jest bezpłatna i niezobowiązująca. Jeśli bezpieczny rozwój z AI nie ma u was sensu, powiemy to wprost.