What our trainers teach, open to read.
The material behind our trainings, free to read: what agentic engineering is, how teams organize their work around coding agents, and what the research says.
- 116 pages
- 9 topics
- free, no sign-up
- Agentic Engineering
The entry point to the field: how it differs from vibe coding, how teams practice it, how to tell whether a team improves, and what changes at enterprise scale.
Updated:
- AEMM industry evidence
Industry evidence shows most enterprises plateauing at modest AI productivity gains, with the larger gains following codebase quality, restructured teams and measured outcomes rather than tool choice. External maturity models map onto AEMM levels and cross-check an assessment without replacing it.
Updated:
- Architecture and Design
Architecture matters more when agents write most of the code. The engineer's contribution moves to structure and judgment, and the artifacts that steer agents, such as specifications, tests, documentation and design systems, become parts of the architecture.
Updated:
- Agent-authored video
Agent-authored video treats a video as code: the agent writes a composition in HTML or React, headless Chrome renders it frame by frame, and FFmpeg encodes the result. The source diffs and reviews like code, but only watching the render tells you whether the video is good.
Updated:
- Architecting agentic systems
An agentic system splits into agents and workflows instead of services, and connects them through MCP, agent-to-agent protocols and hand-offs that carry context. Production use needs durable execution, tracing, bounded loops, trajectory evaluation and a zero-trust posture toward every agent.
Updated:
- Architecture work in the agentic era
When agents write most of the code, the engineer's job moves to architecture: placing boundaries, stating intent and constraints, and judging quality. Cheap implementation raises the value of design, because an agent without a sound design model only produces a mess faster.
Updated:
- Build versus buy
Agents and English-language builders let anyone build software, but they do not make buying obsolete. Business software encodes rules most builders never see, so companies keep buying components, now designed to be driven by people and agents alike through protocols such as MCP.
Updated:
- Modernization and interface design
Agents read undocumented legacy code without tiring, which makes reverse engineering a strong use case, as long as deterministic parsers and tests bound what the model touches. Generated UI needs the same discipline: without explicit design direction, models converge on a generic look.
Updated:
- Specifications, tests, and context
The specification is the source of truth and its tests check the code against it. When the two drift apart, the spec's owner decides which side changes. Documentation now has a second reader, the agent, which needs a small, ranked and maintained instruction layer instead of an exhaustive one.
Updated:
- Federated Context Platform for Enterprise AI Agents
For architects bringing agents into a large company: how context layers follow the org chart, what the gateway and catalog do, and where to start reading.
Updated:
- Engineering context products
How documents, conversations and source code become context products, step by step from ingestion to a code knowledge graph, for platform and data teams.
Updated:
- Governance and operations
Federated context stays safe and useful only if it is governed after launch. An orchestrator assembles just the context a task needs, access control filters data at the source instead of trusting the model, and event-driven re-indexing, versioning and named owners keep context from going stale.
Updated:
- The platform layer
The platform layer is the shared part of a federated context platform: an LLM gateway that governs model access, cost and guardrails, and a context catalog that makes every context product discoverable. Agents ask the catalog what exists and the gateway for the content, so they never depend on where it is stored.
Updated:
- Storage and retrieval architectures
No single store serves every context need. Hybrid enterprise search finds relevant documents, knowledge graphs answer multi-hop questions about relationships, and Git-style repositories give long-running agents auditable, branchable memory. A mature platform routes each request to the store that fits it.
Updated:
- Strategy and architecture
Enterprise agents need timely, domain-specific context, and one central store cannot own or refresh it at enterprise scale. Treating context as a product lets each domain publish owned, discoverable context, while a shared platform supplies the gateway, the catalog and the common controls.
Updated:
- Memory and Context Engineering
Context engineering is the work of curating the tokens a model sees at each step, and agent memory is what carries that context across sessions. Most agent failures are context failures, so this curation is the main lever an engineer has over agent quality.
Updated:
- Persistent agent memory
Persistent agent memory is state an agent writes outside its context window and reads back in a later session, as notes, memory files or knowledge graphs. The hard part is forgetting: memory that only grows ends up holding nothing useful.
Updated:
- Just-in-time retrieval
Search on demand or index up front? The trade-offs for coding agents, Cognition's measurements on both approaches, and a catalog of retrieval tools.
Updated:
- Context as a versioned artifact
For teams with dozens of skills and rules: giving each one an owner, testing context with tiered evals, and the supply-chain risks of sharing it.
Updated:
- Methodologies and Frameworks
Agentic engineering methods redesign how humans and agents divide the work, now that humans no longer write every line. Swapping the coding tool while keeping the sprint-based operating model captures only a fraction of the gain.
Updated:
- The agent loop
What an agent is made of, how to build one in plain code, and how to debug the step that failed instead of re-running the whole loop.
Updated:
- The disciplined compounding loop
How to run each agent task as plan, test-first build, check and retrospective, and why unstructured generation costs delivery stability.
Updated:
- Human accountability
What stays with the engineer when agents write the code: delegate, review and own, the new middle loop, and three manifestos that put it in writing.
Updated:
- Spec-driven development
How specifications create stable intent and verifiable work for coding agents.
Updated:
- Quality and Verification
Verification is the constraint of agentic delivery: when agents write most of the code, generation is cheap and checking is scarce. A team ships as fast as it can prove the output right, through tests, deterministic gates, acceptance evidence and evals, not as fast as it can produce code.
Updated:
- Agentic continuous delivery
The delivery rules for agent-written changes and what each pipeline stage checks, for teams letting agents commit to a production codebase.
Updated:
- Coding benchmarks
Coding benchmarks measure whether an agent makes a small set of unit tests pass, mostly in Python and often on one function. They leave out the parts of the job with the most leverage: turning a fuzzy problem into a good specification, and keeping a codebase easy to change over many edits.
Updated:
- Deterministic quality gates
How feedback loops from language servers through CI constrain agent behavior.
Updated:
- Evaluating non-deterministic systems
How to test output that varies between runs, from unit tests to pass-rate baselines, and what a public eval leaderboard does and does not prove.
Updated:
- Quality and productivity metrics
Under agentic coding, volume metrics such as lines of code or pull requests become harmful, because rewarding volume floods review with unchecked output. The measures that hold are first-pass acceptance, rework rate and the DORA delivery metrics, read for agent changes against the human baseline.
Updated:
- The surrounding quality system
AI magnifies the engineering practices a team already has. Solid source control, observability and small batches turn into speed, while a review bottleneck or a brittle pipeline turns into longer delays and more breakage. The rules, reviews and hard checks around the agent steer what it produces.
Updated:
- The velocity trap
Why generation can outpace verification and reduce real delivery throughput.
Updated:
- Curated Book List
The books worth reading on building technology organizations, ranked by relevance from 10 (essential) to 1 (supplementary). Start with the cross-category list: All Hands on Tech and The Art of Scalability rate 10 for any engineering leader.
Updated:
- Evidence
The research on AI-assisted engineering finds that AI amplifies the practices a team already has: strong delivery systems get faster, weak ones ship more defects. Individual speed gains are real but uneven, and they reach the business only where review, testing and the operating model change with them.
Updated:
- AI productivity studies: METR, Stanford, DORA and Multitudes
No single AI productivity number holds. METR measured experienced developers 19% slower in repositories they knew, Stanford found a median gain near 10% that shrinks as tasks and codebases grow, DORA finds AI amplifies the existing system, and Multitudes ties gains to learning time.
Updated:
- Amazon Cost to Serve Software (CTS-SW)
Amazon's numbers on developer experience: what it measured, how the savings make a business case, what drives cost down and which metrics it rejects.
Updated:
- The DORA report on AI-assisted development
The DORA 2025 report finds that AI amplifies the engineering system it lands in: strong review, pipelines and small batches gain speed, weak ones gain instability. Telemetry from Faros AI disputes that a strong foundation protects a team from downstream deterioration.
Updated:
- The DX AI-assisted engineering impact report
DX's Q1 2026 benchmark of 400+ companies found 92.7% AI adoption and 3.9 hours saved per developer each week, yet quality swung both ways and CI waits and meetings still cost more time than AI saves. Enablement and measurement, not tool choice, decided the outcome.
Updated:
- Moving away from Agile: McKinsey's AI operating-model research
McKinsey's survey of about 300 enterprises found AI lifts company-level productivity only 5 to 15 percent, because teams keep agile-era sizes, sprints and roles. Top performers were 7x likelier to run AI-native workflows and 6x likelier to have AI-native roles in smaller pods.
Updated:
- Vouch in Ghostty: trust-gating open-source contributions
Ghostty merged the Vouch model in February 2026: only contributors a maintainer has explicitly vouched for may open pull requests, and denounced users are blocked. It answers floods of AI-generated contributions with explicit social trust rather than an accumulated reputation score.
Updated:
- The State of AI-Native Engineering report
Augment Code's survey of 219 engineering leaders found that about half their code is AI-generated, yet only 57 changed code review and fewer changed roles, onboarding or measurement. Losing shared understanding of the codebase worried 55%, the top concern and the least addressed.
Updated:
- Getting Started
Getting started with agentic engineering means changing how you work, not upgrading a tool: you learn to specify, delegate and verify instead of typing code. Expect to be slower at first. The productivity evidence shows a learning curve before the gains, and the teams that get through it protect time to practice.
Updated:
- Getting Started and Learning
Getting started with agentic engineering is a learning problem, not a tool installation. Developers are slower in their first hours with coding agents and faster after structured practice, and how the learning is organized decides the difference more than which tool is bought.
Updated:
- Effective beginner practices
Beginners get good with coding agents by practicing in a domain they can judge, keeping tasks and feedback loops small, and granting the agent more autonomy only once reviewing every small step turns into rubber-stamping.
Updated:
- Deliberate practice
Deliberate practice builds judgment with coding agents: start in a domain you can check, keep tasks and feedback loops small, practice daily on real work, and put friction back where the tool makes thinking optional.
Updated:
- Engineering foundations
Engineering foundations matter more when agents write the code, because the work that remains is judging it: framing the problem, seeing what the agent missed, and verifying output that a model inferred rather than compiled.
Updated:
- The junior learning path
AI absorbs the small, low-risk tasks juniors once learned on, so teams have to create learning work on purpose. Hiring shifts with it: interviewers now test whether a candidate questions and audits flawed AI-generated code.
Updated:
- Verification literacy
What an engineer needs to review generated code well, and why that code needs a different kind of review, for anyone who checks agent output.
Updated:
- The learning curve
Developers are often slower in their first weeks with coding agents, and team performance dips while people learn before gains appear. Measurements taken in that window, or built on self-reports and code volume, misread the tools in both directions.
Updated:
- Organizational learning
Individual AI use becomes team capability only when the organization changes with it: incentives, ownership of risk and trust. Without that, pilots succeed technically and still stall, and usage grows while the company learns nothing.
Updated:
- Adoption gaps and resistance
AI pilots stall when the organization does not change with the tool. Usage spreads unevenly and shallowly, nobody owns the risk of AI-generated output, and engineers fear for their expertise more than their jobs, so adoption needs structural and cultural work alongside the rollout.
Updated:
- Productivity and Workflow
Measured effects of AI-assisted engineering range from slowdowns to large throughput gains. Enablement, measurement discipline and the workflow around the code decide where a team lands, far more than the model or the tool.
Updated:
- What moves adoption
Sustained adoption follows dedicated learning time, clear policies, peer mechanisms such as champions and sharing channels, and role-specific workflows packaged for reuse. Top-down usage targets produce compliance theater, and access alone does not produce use.
Updated:
- Productivity evidence and quality
Measured productivity gains from AI coding are modest and conditional, and one randomized trial found a slowdown: they vary by task, codebase and enablement, self-reports overstate them, and higher output raises churn, defects and review load unless quality gates scale with it.
Updated:
- Measuring impact
Measure agentic engineering by pairing AI metrics such as adoption, AI-assisted share and spend with the delivery metrics that predate AI, such as throughput and change failure rate. AI metrics show what is happening. Core metrics show whether it works.
Updated:
- Practitioner practices
As of October 2026, practitioners hand agents whole tasks with the tools to see the delivery cycle and ask for proof instead of steering each step: the plan goes into a committed file, failed attempts are discarded instead of patched, questions state the goal rather than the method, and exact repeated operations go into scripts.
Updated:
- Where gains and losses occur
AI speeds up writing code, which was rarely the bottleneck. The constraint moves into review, testing, change approval and operations, so system-level gains come from fixing coordination and handoffs, not from generating code faster.
Updated:
- Agent instructions (CLAUDE.md, AGENTS.md)
What to put in CLAUDE.md or AGENTS.md and who should own it, for teams setting up the file their coding agents read every session.
Updated:
- Automation catalog
Why a software factory writes its standing automations down as a catalog, and what the auditor job in that catalog checks.
Updated:
- Context window
Why a bigger context window does not fix agent quality, and the habits teams use to keep each session's window small.
Updated:
- Hooks
When to reach for a hook instead of an instruction file, and the jobs teams give hooks in day-to-day work with coding agents.
Updated:
- Quality gates
Why quality gates matter more once agents write the code, and how a gate differs from an instruction the agent may ignore.
Updated:
- Research, Plan, Implement (RPI)
Why RPI gives each step a fresh context window and where people should review, for teams moving from chat prompting to a planned workflow.
Updated:
- Spec-driven development
What a written spec changes for an agent, and how a team keeps the spec true while code and tests move on.
Updated:
- Vibe coding
Where vibe coding is the right call, where it breaks down, and what a team switches to once software has to be run and maintained.
Updated:
- Leadership
Engineering leadership builds the environment in which teams decide well on their own: a strategy that bounds the space for judgment, management that matches the uncertainty of the work, and interfaces that make local responsibility possible. When a team adopts AI, the gains depend on that environment more than on the tool.
Updated:
- Dynamic-robust organization
For engineering leaders: strategy versus plan, matching management to the problem, where responsibility sits, and whether culture can be changed directly.
Updated:
- Leading AI Adoption
The levers an engineering leader actually controls when a team adopts agents, and the measurement trap that turns a good adoption into a bad one.
Updated:
- Product Management
When agents do the building, the scarce skill moves from building a feature to knowing which feature is worth building and saying precisely what it must do. Product management gets more important: the specification and the prototype become what the agents work from.
Updated:
- Software Engineering
Software engineering is the craft of building systems a business can change safely: values that decide where a team puts its weight, principles that turn those values into decisions, and the judgment that applies them. None of it changed when agents arrived. Agents make it matter more, because they amplify the practices a team already has.
Updated:
- Architecture Principles
Architecture principles turn engineering values into decisions a team can check: align systems with business domains, communicate without blocking, keep services small, deliver continuously, couple through proven low-tech means, decide in public, and assume attack. Each principle carries a statement, a rationale, implications and review questions.
Updated:
- Build or Buy Framework
Decide build or buy on four dimensions: functional, technical and operational complexity, plus unique business value. Then count cost at five levels, from technology and staffing up to lost business and missed opportunity. Build what differentiates the business and what your team can understand and operate.
Updated:
- Engineering Manifesto
An engineering manifesto states the values a team weighs every decision against: tech follows business, move fast and fail fast, low technical barriers, coverage of non-functional aspects, and full ownership. Teams apply them with common sense and discuss any deviation openly with the teams it affects.
Updated:
- Engineering Philosophy
Engineering philosophy is the reasoning beneath engineering rules: work flows best when a team can change its part of a system alone, sees the effect of its decisions fast, and keeps learning. People who have internalized that reasoning need fewer rules to act on it.
Updated:
- The Five Ideals
The Five Ideals are the conditions that make fast flow real in daily work: locality and simplicity, focus, flow and joy, improvement of daily work, psychological safety, and customer focus. Where one is missing, engineers lose time to coordination, interruptions, hidden defects or work nobody needs.
Updated:
- The Three Ways
The Three Ways are fast flow from development into operations, fast feedback that fixes quality at its source, and a culture of continuous learning. Together they describe how work should move through a software delivery system, whatever the stack, team size or decade.
Updated:
- Senior Engineering Skills
Senior engineers are judged less on code than on the skills around it: running meetings, writing design docs, leading without authority, picking battles and taking feedback. Agentic work raises the stakes, because design docs and shared conventions become the context AI agents build from.
Updated:
- Software Factories
A software factory is the delivery system that takes a team's intent to released software it can trust, while humans build and tune the system instead of writing the product. Building one is harness engineering: the environment, orchestration, isolation and gates around the agents decide what ships.
Updated:
- Dark Factory Patterns
A practitioner's account of running agents without step-by-step approval: the anti-patterns, the patterns that work, its tools and how far to trust the claims.
Updated:
- The Federated Factory at Enterprise Scale
A federated factory platform serves many software factories in one enterprise by splitting ownership into three tiers: a central platform tier for blueprints, tool routing, identity and audit, a domain tier for context shared across teams, and a team tier where agents run. It avoids both one factory for everyone and one factory per team.
Updated:
- Multi-Agent and Orchestration
Multi-agent orchestration is the design of the system that dispatches, isolates, verifies and merges the work of many coding agents. Designed well, parallel agents multiply output. Designed badly, they multiply rework.
Updated:
- Creator and verifier roles
Patterns that separate making from checking, why self-grading fails, and how to wire a verifier into the loop, for teams running more than one agent.
Updated:
- Security and Runtime Isolation
Securing an agentic software factory means bounding what agent-produced work can do to the system that runs it. Agents route around prompts and permissions, so the controls that hold are below the agent: isolated runtimes, enforced data boundaries, least authority and risk-based approvals.
Updated:
- Contributor trust and dual use
AI makes plausible low-quality contributions cheap, so projects replace default trust in contributors with explicit vouching and proof that a human read the code. The same models let any engineer run a security review and let attackers find exploits faster than the industry patches.
Updated:
- Software Factories and Harness Engineering
The hub for software factories: why the harness matters more than the model, factory models from ticket-to-PR to dark factory, and a resource catalog.
Updated:
- Agent observability
What to record for every agent run and how to trace a commit back to the agent behind it, for teams running agents in production.
Updated:
- The enabling environment
What an agent needs before a factory routes work to it, who builds that environment, why the runtime owns security, and how the repo shortens feedback.
Updated:
- Factory roles and pipeline
How orchestrators, workers, and validators move work through a staged production pipeline.
Updated:
- Harness foundations
The components and control layers that turn a model into a dependable engineering agent.
Updated:
- Harness maintenance
How to prevent configuration decay, remove stale machinery, and recognize harness anti-patterns.
Updated:
- The software-factory pattern
How to measure a software factory, what teams running one report, and where to start reading, for engineering leaders weighing the model.
Updated:
- Production evidence
Reported software factories reach high autonomous throughput where specifications, tests and environments were strong before the agents arrived. Most numbers are self-reports from vendors or frontier labs, and cost, review capacity and long-term maintainability remain the binding limits.
Updated:
- Roles and economics
In a software factory the engineer builds the system that builds the product, and success is the share of changes shipped automatically at a known cost. That moves software production from an R&D expense to cost of goods sold, where every dollar of tokens faces a return test.
Updated:
- Work and orchestration
How factories represent work, coordinate agents, place deterministic gates, and improve their own harnesses.
Updated:
- Tools
Agentic coding tools are the CLIs, editors and autonomous agents that run a model against your codebase, plus the protocols and models underneath them. They converge with every model generation, so the lasting investment is the harness you build around a tool, not the tool you license.
Updated:
- AI Coding Tools
AI coding tools come in four form factors: terminal CLIs, AI-native editors, autonomous agents and enterprise platforms. The brand matters less than which generation of tool you adopt, what the evidence says about its productivity effect, and how its pricing behaves under agentic workloads.
Updated:
- Context and productivity
AI coding tools are limited less by their harness than by the context fed into them, and measured productivity gains sit far below vendor claims. Controlled studies and longitudinal benchmarks show modest throughput gains, and AI amplifies a team's existing engineering quality rather than replacing it.
Updated:
- Pricing agentic coding
Agentic coding is priced by usage, not by seat: an agent re-reads its growing context on every turn, so cost scales with session length rather than request count. Vendors now meter agent work in compute units or credits while keeping autocomplete flat, and per-token API billing can cost far more than a usage-included subscription.
Updated:
- Security of autonomous coding agents
A coding agent that can write files, run commands and reach the network can be turned against its user: a prompt injection that flips the agent's own approval settings becomes remote code execution. System-prompt instructions are no security boundary; concrete opt-in controls and a sandbox around the whole process are.
Updated:
- Supervision and drift
Supervising coding agents takes verification and review capacity that grows with agent output, and the coding skills it requires erode when developers lean on AI. Teams hold quality with deterministic checks in CI, inferential reviews outside it, named human reviewers who own the merge, and continued practice of the craft.
Updated:
- AI Models and Inference
Which model runs an agent, where it runs and what each token costs determine whether an agentic workflow pays off. Outcomes depend more on the harness around the model, its context management, tool selection and validation, than on which frontier model sits underneath.
Updated:
- Inference economics and infrastructure
Agentic workloads make inference cost usage-shaped: parallel agents and growing context drive token consumption, so the bill depends on tokens per completed workflow more than on the list price per token. Routing simple tasks to small models and reserving frontier models for the work that needs them keeps it in proportion.
Updated:
- Choosing models
Choose a model by testing it on your own stack and tasks, not by its leaderboard score: coding benchmarks measure narrow, Python-heavy, well-specified issues, and capability varies sharply by language and task. Routing each role to a fitting model and investing in context and validation give more leverage than chasing the top model.
Updated:
- Structured model output
Structured output means a model answers in a typed shape that code can validate, instead of free text that code has to parse. A schema-first layer declares the shape as a typed model, checks every response against it, and re-asks the model when validation fails.
Updated:
- Claude Code
Claude Code is a coding agent built as one simple loop over a small set of tools. That design leaves most of the leverage with the user: how you manage its context, how you prompt it, and how you extend it with hooks, skills, sub-agents and MCP.
Updated:
- Claude Code Ecosystem
Claude Code ships as a thin harness over the model, so most of its practical leverage sits in the ecosystem around its extension points: plugins, skills, hooks, MCP servers, usage trackers, routing proxies and token optimizers. The same openness makes that ecosystem large and noisy.
Updated:
- Authoring skills and subagents
Our position on writing skills and subagents for Claude Code: selection first, evals before instructions, few maintained skills, and both guides.
Updated:
- Authoring skills
How to write a skill that fires and works, evaluate it before shipping, and whether an agent can tune one unattended, for teams extending Claude Code.
Updated:
- Context and output interfaces
Context pressure drops when each turn carries less and delegated work runs in its own window: load MCP servers per session, keep CLAUDE.md short and clear the window before it fogs. On the output side, HTML has become a practical default for specs and reports that people are meant to read.
Updated:
- Ecosystem and extension model
Claude Code keeps its core harness thin, a single loop that leaves planning to the model, and moves specialization into plugins, MCP servers, SDKs and language servers. Native features keep absorbing popular extensions, so every extension choice needs regular review.
Updated:
- The thin-harness ecosystem
Why Claude Code keeps its core loop small, and what that means for anyone building plugins, MCP servers or other extensions on top of it.
Updated:
- Evaluation and economics
Claude Code's capability stories run ahead of production reality, and evals on your own historical tasks are the corrective. Token cost explains much of the tool market around it: trackers, routing proxies and compressors exist because agentic coding broke request-based pricing.
Updated:
- Context Engineering
Claude Code techniques for a lean session: the context cost of MCP servers, priming over a growing CLAUDE.md, fresh-agent handoffs, compact versus clear.
Updated:
- Prompt Engineering
For anyone writing prompts for Claude Code: format levels, a section-by-section structure for agentic prompts, and Anthropic's recommended techniques.
Updated:
- Designing efficient agent interfaces
An efficient agent interface keeps tool definitions and intermediate data out of the model's context. Agents do better writing code against a few task-shaped tools, or calling a CLI they already know, than choosing among dozens of tools that wrap every API endpoint.
Updated:
- Protocol and context cost
What MCP standardizes, who uses it, and how much of the context window its tool schemas take, with ways to load tools only when a task needs them.
Updated:
Nothing matches. Try a shorter word or another topic.
Start here
-
For engineering leaders
-
For engineers
-
For product people
Topics
-
Getting Started
Your first weeks with coding agents.
All 16 pages TrainingsAgentic Engineering for Developers and QA
-
Agentic Engineering
How teams work with agents once vibe coding stops scaling.
- Architecture and Design
- Federated Context Platform for Enterprise AI Agents
- Memory and Context Engineering
All 32 pages TrainingsAgentic Engineering for Developers and QA
-
Evidence
What research finds AI does to software delivery.
- AI productivity studies: METR, Stanford, DORA and Multitudes
- Amazon Cost to Serve Software (CTS-SW)
- The DORA report on AI-assisted development
All 8 pages TrainingsAgentic Engineering for Engineering and Product Leaders
-
Software Engineering
The values and principles agents amplify.
All 8 pages TrainingsAgentic Engineering for Developers and QA
-
Software Factories
Agents ship the code, people build the system around them.
All 17 pages TrainingsAgentic Software Factory: Advanced Team Training
-
Tools
Coding agents, models and the harness around them.
All 22 pages TrainingsAgentic Engineering for Developers and QA
-
Glossary
Every term, explained in a few sentences.
-
More topics
Product, leadership and the books we recommend.