A 3-part workshop (~35-45 min each) for entry-level to mid-career software engineers on effectively using AI coding tools. Based on the "Getting Gud at LLMs" blog series (pts 1-6) and 125+ Claude Code session logs across multiple projects.
Audience: Software engineers of any language/stack. Examples should be language-agnostic — attendees may use Python, TypeScript, Java, Go, Rust, C#, or anything else.
Source material: Blog series pts 1-6, session logs from Koupang (Rust microservices), Filament (multi-agent orchestration), Jujo (code generation), Haskell learning, and an RLedger C++ port attempt.
Demo codebases: Koupang and Filament (Rust), but demos should emphasize transferable patterns, not language-specific features.
AI automates the "plumbing" of software development. The engineer's value is in knowing which pipes to connect and where the water should flow — architecture, scope control, domain knowledge, and quality judgment.
Separate planning from execution into fresh sessions. Plan with AI, persist the plan, close the session, then execute in a new session. This prevents context bloat and improves output quality. The ratio is roughly 30% human thinking, 70% AI executing.
Project docs (CLAUDE.md or equivalent) are information caches. Without them, AI spends its first 10+ prompts re-discovering your codebase. With them, it starts productive immediately. Treat them like a cache hierarchy with eviction and invalidation.
Don't trust AI output blindly. Stack verification: your language's type checker or linter (catches type errors), your test suite (catches logic errors), and your own review (catches design errors). The more business logic encoded in types, schemas, or validation, the smaller the surface area for "runs but wrong" code.
AI accelerates output but can't replace engineering judgment. Code by hand in unfamiliar languages, read software engineering books, work on legacy codebases. Use AI as a learning accelerator — an endlessly patient tutor that gives hints without full answers.
When presenting or editing content, keep advice applicable across languages:
| Concept | Instead of saying... | Say... |
|---|---|---|
| Type safety | "Use Rust's type system" | "Use your language's type system or validation layer (TypeScript strict mode, Python type hints + mypy, Java records, Go structs)" |
| Compile checks | "Run cargo check" |
"Run your build/lint/type-check step" |
| Value objects | "Rust newtype wrappers" | "Domain types that prevent primitive obsession (branded types in TS, NewType in Python, value records in Java/C#, type aliases in Go)" |
| Pattern matching | "Exhaustive match on enums" | "Handle all cases explicitly — sealed classes, union types, or validation guards depending on your language" |
| Verification loop | "The compiler catches it" | "Your toolchain catches it — compiler, type checker, linter, or test runner" |
| Test infrastructure | "#[sqlx::test] macro" | "Your test framework's setup/teardown mechanism" |
The principle is universal: encode constraints so the machine catches mistakes before you have to. How you encode them depends on your stack.
workshop-prep.md # Full workshop plan (single file)
CLAUDE.md # This file
What changes and what doesn't. The plan-execute-review workflow. Live demo of plan mode.
Documentation as infrastructure. Defensive programming and catching AI mistakes. Live demos of doc hierarchy and supervised coding.
Growing as an engineer. Prompt skill progression. Using LLMs to learn. Skill atrophy discussion. Extended Q&A.
These insights from pt6 (Mar 2026) should be woven into the workshop:
The Filament sprint was exhilarating but led to exhaustion — "a very different kind of tiredness." Contrast with Jujo: small scope, 3 relaxed days, also shipped v1.0. Scope discipline matters more than speed. The workshop should address sustainable AI-assisted development, not just productivity.
Pt6 demonstrates Jevons Paradox concretely: 5 projects in 18 days, 87 commits. The activation energy to start new projects dropped so low that bouncing between them became natural. This reinforces the "efficiency increases consumption" framing.
Adopting TigerBeetle's TIGER_STYLE as a concrete reference for "what good code means" was a pivotal decision. Vague directions to AI produce vague code. A concrete style guide produces consistent code. This is language-agnostic — any team can write a STYLE.md.
Jujo (template-based code generation) vs. having the LLM re-read patterns and regenerate from scratch every time. Adding determinism for repetitive scaffolding is more efficient than having the AI figure it out each time. Applicable to any language's scaffolding tools (cookiecutter, yeoman, plop, etc.).
Haskell learning with strict "hints only, no full answers" mode. Pattern: try → get stuck → ask for hint → try again. An endlessly patient tutor. Also: generating custom exercises, CodeCrafters-style learning projects. This is highly relevant to the workshop audience (early-career engineers).
"The meta-cognition/meta-observation of your own thought/work processes and vigilance of how the LLM works is the biggest takeaway." Engineers who reflect on their own patterns and the AI's patterns get dramatically better results.
From ad-hoc prompting to integrated workflows: spec-driven-dev (Research → Plan → Implement with human checkpoints), skill libraries, structured review skills. The tooling around AI matters as much as the AI itself.
Claude already has worktrees and subagents that overlap with Filament's planned features. What you build today may be native tomorrow. Focus on principles (context management, verification layers, structured planning) not specific tools.
Roleplay simulations for QA (Claude pretending to be multiple agents), structured test case execution by AI. Results were mixed but valuable — found real bugs and missing features. Useful additional layer, not replacement.
- Keep the workshop plan as a single file (
workshop-prep.md) - All examples should be explainable without language-specific knowledge
- When showing code, prefer pseudocode or show equivalent snippets in 2-3 languages
- Live demos use Rust codebases but narration should explain the pattern not the syntax
- Concrete numbers add credibility — keep the appendix metrics current
- Each part should be self-contained (attendees can join any session)