Skip to content
Engineering Manager Handbook
Building with AI
AI-Native Engineering

AI-Native Engineering

🚧 Expanding

There’s a difference between adding an AI feature and building an AI-native system. When the model is at the core of how your product works, the whole engineering discipline shifts: behavior is probabilistic, “correct” gets fuzzy, and your hardest problems move from logic to evaluation, prompts, context, and graceful failure. This is genuinely new territory for most teams, and it leans hard on the failure modes every manager needs to understand — hallucination, drift, the confident-but-wrong answer. It’s easy to underestimate how much the surrounding system — guardrails, evals, observability — matters more than the model call itself. This page is a stub, but the through-line is that AI-native work rewards teams who treat the non-deterministic core as an engineering problem, not magic.

Getting started

The fastest way to internalize “engineering problem, not magic” is to build something with a method that forces the discipline on you — traceable requirements, decisions captured once, code written against a spec instead of a vibe. A couple of ways in:

  • BMAD 101 — a spec-first, role-based workflow where an AI agent plays each role (analyst, PM, architect, developer) with you, producing a documented artifact at every step. Our guide covers install, the agent roles, and the planning-to-implementation flow. I built this handbook and site this way, so the whole paper trail is public if you want to see it in practice.
  • GSD Core — a lighter-weight, spec-driven system that works with Claude Code and other coding agents. Instead of BMAD’s role-by-role cast, it runs a repeating loop — discuss, plan, build, verify, ship — with far less ceremony, so it’s a good fit when the full process feels like too much for the job in front of you.

Either way, the method supplies the discipline and Claude Code does the building — see Claude Code 101 for that side.

What this will eventually cover:

  • Designing for non-determinism: what changes when output isn’t guaranteed
  • Evals as a first-class discipline — how you know the system works and stays working
  • Context, retrieval, and agents as architecture, not afterthoughts
  • The new failure modes: hallucination, drift, prompt injection, runaway cost
💡
The teams that struggle with AI-native work are usually the ones who skipped building evals because “we’ll just eyeball it.” You can’t eyeball a probabilistic system at scale. The moment we invested in a real evaluation harness — before chasing model upgrades — every other decision got easier, because for the first time we could actually tell whether a change made things better or worse.

📚 Go Deeper

Courses

Tools

  • Anthropic — Building with ClaudeThe patterns that matter when a model is load-bearing — tool use, structured outputs, agents, evals. Concepts transfer across providers.
  • Anthropic — Building Effective AgentsThe essay to read on the workflow-vs-agent distinction and when *not* to build an agent. Speaks straight to treating context, retrieval, and agents as architecture.
Last updated on
Claude Code 101BMAD 101