AI Playbook · as of late 2026

Today we architect more than we type

Coding agents now write much of the first draft of code at many companies. The engineers who stand out decide what to build, design how it fits together, give the agent sharp context, and catch its mistakes. To do that you have to understand the fundamentals, which is why the roadmaps make you build by hand first.

Part 1 · While you're learning

Use AI as a tutor, not a ghostwriter

During Sprint Zero and "Learn by building", you're building understanding. AI can make that faster, or it can quietly skip it for you.

Use AI freely for

  • Explaining a concept, an error message or someone else's code, then asking follow-up 'why' questions
  • Quizzing you: 'ask me 5 questions on what I just learned'
  • Reviewing code you wrote: bugs, edge cases, security holes
  • Boilerplate you already understand (config files, repetitive types, test data)
  • Brainstorming edge cases and failure modes for your design

Use carefully

  • Writing code for a concept you're learning: write it yourself first, then compare with the AI's version
  • Choosing libraries: AI may suggest outdated packages, so check the docs and the last release date
  • Facts and numbers: verify anything you'll put in a README, resume or memo

Don't use AI for

  • Code you can't explain line by line. If you can't explain it, you don't own it, and interviews will show it
  • Skipping the struggle. The 20 minutes you spend stuck is when learning happens
  • Deciding what to build or what your analysis concludes. That judgement is your job
  • Pasting secrets, API keys, or private user data into chats
Type the first version yourself. Delegate the second. Review every one.
Part 2 · Once you know the pieces

The architect's loop

This is how strong engineers work with agents: think first, delegate in slices, verify everything.

FrameWho, what problem, what number moves
ConstrainScale, cost, privacy, devices
SketchBoxes and arrows, 5 max
ContractData model and API shapes
SliceSmall vertical pieces
PromptOne slice, full context
ReviewRead every diff
VerifyRun it, test it, eval it
Spec Studio · interactive

Write a real spec, step by step

Fill in each step for your own feature or project. It builds a SPEC.md you can drop into your repo and hand to any coding agent. Your work is saved in this browser.

0/6 steps written

1. Frame the problem

Who is this for, what problem does it solve, and how will you measure success?

Tip: Use a number for success. 'Users like it' isn't measurable.

Prompt Lab

Same request, two prompts, very different results

A good prompt to a coding agent reads like a ticket from a great tech lead: context, one goal, constraints, acceptance criteria and a process. Compare them below.

make a khata app with login and reminders, make it good
What usually happens:
• The agent picks its own stack, folder layout and database.
• It invents features you didn't ask for and skips the ones you needed.
• 1,500 lines arrive at once, too big to review properly.
• Auth is half-done, and every shop can see every other shop's customers.
• You spend the next two days untangling it.
ContextWhat the project is, the stack, and the relevant files. Agents don't know what you know.Next.js 16 app, Postgres via Drizzle. Spec is in SPEC.md. Relevant: src/db/schema.ts, src/app/api/entries/route.ts.
GoalOne slice, stated as an outcome.Implement slice 2: recording a credit entry updates the customer's balance.
ConstraintsWhat not to do. This prevents scope creep.Don't change the schema. Don't add dependencies. Amounts are integers in paise.
Acceptance criteriaHow both of you will know it's done.POST returns 201; balance query reflects it; a test covers a cross-shop access attempt returning 404.
ProcessMake it plan first, so you can catch bad plans cheaply.First list the files you'll change and your approach, and wait for my OK. Ask if anything is ambiguous.
Before you accept any AI change

The reviewer's checklist

Being fast is good. Being the one who catches the bug before it ships is better.

  • Does the diff only touch what the slice needed?
  • Can I explain every line? (If not: ask, then decide)
  • Are inputs validated and errors handled, not swallowed?
  • Does every data query respect who's asking (auth / tenant)?
  • Are there tests or evals, and do they test the risky part?
  • Any new dependency? Is it maintained and actually needed?
  • Secrets, keys, personal data: nothing hard-coded or logged?

Give your agent a memory: the rules file

Put an AGENTS.md (or CLAUDE.md) at your repo root: the stack, folder layout, commands to run tests and lint, naming conventions, and a "never do" list. Agents read it on every task. Keep it under a page and update it whenever you correct the same mistake twice.