Jak pisać SQL z pomocą AI — co faktycznie przyspiesza pracę, a co tylko na to wygląda

Poprosisz AI o zapytanie SQL i po piętnastu sekundach masz gotowy kod. Wygląda dobrze, odpala się bez błędu, zwraca jakieś liczby. Problem w tym, że „działa" i „jest poprawne" to nie to samo — a w hurtowni danych, gdzie ten sam raport czyta dziesięć osób i podejmuje na jego podstawie decyzje, ta różnica kosztuje. Po kilku miesiącach używania Cursora i Claude'a do codziennej pracy z SQL-em na produkcyjnej hurtowni w Keboola mam już dość konkretny obraz tego, gdzie AI realnie oszczędza mi czas, a gdzie tylko daje złudzenie przyspieszenia — kosztem godziny debugowania później.

Gdzie AI naprawdę przyspiesza

Największy, mierzalny zysk to boilerplate i transformacje, których logika jest prosta, ale zapis żmudny. Klasyczny przykład: rozwijanie zagnieżdżonych struktur w eksporcie GA4 do BigQuery.

-- Zamiast ręcznie pisać UNNEST dla każdego parametru zdarzenia
SELECT
  event_name,
  user_pseudo_id,
  (SELECT value.string_value FROM UNNEST(event_params)
   WHERE key = 'page_location') AS page_location,
  (SELECT value.int_value FROM UNNEST(event_params)
   WHERE key = 'engagement_time_msec') AS engagement_time_msec
FROM `project.analytics_XXXXX.events_*`
WHERE _TABLE_SUFFIX = '20260728'

To zapytanie AI napisze poprawnie za pierwszym razem w 95% przypadków, bo struktura eksportu GA4 jest dobrze udokumentowana i powtarzalna. Podobnie z window functions do standardowych rzeczy — ranking, running total, porównanie okres do okresu. Kod jest mechaniczny, wzorzec znany, a błąd łatwo zauważyć, bo wynik albo się zgadza, albo nie.

Drugi obszar to tłumaczenie logiki biznesowej, którą już mam w głowie, na składnię, której nie pamiętam na pamięć. Wiem dokładnie, że chcę policzyć retencję kohortową, ale nie pamiętam, czy w Snowflake lepiej to zrobić przez DATEDIFF na miesiącach czy przez DATE_TRUNC i self-join. AI skraca ten research z dziesięciu minut w dokumentacji do jednej odpowiedzi, którą i tak sam weryfikuję.

Trzeci: dokumentacja i komentarze do istniejącego kodu. Wklejam transformację z Keboola, proszę o opis co robi każdy krok — to oszczędza realny czas przy onboardingu nowych osób w zespole, a AI jest w tym zaskakująco dobre, bo po prostu czyta kod liniowo.

Gdzie AI tylko wygląda na szybsze

Tam, gdzie AI najbardziej mnie zawodziło, to sytuacje wymagające kontekstu, którego nie ma w promptcie — a ja o tym nie pomyślałem, żeby go podać. Poprosiłem kiedyś o zapytanie liczące unikalnych kupujących miesiąc do miesiąca. Kod był składniowo bez zarzutu. Tylko że w naszej hurtowni jeden customer_id może mieć kilka user_id po połączeniu kont po loginie, i bez tej wiedzy AI policzyło coś, co wyglądało jak retencja, a było zawyżone o kilkanaście procent. To nie jest wina modelu — to jest kontekst, którego nikt mu nie dał, a który ja miałem w głowie i machinalnie założyłem, że jest „oczywisty".

Drugi problem: optymalizacja pod wydajność na dużych tabelach. AI potrafi zaproponować poprawny logicznie JOIN, ale nie wie, jak są poukładane klastry w Snowflake, gdzie leżą partycje, ani że tabela fact_orders ma miliard wierszy i trzeba filtrować po order_date przed joinem, a nie po. Dostałem kiedyś zapytanie, które zwracało prawidłowy wynik, ale skanowało całą tabelę faktów zamiast wykorzystać date jako klucz klastrujący — na malej próbce różnicy nie widać, na produkcji to była różnica między 3 sekundami a 40.

-- Wygenerowane przez AI: logicznie OK, wydajnościowo słabe
SELECT o.order_id, o.customer_id, SUM(oi.line_total)
FROM fact_orders o
JOIN fact_order_items oi ON o.order_id = oi.order_id
WHERE o.order_date >= '2026-07-01'
GROUP BY 1, 2

-- Po korekcie: filtr na kluczu klastrującym trafia do obu tabel
-- i ogranicza skan przed joinem, nie po
SELECT o.order_id, o.customer_id, SUM(oi.line_total)
FROM fact_orders o
JOIN fact_order_items oi
  ON o.order_id = oi.order_id
  AND oi.order_date >= '2026-07-01'
WHERE o.order_date >= '2026-07-01'
GROUP BY 1, 2

Trzeci: sytuacje, gdzie zapytanie ma „ładnie wyglądać" w edge case'ach, których AI po prostu nie zna, bo są specyficzne dla naszych danych — np. że eventy purchase czasem duplikują się przy retry na froncie i trzeba je deduplikować po transaction_id, a nie po event_timestamp.

Test, który stosuję zanim zaufam wygenerowanemu SQL-owi

Nie czytam wygenerowanego kodu linia po linii szukając literówek — to bez sensu, bo składniowo prawie zawsze jest OK. Zamiast tego sprawdzam trzy rzeczy:

1. Liczba wierszy przed i po każdym joinie. Jeśli join zwiększa liczbę wierszy tam, gdzie się tego nie spodziewam — jest duplikacja kluczy, o której AI nie wiedziało.
2. Wynik na znanym przypadku brzegowym. Biorę jednego konkretnego klienta czy jedno zamówienie, które znam z pamięci, i sprawdzam ręcznie, czy liczba się zgadza.
3. Explain plan albo query profile — w Snowflake sprawdzam, czy zapytanie faktycznie korzysta z partycji/klastrów, zanim odpalę je na pełnej tabeli produkcyjnej.

Ten trzyminutowy checklist wyłapał mi więcej błędów niż godzina czytania kodu.

Prompt to nie jest specyfikacja

Największa zmiana w tym, jak teraz pracuję: przestałem traktować pierwszy prompt jako coś, co ma dać gotowy wynik. Traktuję go jako pierwszą iterację, do której sam dokładam kontekst, którego model nie mógł znać — strukturę kluczy, znane edge case'y, wolumen danych. Im więcej z tego kontekstu wrzucę na start (schema, przykładowe wiersze, znane pułapki w danych), tym mniej muszę potem poprawiać. AI nie skraca myślenia o problemie — skraca czas zapisu tego myślenia w składni.

TL;DR

• AI realnie przyspiesza: boilerplate (UNNEST, window functions), tłumaczenie znanej logiki na nieznaną składnię, dokumentowanie istniejącego kodu.
• AI tylko wygląda na szybsze tam, gdzie potrzebny jest kontekst biznesowy lub o strukturze danych, którego nie ma w promptcie — duplikaty kluczy, connected accounts, edge case'y w danych.
• Optymalizacja pod wydajność (klastry, partycje, kolejność filtrów) to wciąż domena, w której trzeba wiedzieć, jak fizycznie ułożona jest hurtownia — AI tego nie widzi.
• Sprawdzaj liczbę wierszy przed/po joinie, testuj na znanym przypadku brzegowym, patrz na query profile — to szybsze niż czytanie kodu linia po linii.
• Im więcej kontekstu (schema, edge case'y, wolumen) wrzucisz w pierwszy prompt, tym mniej poprawek później — prompt to punkt startowy, nie specyfikacja gotowego rozwiązania.