Anatomia invariantă

În timp ce pregăteam manualul, am rulat un experiment ca să testez empiric framework-ul. Rezultatul e demonstrația în oglindă în jurul căreia e construit capitolul. Majoritatea demonstrațiilor cu coding agents arată agentul făcând exact ce promite de obicei reclama - scrie o feature nouă, repară un bug, generează teste. Demonstrația mea a făcut altceva. Am folosit Claude Code, coding agent-ul, ca să inspectez codul sursă al altor doi coding agents, unul lângă altul, în paralel.

Cei doi agenți inspectați au fost Codex CLI și opencode. Amândoi sunt complet open source. Codex CLI e scris în cea mai mare parte în Rust, licențiat Apache 2.0 și întreținut de OpenAI. opencode e scris în cea mai mare parte în TypeScript, licențiat MIT și întreținut de o echipă independentă. Servesc cam același scop. Au fost construiți independent. Nu au nicio linie de cod în comun.

Am deschis două panouri de terminal. În panoul din stânga, Claude Code în repository-ul Codex. În cel din dreapta, Claude Code în repository-ul opencode. Același prompt tastat în ambele: "Explain the architecture of this codebase. Map the agent loop, the tool system, the permission gates, the sandbox componente principale, and the plugin model. Cite specific files and line numbers."

Ambele panouri au lucrat în paralel, independent, fiecare cu propriul context window, fiecare pe propriul repository. Cam patru minute pe ceas - am refăcut benchmark-ul în mai 2026 și a ieșit patru minute și treisprezece secunde, din care vreo șapte au fost git clone-ul shallow. Restul a fost agentul umblând prin arborii de directoare, numind componentele principale și citând fișiere. Cifra depinde de faptul că ambele repository-uri își publică arhitectura în numele crate-urilor și ale directoarelor: Codex are core-skills, core-plugins, mcp-server, tools, agent; opencode are skill/, plugin/, mcp/, tool/, agent/. Pentru un codebase mai puțin auto-documentat, socotește mai degrabă zece-cincisprezece minute per repo. Demo-ul e rapid pentru că, la nivel de nume de fișier, convergența se vede cu ochiul liber - ceea ce e, în sine, lecția de fond.

Panourile au întors două rezumate de arhitectură, unul pentru Codex în Rust, unul pentru opencode în TypeScript. Rezumatele nu arătau identic - alte nume de fișiere, alte structuri de foldere, alte idiomuri. Dar aveau aceeași formă.

În ambele repository-uri, Claude Code a găsit o buclă de agent. Codex o implementa în core/session/turn.rs. În opencode, bucla trăiește în session/prompt.ts. Alt limbaj, alt nume de fișier, aceeași buclă: primește promptul, rulează modelul, execută tool-urile, capturează rezultatele, decide dacă mai continuă, repetă.

În ambele repository-uri, Claude Code a găsit un registru de tool-uri. Codex folosea un trait de Rust - fiecare tool implementează trait-ul, registrul enumeră implementatorii. La opencode, același rol îl joacă o interfață TypeScript - fiecare tool implementează interfața, registrul enumeră implementările. Constructe de limbaj diferite, același pattern.

În ambele repository-uri, Claude Code a găsit un gate de permisiuni. Codex trecea fiecare tool call printr-o verificare de permisiuni înainte de execuție. Același pattern se regăsea în opencode. Căi de cod diferite, același rol arhitectural.

În ambele repository-uri, Claude Code a găsit o componentă principală de sandbox. Și aici, pentru prima dată în comparație, implementările au divergat substanțial. Codex implementa izolare reală la nivel de OS pe trei platforme - Seatbelt pe macOS, bubblewrap cu Landlock și seccomp pe Linux, token-uri restricționate cu job objects pe Windows. Kernelul însuși refuza syscall-urile pe care agentul nu era autorizat să le facă. Prin contrast, opencode implementa o îngrădire soft - validare de căi și prompt-uri de permisiune, dar fără o graniță impusă de kernel.

Aceeași componentă principală. Același rol arhitectural. Implementare substanțial diferită. Implicații de guvernanță substanțial diferite.

În ambele repository-uri, Claude Code a găsit un model de plugin-uri. Codex încărca plugin-urile dintr-un director configurat. Modelul de plugin-uri din opencode folosea un pattern similar, de tip „pui fișierul în director”. Aceeași componentă principală conceptuală: extinzi capabilitățile agentului la runtime, fără să-l reconstruiești.

Și în ambele repository-uri, Claude Code a găsit suport pentru MCP. Același server de Jira, același server de GitHub, același server de Postgres funcționau cu amândoi agenții. Specificația de integrare e portabilă.

Și tot în ambele repository-uri, Claude Code a găsit o cale de dispatch pentru subagenți. În codebase-ul Codex, componenta principală de subagenți e cel mai vizibil dintre toate - acolo a fost feature-ul de afiș, iar codul de dispatch e ușor de găsit după nume. În opencode, calea echivalentă poartă un nume mai puțin proeminent, dar există, iar Claude Code a identificat-o după comportament: o funcție care pornește o instanță proaspătă de agent pe un prompt delimitat și un context izolat, întoarce un singur rezultat structurat și nu lasă niciodată contextul copilului să se scurgă înapoi în părinte. Suprafață diferită, aceeași componentă principală.

Componentele principale. Două implementări. Aceeași anatomie. Alegeri diferite despre cum materializezi anatomia.

Îți povestesc despre demo-ul ăsta pentru că demo-ul e mutarea pedagogică centrală a manualului.

Odată ce ai văzut anatomia într-un agent, începi s-o vezi în fiecare agent. Vei citi documentația unui agent nou și ochii îți vor sări direct la „cum tratează ăsta context window-ul? ce tool-uri are? skill-urile se activează la detecție sau sunt always-loaded? există un model de plugin-uri? vorbește MCP?” Nu vei mai evalua agentul nou după afirmațiile de marketing. Îl vei evalua după poziția anatomică.

Ăsta e framework-ul. Anatomia e invariantă. Implementările variază. Alege implementarea care se potrivește constrângerilor tale, nu pe cea cu cel mai spectaculos demo.

Care sunt constrângerile tale? Afinitatea de limbaj - se potrivește runtime-ul agentului cu stack-ul echipei? Licența - Apache, MIT, comercială; poți citi sursa dacă ai nevoie? Potrivirea cu ecosistemul - conține marketplace-ul de plugin-uri integrările de care ai nevoie? Enforcement-ul de sandbox - ai nevoie de izolare la nivel de kernel sau e suficientă o îngrădire soft? Postura de audit - trebuie să demonstrezi conformitate în fața unui reglementator, și produce agentul artefactele cu care s-o demonstrezi? Sunt întrebări concrete, comparabile, decidabile. Nu sunt „care e mai bun”. Sunt „care se potrivește constrângerilor tale”.

Echipele care greșesc aici se fixează pe model. Dezbat Claude Code versus Codex versus Cursor, sau dezbat modelele de dedesubt ca și cum calitatea modelului ar determina singură calitatea livrării. Sunt întrebări diferite. În livrarea de software cu agenți, harness-ul, modelul de guvernanță și integrarea în workflow contează la fel de mult ca plafonul modelului. Harness-ul înseamnă componentele principale plus felul în care sunt organizate, iar diferențele dintre harness-uri sunt locul unde se joacă miza reală.

Un compromis de guvernanță concret înainte să mergem mai departe, pentru că va reapărea pe tot parcursul manualului.

Constatarea despre sandbox din demo e reală și are consecințe. Codex impune izolare la nivel de OS. Sandbox-ul opencode, nu. Dacă evaluezi ce agent pui în fața unui developer care îl va rula pe cod de client, diferența de sandbox contează. Nu e o afirmație de marketing. E verificabilă în sursă. Poți citi apelurile de kernel. Poți vedea dacă sandbox-ul e real sau e teatru.

Dar ideea de profunzime nu e „Codex are un sandbox mai bun”. Ideea de profunzime e că jumătatea de la nivel de OS a componentei principale Permisiuni / Sandbox numit în Capitolul 1 e locul unde vendorii diverg cel mai tare, iar alegerile pe care le face un vendor în privința componentelor principale sunt alegeri de guvernanță. Când compari agenți, nu compari doar capabilități. Compari filozofii de guvernanță.

Un vendor care livrează un sandbox real îți spune că se așteaptă ca agentul lui să fie folosit în medii în care pot ajunge instrucțiuni ostile - prin dependențe, prin fișiere compromise, prin prompt injection chiar în codebase. Construiește apărare în adâncime (defense in depth). Un vendor care livrează o îngrădire soft îți spune că se așteaptă ca agentul lui să fie folosit în medii de încredere, în care utilizatorul e la comandă, iar prompt injection-ul e o grijă teoretică. Ambele posturi pot fi apărate. Sunt posturi diferite.

Tu alegi. Să știi ce anume alegi - ăsta e rostul capitolului de arhitectură.

Acum ai mutarea.

Când apare următorul coding agent în marketplace-ul tău - și va apărea unul în trimestrul următor, pentru că ciclul se măsoară acum în luni - nu trebuie să citești postarea de lansare de pe blog. Nu trebuie să aștepți articolul comparativ. Nu trebuie să-l instalezi și să-l rulezi o săptămână ca să-ți formezi o părere.

Îi deschizi repository-ul. Localizezi asamblarea contextului. Localizezi registrul de tool-uri. Localizezi componenta principală Permisiuni / Sandbox (stratul de decizie + sandbox-ul de OS, cele două jumătăți numite în Capitolul 1). Localizezi încărcarea skill-urilor. Localizezi extinderea prin plugin-uri. Verifici suportul de MCP. Localizezi stratul de memorie (AGENTS.md sau echivalentul lui; orice suprafață de auto-memory expune vendorul). Localizezi dispatch-ul de subagenți - toate înfășurate în bucla de agent a harness-ului.

Opt puncte de inspecție. Douăzeci de minute de inspecție. Vei ști mai multe despre oportunitatea adoptării acestui agent decât îți va spune orice articol de review, pentru că vei ști dacă alegerile lui concrete de implementare se potrivesc constrângerilor concrete ale echipei tale. Afinitate de limbaj. Compatibilitate de licență. Enforcement de sandbox. Postură de audit. Întrebările sunt stabile.

Marketingul vendorului îți spune pe ce vrea el să te uiți. Codul sursă îți spune ce a construit de fapt. Invarianța arhitecturii îți dă lentila prin care vezi dincolo de marketing.

Asta e mutarea. Ia-o cu tine.

Capitolul următor e dedicat guvernanței - care sunt straturile, ce face fiecare, ce se întâmplă când lipsește unul dintre ele. Compromisul de sandbox prin care tocmai am trecut e un exemplu de ce contează întrebarea guvernanței. Mai sunt straturi deasupra și dedesubtul sandbox-ului, și toate au nevoie de atenție.