Why Code-First Beats Slide-First

A slide-heavy workshop produces engineers who know more without doing more. The vocabulary improves. The behaviour does not. A code-first session ends every day with something running, owned by the team, in their repo. That difference compounds over the weeks that follow because the next AI feature on the roadmap has a starting point that already works.

• Lectures retain 5-10% of material at four weeks; pair work retains 60-70% at the same horizon
• Working in the team's own repo removes the translation tax: patterns are immediately applicable
• Real data exposes real problems: chunking that breaks, embeddings that mis-cluster, tools that hallucinate arguments
• CI integration during the workshop forces the patterns to survive the team's actual quality gates
• Code review as part of the engagement: the facilitator reviews the team's in-progress AI work, not just teaching new material
• Working artifact at the end of each day: never close a session without something visibly improving
• Architecture rationale documented in writing: the patterns picked, the patterns rejected, and why, so the choices are durable

What an Engineering Team Training Engagement Covers

The engagement is built around the team's next AI feature or platform decision. The discovery call maps the bottleneck. The training compresses the architecture work and the implementation patterns into a focused window. The team leaves with the feature partially or fully working.

• Working in the team's own codebase and stack: Python or TypeScript, their framework, their database, their hosting
• Hands-on agent build with real data: a feature shipped against production-realistic inputs, not toy datasets
• Production patterns: evaluation, observability, retries, durability, cost and latency budgets
• Integration with existing tools and CI: the patterns ship through the team's actual quality gates
• Code review of the team's in-progress AI work: separate from the labs, focused on existing work the team has been stuck on
• Reference repository the team owns going forward: clean, documented, lifted into production with minor cleanup
• Architecture decision record: written rationale for every pattern picked, so the work survives team turnover
• Cost and latency profiling: the patterns chosen have an honest unit economics story, not a back-of-envelope guess

Curriculum Modules Tailored to the Team

The catalog below is the set of modules engineering teams pick from in 2026. A two- or three-day engagement selects four to seven and arranges them around the team's shipping target. The selection is driven by where the team is: pre-production teams need foundations and patterns, production teams need evaluation and observability, platform teams need orchestration and MCP.

• LLM application foundations: prompting, structured outputs, function calling, model selection, cost and latency budgets
• Retrieval-augmented generation: chunking, embeddings, vector stores (pgvector, Pinecone, Weaviate, Turbopuffer), hybrid search, reranking
• Agent architecture: ReAct, Plan-and-Execute, supervisor, swarm, with a strong opinion on when to use each
• Tool use and Model Context Protocol: writing MCP servers, exposing internal APIs as tools, schema design, error message design
• Memory: short-term scratchpads, long-term episodic and semantic stores, LangMem, Mem0, Zep, Letta
• Evaluation: trajectory-level eval, LLM-as-judge with rubrics, golden test sets, LangSmith, Langfuse, Braintrust, Arize Phoenix
• Observability: trace structure, prompt versioning, the debug workflow for a failed agent run in production
• Recovery and durability: idempotent tool design, retries, budgets, human-in-the-loop checkpoints, Temporal or Restate for durable execution
• Cost and latency engineering: prompt caching, streaming, batching, smaller-model routing, the architecture choices that bring an agent from cents to fractions of a cent
• Safety and guardrails: input sanitization, prompt injection defense, output validation

Format Options for Engineering Teams

Engineering team training is normally one to three days. Longer than that, the team's shipping work starts to compete for attention. Shorter than that, the labs do not reach a working artifact.

• One-day intensive: foundations plus one focused build (RAG service, simple agent, eval harness). Best for teams that have shipped LLM features already and need to lift one specific capability
• Two-day deep dive: foundations, full agent build with tool use and memory, evaluation, and observability. Most common shape
• Three-day intensive: includes orchestration, multi-agent patterns where justified, MCP integration, durability, and a working CI integration
• Four-to-five-day cohort: full agent platform build, only justified when the team is being formed from scratch or pivoting hard into AI
• On-site: high-bandwidth pair work, the right call when the team is co-located and the budget supports travel
• Remote: works well for distributed teams already on Zoom or Slack discipline, lower cost, easier to schedule
• Hybrid (live blocks plus async): rare for engineering team training, better suited to multi-week corporate cohorts

Audience and Prerequisites

The room should be a single engineering team plus their tech lead and engineering manager. Mixing in PMs or non-engineering staff dilutes the labs. The team needs a baseline of production engineering skill; no prior LLM experience is required.

• Engineers and tech leads who have shipped at least one production service in Python or TypeScript
• Engineering managers welcome for the architecture and cost sessions, optional for the deeper labs
• Staff and principal engineers: invaluable for the architecture decision conversations, the room is sharper with them in it
• Cohort size: 6-12 engineers is the sweet spot. 4-5 works but limits the breadth of pair discussion. Above 15, the facilitator cannot pair-work effectively
• Required setup before day one: dev environment running, repo cloned, API keys provisioned, sample data accessible, network access to the chosen LLM providers
• Recommended pre-reading: Anthropic's "Building Effective Agents," OpenAI's Agents SDK docs, and the team's own AI roadmap document if one exists
• No prior LLM experience required: foundations are part of every engagement, calibrated to the room

Deliverables the Team Keeps

These are the artifacts that survive past the workshop. The team owns them, uses them, and extends them. Without them, the engagement is a TED talk billed at $20K+.

• Reference repository: every lab's code, organized so patterns can be lifted directly into production
• Architecture decision record (ADR): written rationale for every pattern picked, so the choices survive turnover
• Evaluation harness: configured against the team's data, ready to extend with new cases
• Observability hooks: traces, spans, prompt versioning, working against the team's existing observability stack
• CI integration: at least one AI quality gate wired into the team's actual CI
• Session recordings: useful for absent team members and for replay in the first weeks of application
• Follow-up Q&A: a scheduled 60-90 minute session 2-3 weeks after the workshop, to clear blockers
• Optional retainer: monthly hours for the months after, used for code review and architectural sanity checks as needed

Pricing for Engineering Team Training

Pricing for code-first engineering team training has firmed up as senior practitioners moved into independent training. The market price for a senior facilitator who customizes against the team's actual codebase is materially higher than catalog bootcamp pricing because the engineering and customization happen before the room ever opens.

• One-day intensive: $10,000-$20,000, includes discovery call, custom labs, reference repo
• Two-day deep dive: $20,000-$35,000, includes follow-up session, 30 days of async Q&A
• Three-day intensive: $30,000-$50,000, the most common shape for engineering teams of 6-15
• Four-to-five-day cohort: $50,000-$120,000, includes a capstone and a written architecture document
• Add-ons: on-site travel pass-through, region-specific delivery, longer post-workshop retainer, code review hours by senior engineers
• What drives the upper end: customization depth, code review scope, post-workshop retainer commitment, on-site travel, larger team sizes
• What drives the lower end: pure remote, fixed-syllabus delivery (avoid this), no post-workshop check-in
• Red flags: per-seat pricing on a code-first engagement (the value is the room, not the seat), fixed syllabi labeled as "custom," and any provider who quotes without a discovery call

How to Brief and Procure

A discovery call is the gate. A facilitator who books an engineering team training engagement without one is selling a fixed syllabus. The brief below is the working set of inputs a senior practitioner needs to design a workshop that earns its fee.

• Team shape: roles, headcount, seniority, geography, who must attend
• Current stack: language, framework, hosting, current LLM exposure, current eval and observability tooling
• The bottleneck: the one feature or capability the team is stuck on or about to start
• Constraints: privacy, regulated data, on-prem only, model approval lists, vendor relationships
• Timeline: when is the workshop, when is the work it unblocks supposed to ship
• Success criteria: what the team should be doing in the four weeks after the workshop that they cannot do today
• Budget envelope: an approximate range lets the facilitator scope the right depth and format
• Decision rights: who signs the SOW, who approves the syllabus, who hosts the room

Common Mistakes Engineering Leaders Make

Most engineering team training engagements that fail are diagnosable in the first 60 days. The patterns repeat across the directors who book this engagement.

• Bought a bootcamp instead of training: a generic syllabus on a shared cohort does not transfer to the team's stack
• Skipped the discovery call: the facilitator showed up with the same labs they ran for the previous client, fit was poor
• Mixed audience: PMs and engineers in the same room, neither got what they needed
• No working artifact at the end: the team learned vocabulary but did not finish anything, so nothing carries into Monday
• Wrong timing: the workshop ran a quarter before the team needed to ship, the patterns went stale before application
• No follow-up: the workshop ended, the facilitator disappeared, the team got stuck on the first real problem and reverted to their old patterns
• Scope creep into management training: the engineering team needs code, not strategy. Strategy belongs in a separate executive session
• Picked the cheapest provider: training is one of the highest-leverage spends in an engineering org, and the cheap option is invariably the most expensive in opportunity cost

FAQ