AI-Native Engineering Canvas.
A workshop template for designing how your team adopts AI-native engineering: an operating model, not a tool checklist. Together the eight areas describe the harness your team builds around its agents, the context, tools, checks, and feedback loops that make AI-assisted work safe and fast.
Download printable PDF?How to use this canvas
Export this page to PDF or screenshot it into Miro, or just print it. Then go area by area and answer the prompts together, using sticky notes for what is already in place and what is still missing. Around 60 to 90 minutes the first time; much shorter on later passes.
It also works async: drop it in a repo doc or a Slack thread, let everyone annotate on their own time, then meet only to resolve the points you disagree on. The value is the shared vocabulary and the disagreements it surfaces, not the meeting itself.
What do we actually walk away with?
A short list of decisions and open disagreements, not a poster. The real output belongs in the codebase: agreed conventions go into AGENTS.md or tool configs, specs into your specs folder, and every unresolved point becomes a ticket.
When do we use it: start, or mid-project?
Both. Run it once when a project starts, to get aligned before habits set. Then revisit it lightly every few months, or whenever something changes: a new model generation, a practice that didn’t work out, a tool you dropped. It’s a checkpoint triggered by change, not a calendar ritual.
Isn’t this just deciding everything upfront?
Only if you fill it with wishes. Answer only from what you already do; leave everything else blank. A blank is signal, not failure. It marks something the team hasn’t figured out yet and should stay open. You’re describing reality and finding its gaps, not committing to a plan.
Is this overkill for a senior team?
It can be. If practices already surface cleanly in standups and PR reviews, you may not need this at all. It earns its keep when seniority is mixed, or when strong opinions collide in a field with no historical baseline. AI-native work has plenty of those grey areas, and this makes the implicit choices explicit before they harden into arbitrary rules.
The team, system, and constraints, and why we're going AI-native.
Where agents help today, and where they don't yet.
Who owns intent, review, and production outcomes.
What agents need to know, and how we write intent before implementation.
The agents, MCP servers, CLIs, and skills we trust.
How we prove work is correct and get it to production safely.
The boundaries that keep tools safe.
How we know it's working, and how the system improves after every change.
The canvas asks the questions.The book answers them.
This canvas is a map of the choices your team has to make. The book is where each one gets worked out in full, with the practices, trade-offs, and examples behind it.
- Context engineering
- Spec-driven development
- Agent orchestration
- Verification & quality gates
- Scaling AI in teams