# Od IDP do ADP: platforma w erze agentów > Gdy część pracy w pętli przejmuje agent, platforma musi się zmienić — z IDP w ADP. Dlaczego przewaga nie leży w lepszym modelu, lecz w systemie produkcyjnym, który go ujarzmia. URL: https://eiac.dev/blog/od-idp-do-adp Filar: SDLC / Policy-as-Code Data: 2026-03-11 Tagi: platform-engineering, adp, idp, agents, ai --- We [wprowadzeniu do serii](/blog/platform-engineering-normalizacja-pracy) postawiłem tezę, że platform engineering to skracanie organizacyjnej [pętli OODA](https://pl.wikipedia.org/wiki/OODA) — uspójnianie i przyspieszanie drogi od obserwacji do działania. Zobaczmy teraz, co się z tą pętlą dzieje, gdy do gry wchodzą agenci AI: większość pracy przestaje wykonywać człowiek przy klawiaturze, a zaczyna ją wykonywać platforma. To wymusza zmianę samej platformy — z **IDP** (Internal Developer Platform) w **ADP** (Agentic Development Platform).
Teza

To nie wyścig o najlepszy model. Modele to towar o zbieżnych możliwościach. Różnicą jest system produkcyjny, który ujarzmia inteligencję i utrzymuje ją w ryzach — czyli deterministyczny szkielet platformy.

## Dlaczego model to nie wąskie gardło Wydajność modeli na zadaniach inżynierskich (mierzona np. na [SWE-bench](https://www.swebench.com/)) przeszła w ostatnich latach od bliskiej zeru do poziomów porównywalnych z człowiekiem, i wciąż rośnie. Dostęp do mocnego modelu jest dziś kwestią klucza API, nie przewagi. Skoro tak, to przewaga nie może leżeć w „lepszym modelu" — bo ten ma każdy. Z analiz nieudanych wdrożeń AI wyłania się powtarzalny wzorzec: w większości przypadków zawiodły **nie modele, lecz platforma** — brak guardrails, brak deterministycznych bramek, brak miejsca, w którym agent mógłby działać szybko i bezpiecznie. Organizacja, która „dokłada AI" na wierzch starego procesu, dostaje wszystkie wady probabilistyki (halucynacje, niespójność) przy znikomych korzyściach — i wnioskuje, że „to nie dla niej". To samospełniająca się pułapka. Prawdziwy wyścig toczy się więc o coś innego: jak bardzo zrównoleglić i zautomatyzować pracę, nie tracąc kontroli. A to zależy od jakości platformy. ## Probabilistyczne spotyka deterministyczne Architektura zdolna do bezpiecznej pracy z agentami musi połączyć dwa światy o przeciwnej naturze. **Systemy probabilistyczne** — rozumują, generalizują i poprawiają się z kontekstem, ale są nieprzewidywalne: - modele fundamentalne i agenci kodujący, - frameworki koordynacji wielu agentów, - warstwy oceny i ewaluacji zachowań (model-evaluating, behavioral evaluation). **Systemy deterministyczne** — przewidywalne, powtarzalne, audytowalne: - orkiestracja platformy (bezpieczne tworzenie i zmiana zasobów), - jawne granice zdolności i stabilne API, - reprodukowalne pipeline'y CI/CD i **środowiska efemeryczne** do izolacji i weryfikacji, - egzekwowanie polityk, tożsamość i RBAC, - zarządzanie stanem, warstwy semantyczne nad danymi, weryfikacja zależności i licencji, - obserwowalność i ślad audytowy. IDP standaryzuje ścieżki dla ludzi. **ADP czyni te ścieżki wykonywalnymi przez agentów na dużą skalę — a docelowo pozwala agentom uruchamiać je samodzielnie.** To nie jest nowy zestaw narzędzi, lecz nowy kontrakt: deterministyczna część platformy staje się systemem bezpieczeństwa dla części probabilistycznej. ## Złote ścieżki dla ludzi to złote ścieżki dla agentów Najważniejsza praktyczna obserwacja: ścieżki, które dziś budujesz dla developerów, to dokładnie te same ścieżki, które jutro będą wykonywać agenci. Model „paths-to-outcomes" z wprowadzenia (zdobądź kontekst → zmień → zweryfikuj → wypuść → obserwuj → napraw) nie znika — zmienia się tylko to, **kto** i **jak często** go przemierza. Dlatego budowa solidnego IDP nie jest „warunkiem wstępnym" myślenia o agentach — to ta sama praca, widziana przez inną soczewkę. Jeśli ścieżka jest deklaratywna, idempotentna i weryfikowalna automatycznie, agent może po niej iść. Jeśli wymaga ręcznego klikania i wiedzy plemiennej, nie pójdzie po niej ani agent, ani nowy człowiek. Przykład: ta sama bramka polityki (tu w Rego dla [Open Policy Agent](/katalog/open-policy-agent)) chroni zarówno zmianę od człowieka, jak i od agenta — bo działa na artefakcie, nie na intencji autora: ```rego package eiac.deploy # żaden obraz z tagiem :latest nie wejdzie na produkcję deny contains msg if { input.kind == "Deployment" some c in input.spec.template.spec.containers endswith(c.image, ":latest") msg := sprintf("obraz %q ma tag :latest", [c.image]) } ``` Bramka nie pyta „czy to napisał człowiek?". Pyta „czy artefakt spełnia regułę?". To właśnie czyni ją bezpieczną przy wolumenie zmian generowanych maszynowo. ## Co naprawdę się zmienia: pętla, nie narzędzia Struktura platformy pozostaje, ale obciąża się inaczej. Trzy przesunięcia są kluczowe: - **Walidacja z bramki staje się pętlą.** Gdy agent generuje zmiany seriami, weryfikacja nie może być pojedynczym przystankiem — staje się przemysłowym sprzężeniem zwrotnym, w którym agent powtarza próby aż przejdzie. Rozwijamy to w artykule [Deterministyczny szkielet platformy agentowej](/blog/deterministyczny-szkielet-adp). - **Ograniczenie przesuwa się z „szybkości pisania" na „jakość weryfikacji".** Wąskim gardłem nie jest już, jak szybko ktoś pisze kod, lecz jak szybko i wiarygodnie platforma potrafi go sprawdzić. - **Rola człowieka wędruje w górę** — od pisania, przez przegląd, po definiowanie reguł i granic. Te poziomy zaangażowania to temat artykułu [Cztery poziomy agentowego wytwarzania](/blog/cztery-poziomy-agentowego-wytwarzania). ## Dlaczego to dotyczy też zgodności Im więcej pętli domyka maszyna, tym ważniejsze stają się dwie rzeczy, które w świecie czysto ludzkim były „miłe, ale opcjonalne": **nadzór** i **ślad audytowy**. To nie przypadek, że dokładnie tego wymagają regulacje — [DORA](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) (odporność operacyjna, udowadnialne procesy) i [AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) (nadzór człowieka, logowanie, transparentność). Deterministyczny szkielet ADP — polityki jako kod, audyt, RBAC, środowiska efemeryczne — jest tym samym, co spełnia te wymogi. Wrócimy do tego w częściach poświęconych [DORA](/blog/dora-w-praktyce-platformy) i AI Act. ## Podsumowanie Przejście z IDP do ADP nie polega na „dodaniu AI". Polega na wzmocnieniu deterministycznej części platformy tak, by mogła bezpiecznie napędzać część probabilistyczną. Modele są towarem; przewagą jest system produkcyjny, który zamienia ich nieprzewidywalną moc w przewidywalny wynik. W kolejnej części rozkładam ten przeskok na cztery konkretne poziomy dojrzałości — od człowieka piszącego kod po platformę, która sama domyka pętlę. Zapraszam do maszynowni, tam robi się konkretnie.