A delivery model for the AI era

Drops playbook

The methodology says what and why. This playbook says how: what to set up, what to settle before the first drop. Templates and examples will follow. It changes as tools and teams change.

See the model
01

Before the first drop: prepare the terrain

The platform team (the people who build and maintain the shared AI stack) should get this ready before any crew starts.

Checklist — settle these first:
  • An environment anyone in the crew can runNot only developers: POs and designers too. Provide a setup skill (an agent instruction that clones and configures the environment) or a ready shared environment.
  • A shared preview environmentEveryone in the crew, including PO and UX, can push to it. It can show one or several versions of a solution to users, testers, stakeholders and deciders.
  • Work happens in the real repository, on a branchA prototype built outside the product code is thrown away. Built in the team repo, under the team's agent instructions, it is close to production from day one.
  • Agent instructions in every team repository(AGENTS.md or equivalent): coding standards, testing rules, links to the central architecture decisions.
  • Automated checksthat run on every change: tests, build, lint, security scans.
  • Which change types may ship without a second reviewWrite the list down (e.g. copy, UI within the design system) and the list of what always needs one (e.g. anything touching security, authentication, payments, personal data).
  • Where the decision log livesFor example, a decision log section in the drop's context.md.
  • Agreed agent skillsavailable to everyone in the crew (e.g. grilling, environment setup).
02

At the dam: the minimum for prioritisation

An idea, need or problem passes the dam only with these five fields — nothing more:

What is wanted
The idea, need or problem, in one or two sentences.
Source
User report, idea, or a finding from data?
Why it matters
Which outcome does it serve? Link to the named outcomes.
Value / risk
What do we gain if it works, and what is at risk if we do nothing?
Decider
Who will say ship, refine or stop? Are they in the crew or available?

Do not work the topic out further here. Detailed framing before the dam is a handover in disguise.

03

Inside the drop

3.1 Gather context

The crew, with AI, collects what agents need to know: systems, data, business rules, user insight, and what is missing. Output: context.md. Nobody needs to know all of it upfront; it is worked out in the first session. Sources: the codebase, existing tickets and documentation, the design system, data exports, customer feedback, earlier prototypes — and knowledge in people's heads.

3.2 Sharpen the problem

Grill the problem before solving it: is it real, what outcome do we want, how will we know it worked? A grilling skill (an agent that interviews you relentlessly, one question at a time) works well here.

3.3 Shape and build

  • Sketch a few options with AI, pick one, build it on the running application.
  • Not everyone needs to be there all the time.
  • Record decisions when they are made, with the reason, in the decision log (let AI draft it from meeting recordings and chats).
04

Architecture check: from person to agent

Start
an architect reviews the change, while written architecture decisions and automated checks are thin.
Later
once decisions are written down and checks are automated, an agent reviews the change against them and a person reads the findings.