Applied AI training

Ironspec AI

The methodology for building quality software when one of the team members is a language model.
Spec-driven. Verifiable. No improvising.

The same methodology we used to build Yggdrasil, our AI cyberdefense platform — now taught to tech leads, architects, and development teams.

# SPEC-EXEC — the task’s contract
id: scout-report-assembler
depends_on: [scout-models]

contract: # signatures and schemas
deliverable: # exact paths
acceptance_criteria:
- strict typing, no errors
 - real reference data

6 Iron guarantees

G1 – G6, each with its own verification mechanism

Executable contract · runnable acceptance

Vibe coding has an expiration date

Up to 62% of AI-generated code with no methodology contains security flaws (Veracode, 2025). Ironspec AI teaches how to use AI as an executor of verifiable contracts, not as autocomplete.

The thesis

The AI arrives cold every session

The model remembers nothing from one session to the next. Agile methodologies could rely on the team’s tacit knowledge —conversation was the channel—; with a pair that remembers nothing, that channel doesn’t exist.

Ironspec AI inverts the rule: everything that holds up the system gets externalized into durable artifacts. Documentation stops being bureaucracy and becomes the condition of possibility for working with AI.

The black box

The AI implements the ticket. It works, it gets merged. Three weeks later nobody —not even whoever asked for it— understands how it was built. The knowledge lived in the chat and evaporated.

Burning through tokens

Without a standard mechanism to hand over context, every session starts from zero: architecture, conventions, and contracts get re-explained. The same context gets paid for over and over.

Fragile implementation

Without an explicit way to define what’s wanted, the AI fills the gaps with assumptions. The result passes the demo but fails at the edges, or solves the wrong problem.

We’re not optimizing for the start, we’re optimizing for the trajectory. Ironspec AI doesn’t compete on Monday’s sprint — it competes at month 18.

The methodology

What Ironspec AI is

Our own AI-augmented software engineering methodology, derived from eXtreme Programming and other agile practices: BDD’s double loop, Lean’s waste elimination, Kanban’s continuous flow and work limits, Scrum’s entry and exit gates, and Shape Up’s scope sizing.

Its unit of work is the SPEC-EXEC: an executable contract per ticket, with a mandatory core and acceptance criteria the machine runs. The specification is the primary artifact — code is a derived output, not the starting point.

It’s not theory: this is how we built Yggdrasil.

Discover Yggdrasil →

Workflow tools

  • Claude (spec design)
  • Claude Code (implementation)
  • GitHub Copilot
  • SPEC-EXEC (executable contract)
  • Decision records and knowledge base
  • Mechanical verification in CI

8 sessions · 16 hours

Learn by building a real project: a real-time collaborative project management platform (Linear/Jira/Notion style). Each session produces a durable artifact, not an exercise.

The guarantees

The «Iron» is six verifiable guarantees

They’re not slogans: each one comes with its own verification mechanism. That’s what separates a methodology from a set of good intentions.

G1

Specification-guided

No code is written without a contract and prior criteria.

How it’s verifiedEvery change references a specification with non-empty acceptance criteria.

G2

Traceable decisions

Every architecture decision leaves a trail.

How it’s verifiedOne record per decision, with its context and the discarded alternatives.

G3

Contract == code

The contract never diverges from the implementation.

How it’s verifiedThe contract is derived from the code; a mismatch fails CI.

G4

Executable acceptance

"It works" is proven, not opined.

How it’s verifiedRunnable criteria + mandatory suite: unit tests, real integration, strict typing.

G5The method’s signature

Cold-start reproducibility

Any agent picks up any work using only the artifacts.

How it’s verifiedThe cold-start test: does it implement without asking? If it asks, the contract is incomplete.

G6

The method evolves from friction

The method corrects itself.

How it’s verifiedIf the ramp-up took more than five questions, the task doesn’t close until the artifact that caused it is fixed.

How it operates

Two loops, two different cadences

Keeping them separate is what keeps the method iterative without losing upstream design. Expensive reasoning is paid once, upstream, where it produces reusable knowledge.

Macro loop

slow · strategic
  1. business need
  2. design document
  3. recorded decisions + knowledge base
  4. specs into the backlog

Micro loop

fast · iterative
  1. specification
  2. paired implementation
  3. green criteria
  4. integration

The micro loop feeds back into the macro: a task blocked by an undecided call becomes a decision record, and recurring friction fixes the artifact that caused it. It’s a closed loop, not a waterfall.

The documentation substrate

Five pillars, each externalizing a different class of memory.

  1. 1

    Diagrams as code

    The system’s visual and structural memory.

  2. 2

    Decision records

    Why the architecture is the way it is, and what got discarded.

  3. 3

    Fragmented knowledge base

    The domain and architecture, loadable in pieces.

  4. 4

    API contracts derived from code

    The interfaces between components, never written by hand.

  5. 5

    Executable specifications

    The units of work and their definition of correct.

The program

8 sessions, 16 hours, one real project

SESSION 01

Why the AI arrives cold

The technical constraint that demands a new method

SESSION 02

Anatomy of a SPEC-EXEC

The executable contract and the cold-start test

SESSION 03

From design to backlog

From the design document to actionable contracts

SESSION 04

The documentation substrate

Diagrams, decisions, and contracts derived from code

SESSION 05

Executable acceptance

Criteria the machine runs, real tests, CI

SESSION 06

Context hygiene

What the model loads on startup, and at what cost

SESSION 07

The three-step protocol

Model and effort decided task by task

SESSION 08

Operating the method

Board, work limits, and continuous improvement

Formats

How would you like to take part?

Format A

Open cohort

Who it’s for
Tech leads and architects, groups of 8–12 people
Format
Live online, 8 sessions
Project
Collaborative project management platform

USD 600 – 800 per person

For teams
Format B

In-company workshop

Who it’s for
Development teams, 6–15 people
Format
Online or in-person, 8 sessions
Project
A real deliverable from your own team

Custom quote
based on team, format, and scope

Format C

Asynchronous access

Who it’s for
Individual developers — waitlist
Format
Recordings + monthly group mentoring
Project
—

USD 250 – 350 per person

Waitlist

The first step is our positioning webinar

We don’t have a confirmed date for the first cohort yet. Leave us your details and we’ll let you know as soon as we do.

You can choose one option, or both — whatever works best for you.