imagile
You've Already Stopped Reading Your Permission Prompts
Anthropic's own telemetry shows people approve 93% of permission prompts — that's not caution, it's a reflex, and the fix is a policy you set before you're tired.
For engineering leaders
Train engineers to build with AI — judgment, not tool tutorials.
Anyone can demo Claude Code, Codex, or Copilot in a lunch-and-learn. The harder job is teaching a team when to trust the suggestion, when to stop and read the diff, and how review discipline has to change once the code is drafted in seconds instead of hours.
Who this is for
Three people who bring me in
The engineering director rolling out a coding assistant org-wide
Claude Code, Codex, or Copilot is already approved and already installed. What's missing is a shared standard for how the team uses it — so ten engineers don't invent ten different habits, half of them bad.
The team lead protecting code review discipline
Velocity went up the week AI-assisted code showed up in pull requests. So did the temptation to rubber-stamp it. This person wants the speed without losing the review culture that catches the expensive mistakes.
The CTO who needs a permission policy, not a vibe
Model harness tools can read files, run commands, and open pull requests on their own. Someone has to decide — in writing — what an agent is allowed to touch unattended and what still needs a human in the loop.
What happens
A workshop or cohort, on-site or remote — equally first-class
Format is a half-day or full-day workshop for a single team, or a 4-week cohort for teams that want the habits to actually stick past the training day. I run this on-site in Central Ohio, or remote to a distributed team over video and a shared repo — remote is not a fallback version of the in-person session, it's the same curriculum, the same live coding, the same Q&A, priced the same.
The work is hands-on, not a slide deck. We work through real pull requests — yours, if you can share them, or representative ones if you can't — and build the muscle for reading an AI-drafted diff the way you'd read a junior engineer's: fast where it's boilerplate, slow where it touches anything that can fail quietly. We talk through what a permission prompt is actually protecting you from, and where teams get burned by clicking through it out of habit.
Cohorts add spaced repetition: a kickoff session, two working sessions with real assignments in between, and a wrap session where the team codifies what worked into something the next new hire can read instead of re-learning by trial and error.
What you walk away with
Artifacts, not vibes
-
A trained team
Every engineer who sat through it has actually driven the tools on real code, not watched a demo.
-
A written permission-policy playbook
What an agent can do unattended, what needs a human to approve first, and why — specific to your stack, not a generic checklist.
-
Review-discipline habits that hold under speed
A shared standard for what "reviewed" means when the diff took thirty seconds to generate instead of thirty minutes.
How pricing works
Flat fees, quoted before anything starts
| Engagement | What it is | How it's priced |
|---|---|---|
| AI Transformation Strategy | A focused session + written recommendation, credited toward what comes next | Flat fee, credited forward |
| Half-day workshop | Up to 12 developers, single focused topic | Flat fee per session |
| Full-day workshop | Up to 12 developers, full workflow arc | Flat fee per session |
| 4-week enablement cohort | Up to 12 developers, habits that outlast the training | Flat fee, scoped to team size |
Most engagements start with a short AI transformation strategy session — a focused conversation and a written recommendation, credited toward whatever comes next. Every format is a flat fee agreed before the first session — remote is priced the same as on-site work, on-site carries a day-rate premium plus travel at cost, and nothing turns into a surprise change order later. Tell me the team and the format and you'll get the number in writing.