The series · 7 episodes
Building intelligence
How machines that learn work, from the first neuron to today's agents. No hype.
Coming soonA hands-on course on coding agents
Take the stack apart. Understand how it works. Learn to govern it.
Don't just make it work.
Learn to tell model, agent, tools and environment apart; follow where code, commands and credentials go; verify why a configuration works.
The author
Giuseppe CiternaArchitect of the transition to artificial intelligence
Among the first CCIE trainers in the EMEA region · Co-Founder and CTO, IeXa Academy.
The main agents explained in the course
Claude Code
Cursor
Codex
Cline
Copilot
Antigravity
Before you start
When doing gets easy,
When doing gets easy,
what becomes important to learn?
Agents keep making execution cheaper. This short section tries to look at the other side of the problem: what kind of capability do we have to keep building in people while capability and work migrate towards AI?
Discover your starting point
How well do you really govern a coding agent?
Twelve cases to find out whether you can tell the components apart, follow the flows and recognize the constraint that really changes the outcome. At the end you get your report right away, no account needed.
12 questions8–10 minutesimmediate report
It isn't an exam. It's the snapshot you start from.
What do you want to do?
Follow the path from the start, or bring the method to a concrete case.
Learn
Learn the method
Build a reusable mental map for reading different coding agents without depending on the product's name.
Use
Bring the method to a problem
Compose a stack, start from your constraints, watch the rules, or compare the alternatives.
Tools
The workbench
Four tools, the same model underneath. Use them to compose, choose, observe and compare.
compose→choose→looks at→compare
Under the bench
Watch the Engine check how the pieces fit
engine room · seven pieces in line
Under the hood
A course that lives as code
Every fact lives in one place only. The numbers are computed, not typed. The texts are under test. And nothing goes online without passing through a pipeline of checks.
1 fact→1 sourcesingle source, read everywhere
655→664the count recomputes itself
text→#c8c6b6fingerprint: changes → the test stops
Start
Build the first map
Start from the checkout case and learn right away to separate who proposes, who coordinates and who executes.
Written byGiuseppe Citerna
Going further
Follow Giuseppe on LinkedIn
Other courses and learning paths
Explore the paths dedicated to networks, models and artificial intelligence systems.
The twin path
The network that thinks: Journey to AgenticOps
The same method applied to networks: how the infrastructure becomes a nervous system that thinks, decides and acts. It's the path that anticipated AgenticOps a year ago. v1 is here, v2 is coming.
v1 available · v2 coming soonThe handbook
AI Stack
The model Open Systems Interconnection (OSI) applied to artificial intelligence systems: ten blocks and three questions for analyzing larger systems.
Coming soonThe essay
The crisis of knowledge in the age of agents
What happens to expertise when agents do the work in our place.
Coming soon
Don't miss the next one
I publish every new path on LinkedIn first. Follow Giuseppe to get them early.
The course remains provider-neutral. Product-dependent information describes the situation as verified in August 2026; updates are recorded on the page Versions.
Curated by Giuseppe Citerna.
Curated by Giuseppe Citerna.
Versions
v3.3September 2026
v3.2August 2026
v3.1August 2026
v3.0August 2026
v2.0August 2026
v1.0June 2026
The course, version by version
The field changes, and the course has to change with it: facts get verified again, examples updated, and explanations corrected when a new surface changes the rules. Here you'll find the history of the public versions and, for each one, what changes for the people studying.
The same course, in English
Agenticodice speaks two languages inside the same application. Italian remains the source and English is derived from it: same lessons, same tools, same identifiers, the same Matrix. What changes is the address you arrive by, not the course.
- Portalbilingual
One application serves both languages:
/is Italian,/en/is English. Deep links point to the same identifiers in both. - Coursetranslated
The 67 lessons, the two Off the path deep dives and the certification exist in English, with a technical glossary fixed once and respected everywhere.
- Toolstranslated
The Matrix, Simulate, Configure, The Engine and the 42 worked cases run in English on the same data and the same rules as the Italian.
- Servicetranslated
What surrounds the course is in both languages too: portal pages, email messages, privacy notice, cookie policy and terms of service.
- Methodunchanged
No lesson was rewritten for the occasion. The method, the module weights and the certification bank remain those of v3.2.
In detail
English is not a copy to be kept aligned by hand: it is born from the Italian at build time, and the key of every phrase is the Italian phrase itself. When an Italian line changes, its translation becomes stale and the check names it before publication, instead of letting it grow old in silence.
Two measures watch the English edition from opposite sides. Coverage asks that every translation actually reach the screen — 10,288 units out of 10,288, with no differences in structure or markup. The residue check asks the opposite, that no unwanted Italian is left in the English; what stays Italian on purpose is declared one by one, with the reason written beside it.
Two things stay in Italian, both by choice. The "Read in Italian" link at the top of the service pages, which exists precisely to take you back. And the lab commands, which are code: translating the expected output of a command would mean changing the rule that authorises it at the same time, and the rule would stop matching.
Update v3.3.2 · September 2026Three fixes to the English edition: the reserved lessons reached account holders in Italian, the language switcher was missing from the course header, and internal links took you back to Italian instead of keeping you where you were.
The facts, re-verified one by one
The course doesn't age in silence. A maintenance procedure compares every product rule against the official sources, and when the documentation isn't enough, we open the application and look. This version collects the first complete round of those checks: no new chapters, many sentences that now say what the product really does.
- Antigravitycorrected
You can bring a guest agent into Antigravity, but with its own account: using the Antigravity login from third-party software violates Google's terms of use. The warning now opens the lesson.
- Clineexpanded
There are four ways to give Cline a model, not two: your own key, a local runtime, the Cline account and the ClinePass subscription. In all of them, the model stays third-party.
- Kilo Codecorrected
The real name is back, and with it the real surfaces: besides the extension there are the JetBrains plugin, the command line, Slack, the mobile app and the cloud agent.
- Kironew
AWS's agent enters the course as an example of the rule on surfaces: five different doors, one agent underneath. It also has a row of its own in the Matrix.
- Cursorcorrected
The Agent's catalog isn't a closed list of four names: today it also hosts third-party models. The rule doesn't change — the catalog decides, not your key.
- Sourcesreviewed
Base URL and memory in Claude Code, Copilot, Lovable and ChatGPT Work: pages moved, one name changed, one sentence turned on its head.
In detail
Google explicitly forbids using third-party software to access Antigravity with the Antigravity login, and the stated penalty is account suspension. The course showed those cases without a warning: now the warning comes first, with the legal way next to it — a Vertex or AI Studio API key.
Cursor's catalog was described as four fixed names. Listing a catalog is a losing battle, because it changes every month: the sentence was rewritten around the thing that doesn't age, namely that Cursor decides the list and that a personal key opens the chat at most, never the Agent.
The Simulator learned a better answer too. When you tried pairing GLM with the Cursor Agent it replied "this model isn't in the catalog": today that's no longer true. The combination is still wrong, but for the right reason — the model is indeed listed, but you reach it with the Cursor plan, not with your key.
**Update v3.2.1 · September 2026** Full language revision of the course and of the two off-the-path deep dives: 95 prose edits, with no changes to content, features or architecture.Full language revision of the course and of the two off-the-path deep dives: 95 prose edits, with no changes to content, features or architecture.
Access, with one tap
The course stays free: what changes is how you unlock all of it. The request for full access reaches the owner, who answers with one tap, and three messages guide you through the process from start to finish.
- Accessnew
Full access opens on the owner's approval, with no manual steps and no waiting in the dark.
- Approvalnew
The owner decides straight from the message they receive: the answer is confirmed and recorded in a single step.
- Messagespolished
The emails along the way — request, approval, welcome — have been rewritten and made safe against anything users enter.
In detail
The approval is a single, indivisible step: either the decision is recorded in full, or it isn't recorded at all. That guarantee matters when two requests arrive at the same instant.
The course becomes a portal
The course stays the same, free and mostly readable without signing up. Around it grows an environment that remembers: an account with your progress saved, a starting point captured by the Diagnostic, certification with a verifiable credential, and the documents that say how data is handled.
- Accountnew
Progress and current lesson saved on any device; the eight opening lessons stay free, the others open with the free account.
- Diagnosticnew
Twelve questions, only once: your starting point, tied to you and not to a browser.
- Credentialnew
Certification issues a credential in your name, with public verification that you can enable yourself.
- Transparencynew
Privacy notice, cookie policy and terms of service describe the system as it is, generated from the same inventory that governs the code.
In detail
The first eight lessons stay free and need no sign-up. The others open with the free account, which does one thing only: remember where you left off, on whichever device you use next.
The documents on privacy, cookies and terms aren't boilerplate: they come from the same inventory the code uses to describe the system, so they say what the system really does.
Learning to govern the system
The first version taught you to recognize the seven fundamental pieces of an agentic stack. The second keeps that map, but builds a complete path around it for learning to use it, verify it and carry it over to new systems.
- Pathrewritten
Seven modules across concepts, labs and guided cases, each closed by a checkpoint.
- Toolsunified
Simulate, Configure, Engine and Matrix become four complementary ways of using the same model.
- Reasoningnew
Forty-two cases let you apply the method beyond the examples explained directly in the course.
- Certificationexpanded
Thirty questions, nine areas and three levels of complexity, with a final profile and a review of your answers.
- Deep divesnew
"Human + agent" and "A course that lives as code" extend the course to the relationship between human expertise and AI, and to the building of the learning system itself.
In detail
The path expands from four stages to seven modules and sixty-seven lessons, and each module closes with a checkpoint that brings together what you've just learned.
The four tools stop being separate exercises: Simulate composes a stack piece by piece, Configure starts from a goal, the Engine shows the rules that decide, the Matrix compares real configurations side by side.
The seven pieces of coding agents
The first public version introduces the original mental model: Model → Provider → API → Agent → Surface → IDE → Environment, with a guided explanation, interactive stack composition and a final test.
Permanent reference
The Matrix
The Matrix puts the ways of using agents side by side. Each row tells you which surface you command them from, where they work, how you get in, who pays, which models you can use and the limit to keep in mind. When a configuration can reach the model through different paths, open "Technical details".
You don't have to memorize it. Use it to compare two configurations or to figure out where to look when something doesn't add up.
19 configurations · 7 with technical details · 2 cross-cutting components
| Agent | Surfacewhere you command it from | Environmentwhere the agent and the tools run, and where the files live | How you get in | Who pays | Models | Different model / service?can you connect it yourself? | Limit to keep in mind |
|---|---|---|---|---|---|---|---|
| Claude / Anthropic | |||||||
| Claude Code | CLI | LocalSSHCI | Claude loginAPI keyCloud identity on enterprise configurations | Claude planChosen provider or serviceCloud account on enterprise configurationsNo API consumption with a local model | ClaudeOther compatible modelsLocal models through a compatible runner | Yes, with limits | To use a different model, the service must be compatible with what Claude Code requires; changing the address alone isn't enough. |
Technical detailsAnthropic pathClaude Code→Anthropic→Claude
API: Anthropic Messages
Compatible pathClaude Code→compatible provider or gateway→model
must accept the format required by Claude Code.
Local modelClaude Code→compatible local runner→local model
the runner must expose a compatible connection.
Enterprise cloudClaude Code→supported enterprise cloud service→Claude
identity, configuration and billing follow the chosen cloud service.
|
|||||||
| Claude Code | IDE extensionVS CodeCursorAntigravity | Local | Claude loginAPI keyCloud identity on enterprise configurations | Claude planChosen provider or serviceCloud account on enterprise configurations | ClaudeOther compatible models | Yes, with limits | If you open Claude Code inside Cursor, VS Code or Antigravity, the agent is still Claude Code: it doesn't automatically use the accounts, models and rules of the IDE hosting it. |
| Claude Code | Claude desktop app | LocalCloudSSH | Claude login | Claude plan | Claude | No | From the desktop app you can't set your own API key or a personal endpoint for the model. |
| Claude Code | WebCan be started from the CLICan be started from the app | Anthropic cloud | Claude login | Claude plan | Claude | No | Starting it from the CLI or the app doesn't make the work local: agent, tools and copy of the files stay in the cloud. |
| Codex / OpenAI | |||||||
| Codex | CLI | LocalSSHCI | ChatGPT loginOpenAI API keyCredential of the chosen service | ChatGPT planOpenAI API platformChosen provider or gatewayNo API consumption with a local model | GPTResponses-compatible modelsCompatible local models | Yes, with limits | A custom service must speak OpenAI Responses. If it only offers Chat Completions, you need a translator. |
Technical detailsOpenAI pathCodex→OpenAI→GPT
expected format: OpenAI Responses.
Compatible providerCodex→Responses-compatible provider→model
GatewayCodex→gateway that exposes Responses→provider→model
Local modelCodex→Responses-compatible local runner→local model
|
|||||||
| Codex | IDE extensionVS CodeCursorAntigravity | Local | ChatGPT loginOpenAI API keyCredential of the chosen service | ChatGPT planOpenAI API platformChosen provider or gatewayNo API consumption with a local model | GPTResponses-compatible modelsCompatible local models | Yes, with limits | If you open Codex inside Cursor, VS Code or Antigravity, the agent is still Codex: it doesn't automatically use the accounts, models and rules of the IDE hosting it. |
| Codex | ChatGPT desktop app | Localseparate worktree of the project | ChatGPT loginOpenAI API keyCredential of the chosen service | ChatGPT planOpenAI API platformChosen provider or gatewayNo API consumption with a local model | GPTResponses-compatible modelsCompatible local models | Yes, with limits | The app is the agent's surface: the work stays in the local workspace and a custom service must be compatible with OpenAI Responses. |
| Codex cloud | WebCan be started from the appCan be started from the CLICan be started from the IDE | OpenAI cloud | ChatGPT login | ChatGPT planChatGPT credits | GPT managed by OpenAI | No | In the cloud task you can't connect your own API key or a personal endpoint. Starting it from the IDE or the CLI doesn't move the work to your PC. |
| Google / Antigravity | |||||||
| Antigravity agents | Antigravity IDE | Localin the configuration documented by the course | Google login | Free use with limitsGoogle AI plan | GeminiThird-party models present in the Google catalog | No | You can't freely add your own key to the managed catalog. If you host another agent in the IDE, that agent keeps its own models, accounts and rules — and always signs in with its own account: using third-party software with the Antigravity login violates Google's Terms of Service. |
| Antigravity | CLI | Not documented | Google login | Free use with limitsGoogle AI plan | GeminiThird-party models present in the Google catalog | No | Don't infer the environment from the word "CLI": in the sources the course uses, the operating environment of this surface isn't specified. |
| Cursor | |||||||
| Cursor Agent | Cursor IDE | Local | Cursor loginPersonal API key for the supported models | Cursor plan / creditsChosen provider for the calls that use your key | ClaudeGPTGeminiComposerand other third-party models in the catalogOther personal models where supported | Yes, with limits | Your own API key can power the supported chat models, but it doesn't replace Cursor Agent and isn't automatically used by all of Cursor's features. |
Technical detailsCursor catalogCursor Agent→Cursor backend→catalog model
for the managed catalog, don't attribute an upstream executor if the sources don't document it.
With your own API keyCursor Agent→Cursor backend→chosen provider→model
even with a personal key Cursor keeps building the prompt through its own backend; what changes is the credential and billing of the model call, not the harness.
|
|||||||
| Cursor Agent | CLI | Local | Cursor login | Cursor plan / credits | ClaudeGPTGeminiComposerand other third-party models in the catalog | No | From this surface you use Cursor's managed catalog: you can't connect your own API key or a model outside the catalog. |
| Cursor cloud agent | WebCan be started from the IDECan be started from the CLI | Cursor cloud | Cursor login | Cursor plan / credits | ClaudeGPTGeminiComposerand other third-party models in the catalog | No | Starting it from the IDE or the CLI doesn't make the work local, and in cloud tasks you can't connect your own API key. |
| AWS / Kiro | |||||||
| Kiro | IDECLIWebMobile to follow and approve | Local on IDE and CLIKiro cloud on Web and agents | GitHub, Google or AWS account loginAPI key only for CI, on paid plans | Kiro plan / credits | ClaudeGPTOpen-weightAutomatic selection | No | From every surface you use Kiro's managed catalog: no key of your own for the models, and the month's credits don't carry over. |
| GitHub Copilot | |||||||
| GitHub Copilot Agent | VS Code | Local | GitHub loginPersonal API key where supportedLocal model where supported | Copilot creditsChosen provider on BYOK callsHardware and upkeep for the local model | GPTClaudeGeminiSupported personal modelsSupported local models | Yes, with limits | Your key can be used in Copilot Chat and in the supported local agentic workflows, but inline completions and some other actions follow separate paths. |
Technical detailsCopilot catalogCopilot Agent→GitHub Copilot services→catalog model
With your own API keyCopilot Agent→chosen provider→model
Local modelCopilot Agent→local runner→local model
a personal key doesn't mean every call in the Copilot experience uses that model.
|
|||||||
| Copilot cloud agent | WebCan be started from the IDE | GitHub Actions cloud | GitHub login | Copilot AI creditsGitHub Actions minutes | GPTClaudeGemini | No | Starting it from the IDE doesn't make the work local, and in cloud tasks you can't connect your own API key or a personal model. |
| Multi-provider | |||||||
| OpenCode | Main CLI | LocalSSH | Provider's API keyLogin where supportedOpenCode Zen account, if usedNo credential for a local model | Chosen providerChosen gateway or serviceOpenCode Zen, if usedNo API consumption with a local model | ClaudeGPTGeminiGLMOpen modelsOther models from the supported providers | Yes | Each connection accepts its own type of access: login, subscription and API key aren't automatically interchangeable. |
Technical detailsDirect providerOpenCode→provider→model
GatewayOpenCode→gateway→provider→model
Local modelOpenCode→local runner→local model
API and format depend on the chosen connection.
|
|||||||
| Cline | IDE extensionVS CodeCursor | Local | Provider's API keyGateway's API keyCline Provider account, if usedCline account with ClinePass subscriptionNo credential for a local model | Chosen providerChosen gatewayCline ProviderFixed monthly ClinePass quota, no per-token costNo API consumption with a local model | ClaudeGPTGeminiGLMOpen modelsOther supported models | Yes | The chosen model and the connection used must properly support the tools Cline needs. |
Technical detailsDirect providerCline→provider→model
GatewayCline→gateway / OpenRouter→provider→model
Managed pathCline→Cline Provider→catalog model
Local modelCline→local runner→local model
|
|||||||
| Kilo | IDE extensionVS CodeCursorJetBrainsother compatible editors | Local | Provider's API keyKilo account on the GatewayAPI key registered in the Kilo Gateway | Provider on the direct connectionKilo when you use the Kilo balanceUpstream provider when you use your own key in the Gateway | Model chosen directlyModels available through Kilo Gateway | Yes | With Kilo Gateway the bill changes with the configuration: with the balance you pay Kilo; with your own key registered in the Gateway you pay the upstream provider. |
Technical detailsDirect providerKilo→provider→model
Kilo Gateway with balanceKilo→Kilo Gateway→upstream provider→model
the user pays Kilo.
Kilo Gateway with BYOKKilo→Kilo Gateway→upstream provider→model
the user pays the provider of their own key.
|
|||||||
IN THE TECHNICAL PATH
Cross-cutting components
Runners and gateways appear in the technical details because they can sit between the agent and the model, but they aren't agents. We keep them separate from the main Matrix so as not to confuse different roles.
| Component | What it does | Where it enters the path | Access and cost | Limit to keep in mind |
|---|---|---|---|---|
| Ollama / LM Studiolocal runners | Runs a model on the machine you choose and exposes a local API connection.The available format depends on the runner and the configuration. | Agent → local runner → local model | Normally no login or keyNo API consumptionHardware, memory, power and upkeep remain | It isn't an agent and doesn't edit files on its own. The model must also be able to use the tools the agent requires correctly. |
| Gateways / adaptersLiteLLM · OpenRouter · proxies | Receives the agent's request and routes it; when needed it can normalize or translate the format. | Agent → gateway → provider → model | Gateway key, provider key, or bothThe gateway or the provider bills you, depending on the configuration | It isn't the model and doesn't guarantee full compatibility: tool use, streaming and other capabilities may change. |
The Matrix compares configurations. If you want to try a combination, use ; if you start from your constraints, use ; if you want to see why a combination passes or gets blocked, open the .
A course that lives as code
An ordinary course can explain to you how a coding agent works. Here we tried to go one step further: to represent its structure inside the course as well. Components, relationships, constraints, cases, and sources don't live only in the pages; part of that knowledge is organized so that software can use it.
That's what lets Simulate, Configure, the Matrix, the Engine, the 42 worked cases, and the certification look at the same system from different perspectives.
Under the course · a structure the software can read
MODEL→Claude
PROVIDER→Anthropic
API→Anthropic API
AGENT→Claude Code
SURFACE→CLI
IDE→VS Code
ENVIRONMENTlocal
The course doesn't just store the names of the pieces: it also represents how they connect, which conditions have to hold, and which sources that information rests on.
Computable model of the course
the part of the knowledge that can be represented in structured form
DATA · components and properties
RELATIONSHIPS · who is connected to whom
RULES · verifiable conditions
SOURCES · evidence and date
ENGINEWhen a relationship can be expressed as a rule, the software can apply it to a concrete stack.
chosen stack → rule → consequenceWhat "as-code" means
It doesn't mean a lesson is written in HTML or that there's JavaScript behind it: that only describes the medium through which the page is published. The interesting step happens when part of what the course teaches is also represented as data, relationships, rules, and sources — that is, in a form the software can read, check, and reuse.
You can think of it as a kind of conceptual digital twin of the coding agent, as long as the metaphor is taken in the right sense: it's not a real-time synchronized copy of Claude Code, Codex, or Cursor, but a general model of the anatomy we're learning to read.
Two models, two audiences
For the software
Computable model of the course
data, relationships, rules, and sources
- represents the pieces and their properties;
- connects what depends on what;
- expresses some conditions in verifiable form.
For you
The student's method
the grid you use to read a system
components → connections → flows
→ constraints → effects
→ constraints → effects
- works even without the course in front of you;
- stays valid on tools you've never seen.
They aren't two competing models. The first lets the course build and check some experiences; the second is the grid with which you learn to read those experiences and, later on, systems the course has never encountered.
How the course uses that model
The same representation is queried in six different ways. They aren't six copies of the same application: what changes is the question they ask and the moment of learning in which they're needed.
| Tool | What it does with the model |
|---|---|
| LESSONSbuild the map | Here you learn to tell the pieces apart and to follow the relationships between them. It's the representation you'll use when you move on to the tools. |
| SIMULATEputs it to the test | You compose a concrete stack. The system builds the state of the combination and, where an executable rule exists, can check whether that step holds. |
| CONFIGUREstarts from the constraints | Here the question flips. You don't ask whether a configuration works: you describe what you need and look for the possibilities that respect those conditions. |
| MATRIXputs the stacks on the same table | It uses common dimensions to make different configurations comparable: agent, model, route, environment, access, costs, and limits stay visible in the same frame. |
| 42 WORKED CASESmake the why visible | The code builds the card from the structured case. Then the explanation walks through the case and shows which mental steps lead to the verdict. |
| CERTIFICATIONtakes the help away | In the end it doesn't matter whether you recognize a screen from the course. What matters is whether you can use the same grid in front of a less familiar situation. |
They're different ways of turning one and the same representation of the domain into a learning experience.
What happens when you use it?
So far we've looked at the architecture from above; now let's follow it from the learner's point of view. The same model passes through three different moments: first you can try a configuration, then you have to learn to explain its behavior, and finally you have to manage to transfer the method when the help disappears.
1 · Try
In Simulate, the model can answer you
YOU COMPOSE
Claude→Anthropic→API→Claude Code→CLI→VS Code→local
↓
MODEL + ENGINEchecks the combination against the available rules
↓
✓ PASS
The route doesn't speak the format the agent expects.
When you choose the components, the course builds the state of the stack. Where that relationship has been turned into an executable rule, the Engine can apply it and return a consequence: it isn't looking for a pre-written sentence, it's using the model to respond to the configuration you built.
Simulate answers one question: "does this combination hold?"
2 · Understand
The verdict alone doesn't teach enough
THE SAME KIND OF CASE
Claude→Anthropic→API from another family→Claude Code
1
COMPONENTSWhat am I looking at?
2
CONNECTIONSWho talks to whom?
3
FLOWSWhat passes through?
4
CONSTRAINTSWhich condition decides?
5
EFFECTSWhat changes?
✓
VERDICTIt stops at the constraint: the route speaks a format the agent doesn't expect.
→
TAKEAWAYBefore blaming the pieces, check what format the route speaks.
Here the goal changes. Simulate can tell you that a combination stops; the case has to teach you how you could have figured it out yourself. The code knows the structured case and builds the card, but the explanation remains a teaching object: it decides what to observe, which constraint to highlight, and which principle to carry to the next case.
Simulate makes the behavior visible. The 42 cases make the reasoning visible.
3 · Transfer
At some point the help has to disappear
A CASE NEVER SEEN BEFORE
X→Y→Z→?
components → connections → flows → constraints → effects
You decide
In the certification the software builds the test and collects the result, but the educational point is to see whether you can use the method without having Simulate's answer or a case's walkthrough in front of you. At that point the model must no longer live only in the page.
The question isn't "do you remember this case?". It's "can you still read the system?"
Try→Understand→Transfer
··
What the code does, what stays with the author
Naturally, not the whole course becomes code. The software can read data, apply some rules, build views, find dependencies, and run checks. What remains editorial is the choice of what to teach, the way to explain it, the design of the cases, and the final judgment on a change.
As-code doesn't mean "everything automatic". It means making explicit what can be structured, connected, and checked.
And when the world changes?
There's another advantage in having a model instead of a simple collection of pages: the world the course describes changes. Imagine a vendor modifies an access route; that fact could be used by a rule, by Simulate, by Configure, by the Matrix, by one of the 42 cases, by the certification, or by an explanation.
In a traditional document
where did I write this?
In a connected system
what depends on this?
This is where the maintenance pipeline comes from: an update is treated almost like a network change, with verification of the source, impact analysis, modification, checks, and only at the end the release.
Change pipeline
keyboard · ← → · space
READY · 10 steps
CHANGE
VERIFY
IMPACT
PATCH
TEST
HUMAN
RELEASE
POST
rule
Simulate
Configure
Matrix
42 cases
certification
lessons
What's happening
One change, ten steps
Here a course update is treated like a network change: you can walk through it step by step, go back, and stop where you need to.
change log · press Next or ▶ Play
A skill can describe the maintenance runbook; an agent can carry out many of its operations; the pipeline produces checks and evidence. Editorial approval stays human.
What remains, in the end
So an "as-code" course isn't simply a course written with code. The difference is that part of the knowledge has an explicit structure: it can be queried by Simulate, compared in the Matrix, used to build cases, and checked when the course changes.
The code, however, doesn't replace the teaching work. The Engine makes executable what can become a rule; the 42 cases go the opposite way, starting from a behavior and turning it into reasoning that can be understood and reused. And the certification closes the loop: at some point that structure must not live only in the course.
This page's rule
The code keeps the model consistent.
The cases teach you to reason about the model.
In the end, that model has to live in the student's head.
The cases teach you to reason about the model.
In the end, that model has to live in the student's head.
We've seen how part of the knowledge can become a model the software can use. But when work and skills also start to move toward agents, a bigger question arises: what do we want to keep building in the human being?
Simulate · try it
Compose a stack
Choose one component for each level. If the combination meets the rules, you move on to the next check; otherwise you see which condition isn't satisfied. The challenges then add more complex constraints.
What you practice here composing a stack component by component and explaining why a combination is valid or not.
This simulation checks the structural compatibility of the seven components. When you complete a coherent structure, a separate panel checks the documented operational route or points out the data still to be specified: gateway, credential and billing aren't inferred from product names alone. In the Engine view you can follow the structural checks, step by step.
First time here?
Configure · your stack
Let's build
your stack
Here you apply the consultant's method: first gather the requirements, then make a reasoned proposal.
The requirementseight questions, the way you'd ask a client
The combinationsyou check which ones meet the constraints and what changes when you alter one
The proposalthree reasoned stacks, with an essential plan and the official documentation
You can repeat the analysis with different requirements.
The Engine generates and verifies the structural combinations; each proposal then completes the access path with separate data —
The rules in execution
It isn't a list.
It's an engine.
This view shows how the structural rules evaluate every combination of the seven components, record the result and produce the counts used by the lab.
The results don't come from a static list. On every load the page generates the combinations of the seven components, applies the structural rules and updates the counts. Credential, gateway, entitlement and billing belong to the access path instead: they are evaluated separately when the configuration specifies it.
—possible structural combinations
→
—hold up to the rules
→
—distinct structural families
→
3yours, from the eight answers in Configure
1
the evaluation · selects seven components and checks them, one check at a time
inside the engine · one attempt at a time
→on record
2
the log · every attempt goes on record — where it fails and why
the log · real attempts
3
the technical view · the code the page actually runs
the technical view · functions and calls in execution
the
buildAllStacks()calls
the
compat(step, id)reads the state · selanswers
the verdict
{ ok, why }The panel shows the engine's canonical rules, the same ones the page is running, rendered directly from the data that defines them. During the animation the rule that is deciding lights up, so you can link each step of the diagram to the corresponding rule.
running
Every line of the log corresponds to a real evaluation. The combination is checked component by component and, if it isn't valid, the log names the rule that isn't satisfied. The numbers are computed: if the component catalog changes, the counts change too.