18 czerwca 2025

AI w dobrze zorganizowanym warsztacie programistów

Klienci regularnie pytają nas, czy dzięki AI oprogramowanie powstaje szybciej i taniej. Uczciwa odpowiedź brzmi: może tak być, ale tylko w zespole, który już pracuje w uporządkowany sposób. AI wzmacnia proces, w który trafia. W dobrze zorganizowanym warsztacie zdejmuje z ludzi rutynę i zostawia więcej czasu na trudne rzeczy. W chaotycznym produkuje więcej kodu, którego nikt porządnie nie sprawdził.

Dlatego ten wpis mniej mówi o narzędziach, a bardziej o tym, gdzie stoją w naszym procesie. Opisuje, jak pracujemy w czerwcu 2025 roku – ze świadomością, że narzędzia zmieniają się co kilka miesięcy.

Najpierw porządek, potem narzędzia

Zanim jakikolwiek asystent się przyda, kilka rzeczy musi być na miejscu. Żadna z nich nie jest nowa, ale przy AI stają się ważniejsze, a nie mniej ważne:

  • Jasne zadania. W naszych projektach każdy pull request jest powiązany ze zgłoszeniem, które ma cel. Niejasne zadanie daje niejasny kod – niezależnie od tego, kto go pisze.
  • Code review jako standard. Zmiana trafia do kodu dopiero wtedy, gdy obejrzy ją inny inżynier – bez względu na to, czy napisano ją ręcznie, czy podpowiedziało ją narzędzie.
  • Automatyczne kontrole. Testy i ciągła integracja wyłapują błędy, które wyglądają wiarygodnie – a takie asystenci produkują chętnie. W części projektów potok CI/CD publikuje też raport pokrycia testami przy każdym pull requeście.
  • Spójny kod. Asystent naśladuje wzorce, które widzi w kodzie. Jeśli kod jest spójny, spójne są też podpowiedzi.

Gdy to działa, wszystko, co wygeneruje asystent, przechodzi dokładnie tę samą ścieżkę co każdy inny kod. Właśnie dlatego korzystanie z niego jest bezpieczne.

Co AI robi dziś w naszym procesie

Podsumowanie każdego pull requestu. Od grudnia 2024 roku do naszej organizacji na GitHubie podłączony jest bot AI do code review – CodeRabbit. Gdy programista otwiera pull request, po minucie czy dwóch bot publikuje krótkie podsumowanie zmiany, omówienie plik po pliku, a gdy to pomaga – diagram sekwencji nowego przepływu. Pisze po polsku, bo to język roboczy zespołów, których to dotyczy. W pierwszych tygodniach testowaliśmy też jego komentarze linia po linii; dziś korzystamy głównie z podsumowań. Bot niczego nie zatwierdza: osoba robiąca review zaczyna od czytelnej mapy zmiany, a zatwierdzenie i scalenie zostają w rękach kolegi z zespołu.

Asystenci w edytorze. Środowiska JetBrains, na które nasza firma ma licencje, mają teraz wbudowanego asystenta AI. Wiosną 2025 roku dostęp do niego stał się ustawieniem na poziomie organizacji – i właśnie tam powinna zapadać taka decyzja: czy i jak AI jest używana w projekcie, decyduje firma i umowa, a nie każdy programista osobno. Od grudnia 2024 roku firma płaci też za Cursor, edytor zbudowany wokół AI; wiosną 2025 roku pracowało w nim na opłacanych przez firmę licencjach kilku naszych programistów i nasz architekt oprogramowania. Typowe zastosowania są wszędzie takie same: powtarzalny kod i powtarzalne zmiany, mapowania danych, pierwsze wersje dobrze rozumianych komponentów i testów oraz wyjaśnienia nieznanego kodu, zanim go dotkniemy.

Czaty AI wokół kodu. Firma płaci za ChatGPT od czerwca 2023 roku, a od początku 2025 roku nasze spotkania nagrywa i streszcza narzędzie AI do notatek. Używamy ich do pracy, która otacza programowanie: przechodzenia przez długie specyfikacje, spisywania otwartych pytań, pierwszych wersji dokumentacji i opisów zmian. Wynik to szkic do sprawdzenia przez człowieka, nigdy ostateczna odpowiedź.

AI pomaga mniej tam, gdzie problem jest naprawdę nowy: przy decyzjach architektonicznych, subtelnej współbieżności i niskopoziomowym kodzie dla konkretnego sprzętu, gdzie publicznych przykładów jest mało, a błędny strzał drogo kosztuje. W projektach embedded i IoT traktujemy podpowiedzi ze szczególną ostrożnością.

Zasady, według których pracujemy

  1. Za kod odpowiada inżynier. Cokolwiek podpowiedział asystent, osoba, która zatwierdza zmianę, odpowiada za nią, musi ją rozumieć i umieć ją wyjaśnić podczas review.
  2. Kod i dane klienta tylko za jego zgodą. Kod trafia do narzędzia AI tylko wtedy, gdy pozwalają na to umowa i zasady klienta, a warunki narzędzia pasują. Danych osobowych, haseł i sekretów nigdy nie wklejamy do promptu.
  3. Umowa jest najważniejsza. Część klientów chętnie widzi pomoc AI, część ją ogranicza, część wyklucza. Robimy to, co mówi umowa.
  4. Ludzie muszą wiedzieć, jak narzędzia się mylą. Od lutego 2025 roku unijny AI Act wymaga od organizacji korzystających z systemów AI działań zapewniających odpowiedni poziom kompetencji w zakresie AI u pracowników. W zespole programistów to praktyczna wiedza: wymyślone funkcje, nieaktualne biblioteki, pewne siebie, ale błędne odpowiedzi – i to, czym wolno, a czym nie wolno dzielić się z narzędziem.
  5. Narzędzie zostaje, bo pomaga. Nie dlatego, że jest modne.

Jak ocenić, czy to naprawdę pomaga

Deklaracje o wzroście produktywności dzięki AI łatwo składać, a trudno sprawdzić, dlatego nie podajemy jednego procentu. Warto patrzeć na sygnały, które liczą się w każdym projekcie: ile trwa zadanie od startu do scalenia, ile poprawek wraca z review, ile błędów pojawia się po wydaniu. I na samych inżynierów, bo szybko zauważają, gdzie narzędzie oszczędza czas, a gdzie tylko dokłada sprzątania.

Nasze robocze założenie jest proste: największe korzyści są przy rutynowej, dobrze określonej pracy, najmniejsze – przy trudnych, nowych problemach. To mówi nam, gdzie polegać na asystentach, a gdzie trzymać je z boku.

Co dalej

Narzędzia szybko się zmieniają. Asystenci, którzy kiedyś dopisywali linię kodu, zaczynają samodzielnie wykonywać kilka kroków: zmieniają kilka plików, uruchamiają testy, proponują kompletną zmianę. Uważnie to śledzimy, a zasady będą te same: jasne zadania, testy, review i człowiek, który odpowiada za wynik.

Jest tu też lekcja dla naszych klientów. To samo, dzięki czemu AI działa w zespole programistów, sprawia, że działa w każdym procesie biznesowym: najpierw uporządkuj proces, potem wybierz narzędzie. Tak samo podchodzimy do tematu, gdy sprawdzamy pomysł na AI, zanim zaczniemy budować.

AI to kolejne narzędzie w dobrze zorganizowanym warsztacie: mocne, ale tylko tak dobre jak proces wokół niego. Jeśli chcesz porozmawiać o tym, jak AI może wesprzeć Twój zespół albo Twój produkt, zobacz, co robimy w AI albo napisz do nas.

Może Cię też zainteresować:
Nowe biuro w Lublinie i targi SALZ21 w Salzburgu
Zanim zbudujesz AI: wykonalność, dane, etyka i prawo
Od asystentów do agentów: jak dziś tworzymy oprogramowanie

Zapytaj o wycenę lub poradę

Administratorem Twoich danych osobowych jest EMBIQ sp. z o.o. (Lublin). Podane przez Ciebie dane przetwarzamy wyłącznie po to, aby odpowiedzieć na Twoje zapytanie, i przechowujemy je nie dłużej niż 24 miesiące. W sprawach dotyczących Twoich danych napisz do nas na adres info@embiq.com.

Przeanalizujmy razem koncepcję Twojego projektu i to, na jakim jest etapie.

Otrzymasz od nas wstępną propozycję zakresu projektu oraz szacunek czasu i kosztów.

Konsultacje są objęte umową NDA.

EMBIQ sp. z o.o. z siedzibą w Lublinie, al. Kraśnicka 27, 20-718 Lublin · Sąd Rejonowy Lublin-Wschód w Lublinie z siedzibą w Świdniku, VI Wydział Gospodarczy Krajowego Rejestru Sądowego · KRS 0000338852 · NIP 9462590420 · kapitał zakładowy 75 000,00 zł