Problem z szacowaniem czasu w erze programowania wspomaganego AI

Kiedyś mówiłeś menedżerowi projektu: "Ta funkcja zajmie dwa tygodnie" i czułeś pewność. Dziś to brzmi jak prehistoria. Agentyczne kodowanie, gdzie AI nie tylko podpowiada, ale projektuje i wdraża całe rozwiązania, rozwaliło nasze stare metody szacowania na kawałki.

Dawna receptura, która działała w miarę

W czasach, gdy kod pisali tylko ludzie, szacunki miały prosty schemat:

• Znajomość kodu + Złożoność projektu + Szybkość pisania + Czas na testy i poprawki = Przybliżony termin

Znałeś codebase na wylot. Wiedziałeś, że auth działa gładko, ale baza danych to porażka. Szacowałeś godziny na refaktoring, edge case'y i codzienne tempo pracy.

Nie było idealnie – opóźnienia po 20-40% to norma – ale kierunek trafiony. Miałeś modele w głowie, które się sprawdzały.

AI wchodzi do gry: reset szacunków

Wyobraź sobie, że dajesz ten sam task AI. Wszystko się zmienia:

Czy AI ogarnie architekturę od razu? Zależy od dokumentacji, limitu kontekstu i dopasowania modelu do twojego stacku.

Czy od razu wypluje idealne rozwiązanie? Jeśli tak, to godziny. Jeśli trzeba iterować i dopracowywać prompty, liczą się dni.

Ile będziesz musiał przerabiać? Kod z AI często wymaga customizacji, wzmocnienia bezpieczeństwa i dopasowania do reszty systemu.

Prawda jest taka: Za dużo zmiennych poza twoją kontrolą jako developera.

Wyznanie "kodowania na czuja"

Wielu devów nie przyzna się publicznie: kodujemy coraz bardziej na czuja. Co to znaczy?

• Szacujemy po szybkości inferencji AI, nie po złożoności feature'a.
• Liczymy, że model "zaskoczy" za pierwszym razem, bez planu na iteracje.
• Niskie szacunki na integrację z istniejącym kodem.
• Przeceniamy naszą prędkość w łapaniu halucynacji czy dziur bezpieczeństwa.

To nie lenistwo. Po prostu stare narzędzia do szacunków nie pasują do nowej rzeczywistości.

Co naprawdę działa (praktyczne triki)

Masz problem z timeline'ami przy AI? Oto, co pomaga devom:

1. Zmierz baseline AI na start

Przed szacunkami przetestuj małe taski. Zmierz czas inferencji, liczbę iteracji i poprawek. Dostaniesz dane, nie domysły.

2. Rozdziel czas ludzki od maszynowego

Nie szacuj wszystkiego razem. Podziel na:

• Czas AI: Promptowanie, inferencja, pierwszy output.
• Czas review: Audit kodu, check bezpieczeństwa, refaktoring.
• Czas integracji: Podpięcie do systemu, testy, debug.

Takie rozbicie daje przewidywalność – szacujesz to, co kontrolujesz.

3. Przygotuj pakiety kontekstu

AI gubi się bez tła. Poświęć 2-3 godziny na docs architektury, konwencje kodu i przykłady. Output będzie lepszy, iteracje krótsze, całość szybsza.

4. Wpuszcz zakresy niepewność

Nie udawaj precyzji. Zamiast "5 dni" powiedz "3-8 dni, w zależności od modelu". Szczerze i praktycznie.

5. Śledź proces i poprawiaj

Każdy team ma swój flow z AI. Jedni wolą głębokie prompty, inni iteracje. Mierz, co działa u ciebie, i kalibruj szacunki na faktach.

Szerszy obraz

Twój dyskomfort z szacunkami to nie wina. To znak, że podstawa software developmentu się zmienia. Przechodzimy od "ile ludzie napiszą kodu?" do "ile AI zrozumie problem, zaproponuje fix, a ludzie sprawdzą i zintegrują?".

Trudniej to przewidzieć, bo zależy od:

• Jakości modelu i prędkości inferencji.
• Specyfiki problemu i dopasowania do danych treningowych.
• Dokumentacji i struktury twojego codebase'u.
• Umiejętności teamu w sterowaniu AI.

Jasna strona medalu

Ale kiedy AI trafi w punkt za pierwszym strzałem – co zdarza się częściej, niż myślisz – shipujesz w dni, nie tygodnie. Wariancja rośnie, ale średnia wydajność skacze w górę.

Klucz:承认 wariancję, mierz ją na bieżąco i dostosuj modele szacunków.

Co dalej

Devowie, którzy przetrwają, nie trzymają się starych metod. Robią tak:

1. Akceptują bałagan w szacunkach.
2. Mierzą workflow z AI na obsesyjnie.
3. Budują lepsze konteksty i prompty.
4. Dają szersze zakresy, ale uczciwe.
5. Skupiają się na szybkim shipie i lekcjach z iteracji.

To "kodowanie na czuja" może być nową normą. Uczymy się szacować z AI ramię w ramię, nie wbrew niemu.