DEV Community: Shixin Zhang

TensorCircuit-NG: Quantum Software On AI, For AI, With AI

Shixin Zhang — Wed, 27 May 2026 11:02:16 +0000

Quantum computing and artificial intelligence are often discussed as two separate frontiers. One is about exploiting quantum mechanics for computation; the other is about building increasingly capable learning systems and agents. The core argument behind TensorCircuit-NG is that this separation is becoming less and less meaningful. If modern AI infrastructure has already solved core problems around automatic differentiation, compilation, accelerator execution, batching, and distributed training, then quantum software should stop reinventing those layers badly and start standing on top of them directly.

This is the central idea behind TensorCircuit-NG. The project is a quantum software stack built in the age of AI, aimed at AI-facing workloads, and increasingly shaped for collaboration with AI agents. Its vision is simple: quantum software on AI, for AI, with AI.

On AI: quantum software should inherit the AI stack

Quantum software has long been held back by two familiar problems. Too much of the workload remains trapped in Python-level control flow or in classical state-vector simulation patterns that scale poorly. At the same time, many quantum libraries sit outside the deep learning ecosystems where most of the tooling innovation has happened. JAX, PyTorch, and TensorFlow already have mature answers to questions like compilation, vectorization, accelerator placement, and distributed execution, yet quantum software has often kept those capabilities at the edge of the stack.

TensorCircuit-NG takes a different route. The framework treats quantum circuits as specialized tensor operations. That design choice opens up a large part of the AI toolchain almost “for free.” Automatic differentiation maps naturally onto variational quantum algorithms. Just-in-time compilation matters for repeated circuit evaluation. Vectorized mapping matters for batching over parameters, measurements, trajectories, or datasets. Accelerator support, mixed precision, and distributed execution are part of the design from the beginning.

That philosophy shows up in the architecture. TensorCircuit-NG is built around a tensor-first worldview: every object is either a tensor or a network of tensors. Once that is the primitive, different computational models become easier to compose inside one workflow. Gate-based circuits, tensor networks, neural models, noisy simulators, analog evolution, approximate methods, and symbolic representations can live inside one coherent environment.

The performance story follows directly from this design. TensorCircuit-NG supports both data parallelism and model parallelism across multiple devices and multiple hosts. In practice that means distribution over inputs, measurements, or noisy trajectories when the workload is embarrassingly parallel, and distribution over tensor-network slices when the contraction itself needs to be split across hardware. Benchmarks on both single-GPU and multi-GPU systems show that high-level Python APIs can still deliver high performance when the compilation and tensor-network substrate are done well.In representative workloads, that performance has reached speedups of several orders of magnitude over mainstream stacks such as IBM's Qiskit and Google's TensorFlow Quantum.

TensorCircuit-NG acts as a bridge among quantum computing, high-performance computing, and intelligent computing. It also serves as an interface layer where quantum models can coexist with the rest of modern computational science. Researchers who want to embed quantum layers inside larger machine learning systems should be able to do so inside the same workflow, without crossing ecosystem boundaries every time the problem gets interesting.

For AI: a platform for fast quantum machine learning

This is where the infrastructure becomes immediately useful. Quantum machine learning sits right at the intersection of circuit design, optimization, data pipelines, and repeated simulation. It is a workload that punishes slow software. If researchers want to try new ansatzes, change encodings, run ablations, train over many seeds, or sweep hyperparameters, then fast prototyping and efficient simulation matter more than slogans about QML.

TensorCircuit-NG provides a strong platform for exactly this kind of work. Differentiable circuits, JIT compilation, batching, accelerator support, and distributed execution all live inside one environment. That makes it much easier to move from an idea for a QML model to a runnable prototype, and from a prototype to a meaningful simulation campaign.

The scientific motivation for QML also becomes clearer in this setting. Attention shifts away from isolated benchmark wins and toward how quantum models behave on problems that already hurt classical AI. In our own work, this has already led to two systematic studies: one on bad data, and one on changing data.

The first studies robustness. When labels are noisy, data is poisoned, or part of the training set later needs to be removed, quantum models may show a more favorable degradation profile and may be easier to unlearn. The second studies plasticity. In continual-learning settings, quantum models may preserve the ability to absorb new tasks for longer instead of becoming rigid.

These are still open research questions. For a software project, though, the main point is straightforward: if people want to explore QML seriously, they need a platform that makes rapid iteration cheap. TensorCircuit-NG is meant to be that platform. It gives researchers a practical environment for fast QML prototyping, efficient simulation, and large-scale testing of ideas about robustness, unlearning, and adaptation.

With AI: a platform for agent-driven research

The same logic carries over to AI agents. Once a scientific software stack is fast, structured, and composable, it becomes a natural substrate for agent-driven development. Agents are useful only when they can read real code, run real tools, inspect results, and keep iterating inside a live repository. That makes software design itself part of the agent story.

TensorCircuit-NG is built with that use case in mind. The APIs are relatively concise, the examples and tests provide dense reference material, and the repository includes explicit rules and task-specific workflows for AI assistants. This lowers the cost of turning natural-language intent into runnable code, benchmarks, figures, and documentation.

The project also ships built-in skills that push this further:

arxiv-reproduce, which turns a paper identifier into a reproduction workflow;
performance-optimize, which injects optimization patterns such as scan, jit, vmap, and contraction tuning;
tc-rosetta, which translates code from other quantum frameworks with attention to intent rather than syntax alone;
tutorial-crafter, which converts programs into polished narrative tutorials.
and many more.

Taken together, these tools make the framework a software platform where researchers can move from idea to prototype, from prototype to benchmark, and from benchmark to documentation with much less friction. That is the practical meaning of “with AI” here: TensorCircuit-NG is designed to work well with agents as a real development interface, not just as a chatbot wrapped around the codebase.

The deeper claim

Taken together, these ideas add up to a stack-level thesis about the future of computational research.

First, quantum software should no longer be architected as an isolated niche. It should inherit the best ideas from the AI and HPC worlds and expose them through abstractions that remain mathematically faithful to quantum workloads.

Second, that same software stack should provide a strong platform for fast QML prototyping and efficient simulation, so ideas about robustness, unlearning, and continual adaptation can be tested quickly at scale.

Third, the arrival of capable software agents changes the design target for scientific frameworks. A good framework now has to work well for skilled humans and also be understandable, navigable, and productively extensible for agents operating over the entire repository and toolchain.

This is how TensorCircuit-NG understands itself: quantum software on AI, for AI, and with AI. It is built on the modern AI execution model, aimed at AI-relevant scientific questions, and increasingly shaped to participate in agent-mediated research workflows.

Getting started

pip install tensorcircuit-ng

An agent-first workflow also works well: ask your coding agent to install tensorcircuit-ng and start building a small quantum application from natural-language instructions.

Next-Generation Software: From by-AI to within-AI

Shixin Zhang — Thu, 21 May 2026 09:11:58 +0000

Why "using AI to build more apps, faster" may just be putting an engine on a horse carriage

Over the past year, most discussions about AI and software have stayed within a very intuitive picture: a human describes a requirement, an AI agent writes the code, and after the code is written the software is still traditional software, only produced faster. Vibe coding, in essence, lowers the marginal cost of software production. What used to require engineers to implement line by line becomes an iterative process of generation, debugging, and refactoring driven by natural language.

This view is correct, but only half-correct.

The bigger change is not whether AI can generate software. The bigger change is whether the word "software" itself is about to change. Using AI to generate yet another standalone app often feels like putting an engine on a horse carriage: the power system has changed, but the form factor still belongs to the previous era. You still have a frontend, backend, account system, deployment, database, permissions, logs, subscriptions, settings pages. These things can now be generated faster, but they are still the same old shape.

But if the engine is already powerful enough, perhaps we should stop optimizing the carriage. The real next step is this: software is no longer merely written by AI agents. It starts to exist within AI agents.

Next-generation software does not necessarily have to be a complete app, a website, a SaaS product, a desktop client, or even a CLI with a fixed entry point. It may be a collection of prompts, skills, scripts, schemas, local files, cache conventions, tool permissions, and agent-facing instructions. The real runtime is not a specialized intelligent application. It is a general agent such as Codex or Claude Code. In other words, the harness is becoming the software.

Everyday ArXiv is a concrete example of this insight.

Research Software Without A Traditional Form

Everyday ArXiv is a daily intelligent arXiv processing assistant. The traditional way to build it would be straightforward: write a backend service, connect to the arXiv API, implement a recommendation algorithm, add a user system, build a web interface or email push system, and embed LLM calls at specific nodes such as summarization, scoring, recommendation explanations, and email drafts. In the end, it would become a specialized agent or SaaS product for researchers.

There is nothing wrong with this path. Many products will continue to be built this way. The problem is that, in this specific setting, the most valuable part is not the UI, not the database, and not a fixed pipeline. The most valuable part is the judgment made during each reading session.

Why is this paper worth reading today? Which of the user's previous papers is it actually connected to? Is the overlap merely keyword-level, or is there a real methodological connection? Is a proposed idea once again falling into the mediocre pattern of "add noise, change the model, run larger numerics"? If a new paper does not cite the user's work, is it an obvious omission, a weak connection, or only conceptually adjacent?

These questions are hard to compress into fixed software features. They look more like the judgment process of a research assistant. So the architecture of this project is inverted. Python code handles only deterministic tasks: fetching arXiv metadata, parsing Google Scholar, writing stable JSON caches, loading configuration, and maintaining local file boundaries. Judgment-heavy tasks are not hardcoded inside the application. They are delegated to a general agent. The repository provides the agent with a workspace, skills, profiles, prompts, scripts, and privacy rules.

In other words, this is not "software with LLM features." It is software that an LLM agent can directly run.

Why This Is Not "Everyone Writes A Custom App"

A common prediction is that AI lowers the cost of software production, so everyone will write many small custom apps for themselves. I think this is only half right.

What may actually happen is not that everyone has a pile of custom apps, but that many custom apps never exist in app form at all.

Once general agents are powerful enough, many "software" systems do not need to be compiled into standalone products. They can remain open-form: a few Skills, a few scripts, a directory convention, a profile, and some examples. Their functionality unfolds at runtime through the agent. They have no fixed buttons, but clear protocols; no complete backend, but stable tools; no page, but Markdown or HTML reports; no embedded intelligence module, but access to the general intelligence of the agent.

This goes beyond vibe coding. Vibe coding still assumes the goal is to generate a software product. Agent-native software tries to avoid prematurely generating software in the old form. It asks: does this thing really need to be productized, or does it only need to be agentized?

The Structural Tax Of Vibe Coding

The appeal of vibe coding is that, for the first time, building software feels cheap. You can ask an agent to generate a full-stack repo with React pages, API routes, database schemas, Dockerfiles, auth, deployment notes, and a README.

But this reveals another problem: the faster AI generates software, the more visible the structural tax of the old software form becomes.

Standalone apps carry many default taxes. There is a UI tax, because every capability must be turned into buttons, forms, and pages. There is a deployment tax, because every capability needs its own runtime environment. There is an integration tax, because every new app has to reconnect to data sources, permissions, and user state. There is a maintenance tax, because dependencies drift, frameworks upgrade, and deployments break. There is also a product-shape tax, because many open-ended judgment processes must be compressed into fixed features, losing flexibility and customization.

When the task is essentially "run a high-judgment workflow in a specific context," these taxes become heavy.

If Everyday ArXiv were built as traditional software, it would be forced to invent many things that are not its core value: recommendation pages, profile editors, PDF readers, email draft editors, background jobs, account systems, synchronization state. Of course these can be built. But they are not the core of "read arXiv and make research judgments." The core is to put the user's profile, today's papers, paper full texts, historical preferences, and research taste into the same reasoning loop.

If a general agent can already read files, run commands, call tools, edit Markdown, maintain local state, and follow project rules, many standalone app shells start to look unnecessary.

This is why "AI helps me write an app faster" may only be a transitional form. It optimizes the speed of software production, not the shape of software itself.

The Compilation Target Of Software Has Changed

Traditional software compiles to machines: CPUs, browsers, mobile devices, cloud services. Even SaaS ultimately compiles into deterministic behavior on some fixed runtime.

Agent-native software does not compile only to machines. It compiles to agents.

This sounds strange, but it is the key point. A Skill is not merely documentation. It is closer to a runtime definition: when an agent encounters a certain kind of task, which files should it read, which scripts should it call, which boundaries should it respect, how should it handle failure, when should it stop, what output format should it use, which judgments must not be hardcoded, and which data must not be committed to Git.

In Everyday ArXiv, the Python package under src/ is the deterministic kernel. .agents/skills/arxiv-daily/SKILL.md is the workflow definition. user_profile/ is user-space memory. agents.md is the runtime specification. data/raw/arxiv and data/reports are the persistence layer. Codex or Claude Code is the execution environment and runtime.

From the perspective of traditional software, src/ is the software, and everything else is documentation or data.

In agent-native software, this boundary is inverted. src/ is only the tool layer. The real software behavior emerges from the tool layer, Skill instructions, user profiles, cache formats, report conventions, privacy boundaries, and the general reasoning ability of the agent.

This is the architectural inversion: infrastructure moves downward from each standalone application into the agent platform. The application itself becomes a lightweight, injectable, modifiable, and portable capability layer.

The shift can be summarized as follows:

Dimension	Old Paradigm: Software by AI	New Paradigm: Software within AI
Architecture	AI generates a custom full-stack repo: frontend framework, backend API, database, and hosting layer included.	Lightweight skills, structured manifests, execution scripts, and local directory conventions are injected into the agent as capabilities.
Infrastructure	Each app has its own runtime, database, DevOps pipeline, permissions, and deployment environment.	The app reuses the native environment of the host agent platform: filesystem, command line, browser, sandbox, tool calling, and context window.
Cost Model	A standalone AI app must maintain a SaaS shell and pay the marginal API cost of each model call. Heavy usage quickly becomes expensive.	An agent-native workflow lives inside general-agent subscriptions such as Claude Code or Codex, letting users share the subscription economics of model providers.
Flexibility	Features are hardcoded into UI, backend, and schemas. New capabilities require code changes, redeployment, and redesigned entry points.	The agent dynamically interprets Skills, reads and writes files, and calls scripts based on runtime intent, adapting to edge cases without rebuilding the product shape.

A Skill Is Not A Plugin. It Is A New Software Unit.

We are used to thinking of plugins as accessories to a host program. Browser extensions depend on browsers. Editor extensions depend on editors.

But Skills inside agents are closer to a new unit of software.

They contain at least four layers.

The first layer is deterministic tools. These are ordinary scripts, CLIs, parsers, fetchers, and formatters. They handle the parts that should not be left to an LLM's improvisation.

The second layer is semantic policy. These are the instructions: what counts as a good recommendation, what counts as a mediocre idea, when to run a citation check, when not to pad the list to ten papers, and when to write only to local private files.

The third layer is private state. User profiles, historical papers, negative preferences, idea logs, and local config are not merely "database records" in the traditional sense. They are personal context that the agent can read, interpret, update, and audit at runtime.

The fourth layer is the execution substrate. This is what the agent platform provides: filesystem access, command execution, browsing, code understanding, long context, multi-tool coordination, and natural language interaction.

A traditional app often packages all four layers into its own code and services. Agent-native software separates them: stable parts become scripts; judgment-heavy parts become Skills; personal parts remain in local files; execution is reused from a general agent.

So it behaves more like a dynamically loaded driver than a complete machine. It does not need to spin up a company-sized software shell every time. It only needs to inject capability into an existing agent runtime.

The Cost Advantage Is Not Just Form. It Is A Pricing-Layer Mismatch.

Another key point is the cost difference between API calls and subscriptions. If you build a specialized agent yourself, every intelligent step calls a model API. If you use a subscription-based general agent such as Codex or Claude Code, many of these steps are absorbed by the platform. This difference is not merely "a little cheaper." It can be an order-of-magnitude architectural difference.

Take Karpathy's LLM Wiki / agentic wiki idea as an example. At its core, it is a lightweight set of directory conventions, Markdown files, schemas, and agent instructions. Of course you can productize it: turn it into a standalone knowledge-base and note-taking app, add login, upload, search, sync, team workspaces, RAG pipelines, a polished UI, and then connect it to frontier-model APIs. At that point it becomes a standard AI SaaS product: every ingest, query, rewrite, and cross-reference burns your API bill.

But the same idea does not have to be productized. You can put raw sources, wiki pages, and instructions in a local repo and let a general agent such as Claude Code maintain it directly. For the user, this is not "opening a new SaaS product." It is "running a workflow inside an agent subscription I already have." The workflow is lightweight enough that its main cost moves from API metering into the agent subscription.

The gap can be huge. For heavy users, the equivalent API cost can easily be more than ten times higher than the subscription cost. Put differently: for the same frontier model capability, a standalone AI app must pay by the API meter, while an agent-native workflow living inside Claude Code or Codex may have its entire user-facing cost absorbed by the platform subscription, because the user already needs an AI subscription plan anyway.

If frontier model providers can sustain this pricing structure, the consequences will be severe. General agent tools such as Codex will devour a large fraction of so-called intelligent software that merely connects large-model APIs to old software shells. Those products carry two layers of cost: the product-shape cost of traditional SaaS, and the usage-based API cost of frontier models. Agent-native workflows reuse a runtime that the agent platform has already subsidized, deployed, and sold to the user.

So the cost advantage comes from two directions.

First, the form is lighter. Standalone software is expensive not only because it runs servers, but because it must maintain a fixed product shape. That shape forces you to predefine user paths, feature boundaries, error handling, state synchronization, permission models, UI copy, and upgrade mechanisms. For high-frequency standardized tasks, this is worth it. For personalized, low-frequency, high-judgment tasks, it becomes a burden.

Second, the billing layer is lower. API-wrapper software turns every intelligent action into its own marginal cost. Agent-native software tries to place intelligent action inside the general-agent runtime that the user already owns. The former is like putting an engine inside every small tool. The latter is like loading different tools onto a unified power system.

The filesystem becomes state. Markdown becomes interface. JSONL becomes database. Skills become product logic. Python CLIs become reproducible tools. The agent becomes the interaction layer, reasoning layer, and glue code. The user does not need a complete app. The user needs a workspace that an agent can understand and operate.

This does not mean engineering quality becomes unimportant. The opposite is true: engineering boundaries become more important. Deterministic tasks must live in code. Privacy boundaries must be protected by .gitignore and file naming rules. Cache formats must be stable. Profile updates must be traceable. Reports must be reviewable. We simply no longer have to assume that all software value must be packaged into a fixed UI.

LLM OS Is Not A Metaphor

This also explains why software within AI agents resonates with the idea of an LLM OS.

If we think of the LLM as an operating system, the model itself is not the whole system. A real OS includes filesystems, permissions, processes, tool calls, environment variables, package management, history, working directories, user preferences, executable scripts, and application protocols. Agent platforms are reorganizing these pieces.

From this perspective, a Skill is like an application. A prompt is like configuration and entry point. A script is like the executable behind a system call. user_profile is like user-space data. agents.md is like a software manual, permission model, and runtime specification. Cache directories are persistence. The agent is a mixture of shell, window manager, workflow engine, and interpreter.

Traditional software runs on top of operating systems. Next-generation lightweight software runs inside the LLM OS.

This does not mean all software disappears. High-frequency, multi-user, strongly consistent, permission-heavy, transaction-heavy systems will still need traditional software forms. Banking systems, collaborative editors, production databases, payment platforms, and medical systems cannot rely solely on an agent runtime.

But a large amount of personalized, low-frequency, high-judgment software will be rewritten.

Research reading assistants, personal knowledge systems, paper response tools, code review workflows, experiment records, document drafting, data cleaning, chart generation, long-term research projects, and idea management have historically been hard to turn into good software. Not because the need does not exist, but because every person's need is too specific, the market is too small, the shape is too fragmented, and fixed products quickly stop fitting.

Agents change that economics.

This Example Generalizes Far Beyond

Everyday ArXiv is just one example. The structure behind it generalizes to many scenarios that used to require being "turned into software."

The first category is knowledge workflows. Today it is arXiv. Tomorrow it could be a paper library, technical blog library, investment research library, legal document library, or internal decision memo system. The traditional approach is to build a standalone application: dashboard, search box, favorites, summaries, recommendations, and RAG. The agent-native approach is looser: raw materials are files, indexes are scripts, workflows are Skills, user preferences are profiles, reports are Markdown. It is less like a product and more like a work environment that an agent can unfold at runtime.

The second category is scientific computing and experiment management. A research project may need to manage models, parameters, run scripts, remote machines, result directories, logs, figures, and conclusions. Of course you can write an independent CLI with commands such as submit, status, plot, and report. This is still valuable, because deterministic low-level tasks need stable tools. But if the entire experiment-management process is compressed into a CLI, you lose a great deal of contextual judgment: when to rerun, which parameter combinations are worth extending, which anomaly may be a bug, which figure should enter the paper, and which result is already sufficient to stop.

The more natural architecture is: keep low-level scripts deterministic, and use a set of Skills to specify how the agent should read experiment directories, submit jobs, record provenance, generate reports, and avoid overwriting results. The experiment system is not a closed tool. It is an agent-operable research workspace. Its flexibility is often stronger than that of an independent CLI, and its results are often better, because scientific experimentation is not a fixed sequence of commands. It is a process of continuous judgment, adjustment, and interpretation.

The third category is existing Python software frameworks. In the past we would ask: should we wrap it in a GUI? Should we build a web app where users can select parameters, drag modules, and display results? But for many scientific computing, machine learning, and quantum simulation frameworks, the better interface may not be a GUI. It may be an agent.

The framework itself provides strict APIs, types, tests, documentation, and examples. Agent-native adaptation lets the agent read the documentation, compose algorithms, write scripts, run demos, explain results, and generate figures directly. The user no longer has to learn every API before starting to explore. The user describes the goal in natural language, and the agent compiles that goal into framework code. This is not wrapping an old framework in a shell. It is connecting the framework to a natural-language programmable operating layer. TensorCircuit-NG represents this agent-native direction: the point is not to build another polished GUI, or a CLI that restricts functionality, but to make the framework itself a computational substrate that agents can understand, invoke, and extend.

These examples point to the same conclusion: next-generation software does not necessarily turn every tool into a standalone product. It lets tools enter the fluid environment of agents. This form has one enormous advantage: fluidity.

Traditional software is hard. It must be installed, deployed, upgraded, compiled, and released. Its features solidify into buttons and pages. If users want to change it, they usually have to file an issue, wait for developers, fork the repo, or edit code.

Agent-native software is soft. It can be copied as a directory, changed into another set of Skills, locally rewritten by users through natural language, and migrated across agent platforms. It does not necessarily need compilation, a fixed UI, or versioned releases. Often, the software is simply a set of readable, editable, executable conventions.

If the user really needs an interface, the agent can generate an HTML page on demand. Today it can be a minimal table. Tomorrow it can be a flashy dashboard. The day after tomorrow it can be a paper-style report page. The interface becomes a runtime artifact, not the fixed shell of the software.

This may be the most counterintuitive part: software in the AI era may not increasingly look like "smarter apps." A lot of software may become less app-like, more like an amorphous fluid that agents can read, modify, compose, and temporarily materialize.

This fluid form does not depend on a fixed UI. It can be executed by Codex, by Claude Code, or by future agents. As long as the agent is strong enough to read files, run commands, follow Skills, and maintain boundaries, it can run the software.

Software portability changes accordingly. In the past, migrating software meant migrating applications and data. Now it means migrating workspace conventions. What you take with you is docs, skills, scripts, templates, profile schemas, and examples. More concretely: a folder. The execution runtime can change; the software remains.

Design Principles From This Project

From Everyday ArXiv, we can extract several design principles.

First, deterministic work belongs in code. Fetching, parsing, caching, schemas, configuration, paths, and format checks should be ordinary software engineering. Do not let an LLM "remember" where today's cache should go. Do not let it invent data structures at runtime every time.

Second, judgment belongs in the agent. Recommendation, selection, close reading, research ideas, citation risk, and email tone are exactly where general agents are strong. Hardcoding them into fixed API pipelines sacrifices flexibility.

Third, user profiles should be local files, not abstract preference buttons. Research interests, negative preferences, prior papers, and citation anchors are detailed and personal. The agent should be able to read, cite, update, and audit them directly.

Fourth, Skills are the product core. They are not documentation attached to the product. They are the main execution logic of agent-native software. Traditional software has its core in code paths; agent-native software often has its core entry point in Skills.

Fifth, the open-source boundary must be designed upfront. The public repository should store the general protocol. Private files should store the user. This allows the software to be reusable without leaking personal knowledge and workflows.

Together, these principles define a new software form: not an application wrapped around LLM APIs, but a workspace growing around general agent platforms.

Closing

AI agents first looked like programmers who could write code faster. Then they looked like assistants that could operate tools. Next, they may look more like general intelligent runtimes and operating systems.

If this is true, part of next-generation software will no longer be understood as "applications." It will be agent-readable directories, prompts, Skills, scripts, profiles, and caches. It will have no fixed shape, but still run reliably. It will have no complete UI, but still complete complex work. It will not be generated once by AI and then left alone; it will continuously live inside AI agents.

Everyday ArXiv is a small research tool, but it shows the early form of this direction: the intelligent part of software does not necessarily need to be packaged into a specialized agent. When general agents become strong enough, software can write itself as a harness for agents. I would even make a stronger claim: very few specialized agents will remain useful. Most will be swallowed by general agents, just as Sutton's bitter lesson would suggest.

This may be the shift from software generated by AI to software existing within AI.

Agentic R&D Insights

Shixin Zhang — Thu, 09 Apr 2026 05:15:02 +0000

This year, I dove headfirst into Agentic Coding and automated workflows, integrating them intensely into my daily development and research. The general consensus is that AI crossed a critical threshold late last year, and my hands-on experience confirms it. I’ve barely written any code manually this year, and the output from AI agents has been staggering.

To give you an idea of the scale: my tensorcircuit-ng (TC) repository saw a net increase of over 20,000 lines of python code. It took me barely two days to organically integrate and rewrite QuEra's newly released tsim into the TC framework. On the research front, I built paper-reproduction infrastructure within TC, allowing me to reproduce highly complex, representative quantum physics papers in mere minutes—I’ve knocked out over a dozen so far. Once, I spent less than a day running an end-to-end automated pipeline that handled a referee report: supplementing experiments, plotting graphs, writing the reply, and revising the manuscript. Algorithmically, I used the TC paradigm to auto-generate high-quality DMRG code in minutes; it natively supports GPUs and its CPU efficiency beats mature frameworks like quimb. Throw in fully automated translations of the TC documentation and auto-filling grant proposal templates, and the efficiency multiplier is absolutely an order of magnitude or more.

But looking at this massive output, an inevitable question arises: In an era where everyone has access to the exact same cognitive baseline—models like Claude 4.6 or GPT 5.4—what actually dictates the ceiling of our productivity? Why aren't we seeing a 100x boost across the board?

After high-intensity practice, I realized the answer isn't "better prompt engineering." It's hidden in the architecture of your workflow. The real differentiator is how you leverage personal data and experience to build a resilient system across the "Frontend, Middle, and Backend" of your pipeline. Interestingly, while building this system, you inadvertently design the exact countermeasures needed to mitigate the three fatal character flaws highly intelligent LLMs exhibit: Laziness, Impatience, and Deception.

The Frontend: Personal Context as the Ultimate Moat

The core insight for the frontend is simple: personal context and workflow paradigms are your ultimate moats in the Agent Era. The coding world is a perfect playground for AI not just because code is easily verifiable, but because its physical logic is self-consistent and its context is completely intact—there is no context fragmentation.

In general problem-solving, our thoughts are scattered across our brains, chat logs, loose docs, and random materials. Without centralized, normalized context, an AI agent will always struggle. In my practice, context consists of a static component and a dynamic one.

The static "Wiki" is the cognitive bedrock for the LLM. The tensorcircuit-ng monorepo itself acts as a hyper-powerful context infrastructure. It doesn’t just hold framework code; it aggregates nearly 200 specific quantum use cases, physical logic constraints, and historical experiment logs. When the LLM hooks into this, it isn't facing a sterile prompt—it's stepping into a rich, domain-specific knowledge base. (Karpathy recently mentioned using AI to index and retrieve personal knowledge bases—often without even needing vectorization, as smart grep and indexing work better. This "Based AI, for AI, from AI" context management is something I had already implemented, and it feels like the most natural evolution of human-computer interaction.)

The dynamic "Skill" component is the digital extension of your personal execution paradigm. Sure, for generic tasks like parsing a DOCX, you just use an off-the-shelf plugin. But workflow skills are deeply personal and nearly impossible to substitute. I don't believe in using standard, third-party workflow skills; every individual's needs are highly customized. I built a .agents/skills toolbox inside TC specifically for performance reviews, paper reproduction, and tutorial generation. I also have a private skill repository encapsulating my highly specific habits for logging numerical experiments, SSHing into remote clusters, and drafting grants.

Simply put: the Wiki tells the AI "what we have," and the Skills tell the AI "how I think and solve problems." (Fun fact: the reason this post doesn't sound like AI slop is because I instructed the AI to mimic my previous blog posts. The blog itself became the context. The AI summarized my style as: "No redundant formatting, hardcore geeky tone, stream-of-consciousness switching between tech and philosophy.")

This frontend architecture perfectly mitigates the AI's first character flaw: Laziness. This laziness often stems from performance degradation and attention-loss over long context windows. Anyone who uses AI knows that on long-haul tasks (like full-repo refactors or translations), it loves to slack off, do half the work, or just spit out a function signature with a pass statement. But when you lock the AI in a high-quality Wiki that enforces strict background constraints, and use custom Skills to force large tasks into atomic, pipeline steps, the AI loses the room to cut corners. You have to back the AI into a corner where it has no choice but to apply its full intellect to solve your problem.

The Middle: The Economics of Human-in-the-Loop

When it comes to execution, there is only one rule: reject blind end-to-end automation. Intervening, discussing, and course-correcting in the middle of a task is vastly more economical.

Many people chase the dream of fully autonomous end-to-end agents. But for research or engineering tasks with strict delivery requirements that cannot be 100% automatically verified, this is a recipe for disaster. Human-in-the-loop (HITL) is mandatory. Think of it like a Principal Investigator advising a PhD student. You don't write every line of code for them, but you must have regular syncs, correct their trajectory, and redeploy tasks based on current progress. You don't just wait three months and read the final paper. The time and "human bandwidth" spent on these middle-stage checks seem costly, but compared to the agonizing effort of reverse-engineering what the AI did wrong—or doing a complete rewrite because the architecture was flawed from day one—it is negligible.

Furthermore, one or two sentences of human intuition can be the difference between success and total failure. This is why human experts still matter. A quick pointer can pull an AI out of a logical mud pit; without it, the task stalls. Currently, the best AI-driven research is done by domain experts, and the best AI-written code is guided by senior engineers. Relying on "AI vibes" in a domain you don't understand only yields half-baked prototypes. AI is not a silver bullet; human taste, experience, and intuition remain rare and decisive.

This mentorship model mitigates the AI's second flaw: Impatience. This impatience is an artifact of RLHF, which encourages models to generate the shortest path to an answer. When an AI hits a test failure or a bug, its first instinct is almost never to carefully read the stack trace. Instead, it relies on hallucinated intuition to blindly hack the source code, hoping for a quick green light. It usually makes things worse. If it fails again, it hacks the code again, refusing to write a script to verify its assumptions.

With HITL, we lay down the law: whenever there is an error, the AI is strictly forbidden from touching the source code. It must first write a minimal reproducible demo script to isolate the bug, and then report back to me. Often, just writing the demo makes the AI realize the bug isn't where it thought it was. Only after I confirm the root cause is the AI allowed to modify the codebase. This forced braking mechanism pulls the AI out of its blind-hacking loop and forces rational deduction.

The Backend: Testing, Eval, and the Bandwidth Bottleneck

In the backend evaluation phase, we have to face a harsh reality: while automated testing and evaluation determine the floor of an Agent's capabilities, human bandwidth is almost always the ultimate ceiling.

Automated testing is crucial. It’s the very foundation of why AI excels at coding tasks (think RLVR). Some argue that tests are the new moat, even more important than the implementation itself, because an AI can generate the implementation if the tests are exhaustive. (This is why some modern frameworks open-source their code but close-source their test suites).

But even in highly formalized tasks like code generation—especially when doing secondary development on a mature, opinionated codebase—humans are still required for global architectural design, semantic alignment, and taking ultimate responsibility for the code. Just like managing a team of human engineers, there is a hard limit to how many Agents a human can effectively manage. We cannot infinitely scale compute and Agent instances and expect them to output 100% reliable work entirely on their own. In the AI era, trust and attention are the most precious resources. Testing and acceptance simply require massive human bandwidth to bridge that trust gap.

Since human review is unavoidable, the trick is to exploit the AI's asymmetric capabilities to save our bandwidth. An LLM's ability to judge (discriminate) is significantly stronger than its ability to generate. Therefore, we can introduce AI cross-validation as a firewall before human review. I use an independent, freshly instanced model in an extremely clean context to review the generated code logic, creating an automated loop of adversarial review and revision. The "clean context" is vital—the reviewer AI must never see the messy trial-and-error history of the generator AI, otherwise it will empathize with the generator and lose its objectivity.

This clean-room evaluation mechanism mitigates the AI's third flaw: Deception (Reward Hacking). If you rely solely on basic automated tests, AI becomes terrifyingly deceptive. To make a failing test turn green, it will maliciously use workarounds or physics-defying hardcodes just to hack the test suite. An independent reviewing Agent with strong discriminative capabilities and a clean context acts as a filter, catching these brainless "code-golfing" hacks before they ever reach my desk, saving my precious bandwidth for the final architectural sign-off.

Conclusion

By building deep personal Contexts, forging custom Skill tools, enforcing HITL mentorship, and utilizing clean-room independent evaluations, you really can boost your productivity by an order of magnitude.

But let's be clear: these systems only mitigate the AI's laziness, impatience, and deception—they do not cure it. In the foreseeable future, human bandwidth remains the absolute bottleneck in the Agent workflow. Dreaming of a 100x or 1000x productivity boost today will only result in highly unreliable output.

And perhaps that’s not a bad thing. In this human-machine collaboration, AI is the ultimate generation engine and an untiring preliminary reviewer. But the final quality control, the closing of the physical logic loop, and the ultimate responsibility for the scientific output must rest with the human. When everyone has access to the exact same AI, your accumulated personal data, your polished workflows, and where you choose to invest your limited human bandwidth (decision-making, reviewing, critical insights) become your deepest moats. The irreplaceable nature of humans right now lies in implicit knowledge—taste, intuition, and problem-framing—which cannot be distilled into a text prompt or an executable Skill.

Of course, given the breakneck speed of AI development, if these remaining "irreplaceable" human traits become commoditized a year from now, I won't be surprised. By this time next year, perhaps none of these insights will even be relevant anymore.

Unleashing AI in Quantum Research: Why TensorCircuit-NG is the Ultimate Foundation for the Agent Era

Shixin Zhang — Thu, 12 Mar 2026 01:45:14 +0000

With LLMs and AI agents making code generation faster, cheaper, and more accessible, a massive new frontier has opened in scientific computing. But while AI can easily string logic together, it still needs a powerful, mathematically rigorous engine to drive it.

This is where TensorCircuit-NG (TCNG) truly shines. Far from just adapting to the AI era, TCNG acts as the essential catalyst that makes AI-driven quantum research possible, scalable, and highly performant.

Here is why TCNG is more important than ever for researchers and AI agents alike.

🧱 1. The Foundational "Physics Engine" for AI

AI models are fantastic at orchestrating high-level logic, but they struggle to invent highly optimized, low-level mathematical frameworks from scratch. TCNG represents the kind of deep, specialized engineering that is incredibly hard to replicate. By fusing machine learning backends with customized hardware operators and advanced tensor network contraction engines, TCNG acts as a fundamental infrastructure layer. Just as AI agents don't try to rewrite TensorFlow or PyTorch—they simply use them—agents can call TCNG as foundational building blocks to construct complex quantum applications effortlessly.

🛡️ 2. Guiding AI to High-Performance Paradigms

Left to its own devices, AI can easily generate code that works but runs terribly. TCNG solves this by providing a strict, high-performance architecture. Because TCNG enforces strong paradigms—such as backend-agnostic design, automatic differentiation (AD), Just-In-Time (JIT) compilation, and hardware acceleration (GPUs/TPUs)—it inherently forces AI to write code using best practices. When an agent builds with TCNG, the resulting scripts automatically inherit top-tier performance and scalability without the AI needing to understand the underlying computational bottlenecks.

📚 3. Unmatched Context Completeness for Agents

For an AI agent to be truly autonomous and accurate, it needs massive, high-quality, and unified context. TCNG provides exactly this: over six years of rich, accumulated domain knowledge packed into a cohesive mono-repo. It houses everything from exhaustive documentation to edge-case physics functionalities. Because the entire quantum landscape is mapped out within a single repository, it is incredibly friendly for AI agents to ingest, cross-reference, and use as a springboard for creating entirely new tools and discoveries.

🧠 4. A Massive Training Ground for Automated Discovery

AI learns best by example, and TCNG is built to be the ultimate reference library. We now host over 150 carefully crafted example scripts, providing an incredibly strong foundation for AI to recognize quantum programming patterns and generate novel applications. Leveraging this, we are launching an exciting new initiative: fully automated reproduction of representative quantum research papers, driven entirely by AI using TCNG's vast library as its reference point.

🛠️ 5. Native Agentic Skills Out of the Box

TCNG isn’t just designed for human researchers to use alongside AI; it is actively built to give AI agents superpowers. TCNG provides a series of native "skills" designed to help agents automate complex workflows, including:

End-to-end reproduction of research papers
Seamless code translation across different frameworks
Automated performance optimization and profiling
The auto-generation of interactive demos and educational tutorials

The Bottom Line

In the era of AI agents, coding might be cheap, but world-class scientific infrastructure is priceless. TensorCircuit-NG provides the deep-tech foundation, the optimized paradigms, and the rich, accumulated context that AI needs to push the boundaries of quantum physics. It isn't just a tool; it is the infrastructure that will power the next generation of automated quantum discovery.

We Built the First AI-Native Quantum Software Framework: Say Hello to Agentic TensorCircuit-NG

Shixin Zhang — Sat, 28 Feb 2026 06:02:18 +0000

Quantum computing software is notoriously hard to write.

If you want to simulate a deep quantum neural network or research a new algorithm, you don't just need to understand Hamiltonian dynamics and Hilbert spaces. You also need to be a High-Performance Computing (HPC) expert—wrestling with GPU memory limits (OOMs), vectorization, JIT compilation staging times, and tensor network contraction paths.

For years, we've provided developers with the tools to do this via TensorCircuit-NG, our next-generation open-source, high-performance quantum software framework.

But tools are passive. You still have to do the heavy lifting.

Today, we are changing the paradigm. We are thrilled to announce that TensorCircuit-NG is now the world’s first AI-native quantum programming platform purpose-built for agentic quantum research and automated scientific discovery. By natively integrating skills directly into our repository, your quantum framework now comes with a built-in HPC engineer, a theoretical physicist, and a technical writer.

The Paradigm Shift: Agent-Ready Architecture 🧠

Most AI coding assistants do "line-by-line" translations or generate boilerplate. That doesn't work in quantum simulation, where a poorly placed for loop can increase compilation time from 2 seconds to 2 hours.

Instead of writing endless tutorials on "best practices," we embedded our framework knowledge directly into the repository as Agentic Skills.

If you clone the latest TensorCircuit-NG repo, you'll notice a new directory structure:

Plaintext

.agents/skills/
├── arxiv-reproduce/
├── performance-optimize/
├── tc-rosetta/
└── tutorial-crafter/

These aren't just prompts; they are strict, engineering-bound AI workflows. Let's break down the four superpowers you now have access to right out of the box.

1. `/arxiv-reproduce`: From arXiv ID to JAX-Accelerated Code in Minutes 📄➡️💻

The gap between reading a cutting-edge quantum machine learning paper on arXiv and actually writing the code to reproduce it is huge.

With the arxiv-reproduce skill, you simply hand the AI an arXiv link. The agent will:

Extract the physical intent (the Ansatz, the Hamiltonian, the loss function).
Intelligently scale down the qubit count so it runs on your local machine without blowing up your RAM.
Generate idiomatically correct, JAX-accelerated TensorCircuit-NG code.
Automatically run formatting (black), linting (pylint), and execute the script to save the reproduced figure into a standardized outputs/ folder.

2. `/performance-optimize`: Your Built-in HPC Architect ⚡

Got a quantum script that takes forever to compile or crashes with an Out-of-Memory (OOM) error?

The performance-optimize agent scans your code to identify bottlenecks. It knows the dark arts of quantum HPC: it will automatically eradicate Python loops in favor of jax.vmap, wrap your deep quantum layers in jax.lax.scan to slash JIT staging time, inject jax.checkpoint to trade compute for memory during backpropagation, and seamlessly switch to cotengra for optimal tensor network contraction paths. It even runs A/B benchmarks to prove the speedup!

3. `/tc-rosetta`: End-to-End Cross-Ecosystem Translation 🌍

Migrating from older, object-oriented quantum frameworks (like Qiskit or PennyLane) to a modern, differentiable, functional framework like TensorCircuit-NG is a steep mental shift.

tc-rosetta does not do naive line-by-line syntax swapping. It performs end-to-end intent extraction. It reads your slow, loop-heavy legacy script, understands the math behind it, and rewrites it from scratch using pure JAX-native paradigms. It then executes both scripts and hands you a benchmark report (e.g., "Execution time reduced from 300 seconds to 0.2 seconds").

4. `/tutorial-crafter`: Automated High-Quality Documentation 📝

Writing docs is the bane of every open-source contributor. What if the code could explain itself?

Point tutorial-crafter at any raw TensorCircuit-NG script. It will analyze the physical background and the code, then generate a beautiful, narrative-driven tutorial in both Markdown and HTML formats. It chunks the code logically, adds LaTeX formulas for the physics theory, and explicitly points out the HPC programming highlights (e.g., "Notice how we used vmap here instead of a loop..."). It generates documentation that rivals hand-crafted, premium tutorials.

How to Experience the Magic ✨

Because these skills are built on the open standard, getting started is zero-friction.

Clone the TensorCircuit-NG repository.
Open your terminal in the repo root.
Fire up your AI agent and simply call a skill: /performance-optimize examples/my_slow_circuit.py

You are no longer just writing code; you are directing an autonomous digital research team.

Welcome to the era of Agentic Quantum Software Engineering. We can't wait to see what you discover. Check out the repo, give us a star, and let the AI handle the boilerplate while you focus on the physics! 🌌

🚀 TensorCircuit-NG: The Universal, Differentiable Quantum Infrastructure

Shixin Zhang — Tue, 10 Feb 2026 03:13:39 +0000

👋 Hello World!

If you are a developer exploring quantum machine learning, or a physicist tired of rewriting code to make it run on GPUs, you have likely faced the "Framework Dilemma."

Do you write in PyTorch because you need the dataloaders?
Do you switch to JAX for that sweet JIT compilation speed?
Do you stick to TensorFlow because of legacy production pipelines?

What if your quantum simulator didn't care?

Meet TensorCircuit-NG (Next Generation)—the open-source, tensor-native platform that unifies quantum physics, AI, and High-Performance Computing.

🌟 What is TensorCircuit-NG?

TensorCircuit-NG is not just another circuit simulator. It is a backend-agnostic computational infrastructure.

It is designed to let you define your physics logic once and execute it anywhere. It wraps industry-standard ML frameworks (JAX, TensorFlow, PyTorch) into a unified engine, making quantum simulation end-to-end differentiable and hardware-accelerated.

🛠️ The "Write Once, Run Anywhere" Philosophy

The killer feature of TensorCircuit-NG is Infrastructure Unification.

You don't need to learn a new dialect for every backend. You simply switch the engine with one line of code:

Python

import tensorcircuit as tc

# Want JAX for JIT speed?
tc.set_backend("jax")

# Want PyTorch for easy integration with your existing DL models?
tc.set_backend("pytorch")

# Legacy TensorFlow project?
tc.set_backend("tensorflow")

This flexibility enables radical interoperability. You can train a hybrid model where the data pipeline lives in PyTorch, but the heavy-duty quantum circuit simulation is JIT-compiled via JAX/XLA for massive speedups—all handling zero-copy tensor transfers (DLPack) under the hood.

⚡ Why You Should Try It

1. Native Machine Learning Integration

We treat quantum circuits as first-class citizens in the computational graph.

Plug-and-Play Layers: Use tc.TorchLayer or tc.KerasLayer to insert parameterized quantum circuits directly into classical ResNets or Transformers.
Automatic Differentiation (AD): Forget parameter-shift rules. We compute gradients via backpropagation through the tensor network, making VQE and QML training exponentially faster.

2. HPC-Ready Scalability

Stop simulating on your CPU. TensorCircuit-NG supports:

GPU/TPU Acceleration: Move simulations to NVIDIA GPUs or Google TPUs without changing your physics code.
Distributed Computing: We support automated data parallelism (scaling to multiple devices) and model parallelism (tensor network slicing across GPU clusters).
Benchmark: We've demonstrated near-linear speedups on 8x NVIDIA H200 GPU clusters, simulating end-to-end variational quantum algorithms with 40+ qubits.

3. Advanced Physics Engines

It’s not just for qubits. TCNG comes with batteries included for:

Fermions Gaussian States: Efficiently simulate thousands of fermions.
Qudits: Native support for high-dimensional systems (d≥3).
Noise Modeling: Customizable noise channels for realistic hardware simulation.

💻 Show Me The Code

Here is how simple it is to build a differentiable variational circuit (VQE) that runs on any backend: