Martwy punkt wydajności: agenci AI piszą wolny kod

Kod przechodził każdy test. Linter był czysty. System typów nie zgłaszał uwag. Przegląd kodu go zaakceptował. Funkcja była 446 razy wolniejsza, niż musiała być.¹

Codeflash, narzędzie do optymalizacji wydajności kodu, przeanalizował dwa pull requesty wygenerowane w całości przez Claude Code: 76 000 linii obejmujących moduł obsługi języka Java oraz integrację z frameworkiem React.¹ Znaleziono 118 funkcji ze znaczącymi problemami wydajnościowymi. Spowolnienia wahały się od 3x do 446x. Najgorsza z nich: funkcja ekstrakcji typów, która przy każdym wywołaniu ponownie skanowała całe drzewo AST zamiast buforować wynik przejścia. Poprawne zachowanie. Katastrofalna wydajność.

To odkrycie nie jest anomalią. SWE-fficiency, benchmark obejmujący 498 zadań optymalizacyjnych z repozytoriów takich jak NumPy, Pandas i SciPy, wykazał, że najlepsi agenci LLM osiągali mniej niż 0,15x przyspieszenia uzyskiwanego przez eksperta na tych samych zadaniach.² Odrębne badanie testujące Claude 3.5, OpenAI o1 i Llama 3.2 na 26 kodach z dziedziny obliczeń wysokowydajnych wykazało, że Claude 3.5 osiągnął przyspieszenie 1,02x w optymalizacji sekwencyjnej (praktycznie zerowa poprawa), jednocześnie generując niepoprawny kod w 30% przypadków.³ Własna analiza Codeflash obejmująca 100 000 funkcji open-source wykazała, że 90% sugerowanych przez AI optymalizacji jest albo niepoprawnych, albo nie przynosi mierzalnych korzyści, a spośród poprawnych 73% dawało zyski poniżej 5%.⁴

Wydajność to wymiar, którego narzędzia AI do kodowania nie widzą. Każda standardowa bramka jakości (lintery, systemy typów, zestawy testów, przeglądy kodu) weryfikuje poprawność. Żadna nie weryfikuje efektywności. Rezultat: niewidzialny podatek na każdej linii kodu wygenerowanego przez AI, który przechodzi każdą kontrolę i degraduje każdy system, do którego trafia.

TL;DR

Agenci AI piszą poprawny, ale wolny kod. Codeflash znalazł 118 problemów wydajnościowych w 76 000 liniach kodu wygenerowanego przez Claude Code, ze spowolnieniami od 3x do 446x.¹ Benchmarki akademickie potwierdzają ten wzorzec: LLM osiągają mniej niż 0,15x przyspieszenia eksperta w zadaniach optymalizacyjnych.² Przyczyna jest strukturalna: dane treningowe nagradzają poprawność, a standardowe bramki jakości nie mierzą wydajności. Przełamanie tego wymaga infrastruktury wydajnościowej: benchmarków obok testów jednostkowych, wykrywania wzorców opartego na AST w hookach oraz profilowania jako standardowego kroku w procesie pracy.

Kluczowe wnioski

Dla indywidualnych programistów. Warto dodać time lub profiler do kroku weryfikacji po każdej funkcji wygenerowanej przez AI na ścieżce krytycznej. Spowolnienie 446x przeszło każdy test i każdy linter. Jedyną bramką, która by je wyłapała, jest benchmark. Należy traktować „działa” jako warunek konieczny, ale niewystarczający. „Jak szybko działa?” powinno być standardowym pytaniem uzupełniającym.

Dla liderów zespołów. Regresja wydajności to niewidoczna forma Good-Enough Plateau. Kod wygenerowany przez AI, który przechodzi wszystkie testy funkcjonalne, tworzy fałszywe poczucie kompletności. Warto dodać benchmarki wydajnościowe do CI obok testów jednostkowych. Dane Faros AI pokazują, że zespoły wspierane przez AI realizują o 21% więcej zadań, generując jednocześnie o 9% więcej błędów.⁵ Błędy wydajnościowe nie są liczone w tych 9%, ponieważ nikt ich nie mierzy.

Dla inżynierów platformowych. Trzeba zbudować brakującą bramkę. Lintery sprawdzają styl. Systemy typów sprawdzają kontrakty. Zestawy testów sprawdzają zachowanie. Nic nie sprawdza złożoności algorytmicznej ani charakterystyk czasu wykonania w standardowym pipeline CI. Wykrywanie wzorców oparte na AST (reguły Semgrep, wzorce ast-grep lub niestandardowe hooki) może wyłapać najczęstsze antywzorce wydajnościowe: zbędne przejścia, brak memoizacji i niepotrzebne kopie.

Jak wygląda 118 błędów

Analiza dwóch PR-ów Claude Code przeprowadzona przez Codeflash dostarcza najbardziej szczegółowego publicznego zbioru danych o problemach wydajnościowych w kodzie generowanym przez AI.¹ Dwa PR-y liczyły łącznie 76 000 linii: 52 000 dla obsługi języka Java i 24 000 dla obsługi frameworka React. Oba były funkcjonalne. Oba przechodziły swoje zestawy testów. Oba zawierały kod, który degradowałby pod rzeczywistym obciążeniem.

Przyczyny skupiają się w czterech kategoriach:

Nieefektywne algorytmy. Dominująca kategoria. Funkcja konwertująca offsety bajtowe na pozycje linii używała skanowania O(n) zamiast wyszukiwania binarnego O(log n) z wstępnie obliczoną tablicą odniesień. Kod był czytelny. Nazwy zmiennych były opisowe. Logika była poprawna. Klasa złożoności była błędna.

Zbędne obliczenia. Funkcje, które ponownie parsowały, ponownie przechodziły lub ponownie obliczały wartości możliwe do buforowania. Wyszukiwanie funkcji pomocniczych ponownie parsowało ten sam plik źródłowy przy każdym wywołaniu. Dekorator memoizacji zredukowałby 74-krotny narzut do zera po pierwszym wywołaniu.

Brak buforowania i memoizacji. Ściśle powiązane ze zbędnymi obliczeniami, ale odrębne — dane były dostępne w szerszym zakresie. Ekstraktor definicji typów za każdym razem przechodził pełne drzewo AST zamiast budować indeks przy pierwszym dostępie. Wzorzec: agent pisze każdą funkcję w izolacji, nie biorąc pod uwagę, jak będzie wywoływana w pętli.

Nieoptymalne struktury danych. Skanowanie list tam, gdzie zbiory lub słowniki zapewniłyby wyszukiwanie O(1). Sprawdzanie eksportów iterowało po liście, testując przynależność. Konwersja na zbiór wyeliminowałaby 9-krotny narzut w całości.

Dlaczego agenci produkują wolny kod

Martwy punkt wydajności nie jest błędem w żadnym konkretnym modelu. Przyczyna jest strukturalna i działa na trzech poziomach: danych treningowych, kryteriów ewaluacji i założeń dotyczących procesu pracy.

Dane treningowe nagradzają czytelność

LLM uczą się z rozkładu kodu w swoich danych treningowych. Najczęstsza implementacja dowolnego algorytmu to implementacja naiwna. Kod z tutoriali priorytetyzuje jasność. Odpowiedzi na Stack Overflow priorytetyzują poprawność. Kod open-source zawiera wersje zoptymalizowane pod kątem wydajności, ale są one wielokrotnie mniej liczne niż proste implementacje.

Wzorzec wykracza poza wydajność. Stanford wykazał, że programiści wspierani przez AI częściej pisali niebezpieczny kod w czterech z pięciu zadań związanych z bezpieczeństwem, a ci sami programiści częściej byli przekonani, że ich kod jest bezpieczny.⁸ Luka w pewności siebie dotyczy w równym stopniu wydajności: kod wygląda czysto, czyta się dobrze i generuje poprawne wyniki, więc programista mu ufa. Badacze SWE-fficiency stwierdzili, że agenci mają trudności z lokalizowaniem możliwości optymalizacji i rozumowaniem o wykonaniu pomiędzy funkcjami.² LLM wprowadzają małe, specyficzne dla danych wejściowych zmiany zamiast usprawnień algorytmicznych. Gdy poproszony o optymalizację, model sięga po najbliższą poprawną transformację (dodanie cache, zinlinowanie funkcji) zamiast ponownego rozważenia podejścia algorytmicznego. Rezultat: mikrooptymalizacja nałożona na zasadniczo nieefektywne struktury.

Żadna bramka ewaluacyjna nie mierzy wydajności

Standardowe bramki jakości weryfikują to, do czego zostały zaprojektowane:

Każda bramka, którą branża zestandaryzowała, operuje na poprawności. Testy wydajnościowe istnieją (profilery, frameworki benchmarkowe, narzędzia do testów obciążeniowych), ale zajmują osobny proces, którego większość zespołów nie integruje z pipeline CI, a agenci AI nigdy nie wywołują z własnej inicjatywy.

Próżnia weryfikacyjna, która wyjaśnia ścianę 10% produktywności, sięga głębiej niż poprawność funkcjonalna. Próżnia to nie tylko „czy kod działa?”, ale „czy kod jest wydajny?” — a żadna standardowa bramka nie zadaje drugiego pytania.

Agenci piszą funkcje, nie systemy

Najgłębsza przyczyna ma charakter architektoniczny. Agent AI generuje kod jedna funkcja, jeden plik, jedno zadanie naraz. Zakres każdej generacji to bezpośrednie wymaganie. Problemy wydajnościowe pojawiają się na granicach: gdy funkcja napisana do pojedynczego wywołania jest wywoływana w pętli, gdy parser napisany dla małych danych wejściowych otrzymuje duże pliki, gdy wyszukiwanie napisane pod kątem poprawności jest trafiane przy każdym żądaniu.

Tryb awaryjny Tunnel Vision z taksonomii awarii agentów opisuje ten wzorzec na poziomie funkcjonalnym: agent doskonali jeden komponent bez sprawdzania punktów integracji. Martwy punkt wydajności to Tunnel Vision zastosowany do charakterystyk czasu wykonania. Funkcja jest doskonała w izolacji. System degraduje, ponieważ charakterystyki wydajnościowe funkcji nigdy nie zostały ocenione w kontekście.

Niewidzialny podatek

Martwy punkt wydajności byłby drobnym problemem, gdyby kod generowany przez AI stanowił niewielką część systemów produkcyjnych. Obecne liczby czynią go ryzykiem systemowym.

DX mierzy kod autorstwa AI na poziomie 26,9% scalonego kodu produkcyjnego — i odsetek ten rośnie.⁶ Faros AI (dostawca analityki DevOps) stwierdził, że zespoły wspierane przez AI scalają PR-y o 154% większe niż przed erą AI, realizują o 21% więcej zadań i generują o 9% więcej błędów na programistę.⁵ Wartość 9% obejmuje defekty funkcjonalne. Regresje wydajnościowe są nieobecne w tej metryce, ponieważ większość zespołów nie ma bazowej linii wydajnościowej, względem której mogłaby nastąpić regresja.

Matematyka kumulacji ma znaczenie. Randomizowane badanie kontrolowane METR wykazało, że doświadczeni programiści potrzebowali o 19% więcej czasu z narzędziami AI, jednocześnie wierząc, że AI ich przyspiesza o 20%.⁹ Jeśli sami programiści nie potrafią trafnie ocenić wpływu, dług wydajnościowy kumuluje się niewykryty. Przy 26,9% scalonego kodu potencjalnie obciążonego długiem wydajnościowym i braku bramki wydajnościowej w organizacji, dług narasta z każdym sprintem. Raport DORA 2025 stwierdził, że adopcja AI koreluje ze zwiększoną niestabilnością dostarczania, nawet gdy przepustowość wzrosła.⁷ Raport nie przypisuje niestabilności konkretnie wydajności, ale mechanizm pasuje: więcej kodu, scalanego szybciej, z charakterystykami wydajnościowymi, których nikt nie zmierzył.

52% liderów inżynierii ankietowanych przez Codeflash zgłosiło, że zwiększone wykorzystanie AI prowadzi do problemów wydajnościowych w ich bazach kodu.⁴ Liczba jest samodzielnie raportowana i pochodzi od dostawcy (Codeflash sprzedaje narzędzia do optymalizacji wydajności), ale kierunek jest spójny z każdym niezależnym zbiorem danych. Więcej kodu generowanego przez AI, scalanego ze standardowymi bramkami jakości, produkuje systemy, które działają poprawnie i pracują wolno.

Ściana 10% produktywności ma wymiar wydajnościowy, którego oryginalne dane nie ujawniają. Jeśli AI przyspiesza generowanie kodu o 10%, ale wygenerowany kod niesie dług wydajnościowy, który ujawnia się tygodnie lub miesiące później jako incydenty produkcyjne, rzeczywisty zysk produktywności kurczy się jeszcze bardziej. Ściana to nie tylko „AI nie przyspiesza programistów”. Ściana obejmuje „AI spowalnia kod w sposób, którego nikt nie mierzy”.

Jak wygląda wykrywanie

Wykrywanie problemów wydajnościowych w kodzie generowanym przez AI wymaga infrastruktury, której większość organizacji nie posiada. Narzędzia istnieją. Integracja — nie.

Bramki benchmarkowe w CI

Najprostsze rozwiązanie: benchmarkowanie ścieżek krytycznych i odrzucanie builda przy regresjach. Frameworki istnieją dla każdego głównego języka: pytest-benchmark dla Python, JMH dla Javy, criterion dla Rusta, benchmark.js dla JavaScript. Wyzwaniem nie jest narzędzie, lecz praktyka. Benchmarki wymagają bazowych pomiarów, a bazowe pomiary wymagają, by ktoś napisał początkowy benchmark, zanim kod generowany przez AI będzie mógł względem niego regresować.

Minimalna użyteczna implementacja: zidentyfikowanie 10–20 funkcji na ścieżce krytycznej, napisanie dla nich benchmarków i dodanie ich do CI. 118 błędów znalezionych przez Codeflash koncentrowało się w parserach i funkcjach przejścia AST: w rdzeniu obliczeniowym, nie w kodzie łączącym. Problemy wydajnościowe skupiają się w tych samych miejscach za każdym razem.

Wykrywanie wzorców oparte na AST

Analiza statyczna może wyłapać najbardziej rażące wzorce bez uruchamiania kodu. Semgrep i ast-grep obsługują niestandardowe reguły wykrywające:

• Wyrażenia listowe lub pętle wewnątrz innych pętli, gdzie wewnętrzna kolekcja się nie zmienia (kandydat do buforowania)
• Sprawdzenia .index() lub in na listach, które mogłyby być zbiorami
• Operacje I/O na plikach lub wywołania sieciowe wewnątrz pętli bez grupowania
• Powtarzane wywołania funkcji z tymi samymi argumentami (kandydat do memoizacji)

Te reguły nie zastępują profilowania. Wyłapują wzorce odpowiedzialne za większość ze 118 błędów: zbędne obliczenia, brak buforowania, niewłaściwe struktury danych.

Świadomość wydajnościowa oparta na hookach

Dla użytkowników Claude Code hook PreToolUse może wstrzyknąć świadomość wydajnościową do procesu pracy agenta. Podejście jest analogiczne do wzorca bramki dowodowej stosowanego dla poprawności:

check_performance_patterns() {
    local file_path="$1"
    local ext="${file_path##*.}"

    case "$ext" in
        py)
            # Detect nested loops with repeated computation
            if grep -Pn 'for .+ in .+:\n.*for .+ in .+:' "$file_path" 2>/dev/null; then
                echo "WARNING: Nested loops detected in $file_path"
                echo "Verify inner loop does not recompute invariant values."
            fi
            # Detect list membership checks that should be sets
            if grep -n '\bin\b.*\[' "$file_path" 2>/dev/null | grep -v '#'; then
                echo "WARNING: List membership check in $file_path"
                echo "Consider converting to a set for O(1) lookup."
            fi
            ;;
        js|ts)
            # Detect Array.includes or indexOf in loops
            if grep -n '\.includes\|\.indexOf' "$file_path" 2>/dev/null; then
                echo "NOTE: Array search detected in $file_path"
                echo "If called in a loop, consider a Set or Map."
            fi
            ;;
    esac
}

Hook nie jest profilerem. Podnosi świadomość. Cel jest taki sam jak przy każdej innej bramce jakości: uczynić niewidzialne widzialnym, aby programista (lub agent w kolejnej iteracji) mógł się tym zająć, zanim kod trafi na produkcję.

Brakująca infrastruktura

Wzorzec we wszystkich punktach danych jest taki sam jak ten, który wyjaśnia ścianę 10% produktywności i siedem trybów awaryjnych: AI wzmacnia każdą istniejącą infrastrukturę, w tym brak infrastruktury.

Organizacje posiadające benchmarki wydajnościowe w CI wyłapią regresje wydajnościowe w kodzie generowanym przez AI tak samo, jak wyłapują te generowane przez ludzi. Organizacje bez nich będą niewidocznie kumulować dług wydajnościowy. Odkrycie DORA o „wzmacniaczu” ma tu bezpośrednie zastosowanie: AI nie tworzy martwego punktu wydajności. AI go skaluje.⁷

Trzy minimalne inwestycje zamykają tę lukę:

1. Benchmarkowanie ścieżek krytycznych, zanim AI zacznie generować kod wokół nich. Benchmark to linia bazowa. Bez niej żadna regresja nie jest wykrywalna. Należy zidentyfikować 10–20 funkcji odpowiadających za większość czasu obliczeń i napisać dla nich benchmarki w pierwszej kolejności.

2. Dodanie lintingu wydajnościowego opartego na AST do pipeline CI. Reguły Semgrep lub ast-grep flagujące cztery dominujące antywzorce (zbędne obliczenia, brak buforowania, niewłaściwe struktury danych, niepotrzebna złożoność). Reguły są lekkie i kompozycyjne z istniejącymi krokami lintingu.

3. Wstrzyknięcie świadomości wydajnościowej do procesów pracy agentów. Dla Claude Code: hook flagujący wzorce istotne wydajnościowo w modyfikowanych plikach. Dla innych narzędzi: prompt zawierający „zweryfikuj złożoność algorytmiczną” jako standardową instrukcję. Celem nie jest automatyczna optymalizacja, lecz świadomość: ujawnienie pytania „czy to jest wystarczająco szybkie?” w procesie pracy, który obecnie go nie zadaje.

Martwym punktem nie jest AI. Martwym punktem jest brak infrastruktury wydajnościowej. Każda standardowa bramka jakości, którą branża zbudowała, weryfikuje poprawność. Żadna nie weryfikuje efektywności. Luka istniała przed AI. AI uczyniło ją problemem dotyczącym 26,9% kodu produkcyjnego.

Źródła