AI Writes the Code, AI Reviews It: What's Happening at Money Forward (1,000 Users) and PlanetScale (2 FTE Saved)

“Composer 2 turned out to be Kimi K2.5.” On March 22, 2026, the day that TechCrunch article dropped, I happened to be reading a piece of primary data.

It was a report from PlanetScale, an overseas database SaaS company, published on Cursor’s official blog.

“Code has become cheap. The bottleneck is now whether your code is correct and whether you understand what it does.”

That single sentence captures, more cleanly than anything else I’ve read, the way the vibe coding phase (the style of writing code in dialogue with AI) has shifted.

“Writing fast” — done. The next question is “Can you trust it to ship?”

In this piece, including the controversy around the Composer 2 release, I want to unpack the substance of that shift using data. Primary-source numbers from PlanetScale and Money Forward, plus practical design patterns for rolling this out to a team.

---

Where Bugbot Stands Now — 76% Resolution Rate, 2M PRs/Month

Cursor Bugbot is an AI agent (an autonomous AI program) that automatically reviews pull requests (PRs: proposed code changes) to detect and fix bugs.

Take a look at the numbers for the current version, which became generally available on February 25, 2026.

• Resolution rate: 76% (up from an initial 52%, after 40 rounds of improvement experiments)
• Monthly throughput: 2 million pull requests per month
• Auto-merge rate: 35% of Autofix suggestions are merged straight into the base branch

Bug detection volume is roughly double the previous version. A 35% auto-merge rate means “humans are adopting AI-fixed code essentially as-is.”

Pricing is $40/user/month (separate from Cursor itself), with a pool of 200 PRs/user/month. Enterprise plans with unlimited usage are also available.

Rippling, Discord, Samsara, and Airtable are among the companies already using it. A University of Chicago study found that companies setting Bugbot as their default reviewer saw a 39% increase in PR merge volume.

For teams stuck on “review is the bottleneck, that’s why we’re slow,” Bugbot is becoming a structural answer.

# Example: configuring Bugbot as the default GitHub reviewer
# .cursor/bugbot.yaml

bugbot:
  default_reviewer: true   # Automatically add Bugbot to every PR
  autofix: true            # Auto-create Autofix PRs for fixable bugs
  severity_threshold: medium  # Report medium severity and above (skip lower)
  languages:               # Explicitly list target languages
    - typescript
    - python
    - ruby

---

The PlanetScale Testimony — What “2 FTE Saved” Actually Means

PlanetScale provides a MySQL-compatible cloud database, with major customers including GitHub and Stripe.

Here are the numbers they reported as a Cursor official blog case study after adopting Bugbot. Given that this was published on a vendor-controlled channel, you should note that the framing is favorable to the company. That said, both PlanetScale and Money Forward are speaking under their own names, and falsifying numbers would directly damage corporate credibility — so I’d assign these figures a reasonable degree of trust as reference data.

• 80% of Bugbot comments are resolved before merge
• Code review workload reduced by the equivalent of 2 FTE

FTE (Full-Time Equivalent) is a unit where one full-time employee’s workload equals 1 FTE. The calculation says Bugbot is absorbing the code review workload of two full-time employees.

Why such a dramatic effect? The backdrop is the explosive growth in the volume of code that AI agents are now writing.

When code was growing at the pace humans could write it, human reviewers could just barely keep up. With AI writing at 10x speed or more, exceeding reviewer capacity was only a matter of time.

This is what “code has become cheap” means. The cost of production fell while the cost of quality assurance rose in relative terms. PlanetScale faced exactly this problem, and Bugbot is functioning as the solution.

There’s another point worth flagging: the question of “whether code is correct.” Code mass-produced by vibe coding may work but be precarious. A March 2026 report by Sia Partners (a strategy consulting firm) notes that while AI coding has rapidly accelerated speed, “the value organizations can capture has not kept pace.” They call this the “productivity paradox.”

By detecting and fixing 76% of bugs, Bugbot is playing the role of closing this “captured-value gap.”

# Examples of actual Bugbot review comments (from Cursor's official blog)
# PR: Refactoring user authentication

# Examples of Bugbot's flags:
# 🔴 High severity: SQL injection vulnerability
#    Line 42: f"SELECT * FROM users WHERE id = {user_id}"
#    Fix: Use placeholders
#    ↓
#    cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))

# 🟡 Medium severity: Unhandled exception
#    Line 67: No error handling on the return value of db.connect()
#    Fix: Wrap in try/except and log appropriately

# When Autofix is applicable, a PR is created automatically

---

Why 1,000 People at Money Forward Use It — Spreading Beyond Engineering

The Money Forward data shows a different angle.

According to a report from the company’s MEPAR (Money Forward Engineering Productivity & AI Research) division, over 1,000 people are currently using Cursor every day. What’s striking is the breakdown: usage has spread beyond engineers to PMs (product managers), designers, and QA (quality assurance staff).

The quantitative effects look like this.

• Engineers save 15–20 hours per week
• QA team test case generation time reduced by 70%

15–20 hours per week is about 40% of the standard working week. The math says nearly half of one’s time is freed up for other work.

The reason Money Forward officially cites for choosing Cursor is “model-agnostic infrastructure.” Because the architecture doesn’t depend on any specific AI model, even when a model update like Composer 2 lands, they can migrate without changing their workflows.

What hit me personally was the spread beyond engineering. Coming from a CS (customer success) background myself, the fact that “the tool transcended engineering’s domain” signals an organizational shift. When PMs and QA get closer to the code, misalignment with engineers shrinks. The team’s overall sensitivity to quality rises.

The definition of “someone who can automate their own job” is changing.

---

Reading the Composer 2 Controversy — The Real Issue Is Transparency

Composer 2, released on March 19, 2026, came with significant architectural changes.

The main specs:

• Base model: Moonshot AI’s Kimi K2.5 (an open-source AI model whose internals anyone can inspect)
• Context length: 200,000 tokens (capable of processing roughly 150,000 characters of context at once)
• Pricing: Standard $0.50/M tokens — 86% cheaper than Composer 1.5
• Benchmarks: Beats Claude Opus 4.6 on Terminal-Bench 2.0

The problem: Cursor initially did not disclose that the base model was Kimi K2.5.

On March 22, TechCrunch published “Cursor admits its new coding model was built on top of Moonshot AI’s Kimi,” and the controversy ignited. Cursor subsequently acknowledged the facts and added that “approximately 75% of the compute spent on continued pre-training and RL was on Cursor’s side.”

My read is that this isn’t “fraud” — it’s “a failure of explanation.” It’s true they didn’t build it from scratch, but it’s also true that Cursor’s proprietary tuning produces meaningful performance gains. Companies retraining open-source models in-house is a common approach these days, and industry norms haven’t yet settled on how much transparency is required.

There’s a practical lesson here: judging on performance rather than provenance is the pragmatic move.

# Composer 2 pricing comparison (as of March 2026)

# Standard mode
# Input: $0.50/M tokens
# Output: $2.50/M tokens
# Use: Draft generation, bulk text processing

# Fast mode
# Input: $1.50/M tokens
# Output: $7.50/M tokens
# Use: Complex multi-file edits, scenarios requiring real-time response

# Composer 1.5 → 2 changes
# Cost: -86% (Standard comparison)
# Context: 100K → 200K tokens
# Benchmarks: Major improvement on SWE-bench Multilingual

---

A Full-Stack Design: Automations × Bugbot

“Automations,” included in Cursor v2.6 released on March 3, 2026, shows its true value in combination with Bugbot.

Automations is a mechanism that auto-triggers Cursor agents based on events from Slack, Linear (project management tool), GitHub, PagerDuty (incident management tool), and others. The shorthand is “code review pipeline automation.”

The actual flow looks like this:

1. A PR is created on GitHub
2. Automations triggers and launches a Cursor agent
3. The agent analyzes the code and hands it off to Bugbot for review
4. Bugbot auto-resolves 76% of issues and creates an Autofix PR
5. Humans review only the remaining 24%

Once this flow is running, the area where humans need to focus shifts from “all reviews” to “the 24% that requires complex judgment.” For teams operating at scale, that shift is significant.

When I actually tried it, the time to first review on a PR was cut roughly in half by feel. Because Bugbot has already flagged the obvious errors, human review consolidates into “verification and design discussion.”

# Example .cursor/automations.yaml (for team rollouts)
automations:
  - name: pr-review-pipeline
    trigger:
      event: github.pull_request.opened    # When a PR is created
      filter: "draft: false"               # Exclude draft PRs
    steps:
      - agent: code-review
        action: analyze_changes            # Analyze the diff
        options:
          check_security: true             # Enable security vulnerability checks
          check_performance: true          # Check for performance issues
      - agent: bugbot
        action: scan_and_fix              # Bug scan + Autofix
      - notify:
          channel: slack                   # Send result to Slack
          template: "bugbot-summary"       # Use the summary template

“You can configure all that?” — some readers might be thinking that. I was half-skeptical myself at first. But looking at the Money Forward and PlanetScale results, it’s clear this isn’t pie in the sky. The bigger the team, the bigger the payoff from this flow.

---

Three Principles for Designing the “Quality Assurance Phase”

For the practical section, here are three principles for moving vibe coding from the “writing fast phase” to the “trust it to ship phase.”

Principle 1: Design Human Review as Exception Handling

Bugbot’s Autofix rate is 35%. In other words, the remaining 65% needs human judgment. Trying to hand everything to AI is where you’ll stumble — exactly in that 65%.

I recommend listing in advance which problems AI can handle and which require human judgment. The line might be: security requirements, performance requirements, and business logic changes always get human review.

Sharing this list across the team also helps prevent review knowledge from getting siloed in one person.

Principle 2: Build Model-Agnostic Configuration Files

As the Composer 2 controversy shows, models change. That’s exactly why Money Forward insisted on “model-agnostic infrastructure.”

If you keep your prompt templates and configuration files in Git, you can ride out model changes without altering your workflows.

# Example structure for git-managed team Cursor config
# .cursor/
#   ├── bugbot.yaml          # Bugbot config (severity threshold, target languages, etc.)
#   ├── automations.yaml     # Automations config (triggers and actions)
#   ├── rules/               # Coding rules
#   │   ├── typescript.md    # TypeScript-specific rules
#   │   └── security.md      # Security requirements
#   └── prompts/             # Team-shared prompts
#       ├── code-review.md   # Prompt for review perspective
#       └── test-gen.md      # Test generation prompt

# Example commit
git add .cursor/
git commit -m "chore: add team cursor config for review pipeline"

Principle 3: Watch the Ratio of “Code Written” to “Code Shipped”

As Sia Partners’ “productivity paradox” points out, speeding up production without quality assurance keeping pace just piles code up.

I’d suggest checking the monthly ratio of “commit count” to “code that actually made it to release.” If your Bugbot × Automations design is working, this ratio should improve. If it doesn’t, that’s your signal to revisit Bugbot’s threshold settings or the Automations flow.

---

Wrapping Up — The Question Beyond “Speed”

Let me consolidate the numbers I covered.

Metric	Value	What It Shows
Bugbot resolution rate	76%	AI review has reached practical territory
Autofix auto-merge rate	35%	AI fixes can be adopted as-is
PlanetScale FTE reduction	2 FTE equivalent	Structural substitution of review workload is happening
Money Forward deployment scale	1,000+ users	We’ve entered the phase of spreading beyond engineering
Composer 2 cost reduction	86% cheaper	The foundation is in place to use far more, far cheaper than before

The Composer 2 controversy was reported as a “transparency issue,” but the practical decision criteria are benchmarks and cost. The fact that it delivers Terminal-Bench top-class scores at 86% lower cost than Composer 1.5 is what matters more as a selection criterion.

“Being able to write with vibe coding” is something many people are achieving. The next hurdle has shifted to “being able to operate it as a team,” “being able to maintain quality,” and “understanding what your own code means.”

To borrow PlanetScale’s words: precisely because “code has become cheap,” what’s now being asked of us is correctness and understanding. The combination of Bugbot × Automations × Composer 2 strikes me as a realistic gateway into that phase.

The reason I, with my CS background, look at tools through the lens of “rolling them out to the team” is simple: it doesn’t matter if only you get faster — if the organization’s output can’t keep up, the speedup is meaningless. The next question is whether you can pass the gains of speed along to your team.

---

References & Sources

• Cursor Blog “Bugbot Autofix is now generally available” (2026-02-25)
• Cursor Blog “PlanetScale: Cursor in Production” (cursor.com/blog/planetscale)
• Cursor Blog “Money Forward: Cursor in Production” (cursor.com/blog/money-forward)
• Cursor Blog “Introducing Composer 2” (cursor.com/blog/composer-2, 2026-03-19)
• TechCrunch “Cursor admits its new coding model was built on top of Moonshot AI’s Kimi” (2026-03-22)
• Cursor Changelog v2.6 — Automations (cursor.com/changelog, 2026-03-03)
• Sia Partners “Vibe Coding Productivity Paradox” (2026-03)
• University of Chicago survey data (cited from cursor.com/blog/bugbot-autofix)