In the previous article, we discussed why we started TenCirPauli and why we chose its technology stack. Many structured tasks in quantum operator processing involve dynamic data structures, discrete computations, and variable-length results. Providing a high-performance, Rust-native runtime for these workloads is the product motivation behind TenCirPauli.
This article is about how it is developed.
TenCirPauli is an extreme experiment in software development: the implementation is delegated entirely to AI. The developer does not write—or even read—any line of code. The goal is to explore whether this new development paradigm can support a rigorous scientific computing software project at meaningful scale.
TensorCircuit-NG Still Uses the “Old-School” Approach
TensorCircuit-NG takes a relatively conservative approach to development.
When we encounter an issue or want to add a feature, we first work out the implementation strategy and then give the AI detailed instructions. After the AI makes the changes, a human reviews every modified file and essentially every significant addition or deletion, checking that the implementation follows the project's conventions and design principles.
For a mature project with years of history and a large user base, this approach may be necessary.
Such projects accumulate a large amount of implicit knowledge that is never fully documented: why an interface is named a certain way, what seemingly unnecessary branch exists for backward compatibility, which coding patterns are intentional, and which internal conventions should never be changed casually. This knowledge is scattered across source code, issues, historical behavior, and the experience of maintainers. It is extremely difficult for an AI to reconstruct all of that context reliably.
This development model has kept TensorCircuit-NG stable. It protects existing abstractions, semantics, and coding conventions, while preventing AI from introducing local workarounds simply to get a task done.
If we simply started “vibe coding” inside such a project, however, the result could be very different. Old implicit conventions would gradually be overwritten, while new conventions would not have enough time to stabilize. Interfaces and internal structures could quickly lose coherence.
That is why we chose a new project for this experiment.
A new project has no historical baggage to preserve. Public interfaces, internal boundaries, testing methodology, and Agent collaboration workflows can all be designed from day one—and, importantly, they can be developed according to the AI's own preferences rather than being constrained by decades of accumulated human conventions.
The Development Workflow
TenCirPauli has already grown far beyond the scale of a toy demonstration. The project now contains more than 80,000 lines of code, roughly half Python and half Rust.
That is large enough for interface design, module boundaries, performance, and maintainability issues to emerge naturally. It is also large enough to test whether this development model can actually scale.
In TenCirPauli, the developer's role is concentrated on goals, specifications, key architectural decisions, and acceptance criteria.
The workflow roughly looks like this:
- A high-capability AI analyzes the goal and develops an initial Spec.
- The human decides on key interfaces, semantics, and architectural trade-offs, and aligns them with the Spec.
- A medium-capability AI implements the design.
- A high-capability AI reviews the implementation and generates a Review Report.
- The implementation AI fixes the identified issues.
- Automated tests and benchmarks provide objective evidence.
- The process is repeated as the project evolves.
- Periodic global AI inspections scan the repository for accumulated problems.
In other words:
High-capability AI → formulate goals and write the Spec
↓
Human → decide key interfaces, semantics, and architectural trade-offs
↓
Medium-capability AI → implement the Spec
↓
High-capability AI → review the implementation and generate a Review Report
↓
Medium-capability AI → fix the issues
The division of labor is deliberate.
The high-capability model is responsible for understanding the problem, proposing solutions, and evaluating the result. The medium-capability model handles implementation and repairs. The human makes design trade-offs and keeps the overall system aligned. Automated infrastructure provides continuous evidence.
The Spec Is Where Human–AI Collaboration Matters Most
A Spec is much more than a feature checklist.
For a nontrivial scientific computing component, it needs to define the API surface and internal boundaries: invocation patterns, conceptual terminology, return values, data lifetimes, error types, the division of responsibilities between languages, performance and resource requirements, as well as independent reference implementations and benchmark-based acceptance criteria.
Writing the initial Spec is therefore the most human-intensive part of the entire workflow.
A high-capability AI can propose several interface designs, compare approaches used by existing libraries, and analyze complexity, resource consumption, language boundaries, and future extensibility.
The developer, meanwhile, keeps asking the more fundamental questions:
What does the user actually need?
Which abstraction should remain hidden?
Which performance trade-offs are worth making?
Which parts are over-engineering without a real use case?
Which design decisions will become painful once the project scales?
This process often takes many rounds of discussion. The goal is to keep challenging the design until the interfaces and the major implementation strategy can survive serious scrutiny.
Once the Spec is properly aligned, implementation becomes almost mechanical.
Even when a single change involves thousands—or tens of thousands—of lines of code, current AI systems can handle the actual implementation surprisingly well.
Mature Libraries Provide the Coordinates
It is remarkably cheap to generate software from scratch with AI. But mature software libraries still play an essential role.
TenCirPauli draws on projects such as QuSpin, OpenFermion, TensorCircuit-NG, PauliPropagation.jl, and QLDPC.
But what we primarily borrow from these projects is not their code or interface design.
We use them for two things:
established correctness references and measurable performance baselines.
Correctness references provide something against which a new implementation can be tested. Existing libraries, physical models, and published examples cover many cases that are difficult to derive correctly from scratch.
Performance baselines provide something equally important: a sense of scale.
Suppose a program is optimized from 10 seconds down to 1 second. That sounds like a spectacular 10Ă— improvement. But if a mature library solves the same problem in 100 milliseconds, the program is still an order of magnitude too slow.
Without a baseline, it is difficult to know how fast a piece of scientific software should be, or whether an optimization is actually attacking the important bottleneck.
TenCirPauli has been developed within this coordinate system.
Different mature frameworks provide correctness and performance references for different classes of workloads. TenCirPauli then uses tireless AI-driven optimization to push the implementation far beyond those baselines.
The project's performance pages and research examples record these comparisons.
What is perhaps most surprising is that even medium-capability AI models can now outperform many mature scientific software implementations across a surprisingly broad range of workloads.
Tests, Benchmarks, and Global Repository Inspections
Once human code review is removed, tests and benchmarks become the core mechanisms of quality control.
They need to continuously answer several questions:
- Is the result correct across different scales, boundary cases, representative workloads, and independent references?
- Is the public API correct, including parameters, return values, error types, failure timing, and deterministic behavior?
- Does the benchmark represent real user workloads, and does it distinguish one-time preparation costs from repeated execution?
- Has a modification introduced a regression in correctness or performance?
A single AI Review primarily examines the current changes and their alignment with the Spec. It cannot reliably detect every problem that accumulates across an entire repository.
That is why TenCirPauli also performs periodic global AI inspections.
Each inspection focuses on a clearly defined set of questions and rescans the repository from a different perspective. It can search for hidden bugs and boundary-condition failures, identify performance bottlenecks, remove dead code and duplicated implementations, and clean up accumulated technical debt.
A single review handles the changes in front of us.
A global inspection handles the entropy accumulated over time.
Together, these two rhythms help keep the project in a low-entropy state.
Will AI Make Mistakes?
Of course.
The repository may still contain hidden performance inefficiencies, subtle bugs that are difficult to trigger, or layers of redundant code that accumulated over time.
These problems are difficult to eliminate completely. But human-reviewed code has exactly the same problem—and often a worse one.
The meaningful engineering question is therefore not whether every line of code is perfect.
The question is whether the main execution paths have sufficiently strong correctness tests and performance baselines.
If the important paths consistently produce correct results and complete within a reasonable amount of time, the software has a solid foundation for real-world use.
As the old saying goes: if it walks like a duck and quacks like a duck, it is a duck.
Users ultimately care about whether the software produces the right answer, does so within a reasonable amount of time, and integrates reliably into their workflow.
The User Is an Agent
TenCirPauli can of course be used directly by humans. It provides Python APIs, documentation, examples, and integration with TensorCircuit-NG.
But from the beginning, its more important user has been the Agent.
This changes some of the traditional trade-offs in software abstraction.
For performance and deterministic execution, an internal implementation may deliberately sacrifice some generality. It can retain specialized low-level implementations while exposing programmable layers of abstraction above them.
The result is not necessarily the most elegant abstraction for a human programmer.
It can instead be a much more flexible substrate for an Agent to call, compose, and optimize.
Maintainability Can Also Be Agent-Driven
A common criticism of software is:
“It works, but the codebase is a mess.”
That criticism is based on an implicit assumption: the future maintainer will be a human who needs to understand the source code before modifying it.
That assumption is changing.
TenCirPauli is maintained by Agents as well.
As long as the project has clear Specs, accumulated context, sufficiently strong tests, performance records, and real integration cases, an Agent can be instructed to locate a problem, propose a modification, implement it, and verify the result.
As long as Agents can continue to perform those maintenance operations reliably, the maintainability of the project remains under control.
This suggests a new form of implementation agnosticism:
First, ask whether the user-facing behavior works.
Then, ask whether the correctness and performance evidence remains stable.
Finally, ask whether an Agent can continue to modify and validate the system.
The source code itself becomes less important than the system of specifications, evidence, interfaces, and automated maintenance surrounding it.
Conclusion
TenCirPauli is both a performance sprint in Rust-based quantum software and an experiment in redefining the role of the developer.
It asks a deliberately extreme question:
Can rigorous scientific computing software be built without humans writing—or even reading—the code?
The answer so far is surprisingly close to yes.
More importantly, the experiment points toward something larger than TenCirPauli itself.
When AI can generate, review, test, benchmark, optimize, and maintain software, the developer's role moves upward—from implementing algorithms line by line to defining problems, designing abstractions, setting constraints, and building systems of evidence that continuously verify the result.
This is not simply a faster way to write software.
It may be the beginning of an irreversible shift in how software—and eventually scientific computing itself—is built.
