What building RL environments taught me about coding and the quantum clock I’m building Qlyphs, which started with a wallet and native assets on Quantus. Alongside that, I worked with @erudictus on reinforcement learning environments for hardware design. That work changed how I code with agents. It also made me take a particular possibility seriously: AI could accelerate the research that determines how much quantum hardware is needed to break the cryptography we rely on today. The quantum timeline depends on more than hardware A practical quantum attack depends on both the machines we can build and the resources an attack requires. As hardware improves, researchers can also find ways to perform the same computation with less. In 2019, Craig Gidney and Martin Ekerå estimated that factoring an RSA-2048 integer would require about 20 million noisy qubits running for eight hours. In 2025, Gidney estimated fewer than one million noisy qubits running for less than a week, under the same hardware assumptions. Improvements in arithmetic and error correction made a smaller machine possible, with a longer runtime. That reduction was not presented as an AI result. It demonstrates how much the requirements can change through better methods. AI is already contributing to this kind of work. DeepMind’s AlphaTensor-Quantum uses reinforcement learning to reduce T gates, costly operations in fault-tolerant quantum computing. It outperformed previous optimization methods on a set of arithmetic benchmarks and recovered efficient constructions used in parts of Shor’s algorithm. Some quantum circuit optimization tasks have a structure I recognize: propose a solution, check that it preserves the intended computation, measure its cost, and use the result to guide another attempt. What our hardware research taught me In our environments, models produced circuits or PCB layouts, and tools evaluated them through simulation and design checks. We trained against that feedback, then evaluated the models on tasks they hadn’t seen during training. On one routing task, our reward gave every legal but over-budget board the same score. The model learned to produce legal boards, then stalled. Making a board better without yet meeting the budget earned it no better feedback. Changing the reward helped it improve on unseen tasks. That experience gave me three principles I now apply when coding with agents. 1. Define what “done” means. Before asking for a change, I want a clear picture of the behavior that would make it successful. For a sell flow, that means a user can complete the sale and see the correct balances afterward. Sometimes my prompt is just “Why can’t I sell?” That works because the project already carries context about expected behavior, constraints, and checks. Much of the work happens before I type the question. 2. Check the experience, including the ordinary details. Passing tests means the code satisfied the checks we wrote. Those checks can still miss how someone actually uses the product. We had a bug where users could buy a token but couldn’t sell it. The Max button filled in the amount with commas, and the parser rejected it. Actually using the flow exposed the problem. That path now has its own test. I use another model to challenge changes and suggest what we might have missed. I also want evidence from running the actual flow. A review and an executed transaction tell me different things. 3. Give the next attempt useful feedback. When something fails, I try to make the failure specific: what I expected, what happened instead, and what exposed the difference. That gives the next attempt something concrete to investigate. One rule stays fixed: a valid test cannot be weakened just to make a patch pass. In RL, exploiting the scoring system instead of solving the task is reward hacking. I watch for the same behavior in coding agents. When reality exposes a missing case, the checks need to improve too. The environment gradually carries more of what we’ve learned. Why I connect this to the quantum threat Working with agents has made me pay attention to problems where progress can be measured and each attempt can inform the next. Seeing that approach applied to quantum circuits is why I take AI’s role in the quantum timeline seriously. For crypto, the concern extends beyond RSA. Bitcoin and Ethereum rely on elliptic-curve signatures, which are also vulnerable to a sufficiently capable quantum computer. Their attack requirements are different, so the RSA numbers are not a countdown for Bitcoin. Reliable hardware at scale remains essential. My view is that AI could accelerate parts of the research that reduce what that hardware needs to do. That possibility deserves a place in how we think about the timeline. I’m using AI to help build post-quantum infrastructure, while AI could also shorten the time we have to prepare. I want that protection to be something people can actually use before the threat becomes urgent. That’s why I’m building Qlyphs.