AI w procesie dostarczania software'u
Od licencji AI do wspólnego sposobu tworzenia oprogramowania.
Wasi developerzy mają narzędzia AI, ale każdy korzysta z nich inaczej i trudno powiedzieć, co tak naprawdę się zmieniło. Pomagam zespołom technologicznym zbudować własne podejście do dostarczania software'u z AI w całym procesie: od domeny i wymagań, przez kontekst projektu i implementację, po review, testy i wdrożenie.
Zaczynamy od audytu obecnego sposobu pracy. Potem idziemy krok po kroku: warsztaty, wspólna konfiguracja, praca w parach nad prawdziwymi zadaniami i, jeśli to pomaga, dłuższa współpraca.
- Dla kogo
- Firmy produktowe i software house'y z rozproszonym użyciem AI
- Zaczynamy od
- Audytu tego, jak dziś dostarczacie software
- Forma
- Warsztaty i praca w parach stacjonarnie, w Waszym biurze
Pierwszy krok
Krótki mail: jak duży jest zespół, jak dziś korzysta z AI i co chcielibyście zmienić.
bartek@bartekwitczak.com
Czy to brzmi znajomo?
Co często opisują liderzy zespołów
- Wszyscy dostali licencje na Claude, ChatGPT, Gemini albo Copilota, ale nie widzicie różnicy albo nie potraficie jej ocenić, bo nic nie jest mierzone.
- Każdy developer korzysta z innych komend, agentów i sposobów pracy. To, co działa u jednej osoby, zostaje tylko u niej.
- Jedyna wspólna praktyka AI w zespole to drogi bot do code review.
- Developerzy widzieli słaby kod wygenerowany przez AI i nie chcą z niego korzystać. Kod może nie być przygotowany do takiej pracy.
- Chcecie inwestować w AI, ale nikt nie ma czasu nadążać za tym, jak szybko zmieniają się narzędzia i modele.
Nic z tego nie oznacza, że AI nie pomaga. Oznacza, że trudno to ocenić i trudno budować na tym, co działa.
Moje podejście
Kod to tylko część dostarczania
Lepsze narzędzia nie zastąpią wiedzy domenowej, jasnych wymagań, dobrych testów ani procesu, na który zespół się umówił. Jeśli to tam jest ograniczenie, szybsze generowanie kodu tylko przenosi problem, zwykle do review.
Więcej użycia AI, więcej wygenerowanego kodu czy więcej agentów nie jest celem samym w sobie. Celem jest lepsze dostarczanie.
Nad czym pracujemy
Audyt pokazuje, które obszary są najważniejsze. Nie zmieniamy wszystkiego naraz.
Produkt, domena i wymagania
- Zaczynamy przed kodem: co trzeba zbudować i dlaczego
- Developerzy rozumieją produkt i domenę, a nie tylko tickety
- Wymagania na tyle jasne, żeby prowadziły ludzi i AI
- Tam, gdzie to pomaga, nowe spojrzenie na podział ról
Kontekst i sposób pracy
- Zasady projektu, konwencje i dokumentacja dla agentów
- Narzędzia i agenty skonfigurowane pod Wasze repozytoria
- Zapisywanie tego, czego zespół się uczy
- Małe, celowane zmiany, które łatwo przejrzeć
Weryfikacja i wdrażanie
- Strategia testów i CI/CD wspierające bezpieczne, częste zmiany
- Wartościowe testy zamiast dużej liczby testów
- Review oparte na tym, co zmiana miała zrobić
Informacje z produkcji
- Później, jeśli ma to sens: agenty z dostępem do monitoringu, które wychwytują i zgłaszają problemy
- Tylko z jasnymi uprawnieniami, akceptacją człowieka i właścicielem po Waszej stronie
Jak współpracujemy
Zaczynamy od audytu i budujemy dalej
Każdy krok opiera się na poprzednim, ale to Wy decydujecie, czy idziemy dalej.
Audyt
Rozmawiam z liderami technicznymi i produktowymi oraz z developerami. Przyglądam się repozytoriom, narzędziom, drodze od wymagania do wdrożenia i temu, jak dziś korzystacie z AI.
→ Obraz obecnej sytuacji, główne ograniczenia, rekomendacje według priorytetów, od czego zacząć (np. od zespołu pilotażowego) i jak ocenić, czy zmiany pomagają.
Warsztaty
Stacjonarne warsztaty dla developerów, a w razie potrzeby także dla liderów, oparte na wynikach audytu i prowadzone na Waszym kodzie.
→ Zespół, który mówi wspólnym językiem i ma przećwiczony nowy sposób pracy.
Wspólne podejście i konfiguracja
Kontekst i zasady projektu, konfiguracja narzędzi, praktyki review i testów, zwykle zaczynając od jednego zespołu pilotażowego. Razem decydujemy, co jest wspólne, a gdzie zespoły zachowują swobodę.
→ Działająca konfiguracja w Waszych repozytoriach i spisane podejście, na które zespół się umówił.
Praca w parach i mentoring
Pracuję z Waszymi ludźmi nad prawdziwymi zadaniami, żeby podejście stało się częścią codziennej pracy, a nie zostało w dokumencie.
→ Ludzie, którzy samodzielnie stosują to podejście i przekazują je dalej.
Stała współpraca
Dopracowywanie podejścia, przenoszenie go do kolejnych zespołów i sprawdzanie nowych narzędzi oraz modeli pod kątem tego, czego naprawdę potrzebujecie.
→ Zewnętrzny partner, który zna Wasz kontekst, w rytmie, który razem ustalimy.
Każdy krok jest osobny. Po audycie możecie zakończyć współpracę, kontynuować ze mną albo działać samodzielnie. Kolejność nie jest sztywna: niektóre zespoły potrzebują najpierw warsztatów, inne konfiguracji.
Z czym zostajecie
Własne podejście, które należy do Was
- Wspólny, spisany sposób pracy z AI w całym procesie dostarczania
- Kontekst projektu, zasady i konfiguracja narzędzi w Waszych repozytoriach
- Praktyki review, testów i weryfikacji dopasowane do Waszych zmian
- Plan dalszych usprawnień i sposób oceny, czy zadziałały
- Ludzie, którzy prowadzą i rozwijają to podejście beze mnie
Dlatego od początku potrzebujemy osoby odpowiedzialnej po Waszej stronie.
Czy to dla Was?
Zwykle tak, jeśli jesteście gotowi przyjrzeć się procesowi
Zwykle dobre dopasowanie
- Zespół korzysta z AI w rozproszony sposób albo z rozczarowującymi efektami
- Bierze udział lider, który ma wpływ na sposób dostarczania
- Jesteście gotowi przyjrzeć się procesowi, a nie tylko dodać narzędzie
- Mogą uczestniczyć osoby, które znają produkt, kod i ograniczenia
- Ktoś po Waszej stronie będzie właścicielem zmian
Raczej nie dla Was, jeśli
- chcecie wdrożyć narzędzie bez zmiany sposobu pracy
- przed startem potrzebujecie gwarancji konkretnego przyspieszenia
- potrzebujecie audytu bezpieczeństwa albo certyfikacji zgodności
- szukacie zewnętrznego zespołu, który zbuduje Wasz produkt
Granice
Czym ta współpraca nie jest
- To nie jest wdrożenie narzędzia ani rozdanie licencji.
- Nie obiecuję przyspieszenia. Na początku ustalamy, jak ocenimy, czy zmiany pomagają: jakość, liczba poprawek, czas dostarczania, koszty.
- To nie jest audyt bezpieczeństwa ani certyfikacja zgodności.
- To nie jest zewnętrzny zespół developerski. Pracuję z Waszymi ludźmi i nie przejmuję dostarczania.
- To nie jest jeden standard narzucony wszystkim zespołom.
Nie wiecie, co wybrać?
To czy warsztaty dla developerów?
Jeśli chcecie zacząć od czegoś mniejszego, warsztaty dla developerów są osobną usługą.
Dlaczego ja
Bartek Witczak
Architekt oprogramowania i principal engineer z ponad 15-letnim doświadczeniem w budowaniu kluczowych dla biznesu produktów. Z developerami rozmawiam o architekturze, a z zarządem o priorytetach.
Codziennie pracuję z AI w praktyce, w starszych i nowych projektach. Sam przygotowuję zasady projektów, design systemy i własne środowiska do pracy z AI, a także buduję z AI własne produkty.
Pomagałem zespołom usprawniać sposób dostarczania. Jako konsultant i principal engineer zajmowałem się architekturą, standardami inżynierskimi, mentoringiem i rekrutacją.
Uczę developerów. Od 2017 roku prowadzę stacjonarne warsztaty, często 2–3-dniowe, również dla dużych firm.
AI w dostarczaniu software'u to nowy temat dla wszystkich, dlatego nie sprzedaję gotowego frameworka. Budujemy podejście dopasowane do Waszego zespołu, sprawdzamy je na prawdziwej pracy i zostawiamy to, co się sprawdza.
Pytania
FAQ
+Czy musimy od razu zobowiązać się do całego procesu?
Nie. Zaczynamy od audytu. Każdy kolejny krok ustalamy osobno i w każdej chwili możecie zakończyć współpracę albo działać samodzielnie.
+Ile trwa audyt i ile kosztuje?
To zależy od wielkości zespołu i procesu. Po krótkiej rozmowie wysyłam propozycję z zakresem, harmonogramem i ceną.
+Czy wszystko musi odbywać się stacjonarnie?
Warsztaty i praca w parach odbywają się stacjonarnie, w Waszym biurze. Przy zmianie sposobu pracy ludzi to dużo skuteczniejsze niż spotkania zdalne.
+Jakie narzędzia AI polecasz?
Nie sprzedaję żadnych narzędzi. Wybieramy je na podstawie Waszych potrzeb, zasad i budżetu.
+Pracujesz z software house'ami czy z firmami produktowymi?
Z jednymi i drugimi. Szczególnie dobrze pasują firmy produktowe z własnymi zespołami developerskimi.
+Skąd będziemy wiedzieć, że to działa?
Na początku ustalamy, co oznacza dla Was „lepiej”: np. jakość, liczba poprawek, czas dostarczania, koszty i to, jak zespół faktycznie pracuje. Sprawdzamy to w czasie, zamiast mylić aktywność z poprawą.
+Co się dzieje, kiedy kończymy współpracę?
Wasz zespół jest właścicielem podejścia i dalej je rozwija. To jest cel od pierwszego dnia.
+Czy możemy zacząć od samych warsztatów?
Tak. Warsztaty dla developerów to osobna usługa i lżejszy sposób na początek.
Następny krok
Napiszcie krótkiego maila.
Wystarczy kilka zdań:
- · jak duży jest Wasz zespół developerski i co budujecie,
- · jak zespół korzysta dziś z AI,
- · co chcielibyście zmienić albo co Was niepokoi.
Odpowiadam, umawiamy krótką rozmowę i jeśli pasuje, wysyłam propozycję audytu z zakresem, harmonogramem i ceną.
bartek@bartekwitczak.com
Potrzebujecie czegoś innego?
Każda z tych usług jest osobna. To nie są kolejne kroki, które trzeba przejść.
Zewnętrzny doradca AI
AI, które realnie usprawnia pracę Twojej firmy.
Warsztaty AI dla zespołów biznesowych
Twój zespół wie, jak korzystać z AI w codziennej pracy.
Warsztaty AI dla developerów
Od pojedynczych promptów do sposobu pracy, na którym można polegać.