Programista COBOL-a wygrał hackathon w technologii, której nie znał. Badania mówią, że to najłatwiejszy przypadek z możliwych

Na konferencji w Australii dyrektor do spraw informatyki tamtejszego urzędu podatkowego opowiedział historię: wewnętrzny hackathon wygrał programista, który całe życie pisał w COBOL-u, a zadanie zrobił w technologii .NET, w której nie napisał wcześniej ani jednej linijki. Pomógł mu Copilot.

Historia jest dobra i prawdopodobnie prawdziwa. Zanim jednak zbudujemy na niej wniosek, warto zauważyć dwie rzeczy: co dokładnie w niej jest, i dlaczego akurat ten typ zadania jest dla narzędzi AI najkorzystniejszy z możliwych.

Cała historia pochodzi z jednego tekstu branżowego, relacjonującego wystąpienie z 14 września 2026. Nie ma w niej nazwiska programisty ani jego stażu, nie ma daty hackathonu, liczby uczestników, składu jury ani opisu, co konkretnie powstało. Nie wiadomo nawet, czy „wygrał" znaczy zwycięstwo ogółem, czy w kategorii. Sam urząd nigdzie tej historii nie ogłosił — nie ma komunikatu, wpisu ani wystąpienia.

Co da się potwierdzić niezależnie, pochodzi z raportu państwowego audytora z lutego 2025. Urząd miał wtedy czterdzieści trzy modele w produkcji, osiem zatwierdzonych publicznie dostępnych narzędzi generatywnych, a siedemdziesiąt cztery procent modeli nie miało ukończonej oceny etyki danych. Ocena całości: rozwiązania tylko częściowo skuteczne, siedem zaleceń, wszystkie przyjęte.

Czego potwierdzić nie umiemy, a co warto powiedzieć wprost. Czy GitHub Copilot jest wśród tych ośmiu zatwierdzonych narzędzi, wynika z odczytu przypisu w tabeli raportu — a serwer urzędu kontroli nie odpowiada, więc raport dostępny jest wyłącznie z kopii archiwalnej. Ta jedna linijka pozostaje niepotwierdzona u źródła.

Za to w rejestrze zamówień publicznych jest coś, co układa tę historię inaczej. Trzynastego sierpnia 2025 urząd ogłosił przetarg o numerze SPC-14400 na dostarczenie narzędzia AI wspomagającego programowanie, zamknięty 19 września 2025. W opisie stoi, że chodzi o wpięcie takiego asystenta w pracę programistów urzędu. Nie pada w nim nazwa żadnego produktu ani dostawcy, a rozstrzygnięcia nie znaleźliśmy. Według relacji branżowej przetarg dotyczył około ośmiuset programistów.

Innymi słowy: w sierpniu 2025 urząd dopiero szukał narzędzia dla swoich programistów, a rok później jego dyrektor opowiada o wygranym dzięki takiemu narzędziu hackathonie. Jedno drugiemu nie przeczy — asystent mógł być dostępny z innej puli albo przetarg mógł się rozstrzygnąć bez ogłoszenia. Warto tylko wiedzieć, że publiczne dokumenty tej historii nie potwierdzają, a jedynym jej źródłem pozostaje relacja z konferencji.

Warto też zauważyć, czego dyrektor nie obiecuje. Nie spodziewa się po udostępnieniu Copilota pracownikom ani wzrostu wydajności, ani zwrotu z inwestycji. Mówi wprost, że zależy mu na czym innym — żeby jak najwięcej ludzi miało AI w rękach i wyrobiło sobie nawyk. Dopuszczenie do procesów podstawowych urzędu to u niego osobna sprawa i tam generatywnej AI nie ma.

Badania nad pomocą AI w programowaniu wyglądają na sprzeczne, dopóki nie zauważy się, kogo badały. Wtedy układają się w jedną, dość prostą regułę.

Trzecie badanie, największe z nich, obejmowało 4867 programistów w trzech firmach, w normalnym toku pracy i z losowym przydziałem dostępu do narzędzia. Liczba ukończonych zadań wzrosła o dwadzieścia sześć procent, ale nie po równo: wyraźny efekt wystąpił u osób niedawno zatrudnionych i na stanowiskach juniorskich, a u osób z długim stażem i na stanowiskach seniorskich nie wystąpił.

Reguła, która z tego wychodzi, brzmi więc tak: narzędzie pomaga najbardziej tam, gdzie człowiek wie najmniej. Zwycięzca hackathonu był dokładnie w tej sytuacji — rozumiał pojęcia podstawowe, ale nie znał konkretnej technologii ani nie miał w głowie żadnego zastanego kodu. To jest najlepszy możliwy przypadek dla AI i dlatego ta historia, choć prawdziwa, mówi mniej, niż się wydaje.

Wynik mówiący o dziewiętnastu procentach spowolnienia zrobił w 2025 roku karierę i do dziś krąży jako argument, że pomoc AI w programowaniu jest złudzeniem. Rzecz w tym, że w lutym 2026 ten sam zespół opublikował wpis, w którym zmienia projekt badania i uznaje własne dane za niewiarygodne.

Powód jest pouczający. W drugiej turze od trzydziestu do pięćdziesięciu procent uczestników przyznało w ankiecie, że przestali zgłaszać do badania te zadania, których nie chcieliby robić bez AI — czyli dokładnie te, przy których narzędzie pomaga najbardziej. Autorzy napisali wprost, że uważają za prawdopodobne, iż programiści są dziś przez narzędzia AI przyspieszani bardziej, niż wynikało z ich szacunków sprzed roku.

Kto cytuje dziś te dziewiętnaście procent bez tej poprawki, cytuje wynik, od którego odcięli się jego własni autorzy. Warto to wiedzieć niezależnie od tego, po której stronie sporu się stoi.

Najbardziej otrzeźwiająca liczba w całym tym temacie nie pochodzi z pracy naukowej, tylko z oceny, którą australijskie ministerstwo skarbu zrobiło po własnej próbie asystenta u siebie. Dwustu osiemnastu pracowników, czternaście tygodni.

To jest najuczciwsze podejście, jakie w tym temacie widzieliśmy. Zamiast ogłaszać oszczędność, której nie da się zmierzyć, urząd policzył, jak mało trzeba, żeby wydatek miał sens. Trzynaście minut tygodniowo to próg niski i to jest dobra wiadomość — ale jest to próg opłacalności, a nie zmierzony wynik, i mylenie tych dwóch rzeczy jest najczęstszym błędem w przedrukach.

Hackathon ocenia efekt po jednym dniu. Urząd podatkowy utrzymuje systemy od maszyn mainframe po Javę, więc jego prawdziwy problem zaczyna się piątego roku, a nie pierwszego dnia. Żadne z opisanych badań nie mierzy tego, co dzieje się z takim kodem przez lata.

Jest za to badanie, które mierzy coś innego i warte jest wzmianki: uczestnicy piszący z asystentem tworzyli kod istotnie mniej bezpieczny, a jednocześnie częściej byli przekonani, że napisali kod bezpieczny. Zastrzeżenie jest poważne — badano model o cztery lata starszy od opisywanego hackathonu, więc nie wolno tego przenosić wprost na dziś. Ale sam mechanizm, czyli rosnąca pewność siebie przy spadającej jakości, jest tym, na co przy takich historiach warto patrzeć.

1. 1

   Sprawdź, czy zadanie było od zera, czy w zastanym kodzie

   To jedno rozróżnienie tłumaczy prawie całą rozbieżność między badaniami. Praca od zera w nieznanej technologii to najlepszy przypadek, praca w znanym sobie dużym projekcie to najgorszy.

2. 2

   Sprawdź, czy ktoś mierzył, czy pytał

   Deklaracje programistów mylą się w obie strony. W jednym badaniu ludzie nie doceniali zysku, w innym czuli przyspieszenie, będąc spowolnieni. Opowieść uczestnika o tym, jak bardzo mu pomogło, jest danymi najsłabszego rodzaju.

3. 3

   Sprawdź, kto badał

   Przy najkorzystniejszym z opisanych wyników autorzy pracowali w firmie, która sprzedaje badane narzędzie. To nie unieważnia wyniku, ale każe go czytać razem z pozostałymi.

4. 4

   Zapytaj o utrzymanie, nie o powstanie

   Pytanie „ile czasu zajęło napisanie" jest łatwe i dlatego wszyscy je zadają. Pytanie „ile kosztowało utrzymanie tego przez rok" jest trudne i dlatego nie ma na nie jeszcze dobrych danych.