Dwa lata adopcji – od autouzupełniania do potoków produkcyjnych
Kwiecień 2026
Kiedy w 2024 roku nasz pierwszy programista włączył wtyczkę z autouzupełnianiem kodu, nikt w firmie nie myślał, że za dwa lata sztuczna inteligencja będzie integralną częścią każdego etapu naszego procesu wytwarzania oprogramowania. Nie byliśmy wielką korporacją z budżetem na transformację cyfrową ani startupem finansowanym przez fundusze venture. Byliśmy – i wciąż jesteśmy – małym Software Housem.
Ten artykuł to nasza historia. Nie poradnik, nie lista narzędzi z afiliacyjnymi linkami. Szczera relacja o tym, jak wyglądała adopcja AI w praktyce: co działało, co nas zaskoczyło, co okazało się ślepą uliczką i co – ostatecznie – zmieniło sposób, w jaki pracujemy na co dzień.
Etap 1 – 2024 / Początek 2025: Pierwsze kroki i nowe nawyki
Autouzupełnianie jako nowy standard
Wszystko zaczęło się niewinnie. Od włączenia biznesowej subskrypcji copilota. Po prostu narzędzia działały, oszczędzały czas i szybko stały się częścią codziennego rytuału przy klawiaturze.
Na tym etapie AI pełniło rolę bardzo sprawnego asystenta w edytorze. Uzupełniało powtarzalne fragmenty kodu, podpowiadało nazwy metod, generowało boilerplate. Dla kogoś, kto nie używał podobnych rozwiązań, było to rozszerzenie dotychczasowego podpowiadania metod.
Ale prawdziwym przełomem – choć wtedy jeszcze tego tak nie nazywaliśmy – była zmiana w sposobie szukania rozwiązań problemów technicznych.
Koniec epoki googlowania, początek epoki pytania
Przez lata Stack Overflow, dokumentacja i różne fora były pierwszym przystankiem przy każdym błędzie czy pytaniu. Nowy wzorzec wyglądał inaczej: zamiast wpisywać w wyszukiwarkę „jak zrobić X w Y”, programiści zaczęli pytać model językowy bezpośrednio.
„Zamiast przeglądać pięć zakładek i składać odpowiedź z fragmentów, po prostu opisuję problem i dostaję konkretną propozycję. Oczywiście weryfikuję – ale punkt wyjścia jest o wiele lepszy.”
Ta zmiana brzmi banalnie, ale jej konsekwencje były głębsze, niż się zdawało. Po pierwsze, pytania stały się bardziej precyzyjne – żeby uzyskać dobry wynik, trzeba dobrze sformułować problem. To wymuszało głębsze rozumienie własnej sytuacji, zanim w ogóle zaczęło się szukać odpowiedzi. Po drugie, rola indywidualnej wiedzy o topologii internetu – wiedza, że ta jedna strona zawsze ma dobry przykład – zaczęła tracić na znaczeniu.
Dla firmy oznaczało to też coś praktycznego: mniej czasu spędzonego na przeszukiwaniu zasobów, więcej czasu na faktyczne rozwiązywanie problemów. Efekty były widoczne, choć trudno je było wtedy zmierzyć.
Wnioski z pierwszego etapu
- Adopcja była organiczna – to programiści sami wprowadzali narzędzia przy pomocy firmowych zasobów.
- Bariera wejścia była niska, efekty natychmiastowe.
- Zmiana nawyków wyszukiwania była subtelna, ale realna i trwała.
- Nie wypracowano jeszcze żadnych standardów ani metod pracy z AI.
| Kluczowe pytanie tamtego okresu Czy to tylko modna gadżeciarnia, czy coś, na czym warto zbudować prawdziwy proces? |
Etap 2 – Czerwiec 2025: „Półrocze dla AI” i świadoma adopcja
Moment przełomu
Wiosna 2025 przyniosła coś, czego się nie spodziewaliśmy: zbiorową refleksję. Kilka rozmów przy kawie, kilka dyskusji na retrospektywach i nagle zdaliśmy sobie sprawę, że używamy AI od wielu miesięcy, ale robimy to każdy po swojemu, bez żadnej spójności. Jedni korzystali intensywnie, inni sporadycznie. Nie dzieliliśmy się doświadczeniami w żaden usystematyzowany sposób.
Postanowiliśmy to zmienić. Tak narodziło się to, co wewnętrznie zaczęliśmy nazywać „półroczem dla AI” – świadomy, sześciomiesięczny eksperyment mający na celu zrozumienie, jak naprawdę chcemy pracować z tymi narzędziami.
Od autouzupełniania do planowania funkcjonalności
Pierwszą i najważniejszą zmianą było wyjście poza edytor kodu. Zaczęliśmy testować, czy AI może pomagać na wcześniejszych etapach – przy projektowaniu, dekompozycji wymagań, planowaniu funkcjonalności.
Wypracowaliśmy praktykę, którą trudno opisać jednym słowem – może „prowadzone planowanie z AI”? Przed przystąpieniem do implementacji programista siadał z modelem i rozmawiała o zadaniu: jakie są warunki brzegowe, jakie możliwe podejścia, jakie ryzyko niesie każde z nich. Model pełnił rolę rozmówcy, który zadaje pytania i wskazuje na rzeczy, o których łatwo zapomnieć w ferworze kodowania.
„Zacząłem traktować model jak kolegę z doświadczeniem, który nie ma uprzedzeń do konkretnych rozwiązań. Nie broni swojego kodu, nie jest zmęczony, nie śpieszy się. Pomaga myśleć.”
Efektem było mniej niespodzianek podczas implementacji. Problemy, które wcześniej wychodziły w połowie sprintu, teraz były identyfikowane przed napisaniem pierwszej linijki kodu.
Analiza kodu i testowanie modeli
Równocześnie weszliśmy w intensywną fazę testowania różnych modeli i narzędzi. Rynek rozwija się dynamicznie – co miesiąc pojawiały się nowe możliwości. Testowaliśmy modele pod kątem kilku wymiarów: jakości sugestii kodu, zdolności do rozumienia kontekstu dużych baz kodu, umiejętności wyjaśniania złożonych fragmentów oraz szybkości odpowiedzi przy codziennej pracy.
Nie chcieliśmy być lojalni wobec żadnego dostawcy – testowaliśmy i porównywaliśmy. To podejście wymagało czasu, ale pozwoliło nam na świadomy wybór narzędzi dopasowanych do różnych zadań, zamiast ślepego podążania za hype’em.
Pliki kontekstowe jako protokół współpracy z AI
Jednym z najciekawszych odkryć tego okresu była potrzeba standaryzacji kontekstu. Modele językowe są tak dobre, jak dobry jest kontekst, który im podajesz. Szybko zorientowaliśmy się, że każdy z nas przekazuje ten kontekst inaczej – jedni opisywali architekturę projektu, inni wrzucali surowy kod, jeszcze inni nie dawali żadnego kontekstu i liczyli na intuicję modelu.
Postanowiliśmy to ustrukturyzować. Zaczęliśmy przygotowywać pliki kontekstowe – dokumenty opisujące projekt: jego architekturę, konwencje nazewnicze, przyjęte wzorce, ograniczenia techniczne, specyfikę klienta. Te pliki były dołączane do rozmów z AI jak instrukcja obsługi.
| Co zawierał typowy plik kontekstowy?Opis architektury projektu, konwencje kodu obowiązujące w projekcie, kluczowe zależności i biblioteki, znane ograniczenia i pułapki techniczne, słownik domenowy klienta, instrukcje dotyczące preferowanego stylu odpowiedzi modelu. |
Efekt był natychmiastowy. Jakość odpowiedzi modeli wzrosła dramatycznie. Zamiast generycznych sugestii, które trzeba było dostosowywać do projektu, zaczęliśmy otrzymywać odpowiedzi, które „rozumiały” specyfikę tego, nad czym pracujemy.
Pliki kontekstowe stały się z czasem żywymi dokumentami – aktualizowanymi przy każdej większej zmianie w projekcie, traktowanymi jako część repozytorium. To był nasz pierwszy krok w stronę systematycznego zarządzania wiedzą z myślą o AI jako o współpracowniku, nie tylko narzędziu.
Wnioski z drugiego etapu
- AI przestało być tylko dodatkiem do edytora – weszło do procesu planowania.
- Jakość interakcji z modelem zależy przede wszystkim od jakości kontekstu.
- Pliki kontekstowe okazały się jednym z najważniejszych narzędzi, które wypracowaliśmy.
- Testowanie wielu modeli dało nam realistyczny obraz możliwości i ograniczeń każdego z nich.
- Półrocze dla AI zakończyło chaotyczną, indywidualną adopcję i zastąpiło ją świadomym procesem.
Etap 3 – Koniec 2025 / Początek 2026: Rewolucja procesów
AI wchodzi do procesów
Jeśli pierwsze dwa etapy to były eksperymenty i nauka, trzeci etap to była rewolucja. Nie dlatego, że nagle pojawiły się nowe, niesamowite możliwości – choć to też prawda – ale dlatego, że dojrzeliśmy jako zespół do tego, żeby AI włączyć w strukturę samego procesu, nie tylko w pojedyncze działania programistów.
Pierwszym krokiem było wpięcie AI w pipeline’y CI/CD. Automatyczne przeglądy kodu generowane przez model językowy zaczęły pojawiać się w pull requestach. Nie jako zastępstwo dla code review prowadzonego przez człowieka – ale jako pierwsza linia, która wyłapuje oczywiste problemy, zanim w ogóle spojrzy na to drugi programista.
„Zmieniło to dynamikę code review. Zamiast komentować błahe rzeczy stylistyczne, możemy skupić się na tym, co naprawdę wymaga ludzkiego osądu – na decyzjach architektonicznych, na zrozumieniu intencji, na edge case’ach.”
Pomoc w code review – nie zastąpienie, lecz wzmocnienie
Ważne zastrzeżenie, które szybko stało się zasadą w naszym zespole: AI w code review to wzmocnienie, nie zastąpienie. Modele są świetne w wyłapywaniu powtarzalnych problemów, niespójności w stylu, potencjalnych błędów logicznych, brakujących przypadków obsługi błędów. Ale nie rozumieją kontekstu biznesowego, nie wiedzą, dlaczego pewne decyzje zostały podjęte, nie czują odpowiedzialności za kod.
Kod, który AI ocenia jako dobry, może być złym kodem w kontekście konkretnego projektu i konkretnego klienta. To rozróżnienie jest kluczowe i musieliśmy je wyraźnie komunikować – zarówno wewnętrznie, jak i wobec klientów, którzy pytali, jak zmieniły się nasze procesy.
Skille – wiedza skodyfikowana
Jednym z najciekawszych produktów wprowadzonych były “skile”. To pliki lub zestawy plików zawierające skodyfikowaną wiedzę o tym, jak podejść do konkretnego rodzaju zadania z pomocą AI.
Programista, który dobrze opanował metodę pracy z AI przy refaktoryzacji kodu, musiał tę wiedzę przekazywać ustnie innemu – a ta wiedza często ginęła lub była niekompletna. Skile rozwiązały ten problem: to coś pomiędzy promptem a dokumentacją, spisane wskazówki jak efektywnie korzystać z AI przy danym typie zadania.
| Przykłady skili wypracowanych w naszym zespoleSkill do analizy code review – jak opisywać PR modelowi, żeby dostać użyteczny feedback. Skill do dekompozycji wymagań – jak rozkładać niejasne wymagania klienta na mniejsze, testowalne zadania. Skill do dokumentacji – jak generować i weryfikować dokumentację techniczną. Skill do debugowania – jak efektywnie opisywać problem, żeby model pomógł go zlokalizować. |
Skile stały się żywą biblioteką wiedzy. Są aktualizowane, dyskutowane na retrospektywach, czasem odrzucane, gdy przestają działać. To jeden z artefaktów naszej pracy z AI, który ma wyraźną wartość organizacyjną – jest własnością firmy, nie konkretnego programisty.
Jak zmieniła się kultura pracy
Proces wpłynął też na kulturę. Rozmowy o tym, jak ktoś używa AI, stały się normalną częścią spotkań. Wprowadziliśmy również ”weekly AI”, na którym dyskutujemy o nowościach, opowiadamy sobie co każdy z nas zrobił ostatnio, czego się nauczył i co dobrze działa. Nie ma wstydu w przyznaniu, że coś się robiło z pomocą modelu – ważne, że wynik jest dobry i że rozumiesz, co wygenerowałeś.
To ostatnie stało się dla nas ważną zasadą: AI generuje, człowiek rozumie i odpowiada. Nie akceptujemy „czarnej skrzynki” – jeśli ktoś wkleja kod z modelu, musi potrafić wytłumaczyć, co ten kod robi i dlaczego jest właściwym rozwiązaniem. Ta zasada chroni jakość, buduje kompetencje i sprawia, że AI jest narzędziem przyspieszenia, nie narzędziem omijania myślenia.
Wnioski z trzeciego etapu
- Integracja z pipeline’ami CI/CD przeniosła AI z roli osobistego asystenta do roli elementu systemu.
- Code review z AI to uzupełnienie, nie substytut – i to rozróżnienie musi być świadome.
- Skile pozwoliły skodyfikować wiedzę o pracy z AI i dzielić się nią w sposób skalowalny.
- Zasada „AI generuje, człowiek rozumie” chroni jakość i kompetencje zespołu.
- Kultura organizacyjna musiała ewoluować równolegle z narzędziami.
Co z tego wynika? Refleksje po dwóch latach
AI nie zastąpiło programistów – zmieniło, co robią
Wbrew katastroficznym prognozom i euforycznym przepowiedniom, rzeczywistość okazała się bardziej stonowana i bardziej interesująca. Nasz zespół nie skurczył się – wręcz przeciwnie, jesteśmy w stanie przyjmować bardziej złożone projekty przy tym samym składzie personalnym. Programiści nie piszą mniej kodu – piszą lepszy kod, szybciej, bo mniejszą część energii wydają na rzeczy mechaniczne.
Zmieniła się natura pracy. Mniej czasu na boilerplate, więcej czasu na architekturę i projektowanie. Mniej czasu na szukanie odpowiedzi, więcej czasu na ocenę odpowiedzi i podejmowanie decyzji. To wymaga innych kompetencji – i być może bardziej wymagających, bo krytyczne myślenie jest trudniejsze do zautomatyzowania niż pisanie kodu.
Co polecamy innym?
Nie polecamy kopiowania naszej ścieżki. Polecamy wyciągnięcie z niej kilku zasad:
- Zacznijcie od dołu – niech programiści sami eksperymentują, zanim zarząd cokolwiek zarządzi. Ważne by było wsparcie z góry odnośnie narzędzi.
- Dajcie sobie czas na refleksję – bez świadomego „półrocza” nadal działalibyśmy chaotycznie.
- Kontekst jest wszystkim – zainwestujcie w pliki kontekstowe i skile wcześniej, niż myślicie.
- Nie pomijajcie kultury – technologia zmienia się szybko, kultura wolniej, a ona jest ważniejsza.
- Zachowajcie zasadę rozumienia – AI przyspiesza, ale nie zwalnia z odpowiedzialności.
Gdzie jesteśmy teraz?
Wiosna 2026. AI jest w naszym procesie w kilku miejscach jednocześnie: w edytorze każdego programisty, w procesie planowania funkcjonalności, w code review, w dokumentacji, w dekompozycji wymagań. To nie jest jeden projekt ani jeden system – to sieć drobnych zmian, które razem zmieniły sposób pracy.
Nie twierdzimy, że znaleźliśmy idealne rozwiązanie. Narzędzia nadal się zmieniają. Nasze skile są nadal w procesie aktualizacji. Nowe możliwości pojawiają się co kilka tygodni. Ale mamy coś cenniejszego niż optymalne narzędzia – mamy kulturę i procesy, które potrafią się adaptować.
Tego, bardziej niż konkretnych promptów czy konkretnych modeli, życzymy każdemu Software House’owi, który stoi teraz w miejscu, gdzie my staliśmy dwa lata temu.
Artykuł powstał na podstawie wewnętrznych doświadczeń firmy.
Kwiecień 2026
