Quantum Twin

Inspiration

I have been interested in cybersecurity since I was a kid. I liked learning how systems get attacked, how defenders stop those attacks, and why small security mistakes can cause big problems.

Then I started learning about quantum computing.

At first, I thought it was just a much faster computer. But I learned that powerful quantum computers could one day break cryptography like RSA, which is still used across the internet for signatures, keys, and secure communication. RSA and other cryptographic algorithms are the foundation of the internet; when they get compromised, there will be utter chaos.

That made me ask:

What happens to all the software that still depends on RSA?

I found that post-quantum algorithms like ML-DSA already exist. But replacing RSA in a real project is not simple. Cryptography can be connected to APIs, databases, stored signatures, key files, and verification code. One missed file can break the whole system.

And trusting one AI agent to make every security change correctly felt risky.

That is why I built Quantum Twin.

What it does

Quantum Twin helps developers move Node.js and TypeScript projects from RSA signatures to post-quantum ML-DSA signatures.

It scans the repository, finds where cryptography is used, and creates a migration plan with GPT-5.6.

Then it launches two separate Codex agents in isolated Git worktrees. Each agent builds its own solution.

For example, one agent might fully replace RSA, while the other keeps support for old RSA signatures and uses ML-DSA for new ones.

Quantum Twin then tests both solutions for:

Security
Compatibility
Build errors
Invalid or damaged signatures
Dependency changes
Signature size
Speed

Any solution that fails a required test is rejected.

The developer receives the best branch, the code changes, the test results, and a clear explanation of why it was selected.

How we built it

Quantum Twin is built with Node.js and TypeScript.

GPT-5.6 understands the repository, creates the migration plan, and explains the results.

Codex makes the code changes.

Git worktrees keep both agents separate, and Zod checks that all AI outputs follow the correct format.

The final pass or fail decision comes from real tests, not from the AI.

Challenges

One major challenge was finding the full cryptographic flow.

A signature may be created in one file, stored in another, sent through an API, and verified somewhere else.

Another challenge was making the two agents truly independent. Git worktrees solved that by giving each agent its own branch and folder.

We also had to test more than the normal success case.

For example, Quantum Twin checks what happens when the message changes, the wrong key is used, or the signature is damaged.

Post-quantum signatures can also be much larger, so we had to measure storage, payload size, and performance.

What we learned

I learned that the quantum threat is serious, but the hardest part is not only creating safer algorithms.

The hard part is moving real software to those algorithms without breaking anything.

I also learned that AI-generated security code should not be trusted just because it looks correct.

It should be isolated, tested, compared, and supported by evidence.

What's next

Next, I want Quantum Twin to support more languages, more post-quantum algorithms, hybrid cryptography, GitHub pull requests, and larger projects with multiple services.

The same twin-agent system could also be used for other risky changes, such as fixing authentication flaws or replacing unsafe dependencies.

The main idea stays the same:

Do not trust one generated solution. Build two, test both, and choose based on proof.