Ako sa zo štyroch mesiacov programovania stal event-driven runtime systém
Keď som dal výpoveď v práci, plán bol jednoduchý:
- prejsť na Arch Linux,
- spraviť lepšiu automatizáciu,
- zistiť, čo je pravda na AI hype.
V tom momente ma zaujímalo hlavne:
- Hyprland,
- shell automatizácia,
- reproducibilné systémy,
- lokálne AI modely,
- terminálové workflow.
Myslel som si, že staviam malý AI toolkit.
Nemyslel.
Nakoniec z toho vznikol úplne iný typ systému:
event-driven runtime architektúra.
Začalo to Arch Linuxom
Pred AI už existovala automatizácia na Debiane. Rôzne deploy skripty, setup workflow a systémové utility.
Ale po prechode na Arch Linux a Hyprland sa všetko zmenilo.
Cieľ bol:
- plne reprodukovateľný systém,
- plne skriptovateľné prostredie,
- transparentný runtime,
- minimum „magických“ vrstiev.
Prvá veľká myšlienka bola:
deploy zariadenia a runtime logika nie sú ten istý problém
Z toho vzniklo:
deploy_os pripraví zariadenie
OS Layer je nezávislý od OS
A práve toto sa stalo jedným z najdôležitejších architektonických rozhodnutí.
AI fáza
Projekt sa pôvodne volal AI toolkit.
Vznikli:
aiagawat
Kde:
aibol runtime interface,agorchestration layer,awwatch/event systém,atreplay/testing/trace tooling.
Najprv to vyzeralo ako klasický AI agent projekt.
Prompty.
Modely.
Tool cally.
OpenAI.
Ollama.
Shell integrácia.
Lenže potom prišiel skutočný problém.
Skutočný problém nebolo AI
Najväčší problém nebolo generovanie textu.
Najväčší problém bolo:
nedeterministické runtime správanie
LLM systémy priniesli úplne nový debugging problém:
- čo spustilo čo?
- prečo sa vykonal tool?
- aký bol runtime state?
- ktorý output spôsobil ďalší krok?
- ako replaynúť failure?
Klasické logovanie prestalo stačiť.
AI agent bez runtime observability sa veľmi rýchlo stane nedebugovateľný systém.
A práve vtedy sa celý projekt otočil úplne iným smerom.
Event sourcing zmenil všetko
Zlom prišiel v momente, keď runtime začal fungovať cez append-only event model.
Namiesto:
- mutable state,
sa pravda systému presunula do:
- eventov.
Architektúra sa zmenila na:
events.jsonl -> reducers -> state.json -> realtime board
Kde:
events.jsonlje runtime história,- reducers vytvárajú projekcie,
state.jsonje snapshot,- board vizualizuje runtime.
To prinieslo:
- replay,
- deterministickú rekonštrukciu,
- runtime audit,
- causal tracing,
- realtime observability.
Runtime sa stal debugovateľný.
Architektúra veľmi pripomína Event Sourcing a CQRS modely používané v distribuovaných systémoch.
AI prestalo byť špeciálne
A tu prišlo ďalšie zistenie:
AI už nebolo špeciálne.
Keď existoval runtime contract, rovnaký systém mohol riadiť:
- AI,
- crypto,
- workflow,
- deployment,
- realtime dashboardy,
- execution systémy.
AI sa stalo iba prvým runtime participantom.
A práve vtedy sa projekt prestal volať AI toolkit.
Vznikol:
OS Layer
Systém postavený na:
- eventoch,
- replay,
- projekciách,
- runtime truth,
- observability.
Deploy OS
Deploy vrstva sa postupne oddelila od runtime vrstvy.
deploy_os dnes rieši:
- hardware preparation,
- Linux deployment,
- desktop provisioning,
- mobile deployment,
- reproducibilné prostredie.
Základné pravidlo architektúry je:
deploy_os pripraví prostredie
OS Layer beží nad prostredím
Vďaka tomu rovnaký runtime funguje nad:
- Arch Linux,
- Debian,
- Android,
- postmarketOS,
- LineageOS,
- SDM845 zariadeniami,
- x86_64 systémami.
Runtime už nezaujíma konkrétny OS.
Prečo shell?
Častá otázka:
prečo shell?
Pretože shell dáva:
- transparentnosť,
- composability,
- natívnu integráciu s OS,
- jednoduchý debugging,
- jednoduché pipeline workflow.
Tam nie je schovaná mágia.
Každý krok je viditeľný.
Každý proces je inspectable.
Každý runtime event sa dá replaynúť.
A práve to je extrémne dôležité pri AI systémoch.
Cieľ nikdy nebol:
- framework hell,
- skryté runtime vrstvy,
- magické orchestration systémy.
Cieľ bol:
- explicitný runtime,
- explicitný state,
- explicitné eventy.
Realtime board
Realtime board sa časom stal centrálnou observability vrstvou.
Board dokáže realtime zobrazovať:
- AI runtime,
- workflow execution,
- tool cally,
- crypto execution,
- reducer state,
- replay state,
- runtime causal chain.
Najdôležitejšia vec je:
board ukazuje kauzalitu
Nie iba:
- čo sa stalo,
ale:
- čo to spustilo,
- prečo sa to stalo,
- aký bol runtime state,
- čo nasledovalo potom.
To úplne mení debugging.
Crypto vrstva
Crypto bola paradoxne pôvodná motivácia projektu.
Lenže AI zhltlo niekoľko mesiacov vývoja.
Až keď vznikol runtime contract, crypto integrácia začala byť jednoduchá.
Crypto dnes dedí:
- event systém,
- replay,
- realtime board,
- state projections,
- runtime observability.
Vznikol:
- exchange layer,
- execution contracts,
- realtime monitoring,
- deterministic runtime flow.
A tam prišlo ďalšie zistenie:
matematika hype nezaujíma
Nakoniec všetko skončí pri:
- eventoch,
- state,
- execution,
- causalite,
- replay.
Dnešná architektúra
Dnes systém tvorí viac vrstiev.
Deploy Layer
Rieši:
- hardware,
- OS deployment,
- provisioning.
OS Layer
Spoločný runtime/event systém.
AI Layer
LLM orchestration a tooling.
Crypto Layer
Exchange execution a trading runtime.
Všetky vrstvy zdieľajú:
- replay,
- event contract,
- reducers,
- realtime board,
- runtime persistence.
Čo sa vlastne stalo
Pôvodný cieľ bol:
- lepšia automatizácia,
- lepší Linux workflow,
- AI tooling.
Výsledok je:
- event-driven runtime systém,
- replayable execution layer,
- realtime observability platform,
- deterministic runtime reconstruction.
AI bol iba katalyzátor.
Skutočný projekt sa nakoniec stal:
systems engineering.
A najdôležitejšie zistenie bolo:
runtime truth musí byť observable
Bez toho:
- AI agenti prestanú byť debugovateľní,
- workflow sa stanú nečitateľné,
- automatizácia začne byť nebezpečná,
- runtime sa rozpadne na chaos.
S replayable eventami a deterministic reconstruction sa systém stáva pochopiteľný.
A to zmenilo úplne všetko.
Záver
Celé to začalo:
- AI hype,
- Arch Linuxom,
- Hyprlandom,
- shell scriptingom.
A skončilo to ako:
event-driven OS runtime layer
A úprimne, najviac absurdné na tom je, že pôvodne som si len chcel pozrieť, či AI nie je iba hype. ????