Budowanie oprogramowania w erze agentów: architektura to podstawa

Świat tworzenia oprogramowania zmienia się na naszych oczach. Jeszcze rok temu temat „architektury przyjaznej dla agentów AI" nikogo szczególnie nie interesował. Dziś? To wiedza, którą po prostu trzeba mieć.

ZAI coding assistants przeszliśmy od ciekawostki do czegoś, bez czego ciężko sobie wyobrazić pracę. I właśnie w tym momencie dociera do nas pewna fundamentalna prawda: te agenty są tak skuteczne, jak dobrze zorganizowany jest kod, z którym pracują. Wrzuć AI w chaos rozproszonych serwisów, cyklicznych zależności i nazewnictwa rodem z szyfru — a połowa dnia minie na cofaniu się i wyjaśnianiu. Ale daj agentowi (albo programiście) przejrzysty projekt, gdzie kontekst płynie naturalnie? Wtedy zaczyna się prawdziwa magia.

I tutaj pojawia się koncepcja, która powoli, ale wyraźnie zdobywa uznanie w tym środowisku: Polylith. Szczerze mówiąc, to jeden z tych pomysłów, które wydają się oczywiste dopiero wtedy, gdy je zrozumiesz.

Czym właściwie jest Polylith?

W telegraficznym skrócie: Polylith to korzyści z mikroserwisów osiągnięte przy prostocie monorepo. Dostajesz modularność i izolację charakterystyczną dla mikroserwisów, ale wszystko trzymasz w jednym, uporządkowanym repozytorium.

Główna idea jest taka, że twój kod składa się z klocków budowlanych — jak klocki LEGO. Niektóre są małe i wyspecjalizowane, inne tworzą większe agregaty, ale wszystkie zaprojektowano tak, by do siebie pasowały. W terminologii Polylith te klocki nazywają się bricks i dzielą się na dwa typy:

• Components — tutaj dzieje się cała magia aplikacji. Logika biznesowa, funkcje, cała treść systemu mieszka właśnie tutaj.
• Bases — punkty wejścia do aplikacji i serwisów. Najlepiej jak najcieńsze — ograniczają się do delegowania zadań do komponentów.

Ta separacja ma znaczenie, bo wymusza myślenie o granicach od samego początku. Base nie musi znać wewnętrznej budowy komponentu; wystarczy, że wie, jak go wywołać. Czyste, przewidywalne i — co ważne — proste do nawigowania zarówno dla ludzi, jak i dla agentów AI.

Dlaczego agenty zwracają uwagę na architekturę

Tu robi się ciekawie z perspektywy wspomagania przez AI.

Tradycyjne architektury mikroserwisowe, choć potężne, wprowadzają złożoność, która potrafi zatrzymać nawet najinteligentniejsze agenty:

• Kod rozrzucony po wielu repozytoriach
• Duplikowana logika w różnych serwisach
• Współdzielony kod wydzielony do bibliotek (a to oznacza kolejne repozytoria)
• Niezgodności wersji między zależnościami

Agent próbujący zrozumieć lub zmodyfikować taki system musi przeskakiwać między repozytoriami, szukać, gdzie dana funkcjonalność się znajduje, i rozplątywać zależności — a wszystko to zanim napisze choćby jedną użyteczną linię kodu. To obciążenie poznawcze, którego naprawdę nie chcesz.

Polylith rozwiązuje ten problem, trzymając wszystko w jednym miejscu. Kontekst masz zawsze pod ręką. Agenty nie muszą nawigować przez labirynt połączonych repozytoriów — pełny obraz jest dostępny w jednym workspace'u. To nie tylko wygodne dla agentów — to transformuje ich skuteczność.

Kwestia narzędzi

To, co czyni Polylith szczególnie atrakcyjnym, to ekosystem narzędziowy. Dobrze zaprojektowane narzędzia automatycznie egzekwują reguły architektury. Ostrzegają, gdy granice zostają naruszone, wychwytują cykliczne zależności i ogólnie pilnują porządku w kodzie.

Dla developerów Pythona szczególnie istotne jest to, że narzędzia integrują się z ulubionymi menedżerami pakietów — uv, poetry, pdm, pixi, czymkolwiek akurat pracujesz. Jest nawet wbudowana obsługa agent skills, czyli sposób na uczenie asystentów AI, jak pracować w ramach struktury Polylith.

To też prawdziwa wygrana dla efektywności promptów. Kiedy agent AI rozumie konwencje architektury przez narzędzia, mniej tokenów tracisz na tłumaczenie kontekstu, a więcej na generowanie wartości.

Co się nie zmienia

Oto uspokajająca część: wiele zasad dobrej architektury oprogramowania pozostaje niezmiennych niezależnie od tego, czy kod czyta człowiek, czy AI.

Prostota wygrywa ze złożonością. Jasne granice biją pogmatwane zależności. Kontekst ma znaczenie. Te prawdy obowiązywały przed erą agentów i będą obowiązywać po. Różnica polega na tym, że teraz mamy większą motywację, by ich faktycznie przestrzegać — bo korzyści rozciągają się też na nasze asystenty AI.

Szerszy obraz

Wchodzimy w erę, gdzie rozwój oprogramowania odbywa się we współpracy z AI. To zmienia równanie decyzji architektonicznych. Nie chodzi już tylko o doświadczenie programisty — chodzi też o doświadczenie agenta.

Polylith nie jest jedyną odpowiedzią na to wyzwanie, ale to interesująca propozycja, która elegancko adresuje obie strony. Stawiając na prostotę i dostępność kontekstu, tworzy kodbase, po którym przyjemnie się porusza ludziom i który coraz lepiej obsługują agenty.

Jeśli budujesz nowe projekty albo rozważasz restrukturyzację istniejących, warto mieć tę perspektywę na uwadze. Narzędzia, które wybieramy, i decyzje architektoniczne, które podejmujemy — to wszystko ukształtuje, jak skutecznie nasze asystenty AI będą nam pomagać w tworzeniu.

Era agentów nie nadchodzi — ona już nadeszła. Pytanie brzmi: czy nasze architektury są gotowe, by ją przyjąć.

Jakie wzorce architektoniczne sprawdziły się wam najlepiej we współpracy z asystentami AI? Dzielcie się doświadczeniami w komentarzach — zawsze chętnie słucham, jak inni radzą sobie w tej zmieniającej się rzeczywistości.