Getting started¶
This framework is a set of decisions, practices, and templates for running AI-assisted software development at an organization. It is:
- Vendor-neutral. Works with GitHub Copilot, Cursor, Claude Code, Windsurf, Cody, Amazon Q, self-hosted models, or any combination.
- Size-agnostic. Sized guidance from a 5-person startup to a 50,000-person bank.
- Publicly sourced. Every quantitative claim links to a public URL.
- Artifact-first. Every practice ships a template you can use on Monday morning.
The 30-minute version¶
If you read nothing else
- AI coding assistants ship a productivity gain on greenfield tasks and a code-quality tax on brownfield ones. Net outcome depends on governance.
- Running without a written Acceptable Use Policy, incident playbook, and vendor approval list is the single biggest adoption risk.
- The right metrics are SPACE + DORA at the team level, not Copilot acceptance rate.
- Start with a scoped pilot (one squad, 90 days, explicit success criteria), not a company-wide rollout.
- Document decisions with rationale, not just choices. Leaders rotate.
What "vibe coding" means here¶
"Vibe coding" is shorthand for directing AI tools to produce code from natural-language intent, at any scale from a function to a full application. The term was popularised by Andrej Karpathy in early 2025, describing exploratory, throwaway use1. This framework applies the term more broadly to all AI-assisted software work where a human directs an AI model to produce executable artifacts, and where the output is intended to reach production.
The distinction matters: Karpathy's original sense described code you'd never ship. This framework exists because organisations are shipping it.
Five moves in your first week¶
| Day | Move | Worksheet |
|---|---|---|
| 1 | Hold a leadership-charter meeting; decide whether to proceed and under what conditions. | Leadership charter |
| 2 | Publish an interim Acceptable Use Policy (one page). | AUP drafting |
| 3 | Classify your workloads by risk. | Risk classification workshop |
| 4 | Pick a pilot scope and team. | Pilot scope |
| 5 | Baseline your current DORA and SPACE metrics. | Metrics baselining |
None of these moves commits you to adoption. They commit you to knowing what you'd do if you adopted. That's the point of Phase 0.
The rest of the site at a glance¶
-
Adoption Roadmap Phase 0 through Phase 3, with exit criteria.
-
Worksheets One meeting, one worksheet, one decision record.
-
Governance Policies, RACI, vendor strategy, regulatory crosswalks.
-
Frameworks Eight named practices (S.C.A.F.F., V.E.R.I.F.Y., ...).
-
Measurement What actually correlates with good outcomes.
-
Evidence Public studies, named rollouts, documented incidents.
What this framework is not¶
- Not a vendor comparison. We cite tools by name where useful but do not rank them.
- Not a model-training guide. If you are training your own code model, this framework is about how teams use it, not how you build it.
- Not legal advice. The regulatory mapping is a starting point for a conversation with your counsel, not a substitute for it.
- Not a productivity-gain promise. We quote both the positive and the negative studies. What outcome you get depends on how you govern the work.
Next¶
- Who is this framework for?: find your role's starting path.
- Philosophy: the seven principles.
- Adoption roadmap: if you're ready to plan.