AI Engineering Foundations — Teach Your Team to Actually Use the AI Tools You Already Pay For

A two-week, hands-on programme on your own codebase: spec-driven development from zero, which model and effort level for which task in Claude Code and GitHub Copilot, the folder structure that gives every tool project context, and the token maths behind the bill.

The Problem

Your engineers have Copilot, Claude, Kiro, maybe OpenAI too. Leadership has seen a dozen proofs of concept. Yet nobody can say how much faster the team actually ships, because day-to-day usage is shallow: prompts typed straight into chat with no spec, the most expensive model on every task or the cheapest one on the hard ones, effort left on the default, no repository instructions, so every tool guesses at your conventions. Measuring productivity at this stage only measures the gap in basics. Close the fundamentals first — specs, model and effort choice, context files, review habits — and the gains become real enough to measure.

What You Get

• ✓Spec-driven development from zero: why specs beat ad-hoc prompting, and the full Spec Kit flow — constitution, specify, clarify, plan, checklist, tasks, analyze, implement, converge — run on a real feature from your backlog
• ✓Kiro specs side by side with Spec Kit: requirements in EARS notation, design, tasks, and steering files — so teams on either tool follow one process
• ✓Model and effort playbook for Claude Code and GitHub Copilot: which model and which effort level for spec writing, planning, implementation, debugging, review and support work
• ✓Repository context set up for your main repos: CLAUDE.md, AGENTS.md, .github/copilot-instructions.md, path-specific instructions and Kiro steering — the single biggest lever on output quality
• ✓Token and cost basics: context windows, input vs output vs thinking tokens, prompt caching, and a cost model per feature so spend is predictable
• ✓Separate tracks for Development (C++ and Node/React), QA (specs to test cases) and Support (docs and ticket retrieval)
• ✓Recorded demo, spec templates and a written playbook your team owns
• ✓Before-and-after skills check, plus named internal champions who carry the practice after the programme ends

Where This Fits

1. 1
   Foundations

   This programme. The team learns specs, model and effort choice, context files and review habits.
2. 2
   Measure & roll out →

   Team-wide tool setup, guardrails and a productivity baseline.
3. 3
   Build →

   AI systems shipped inside your product by an embedded engineer.

Demo: One Ticket, Spec to Pull Request

A real feature taken from a one-line ticket to a reviewed pull request with Spec Kit — and the model and effort level chosen at each step, with the reason.

Recording in progress — until it is up, the same walkthrough runs live on your own codebase in the free half-day demo.

1. 0:00Install Spec Kit and run specify init --here in an existing repo
2. 1:00/speckit-constitution — the project's non-negotiables
3. 2:00/speckit-specify and /speckit-clarify on a real backlog ticket
4. 3:30/speckit-plan with Opus at high effort, /speckit-tasks
5. 5:00/speckit-implement on Sonnet at medium effort
6. 6:30/speckit-converge, review the diff, open the PR

Spec-Driven Development, From Zero

Most teams use AI coding tools by typing a one-line request into chat. That works for a small edit and falls apart for a feature: the agent guesses the requirements, picks its own architecture, and nobody can review the result against anything. Spec-driven development fixes the order of work — what and why first, then how, then tasks, then code — and keeps each step in a file that humans review and the agent implements against.

The Spec Kit flow

Install once: uv tool install specify-cli, then, inside an existing repo, specify init --here --integration claude (or copilot). The steps run inside the agent's chat, not the terminal. Copilot and Claude Code both invoke them as /speckit-specify and so on; Spec Kit's docs write the same steps as /speckit.specify.

Small features take the short path: specify → plan → tasks → implement → converge. Production features add the three quality gates (clarify, checklist, analyze).

Kiro specs, for teams on Kiro

Kiro builds the same idea into the IDE. Each spec lives in .kiro/specs/<feature>/ as requirements.md (or bugfix.md), design.md and tasks.md. Acceptance criteria use EARS notation, which keeps them testable:

WHEN an auditor exports a report for a closed period
THE SYSTEM SHALL produce a PDF signed with the firm's certificate
AND record the export in the audit log with user, time and checksum.

What a good spec contains

The Folder Structure That Gives Every Tool Context

Output quality depends less on the model than on what the model knows about your repo. These files are how you tell it — once, in version control, for every engineer and every tool.

your-repo/
├── AGENTS.md                         ← shared instructions every agent reads
├── CLAUDE.md                         ← Claude Code project memory (Copilot reads it too)
├── .specify/                         ← Spec Kit
│   ├── memory/constitution.md        ← project principles, written once
│   ├── templates/  scripts/
│   └── feature.json                  ← which feature is active
├── specs/
│   └── 001-export-audit-report/      ← one folder per feature
│       ├── spec.md                   ← what & why
│       ├── plan.md                   ← how (+ research, data model, contracts)
│       ├── tasks.md                  ← ordered work items
│       └── checklists/requirements.md
├── .claude/                          ← Claude Code
│   ├── skills/speckit-*/SKILL.md     ← Spec Kit skills (specify init --integration claude)
│   ├── agents/  commands/
│   └── settings.json                 ← permissions, hooks, per-model effort
├── .github/                          ← GitHub Copilot
│   ├── copilot-instructions.md       ← repo-wide instructions
│   ├── instructions/cpp.instructions.md   ← path-specific, applyTo: "src/**/*.cpp"
│   └── skills/speckit-*/SKILL.md     ← Spec Kit skills (specify init --integration copilot)
└── .kiro/                            ← Kiro
    ├── specs/export-audit-report/
    │   ├── requirements.md           ← user stories + EARS acceptance criteria
    │   ├── design.md
    │   └── tasks.md
    └── steering/                     ← Kiro's equivalent of instruction files

Copilot reads .github/copilot-instructions.md, path-specific .github/instructions/*.instructions.md files, the nearest AGENTS.md, and a root CLAUDE.md. Keep shared rules in AGENTS.md so a team using several tools maintains one source of truth.

Which Model and Which Effort, for Which Task

Two dials matter. The model sets the ceiling on capability and the price per token. The effort level sets how many tokens the model spends thinking, calling tools and writing — on Anthropic's current models, effort is the main control for depth and cost. The expensive mistake is running everything at one setting.

Claude Code

Switch model with /model opus, /model sonnet, /model haiku or /model fable; set effort with /effort high or claude --effort xhigh. The opusplan alias plans with Opus and implements with Sonnet — a good default for spec-driven work. Per-model effort can be pinned in .claude/settings.json under modelSettings, and a skill or subagent can set its own effort in frontmatter.

GitHub Copilot

Choose the model in the chat input's model picker; for reasoning models, the arrow next to the model name opens a Thinking Effort menu (None, Low, Medium, High). Auto lets Copilot route by task complexity — fine for everyday chat, but pin the model for spec and review work so results are repeatable. The same Claude models are available in Copilot alongside OpenAI's GPT and Codex models, Gemini and others; which ones you see depends on your plan and your organisation's policy.

Larger models use more of a Copilot plan's premium allowance, so the routing above is also a budget decision.

Effort levels explained

Rule of thumb: raise effort before switching to a bigger model, and lower it only where you have checked that quality holds.

Tokens and Cost, the Basics

• Token: the unit models read and bill in. On Claude's current tokenizer, 1M tokens is roughly 555,000 words.
• Context window: how much the model can hold at once — 1M tokens on Fable 5.1, Opus 5.5 and Sonnet 5.5; 200K on Haiku 4.5. Bigger is not free: every token in context is billed on every turn.
• Input vs output: output costs five times input on current Claude models, and thinking counts as output. That is why effort level moves the bill.
• Prompt caching: repeated context (instruction files, the spec, unchanged code) is read from cache at a fraction of the input price — 10% on most models, 5% on Opus 5.5, 2.5% on Fable 5.1.
• Batch: non-urgent jobs through the Batch API are 50% off.

Current Claude models

API list prices, last verified 29 September 2026 against Anthropic's models overview. Seat-based plans (Claude Team and Enterprise, Copilot) bill differently; the relative costs still hold.

Worked example: one feature, two ways

A mid-sized feature: about 150K input and 40K output tokens for spec, plan and tasks, then about 2M input (80% cached) and 150K output for implementation.

Illustrative list-price arithmetic that ignores cache-write surcharges. The point is the ratio: routing by task cuts the bill by roughly 4× with no loss where it matters. Across a team of 50 shipping a few features a week, that difference is a budget line.

Tracks by Function

Formats

Tech Stack

Related Work

Frequently Asked Questions

Related Engagements & Reading