Programowanie z AI: agenci kodowania w praktyce

Programowanie z AI i agenci kodowania zmieniają dziś nie tylko sposób pisania kodu, ale cały proces tworzenia oprogramowania — od analizy i architektury po testy, wdrożenie i kolejne iteracje.

W praktyce sprawdziłem ten model przy realizacji trzech różnych produktów: AI‑TOP.PL, Podstawy‑AI.pl oraz AI‑Katalog.pl. Od pomysłu biznesowego do działających wdrożeń potrzebowałem od około dwóch tygodni do około miesiąca.

Najprościej byłoby napisać, że powstały trzy strony internetowe. Byłby to jednak opis wygodny i całkowicie nietrafiony.

Strona jest w tych projektach tylko warstwą prezentacji. Pod nią znajdują się trzy różne produkty cyfrowe: system pracujący na dynamicznych danych o modelach AI, uporządkowana architektura wiedzy dla osób początkujących oraz katalog organizacji oparty na źródłach i wieloetapowej weryfikacji.

Realizatorem wszystkich trzech projektów byłem ja — od pomysłu biznesowego i analizy, przez architekturę oraz podział prac, po kontrolę jakości i wdrożenie. Agenci kodujący zwiększali możliwości wykonawcze procesu, ale nie przejmowali odpowiedzialności za jego cel, logikę ani końcowy rezultat.

AI dało tempo. Proces dał stabilność.

Programowanie z AI w praktyce: trzy różne produkty

Projekty nie powstały jako trzy przypadkowe inicjatywy. Tworzą spójną ścieżkę użytkownika:

AI‑TOP.PL: od pomysłu biznesowego do produktu danych

Punktem wyjścia dla AI‑TOP.PL nie był pomysł na kolejną listę popularnych modeli. Takich list jest w Internecie wiele.

Problem biznesowy polegał na czymś innym: informacje o modelach, dostawcach, wariantach i ofertach API są rozproszone, szybko się zmieniają i często nie są bezpośrednio porównywalne.

Samo stwierdzenie, że określony model jest „dobry”, niewiele wyjaśnia. Trzeba jeszcze ustalić, do jakiego zadania, w jakim wariancie, u którego dostawcy, w jakiej cenie, według jakiej metody i na podstawie jak aktualnych danych.

W ciągu około miesiąca powstał system obejmujący między innymi:

• katalog modeli AI i ich dostawców;
• oferty API oraz ceny wejścia i wyjścia za milion tokenów;
• przeliczanie stawek na PLN według zapisanego kursu NBP;
• ranking ogólny i wyspecjalizowane widoki porównawcze;
• porównywarkę modeli;
• oddzielenie wyniku AI‑TOP od opinii użytkowników;
• datowane snapshoty i historię pozycji;
• mechanizm oceny oparty na jawnych składnikach;
• kontrolę źródła, aktualności i kompletności danych.

Projekt wykorzystuje dane między innymi z OpenRouter i Hugging Face. Bieżąca metodologia AI‑TOP łączy jakość modelu, konkurencyjność kosztową, aktualność danych i popularność. Brakujący składnik nie jest zastępowany domysłem ani nie zwiększa automatycznie wagi pozostałych danych.

Według publicznego kokpitu z 17 sierpnia 2026 roku serwis obejmował 506 aktywnych rekordów modeli, 92 dostawców i 195 ważnych ofert API. Liczby te nie zostały wpisane ręcznie do tekstu marketingowego. Są wynikiem działania modelu danych, integracji oraz procesu synchronizacji.

Najtrudniejszym elementem nie było narysowanie tabeli. Było nim zbudowanie systemu, który wie:

• skąd pochodzi określona wartość;
• czego dokładnie dotyczy;
• kiedy została pobrana;
• czy można ją porównać z inną;
• jak zachować jej historię;
• oraz kiedy brak danych powinien pozostać po prostu brakiem danych.

Ranking z nieznaną metodą jest w praktyce opinią ubraną w tabelę i krawat. Dlatego w AI‑TOP jawność metodologii nie jest dodatkiem redakcyjnym, lecz częścią architektury produktu.

Podstawy‑AI.pl: dwa tygodnie na zaprojektowanie schodów wiedzy

Podstawy‑AI.pl były zupełnie innym projektem.

Serwis edukacyjny może wydawać się technicznie prostszy od katalogu modeli. Merytorycznie zadanie było jednak równie złożone, ponieważ największym problemem nie był brak informacji o AI, lecz ich nadmiar.

Osoba początkująca spotyka dziś jednocześnie pojęcia modeli językowych, tokenów, promptów, pamięci, kontekstu, RAG, agentów, API, modeli lokalnych, bezpieczeństwa danych i AI Act. Można opisać je wszystkie w jednym miejscu, ale czytelnik nadal nie będzie wiedział, co powinien zrobić jako pierwsze.

Celem projektu nie było więc opublikowanie dużej liczby artykułów. Celem było stworzenie architektury uczenia się.

Złożona merytoryka została podzielona na krótkie materiały ułożone według kolejnych etapów:

1. podstawowe pojęcia: AI, model, czat i Asystent AI;
2. bezpieczeństwo i ochrona danych;
3. ryzyka, błędy i halucynacje;
4. wybór czatu według zadania;
5. pierwsza bezpieczna praca z AI;
6. pliki, dokumenty i multimedia;
7. zastosowania w domu, nauce, analizie, pisaniu i programowaniu;
8. pamięć, projekty, własna wiedza i modele lokalne;
9. integracje, API, agenci i poziomy autonomii;
10. prawo oraz skutki społeczne.

Każdy materiał odpowiada na jedno główne pytanie i prowadzi do kolejnego sensownego kroku. Serwis nie jest klasycznym blogiem uporządkowanym według dat publikacji, lecz mapą edukacyjną.

Pierwsza praktyczna ścieżka trwa około 15 minut. Użytkownik wybiera neutralne dane, określa cel, wykonuje zadanie i sprawdza odpowiedź. Dopiero później przechodzi do bardziej złożonych funkcji.

W projekcie przyjąłem trzy stałe zasady:

Uproszczenie wiedzy nie może oznaczać jej zniekształcenia. Można skrócić zdanie, ale nie należy usuwać z niego warunku, który decyduje o poprawności całej informacji.

Dlatego materiały posiadają poziomy, wymagania początkowe, ćwiczenia, następne kroki, źródła oraz daty weryfikacji. Techniczna warstwa serwisu wspiera wyszukiwanie, porównanie usług, słownik pojęć i zapisywanie postępu w przeglądarce.

AI‑Katalog.pl: dwa tygodnie na proces, w którym API nie wydaje wyroku

Trzeci projekt powstał w odpowiedzi na jeszcze inny problem.

W dobie treści masowo generowanych przez AI samo znalezienie profesjonalnie brzmiącego opisu organizacji ma coraz mniejszą wartość. Wygenerowanie listy kompetencji, produktów, partnerów, a nawet pozornego case study zajmuje dziś kilka sekund.

Znacznie trudniej ustalić:

• czy organizacja rzeczywiście istnieje;
• czy ma konkretny związek z polskim rynkiem;
• czy publicznie opisuje ofertę związaną z AI;
• czy informacja dotyczy produktu, usługi, partnerstwa czy wdrożenia;
• czy klient lub partner potwierdza opisaną relację;
• oraz które źródło wspiera konkretne twierdzenie.

AI‑Katalog.pl nie został więc zaprojektowany jako kolejny katalog SEO, w którym firma samodzielnie wpisuje kilka zdań o sobie. Powstał jako katalog źródłowy z ujednoliconą strukturą profili i kontrolowanym procesem publikacji.

W ciągu około dwóch tygodni wdrożyłem:

• model organizacji, ról, segmentów rynku, technologii i zastosowań;
• strukturę twierdzeń powiązanych z konkretnymi źródłami;
• integrację z Exa Search API do wyszukiwania potencjalnych materiałów;
• integrację z Exa Contents API do pobierania wybranych fragmentów;
• lokalny, walidowany pakiet źródeł i rekordów;
• pracę w małych paczkach kandydatów;
• kontrolę spójności taksonomii;
• oddzielenie deklarowanej oferty od konkretnego zastosowania;
• dwa poziomy weryfikacji profilu;
• trzy statusy twierdzeń;
• obowiązkową decyzję człowieka przed publikacją.

Proces przebiega etapami:

Wyszukiwarka i API pomagają dotrzeć do materiału. Nie są jednak dowodem i nie publikują rekordu samodzielnie. Dowodem pozostaje treść wskazanego źródła.

To rozróżnienie było jednym z najważniejszych wymagań całego projektu. Automatyzacja ma przyspieszać research i porządkowanie informacji. Nie może zastępować decyzji o tym, czy dane twierdzenie zostało rzeczywiście potwierdzone.

Najtrudniejszą funkcją systemu nie jest wygenerowanie opisu. Jest nią umiejętność pozostawienia pola pustego.

Brak informacji pozostaje brakiem informacji. Nie jest zaproszeniem do jej wygenerowania.

Według stanu z 17 sierpnia 2026 roku katalog obejmował 92 opublikowane profile: 30 z pełną oraz 62 z podstawową weryfikacją.

Pełna weryfikacja oznacza, że publiczne źródła pozwalają opisać organizację, ofertę AI i co najmniej jedno konkretne zastosowanie. Weryfikacja podstawowa oznacza potwierdzenie organizacji, jej związku z polskim rynkiem oraz oferty AI, ale bez materiału wystarczającego do opisania wdrożenia.

Poziom weryfikacji opisuje zakres dostępnego materiału, a nie jakość firmy. Katalog nie przyznaje certyfikatów i nie tworzy rankingu „najlepszych organizacji AI”.

Agenci AI w programowaniu: co naprawdę przyspieszyło realizację?

Najłatwiej byłoby odpowiedzieć: sztuczna inteligencja.

Byłoby to efektowne, ale mało precyzyjne.

Same modele nie organizują procesu wytwórczego. Potrafią generować kod, lecz nie wiedzą automatycznie:

• po co powstaje produkt;
• kto jest jego użytkownikiem;
• które pojęcia są odrębnymi obiektami;
• jakie dane są kanoniczne;
• gdzie kończy się automatyzacja;
• jakie błędy są krytyczne;
• co oznacza gotowość do wdrożenia.

Tempo było wynikiem połączenia agentów z procesem, którego wcześniejszym laboratorium był Project Venom.

1. Najpierw powstawał model biznesowy i pojęciowy

Każdy projekt rozpoczynałem od celu, odbiorcy, głównych obiektów i relacji pomiędzy nimi. Dopiero później powstawał interfejs.

Dzięki temu agent kodujący nie otrzymywał polecenia „zrób katalog” albo „zbuduj portal o AI”. Otrzymywał ograniczony pakiet pracy dotyczący modelu danych, importu, widoku, walidacji, testu albo określonej ścieżki użytkownika.

2. Duży zakres był dzielony na małe, sprawdzalne zmiany

Praca była realizowana iteracyjnie, w niewielkich zadaniach i pull requestach. Każdy pakiet miał cel, zakres, ograniczenia, kryteria akceptacji oraz sposób sprawdzenia wyniku.

Małą zmianę łatwiej wykonać, przejrzeć, zaakceptować lub wycofać. Jest to również podstawa sensownej orkiestracji agentów — bez dekompozycji orkiestracja pozostaje jedynie uruchamianiem kolejnego silnego modelu.

Ten problem opisałem szerzej w materiale „15 Billion Tokens Later: One Agent Was Not Enough”.

3. Agenci byli wykonawcami, a nie właścicielami decyzji

Agenci kodujący wspierali między innymi:

• implementację funkcji;
• migracje i porządkowanie danych;
• refaktoryzację;
• budowę testów;
• analizę skutków zmian;
• naprawę błędów;
• przygotowanie dokumentacji;
• dostosowanie interfejsu.

Nie przekazywałem im jednak odpowiedzialności za sens produktu. Agent mógł zaproponować rozwiązanie techniczne, ale nie ustalał samodzielnie metodologii rankingu, znaczenia pełnej weryfikacji ani kolejności edukacyjnej w Podstawach AI.

4. Kontrola jakości była elementem wykonania

Kod wygenerowany przez agenta nie był traktowany jako wynik końcowy. Musiał przejść przez kompilację, testy, kontrolę spójności, przegląd zmian i sprawdzenie na działającym środowisku.

W projektach danych dochodziła do tego kontrola źródeł, jednostek, dat i relacji. W projekcie edukacyjnym — kontrola języka, kolejności pojęć i tego, czy uproszczenie nie zmieniło znaczenia.

Agent mógł wykonać pracę szybko, ale nie mógł sam ogłosić własnego sukcesu. To uprawnienie pozostało po stronie operatora. 🙂

5. Wdrożenie było kolejnym punktem pomiarowym

Działająca wersja ujawnia problemy, których często nie widać w dokumentacji: zbyt długą ścieżkę użytkownika, nieczytelną prezentację danych, błędne założenie rankingu, brakujący status rekordu albo materiał edukacyjny wymagający wcześniejszej definicji.

Wdrożenie nie kończyło więc analizy. Dostarczało informacji zwrotnej do kolejnej iteracji.

Automatyzacja tworzenia oprogramowania nie oznacza automatyzacji decyzji

W klasycznym modelu trzy takie projekty wymagałyby udziału kilku funkcji: analizy, architektury, developmentu, danych, redakcji, testów i administracji.

W moim modelu funkcje te zostały skupione wokół jednego operatora oraz zestawu agentów kodujących.

W praktyce pełniłem role:

• autora koncepcji biznesowej;
• analityka biznesowego i systemowego;
• architekta rozwiązania;
• właściciela produktu;
• operatora agentów;
• recenzenta wyników;
• osoby odpowiedzialnej za wdrożenie.

Można powiedzieć, że powstała mała fabryka oprogramowania.

Fabryka nie działa jednak dlatego, że maszyny są szybkie. Działa dlatego, że ktoś zaprojektował linię produkcyjną, kolejność operacji, punkty kontroli oraz procedurę zatrzymania procesu przy błędzie.

Agenci zwiększyli przepustowość procesu. Nie zastąpili odpowiedzialności.

Proces tworzenia oprogramowania z AI: od Project Venom do produktów rynkowych

Project Venom był wcześniejszym środowiskiem badawczym, w którym sprawdzałem wpływ agentów kodujących na tempo pracy, jakość kodu i organizację procesu.

W analizowanym cyklu projekt osiągnął między innymi 1 587 commitów, medianę obsługi pull requestu na poziomie 0,9 godziny oraz 95% merge rate. Jednocześnie liczba zgłoszeń SonarQube spadła z 1 650 do zera, dług techniczny z 19 dni do zera, a pokrycie testami wzrosło do 92,2%.

Wniosek z tego badania nie brzmiał: „AI pisze kod szybciej”.

Wniosek był bardziej praktyczny:

AI‑TOP.PL, Podstawy‑AI.pl i AI‑Katalog.pl były kolejnym etapem: zastosowaniem tego procesu nie w jednym eksperymentalnym repozytorium, lecz przy realizacji trzech odrębnych produktów.

Implementacja Asystenta AI przestała być w tym momencie wyłącznie koncepcją. Stała się praktyką organizowania analizy, architektury, wykonania i kontroli wokół jednego operatora.

Dlaczego programowanie z AI przyspiesza dopiero przy dojrzałym procesie?

Czas realizacji może sugerować, że wszystkie trzy produkty powstały od zera w kilka tygodni.

Technicznie — tak.

Koncepcyjnie — nie.

Za tym tempem stały lata doświadczeń w analizie biznesowej i systemowej, projektowaniu aplikacji, integracjach, modelowaniu procesów, pracy z danymi oraz wcześniejszych eksperymentach z agentami kodującymi.

Dojrzały proces działa podobnie do biblioteki sprawdzonych komponentów. Nie trzeba za każdym razem od początku odkrywać:

• jak definiować cel i wymagania;
• jak dzielić zakres;
• jak opisywać zmianę;
• jak oceniać ryzyko;
• jak organizować testy i review;
• jak wdrażać;
• jak reagować na błąd.

AI przyspiesza wykonanie decyzji. Nie zastępuje braku decyzji.

Im dojrzalszy proces, tym więcej pracy można bezpiecznie przekazać agentom. Im słabszy proces, tym szybciej można wyprodukować dużą liczbę zmian, których nikt nie potrafi już ocenić.

Granice tego doświadczenia

Trzy szybkie wdrożenia nie oznaczają, że każdy produkt cyfrowy można zbudować w dwa tygodnie.

• Były to projekty prowadzone przez jednego operatora, który jednocześnie definiował cele i podejmował decyzje.
• Nie występował klasyczny koszt uzgadniania zakresu pomiędzy wieloma działami i interesariuszami.
• Intensywność pracy była wysoka, a wąskim gardłem pozostawała zdolność człowieka do oceny kolejnych rezultatów.
• Uruchomienie produktu nie kończy jego rozwoju — dane, źródła, treści i integracje wymagają dalszego utrzymania.
• Tempo wykonania nie zwalnia z kontroli bezpieczeństwa, zgodności, architektury ani jakości.

Nie jest to więc uniwersalny wzór kosztorysowania dowolnego projektu. Jest to praktyczny dowód, że dobrze przygotowany proces z udziałem agentów może radykalnie skrócić drogę od pomysłu do działającego produktu.

Trzy produkty jako trzy testy tego samego procesu

Każdy projekt sprawdził ten sam model pracy w innej domenie:

• AI‑TOP.PL zweryfikował pracę z dynamicznymi danymi, integracjami API, normalizacją, historią i interpretowalnym rankingiem.
• Podstawy‑AI.pl sprawdziły projektowanie architektury wiedzy, ścieżek edukacyjnych i prostego języka bez spłycania merytoryki.
• AI‑Katalog.pl zweryfikował wieloetapowe pozyskiwanie, porównywanie i publikowanie informacji z zachowaniem kontroli człowieka.

Wspólna metoda wyglądała następująco:

Agenci kodujący przyspieszyli część wykonawczą tego cyklu.

Największą wartością pozostała jednak zdolność przeprowadzenia całego procesu: od pytania biznesowego, przez strukturę rozwiązania, aż do działającego systemu.

Agenci kodowania zmieniają rolę człowieka: z wykonawcy w operatora procesu

W klasycznym modelu ograniczeniem bywa tempo ręcznego wykonania. W procesie wykorzystującym agentów coraz większym ograniczeniem staje się zdolność operatora do:

• utrzymywania spójnej wizji;
• analizowania zależności;
• podejmowania decyzji architektonicznych;
• opisywania wymagań;
• oceniania jakości;
• akceptowania lub odrzucania kolejnych zmian.

Wąskie gardło przesunęło się więc z klawiatury do procesu decyzyjnego.

To właśnie w tym widzę największy potencjał agentów kodujących.

Nie w zastępowaniu człowieka.

W skracaniu drogi pomiędzy dobrze zdefiniowanym pomysłem a działającym produktem.

Najczęstsze pytania o programowanie z AI i agentów kodowania

Czym różni się agent kodowania od zwykłego asystenta AI?

Zwykły asystent najczęściej podpowiada fragment kodu lub odpowiada na pytanie. Agent kodowania może pracować na repozytorium, analizować pliki, planować zmianę, modyfikować kod, uruchamiać testy i iterować na podstawie wyniku. Nadal wymaga jednak dobrze określonego zadania oraz kontroli jakości.

Czy agenci AI mogą automatyzować cały proces tworzenia oprogramowania?

Mogą automatyzować znaczną część pracy wykonawczej, ale nie zwalnia to z analizy celu, projektowania architektury, określenia kryteriów jakości i decyzji o wdrożeniu. Im większa autonomia agentów, tym ważniejsze stają się bramki jakości, testy i obserwowalność procesu.

Co najbardziej przyspiesza development z AI?

Nie pojedynczy model, lecz połączenie kilku elementów: precyzyjnych wymagań, małych pakietów pracy, sprawdzalnych kryteriów akceptacji, agentów kodowania, automatycznych testów oraz szybkiej pętli informacji zwrotnej.

Czy programista staje się zbędny?

Zmienia się przede wszystkim rozkład pracy. Mniej czasu może zajmować ręczne tworzenie kolejnych fragmentów kodu, a więcej analiza zależności, architektura, ocena rezultatów i zarządzanie pracą agentów. Odpowiedzialność za produkt nie znika wraz z automatyzacją wykonania.

---

Zrealizowane projekty

• AI‑TOP.PL — ranking, porównywarka i katalog modeli, dostawców oraz cen API.
• Podstawy‑AI.pl — uporządkowana ścieżka bezpiecznego i praktycznego korzystania z AI.
• AI‑Katalog.pl — katalog organizacji związanych z polskim rynkiem AI, oparty na publicznych źródłach i wieloetapowej weryfikacji.

Powiązane materiały na pieniak.it

• Implementacja Asystenta AI
• Automatyzacja procesu wytwórczego oprogramowania — studium przypadku Project Venom
• 15 Billion Tokens Later: One Agent Was Not Enough
• Architektura Asystenta AI

Dane liczbowe dotyczące AI‑TOP.PL i AI‑Katalog.pl przedstawiają stan publicznych serwisów z 17 sierpnia 2026 roku. Projekty są rozwijane, dlatego bieżące wartości mogą być wyższe.