Manifest
Everything Is A Code
Cześć. Jestem praktykiem — admin, potem developer, teraz devops — i przez lata nauczyłem się jednego: prawie wszystko, czym zarządzamy, najlepiej żyje jako kod. Infrastruktura, aplikacje, design, cały cykl wytwarzania. Wersjonowane, testowalne, powtarzalne. To nie fanaberia estetyczna, tylko sposób, żeby praca przestała wisieć na tym, co ktoś akurat pamięta — a zaczęła od repozytorium. Tak powstało eiac.dev.
Kiedy decyzja staje się danymi — kawałkiem kodu w repo — przestaje być dokumentem, który ktoś musi pamiętać i ręcznie egzekwować. Zaczyna być faktem: wersjonowanym, walidowanym w CI, odtwarzalnym. I właśnie ta drobna zmiana nośnika otwiera drzwi do automatyzacji — a dziś także do bezpiecznego wpuszczenia agentów AI w pętlę wytwarzania. O tym jest cała ta strona.
Pięć filarów
Tę samą zasadę biorę na pięć obszarów. Każdy to inny wycinek tej samej idei „as-code", a razem układają się w spójny sposób budowania i utrzymywania softu — bez świętowania jednego, konkretnego narzędzia.
- Infrastructure-as-Code
- Infrastruktura jako deklaratywny, wersjonowany kod — odtwarzalna i audytowalna, gotowa do odtworzenia od zera.
- App-as-Code
- Aplikacje i ich zależności opisane w kodzie: od buildu, przez konfigurację, po powtarzalne wdrożenie.
- Design-as-Code
- Decyzje wizualne jako tokeny — jedno źródło prawdy dla UI, które zasila kod i markę.
- SDLC / Policy-as-Code
- Reguły, jakość i zgodność jako testowalne bramki w pipeline — egzekwowane, nie opisane w wiki.
- Security-as-Code
- Tożsamość, sekrety i polityki deklaratywnie i lokalnie — bezpieczeństwo wbudowane w ścieżkę, nie doklejone na końcu.
Co znajdziesz na eiac.dev
eiac.dev to dwie rzeczy naraz: pismo i katalog. W piśmie piszę pogłębione analizy — nie newsy, tylko tezy: skąd wziął się problem, jakie ma rozwiązania i jaką cenę płacisz za każde z nich (bo darmowego lunchu nie ma). W katalogu zbieram otwarte narzędzia, które realnie robią robotę „as-code", poukładane w pięć filarów. A graf pokazuje, jak teksty i narzędzia łączą się w sieć — trochę jak w Obsidianie.
Zasady
- Teza ponad narzędzie. Opisuję podejścia i problemy, a nie sprzedaję konkretnego produktu. Narzędzie jest ilustracją zasady, nie odwrotnie.
- Otwartość i suwerenność. Wolę otwarte, fundacyjne narzędzia, które nie trzymają Cię za gardło u jednego dostawcy ani pod obcą jurysdykcją.
- Wszystko jako kod. Wersjonowane, testowalne, powtarzalne — od infrastruktury po design i polityki.
- Człowiek w pętli. Automatyzuję to, co deterministyczne; osąd — architektura, doświadczenie, decyzje wrażliwe — zostaje przy człowieku. Zawsze.
- Źródła pod ręką. Każde odwołanie do standardu czy regulacji linkuję do oficjalnego źródła, żebyś mógł sięgnąć dalej jednym kliknięciem.
Dokąd zmierzamy
Wytwarzanie softu wchodzi w fazę, w której część pracy w pętli robi już nie człowiek przy klawiaturze, lecz agent AI. To zmienia samą platformę — z wewnętrznej platformy deweloperskiej (IDP) w platformę agentową (ADP), gdzie na pierwszy plan wychodzą deterministyczne guardrails, ślad audytowy i policy-as-code. Rozkładam tę ewolucję — wraz z jej wymiarem suwerenności i regulacji UE — na czynniki pierwsze w serii o platform engineeringu.
Dla agentów i maszyn
Treść eiac.dev celowo przygotowałem tak, żeby mogła być wsadem dla agentów AI — bo skoro
sam o nich piszę, to głupio byłoby im tej treści nie podać. :) Udostępniam ją w formatach
maszynowo-czytelnych: llms.txt (kuratorowany
indeks wg konwencji llmstxt.org), llms-full.txt (pełna treść
artykułów i katalogu w jednym pliku), surowy markdown każdego artykułu pod
/blog/<slug>.md, kanał RSS oraz dane strukturalne
schema.org (JSON-LD) osadzone w stronach.
Nic wyrytego w kamieniu
I jeszcze jedno, ważne: struktura tej strony może się zmieniać. Filary, sekcje, formaty, układ katalogu — to żywy organizm, nie tablica wykuta w granicie. Jak coś przestanie mi pasować albo znajdę lepszy sposób, po prostu to przebuduję. Traktuj eiac.dev jak repo w ciągłym rebase, nie jak wydany raz na zawsze artefakt. :)