5.2 Billion Tokens in Practice: One Developer Built a Commercial-Grade RBAC Admin System with Cursor

An AI Programming Journey That Started with an Email Template

In late March of this year, a developer started using Cursor for programming with an experimental mindset. The initial goal was modest — he just wanted to write an email sending template. Yet this small starting point was what made him truly feel the power of AI-assisted programming.

From March 20th to August, in just a few months, he single-handedly used Cursor to push a complete admin system from zero to production-ready. The project, called "Aus Community," is an RBAC (Role-Based Access Control) data permission admin system built with a separated frontend-backend architecture.

RBAC is one of the most mainstream permission management models in enterprise applications. Its core idea is to assign permissions to roles, then assign roles to users, rather than binding permissions directly to individuals. This model was formally proposed by the U.S. National Institute of Standards and Technology (NIST) in 1992. Over more than thirty years of evolution, it has developed four levels from RBAC0 to RBAC3, ranging from basic user-role-permission mapping to support for role inheritance, mutual exclusion constraints, and other complex scenarios. "Data permissions" take this a step further beyond RBAC with more granular control — not only governing "what operations a user can perform" but also "what data a user can see." For example, with the same "view orders" permission, a regional manager can only see orders within their territory, while a national director can see all orders. The design complexity of this row-level data isolation far exceeds simple functional permission control, requiring dynamic injection of filter conditions at the database query level — demanding extremely high standards for architectural design. Under a separated frontend-backend architecture, the permission system faces additional challenges: the frontend needs to dynamically render menus and buttons based on user roles, while the backend must independently verify permissions for every API endpoint. The permission logic on both sides must be strictly synchronized; otherwise, security vulnerabilities emerge where "the button is hidden on the frontend, but calling the API directly still works."

What you might not have noticed is that throughout the entire development process, he consumed a staggering 5.2 billion Tokens. This number intuitively reflects the depth of AI-assisted programming's involvement in a real commercial project — AI is no longer a toy for writing a few lines of code, but a productivity tool capable of participating throughout the entire design, development, testing, and deployment lifecycle.

To understand the true scale of 5.2 billion Tokens, you first need to understand the concept of Tokens. In large language models, a Token is the smallest unit of text processing — one English word typically corresponds to 1-2 Tokens, and one Chinese character typically corresponds to 1.5-2.5 Tokens. A standard technical document contains roughly 2,000-3,000 Tokens, and GPT-4's conversation context window is approximately 128,000 Tokens. What does 5.2 billion Tokens mean? Estimating an average consumption of 3,000-5,000 Tokens per conversation, this is equivalent to roughly 1 million to 1.7 million rounds of effective interaction between the developer and AI. Converted to text volume, it's approximately equivalent to the total text of 2,500-3,500 standard books. This number also illustrates from a different angle that AI programming is far from "one prompt handles everything" — it requires massive iterative dialogue, repeated debugging, and continuous correction. Each functional module may have gone through dozens or even hundreds of rounds of human-AI interaction before being polished into its final form.

Solo Full-Lifecycle Delivery: Design, Development, Testing, Deployment

What makes this project most impressive is that it was completed entirely by one person. Under traditional development models, a commercial-grade RBAC permission admin system typically requires a small team collaborating for months. With Cursor, a single developer can cover the complete loop from design to deployment.

Cursor is an AI-native code editor deeply rebuilt on top of VS Code, launched by Anysphere in 2023. Unlike AI programming tools like GitHub Copilot that embed into IDEs as plugins, Cursor deeply integrates AI capabilities into every aspect of the editor. It supports multiple large language models (including GPT-4, Claude, etc.) and can understand the entire project's codebase context — not just the currently open file. Developers can use natural language conversations to have AI understand requirements and directly generate or modify content in the code, or have AI analyze the entire project structure to answer architecture-level questions. A key capability of Cursor is "Codebase Indexing" — it vectorizes and indexes the entire project's code, so that when AI answers questions or generates code, it can reference implementation logic from other files in the project, producing results more consistent with the existing code style and architecture.

At the project's start, the developer made a bold decision: delete almost all of the old frontend and backend code, keeping only a few reusable backend modules, then rebuild from scratch with AI assistance.

Looking at the data, the frontend and backend pushes across related repositories on GitHub reached approximately 1,200+ commits. Behind this high-frequency submission rate, AI dramatically lowered the barrier to coding and the cost of experimentation, enabling the developer to iterate rapidly and validate frequently. Completing 1,200+ Git commits within five months means an average of about 8 commits per day — a frequency that in traditional development is almost only seen in large teams' CI/CD pipelines, yet here it was accomplished by a single person.

Fast Doesn't Mean Shippable: The Core Insight of AI Programming

However, the most valuable part of this developer's practical experience isn't "speed" — it's his clear-headed understanding of the true nature of AI programming. He repeatedly emphasized one core viewpoint:

Cursor writes fast, but fast doesn't mean shippable.

For commercial-grade projects, code that runs is merely the minimum standard. What truly determines project quality is architectural design, edge case handling, and engineering standards.

He gave a specific example: the priority problem of interface annotations. Public annotations, internal annotations, login annotations — when these annotations coexist, which should take precedence?

In the Java Spring framework (and similar backend frameworks), annotations are the core mechanism for controlling interface behavior. Taking permission systems as an example, developers typically define multiple custom annotations to mark API endpoint access levels: @Public means accessible without login (e.g., registration and login endpoints); @LoginRequired means user login is needed; @InternalOnly means restricted to internal service calls. The problem arises when a Controller class is marked with @LoginRequired, but a specific method within that class is marked with @Public — how should the system handle this? This involves the design of annotation inheritance and override mechanisms. Common design patterns include: method-level annotations take precedence over class-level annotations (proximity principle), higher security level annotations take precedence over lower ones (security-first principle), and resolving conflicts through explicit priority values. There's no standard answer to these decisions — they must be weighed based on specific business scenarios. AI might produce an implementation that "works," but it cannot understand judgments like "whether the public annotation should override the login requirement in this business scenario" — decisions that require domain knowledge and security awareness.

These kinds of design decisions requiring deep business judgment must be thought through by humans to form a complete loop, rather than being entirely handed off to AI.

Humans Handle Design, Models Handle Implementation

This reveals an efficient human-AI collaboration model: humans are responsible for thinking through design logic, while models are responsible for efficient implementation. AI excels at rapidly converting clear intentions into code, but it cannot replace the developer's holistic control over system architecture.

In other words, the "guardrails" of AI programming matter more than "speed." Developers need to draw clear boundaries for AI, keeping it running efficiently on the right track rather than letting it improvise freely. This collaboration model is essentially an upgraded version of "declarative programming" — in the past, developers used SQL to declare "what data I want" and the database engine handled "how to query"; now developers use natural language to declare "what system behavior I want" and AI handles "how to implement it." But the more precise the declaration, the more controllable the result; the more vague the declaration, the more room AI has for "creative freedom," and the higher the probability of things going wrong.

Using Cursor Rules to Constrain AI: The Key Strategy Against Technical Debt

In practice, the developer distilled an effective methodology — explicitly writing rules into Cursor's rules files.

Cursor Rules is a project-level configuration mechanism provided by the Cursor editor. Developers can create a .cursor/rules folder in the project root directory and write natural language or structured rule documents within it. These rules are automatically loaded as part of the System Prompt during every AI interaction, continuously constraining AI's code generation behavior. For example, you can specify in the rules file that "all Service layer methods must have corresponding unit tests," "direct database operations in Controllers are prohibited," or "API response format must follow the project's unified ResponseWrapper structure." This mechanism is essentially a "project constitution" for AI, requiring AI to follow these conventions when generating any code, rather than relying solely on the model's generic coding habits.

Through rules files, he set hard engineering standards for AI, such as:

• Backend code must include unit tests
• There must be architecture tests to ensure code structure conforms to design specifications
• Integration with code quality analysis tools like SonarQube for continuous quality gates

The core value of this mechanism lies in combating an increasingly prominent problem in the AI programming era: technical debt.

The concept of technical debt was proposed by Ward Cunningham in 1992, drawing an analogy between sacrificing code quality for short-term speed in software development and financial debt — you "borrow" speed now, but must repay it with "interest" in the future, where the interest is the additional cost required for subsequent maintenance, refactoring, and bug fixing. SonarQube is an open-source continuous code quality inspection platform developed by SonarSource. It performs static analysis on code, automatically detecting code smells, potential bugs, security vulnerabilities, duplicate code, and other issues, quantifying technical debt into specific time costs — for example, "fixing all current issues in the code is estimated to require 47 working days." In the AI programming era, the importance of tools like SonarQube has been dramatically amplified: AI can generate in one day the volume of code that used to take a week to write, but if that code lacks consistent error handling patterns, contains redundant logic branches, or violates the project's architectural layering rules, technical debt accumulates at several times the previous rate.

He pointed out incisively: once you connect code quality detection tools, you'll discover that the faster you write, the faster technical debt grows. AI's high productivity is a double-edged sword — it can produce massive amounts of code in a short time, but without quality constraints, this code can quickly accumulate into an unmaintainable burden.

Therefore, pairing tools like SonarQube to keep code quality controllable during rapid development has become the dividing line between whether a commercial-grade AI programming project can truly be "shipped." This also echoes a classic principle in software engineering: the later a defect is discovered, the higher the repair cost grows exponentially. In the context of AI programming, this principle becomes even sharper — because AI's output speed is so fast, if quality gates aren't set at the generation stage, problems can balloon to an unmanageable scale in an extremely short time.

Insights for AI Programming Practitioners

This real-world case of 5.2 billion Tokens and 1,200+ commits offers several important insights for practitioners looking to use AI for commercial-grade development:

First, AI can significantly raise the capability ceiling of solo development. Projects that previously required teams can now potentially be handled independently with Cursor — a tremendous opportunity for indie developers and small teams. Looking at industry trends, in Y Combinator's Winter 2024 batch, over 25% of startups had codebases largely generated by AI. Cases of "one-person companies" or "two-person teams" completing the workload of previously ten-person teams are increasing rapidly. This doesn't mean team collaboration will disappear, but rather that AI is redefining the lower bound of a "minimum viable team."

Second, the human role shifts from "writing code" to "defining rules and designing." A developer's core value is no longer reflected in typing speed, but in the ability to make judgments about architecture, boundaries, and priorities. This actually demands higher-level abstract thinking skills — you need to clearly describe "what the system should look like," not just "how the code should be written." This capability shift means that future excellent AI programming practitioners may look more like a hybrid of software architects and product managers, rather than programmers in the traditional sense.

Third, quality engineering must be front-loaded. Unit tests, architecture tests, and code quality scanning are not optional — they are essential tools for harnessing AI's high output. AI programming without quality guardrails only leads to runaway technical debt. The concept of "architecture tests" deserves special explanation — it refers to using tools like ArchUnit to write test cases that verify whether code structure conforms to predetermined architectural rules, such as "the Service layer cannot directly depend on the Controller layer" or "all Repository interfaces must be placed in designated packages." This type of testing is an advanced practice in traditional development, but has become almost a necessity in AI programming, because AI easily breaks the architectural conventions that human developers silently follow by default.

From an email template to a production-ready commercial-grade admin system, this journey vividly demonstrates the true capability boundaries of AI programming: it's powerful enough, but only under the guidance of human engineering wisdom can it truly deliver value.