How Cursor Produced a $180, Three-Day Prototype That Split a Development Team

At one large IT company, an experiment with Cursor quickly turned into a dispute over what matters more: delivery speed or code maintainability. A systems architect spent $180 over three days and showed the business a clickable result, while the team spent three months building a typed, test-covered module.

Three days versus three months

It began as an ordinary AI-tool pilot. The team had five developers, and the company agreed to reimburse each of them for a Cursor subscription at $20 a month. After a month, the numbers looked calm: three employees had spent $60 between them. Then it emerged that the systems architect had burned through $180 in just three days.

He used Agent mode, loaded a Figma mockup, an old component and a text prompt into the editor, and then wrote almost no code by hand. Cursor generated the interfaces itself, read terminal errors, fixed them and re-ran the build.

At the other extreme was the team, which spent three months building its module by classic rules. They had TypeScript, code review, Storybook, JSDoc and about 300 unit tests with coverage of at least 85%. In the same period, the architect produced a clickable prototype with more features, but in Vanilla JS and with roughly five tests.

When the two versions were put side by side, the business saw not development discipline but two different delivery paces: slow and reliable versus fast and flashy.

Why the prototype won

The decision was made at a meeting with business analysts and management. To the engineering team, its version looked mature: it matched the stack and standards and could be maintained by any developer. But for the business, a different criterion proved decisive: a visible result right now.

The architect's prototype could be clicked, scrolled and shown off as an almost finished product. The team's module was better on the inside but looked less impressive on the outside, because most of the effort had gone into the foundation rather than demo features.

"Tests can be added later, the market won't wait."

That logic became the breaking point. The team refused to move its work onto the architect's solution: different stack, almost no documentation and far too few checks. The architect, for his part, believed his colleagues were overcomplicating the process and wasting time when a working form already existed.

As a result, one project now has two parallel solutions to the same task. On paper there is progress, but the company no longer has a single architecture. It has a conflict between speed, standards and responsibility for future maintenance.

The flip side of AI speed

The main risk in this story is not just technical debt but what the authors call AI debt. Under ordinary time pressure, a team at least knows what it will have to rewrite later. Here the problem runs deeper: code is generated so fast that its author may not understand the implementation details. If a bug surfaces later or a business rule changes, maintenance will have to be handed back to the model again, in the hope that it reconstructs the context correctly and doesn't start hallucinating on top of code it already generated.

• There is no shared stack or typing for the team to rely on
• Tests and documentation are nearly absent, so changes become less predictable
• The bus factor approaches one: maintenance depends on a single author and the same tool
• Every new requirement raises the risk of breaking code that nobody really understands

The authors of the case do not call for banning Cursor. Their conclusion is practical: the problem is not the tool but the lack of rules before work began. Had the team agreed in advance on a mandatory stack, a minimum set of tests and a review format for AI-generated code, the dispute might not have arisen. Cursor can serve as an accelerator for finding solutions, drafting and prototyping, but not as a replacement for engineering thinking. Otherwise the developer stops writing a system and starts watching it write itself.

What this means

The Cursor story shows that AI is changing not only the speed of development but also the internal politics of teams. In such disputes, the winner will not be whoever has the stronger model, but whoever first agrees on boundaries: where a quick prototype is acceptable, and where code simply cannot be considered finished without tests, typing and a shared stack.