How Cursor Built a Prototype in Three Days for $180 That Divided the Development Team

How Cursor in three days and $180 created a prototype that split the development team

In a large IT company, an experiment with Cursor quickly turned into a dispute about what matters more: speed of delivery or code manageability. A system architect spent $180 in three days and showed the business a clickable result, while the team spent three months building a typed and tested module.

Three days against three months

The story started like a typical AI tool pilot. The team had five developers, and the company agreed to reimburse each employee's Cursor subscription at $20 per month. After a month, the numbers looked calm: three employees together spent $60.

But then it turned out that the system architect had spent $180 in just three days. He used Agent mode, loaded a Figma layout into the editor, an old component and a text prompt, and then almost never wrote code by hand. Cursor generated interfaces itself, read errors in the terminal, fixed them and ran the build again.

At the other extreme was the team that spent three months building their module by classic rules. They had TypeScript, code review, Storybook, JSDoc and about 300 unit tests with coverage not lower than 85%. The architect in the same time got a clickable prototype with a lot of features, but in Vanilla JS and with approximately five tests.

When both options were placed side by side, the business saw not development discipline, but two different delivery speeds: slow and reliable against fast and effective.

Why the prototype won

The decision was made in a meeting with business analysts and management. For the engineering team, their version looked mature: it matched the stack, standards and could be maintained by any developer. But for the business, the decisive criterion was different — a visible result right now. The architect's prototype could be clicked, scrolled and shown as an almost finished product. The team's module was better quality inside, but looked less impressive on the outside, because most of the effort went into the foundation, not demonstration features.

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

This logic became the breaking point. The team did not want to transfer their work to the architect's solution: it has a different stack, almost no documentation and too few checks. The architect, on the other hand, believed that colleagues were overcomplicating the process and wasting time, even though a working form already existed. As a result, two parallel solutions to one task appeared in one project. Formally there is progress, but the company now has not a unified architecture, but a conflict between speed, standards, and responsibility for future maintenance.

The downside of AI speed

The main risk in this story is not just technical debt, but what the authors call AI debt. In a regular rush, the team at least understands what exactly will have to be rewritten later. Here the problem is deeper: code is generated so quickly that the author themselves may not understand the details of the implementation. If a bug appears later or a business rule changes, maintenance will have to be delegated to the model again, hoping that it will correctly restore the context and not start hallucinating over the already generated code.

• No unified stack and typing that the team relies on
• Almost no tests and documentation, so the predictability of changes falls
• Bus factor tends toward one: support depends on one author and the same tool
• Any new requirement increases the risk of breaking code that no one really understands

The case authors do not call for Cursor to be banned. On the contrary, their conclusion is practical: the problem is not in the tool, but in the lack of rules before starting work. If the team had in advance fixed the mandatory stack, the minimum set of tests and the review format for AI-generated code, the dispute might not have arisen. Cursor can be used as an accelerator for finding solutions, drafts and prototypes, but not as a replacement for engineering thinking. Otherwise, the developer begins not to write the system, but to watch how the system writes itself.

What it means

The Cursor story shows that AI is already changing not only the speed of development, but also the internal policy of teams. Those who will win in such disputes will not be the one with a stronger model, but the one who agrees first on the boundaries: where a quick prototype is acceptable, and where code without tests, typing and a common stack simply cannot be considered ready.