Introduction to working from a specification
Working from a specification is the practice in which the first artifact in solving a task is a short document: the goal, the context, what we do, what we do not do, the criteria of acceptance, the open questions. The agent works from it, while messages in the chat play a supporting part.
Why the practice is needed
The agent answers not your question but everything that happened to be in its context window by the moment it generated the answer. A forty-turn correspondence is a poor carrier of a task: the intent is smeared across it, the constraints are lost somewhere in the middle of the window, and the criterion of acceptance is never named at all. Hence the familiar result: the code builds, but it does something other than what was needed, and there is nothing to argue about — the agreement exists in no single place.
A specification moves the intent out of the correspondence and into a document. It is short — a page, not a requirements dossier — and its value lies in three things a dialogue never has. First, an explicit negative list. “What we do not do” constrains an agent more firmly than ten clarifications after the fact. Second, a criterion of acceptance named before the work. Until it exists, “done” means “the agent stopped typing”. Third, a shared subject of the task when things diverge. When the result does not match the expectation, you correct the specification and run again instead of explaining anew every time.
What this gives the Academy
The practice sits at the centre of the first two courses, and they divide the work between them. The first sets up the loop: intent → specification → agent → result → human acceptance, with a return to the specification when things diverge. The second answers the question the first only raises: what fills the agent’s context window at the moment the answer is generated and who is answerable for that filling — because the specification enters the window not alone but together with four other layers of context, and competes with them for room in a limited capacity.
Neither step is tied to a platform or to a domain: the practices carry over to any project where you work with agents.
Course 1 · AI-driven PDLC
Why you need this course. You already write code with an agent, but the result depends on luck: sometimes it works the first time, sometimes much of it — or all of it — has to be rewritten. The course turns that work into a result you can repeat.
What you will learn. Framing a task and assembling its context, the specification as the first artifact, basic checking of the result, the analysis of risks and guard rails. Then the concept of the lifecycle: from Waterfall to working from intent, the roles of an AI team, agentic patterns. The third chapter is a workshop on two instruments, Claude Code and Cursor: subagents, skills, MCP, the links and the boundaries of the agent’s loop.
What you gain. You stop treating the agent as a clever autocomplete and start seeing exactly where the work needs your gate.
How it is built. Three chapters, 19 lessons, 1 practical assignment and 57 test items. Prerequisites — development experience, Git and the command line.
Course 2 · Context management for AI agents in team development
Why you need this course. The agent answers not your question but everything the context window holds. The course is about what fills that window and who is answerable for filling it.
What you will learn. The five layers of context — permanent, project, task, session and tool: each with its own lifetime, its own owner and its own way of reaching the window. Why the permanent layer is not remembered for good but weakens as the session goes on, and why the window is a capacity the layers compete for. Then the development team’s context system: rules, README files and the decision log, the artifact standard and its owner, the normative layer, implicit sources, quality metrics and the symptoms of degradation. The third chapter is work on a task: planning mode, working from a specification and folding the context, review of the context package, test design, research and the coordinator’s eleven-stage workflow.
What you gain. You stop fixing the agent’s answers and start fixing its input.
How it is built. Three chapters, 25 lessons, 25 practical assignments and 75 test items. Prerequisite — the first course.
Course 5 · optional · Comparative analysis of agentic development methodologies
Why you need this course. Several methods call themselves agentic development and use the same words — “specification”, “intent”, “engineering” — while meaning different things by them. Merging methods by a shared word is a false economy: a change in the very subject of development is easily mistaken for one more maturity level. The course compares seven approaches and does not fuse them.
What you will learn. A comparison frame and a vocabulary of such homonyms. Vera Vishnyakova’s maturity pyramid of agentic engineering and the code-path methodologies: Software Engineering 3.0, Vibe and Deep Coding, industrial vibe coding, the AI-driven development life cycle. Where executable knowledge engineering stands beside the pyramid, and where the closed execution contour sits on the overall map. Trust engineering and the activity operating system, illustrated by the intensive care unit — together with the regulatory frame for medical software and the EU AI Act.
What it gives you. You can put one diagnostic question to any approach — where is it written why this value is here: in the source code, or in separated, authorized knowledge — and from the answer tell what a method really changes and what it merely renames.
How it is built. Four chapters, 17 lessons, 0 practical assignments and 51 test items. Prerequisite — the course “AI-driven PDLC”. The course is aimed at the advanced part of the audience: it is a map of the field, not a programming textbook.
After the second course, the recommended continuation is the course on agent memory: what of the context outlives the session, who has the right to write there, and how to verify that memory works.
Course 6 · optional · Agent memory management
Why you need this course. The context of a window lives for one model call. An agent’s memory is everything that outlives the session and enters the window again — rules, logs, summaries, reference books — or is built into the model’s weights. The course examines what kinds of such memory exist, who has the right to write to it, how it fails, and how to verify that it actually works rather than being merely declared.
What you will learn. The first chapter introduces the language: the four memory usage classes, the three forms of its storage and their intersection. The second applies it to work: who writes to long-term memory, how the window behaves, how memory fails, how development and operation differ, how to measure memory and for whom it should be built at all. The third assembles all of this into two complete scenarios — agentic development and the ECG pipeline.
What it gives you. You can tell memory that works from memory that is merely declared, and you know who has the right to write to it.
How it is built. Three chapters, 13 lessons, 16 practical assignments and 39 test items. An optional course; its chapters sit at levels 4.0, 5.0 and 6.0. It is recommended after the course “Context management for AI agents in team development” — the concepts of context and the context window are taken from there; this is a recommendation, not a condition of access.
The next step is the introduction to Agentic Ops: the same discipline inside a regulated ecosystem and inside a closed perimeter.