「速くなった」では足りない ─ Cursor Meetup Sapporo で話した、弥生の Cursor 組織導入1年Yayoi shared one year of org-wide Cursor adoption at Cursor Meetup Sapporo,…

At a Cursor Meetup held in Sapporo on August 1, 2026, an engineer from the Japanese business-software company Yayoi delivered a lightning talk recounting roughly one year of adopting Cursor across the organization. The talk, titled in Japanese to the effect that "'It got faster' is not enough," and later written up as a blog post on Zenn, matters because it moves the conversation past anecdotal enthusiasm toward the harder question of how a company actually measures productivity when it rolls out an AI coding assistant to an entire team.

The event was hosted at the Classmethod Sapporo office, part of a growing circuit of community meetups centered on Cursor, the AI-native code editor built as a fork of Visual Studio Code and developed by Anysphere. Cursor integrates large language models directly into the editing workflow, offering inline code generation, multi-file edits, and a chat interface that can reason over a codebase. Its rapid rise has placed it alongside tools such as GitHub Copilot, Windsurf, and Claude Code as part of a broader shift in how software is written, and community gatherings like the Sapporo meetup have become venues for practitioners to share real deployment experience rather than vendor messaging.

The central thread of the presentation, according to the source, is the tension between individual perception and organizational evidence. The speaker is candid that on a personal level the speedup was genuine: after beginning to use Cursor, everyday tasks such as writing code, fixing it, and researching all took noticeably less time than before. That subjective experience, however, is framed as the starting point rather than the conclusion. The stated purpose of the talk is to summarize what Yayoi tried to measure as an organization, not simply what one developer felt at the keyboard.

That distinction reflects a well-known challenge in the field. Developer productivity is notoriously difficult to quantify, and a faster individual coding loop does not automatically translate into faster delivery, higher quality, or better outcomes at the team or company level. Industry frameworks such as SPACE and DORA have emerged precisely because single metrics can mislead; more lines of code or quicker edits may say little about review load, defect rates, or the time it takes a change to reach production. By emphasizing that "it got faster" is insufficient as a justification, the talk appears to align with this more cautious, evidence-oriented view of measuring engineering work.

For a company like Yayoi, which builds accounting and business-management products used by many small and mid-sized businesses in Japan, an organization-wide tooling decision carries weight beyond raw speed. Rolling out an AI editor across a team typically raises questions about consistency of code quality, onboarding and training, security and data handling, licensing costs, and how to define success in a way that stakeholders outside engineering can understand. Presenting a full year of experience suggests the effort has moved past an initial pilot into something closer to sustained, measured practice, though the blog post is the primary place where the specific metrics and findings would be detailed.

The framing also fits a wider industry moment. As AI coding assistants have matured from novelty to standard tooling, many organizations have shifted from asking whether to adopt them to asking how to demonstrate their value and manage their risks. Reports of productivity gains are common, but rigorous, organization-level measurement remains comparatively rare and is often complicated by confounding factors, making transparent accounts from adopting companies particularly useful to peers weighing similar decisions.

Because the available material centers on the premise and motivation of the talk rather than a complete set of results, readers seeking the concrete metrics, methodology, and lessons learned would likely need to consult the accompanying slides and the Zenn write-up directly. What is clear from the source is the intent: to treat one year of Cursor adoption as a subject for organizational measurement, and to argue that a compelling personal sense of speed, while real, is not by itself an adequate basis for evaluating an organization-wide investment in AI-assisted development.