Asystent programistyczny w Big Data i ML: szybko nie zawsze znaczy dobrze

W połowie 2025 roku dla większości doświadczonych inżynierów oprogramowania asystent programistyczny nadal był głównie narzędziem do autouzupełniania kodu. Rok później mówimy już o rozwiązaniach, które coraz lepiej rozumieją rozległe repozytoria, potrafią modyfikować wiele plików powiązanych skomplikowanymi zależnościami, uruchamiać testy, korzystać z CLI i generować uwagi do code review w pull requestach. 

Generowanie kodu to dopiero początek

W web developmencie ta zmiana jest już dobrze widoczna. Problem w tym, że w projektach Big Data i ML zachwyt nad samym generowaniem kodu bywa mylący. Trudniejsze pytanie brzmi: Co dzieje się na froncie w inżynierii dużych zbiorów danych i uczeniu maszynowym – tam, gdzie kod jest tylko jednym z elementów większego systemu?  

Już dziś powstają narzędzia pokroju Databricks AI Dev Kit, które bazują na predefiniowanych zestawach umiejętności, tzw. „skills”, wzorcach zarządzania danymi oraz narzędziach osadzonych w realnym środowisku platformowym do pracy z Big Data i ML. To robi wrażenie! I słusznie. Bo najtrudniejsze rzeczy w tych systemach rzadko dotyczą samej składni kodu. To co sprawia realną trudność to semantyka danych, zależności między pipeline’ami, zasoby potrzebne do pracy na produkcyjnym wolumenie danych, zgodność train-serve, monitorowanie dryftu, jakość danych, governance i odpowiedzialność za to, co trafia na produkcję. Czyli osadzenia systemu w kontekście realnych, zmieniających się zależności. 

Właśnie dlatego Big Data oraz ML są dobrym papierkiem lakmusowym dla całej dyskusji o dojrzałości AI do dostarczania oprogramowania. A dla nas w Lingaro efektywne zastosowanie szerokiej gamy narzędzi AI jest jedną z najważniejszych kwestii w rozwoju kompetencji Data i AI Engineeringu. 

Big Data i ML to nie jest kolejny CRUD

Zatem jakie wyzwania możemy spotkać na swojej drodze?

• Transformacja danych może działać poprawnie na małej próbce, a przestać mieć sens przy większym wolumenie.  
• Model może raportować świetne metryki, ale tylko dlatego, że do pipeline’u wślizgnął się leakage.  
• Feature engineering może dawać poprawny wynik offline, ale nie zgadzać się z logiką online.  

Na produkcji modele zależą od jakości danych, feature skew, dryftu i ciągłego monitoringu. W systemach uczących się szybkie zwycięstwa często zostawiają po sobie splątane zależności, źle zdefiniowane feedback loopy i narastający koszt utrzymania.

Przy pracy w systemach ML pytanie nie brzmi więc: „czy asystent potrafi wygenerować ten kod?”, tylko: „jak zapewnić, żeby wygenerowany kod można było skutecznie ewaluować, skalować i rozwijać – używając AI do kolejnych iteracji?”.  Jest to kolejny kamień milowy w dojrzałości pracy z asystentami.  

Od promptów do systemu pracy z AI

Największy błąd, jaki dziś widzę, to wciąż skupienie zbyt dużej uwagi na promptcie. Oczywiście, dobrze sformułowane polecenie jest kluczowe. Ale w dojrzałych projektach Big Data i ML różnica nie bierze się z tego, że ktoś nauczył się pisać bardziej eleganckie prompty, lecz z tego jak asystent działa w ramach systemu pracy, a nie w próżni programisty. 

Dojrzały asystent powinien działać w imieniu użytkownika z odpowiednimi uprawnieniami, mieć kontekst repozytorium kodu, znać standardy zespołu, ograniczenia architektoniczne, zasady bezpieczeństwa, kontrakty danych, metodologie uczenia maszynowego oraz wzorce walidacji i iteracji. Powinien mieć też dostęp do odpowiednich narzędzi. 

MCP, zapoczątkowany przez Anthropic, a obecnie rozwijany pod skrzydłami Linux Foundation, stał się jednym z najważniejszych otwartych standardów łączenia asystentów z danymi, narzędziami i systemami, w których faktycznie wykonywana jest praca. 

Podobny kierunek widać już w narzędziach platformowych. 

Open-source’owy Databricks AI Dev Kit jest blisko frontu realnych wdrożeń. Zawiera wzorce, skille i ponad 75 wykonywalnych narzędzi, których asystent AI potrzebuje, aby budować rozwiązania na Databricks. 

Microsoft Fabric Copilot działa z kolei w kontekście notebooka, workspace’u, schematów, tabel i plików w Lakehouse. To bardzo dobre przykłady do przestudiowania, jeśli chcemy zrozumieć, jak zmienia się praktyka dostarczania systemów data-driven.

Framework AI KONTUR

Żeby nie zostać na poziomie abstrakcji, proponuję prosty framework pracy z asystentami programistycznymi w projektach Big Data i ML: AI KONTUR. 

AI KONTUR można kojarzyć z granicami przestrzeni, w której działa asystent. 

K jak Kontekst

Zanim asystent cokolwiek wygeneruje, powinien dostać kontekst systemu. Nie tylko nazwę taska, ale też semantykę danych, definicje kluczowych kolumn, oczekiwany kształt wejścia i wyjścia, model dostępów, SLA pipeline’u, zależności upstream/downstream i przykładowe przypadki brzegowe. 

Bez tego asystent zwykle nie rozwiązuje realnego problemu. Co najwyżej generuje kod, który wygląda wiarygodnie.

O jak Ograniczenia

Trzeba jasno określić, czego używać nie wolno, jakie są limity zasobów, co można modyfikować, jakie dane są wrażliwe, jak wygląda model autoryzacji i jakie są ograniczenia budżetowe. 

W projektach Big Data i ML ograniczenia nie są formalnością. Są częścią architektury. Kod, który działa, ale łamie model bezpieczeństwa albo generuje nieakceptowalny koszt przetwarzania, nie jest dobrym kodem.

N jak Narzędzia

Tu zaczyna się prawdziwe przejście od promptów do systemu. Asystent nie powinien być tylko czatem. Powinien mieć możliwość wykonywania bezpiecznych, kontrolowanych akcji: uruchomienia testów, sprawdzenia planu wykonania, przeczytania dokumentacji wewnętrznych wzorców, użycia narzędzi, sprawdzenia schematów danych, zajrzenia do model registry albo do wykonanych eksperymentów. 

Stąd rosnące znaczenie skills oraz MCP. Asystent bez narzędzi zgaduje. Asystent z narzędziami zaczyna współpracować z realnym środowiskiem.

T jak Testy

Największą wartość asystentów programistycznych widzę nie w samym generowaniu kodu, ale w przyspieszeniu ścieżki: implementacja → walidacja → poprawka. Tylko że to działa dopiero wtedy, gdy naprawdę istnieją testy i sensowna walidacja. 

W Data/ML absolutne minimum to: testy jednostkowe transformacji, testy jakości danych, walidacja schematu, testy integracyjne i regresyjne, benchmarki wydajnościowe tam, gdzie koszt ma znaczenie, oraz osobna walidacja modelowa: holdout, leakage guardrails, dryftu/skew monitoring i metryki po wdrożeniu. 

Jeśli tego nie ma, asystent nie skraca procesu. Zwiększa tylko wolumen niezweryfikowanych zmian.

U jak Uzgodnienie

DORA.dev bardzo trafnie opisuje „verification tax”: czas zaoszczędzony na generowaniu kodu wraca później jako narzut na audyt, promptowanie, poprawki i review. To szczególnie boli wtedy, gdy autor generuje ogromne PR-y, a reviewer nadal odpowiada za całość. 

W praktyce właśnie dlatego warto przenieść jak najwięcej automatycznej walidacji jak najbliżej autora, pracować na małych zmianach i zawsze wymagać dowodów zamiast wiary.

R jak Rejestr

Na końcu zostaje rzecz, której większość zespołów nie docenia a staje się kluczowa: dokumentacja decyzji. 

Nie chodzi o automatycznie wygenerowany opis klasy czy pipeline’u. Chodzi o zapisanie, dlaczego dana transformacja istnieje, jakie ma założenia biznesowe, jakie były kompromisy kosztowe, jak działa rollback, co monitorować po wdrożeniu i kto jest właścicielem. 

Automatycznie wygenerowane dokumentacje są szybkie, ale dobra dokumentacja operacyjna nadal jest efektem myślenia zespołu. I to właśnie ona często odróżnia przyjemne demo od operacyjnego systemu, który da się utrzymać za pół roku.

Antywzorce, które wyglądają jak produktywność

Największe ryzyko pojawia się wtedy, gdy zespół przyspiesza generowanie kodu, ale nie zmienia niczego w procesie. 

Asystent wygenerował transformację danych, a nikt nie sprawdził zmiany semantyki kolumn. Kod przeszedł na próbce, ale nie miał sensu na danych produkcyjnych. Asystent napisał poprawny składniowo Spark SQL, ale koszt wykonania okazał się fatalny. Pipeline treningowy wyglądał dobrze, tylko przygotowanie danych było inne niż na produkcji. Model miał świetne KPI, bo pojawił się data leakage. Dokumentacja została wygenerowana szybko, ale opisywała nie wymagania biznesowe, tylko to, co LLM „wydedukował” z kodu. Pull request został zatwierdzony, mimo że wolumen zmian radykalnie wzrósł. 

Wszystkie te sytuacje wyglądają jak produktywność. W praktyce są antywzorcami implementowanymi przez wielu inżynierów i szybką ścieżką do długu technicznego. 

Simon Willison dobrze rozróżnia te dwa światy. Jeśli LLM napisał cały kod, ale ty zrobiłeś review, przetestowałeś go i rozumiesz, to nie jest vibe coding. To po prostu software development z nowym narzędziem. 

W projektach Big Data i ML to rozróżnienie jest kluczowe. Produkcyjny pipeline nie działa „na vibe”. On spełnia wymagania użytkownika albo nie działa. Kosztuje tyle, ile powinien, albo więcej. Przestrzega zależności z innymi systemami albo je łamie. 

Co warto zrobić, zanim wdrożysz asystentów szerzej  

Jeśli miałbym sprowadzić temat do jednej praktycznej rady, brzmiałaby ona tak: nie zaczynaj od pytania, które narzędzie wybrać. Zacznij od pytania, jaki proces to narzędzie ma zasilać. 

Jeśli zespół ma jasne standardy repozytorium, małe PR-y, sensowne testy, walidację danych i modeli, przejrzyste modele własności, dobrą observability oraz platformę, która daje dostęp do kontekstu i narzędzi, to organizacyjny asystent programistyczny bardzo prawdopodobnie da realną przewagę. 

Jeśli tego nie ma, AI nadal przyspieszy pracę, ale często głównie tę część, którą najłatwiej było przyspieszyć: samo pisanie kodu. A to zwykle nie jest największe wąskie gardło ani w data engineeringu, ani w MLOps. 

W projektach typowych dla Lingaro Big Data & ML najzdrowsze podejście polega na tym, by potraktować asystenta programistycznego jak nowy element procesu inżynieryjnego – taki, który potrzebuje kontekstu, dobrze zdefiniowanych granic, skutecznej walidacji i jasnej odpowiedzialności po stronie zespołu. Zanim więc wdrożysz asystentów programistycznych szerzej, sprawdź nie tylko, czy masz dobre narzędzie, ale przede wszystkim, czy twój proces wytwarzania oprogramowania jest gotowy je wykorzystać.

• Sprawdź naszą stronę karier.