3 min read

🚀 AI Development, Part 8: What’s Next — Scaling AI Workflows Across Teams

“This isn’t just a dev tool anymore. It’s part of how we build.”

Over the last seven posts, we’ve explored how AI tools like Cursor, when paired with a structured approach like RIPER, can transform the way we develop software.

We’ve shown how to:

  • Use Cursor like a teammate, not just a tool
  • Guide it through a structured development lifecycle
  • Avoid chaos with rule files and memory banks
  • Generate real-world code, tests, and even QA plans
  • Catch and correct hallucinations before they cause damage

But this is just the beginning.

In this final post, we’ll look ahead:
How do we scale AI-first development beyond individuals, beyond teams — and into company-wide workflows?


🧠 1. Multi-Repo Awareness Is Coming

Right now, Cursor struggles to work across repos without hacks. But multi-repo support is improving, and we’re building workflows around it.

Today:

  • You can load multiple repos into a single workspace
  • Use @repo-name/file to reference files across systems
  • Tag shared memory bank files into local repos for context

Tomorrow:

  • Cursor will support native cross-repo context management
  • Teams will be able to share structured memory across projects

✅ Use case: Letting the client repo understand the CLI via shared memory bank files — no need to duplicate code or docs.


🔁 2. Shared Memory Banks

We’re experimenting with ways to share knowledge across squads, while keeping individual workspaces clean and focused.

How we’re structuring it:

  • Core memory (e.g., systemPatterns.md, techContext.md) is shared across teams
  • Squad-specific memory (e.g., matching.md, qa-guidelines.md) scoped to feature groups
  • Planning to track memory updates like code changes — with PRs and reviews
“If it impacts how the AI thinks, it should be reviewable.”

🔗 3. External Integrations

We’ve started exploring Cursor’s external tool integrations, including:

  • GitHub PR context + activity
  • GCP logs or service descriptions
  • Confluence pages for architectural docs
  • Jira tickets for feature or bug requirements

This allows Cursor to:

  • Research tickets
  • Cross-reference implementation plans
  • Suggest links to logs or metrics
  • Pull in docs via @Docs for use in prompts
🧠 Soon, we’ll teach Cursor to build from your Jira ticket directly — not just your prompt.

📚 4. A Growing Library of Internal Best Practices

We’re creating a shared prompt and usage library, including:

  • Common /plan and /execute prompt templates
  • Examples of well-structured memory bank files
  • Tips for context scoping
  • Response review checklists
  • Debugging advice when Cursor "gets weird"

This isn’t just for new devs — it’s a living system that helps everyone level up their AI fluency.


🛡️ 5. Policies for Safe Scaling

As more devs adopt Cursor, we’re working on guidelines to ensure:

  • AI changes are always reviewed
  • Memory bank updates are versioned and peer-reviewed
  • No code goes live without human eyes
  • Everyone is trained in RIPER before using Cursor on production repos
“We want velocity, not volatility.”

📅 What’s Ahead

  • ✅ Weekly AI standups via #ai-hub Slack channel
  • ✅ Shared dashboard of successful Cursor prompts
  • ✅ Onboarding guide for new developers to use Cursor + RIPER
  • ✅ Experiments with other tools (Cody, GPT agents) for comparison

🧠 Final Thought: Build the System You Want AI to Join

Tools like Cursor are only as effective as the system they plug into. RIPER works not just because it tells the AI what to do — but because it reflects how we want to build: thoughtfully, collaboratively, and with repeatable discipline.

“AI can move fast — but we’re here to move fast without breaking things.”

This isn’t about replacing engineers.
It’s about amplifying great engineers with a system that turns AI from an autocomplete engine… into a collaborator.

Thanks for following along.

We’re just getting started.