Cursteroids
The job description you can playWe're hiring an AI Adoption Engineer. This is the job, playable.
Clear the adoption blockers real engineering orgs throw at you. Accept the Tab suggestions. Deploy agents on the toil. Keep Trust alive. If ninety seconds of this feels like your day job — good. If the role loop above sounds like what you already do informally, we should talk.
Fly with Arrow keys or WASD. Fire with Space. Press Tab to snap-fire at the suggested target (the dotted line). Press E to deploy a banked Cloud Agent charge at chore blockers. Fly alongside a "won't break" blocker to pair with and convert it. Pause with P. Pick up artifact powerups: Rules, MCP, Cloud Agent, Dashboard.
Account desk
A short ADM huddle. Pick the artifact you would ship — the coach answers like a senior on the Customer Education team.
Pilot looked good two weeks ago. Usage flatlined. Platform eng says demos feel like theater. What do you ship first?
The actual job
Credibility from what you ship alongside the team, not from what you present to them.
You work directly inside enterprise engineering teams to turn AI pilots into permanent practice.
Not as a trainer. Not as a consultant who delivers decks and leaves. You build the things that make adoption stick: the Rules libraries that encode team conventions, the prompt architectures that match how a specific codebase works, the workflow patterns that let engineers use agents without breaking what they know.
Your credibility comes from what you ship alongside the team, not from what you present to them.
Diagnose
Read the engineering org — Understand the team's stack, delivery patterns, trust level with AI, and where the gap between capability and practice is widest — through working sessions, PR history, and listening, not surveys.
Design
Build the intervention — Draft the Rules library, prompt framework, workflow template, or MCP configuration that closes the gap. Technical, specific, grounded in their codebase — not a generic best-practices doc.
Enable
Ship it with the team — Run working sessions where you build with engineers, not in front of them. By the end, the team owns what you built together.
Measure
Prove the change — Track what actually changed: PR cycle time, test coverage, agent request volume, time in context vs generating. Ground the leadership story in data, not sentiment.
Scale
Turn wins into systems — Document what worked so the customer can replicate across teams. Feed learnings into Cursor's playbook so the next engagement starts ahead.
What you build
The powerups in the game are the deliverables in the job. Events are optional. Systems other teams can reuse are the work.
Rules libraries
Team- and repo-specific .cursorrules that encode standards, review conventions, and domain context — different for a fintech monorepo vs a legacy Java codebase.
Prompt architectures
Structured frameworks for high-frequency tasks: incident investigation, PR review, test generation, architecture docs — in the team's vocabulary and toolchain.
Workflow guides
Step-by-step docs for real SDLC motions: sprint kickoffs, on-call handoffs, large refactors. Reproducible by someone who was not in the room.
Adoption dashboards
Usage reporting with eng leaders: adoption depth, agent trends, feature utilization. Used in QBRs and internal eng communications.
MCP configurations
Model Context Protocol setups connecting Cursor to knowledge bases, JIRA, internal APIs, monitoring — an AI that knows the business.
Cloud Agent workflows
Automated jobs for common work: security scans, dependency audits, docs updates, CI checks — handed off documented and running.
Enablement guides
Onboarding for eng managers rolling Cursor to new squads, built from what worked at this customer — not generic docs.
Artifact challenge
You've seen the job. Now do one rep of it. Fork Cursteroids and ship one adoption artifact sample — a Rules snippet, prompt architecture, MCP sketch, workflow guide, dashboard brief, Cloud Agent workflow, or enablement guide — that would help a real team make Cursor stick. Open a PR, or record a short Loom plus a written note on why the team would own it after you leave.
Rubric
Struggling moment
Names a real org/workflow gap, not a vague AI buzzword.
Artifact specificity
Grounded in a codebase, stack, or team convention — not a generic tip sheet.
Build-with ownership
Clear how the team would own and extend the artifact after you leave.
Measurability
Hints at what would change (habits, cycle time, usage depth) if it worked.
Shippability
Focused, typed, runnable with npm run dev — or a crisp Loom + written brief.
Where to start
Fork the repo. There's a .cursorrules at the root written as a model leave-behind artifact — study it, then ship your own: a Rules snippet, prompt architecture, MCP sketch, workflow guide, dashboard brief, Cloud Agent workflow, or enablement guide grounded in a real stack.
Open a PR, or record a short Loom plus a written note on why the team would own it after you leave.
For recruiters and hiring managers
Arcade score is not the hiring signal. Read the PR or Loom against the artifact rubric. Strong submissions look like Rules, prompts, MCP, dashboards, or workflow systems a real eng team could own — not event agendas or game reskins.
Usually senior engineers or staff-level DevEx practitioners who watched good tooling fail because nobody built the right habits around it. Practical. Earn trust by doing. Find patterns across complex systems. If the role loop above sounds like what you already do informally, we should talk.