The team had Cursor installed. GitHub Copilot available. Technically, everyone was using AI. The results weren't tracking.
Where the Team Was
The inconsistency had a pattern. One engineer would use AI for a complex algorithm and write all the surrounding scaffolding by hand. Another would try to generate an entire feature and get frustrated when the output went sideways mid-implementation. Nobody had a reliable approach for when to lean in, how to structure the request, or how to validate what came back.
POC results didn't transfer. People would experiment, get something interesting in one context, and it wouldn't apply to the next use case. No vocabulary. No repeatable process.
The gap was structural. Engineers weren't missing capability — they were missing a process.
The Constraints
The team couldn't be mandated into a new workflow. Cursor was already installed and people were already using it their own way — mandating a "correct" approach would have created compliance theater, not actual adoption. Engineers had years of habit built around their existing process. The methodology had to win on its own merits, which meant showing results before asking anyone to change anything. And the change couldn't require new tooling, new approvals, or new budget. Everything had to run on what was already in the environment.
What I Considered
- Leave it alone — organic adoption was already producing inconsistent results after months. It wasn't improving.
- One-time workshop on prompting — engineers remember the session, not the pattern. Doesn't transfer.
- Mandated style guide — produces compliance, not judgment. Same problem, different form.
- Structured methodology with documented POCs — the only path that gives engineers something concrete to follow and adapt, not just something to be told. The methodology had to win on its own merits before anyone changed their habits.
The decision: CursorRIPER
The approach I introduced is built around CursorRIPER — a structured AI development methodology adapted from RIPER: Research, Innovate, Plan, Execute, Review.
The five phases force discipline in the right places:
Research — understand the problem before touching code. What are the constraints? What does the existing system look like? What has been tried? Feed the AI context, don't just fire off a prompt.
Innovate — use AI as a thought partner for solution design. Explore multiple approaches. The AI will generate options you wouldn't have considered; your job is to evaluate them against the actual constraints.
Plan — structure the implementation before executing. Write out the approach. Have the AI review it. Catch design problems here, not mid-implementation.
Execute — implement with AI in the loop. Break the work into pieces. Validate each piece before moving forward. Don't paste 500 lines and hope.
Review — validate, test, refine. The AI helps here too — reviewing its own output, suggesting edge cases, checking against the original plan.
The framework isn't magic. What it does is give engineers a repeatable process instead of hoping the AI delivers on the first try. Most AI disappointment comes from under-structured prompting and no validation loop. RIPER fixes both.
Driving Adoption
The approach to rollout was deliberate: tech talks first, then POCs across concrete use cases.
The talks covered both the methodology and specific walkthroughs. Not abstract theory — actual case studies with before/after comparisons. Engineers respond to specifics. Showing a class-to-functional component refactoring done with CursorRIPER in two hours instead of two days is more persuasive than any slide about "AI-assisted development."
We ran POCs across four domains:
- General AI-driven development with CursorRIPER — the baseline methodology applied to a standard feature build
- Class-to-functional component refactoring in React — a high-volume maintenance task that benefited immediately from AI automation under a structured process
- Email test and preview feature — a new feature built end-to-end with CursorRIPER phases explicit throughout
- CapBot — a Slack-JIRA integration built for the internal hackathon under time pressure
Each POC was documented. Not in a slide deck — as actual case studies that engineers could follow, replicate, and adapt. The goal was to build a library of proof, not a pitch deck.
CodeRabbit landed during this period too. AI code review rolled out across all Engage UI repos. Configuration guidance, review standards, getting engineers used to AI feedback in their normal PR workflow. It's a lower-friction entry point than changing how you write code — you're just changing what reviews you.
On the operations side: Perplexity and Cursor for the NFS module handover — NFS (Node File Service) is an internal shared service with substantial undocumented surface area. AI-assisted onboarding: generating structured documentation, architecture visuals, integration pattern analysis. Shared the approach org-wide because the same pattern applies anywhere you're trying to understand an unfamiliar system quickly.
What the Framework Cost
CursorRIPER adds phases you have to move through. On a small bug fix or a trivial config change, the RESEARCH and PLAN phases feel like friction — you know what you're doing, and you don't want to write a plan for a two-line change. The engineers who struggled with adoption were often dealing with this: the structure that helps on complex work slows you down on simple work, and knowing when to apply it fully vs. when to skip phases requires judgment the framework itself doesn't give you.
The gains are real, but they're team averages across varied tasks. For tasks well-suited to AI collaboration — architecture exploration, refactoring, boilerplate generation — the gains are higher. For tasks that are fundamentally about judgment and context that AI doesn't have — debugging obscure production issues, navigating org-specific legacy code, making calls that require knowing why something was built the way it was — the gains are smaller or negative if you apply the framework too rigidly.
The Signal That Mattered
There's a metric for adoption that doesn't show up in dashboards: when someone else starts evangelizing.
Akshay Ash — a senior frontend engineer on the Engage UI team — independently published his own CursorRIPER case study. Unsolicited. His own framing, his own use case, his own documentation of how the methodology played out for him.
That's not compliance. That's adoption. When the framework stops being "what Harish introduced" and becomes "how we work," the methodology has crossed over. Akshay's case study is that signal.
That moment matters more than any metric I could report. It means the approach is replicable, not just applicable. Other engineers can take it, apply it to their specific context, and produce something worth writing down. That's a methodology. Anything less is a memo.
Outcome
~70% reduction in dev efforts across structured CursorRIPER POC tasks — team-reported, measured against baseline effort estimates from the same engineers before the methodology was introduced. This isn't engineers working fewer hours — it's engineers not spending hours on boilerplate, repetitive implementation, and first-draft code that needs to be thrown away. That time goes into earlier design review, tighter problem framing, and the decisions that require judgment the AI doesn't have.
Improved code quality. The PLAN phase started catching architectural problems before two days of implementation got sunk in the wrong direction — fewer abandoned branches, fewer mid-sprint pivots. CodeRabbit in the review loop means reviewers are spending time on logic, not style.
Improved design quality. The INNOVATE phase forces design thinking before execution. Less mid-implementation discovery of "this architecture doesn't work."
Time shifted toward feature enhancement. Engineers spending time refining and extending features instead of building them from scratch. The engineer's contribution moves to problem framing, constraint identification, and the final judgment on what ships.
CapBot as proof. The internal hackathon was 42 hours, team of four. We built a Slack-JIRA integration, got third prize, and did it with AI-generated code as the primary output. That's not what you produce by hoping for autocomplete suggestions. That's what you produce when you have a structured process for AI collaboration under time pressure.
What Changed
The productivity numbers are real, but they're not the thing worth writing down. What actually changed is how engineers on the team think about their own role. When AI handles first-draft generation, boilerplate, and initial review, the engineer's contribution has to be somewhere else — in the problem framing, the constraint identification, the evaluation of options, the final judgment on what ships.
The ones adapting fastest are already questioning whether lines-of-code-per-day was the right measure. CursorRIPER gave that instinct a repeatable shape.
We're still inside this. The methodology is working. The question for the rest of the year is how it compounds — whether the engineers who adopted it first are visibly leveling up in ways that pull others forward. That's the signal I'm watching.