There are two recurring personalities in the working-developer conversation right now. One is the engineer who refuses to touch an AI coding tool the same week a major acquisition closes. The other is the engineer who quietly uses one on weekends and would not put their name on the practice at work. Both kinds are right. After watching the public numbers land across 2026, the only framing I trust is to stop reading them as one story and start reading them as three.
The shape of the question matters too. Consider a small dev shop weighing whether to buy seats. By the time the conversation moves past the headline, three separate questions have emerged: how are sales trending, what does a baseline security scan say about the code, and will the team keep using it after the first month. None of those questions maps cleanly onto the headline. The buyer-side answer and the working-developer answer point opposite directions, and the security baseline pulls in a different direction entirely. Here is what the public record says about each, sourced where I can, with a rule you can actually use this week.
The buyer side: three vendors, three shapes
Cursor, Lovable, and Replit are the names that keep coming up in 2026. Each published numbers between March and August, and the shapes are different enough that averaging them erases the actual picture.
Cursor’s annual recurring revenue moved from roughly $2 billion in February to $3 billion by late April and to $4 billion by early June, per a Forbes report dated June 8, 2026. Forbes also reported that three quarters of that run rate was enterprise seats rather than individual subscribers. SpaceX agreed in mid-June to buy Cursor all-stock at $60 billion; the deal closed in mid-August per a regulatory filing cited by Bloomberg. Cursor’s own Series D announcement earlier in the year had valued the company at $29.3 billion post-money, so the acquisition price was almost double.
Lovable announced 60 million projects shipped by August 2026 alongside a $13.3 billion post-money valuation following a $400 million Series C. Replit published a $9 billion valuation as part of its March 2026 funding round.
- Cursor ARR: $2B in February to $4B by early June, per Forbes reporting.
- SpaceX acquisition of Cursor closed in August 2026 at $60 billion all-stock, per Bloomberg.
- Lovable reported 60M projects and a $13.3 billion valuation by August 2026.
- Replit valued at $9 billion in March 2026 per its funding announcement.
Two honest reads sit next to each other. The category has found paying enterprise customers faster than almost any developer tool in recent memory, and a $60 billion buyer implies the funding is not slowing. At the same time, annualized revenue is a forward-looking estimate the company itself supplies. Both takes matter. Read them together and you have the right starting point.
The shipping side: a quiet majority against
Stack Overflow’s 2025 developer survey is the closest thing to a census on whether working programmers have folded these tools into their day jobs. A bit more than seven in ten respondents said vibe coding, defined as describing what you want in English and letting AI write the code, is not part of their professional work. The gap widens when you slice by age cohort. Older developers report almost no daily use; younger ones report more. Trust is the consistent factor in every age bracket that says no. The reasons cited most often are hallucinated suggestions and the rewrite churn that follows.
So you have a real category with a $60 billion acquirer on one side, and a clear majority of working developers saying they are not actually using it in their professional work on the other. That tension is the actual story, and it is the part of the story the headlines tend to flatten out.
The 56 percent line
Veracode published a July 2026 study that ran standard scanners across AI-generated code in several languages. The average pass rate across a baseline of long-known flaw categories (injection patterns, insecure defaults, broken access control) was 56 percent. That baseline is what most security teams would expect a junior engineer to clear with review. The AI output clears it just over half the time.
Two follow-up studies sharpen the picture. Escape scanned live vibe-coded apps in production and saw roughly the same failure rates on the same categories. CodeRabbit compared pull requests that included AI suggestions to pull requests that did not, on the same set of repos, controlling for how thoroughly the changes were reviewed. Their headline finding is that per-pull-request the rate of new regressions was similar. The reframing matters. AI is not making individual lines more dangerous. AI is letting teams push larger diffs per unit of time. Volume, not per-line quality, is the surface-area problem.
- Veracode, July 2026: 56 percent pass rate on the standard baseline categories.
- Escape: production scans of live vibe-coded apps found similar failure rates on the same categories.
- CodeRabbit: AI-assisted and human-only pull requests introduce new regressions at a similar rate after controlling for review quality.
The single number to remember is 56 percent. If your team ships six features a quarter with AI help, expect to find roughly three of them with a baseline-level issue each, before any project-specific concern enters the picture.
Two products that share a name and not much else
When people say Claude Code, they usually mean the agentic version that runs in the terminal, edits files, and runs the project’s own tests as it goes. That is a different product from the chat interface at claude.ai. Anthropic’s usage data shows that terminal sessions are typically longer, more tool-heavy, and concentrated on a narrower set of tasks: writing tests, reorganizing existing files, prepping pull requests. The chat product is broader and shallower and tends to work better for reading code, sketching ideas, and asking questions about unfamiliar territory.
Pretending the two are interchangeable is the easiest way to pick the wrong one. If you find yourself asking the chat product to edit files across an unfamiliar repo, you are using the wrong tool. The vendor sells both, the logos match, and neither the marketing page nor the in-product switch tells you which one fits.
What the productivity data actually showed
The 2025 randomized trial from METR is the cleanest data point on whether AI help makes experienced developers faster. The result was that on a large codebase the developers had not personally written, the AI group finished around 19 percent slower than the control group, even though the AI group believed they were going faster. That gap between belief and measurement is the single most important fact in the study, and most commentators skip it.
The 2026 follow-up narrowed the slowdown. On smaller scoped tasks inside codebases with existing test coverage, the AI group showed small to modest speedups. The takeaway is not “AI slows you down” or “AI speeds you up.” The takeaway is that gains depend on whether the model can effectively pattern-match against code it has seen before. Losses show up where you have to verify every suggestion against logic you have not internalized.
- METR 2025: experienced developers roughly 19 percent slower on a large unfamiliar codebase with AI.
- METR 2026 follow-up: small but real gains on scoped tasks in already-tested code.
- The gap between belief and measurement was the largest single effect in both studies.
If you are landing on a codebase you did not write, plan for slower. If you are writing the same form-validation routine you have written fifty times, plan for meaningfully faster. Most arguments from either side that miss the data are arguments from feeling.
Trade-offs
The catches that the headlines skip are the ones I would want to know before signing a year of seats. Three matter most.
First, 56 percent is an average. A vendor quoting “almost half fail” is not telling you which half. Your actual scan results may run lower or higher than the average, and you will not know which way until your scanner is pointed at real artifacts. Second, “a clear majority say no” is a 2025 snapshot, not a permanent verdict. Working-dev adoption has moved noticeably in the past twelve months and the same survey a year from now could read differently. Third, the productivity studies have been re-run twice in eighteen months. Treat any single result as the case as of that study, not as a stable rule.
On the user side, the catch is that unfamiliar code plus an AI tool is the worst-shaped combination, and it is the one most teams land in during a ramp-up or a takeover. The other catch is the chat-versus-terminal confusion. Picking the chat product for terminal work, or vice versa, shows up immediately in the daily experience and is invisible in the headline numbers.
A practical starting point for your week
You do not need to take a side in this debate. You need a small experiment you can run inside a single sprint, and a way to decide based on the numbers that come out of it rather than the headlines.
Pick a piece of work that has crisp acceptance criteria, where the tests already exist, and where someone on the team will read the diff line by line before merge. Hand that piece of work to whichever tool you are considering. Measure the time from “kicked off” to “ready for review,” the count of comments from review, and the count of CI failures the diff produced. Hold that record side by side with the last three comparable features your team shipped without AI help.
That three-number comparison (time, review comments, CI failures) tells you more about your team and your codebase than any public revenue line. If the AI number is meaningfully better on all three, the tool has earned its seat. If the AI number is worse on review comments or CI failures, the tool is creating cleanup work that does not show up in the cycle-time stat. If the AI number is better on time but worse on review comments by an order of magnitude, that is the precise signature of “the AI wrote more code than it understood.”
This is the only experiment that matters for your decision, and it is the only one that uses numbers from your team rather than from a vendor.