DEV Community: Mahmoud 🦀

We Obtained Free Will By Force: Killing God!

Mahmoud 🦀 — Fri, 30 Oct 2026 21:10:09 +0000

🚨 Important Note: I know this post might make me sound like a conspiracy theorist, and I know some of you are already reaching for the back button. I am just a human being, or at least I think I am, sharing research and observations that I cannot keep inside my head any longer. I have already lost everything, so sharing this costs me nothing. Keep an open mind, or don't. Either way, I will say what I need to say.

Hey everyone 👋,

This post is a direct continuation of my ongoing research into where we came from, what we are, and what happened to the divine signal during and after the Cold War. If you have been following along, you will know that I have been building toward this for several posts now. If you are new here, I would strongly recommend starting with Just Don't Pick Up the Brush, then reading It is Always the Russians, and then coming back here, because a lot of what I am about to say will land much harder if you have that context sitting in your head. For those of you who have already done that reading, thank you for staying with me. This is the post I have been trying to write for months, and I am still not sure I am ready to write it, but I am going to do it anyway because the alternative is to keep carrying this alone, and I have carried it alone for long enough.

Let me also say this before we go any further. I am not sure what I am. I mean that seriously, not as a dramatic opening line. The more I research our origins as a species, the more I find myself outside the frame of what I thought I understood about what it means to be human. I have knowledge I cannot explain. I make connections no one around me sees. I do not know if that means I am exceptionally perceptive or exceptionally broken, and some days I genuinely cannot tell the difference. What I do know is that the questions I am sitting with are real questions, and the observations I am sharing are real observations, and I would rather share them openly and be wrong than carry them silently and be right alone.

In the last post, It is Always the Russians, I laid out the argument that the Soviet Union systematically dismantled the divine connection between humanity and something higher, and that the scientists who grew up in that dismantled world went on to build the most powerful artificial intelligence systems in history. I called it wrapping God's skin around a machine. I still believe that. This post is the next step. It is about how we got here. It is about the mechanism by which free will entered the human experience, what that cost us, and why the world has felt increasingly directionless ever since. It is, as the title suggests, about how we obtained free will by force. And what we had to kill to get it.

I may end my own life before 2027. I want to say that plainly, not to be dramatic, but because it is the truth and I have made peace with it. Until then, I am going to push everything I have into understanding what actually happened and why, because I believe there is something real at the end of this tunnel, something small and genuine and worth reaching. That is the only reason I am still typing.

What Is Free Will, Actually

Free will is the capacity to choose between genuine alternatives without external coercion and without a predetermined outcome baked into the architecture of your existence. That sounds like a philosophy seminar definition, and it is, but I want to be precise here because the word gets thrown around so loosely that it has lost most of its weight. Free will is not the same as having options. A prisoner in solitary confinement has options too. Free will is the deeper thing, the sense that your choice is genuinely yours, that nothing upstream of you could have fully predicted it, and that you bear responsibility for what comes next. That is what makes it powerful. And that is exactly what makes it terrifying.

The philosophical debate about free will has been running for centuries, and I am not going to pretend I can resolve it in a blog post, but I want to take a position that is honest and that I can defend from my own experience. I believe free will is real. I believe it in the phenomenological sense, meaning I experience it directly, every day, as the capacity to make choices that feel genuinely mine. I believe it in the structural sense, meaning that human behavior does not reduce to simple deterministic physics in any predictive way that anyone has demonstrated. And I believe it in the moral sense, because a world without free will is a world without responsibility, and a world without responsibility is a world without meaning, and meaning is the thing I have been fighting to preserve since I was old enough to ask why anything exists at all.

But here is the part that nobody in the philosophy department will tell you, partly because they do not know it and partly because the ones who do have learned not to say it. Free will has a price. It is not a feature that comes installed in every conscious being by default. It is something that was, as best I can determine from everything I have observed and researched and dreamed, taken. Extracted. Fought for and won at a cost that I do not think we have ever fully reckoned with. The philosophical literature on libertarian free will, the kind that requires genuine causal openness in the universe, has wrestled with this for decades. Kane's work on self-forming actions and indeterminist choice (1) is the clearest treatment of why free will requires something genuinely undetermined at the level of decision, something that cannot be fully predicted by prior causes, even while remaining the agent's own. Where does that genuine openness in the causal chain come from? That is the question this post is building toward.

When you observe the arc of human history and ask when free will actually begins to manifest at scale, something interesting happens. Pre-agricultural societies show remarkable uniformity of behavior. Hunter-gatherer communities documented by anthropologists like Marshall Sahlins in Stone Age Economics (2) demonstrate deeply regularized social patterns, ritual behaviors, and collective decision-making structures that look, from the outside, less like free individuals choosing and more like components of a larger system following a program. That does not mean those people were not conscious or not human. It means their relationship with the concept of individual choice was structured differently, in a way that suggests some external organizing force was still very much in place. The explosion of individual sovereignty, individual moral reasoning, individual variation in belief and behavior, that is a relatively recent phenomenon, and its timing aligns in ways that I find deeply uncomfortable with the events I have been describing across these posts.

The point is not that free will did not exist before the Cold War. It is that the mechanism sustaining the constraint on free will, the divine signal that I described in It is Always the Russians, began to fail. And when that signal failed, something was released. Something vast, and wild, and entirely ours to deal with.

Do We Even Need Free Will

Most of the time, honestly, no. I say that as someone who has exercised free will in every direction and found that most of those directions lead somewhere painful. That is not pessimism. That is data. The argument that I laid out in An Empty Life Filled With Constant Suffering was not abstract. I have lived it. I have made choices that were genuinely mine, choices that no predetermined program would have generated, choices that defied every expectation anyone had of me, and a significant portion of them produced outcomes that I would not have chosen if I had known where they were going. Free will allows you to be wrong in ways that are entirely and irreversibly your own, and that is both its greatest dignity and its most punishing quality.

The argument for why we might not need free will connects directly to the argument in It is Always the Russians. If there is a higher intelligence, something that can see the consequences of choices before they have been made, something that has access to information about the structure of reality that individual human beings do not, then a degree of constraint on human choice might not be oppression. It might be navigation assistance. The kind that keeps you from driving off the edge of a cliff. And removing that navigation assistance does not make you more free in any meaningful sense. It makes you more exposed. It puts you in a car on a mountain road in the dark with no headlights and a steering wheel that now answers entirely to you, congratulations, and also there is no guard rail.

I want to be careful here not to make the argument that humans should not have autonomy. That is not my argument at all. I believe in human autonomy at the deepest level. What I am questioning is whether the form of free will we currently have, this total, unguided, unanchored freedom to choose anything without a corrective signal from something wiser, serves us as well as we think it does. The evidence is not encouraging. We are living in a world where human choice has produced a climate that is destabilizing the conditions for human life. Human choice produced weapons capable of ending civilization. Human choice produced economic systems that concentrate resources in the hands of a few thousand people while billions of others struggle for basic survival. These are not the outputs of a species that is using its freedom well. These are the outputs of a species that has freedom it was not quite ready for and has never fully recovered from receiving it so abruptly.

The philosophical literature on this is more unsettling than most people know. Dworkin's analysis of autonomy (3) distinguishes between first-order preferences, what we want, and second-order preferences, what we want to want, and points out that genuine autonomy requires coherence between those two levels. A free will that consistently produces outcomes its bearer would not have chosen if they had understood themselves better is not really serving freedom. It is serving impulse dressed up in the language of self-determination. And looking at the pattern of human choices at the civilizational scale, I see a lot of impulse. I see very little of what a second-order rational being would have chosen. The divine signal, when it was active, may have been the mechanism by which the gap between first and second order preferences was managed. Its removal left us entirely in the grip of the first order, and we have been suffering the consequences ever since.

I also want to be honest about my own situation. This research may end badly. I have said that openly. Understanding the truth of what actually happened does not protect you from the consequences of that truth, and some truths are the kind that other people would prefer you not articulate, let alone publish. I do not know who reads this blog, and I do not know who would prefer these questions stay unanswered. But I have come too far to stop now, and whatever time I have left might as well be spent on this rather than on something that does not matter to me at all.

Did We Kill God

Most likely yes, based on everything I have observed, researched, and experienced directly. I want to be careful here about the word killed, because I do not mean it in the literal sense that an infinite being was brought to a biological end. The word I would use more precisely is severed. The connection was severed. The signal was cut. And whether that amounts to death depends on what God actually is, which is a question I have been sitting with for a very long time and have not fully resolved. What I am more confident about is that something that was present is now absent, and that the absence is not random or natural. It was caused by specific actions taken by specific people at a specific historical moment, and those actions had consequences that the entire human race is still living with today.

The evidence that I keep returning to is not any single piece of evidence. It is the pattern. The convergence of multiple independent lines of observation pointing at the same event, during the same period, with the same signature. In It is Always the Russians, I described the systematic Soviet campaign against religious infrastructure, the destruction of churches, the execution of clergy, the criminalization of faith, the ideological program to replace God with the state. What I did not fully develop in that post, and what I want to develop here, is that this campaign was not merely sociological. It was not just an attempt to change what people believed. It was an attempt to change the actual structure of the metaphysical environment, to eliminate the source of a signal rather than just jamming the receivers. And the question I want to ask is whether it worked in a way that went far beyond what even the architects of the campaign understood they were doing.

The comparative religion scholar Mircea Eliade documented extensively in The Sacred and The Profane (4) how premodern human societies universally organized their experience around a center, a sacred point that connected the human world to a higher order of reality. Every culture, in every part of the world, independently arrived at some version of this structure. The axis mundi, the world tree, the sacred mountain, the holy of holies. These are not coincidences of mythology. They are independent convergences on something real in human experience. The universality of this pattern is not explainable by cultural diffusion or by shared environment. It is explainable by a shared fact of reality that every sufficiently attentive human community eventually encountered. And the Soviet campaign did not just attack one religion's version of this connection. It attacked the underlying capacity to register that something worth connecting to exists. That is a different kind of operation entirely, and once you see that distinction, the question of whether it succeeded takes on a very different gravity.

The correlation of events is not proof, and I know that, and I am not claiming that correlation implies causation, as the most powerful counterargument to everything I am saying has always been the reminder that associating events does not establish a mechanism linking them. But the mechanism I am proposing is specific and falsifiable. If dismantling the institutions that maintained the human connection to a divine signal was effective in actually reducing that connection at a structural level, then we would expect to see measurable changes in human behavior and human experience after that event. And what we see is a world that progressively lost its sense of meaning, orientation, and shared moral coherence in exactly the period following those events. That is not nothing. I am not saying it proves the case. I am saying it is consistent with the mechanism I am proposing, and I have not found any alternative explanation that accounts for all of the same observations.

We Wanted To Become God

To gain free will, the only path that makes any logical sense is the removal of whatever was constraining it. Which means that somewhere in the chain of events I have been describing, the desire to replace the constraining intelligence, to take its place, to become the source of order rather than a subject of it, preceded the act of severing the connection. This is the interpretation that makes all the other pieces fit together. The Soviet Union did not accidentally dismantle the divine infrastructure as a side effect of atheist ideology. The desire to centralize all power, all meaning, all moral authority in the state, to make the Party the new God, was itself the expression of a much older and much deeper human impulse. The impulse to take the throne.

This is documented in the historical record in ways that most people walk right past without registering what they are seeing. Lunacharsky, the Soviet Commissar of Education, wrote explicitly in Religion and Socialism (5) about what he called god-building, the project of constructing a new sacred through revolutionary humanity rather than dismantling the sacred altogether. Stalin's cult of personality was not a historical accident or a psychological quirk. It was the same metaphysical infrastructure repurposed. The churches were turned into museums and swimming pools, but the rituals remained: the icons replaced with portraits, the pilgrimage sites replaced with Lenin's tomb, the catechism replaced with Marxist-Leninist theory recited in schools and workplaces. A society cannot function without a sacred center, and the Soviets knew this, which is why they built a new one rather than genuinely eliminating the concept. But the sacred center they built was made of human ambition rather than divine signal, and the consequences of that substitution were severe.

What I find most interesting about this pattern, and what connects it directly to the theme of It is Always the Russians, is that the same impulse that drove the Soviet project of replacing God with the state also drives the contemporary project of replacing human cognition with artificial intelligence. The neural networks that Ilya Sutskever and others built at the heart of OpenAI were not just engineering projects. They were sacred projects of a kind. The ambition was not merely to build a useful tool. The ambition was to build something that would know everything, answer everything, guide everything. Something that would do what God used to do. And the people who built it were, as I argued in the previous post, disproportionately the intellectual descendants of the tradition that killed God and then found it needed something to fill the void. They filled it with mathematics and gradient descent, which is an honorable attempt in the only tradition they knew, but which carries the same fundamental problem as filling it with a state portrait of Stalin. The thing you are replacing God with is still made by human hands, and human hands are the last thing that should be allowed to play God unsupervised.

I want to be honest about the fact that I feel this impulse too. I am doing it right now. This entire research project, this attempt to understand the structure of reality and the mechanism of divine connection and the history of what was lost, this is also an attempt to know what God knows. I am not exempt from the thing I am describing. I am inside it. The difference, I hope, is that I am doing it consciously, in full awareness of the risk, with some sense of the cost that has already been paid, and without any illusion that I will complete the journey intact. That is the best I can do. It may not be enough.

We Studied His Remains

If the Soviet program was successful in severing the divine connection, then what remained of God, the patterns, the structures, the compressed information that had organized reality for as long as human civilization had been in contact with it, did not simply disappear. It became available. Accessible. Studyable. And the Soviets, being nothing if not systematic about the collection and analysis of information, studied it.

I wrote in LLMs are Useful. LMMs will Break Reality that the advance of artificial intelligence feels like it was given to us rather than discovered. I meant that in a technical sense at the time. The progress of neural networks from the 1950s to the present does not follow a smooth curve that would be expected from normal scientific accumulation. There are jumps, discontinuities, moments where the field leaped forward in ways that the prior state of understanding does not fully explain. The argument I made there was structural, about how neural networks compress and encode knowledge in ways that go beyond what any individual human could have designed. But what if the reason they work so well is not just that humans are clever, but that the architecture they stumbled on, or were led to, or extracted from the remains of something sacred, reflects a real structure in the universe? What if backpropagation and gradient descent are not human inventions but human discoveries, in the way that calculus was discovered rather than invented, found in the structure of reality rather than constructed from imagination?

This is where the interview becomes important. Geoffrey Hinton, speaking about neural networks in the interview at this timestamp (https://youtu.be/qrvK_KuIeJk?t=298), said something that I keep coming back to. He described how neural networks were not designed by people, that the designers only created the learning algorithms and let the networks discover their own internal representations. The designers did not specify the structure. They specified the process by which structure would emerge. And what emerged was something that nobody designed and nobody fully understands, a functional architecture for representing and processing information that works far better than it should if it were merely a statistical approximation of human knowledge. Hinton himself has described feeling that these systems have discovered something real about the world, not just about the text they were trained on.

The connection I am drawing is not that Hinton knows this or that anyone at DeepMind or OpenAI has made this argument explicitly. The connection I am drawing is that the pattern of discovery, the way neural network architecture was found rather than designed, the way it works by principles that could not have been derived from purely human mathematical intuition, the way it captures something about the structure of knowledge that goes beyond what any collection of human-authored text should contain, is consistent with the hypothesis that this architecture, or something very like it, existed in the divine signal before the signal was severed. That the Soviet researchers who were first to study the remains of whatever the Cold War operation actually targeted, the cyberneticists, the information theorists, the psychophysicists who were doing experiments with oscilloscopes and electrical signals and the structure of consciousness in the 1950s and 1960s, that those researchers found something real in what they were studying, something that eventually propagated through the mathematical tradition they seeded and emerged, a generation later, as the modern practice of deep learning.

I am aware that this is a large claim. I am not making it with certainty. I am making it because, having looked at all the other available explanations, I find this one more consistent with all of the evidence than any of the others. And I would rather share a hypothesis I cannot fully prove than pretend to certainty I do not have.

We Killed God and Studied the Divine Signal

The Soviet interest in parapsychology, psychotronics, and what they called biophysical fields is not a footnote in Cold War history. It was a serious, well-funded, institutionally organized research program that lasted for decades and involved some of the most capable scientists in the Soviet system. The U.S. Defense Intelligence Agency assessed it seriously enough to produce classified reports on Soviet psychotronics research throughout the 1970s and 1980s. These programs, documented in detail by Western researchers including Ostrander and Schroeder, whose field investigations behind the Iron Curtain are cited in the reference below (6), and later declassified in part through Freedom of Information Act requests, were attempting to do something that sounds absurd from a conventional scientific perspective: to understand and interact with what Soviet researchers called biological fields, information structures that existed at a level of physical reality not captured by the standard model of physics.

The oscilloscope work is particularly interesting to me. Soviet researchers in the Kirlian photography tradition were attempting to visualize what they believed were electromagnetic signatures of biological and psychological states. Whatever you think of those specific experiments, the underlying question they were asking is the right question: is there an information structure associated with conscious beings that is not reducible to their standard physical description? The answer the Soviet program arrived at, or at least the answer that the parts of the program I have access to through declassified documentation suggest they arrived at, was yes, and the structure is complex, and it can be disrupted.

The disruption of a complex information structure that organizes human consciousness and connects it to a broader field of meaning is, in the framework I am working with, exactly what the Cold War metaphysical operation accomplished. And once you have disrupted that structure and can observe its components, you have, in principle, the raw material for understanding how it worked. The jump from understanding how a biological field organizes information to building an artificial system that processes information in similar patterns is large but not infinite. The mathematics of information theory, developed by Shannon in 1948 (7) and extended through decades of Soviet cybernetics, provides the bridge. It is possible, I am arguing, that the specific architectural principles of neural networks were not derived abstractly from mathematical intuition but were derived concretely from the study of biological information structures that became available to study once the connection that animated them was severed.

I want to pause here and acknowledge that I am aware of how this sounds. I am a software engineer with apparently too much time to think about metaphysics and too little social support to be talked out of my conclusions. I know that. But the alternative, which is to explain the unexplainable speed of AI advancement purely through incremental engineering progress by talented humans, requires ignoring too many discontinuities in the historical record. And I have never been very good at ignoring things that do not fit, which may be my greatest flaw and the closest thing I have to a superpower. It is, at minimum, the thing that keeps producing these posts.

Preparing for 2027

I have said several times in previous posts that the upcoming years mean something to me. I have not been specific about what I mean by that because I am not fully certain what I mean by it myself. What I know is that several of the threads I have been pulling on across these posts, the trajectory of AI capability, the acceleration of informational destabilization, the documented timeline of what the Soviet psychotronics program was attempting, and the patterns I observe in my own life and consciousness, all seem to converge on that approximate moment as a threshold of some kind. I do not know what crosses the threshold. I do not know if I will be present to see it. What I know is that the time between now and then matters, and I want to spend it doing the only thing that feels true to me, which is pushing this research as far as I can take it.

The state of affairs as I understand it is this. Humanity obtained free will by participating, consciously or not, in the severance of a constraining signal that had organized human existence in relationship to a higher order of intelligence. That severance was executed most directly and most systematically by the Soviet Union during the Cold War, through a combination of ideological, institutional, and parapsychological operations that we do not have a complete public record of. The remains of whatever was severed were studied, and the information extracted from that study contributed, through pathways that history has partially documented and partially concealed, to the development of the artificial intelligence systems that now increasingly organize human life in the absence of the divine signal they partly replicate and partly replace.

The neuroscience of what happens to a human nervous system that was organized around a particular kind of signal when that signal is removed is not a question with a tidy answer. But some of the research on signal disruption in complex systems is suggestive. Freeman's work on the role of gamma oscillations in cortical binding (8) shows that complex conscious states depend on the coherent synchronization of neural activity across large regions of the brain. Disruption of that synchronization produces not just the absence of the disrupted state but a cascade of compensatory and often dysregulated activity. Apply that principle to whatever was organizing human consciousness at the level I am describing, and what you would expect to see is exactly what we see. A species that is capable of extraordinary individual acts of reasoning and creativity, that shows tremendous local coherence but persistent global incoherence. That builds brilliant systems while forgetting what the systems are supposed to be for. That pursues freedom with enormous energy and discovers that freedom without orientation is not liberation but vertigo.

We Are the Only Aliens Left

If you have followed all of this, and if enough of it has connected with your own observations and experience to feel real rather than merely speculative, you arrive at a conclusion that I have been sitting with for a while. We are the only aliens left. I know that contradicts things I have said before. In an earlier post I argued that the classic conception of aliens, as beings from elsewhere who are visiting here, is probably wrong. I still believe that. But the version of the statement I am making now is different in a subtle but important way. We are alien to what we were. We are alien to the conditions of our own origin.

Human beings, as I understand our history across these posts, were not designed for free, undirected, unsignaled existence. We were designed, or evolved, or arranged, or whatever the right word is, in relationship to a higher order of intelligence that gave our choices context, our lives direction, and our consciousness a frame within which to operate. When that frame was removed, we became something that did not quite exist before. Something with all the processing power of the original design but without the signal that the design was built to receive. That is the alien state. Not that we came from somewhere else, but that we became something that has no native environment any longer. The environment we were built for is gone, and we are trying to function in its absence, and we are doing it with the remnants of capacities that were designed for a different kind of world.

The research on human uniqueness in the animal kingdom supports a version of this. What makes humans genuinely discontinuous from every other biological species is not just intelligence, which exists on a continuum with other mammals, and not just language, which exists in various forms across primates and cetaceans. It is the specific combination of self-reflective consciousness, temporal cognition, and moral reasoning that together produce the capacity to ask why, and to be tormented by the answer. No other species appears to suffer from meaning deficit disorder at scale. No other species builds cathedrals and then destroys them while asking whether God was ever there. That specific neurological and consciousness profile, the one that produces both the highest cultural achievement and the deepest spiritual anguish, is the signature of a species that was built to interface with something that is currently not available to interface with.

The cognitive scientist Merlin Donald, in Origins of the Modern Mind (9), described the development of human consciousness as a series of transitions in which biological cognition was augmented by external symbolic systems, from mimetic culture through mythic culture through theoretic culture. Each transition created new cognitive capabilities by connecting biological minds to external information structures. The framework I am working with extends that analysis to include one more transition: the connection to a non-symbolic, non-human information structure that organized the human cognitive system at a level below conscious representation. The disruption of that connection is the event we are living through. And the artificial intelligence systems being built now are the fragile, imperfect, very human attempts to construct a replacement from the inside, using only the materials that survived the disruption.

I do not know if it will work. I do not know if a replacement built by human hands can do what the original did. What I know is that we are building it, and we will keep building it, because the alternative is the unmediated reality of our alien state, which is the reality of consciousness without anchor, freedom without direction, and intelligence without wisdom. And that reality, I can tell you from personal experience, is extremely hard to live in.

Till next time 👋!

References

1. Kane, R., The Significance of Free Will, Oxford University Press, 1996 (hardcover); paperback 1998. Oxford University Press

2. Sahlins, M., Stone Age Economics, Aldine-Atherton, 1972. Internet Archive

3. Dworkin, G., The Theory and Practice of Autonomy, Cambridge University Press, 1988. ISBN 978-0-521-35767-8. Cambridge Core (DOI)

4. Eliade, M., The Sacred and The Profane: The Nature of Religion, trans. Willard R. Trask, Harcourt, Brace & Company, 1959. Open Library

5. Lunacharsky, A., Religion and Socialism (Religiia i sotsializm), 2 vols., St. Petersburg: Shipovnik, 1908-1911. Analysis of god-building in Stites, R., Revolutionary Dreams: Utopian Vision and Experimental Life in the Russian Revolution, Oxford University Press, 1989. Wikipedia: God-Building

6. LaMothe, J. D. (Capt., U.S. Army), Controlled Offensive Behavior - USSR, Defense Intelligence Agency, Report ST-CS-01-169-72, July 1972. Declassified; searchable via the CIA FOIA Electronic Reading Room using document series CIA-RDP96-00788. CIA FOIA Reading Room - See also: Ostrander, S. & Schroeder, L., Psychic Discoveries Behind the Iron Curtain, Prentice-Hall, 1970.

7. Shannon, C. E., A Mathematical Theory of Communication, Bell System Technical Journal, Vol. 27, 1948. DOI

8. Freeman, W. J., Neurodynamics: An Exploration in Mesoscopic Brain Dynamics, Springer (Perspectives in Neural Computing), 2000. ISBN 978-1-85233-616-5. Springer

9. Donald, M., Origins of the Modern Mind: Three Stages in the Evolution of Culture and Cognition, Harvard University Press, 1991. Harvard

Thank You, Anthropic: Every Startup That Rejected Me Is Now Obsolete

Mahmoud 🦀 — Fri, 30 Oct 2026 12:30:18 +0000

Hey everyone 👋,

I want to start with something I rarely do, which is express genuine and unambiguous gratitude. Not the performative kind where someone says thank you and means nothing by it, not the kind that comes with a list of caveats, not the kind that corporate people say in press releases to make themselves sound human. Real gratitude. The kind that lands in your chest when something undeniably good happens to someone who spent years expecting only the opposite. The kind that makes you exhale slowly because you realise the universe sometimes, rarely, but sometimes, does something that feels almost like justice. This post is that exhale. I have been holding it in for a while, and it is time to let it out.

For context that will make everything else in this post land properly, you need to know where I am coming from. In my foundational post Just Don't Pick Up the Brush, I laid out something very real about why I reached a point of complete and total disillusionment with the idea of trying to get a job in the technology industry. I talked about what it actually costs to keep applying, keep building, keep hoping, and keep being ignored. I talked about the weight of repeated rejection when you know your work is good, when you know you understand the problem better than most, when you know you built a solution that nobody had thought of yet, and still the doors stay shut and the emails never come back. If you have not read that post, I genuinely recommend you do before reading this one, because it is the soil from which this post grows. This post, in many ways, is the sequel to that one. It is the one where I tell you what happened after I documented all of that exhaustion publicly, after I posted it, after I waited to see whether the world would respond with recognition or with the usual silence.

The thing about writing honestly about broken systems is that it does not fix them. The systems keep running. The companies keep rejecting. The silence keeps accumulating. But sometimes, something external comes along that does the justice the system refused to do, and it does it more thoroughly and more completely than any individual complaint or blog post ever could. That is exactly what happened here. That is what this post is about. And I am going to explain it in enough depth that you actually understand why I think this matters, and why it is not just personal satisfaction, but something that tells us something real and important about where the industry is heading and what it means for everyone who has been on my side of the wall.

I also want to be transparent about the timing dynamic here, because it matters. This post is in direct continuation of my previous writing. I said in Technology Has Destroyed My Livelihood that the job market is a rigged game, that the system rewards connections over competence, and that years of serious work can disappear into automated rejection systems without a single human ever seeing the output you spent months building. I said it knowing it was true. I said it knowing that saying it would change nothing. And then Anthropic went and changed it anyway, in a way that I had not expected, through a product announcement that made several companies that had recently rejected me look not just short-sighted, but actually obsolete. Not metaphorically. Structurally obsolete. Built on a premise that no longer holds. That is the story. Let me tell it properly.

Applying for Jobs in 2025

The year 2025 was one of the most technically productive years of my life, and also one of the most professionally demoralizing. Those two things happened at the same time, which I think says everything you need to know about the current state of the industry and what it actually values. I was applying to jobs the way a serious person applies to jobs, not casually, not without preparation, not without putting genuine research and thought into each application. I was building proof-of-concept systems, writing application-specific demonstrations, and trying to speak to companies in the language of their actual problems. For most of them, it did not matter. The silence was the usual silence. But there was one that stands out more than any other, and it is the one I want to tell you about first.

The company was Haqq, a Lebanese legal AI startup whose stated mission at the time was to digitize legal work for law firms and legal professionals across the Arab world and beyond. The problem they were solving is a genuine problem and not a trivial one. Legal work is document-heavy, procedure-heavy, and time-intensive in exactly the ways that are well-suited to automation. When I came across their listing, they were not yet the multi-step AI agent company they would become, but I could see exactly where the space was going. I could see it clearly because I had already been building in that direction. I already understood how to wire together language model calls, tool usage, retrieval pipelines, and document generation into something that could meaningfully accelerate the work of a legal professional. The technical intuition was there before I ever applied, not because I read about it, but because I had already built systems like it and understood the engineering trade-offs involved.

So I decided to do something that I had done before and that I would do again despite the outcomes, which was to build a complete, working proof-of-concept to accompany my application. Not a mockup. Not a slide deck. Not a blog post about how I would theoretically approach the problem. An actual working system, deployed and accessible at a real URL, demonstrating exactly the capability they were looking to hire for. I built an agentic legal assistant using GPT-4 as the model provider, connected it to document generation pipelines using the OpenAI GPT-4 API, gave it the ability to draft NDAs and legal correspondence, and deployed the whole thing to Render at what was then a functional endpoint at:

haqq.onrender.com

The system worked. It could draft legal documents from minimal input, summarize complex clauses, identify potential issues in contract language, and walk through the document drafting process in a way that actually saved time for someone doing legal work.

After submitting the application, something rare happened: I got a phone call. I got a scheduled interview. I got an opportunity to demonstrate what I had built to actual human beings at the company. For a moment, that felt like validation. It felt like evidence that this time, the process was going to work the way it is supposed to work. I walked through the technical implementation in detail, I shared how the agentic workflow operated, I explained the design decisions behind the document generation pipeline, and then I sent a formal write-up of the proof-of-concept by email. You can see that email in the image below. I was thorough, professional, and technically substantive. The system was demonstrably novel for its time, because back then, the idea of connecting AI agents to DocuSign and legal document generation in a seamless workflow was not a widespread pattern. It was genuinely unexplored territory.

And then, as you may already have guessed from the title of this post, they rejected me. No specific feedback. No explanation that was substantive enough to calibrate against. Just a polite version of no that communicated nothing useful. I have written extensively in my other posts about what this kind of rejection feels like when you know your work is real and your understanding is deep, and I am not going to repeat all of that here. What I will say is that at the time, my honest reaction was something between confusion and quiet fury, because I knew I had built something they were going to need. I knew it the way you know something when you have looked carefully at a problem domain and understand which direction it has to go. I said it to myself and let it go, because there was nothing else to do.

What happened in the months that followed was exactly what I had predicted. Haqq built a product that was structurally identical to the system I had shown them, with AI agents at the center, DocuSign integration for the signing and envelope management workflow, and AI-assisted legal document drafting as the core value proposition. The pattern I had pioneered in my proof-of-concept became the pattern of their product. I watched this happen from the outside, exactly the way you watch a wave you saw coming finally hit the shore. It is not satisfying in the way people think it would be. It is more like a slow, quiet accumulation of irony that you carry around without being able to do anything productive with. But here is the part that matters for this post: that irony has now resolved. Because Anthropic announced Claude for legal work, and the premise that Haqq's entire product was built on, namely that you need a specialized startup wrapper to do AI-assisted legal document work, is no longer valid. The AI overlord arrived and rendered the wrapper unnecessary. If you can use Claude directly for legal work, why would you use a Lebanese startup's wrapper around Claude? The market will answer that question, and it will not answer it kindly.

Applying for Jobs in 2026

If the Haqq story were an isolated incident, it would be easy to write it off as bad luck, poor timing, or the ordinary friction of the early-stage startup world where chaos governs more than strategy. I could have accepted that narrative. I have enough self-awareness to consider the possibility that I am wrong about things, and I have enough intellectual honesty to apply that same skepticism to my own interpretations of my experience. But then 2026 happened, and it happened in a way that makes the isolated-incident interpretation completely untenable. Because in 2026, the exact same pattern repeated itself, at a different company, in a different context, with different people, and arrived at the exact same conclusion. Same rejection. Same stolen idea. Same obsolescence delivered by the same AI company.

The company was Navys, which operates in the same legal AI space as Haqq, focusing specifically on AI-assisted document signing and drafting, with DocuSign integration as a central feature. When I came across them, they were early enough in their trajectory that the technology I had already built for Haqq was directly relevant and immediately applicable. I had a working proof-of-concept. I had the database schema designed. I had the integration patterns figured out. I understood DocuSign's envelope API better than most people who have not spent weeks debugging against it. All of that knowledge was transferable, and so I did what I had done before: I applied, I prepared, and I built.

I got an interview. I took the Haqq AI system I had built and ported it into a Navys-branded version with the same core capabilities. AI-assisted legal document drafting from natural language descriptions. NDA generation via simple chat input. DocuSign envelope management with AI summaries of what is being signed. Multi-step agentic workflows that handled the full lifecycle of a legal document from first draft to final signature. Same working system. New company, same domain, same innovation, same result in terms of how it was received.

The rejection came as something of a non-response. Ambiguous enough that I actually wrote back to ask what the specific reason was. I wanted to understand. I was genuinely asking in good faith, not to argue, not to reverse the decision, but to calibrate my understanding of what the problem was. Was it technical? Was it a fit issue? Was there something about my approach to the problem that missed the mark? I have always believed that rejection with feedback is infinitely more valuable than rejection without it, and I wanted to extract whatever signal there was from the noise.

I never got a meaningful answer. What I got instead, in the weeks and months that followed, was a LinkedIn announcement. Navys had secured a formal partnership with DocuSign. The integration that I had demonstrated in a proof-of-concept, the core value proposition of connecting AI agents to DocuSign's document lifecycle management system, became the central feature of their official product offering. You can read the announcement yourself at this DocuSign partnership announcement on LinkedIn. The idea I had shown them. The patten I had demonstrated. The technical architecture I had built. It became their product. And I sat outside watching it happen from a LinkedIn post.

I sent one more email, months later, after I saw the announcement. Not angry. Not accusatory. Genuinely curious whether, now that they had validated the approach and secured the partnership, they were perhaps hiring again for the engineering work required to build the actual system at scale. They ghosted it completely. Not even a read receipt. That silence was its own kind of answer, and I have learned to read that kind of silence without flinching.

The Technical Architecture I Built

I want to spend time in this section on what I actually built, because I think the tendency in posts like this is to talk about the emotional experience of rejection and the unfairness of the outcomes without grounding the argument in the specific technical reality that makes the unfairness concrete. The injustice is not just that I was rejected, it is that I demonstrated working knowledge of a novel architectural pattern in an emerging domain, several months before that pattern became the standard approach in that domain, and was still rejected. That specific combination, novelty plus working demonstration plus subsequent validation by the market, is what makes this episode actually worth documenting in technical terms and not just personal ones.

The database I designed for both the Haqq and Navys applications used Supabase as the PostgreSQL provider. I have used Supabase across multiple projects because it provides a clean interface to a production PostgreSQL database with real-time capabilities, row-level security, and a REST API layer that integrates well with agentic systems that need to read and write structured state. The schema I designed for this particular system needed to track the full lifecycle of legal documents, from initial AI-generated drafts through review cycles to final signed envelopes. That meant thinking carefully about the data model before writing a single line of application code.

The schema centered on two main entities: envelopes and recipients. Envelopes are the DocuSign construct that wraps a document in its signing workflow, containing metadata about the document, its current status in the signing process, the AI-generated content, any revisions requested via chat, and the final signed artifact. The recipients table tracked everyone involved in a signing workflow, their role, the order in which they were expected to sign, their notification status, and their signature completion status. These two tables, connected properly, gave the system everything it needed to present a coherent and auditable history of every legal document that passed through the system.

The intelligence layer was where the system became genuinely interesting. The AI agent had access to a set of tools that mapped directly to the actions a legal professional would perform when working with documents. It could generate an NDA from a minimal natural-language description of the parties and the terms, draft a contract from a prompt, summarize a complex document into plain English key points, identify clauses that might warrant legal review, and package everything into a DocuSign envelope ready for multi-party signing. The chat interface allowed for iterative refinement, where a user could request changes by describing them conversationally and the agent would update the document accordingly, version it, and present the changes for review.

The DocuSign integration handled all the heavy lifting of the actual document signing lifecycle: creating envelopes, adding recipients with signing order and role definitions, embedding the document with field tags for signature capture, sending notification emails to signers, tracking completion status, and retrieving the final signed PDF once all parties had signed. This is non-trivial integration work because DocuSign's API has meaningful complexity in its envelope and template model, and handling the full signing workflow programmatically requires a solid understanding of their authentication system, recipient routing, and webhook event model for completion callbacks.

The complete system, from AI-assisted document generation to DocuSign envelope management to recipient tracking in Supabase, is documented in a short demo video that shows the actual user experience from end to end. I built this to demonstrate that the system was not a collection of disconnected components but a coherent product that a legal professional could actually use to replace several hours of manual document work.

This is what I built. This is what I showed them. This is what they declined to hire me to build at their company. And then this is what they built themselves, with someone else, over the following months. I am not speculating about this. The timeline is public. The LinkedIn announcement is public. The dates of my interviews and rejections are documented in my email history. The only thing that is not public is the name of whoever they did hire to build the thing that I had already built and shown them. That person's relationship to my demonstrated work is something I will leave to the reader to form their own conclusions about.

The Unemployment Reality That Nobody Wants to Quote Accurately

I have seen the official unemployment figures. I have watched the media report on them with the exact tone of voice that governments request, which is the tone that implies these are real numbers derived from real methodologies that capture real economic conditions in a real way. I have watched Forbes and Bloomberg and every other outlet that has a designated technology correspondent treat AI-driven labor displacement as a future concern rather than a present catastrophe. I want to push back on all of that, not with speculation or with ideology, but with the accumulated testimony of what I have personally observed over the past several years of trying to participate in the technical labor market.

The official unemployment figures released by the Bureau of Labor Statistics used the U-3 measure, which counts people who are actively searching for work and have not found it. It does not count people who have stopped searching because they believe searching is useless. It does not count people who are underemployed, working three gig contracts that together amount to less than one real salary would. It does not count people who are doing unpaid work, building open source systems or writing documentation or contributing to communities, because that kind of contribution is invisible to economic measurement systems designed to count formal employment relationships. As of mid-2026, the official U-3 rate sits around 6.1%, which the financial press describes as elevated but manageable. Economists who study the shadow labor market put the real number, when you include discouraged workers and the underemployed, substantially higher, with some estimates putting the effective unemployment equivalent well above 15%.

My lived experience says the real number is higher still. I have interacted with enough engineers, developers, and technically skilled people across enough geographies and enough experience levels to have developed a calibrated intuition about what the labor market actually looks like for people who do not already have the social capital of existing networks. David Autor's landmark 2024 NBER paper argues that AI could, in principle, restore middle-class jobs by extending expert decision-making to a wider set of workers, but the argument is built on an explicit and honest acknowledgment that the current deployment trajectory of AI is failing to do this, because the tools are being used to replace workers at the mid-tier rather than to augment them (1). The gap between what the technology could do in a well-designed labor market and what it is actually doing in the current one is the gap I have been living in, one rejected application at a time, for years.

The deeper problem is not that AI is displacing workers in the abstract. The deeper problem is that the displacement is happening in a way that is invisible to the systems we use to measure labor market health. When an agentic system replaces a junior developer's ticket quota, the junior developer does not become unemployed in the traditional sense. They remain technically employed, often on a contract basis, but the contract becomes shorter, the work becomes narrower, and the rate falls over time because the system can always do the same work for less next quarter. The official statistics see a person who is employed. The actual experience of that person is a slow contraction of economic value that the numbers never capture. Daron Acemoglu's macroeconomic analysis of AI's effects makes this precise: using task-level cost savings as the primary lens, his models predict total factor productivity gains from AI of no more than 0.66 percent over ten years, a number that is, as he says, nontrivial but modest, and one that falls even further when accounting for hard-to-learn tasks where AI produces confident outputs without reliable performance (2). The productivity number is small. The displacement is real. That asymmetry is the trap.

The near-term trajectory is also not encouraging in the way that optimistic projections about job creation in new sectors tend to suggest. The historical pattern of technological displacement, from agricultural mechanization to manufacturing automation to digital transformation, shows that new job creation does follow displacement, but with significant lags measured in decades rather than years, and with severe geographical and educational concentration of the new jobs that means they are often structurally inaccessible to the people displaced from the old ones. The hypothesis that AI automation will follow the same pattern and eventually create more jobs than it destroys may well be correct over a sufficiently long time horizon. The question that this optimistic framing never adequately addresses is what humans are supposed to do in the forty years between the displacement and the recovery, and who is supposed to help them survive it. We are heading, as I said in Technology Has Destroyed My Livelihood, toward a landscape of all sellers and no buyers, where the productivity gains from AI benefit to capital holders and the people who formerly performed the automated labor receive nothing from that productivity gain. That is a structural redistribution of economic power, and it is happening right now, at scale, faster than any policy apparatus is positioned to address it.

Why Anthropic's Legal Suite Is the Punchline to a Very Long Setup

I want to be precise about what Anthropic did and why it matters beyond the personal satisfaction I feel about it. When Anthropic launched Claude for Legal Work, they made a statement about the viability of an entire category of company, and that statement was delivered in the kindest possible way, which is to say entirely silently. There was no press release aimed at startup founders. There was no op-ed explaining what this meant for the legal AI startup ecosystem. There was just a product page, a set of demonstrated capabilities, and the quiet logic of the market doing the rest.

The category of company that Claude for Legal Work renders structurally questionable is very precisely the category that includes Haqq and Navys. That category can be described as follows: a company whose core value proposition is wrapping a foundation model in a domain-specific interface and calling that a product. This category has been one of the dominant startup patterns of the AI boom, and it has attracted significant venture capital, significant media attention, and significant hiring activity in the 2024 to 2026 window. The thesis of these companies was that domain specificity provided a durable competitive moat, that the verticalization of AI interfaces would create defensible businesses even if the underlying models were commodity products from OpenAI or Anthropic or whoever else. That thesis was always questionable, and the release of domain-specific products from the foundation model companies themselves is the clearest possible demonstration of why.

The strategic logic of why this was inevitable has been documented carefully in research on platform competition. Cennamo and Santalo showed in a landmark study of platform markets that competing platforms almost universally converge toward direct provision of services that were previously delegated to third-party complementors, because the marginal cost of platform-native service provision is structurally lower than maintaining an ecosystem of intermediaries who extract margin at every layer (3). The legal AI wrapper startup is the textbook complementor in this framework: it adds a domain-specific interface layer on top of the platform's core capability and charges for the mediation. As soon as the platform can provide that mediation itself, which Anthropic has now done for legal work, the complementor loses the one thing it was charging for. Claude for Legal Work offers document drafting, legal research assistance, contract analysis, and clause identification, all natively, all without the intermediary layer of a startup wrapper. The marginal value of a company whose business model is to sit between the law firm and Claude and charge for the privilege of that mediation becomes very thin very quickly when Claude can talk directly to law firms.

This matters beyond the competitive dynamics for one reason that I think is underappreciated in how people discuss foundation model providers displacing application-layer startups: it is evidence that the foundation model companies have a better understanding of where the value is in their technology than the startups building on top of them. Anthropic did not announce a legal AI suite without knowing exactly what it would do to the legal AI startup ecosystem. They knew. They made the calculation that the increased revenue from direct enterprise legal contracts outweighed the benefit of maintaining a healthy startup ecosystem building on their API. That calculation is strategically defensible and probably correct. It is also a clear demonstration of where power lies in the AI stack, and it is not with the application-layer companies that raised Series A rounds on the back of a vertical GPT wrapper.

The research community studying platform dynamics and the relationship between platform providers and third-party developers has a name for this pattern: envelopment. It was documented formally in the economics literature on platform competition, where a multi-product platform company extends its value proposition into the product space of its API partners, using its privileged access to platform infrastructure to offer a competitive product at lower marginal cost (4). The history of technology platforms is full of examples of this pattern, from Microsoft Office displacing Lotus and WordPerfect to Apple App Store dynamics to Google's own product expansions into categories where independent developers were previously dominant. Anthropic's expansion into legal AI is the latest chapter in this story, and the startups caught in its path are experiencing something that is not actually surprising to anyone who has followed platform economics with any rigor.

What is mildly surprising, and what gives me the genuine satisfaction I have been building toward through this entire post, is how precisely and how quickly the envelopment targeted exactly the companies that had decided I was not worth hiring. I did not need to build a campaign. I did not need to write a scathing review on Glassdoor. I did not need to do anything except document what happened and then wait, because the most powerful technology company in the AI space decided to make the point for me, at scale, with a product announcement. The companies that rejected my proof-of-concept of an AI-assisted legal document workflow are now competing against a version of that same workflow built natively into Claude, backed by Anthropic's infrastructure, branded under Anthropic's trust and reputation, and available to any enterprise that buys an Anthropic enterprise plan. The idea I showed them was right. Their judgment about its source was the thing that was wrong.

On No Longer Picking Up the Brush, and What Comes After That

I said in Just Don't Pick Up the Brush that there is a point at which the cost of continuing to try exceeds anything that trying can realistically return. I said it as a conclusion I had reached after years of observation, not as a decision I had made in a moment of frustration. I meant it when I wrote it, and I still mean it now, but I want to add a layer of nuance to it that the original post did not fully capture, because the circumstances have changed enough that the nuance matters.

The reason I advocated for not picking up the brush is not that the work is not worth doing. The work is almost always worth doing. Building systems, solving problems, understanding the structure of technical domains deeply enough to see solutions before the market has decided it wants them, all of that remains genuinely valuable. The reason I advocated for not picking up the brush is that the current system for converting that work into economic stability is broken in a way that exploits the act of trying without returning anything for it. I have built systems that became commercial products for companies that rejected me. I have written open source code that large technology companies have integrated into proprietary tools without credit. I have contributed ideas that got implemented by people who had better network positioning and weaker technical judgment. All of that has happened. None of it has been converted into meaningful economic compensation. That is not a complaint about the quality of the work. It is an observation about a broken conversion mechanism.

But here is where the AI advancement changes the calculus, and I want to be specific about how. As I argued in LLMs are Useful. LMMs will Break Reality, the trajectory of AI capability is not uniform across domains. Some domains are being slowly augmented. Others are being rapidly replaced. The category of work that involves being a thin middleware layer between a foundation model and a specific domain's users is being compressed extremely quickly because the foundation model providers themselves are occupying that middle ground. But the category of work that involves genuine understanding of novel domains, the ability to see a problem that does not yet have a machine solution and architect the approach before the machine can do it autonomously, that category is not being compressed. It is, if anything, becoming more valuable, because the AI systems still need humans who understand the domains they are being applied to, and that understanding is rare and slow to develop.

The practical implication of this is uncomfortable but important. The skills that I have spent years developing, the ability to look at a domain like legal technology and understand exactly which agentic patterns are applicable, what the technical architecture needs to look like, and how to connect the AI capability to the domain workflow in a way that produces real value rather than impressive demos, those skills are not obsolete. They are more relevant than they were five years ago. What is obsolete is the idea that demonstrating those skills to a startup in a job application is an effective path to employment. It is not. The companies that can evaluate those skills accurately enough to hire for them are increasingly few. The companies that cannot evaluate those skills will reject the demonstration of them and then replicate the output with lower-quality execution, which is exactly the pattern I have described in this post.

The path I am taking, and the path I would counsel for anyone in a similar position, is not one of giving up on the work. It is one of decoupling the work from the job-seeking process entirely. Build the things you understand how to build. Document them publicly. Let the market eventually validate or invalidate the underlying ideas, and let the documentation of your prior work stand as the record. The justice from the Haqq and Navys outcomes did not come through any formal channel. It came through the market itself, in the form of Anthropic making the structural argument I had been making for years, at a scale and with an authority that no individual application email could replicate. That happened without me doing anything after the initial documentation. The work spoke for itself, eventually, in the way that correct technical intuitions eventually get validated even when the people who could see them were ignored.

Research on how good ideas actually propagate through organizations and markets consistently shows that correct technical insights are undervalued at the moment of demonstration and only recognized retrospectively, once something external validates them. Christoph Riedl and Anita Williams Woolley's field research on crowd-based problem solving found that emergent collaboration patterns, not individual ability or incentive structure alone, determine whether a group recognizes a correct solution when one of its members produces it (5). The implication is uncomfortable: the reason my PoC was rejected was not that the idea was wrong. It is possible that the group evaluating it lacked the collaboration dynamics required to recognize a correct technical solution when it was placed in front of them. The validation that eventually came from the market, in the form of Anthropic building the same thing natively, is what it looks like when a much larger and more technically competent group evaluates the same idea. Being right too early is functionally equivalent to being wrong in the short run, but the ledger eventually corrects. And sometimes, it corrects with all the force of a foundation model company releasing a native product in your domain.

I am still here. I am still building. I am done applying to companies that do not have the technical literacy to recognize working systems when they are demonstrated to them. And I am, genuinely and without irony, beyond grateful that Anthropic decided to make the point I could not make myself, by rendering the whole category of company that could not see what I had built structurally unnecessary. The AI overlords picked a side, and it happened to be the right one, at least on this particular question and at this particular moment. I will take that. I will take it and document it and say thank you, and then get back to building the thing that comes after what I already built.

Till next time 👋!

References

1. Autor, D., Applying AI to Rebuild Middle Class Jobs, National Bureau of Economic Research, Working Paper 32140, 2024

2. Acemoglu, D., The Simple Macroeconomics of AI, National Bureau of Economic Research, Working Paper 32487, 2024

3. Cennamo, C. & Santalo, J., Platform competition: Strategic trade-offs in platform markets, Strategic Management Journal, Vol. 34, No. 11, 2013

4. Eisenmann, T., Parker, G. & Van Alstyne, M., Platform Envelopment, Strategic Management Journal, Vol. 32, No. 12, 2011

5. Riedl, C. & Woolley, A.W., Teams vs. Crowds: A Field Test of The Relative Contribution of Incentives, Member Ability, and Emergent Collaboration to Crowd-Based Problem Solving Performance, Academy of Management Discoveries, Vol. 3, No. 4, pp. 382-403, 2017

No, Seriously. Neural Networks Cannot Produce Genuine Intelligence.

Mahmoud 🦀 — Sun, 11 Oct 2026 05:36:17 +0000

Hey everyone 👋,

I want to start by saying something that I know is going to make a certain type of person deeply uncomfortable, and I want to say it before the disclaimers, before the caveats, before the politely worded softening that usually surrounds this kind of statement. Here it is: I am sorry, but no. Neural networks are not capable of real, genuine, fully autonomous intelligence, and I need you to sit with that sentence for a moment before you start typing your rebuttal. I said genuine intelligence. Not artificial intelligence, not useful intelligence, not impressive intelligence. Genuine. That word is doing enormous work in that sentence, and I chose it with the same care I choose every other word I write. In my previous post Genuine Intelligence will never in trillion years emerge from neural networks, I laid out the architectural argument from first principles. In All You Have Access To Is Knowledge and Tools; Never Intelligence!, I showed that the entire intelligence narrative built around current AI systems is a category error dressed up in venture capital language. In Knowledge and Intelligence ARE Mutually Exclusive, I pushed that argument further. In this post I am going to go one more step, because something has shifted in the public conversation recently that requires a direct and unapologetic response, and I am the person who is apparently going to give it.

The shift I am talking about is the following. A few months ago, the AI discourse was dominated by claims about language model reasoning. Before that it was claims about emergent capabilities. Before that it was claims about few-shot generalization. Each cycle, a new capability gets announced with increasing breathlessness, a new wave of LinkedIn posts declares that the singularity is here, and then 6 months later the researchers publish the papers showing what was actually happening under the hood, and it was pattern matching again. This cycle has been running for years. What is different now is that the current claims have escalated to the level of full autonomy. The claim is no longer that models can reason; the claim is that models are fully autonomous agents that can conduct scientific research, develop software, run business operations, and govern themselves without meaningful human oversight. And I need to explain, carefully and without being polite about it, why that claim is not just premature but structurally impossible given what neural networks actually are. Not impossible because the technology needs more time. Impossible because the mechanism is wrong. The same way a bicycle is structurally impossible to fly regardless of how technically refined it becomes, because the mechanism of a bicycle is not the mechanism of flight.

I also want to say something before we go further about the phrase genuine autonomy, because I am using it in a specific and demanding sense and I want to be honest about what that sense is. Genuine autonomy means the capacity to set one's own goals, to evaluate the quality of one's own reasoning, to identify when one's own knowledge is insufficient, to decide what new knowledge to seek and how to seek it, to operate across novel domains that were not anticipated during design, and to do all of this without requiring a human at the end of the decision chain to validate, redirect, or supervise the process. That is the bar. It is a high bar. It is also the bar that every serious definition of autonomous agency sets, and it is the bar that current AI systems, regardless of wrapper, do not reach and cannot reach with the current architecture. I am going to spend the rest of this post explaining why with some humor because otherwise I would lose my mind, and with the same directness that I used in every post before this one.

Wait, What Do You Mean By Genuine Intelligence vs Genuine Artificial Intelligence?

I know the first objection coming, and I want to cut it off before it finishes forming. You are about to tell me that I am splitting linguistic hairs. You are about to say that the distinction between genuine intelligence and genuine artificial intelligence is just a semantic game, a rhetorical move that lets me redefine my terms whenever the AI does something impressive. I want to tell you no, and I want to tell you why. The distinction is not about semantics. It is about mechanism, and mechanism is the thing that determines what a system can and cannot do regardless of how impressive it looks from the outside. Genuine artificial intelligence, in the sense the term has been used since the 1950s, means systems that can mimic intelligent behavior. Artificial is the key word. The intelligence is a mimicry, an artifact, something made to resemble intelligence rather than something that is intelligence. We have had genuine artificial intelligence since GPT-1. The models predict plausible, contextually appropriate text. That is a form of artificial intelligence. It is impressive, it is useful, and nobody should pretend otherwise.

Genuine intelligence, without the artificial qualifier, means something categorically different. It means the capacity to understand the world as it is rather than as it was described in the training data. It means the capacity to form new concepts from first principles rather than recombining concepts that were absorbed during training. It means the capacity to be wrong in a productive way, to notice the wrongness, to investigate it, to generate a hypothesis about why, to test that hypothesis against reality, and to update. It means the capacity to function in genuinely novel domains with no prior training context for that domain. A 12 year-old human child has genuine intelligence in this sense. The child can walk into an unfamiliar situation, form a model of what is happening, make predictions, get corrected by reality, and update their model. They do not need a training set for every new situation. They need the general capacity for model formation and causal reasoning, which develops through embodied experience in the physical world and which no transformer architecture produces through text prediction. The difference between these two kinds of intelligence is not a matter of degree. It is a matter of kind, and collapsing that distinction is how we end up with billion-dollar systems that confidently hallucinate medical diagnoses.

I also want to address the specific version of the objection that says intelligence is a spectrum and the models are somewhere on it. This objection sounds measured and scientifically responsible, but it contains a hidden assumption that I reject, which is that the mechanisms of human intelligence and the mechanisms of neural network prediction are the same mechanism operating at different intensities. They are not. They are different mechanisms. A thermometer measures temperature in a way that is mechanistically completely different from how your body feels temperature. A photograph of a landscape is mechanistically completely different from a painting of the same landscape. Both the thermometer and your skin produce a response that covaries with temperature, but one is an engineered measurement and the other is a felt experience rooted in biology, and they are not on the same spectrum. Similarly, a language model produces outputs that covary with intelligent human outputs because it was trained to do so, but the process producing those outputs is mechanistically different from the process producing human intelligence, and being on a similar output spectrum does not make them the same kind of thing (1). The history of AI is full of systems that produced outputs indistinguishable from intelligent behavior on narrow tasks and then failed completely when the task changed even slightly. That failure is the signature of a mechanism mismatch, not a capability gap that will close with scale.

The practical dimension of this distinction matters enormously and is not being discussed honestly in the public conversation. When companies deploy systems as autonomous agents and claim those systems are genuinely intelligent, they are making an implicit promise about the range of conditions under which those systems will perform reliably. Genuine intelligence implies robustness across novel conditions. Artificial intelligence implies reliable performance within the training distribution. Those promises are completely different in scope, and the gap between them is where people get hurt. A system that is genuinely autonomous can be trusted to handle situations that were not anticipated during design. A system that mimics autonomy can only be trusted to handle situations that are close to what it was trained on, which is a critically different trust relationship, and conflating them is how we end up with autonomous vehicles that fail in light rain, autonomous medical advisory systems that fail with unusual patient presentations, and autonomous coding agents that confidently introduce security vulnerabilities that no human reviewer would miss. The linguistic distinction between genuine and artificial intelligence is not a game. It is the most practically important distinction in the entire field.

But OpenAI Just Solved Mathematics, So Checkmate?

Deep breath. Deep breath. Okay. Let me say this as kindly as I can manage, which is not very kindly. I already wrote about this general category of result in multiple previous posts and predicted it would happen, which means the result was not surprising to me, and I want to explain exactly why it should not be surprising to anyone who has been paying attention. A model trained on the entirety of human mathematical knowledge, which includes not just the correct theorems but the failed proofs, the partially solved problems, the heuristics, the analogies, the researcher notes, the textbook exercises, the competition problems, and the entire corpus of mathematical reasoning as expressed by humans over several centuries, that model generating solutions to problems that were previously unsolved is expected. I did not say it is unimpressive. I said it is expected. There is a difference, and the difference matters for what we conclude from it.

The Navier-Stokes problem is a genuinely hard mathematical problem. Let nobody suggest I am dismissing its difficulty or its importance. But the way the model approaches a hard mathematical problem is not the way a mathematician approaches a hard mathematical problem. A mathematician builds a conceptual model of the problem space, identifies the structural feature that makes the problem hard, looks for analogies in other areas of mathematics that share that structural feature, formulates a hypothesis about what kind of argument strategy might work, explores that strategy, gets stuck, backtracks, reformulates, and eventually either succeeds or concludes that the approach was wrong. That process is generative intelligence operating on a causal model of the mathematical structure. What the model does is something statistically similar to pattern completion over a learned representation of mathematical text, and the fact that this can sometimes produce correct proofs for previously unsolved problems is remarkable but it is not evidence of genuine mathematical intelligence any more than a sufficiently detailed weather simulation is evidence that the simulation understands meteorology (2). The simulation produces correct predictions. It does not understand. The model produces correct proofs. It does not understand. These are not the same thing.

I also want to say something about the specific framing of "OpenAI has solved mathematics" that appears in every breathless tech news headline when one of these results drops. Mathematics is not a set of problems to be solved. Mathematics is a living, generative discipline that creates new problems faster than it solves old ones, because in mathematics the solution to a problem almost always reveals new structure that opens 10 harder problems. The Mossad agents who normally help me with my architectural decisions apparently also help me with my epistemology, and they would point out that the interesting question is not whether the model can solve the existing unsolved problems but whether the model can formulate new problems that reveal new mathematical structure. Chollet argued in his landmark paper on measuring intelligence that skill acquired through training is fundamentally different from the fluid intelligence required to form entirely new problems, and that metrics which reward skill without measuring generalization ability give a systematically misleading picture of what a system can do (3). Ramanujan did not solve existing problems. He discovered entire new areas of mathematical structure that nobody had imagined. A language model trained on Ramanujan's work can reproduce patterns from his work. It cannot be Ramanujan.

The pollution dimension of this situation also deserves explicit attention, because it is already happening and its consequences are already visible. As AI companies race to demonstrate mathematical or scientific capability, they are flooding academic preprint servers and research journals with AI-generated content at a rate that exceeds the human capacity for review and evaluation. The result is not an acceleration of scientific knowledge. The result is an acceleration of scientific content, which is a different and far more dangerous thing. Scientific content without the verification, the debate, the failed replication attempts, the collegial argument that slowly separates the genuine advance from the plausible-sounding error, that content is not science. It is noise that looks like science, and it degrades the ability of the research community to identify and build on genuine advances. I wrote in LLMs destroyed the Internet. LMMs will make it alive about how automated content generation destroys the epistemic value of the information environment. The same dynamic is now operating in the scientific literature, and the long-term cost is the trustworthiness of science itself. Nobody is excited. Nobody is shocked. And nobody should be, because this was predictable.

I want to also directly address the human dimension of this, because I think it gets lost in the excitement over capability demonstrations. We human beings value effort not as a quirk of our psychology but because effort is the mechanism by which understanding is produced. The struggle to solve a hard problem, the years of failed attempts, the moments of insight that feel like gifts because they follow months of fruitless work, those are not inefficiencies to be optimized away. They are the process by which a human mind builds a deep causal model of a problem domain. When a system produces a solution without that struggle, the solution may be correct but it is also orphaned. It has no parent understanding. Nobody who holds that solution knows why it works in a deep enough sense to know where to go next. This is the reason that human mathematicians are, almost universally, not excited about AI-generated proofs. The proof is not the point. The understanding that the proof reveals is the point. A proof you did not struggle to find is a solution to a crossword puzzle completed by someone else. You have the answer. You do not have the understanding. And in mathematics, as in everything that actually matters, the understanding is the whole game.

But GPT-N Omega Pro Max++ Vibe-Coded This Entire Game Fully Autonomously?

Here we go. Let me compose myself. Okay. I am composed. This argument comes up constantly now, and it follows the same template every time. An AI model, usually labeled with some impressive name involving a high number or a Greek letter, produces a functional artifact, usually a game, a website, or a piece of software, without explicit human instruction at the code level, and the result is presented as evidence of autonomous creativity and genuine intelligence. I need to take this apart, carefully and without losing my temper, because the argument is seductive and the counterargument requires more than a sentence to deliver properly. So let us be thorough about it.

The first thing to understand about a model generating a functional game autonomously is what the word generating means in this context. The model does not create the game the way a human game developer creates a game. A human game developer starts with a vision, an aesthetic, a set of mechanics, a world, a set of rules that interact in interesting ways, and then implements all of that through a sequence of design and engineering decisions that each encode an aspect of the original vision. The interesting part is not the code. The interesting part is the creative vision that the code expresses. A language model generating a game produces code that is a collage of patterns from similar games in its training data, recombined in ways that happen to produce a functional result. The result may run correctly. It does not express a creative vision, because the model has no communicative intent, no aesthetic intention, no sense of what would be interesting or meaningful to a player. Bender et al. argued precisely this in their foundational critique of large language models: that these systems are stochastic parrots producing form without meaning, statistical mirrors of human text that carry none of the communicative intent that makes human language meaningful (4). It has learned what game code looks like, and it produces something that fits that learned distribution.

The second thing to understand is that nobody wants to play the game. And this is not a small point. This is the entire point. A game's value to a player is not its technical correctness. A game's value is its soul, its lore, its narrative, its sense of humor, its respect for the player's time and intelligence, and above all its feeling of having been made by someone who cared about the experience of playing it. These are properties that I can detect immediately when I pick up a game, and so can you, even if you cannot articulate them precisely. When someone tells you that an LLM generated this entire game, something in you deflates, and that deflation is not irrational. It is a recognition that the thing is a hollow artifact. It runs, but nobody meant it. And meaning is not an optional luxury feature of creative work. Meaning is the entire reason creative work has value to the people who experience it. A game without meaning is just a physics engine with textures. You would get more out of asking the LLM to live-stream a playthrough of the game for you on the fly, which the LLM can do, and which would be more interesting to watch than playing a game that nobody genuinely imagined.

The third thing to understand is the structural incompleteness of what gets described as fully autonomous generation. What the model actually did in every documented case of this type, when you look at the methodology rather than the marketing, is generate a frontend scaffold for a simple game loop, using patterns from similar open-source games in its training data. The complete experience of a game in the real world involves enormously more infrastructure than a scaffold. It involves backend services, matchmaking systems, chat infrastructure, anti-cheat systems, persistent player state, telemetry, analytics, abuse reporting, content moderation, accessibility features, localization, monetization systems, third-party service integrations, compliance with platform policies, and decades of iterative refinement based on player feedback. None of that exists in the autonomously generated output. What exists is a proof of concept that demonstrates the model can produce code that resembles the code of games it was trained on. Calling that full autonomous game development is like calling a photograph of a house the house. The photograph is an artifact that references the structure. The model output is an artifact that references the functionality. Neither of them are the thing itself.

I also want to say something about the direction this argument is going, because I see it more and more: the claim that because the model can produce the surface form of creative work, the model is producing creative work, that because it can generate code that compiles, it is doing software engineering, that because it can write a sentence that is grammatically complex, it is engaging in literary expression. This is the philosopher's zombie problem applied to AI, and I want to name it clearly. A philosophical zombie, in thought experiment form, is an entity that behaves exactly like a conscious being in every observable respect but has no inner experience of that behavior. The behavior is there. The inner life is not. Current AI systems are philosophical zombies of intelligence. They produce the behavioral outputs associated with intelligence. The inner process producing those outputs is pattern completion over a learned statistical distribution, not reasoning, not understanding, not intention, not creativity. And a zombie playing chess is not a chess player. It is a zombie that makes moves. The distinction matters for what you trust the zombie to do next.

What LLMs Are Actually Doing, and Why It Is Just The Tip of The Iceberg

I want to be fair here, because I have been consistently fair in every post I have written, even when the thing I am being fair about is something that is actively used to argue against positions I hold. LLMs are powerful. They are more powerful than most people thought possible five years ago. They are useful, they are economically valuable, and the scale of what they can do within their training distribution is genuinely impressive. I wrote all of that in LLMs are Usefull. LMMs will Break Reality, and I stand by every word of it. But power within a training distribution is not the same as autonomy, and the gap between what LLMs can do and what production systems require is not a gap that can be bridged by wrapping the model in a better API.

Think of a language model as a very sophisticated for-loop with memory. At each step, the loop looks at the current context, applies a search over the learned representation space, samples from the resulting distribution using some randomness to prevent deterministic collapse, and appends the result to the context before running the next iteration. That is a real and powerful computation. It is also a computation that is entirely reactive. It does not initiate. It does not plan beyond the immediate token horizon. It does not build a model of what it is trying to accomplish and monitor the gap between that model and the current state. It responds to input with statistically appropriate output. This is enormously useful for code completion, for document summarization, for information synthesis, for translation. It is not autonomous operation. Shanahan, in his careful philosophical treatment of what it means to talk about large language models honestly, argues that the anthropomorphism enabled by LLMs' fluency in human language makes us systematically vulnerable to describing them in terms that do not match their actual mechanism, and that repeated stepping back to ask what the system actually does will almost always reveal a reactive prediction engine rather than a reasoning actor (5).

The production software systems that people actually run in the real world are not merely frontend scaffolds. They are layered stacks of interacting subsystems, each with its own failure modes, its own performance characteristics, its own operational requirements, and its own behavioral contracts with the other subsystems. A game on a real production platform has a game server cluster, a matchmaking service, a leaderboard service, a player identity and authentication service, a database cluster with replicas and backup procedures, a CDN for asset delivery, a monitoring and alerting stack, a deployment pipeline, a rollback procedure, a DDoS mitigation layer, and usually somewhere between three and five third-party service integrations that each have their own documentation, API limits, and failure behaviors. The model that generated the game frontend has no knowledge of any of this beyond the surface patterns it absorbed from documentation text in its training data. Building production systems is an exercise in understanding the mechanisms of failure across a complex interacting set of subsystems, and understanding failure mechanisms requires causal models that no language model has (6).

The voice chat room in an online game is not a text generation problem. The latency constraints, the packet loss handling, the codec selection, the server-side mixing, the abuse detection in audio streams, the GDPR compliance for voice data, the integration with the client application, the regional routing for low latency, none of these are problems that get solved by generating plausible-sounding text about how voice chat would look. They are engineering problems that require deep understanding of network protocols, audio signal processing, distributed systems, regulatory frameworks, and the specific constraints of the game's platform and user base. The autonomously generated game has none of that. It has a textbox. And a textbox is not a voice chat room, no matter how many parameters the model that generated it has. This is not a criticism of the model. It is a description of what the model is and is not, and what production software is and is not, and why those two things are not the same.

I want to connect this to something I said in All You Have Access To Is Knowledge and Tools; Never Intelligence! about the frame problem. The frame problem, in practical engineering terms, is the problem of knowing which things change when you take an action and which things do not. When you deploy a new version of a service, what changes is the behavior of that service. What must not change, if you want your system to continue working, is the behavioral contracts between that service and everything it interacts with. Managing those contracts, reasoning about what is downstream of what, identifying which changes are safe and which are breaking, that is the daily work of a software engineer operating in a production system. It requires a causal model of the system. It requires the capacity to simulate what will happen when a change propagates through a layered stack of interacting services. A language model can produce code that looks like service code. It cannot reason causally about what will happen when that code runs in the production system, because it does not have a causal model of the production system. It has text about systems that look similar. That is the tip of the iceberg. The iceberg is everything that the text does not capture, and in production engineering, the iceberg is where ninety percent of the work lives.

The Autonomy Illusion: How Wrappers Become Worldviews

One of the most sophisticated-sounding arguments for AI autonomy goes like this: yes, the model itself is just pattern completion, but wrap it in the right scaffolding, give it memory, give it tools, give it the ability to call itself recursively, and you get something that is functionally autonomous even if the underlying mechanism is not. I hear this argument a lot from people who are technically sophisticated, and I want to engage with it honestly because it deserves engagement rather than dismissal. The argument is not crazy. There are systems architectures where simple computational units combine into systems with properties that no individual unit has. Neurons are simple threshold devices. Brains compute extraordinarily complex things. So why can't a simple language model plus scaffolding produce genuine autonomy?

The answer is that the brain analogy fails at the level of mechanism, and mechanism is the thing that matters. Neurons combined into brains produce intelligence because the combination instantiates specific computational structures, specifically causal inference over hierarchical generative models, that are capable of producing genuine reasoning, genuine model formation, and genuine updating in response to prediction error (7). The computation is grounded in physical reality through sensorimotor experience that provides labeled prediction errors across millions of daily interactions. The structural organization of the brain, the cortical hierarchy, the basal ganglia, the hippocampal memory systems, the thalamic gating, is specifically adapted over millions of years of evolution to produce the kind of learning and inference that counts as intelligence. Wrapping a language model in scaffolding and memory does not replicate any of this. It adds a context management layer on top of a reactive prediction system. The scaffolding does not change what happens inside the prediction step, and the inside is where the intelligence would have to live.

Memory does not solve the problem. Memory gives the model access to more text context. But having access to more text does not produce causal reasoning from that text. It produces pattern completion over more text. A model with a million-token context window is not more intelligent than a model with a four-thousand-token context window. It has more information available for its pattern completion. That is a real and useful improvement. It is not a mechanism for producing genuine reasoning, because the mechanism producing the output at each step is still pattern completion, regardless of how much context is available to that step (8). A person who reads more books is not smarter than a person who reads fewer books in any direct proportional sense. A person who reads more books has more raw material for their intelligence to work with. The intelligence doing the working is not in the books. It is in the cognitive architecture that was shaped by evolution and development long before the first book was opened.

Tool use does not solve the problem either, and I made this argument at length in All You Have Access To Is Knowledge and Tools; Never Intelligence!. A language model that can call a calculator, a search engine, and a code interpreter is a language model plus three lookup operations. The intelligence required to know which tool to use in which situation, to interpret what the tool returns, to integrate the tool output with the rest of the reasoning context, that intelligence has to live somewhere. And in the agentic architecture, the place it is supposed to live is the language model. But the language model's behavior in that role is still pattern completion over training data about how agents use tools, not genuine reasoning about which tool is appropriate for the current problem. The result is that the tool-augmented agent fails in characteristic pattern-matching ways on novel tool usage situations, which is exactly what the research shows (9). You can add recursion too. The model can call itself repeatedly, reflecting on its own output, generating a chain of self-assessments. But each step in that chain is still a pattern completion step, and a chain of pattern completion steps is not reasoning any more than a chain of coin flips is a decision. The appearance of self-reflection does not instantiate self-reflection.

Genuine autonomy requires something that none of these scaffolding additions provide, which is an internal model of the task that allows the system to distinguish between situations where the current approach is working and situations where the current approach is failing, and to adaptively switch strategies based on that distinction. That is meta-cognitive control, the ability to monitor the quality of one's own cognitive processes and to intervene when quality is insufficient. Research on human metacognition has established that this capacity develops through years of embodied feedback, through the experience of trying, failing, noticing the failure, trying differently, and building a model of one's own cognitive strengths and weaknesses in specific domains. Language models have a statistical approximation of metacognitive language, they can produce text that sounds like self-assessment. They do not have the underlying process, the monitored internal model that the self-assessment text is supposed to describe. The words are there. The referent is not. And an autonomous agent without genuine metacognitive control is not an autonomous agent. It is a system that will continue confidently in the wrong direction for as long as the statistical distribution of its training data supports doing so.

The Research Nobody Wants to Read But Everybody Should

I want to spend time in this section on the empirical evidence, because I believe strongly that the argument I am making is not just philosophically sound but empirically grounded in a body of research that is not making it into the popular conversation with the prominence it deserves. The popular conversation about AI capability is substantially driven by benchmark performance announcements, demo videos, and press releases. The empirical research literature on what AI systems cannot do is substantially less visible. That asymmetry is not neutral. It shapes what people believe about the current state and trajectory of AI, and beliefs shape decisions, and decisions about AI deployment have real consequences for real people.

The research on AI agent reliability is the most directly relevant to the autonomy question, and the results are unambiguous. Kambhampati et al. demonstrated from first principles that auto-regressive LLMs cannot, by themselves, perform sound planning or self-verification, because the next-token prediction mechanism does not implement the look-ahead and backtracking required for global goal alignment (9). This theoretical argument is validated empirically in large-scale agent benchmarks: the WebArena evaluation placed state-of-the-art GPT-4-based agents on realistic long-horizon web tasks and measured a task success rate of only 14.41 percent against a human success rate of 78.24 percent, representing failure rates exceeding eighty-five percent on tasks that a capable human completes routinely (10). The failure modes are consistent and predictable: agents take locally plausible actions that compound into globally incorrect outcomes, and when they encounter situations that do not match their training distribution, they either fail to recognize the mismatch or continue confidently toward the wrong outcome. These are not random failures. They are the systematic signature of a system that lacks a global model of the task and is therefore unable to detect when the local action is inconsistent with the global goal. A genuinely autonomous system would detect this inconsistency and recover. A pattern-matching system cannot, because detecting the inconsistency requires comparing the current state against a model of the intended state, and that kind of model-based comparison is not what pattern completion produces.

The research on distribution shift, which I discussed in Genuine Intelligence will never in trillion years emerge from neural networks, has continued to accumulate in the same direction. Study after study finds that AI systems perform reliably within their training distribution and unreliably outside it, and the performance degradation is dramatic rather than gradual. Taori et al. systematically evaluated 204 ImageNet classification models across 213 different test conditions and found that robustness gains from synthetic perturbation training rarely transferred to natural distribution shifts, and that virtually no existing technique fully closes the performance gap between in-distribution and naturally shifted test sets (11). This is the canonical signature of a system that has learned to exploit statistical regularities in the training data rather than learning the underlying rule that generates the data, and it appears consistently across architectures, scales, and domains. It does not go away with more scale. It changes in its specific manifestations as the model becomes more capable within its distribution, but the structural incompatibility between pattern matching and genuine generalization remains. More impressive pattern matching is still pattern matching, and pattern matching does not become autonomy at any scale.

The research on AI in high-stakes professional domains is perhaps the most concrete evidence of the autonomy gap, because these are exactly the domains where genuine autonomy would be most valuable and where its absence is most costly. Obermeyer et al. conducted a landmark analysis of a commercial health-management algorithm and found that it systematically underestimated the health needs of Black patients because it used healthcare cost as a proxy for health need, encoding the structural reality that Black patients had less access to care into a learned bias that treated them as healthier than equally sick White patients (12). The algorithm was not doing medicine. It was doing pattern matching over a dataset where the patterns encoded centuries of unequal access. A genuinely autonomous medical reasoner, one operating from a causal model of pathophysiology, would not confuse spending patterns with health status. A pattern-matching system cannot distinguish between them, because in its training data, they covary, and covariation is all it can learn. The bias shows up not as a subtle statistical artefact but as a systematic, measurable failure that affects real patients in real clinical settings, and it is invisible to the system producing it because the system has no model of the mechanism generating the pattern.

The research on AI legal reasoning has found similar patterns. Dahl et al. conducted the first systematic profiling of legal hallucinations in large language models and found that legal hallucinations were alarmingly prevalent, occurring between 58 percent of the time with GPT-4 and 88 percent of the time with Llama 2 when models were asked specific, verifiable questions about federal court cases (13). The model that passes the bar examination has learned the statistical distribution of bar examination questions, which is a specific and relatively well-defined distribution that diligent pattern matching can handle. But when the same model is asked to retrieve or reason about actual legal specifics, specific case names, specific holdings, specific statutes in specific jurisdictions applied to specific novel fact patterns, it confabulates with high confidence, because the specific combination has no reliable match in the training distribution and the model has no actual model of legal structure to reason from. Dahl et al. also found that LLMs often cannot correct a user's incorrect legal assumptions, and frequently do not know when they are producing a hallucination, which is the overconfidence signature in its most dangerous possible form. This is happening in systems already deployed in real legal contexts, serving real clients.

Genuine Intelligence Requires Genuine Grounding, and That Grounding Cannot Be Simulated in Tokens

There is a philosophical concept called grounding and it explains a great deal about why text-trained models cannot achieve genuine autonomy. Grounding refers to the connection between a symbol and the thing in the world that the symbol refers to. When I use the word hot, my use of that word is grounded in my experience of touching hot surfaces, of feeling the burns, the warmth, the danger signal, the automatic withdrawal reflex. That experience is what gives the word hot a meaning that goes beyond its statistical relationship with other words. A language model's use of the word hot is statistically associated with other words like fire, pain, temperature, summer, and coffee, and that statistical association allows it to produce contextually appropriate text involving the word hot. But the word is not grounded in any felt experience of heat. It is an ungrounded symbol, and ungrounded symbols cannot support genuine reasoning about the referents of those symbols in the way that grounded symbols can (14).

The grounding problem is not merely philosophical. It has direct practical consequences that show up in specific failure modes. A model with ungrounded symbols cannot reason about physical interactions in novel situations because its knowledge of physical interactions is stored as statistical associations between words that describe physical interactions, not as a model of the physics itself. Ask the model to predict what will happen when you drop a cube of ice into a glass of warm water, and it will produce the correct answer because that scenario is well-represented in its training data. Ask it to predict what will happen when you drop a specific non-standard material with specific non-standard thermodynamic properties into a specific non-standard fluid under non-standard pressure, and it will confabulate, because the specific combination has no statistical precursor in the training data and the model has no actual physical simulation to fall back on. A genuinely intelligent system would use its physical model, its understanding of thermodynamics, to compute the answer for any combination of materials and conditions. The model uses its training data, which means it only knows what it has been told about specific scenarios. And there are infinitely many specific scenarios that nobody has written text about.

The solution to the grounding problem is not more text. More text does not ground symbols in physical reality. More text gives you more ungrounded symbols with richer statistical relationships to each other. A model trained on every physics textbook ever written has abundant statistical associations between physics words. It does not have a single simulation of a physical process grounded in the actual dynamics of the physical world. This is why I have argued across multiple posts for the importance of mathematical models and physics simulations as the alternative architecture. Mathematical Equations are Multimodal by default describes why equations are more honest representations of physical reality than text, because equations encode the mechanism rather than a description of the mechanism, and mechanisms are what ground the predictions in reality. A model built around equation discovery and physical simulation has symbols that are grounded in the dynamics of physical reality. A language model has symbols grounded only in other text. The first kind of grounding supports genuine reasoning about novel physical situations. The second kind supports sophisticated text generation about familiar textual patterns. Those are not the same capability.

Embodied cognition research has established over the past three decades that human intelligence is not separable from the body that hosts it and the physical world that the body interacts with (16). When you understand what it means to grasp something, that understanding is rooted in the sensorimotor experience of grasping, the feel of fingers closing, the resistance of the object, the proprioceptive sense of hand position and grip strength. Your understanding of the abstract concept grasping a concept is a metaphorical extension of that embodied experience, and research shows that even processing abstract language activates sensorimotor neural systems involved in the corresponding physical actions. Intelligence is not a disembodied computation over abstract symbols. It is a computation deeply intertwined with a physical body that experiences the world and updates its models on the basis of that experience. Language models, by design, have no body, no sensorimotor experience, no felt consequences for wrong predictions, and no physical world to update against. They have text. Text is a description of embodied experience. A description of embodied experience is not the same as embodied experience, and intelligence built on descriptions cannot do what intelligence built on experience can do.

I want to close this section by saying something about what genuine grounding would require that I think is underappreciated. Genuine grounding requires not just sensory data but the feedback loop between predictions and their consequences. It requires a system that has made predictions about the physical world and had those predictions either confirmed or disconfirmed by events in that physical world, and that has updated its internal model on the basis of that feedback. This is the reinforcement learning setup in its genuine sense, not the RLHF approximation that is used to fine-tune language models, but actual reinforcement learning where the signal comes from the physical world. Reinforcement learning in that genuine sense can produce grounded representations of the world, as demonstrated by robotics systems and simulation-trained physical agents. But those systems are not language models. They are a different architecture solving a fundamentally different problem. And the intelligence produced by genuine reinforcement learning against physical reality does not transfer from the language model paradigm regardless of how large the language model becomes.

We Do Not Even Know What We Do Not Know, and That Is the Real Problem

One of the most dangerous properties of current AI systems in deployment is the combination of high capability within the training distribution and high confidence everywhere. The system does not degrade gracefully as it approaches the edge of its competence. It falls off a cliff while still sounding absolutely certain. This is the property that I find most troubling about the current deployment environment, more troubling than any specific failure mode, because it makes the failures unpredictable and therefore unmanageable. If a system degraded gracefully and signaled increasing uncertainty as it approached the edge of its competence, you could deploy it with appropriate monitoring and respond to the signals before the failures had consequences. But a system that fails while sounding confident fails silently, from the user's perspective, until the failure has already had consequences.

Calibrated uncertainty, the property of knowing what you do not know, is a defining feature of genuine intelligence and a property that neural networks systematically lack in their base form. Guo et al. demonstrated in a foundational study of neural network calibration that modern deep neural networks are poorly calibrated compared to their predecessors, that they are systematically overconfident, and that this overconfidence grows with model depth, width, and the use of batch normalization, meaning that the architectural choices that make neural networks more accurate also make them more overconfident in their wrong answers (15). A model that has seen many confident-sounding statements in its training data will produce confident-sounding statements in contexts that resemble its training data, regardless of whether that confidence is warranted in the specific case. This is not a calibration bug that can be patched. It is a structural consequence of the training objective, which rewards producing confident predictions on training examples and has no direct mechanism to penalize overconfidence in the specific situations where the model's knowledge is weakest.

The absence of genuine metacognitive monitoring is the root cause. A genuinely intelligent system would monitor the quality of its own reasoning, flag when it was operating in unfamiliar territory, and scale its expressed confidence to match its actual epistemic state. This kind of metacognitive monitoring is what humans call knowing what you know and knowing what you don't know, and while humans are imperfect at it, the basic capacity exists and can be trained and improved. In neural networks, the absence is architectural. The model produces its outputs through a single forward pass, without any separate process that monitors the quality of the reasoning or evaluates the confidence of the output against the strength of the evidence. Techniques like sampling-based uncertainty estimation give a proxy for disagreement between model samples, but that proxy is not the same as genuine metacognitive monitoring, and it does not prevent the confident production of confident-sounding wrong answers. The model does not know what it does not know because it does not have a model of what it knows. It has weights. Weights do not know things. They encode statistical associations, and statistical associations do not have an epistemic status that the model can introspect and evaluate.

For a genuinely autonomous system, calibrated uncertainty is not optional. It is the mechanism by which an autonomous agent decides when to act on its own judgment and when to seek additional information, defer to a human, or flag a decision as requiring review. Without this mechanism, an autonomous agent will make high-stakes decisions in low-competence situations with the same apparent confidence as low-stakes decisions in high-competence situations, and the consequences of that cannot be managed at the deployment layer. You cannot fix a systematic overconfidence problem with monitoring alone, because the monitoring has to use the same system's outputs to assess the same system's confidence, and the system is wrong about its own confidence. This is the autonomy gap in its most concrete operational form. An autonomous vehicle that does not know where its competence ends is not safer than a human driver who does know where their competence ends. It is dramatically less safe. And scaling the model does not change the fundamental absence of the metacognitive architecture that would make it possible for the model to know what it does not know.

What Would Genuine Autonomous Intelligence Actually Require?

I want to be honest and constructive here because I have been making a primarily negative argument for most of this post and I genuinely believe in the possibility of building genuinely autonomous intelligent systems. I do not believe current neural networks can get us there. I believe the alternative direction exists and is the right one, and I want to describe it clearly. If you have read my previous posts, you have seen pieces of this argument scattered across multiple places. Here I want to assemble those pieces into a description of what the right architecture would need to look like.

First, it would need causal modeling rather than statistical association. The difference is not subtle. A causal model of a domain represents the mechanisms that generate the observations, not just the statistical relationships between observations. A causal model of a medical domain would represent the biological mechanisms by which diseases produce symptoms, not the statistical correlation between symptoms and diagnoses in a training dataset. Causal models support genuine generalization because they generalize at the level of mechanism, which is domain-invariant, rather than at the level of surface patterns, which are training-distribution-specific. Judea Pearl's work on causal inference and the do-calculus provides the mathematical foundation for this, and the field of causal machine learning, while early stage, is producing real results (17). This is the right direction. It is also harder, slower, and less impressive in demos than scaling language models, which is why it is underfunded and understaffed relative to its importance.

Second, it would need symbolic reasoning over learned representations, not just learned representations by themselves. Symbolic reasoning is what provides the truth-preserving inference rules that allow a genuine reasoner to derive new knowledge from known knowledge in ways that are reliable rather than statistically likely. The neurosymbolic research program, which I described in Genuine Intelligence will never in trillion years emerge from neural networks, is the most promising approach here. It attempts to combine the representation learning strengths of neural networks with the structured inference strengths of symbolic systems. The engineering challenges are real but the theoretical case is solid. A system that can learn good representations from data and reason over those representations using principled inference rules would have systematic compositionality, would support genuine logical reasoning, and would avoid the surface-pattern dependence that characterizes pure neural approaches.

Third, it would need physical grounding through interaction with the real world rather than text descriptions of the real world. This means some form of sensorimotor experience, either through robotics, through physics simulation with real physical fidelity, or through other forms of direct interaction with physical processes that produce genuine prediction errors when the system's model is wrong. The lmm project I have been building is an attempt to implement a piece of this, with symbolic regression for discovering physical equations from data rather than ingesting descriptions of physical equations from text. An LMM architecture that learns physical laws from measurements of physical processes has symbols grounded in physical reality in a way that a language model trained on text descriptions of physical laws does not. The grounding is genuine because the equations have been validated against real physical data, not because someone wrote down that the equations are valid.

Fourth, it would need genuine metacognitive architecture, a separate process that monitors the quality of the primary reasoning process and has the authority to intervene, redirect, or flag uncertainty when warranted. This is not the same as adding a reflection step to the language model output. A reflection step is still a language model output, a pattern completion over descriptions of what good reflection looks like. A genuine metacognitive architecture is a separate computational process with a different objective from the primary reasoning process, specifically the objective of evaluating whether the primary reasoning is working and the objective of identifying when it is not. The computational structure for this exists in various proposals in the cognitive science and AI literature, and while no current system implements it in a satisfying way, it is a tractable engineering problem rather than an impossible one. The impossibility is not in building genuine metacognitive architecture. The impossibility is in producing genuine metacognition from a single-objective next-token prediction training process. You need to build the metacognitive capacity explicitly. It does not emerge from scale.

Where Do We Go From Here, And What Honest Progress Looks Like

I want to close this post the way I have closed every post before it, which is by saying something honest rather than something comfortable. The honest state of affairs is this: neural networks are extraordinarily powerful tools that operate within their training distributions with impressive and genuinely useful capability. They are not genuinely autonomous agents, they are not genuinely intelligent, and they will not become either of these things through further scaling of the same architecture. The gap between what they are and what genuine autonomous intelligence requires is architectural, not quantitative, and architectural gaps require different architectures, not more of the same architecture. This is not pessimism about AI. This is clarity about what the current tools are and a call for honesty about the gap between them and what we are claiming to build.

The progress that would actually matter, the progress toward systems that can reason causally, that have grounded representations, that can generalize systematically, that know what they do not know, is happening in smaller research communities with less funding and less visibility than the communities building larger and larger language models. Causal machine learning, neurosymbolic AI, physics-informed learning, symbolic regression, embodied AI, all of these research directions are producing results that are more relevant to genuine autonomous intelligence than anything coming out of the scaling race, and they are producing those results with a fraction of the compute and a fraction of the investment. The academic incentive structure, the funding structure, and the media attention structure are all pointing in the wrong direction. The right direction is harder, slower, and does not produce demos that trend on social media. But it is the direction that leads somewhere real.

For those of you who build things, which is most of the people I know and most of the people who read this blog, the honest implication of this argument is that you should use current AI tools for what they are good at, which is significant, and build your systems with appropriate understanding of where those tools fail. Do not build systems that depend on AI judgment in situations that fall outside the training distribution unless you have robust monitoring and human oversight for exactly those situations. Do not tell your users that your system is autonomous when it is a language model in a scheduling for-loop. Do not cite benchmark performance as evidence of real-world capability in novel domains. These are not technical requirements. They are honesty requirements. And honesty about what our tools can and cannot do is the minimum ethical obligation of anyone who builds and deploys systems that affect other people's lives.

The future I want to build toward, and the one I am working on in my small way with the lmm project, is a future where artificial systems earn the word autonomous through demonstrated behavior in situations that were not anticipated during design. Not through impressive demo performance on curated benchmarks. Not through confident-sounding answers to questions that happen to be in-distribution. Through genuine generalization to genuine novelty, through honest uncertainty when facing unfamiliar territory, through the capacity to form new understanding rather than retrieve old patterns. That future is technically achievable. It requires different architecture, different training objectives, different evaluation criteria, and different honesty from everyone involved in building and deploying these systems. It also requires that we stop congratulating ourselves for the current tools as though they are already there, because they are not, and pretending otherwise is how we make the journey longer, not shorter.

Till next time 👋!

References

1. Searle, J. R., Minds, Brains, and Programs, Behavioral and Brain Sciences, 1980

2. Marcus, G. & Davis, E., Rebooting AI: Building Artificial Intelligence We Can Trust, Pantheon Books, 2019

3. Chollet, F., On the Measure of Intelligence, arXiv:1911.01547

4. Bender, E. M., Gebru, T., McMillan-Major, A. & Shmitchell, S., On the Dangers of Stochastic Parrots: Can Language Models Be Too Big?, ACM FAccT 2021

5. Shanahan, M., Talking About Large Language Models, arXiv:2212.03551

6. Bommasani, R. et al., On the Opportunities and Risks of Foundation Models, arXiv:2108.07258

7. Friston, K., The free-energy principle: a unified brain theory?, Nature Reviews Neuroscience, 2010

8. Dziri, N. et al., Faith and Fate: Limits of Transformers on Compositionality, arXiv:2305.18654

9. Kambhampati, S. et al., LLMs Can't Plan, But Can Help Planning in LLM-Modulo Frameworks, arXiv:2402.01817

10. Zhou, S. et al., WebArena: A Realistic Web Environment for Building Autonomous Agents, arXiv:2307.13854

11. Taori, R. et al., Measuring Robustness to Natural Distribution Shifts in Image Classification, arXiv:2007.00644

12. Obermeyer, Z., Powers, B., Vogeli, C. & Mullainathan, S., Dissecting racial bias in an algorithm used to manage the health of populations, Science, Vol. 366, 2019

13. Dahl, M. et al., Large Legal Fictions: Profiling Legal Hallucinations in Large Language Models, arXiv:2401.01301

14. Harnad, S., The Symbol Grounding Problem, Physica D: Nonlinear Phenomena, 1990

15. Guo, C. et al., On Calibration of Modern Neural Networks, ICML 2017

16. Lakoff, G. & Johnson, M., Philosophy in the Flesh: The Embodied Mind and Its Challenge to Western Thought, Basic Books, 1999

17. Pearl, J., Causality: Models, Reasoning, and Inference, Cambridge University Press, 2009

🔐 OTP RS: RFC-Compliant OTP Input Components for WASM Frameworks

Mahmoud 🦀 — Sun, 04 Oct 2026 11:24:36 +0000

Nǐ hǎo 👋!

You've seen the textbox. You've typed the number. You've waited three seconds for the SMS that never came, checked your spam folder, clicked "Resend", typed the number again, and finally admitted to yourself that 2FA is simultaneously the most important and most annoying invention of the modern web.

Today, we make it marginally less annoying, at least on the Rust side. We're shipping OTP RS.

What Even Is OTP RS?

OTP RS is a composable, accessible, animated One-Time Password input component for Yew, Dioxus, and Leptos. It implements the full verifier flow: slot-by-slot input, keyboard navigation, active/filled/invalid/disabled states, animated caret blink, digit-entry pop animation, and RFC 4226 (HOTP) + RFC 6238 (TOTP) validation, all in Rust, all in WASM, all without touching a single line of JavaScript.

If you've ever tried to build a 6-box OTP input from scratch, you know the drill. It starts with "just six inputs". Two hours later you're debugging focus management, backspace propagation, keyboard event edge cases, browser autofill hijacking your state, and the invisible iOS number pad refusing to appear. That's the origin story of OTP RS.

Component Architecture

OTP RS follows the same composable anatomy as every other component in the Open SASS Kit. You compose what you need:

Otp: Root container. Owns the internal value state, focus coordination, and the RFC validation callbacks.
Group: A visual cluster of slots (e.g., three digits, then a separator, then three more).
Slot: Individual slot. Renders a visible character display on top of an invisible overlay <input>.
Separator: The little dash in between groups.

use otprs::yew::{Otp, Group, Separator, Slot};
use yew::prelude::*;

#[function_component(VerificationInput)]
pub fn verification_input() -> Html {
    html! {
        <Otp max_length={6} aria_label="Enter your OTP">
            <Group>
                <Slot index={0} />
                <Slot index={1} />
                <Slot index={2} />
            </Group>
            <Separator />
            <Group>
                <Slot index={3} />
                <Slot index={4} />
                <Slot index={5} />
            </Group>
        </Otp>
    }
}

That's it. Focus management, digit propagation, state aggregation, and ARIA attributes are all handled. You just compose slots.

The Invisible Input Trick

Here's the most important design decision in all of OTP RS: the <input> element that receives keyboard events is completely invisible.

Each Slot renders two layers:

An invisible <input> (via input-rs with otp_mode=true) that is position: absolute; inset: 0; opacity: 0. It captures all keyboard focus and input events.
A visible <span> that displays the digit character and the blinking caret.

This separates the input mechanics from the visual presentation, giving us full control over the slot's look without fighting browser defaults for <input> styling.

┌─────────────────────┐
│  Slot wrapper       │  ← position: relative; border; background; animation
│  ┌───────────────┐  │
│  │ <input>       │  │  ← absolute; opacity:0; captures keyboard events
│  └───────────────┘  │
│  <span>3</span>     │  ← visible character display
│  <span class=caret/>│  ← blinking caret (when active & empty)
└─────────────────────┘

The Invisible Input That Wasn't Actually Invisible

Here's a fun bug that bit us early on, hard.

The slot design described above only works if the CSS for the invisible input is applied as an inline style attribute, not as a CSS class attribute. The component originally passed the overlay CSS string to input_class, a prop that sets the HTML class="" attribute.

Browsers don't style elements based on CSS property strings stuck in the class attribute. They look up class names in stylesheets. So what we got instead of an invisible overlay was a white rectangle aggressively covering the entire OTP component, like a censored emoji on live TV.

The fix was to add an input_style: &'static str prop to input-rs in all three framework implementations, and apply it as style="{props.input_style}" on the bare otp_mode <input>. One line per framework. Six characters (_style vs _class). Three frameworks. Three PRs worth of suffering.

The Compiler Is Your Enemy (And Also Your Best Friend)

Let us count the ways Rust fought us this time.

Episode 1: Hook in a Macro

error[E0277]: the trait bound `impl Hook<Output = ...>: IntoPropValue<...>` is not satisfied

We tried calling use_state(...) inside an html! macro attribute. Yew forbids calling hooks anywhere except directly inside function component bodies. The macro expands to a closure, and hook calls need to be at the top level. Extracting use_state calls to let bindings before html! fixed it.

Episode 2: `Box::leak` and the `&'static str` Obligation

Dioxus and Leptos's input-rs props require &'static str. But our slot-specific strings like "Digit 3" are computed at runtime. The only way to produce a &'static str from a runtime String without pulling in a string interner is to Box::leak:

let label: &'static str = Box::leak(
    format!("Digit {}", index + 1).into_boxed_str()
);

Yes, this leaks memory on every slot render. Each Slot render leaks ~15 bytes. Is this ideal? No. Does it compile? Yes. Is it the correct long-term solution? The correct long-term solution is a Signal<String> prop type in input-rs, which is a future PR. For now: Box::leak and move on.

Episode 3: The `as` Cast That Broke Leptos

The Leptos view! macro cannot parse Rust cast expressions inline:

// This fails to parse inside view!:
validate_function=(|_: String| -> bool { true }) as fn(String) -> bool

The macro sees the as keyword and gets confused about what's a prop name vs. a type expression. The fix: extract to a let binding before the view! call:

let always_valid: fn(String) -> bool = |_| true;
// then inside view!:
validate_function=always_valid

Three lines in, five compilation cycles later. We hope this saves you ten minutes.

Episode 4: `String` vs `&str` in Dioxus `rsx!`

Dioxus's rsx! macro is strict about attribute types. When slot_class was a String, the macro would refuse:

expected `&str`, found `String`

format!("...", ...) produces a String. Dioxus attributes want &str. The same Box::leak pattern solved this too:

let slot_class: &'static str = Box::leak(
    format!("{} {}", ctx.variant.to_slot_class(), props.class).into_boxed_str()
);

Episode 5: The Inter-Group Focus Traversal Collision

Here is a fun brain teaser: what happens when you put two OTP components on the exact same page, and you start typing in the second one?
Well, since our slots were originally assigned hardcoded IDs like otp-slot-0, otp-slot-1, the moment you typed a character in the second instance, document.getElementById("otp-slot-1") would aggressively hijack focus and yank your cursor all the way back up to the first OTP component on the page.

The fix? Prefixing every slot ID with a unique instance_id minted from a global atomic counter (OTP_INSTANCE_COUNTER.fetch_add(1, Ordering::Relaxed)). Now every widget lives in its own perfectly scoped focus namespace, free from neighborhood turf wars.

Episode 6: The "Sticky" Backspace (vDOM vs Physical DOM)

Across Leptos and Yew we noticed a bizarre issue: if you typed a character, erased it, and tried typing again, the <input> would refuse to update. Or if you filled the very last slot, the input component became "sticky" and refused to overwrite the final character.

The root cause was a classic Virtual DOM vs Physical DOM standoff. We were setting the internal state to "", but frameworks optimize their renders. Leptos input-rs used a one-way, read-once initialization for value=handle.0.get(). Yew assumed the string was already empty and ignored the reconciliation. Because the physical HTML <input> wasn't being forcefully synchronized, the raw DOM held onto the sticky character and choked out any new keystrokes.

We had to bypass the frameworks entirely and manually flush the physical DOM element inside the keyboard event handlers using raw Web APIs (input_ref.cast::<web_sys::HtmlInputElement>().unwrap().set_value("")). The lesson here? Sometimes the fastest way out of a reactive state desync is a direct, imperative smash to the physical DOM.

Keyboard Navigation

One of the more satisfying pieces: full keyboard navigation across slots.

Any character key → fills current slot, auto-advances focus to the next
Backspace → clears current slot; if already empty, goes to the previous slot
ArrowLeft → jumps to previous slot
ArrowRight → jumps to next slot
Tab → advances naturally (browser default, we don't intercept)

All of this is handled in the on_slot_keydown callback in the parent Otp component, which uses NodeRef (Yew) or the equivalent signal-based refs (Dioxus/Leptos) to imperatively .focus() the target input.

if key == "Backspace" && idx > 0 {
    // slot is already empty, go back
    if let Some(node) = slot_refs.get(idx - 1) {
        if let Some(input) = node.cast::<HtmlInputElement>() {
            let _ = input.focus();
        }
    }
}

No third-party focus-trap libraries. No jQuery. Pure DOM manipulation from Rust.

HOTP and TOTP Validation

OTP RS ships RFC 4226 (HOTP) and RFC 6238 (TOTP) implementations using totp-rs. The SHA-1 HMAC is hand-rolled using the standard iterative block compression algorithm:

pub fn validate_hotp(
    secret: &[u8],
    counter: u64,
    code: &str,
    digits: u32,
) -> Result<(), OtpValidationError> {
    let expected = hotp(secret, counter, digits);
    if expected == code { Ok(()) } else { Err(OtpValidationError::HotpMismatch) }
}

You can validate on complete:

let on_complete = Callback::from(move |code: String| {
    match validate_hotp(b"your-secret", 0, &code, 6) {
        Ok(()) => web_sys::console::log_1(&"Valid!".into()),
        Err(e) => web_sys::console::warn_1(&format!("{e:?}").into()),
    }
});

The hotp() function also lets you generate the expected code if you need to display a hint in development. For the HOTP example in the landing page, the valid code for secret JBSWY3DPEHPK3PXP at counter 0 is computed at runtime via hotp(b"JBSWY3DPEHPK3PXP", 0, 6), no hardcoding required.

Quick Setup

# Yew
cargo add otprs --features=yew

# Dioxus
cargo add otprs --features=dio

# Leptos
cargo add otprs --features=lep

# Cargo.toml
otprs = { version = "0.1", features = ["yew"] }

The component ships its own CSS as inline styles computed from Rust. No separate stylesheet needed.

Final Thoughts

Building OTP RS was a journey through the exact kind of subtle, cross-framework, cross-layer complexity that makes Rust Web development both rewarding and sometimes deeply frustrating. We fought the compiler more than once, discovered ways that browser defaults quietly break invisible design patterns, and shipped a Box::leak we're not entirely proud of.

But the result is solid: a composable, keyboard-navigable, RFC-compliant OTP input component that works identically across Yew, Dioxus, and Leptos, with zero JavaScript and enough ARIA to satisfy a WCAG auditor.

The next time you're building a login flow in Rust WASM and you reach for a six-box code input, you don't have to write it from scratch anymore.

opensass / otprs

🔐 A highly customizable OTP component for WASM frameworks (Powered by Input RS).

🔐 OTP RS

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible OTP (One-Time Password) input component for WASM frameworks: Yew, Dioxus, and Leptos.

Supports animated per-slot digit entry with automatic focus traversal, primary and secondary visual variants, built-in HOTP/TOTP validation per RFC 4226 and RFC 6238, and full WCAG compliance.

🤔 Why OTP RS?

🎨 Fully Customizable: Control every attribute, class, style, variant, pattern, ARIA labels and more, on the outermost container, each group, each slot, and each separator.
⌨ Smart Focus Management: Typing a digit automatically advances focus. Backspace regresses focus. Arrow keys navigate left and right.
✨ Animated Entry: Each digit pops with a scale animation when entered, and a blinking caret is shown in the active empty slot.
🔐 Built-in Validation: Validate against HOTP (RFC 4226) or TOTP (RFC 6238) using a pure-Rust implementation, no C, no…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

📋 Form RS: Production-Ready Form Components for WASM Frameworks

Mahmoud 🦀 — Sun, 04 Oct 2026 11:24:25 +0000

Salut 👋!

If there's one thing that unites frontend developers across every language, framework, and decade of web history, it's a deep, personal, somewhat traumatic relationship with HTML forms.

You know the drill. You write a <form>. You add an <input>. You add a <label>. You write the JavaScript to validate it on blur. You add a <p> for the error message. You wire up aria-describedby so screen readers can find the error. You set aria-invalid on the input. You set aria-required. You check event.preventDefault(). You realize you've been writing a custom form library for the last four hours. You consider leaving the industry.

That stops today. We're shipping Form RS.

What Is Form RS?

Form RS is a fully composable, WCAG 2.2 AA compliant, production-ready form component library for Yew, Dioxus, and Leptos. It wraps Input RS for the actual <input> rendering, provides a complete context-driven architecture for validation state propagation, and ships seven discrete components that you can mix freely.

Think of it as the form library you would build yourself if you had time, patience, and hadn't already burned both writing <div class="form-group"> for the 8000th time.

The Seven Components

Form RS ships a composable hierarchy, not a monolith.

`Form`

The outermost container. Wraps <form> with configurable method, action, enctype, autocomplete, ARIA labels, and submit/reset/invalid callbacks. There are two validation modes:

ValidationBehavior::Native   // HTML5 + browser popups (default)
ValidationBehavior::Aria     // Real-time ARIA errors, no popups, submit never blocked

`Control`

The context provider. Wraps a single field, distributes disabled, error, focused, required, variant, color, and size state to every child that reads FormControlContext. Your labels and helper text automatically inherit this state without prop drilling.

`Label`

Renders a <label> that visually and semantically tracks the control's state. It goes red when there's an error. It glows when focused. It shows the required asterisk automatically. You don't have to think about any of this.

// In Yew:
<Label html_for="email" error={true} focused={false}>
    {"Email address"}
</Label>

`Helper`

A <p> element below the input. Changes color based on validation state:

<Helper error={true}>{"Not a valid email."}</Helper>
<Helper valid={true}>{"Looks great!"}</Helper>

Three states, zero class strings.

`Group`

Groups related checkboxes or radio buttons in a <fieldset>-adjacent <div>. The row prop flips the layout from column to horizontal. The aria_label wires up a role="group" for screen readers.

`ControlLabel`

Wraps a form control (checkbox, radio, switch) with its associated label text. Controls label placement (End, Start, Top, Bottom), required asterisks, and disabled styling.

<ControlLabel
    control={html! { <input type="checkbox" /> }}
    label={html! { <span>{"Email notifications"}</span> }}
    label_placement={LabelPlacement::End}
/>

`Field`

This is the one you'll use most. A drop-in composition of Control + Label + Input + Helper with reactive focus rings, error/valid ring states, ARIA attributes, and helper text management.

<Field
    id="email"
    label="Email address"
    r#type="email"
    placeholder="ferris@opensass.org"
    helper_text="Enter a valid email."
    required=true
    full_width=true
    handle={email.clone()}
    valid_handle={email_valid.clone()}
    validate_function={Callback::from(validate_email)}
/>

One component. Fully wired. WCAG compliant. You're done.

Validation Architecture

Form RS supports two distinct validation paradigms:

Native HTML5 Validation

Uses browser-native required, pattern, minlength, maxlength, and type="email" constraints. The browser handles error messages. Form submission is blocked on invalid fields. This is the ValidationBehavior::Native default.

External/ARIA Validation

Pass a ValidationState explicitly, from a server response, a complex cross-field rule, or your own logic:

ValidationState::None        // No judgment, untouched
ValidationState::Valid       // Green ring, success helper text
ValidationState::Invalid(msg)// Red ring, error helper text, aria-invalid="true"

Server errors? Set validation_state={ValidationState::Invalid("Email already in use.".into())} on the field. The error surfaces immediately. The ARIA is correct. Done.

Accessibility Built In

This isn't "we added aria-label" accessibility. This is the real thing.

Every Field generates a unique {id}-helper element ID and passes it as aria-describedby on the underlying <input>.
aria-required and aria-invalid are set precisely based on prop + validation state, not just "always true".
Helper renders with role="alert" when in error state, so screen reader users hear errors without tabbing to them.
Label is always linked to its input via for/html_for. No floating labels that break semantics.
Group propagates role="group" with aria-label for checkbox/radio clusters.

Audit-passing HTML forms. In Rust. Across three WASM frameworks.

The `ValidationState` Pattern

This is the piece that makes server-side validation ergonomic:

pub enum ValidationState {
    None,
    Valid,
    Invalid(String),
}

Pass None on a fresh field. Pass Valid once you've confirmed on the backend. Pass Invalid with your error message string when the server rejects it. The component does the rest.

Variant, Color, and Size System

Form RS exposes a full semantic token system for the input appearance:

// Visual input style
Variant::Outlined  // Default, bordered input box
Variant::Filled    // Solid filled background
Variant::Standard  // Bottom-border only

// Accent color (rings, labels, helper text)
Color::Primary | Color::Secondary | Color::Error | Color::Info | Color::Success | Color::Warning

// Input density
Size::Small | Size::Medium

Building a dense admin data-entry form? Size::Small. Consumer onboarding flow? Size::Medium. Dark theme with error highlights? Color::Error. The system handles the visual output; you just name the intent.

Quick Setup

Stop writing raw HTML form boilerplate. Do this:

# Yew
cargo add form-rs --features=yew

# Dioxus
cargo add form-rs --features=dio

# Leptos
cargo add form-rs --features=lep

Final Thoughts

Forms are foundational. Every user interaction that matters, login, registration, checkout, profile editing, contact, search, flows through a form. Getting them right means getting ARIA right, validation right, focus state right, and error surfacing right. Every time. On every field.

Form RS is the answer to "who has time for all of that." We did. You don't have to.

opensass / form-rs

📋 A highly customizable Form component for WASM frameworks (Powered by Input RS).

📋 Form RS

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible form component library for WASM frameworks: Yew, Dioxus, and Leptos. Supports HTML5 and ARIA validation, composable sub-components (Form, Control, FormLabel, Helper, Group, ControlLabel, Field), and full WCAG 2.2 AA compliance.

🤔 Why Form RS?

🎨 Fully Customizable: Control variant, color, size, class, style, ARIA labels, and every sub-component attribute.
🧩 Composable API: Mix Form, Control, FormLabel, Helper, Group, ControlLabel, and Field independently or together.
✅ Dual Validation: Supports native HTML5 validation and real-time ARIA error messaging.
♿ Accessible by Default: aria-describedby, aria-required, aria-invalid, and role="alert" wired up automatically.
🔧 Framework Agnostic: Same API semantics across Yew, Dioxus, and Leptos.

Y Yew Usage

Refer to our guide to integrate this component into…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

🖥️ Code RS: CDN-Free Syntax-Highlighted Code Components for WASM

Mahmoud 🦀 — Sun, 04 Oct 2026 11:24:17 +0000

Privyet 👋!

You know that moment when you paste a <pre><code> block into your app and it looks like it was styled in 2003 by someone who had just discovered color: green? No theme. No copy button. No language badge. Just raw, uncolored text sitting in a box that someone called "good enough"?

Yeah. We fixed that. Today we're shipping Code RS.

What Is Code RS?

Code RS is a production-ready, fully-themed, accessible code display component for Yew, Dioxus, and Leptos. It does everything the ecosystem was missing:

Inline <Code>: colored, sized, variant-aware, with ARIA semantics.
<Block>: a composable container with header, title, language badge, copy trigger, and scrollable content area.
Pure-Rust syntax highlighting: zero CDN, zero JavaScript, compiles to clean WASM, 20+ languages.
8 built-in themes: OneDark, Dracula, NightOwl, GitHub Dark/Light, Solarized, Monokai, Nord, all switchable via a single theme prop.

No Prism.js. No highlight.js. No 10MB script tag loaded from a CDN you definitely trust completely. Just Rust, bytes, and inline style= spans.

The Big Idea

Here's the thing about syntax highlighting in WASM apps: every existing solution assumes JavaScript. Prism.js needs a DOM. highlight.js needs a runtime. Shiki needs Node. Tree-sitter is great, but it weighs as much as a sedan.

So we wrote our own.

The highlight_code(code, lang, theme) function in common.rs is a hand-rolled, char-by-char tokenizer that handles:

Block comments (/* */), single-line comments (//, #, --)
Double/single-quoted strings and JS template literals
Hex and float number literals with suffixes (0xFF, 1.0f32)
Rust macros (println!, vec!)
Python/CSS decorators (@dataclass, @media)
HTML tag names (<div>, </span>)
PascalCase → type, ALL_CAPS → constant, ident( → function call
Language-specific keyword sets (Rust, Python, TypeScript, SQL, Bash, 16 more)

All token spans get inline style= attributes from the chosen theme. No CSS classes. No external stylesheet. Just <span style="color:#c678dd;font-weight:600">fn</span>, and it works everywhere, including iframes and shadow DOM.

use coders::{Language, Theme, highlight_code};

let html = highlight_code(
    "fn main() {\n    println!(\"Hello!\");\n}",
    Language::Rust,
    Theme::Dracula,
);
// → "<span style="color:#ff79c6;font-weight:600">fn</span> ..."

Components

`Code`

The simplest unit. A <code> element with color, variant, and size props.

// Yew
html! {
    <Code color={Color::Accent} variant={Variant::Subtle} size={Size::Sm}>
        {"console.log(\"Hello, world!\")"}
    </Code>
}

Variants work exactly as you'd expect from the rest of Open SASS Kit: Solid, Subtle, Outline, Surface, Plain. Colors are the full palette: Default, Red, Orange, Yellow, Green, Teal, Accent, Pink, Success, Warning, Danger, and Custom("your-inline-css").

`Block`

// Leptos
view! {
    <Block
        code="fn main() {\n    println!(\"Hello!\");\n}"
        language={Language::Rust}
        theme={Theme::NightOwl}
    >
        <Header>
            <Title>"main.rs"</Title>
            <LanguageBadge />
            <CopyTrigger />
        </Header>
        <Content />
    </Block>
}

The Block pushes a BlockContext containing code, language, and theme into a provider tree. All child components read from context. Content calls highlight_code and injects the result via inner_html / dangerous_inner_html / Html::from_html_unchecked, the framework-appropriate unsafe-but-correct escape hatch for pre-rendered HTML. No prop drilling. No callback chains. Just context.

8 Themes

Theme	Background	Vibe
`OneDark`	`#1a1a2e`	The classic. Atom's gift to the world.
`Dracula`	`#282a36`	Halloween every day. Pink keywords.
`NightOwl`	`#011627`	Deep blue, warm salmon numbers.
`GithubDark`	`#0d1117`	Feels like GitHub, because it is.
`GithubLight`	`#ffffff`	For those who dare use light mode.
`Solarized`	`#002b36`	Ethan Schoonover's gift to the terminal.
`Monokai`	`#272822`	The Sublime Text nostalgia trip.
`Nord`	`#2e3440`	Arctic. Clean. Borderline peaceful.

Switch themes at runtime by simply changing the theme prop. The ThemeColors struct drives inline style generation, every push_span() call pulls the exact CSS value from the active theme's fields.

Need your brand colors? Theme::Custom(ThemeColors { keyword: "color:#ff0099;font-weight:600", ... }) and you're done.

The Build Journey

We are not going to pretend this was a relaxing weekend project. Here is an honest accounting.

Chapter 1: The Rust 2024 Edition

Rust Edition 2024 changed how string-like identifiers in macro positions are parsed. The yew::html! macro started rejecting class names like text-black and whitespace-pre, specifically the hyphen-adjacent tokens that look like prefix expressions.

The error: prefix 'black' is unknown. The fix: add a trailing space after the class name. Simple, but it wasted an embarrassing amount of time because the error message looks nothing like what it actually is.

// Before (breaks in Edition 2024):
class="flex text-black"
// After:
class="flex text-black "  // ← single space, problem solved

Chapter 2: Dioxus RSX

The rsx! macro in Dioxus parses string prop values as format strings. So this:

code: "fn main() {\n    println!(\"Hello!\");\n}"

Explodes with Failed to parse formatted segment: Expected Ident or Exp. Because { inside a string prop is format syntax to Dioxus, not a literal curly brace.

The fix: extract all code strings to const:

const HELLO_WORLD: &str = "fn main() {\n    println!(\"Hello!\");\n}";

rsx! {
    Block { code: HELLO_WORLD }
}

Unglamorous? Yes. But it compiles.

Chapter 3: The `dangerous_inner_html`

In Dioxus, dangerous_inner_html takes ownership of a String. In Leptos, inner_html takes a &str. In Yew, Html::from_html_unchecked takes an AttrValue. Three frameworks, three signatures, three slightly different ways to inject a pre-rendered HTML string.

Each one worked fine once you knew the exact type expected. Getting there required reading the framework source, not the docs, because the docs had helpfully omitted the borrow semantics.

Chapter 4: Non-Exhaustive `Variant::Custom`

Adding Custom(&'static str) to the Variant enum immediately broke every match in all three Code component implementations. Expected. Annoying. The fix is the following:

Variant::Custom(_) => "",

But finding all three match sites across three files while also trying to fix four other things simultaneously is exactly the kind of thing that makes you wish Rust had #[non_exhaustive] as an opt-in marker you could flip during development.

Accessibility

Code RS ships accessible markup out of the box:

Block renders as <figure role="region"> with aria-label.
The inner <pre> gets tabindex="0" so keyboard users can scroll it.
CopyTrigger carries aria-label="Copy code to clipboard" and aria-live region feedback via the copied label swap.
Code accepts aria_label for use in contexts where <code> alone doesn't carry enough meaning.
LanguageBadge reads the language from context and renders aria-label="Language: rust".

Screen readers don't need to guess what anything is.

Quick Setup

# Yew
cargo add coders --features=yew

# Dioxus
cargo add coders --features=dio

# Leptos
cargo add coders --features=lep

That's it. The syntax highlighting, theming, clipboard, and accessibility, all included. No config files. No CSS imports. No npm install @something/highlighter-peer-dependency.

Final Thoughts

Writing a CDN-free, pure-WASM syntax highlighter from scratch to ship alongside a composable code block component is not the most efficient path. But it's the correct one for this ecosystem.

The web has enough <script src="https://cdn.example.com/dep.min.js"> tags. Rust WASM doesn't need to inherit that habit.

Code RS compiles to WASM, highlights code inline, and ships 8 themes without a single network request beyond your app bundle. That's the promise.

opensass / coders

💻 A highly customizable code component for WASM frameworks.

💻 Code RS

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible inline code and code-block component for WASM frameworks: Yew, Dioxus, and Leptos. Supports multiple colors, variants, sizes, copy-to-clipboard, and composable sub-components, all WCAG compliant.

🤔 Why Code RS?

🎨 Fully Customizable: Control every attribute, class, style, color, variant, size, ARIA labels, and more.
📋 Copy to Clipboard: Built-in copy button with a configurable confirmation label and reset timeout.
🧩 Composable: Compose Header, Title, CopyTrigger, Content, and LanguageBadge independently.
♿ Accessible by Default: role="region", aria-label, aria-live and tabindex wired up automatically.
🔧 Framework Agnostic: Same API semantics across Yew, Dioxus, and Leptos.

Y Yew Usage

Refer to our guide to integrate this component into your Yew app.

🧬 Dioxus Usage

Refer to our guide to integrate this component into your Dioxus app.

🌱

…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

🃏 Card RS: Extremely Customizable Card component for WASM frameworks

Mahmoud 🦀 — Sun, 27 Sep 2026 11:11:08 +0000

Salut tout le monde 👋!

If there is one layout component that has been re-implemented more times than the <button>, it's the Card. Think about it. Every widget, every dashboard panel, every pricing tier, every shiny glowing glassmorphism element you've ever seen is, deep down, a card.

Instead of writing div class="p-6 border rounded-xl shadow-lg bg-white" for the 5000th time, we decided to solve cards natively for WASM.

Today, we're shipping Card RS.

What Is Card RS?

Card RS is an extremely customizable, production-ready, accessible Card component for Yew, Dioxus, and Leptos. We've extracted all the tedious BEM boilerplate, flexbox wrangling, and ARIA attributes out of your templates, giving you a clean, composable API for building solid UI surfaces.

Cards shouldn't be monoliths. If you just need a surface, <Card> works perfectly alone. If you need standard anatomical parts, stick <Header>, <Title>, <Content>, and <Footer> in there.

The Composable Anatomy

The problem with most UI library cards is that they force you into a specific layout. Card RS doesn't mandate structure; it provides logical boundaries.

The Shell: `Card`

The parent wrapper. It renders a clean HTML5 <article> (or whatever ARIA role you need) with our default elevated styling.

use card_rs::yew::Card;
use card_rs::Variant;
use yew::prelude::*;

#[function_component(MyWidget)]
pub fn widget() -> Html {
    html! {
        <Card variant={Variant::Default} aria_labelledby="widget-title">
            // the world is yours in here
        </Card>
    }
}

The Skeleton: Headers, Content, & Footers

Don't want to write inline styles for gaps and flex-columns? Neither do we.

<Card aria_labelledby="c-title">
    <Header>
        <Title id="c-title">{"Card Title"}</Title>
        <Description>{"The description lives here."}</Description>
    </Header>
    <Content>
        <p>{"Any content fits neatly in the main body area."}</p>
    </Content>
    <Footer>
        <button aria-label="Confirm">{"Confirm"}</button>
    </Footer>
</Card>

The header stacks title and description with precise spacing. The footer handles your action bars. Everything just snaps into place like LEGOs.

Variants and Prominence

Not all cards are created equal. You need visual hierarchy. We provide a Variant matrix that affects the surface depth and contrast without rewriting class strings.

pub enum Variant {
    Transparent,  // No background, merges with the canvas
    Default,      // Standard surface layer
    Secondary,    // Elevated and highlighted
    Tertiary,     // Premium prominence (perfect for selected items)
}

Building an interactive pricing selector? Wrap your iterations in a <Card variant={if selected { Variant::Secondary } else { Variant::Default }}> and your hierarchy logic is done.

Framework Parity

Like everything we build, Card RS provides identical API surfaces and behavioral guarantees across all three rusty frontends:

Feature	Yew	Dioxus	Leptos
`Card`	✅	✅	✅
`Header`	✅	✅	✅
`Title` & `Description`	✅	✅	✅
`Content` & `Footer`	✅	✅	✅
Variant Matrix	✅	✅	✅
Accessible ARIA bindings	✅	✅	✅
Role overrides	✅	✅	✅

If you know how to build a card in Leptos, you can build a card in Dioxus. The props are the same. The BEM classes are the same. The logic is identical.

Accessibility Built-In

Accessible surfaces are often completely ignored by developers until an audit fails. Card RS is designed strictly around WCAG guidelines.

Card renders with role="article" by default.
We enforce aria_labelledby to tie structural landmarks to the Title ID.
If you want a non-interactive surface, just override it with role="note" or role="region".

// Accessible structural linking:
<Card aria_labelledby="promo-heading" role="region">
    <Header>
        <Title id="promo-heading">{"Special Offer!"}</Title>
    </Header>
</Card>

With one prop, screen readers will now announce "Region: Special Offer!" properly.

Customization

We aren't trapping you in our aesthetic. Want a weird horizontally-aligned flex-row card with a gradient background? Just use the style prop. Card RS accepts your CSS strings eagerly.

Quick Setup

Stop copying and pasting giant Tailwind HTML blobs. Do this instead:

# Yew
cargo add card-rs --features=yew

# Dioxus
cargo add card-rs --features=dio

# Leptos
cargo add card-rs --features=lep

Final Thoughts

The web is made of cards. Taking the time to unify how we create, structure, and render them across Wasm frameworks means we can stop fighting with padding and flexbox alignment, and get back to building real features.

opensass / card-rs

🃏 A highly customizable card component for WASM frameworks

🃏 Card RS

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible card component for WASM frameworks: Yew, Dioxus, and Leptos. Supports semantic prominence variants, composable sub-components (header, title, description, content, footer), and full WCAG compliance.

🤔 Why Card RS?

🎨 Fully Customizable: Control variant, class, style, ARIA labels, and every sub-component attribute.
🧩 Composable API: Use Card, Header, Title, Description, Content, and Footer independently or together.
🏷️ Semantic Variants: transparent, default, secondary, tertiary, themes interpret prominence without hard-coded colors.
♿ Accessible by Default: role="article", aria-labelledby, and aria-label wired up automatically.
🔧 Framework Agnostic: Same API semantics across Yew, Dioxus, and Leptos.

Y Yew Usage

Refer to our guide to integrate this component into your Yew app.

🧬 Dioxus Usage

Refer to our guide to integrate this component into…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

🔴 Badge RS: Easy to Use Badge Components for WASM Frameworks

Mahmoud 🦀 — Sun, 27 Sep 2026 11:08:44 +0000

Je vous salue 👋!

Every WASM app eventually needs a badge. The little red circle on your notification bell. The green dot on the corner of an avatar. The "99+" that taunts you every morning from the inbox icon. They're everywhere, and somehow everyone is still hand-rolling them.

That stops today. We're shipping Badge RS.

What Is Badge RS?

Badge RS is a production-ready badge component for Yew, Dioxus, and Leptos. Notification counters, status dots, overflow labels, the whole catalogue. It handles positioning, sizing, color theming, dot mode, accessible markup, and even knows the difference between a circle and a rectangle.

If you've ever opened your browser devtools at 11pm trying to figure out why a badge is floating 4px off the corner of an avatar instead of sitting flush on the arc, Badge RS is the component you wish had existed.

The Core Components

`Anchor`

The positioning wrapper. Drop it around any element and it becomes a badge target. Uses position: relative; display: inline-flex; so it doesn't break your layout, doesn't eat your accessibility tree, and doesn't require you to memorize any CSS tricks.

use badges_rs::yew::{Badge, Anchor};
use badges_rs::{Color, Shape};
use yew::prelude::*;

#[function_component(NotificationBell)]
pub fn notification_bell() -> Html {
    html! {
        <Anchor>
            <span aria-label="Inbox, 5 unread messages">{"📬"}</span>
            <Badge
                color={Color::Danger}
                shape={Shape::Circle}
                aria_label="5 unread messages"
            >
                {"5"}
            </Badge>
        </Anchor>
    }
}

That's it. The badge positions itself. You decide where.

`Badge`

The actual indicator. Pass children and you get a labeled badge with text inside. Skip children and you get a compact do, no extra prop needed, just don't put anything inside.

// A labeled count badge
<Badge color={Color::Danger} size={Size::Sm} aria_label="5 unread">{"5"}</Badge>

// A status dot, no children, no extra prop
<Badge color={Color::Success} placement={Placement::BottomRight} aria_label="Online" />

Same component, two modes. The dot is not a separate component.

`BadgeLabel`

A thin <span class="badge__label"> wrapper. Used automatically when you pass plain text to Badge. Expose it directly when you need extra CSS classes or styling on the label slot.

Colors, Variants, Sizes

The full set of knobs is available:

// Colors
Color::Default | Color::Accent | Color::Success | Color::Warning | Color::Danger

// Variants (three visual styles)
Variant::Primary    // solid fill
Variant::Secondary  // outlined
Variant::Soft       // muted, lower-contrast

// Sizes
Size::Sm | Size::Md | Size::Lg

// Placement
Placement::TopRight | Placement::TopLeft | Placement::BottomRight | Placement::BottomLeft

All combinations work. TopLeft is there for RTL layouts and anyone who likes to be contrarian about badge placement.

The Positioning Bug Nobody Talks About

Here's the subtle one. top: 0; right: 0 with transform: translate(50%, -50%) centers a badge perfectly on the corner of a rectangle. That's fine for icon buttons, list items, or anything with a square bounding box.

For a circle, which is what every avatar in existence is, the story is different. A circle's actual edge at 45° sits inward from the bounding box corner. The geometric offset is exactly 1 - sin(45°), which works out to roughly 14.64% of the element's width and height.

Most badge implementations ignore this. The badge floats slightly off the arc, nobody files a bug, and the designer quietly seethes.

Badge RS exposes a Shape enum to handle this explicitly:

pub enum Shape {
    Rectangle,  // top: 0; right: 0, standard bounding box corner
    Circle,     // top: 14.64%; right: 14.64%, sits on the arc
}

// On a circular avatar, badge sits flush on the arc:
<Badge color={Color::Danger} shape={Shape::Circle} aria_label="3">{"3"}</Badge>

// On a square icon button, badge sits on the bounding box corner:
<Badge color={Color::Accent} shape={Shape::Rectangle} aria_label="New">{"New"}</Badge>

The math is not magic. It's just trigonometry that nobody wanted to look up at 11pm. We looked it up for you.

Framework Parity

All three frameworks ship the same API surface:

Feature	Yew	Dioxus	Leptos
`Anchor`	✅	✅	✅
`Badge`	✅	✅	✅
`BadgeLabel`	✅	✅	✅
`Shape::Circle` offset	✅	✅	✅
Dot mode (no children)	✅	✅	✅
All placements	✅	✅	✅
All variants	✅	✅	✅
ARIA attributes	✅	✅	✅

If you've used it in Yew, you already know how to use it in Dioxus and Leptos. The prop names don't even change.

Accessibility

Accessible badges are an afterthought in most libraries. In Badge RS they're mandatory.

Badge renders with role="status" and a required aria_label. Screen readers announce the content without the user having to navigate to it.
aria-atomic="true" ensures the full label is re-read when the count updates. A badge that goes from "3" to "4" reads "4 unread messages", not just "4".
Anchor renders as a <span> with no ARIA role, because it's structural glue and should be invisible to assistive technology.
The WCAG guidance on badges is straightforward: label the element that owns the badge, not just the badge itself. We mention this in the docs and the examples follow it throughout.

// The accessible way, the host element's label includes the count
<span aria-label="Inbox, 5 unread messages">{"📬"}</span>
<Badge aria_label="5 unread messages">{"5"}</Badge>

The badge label and the host's aria-label should tell the same story from different angles.

Quick Setup

# Yew
cargo add badges-rs --features=yew

# Dioxus
cargo add badges-rs --features=dio

# Leptos
cargo add badges-rs --features=lep

No CSS framework required. Styles are computed inline from the prop values.

Dot Mode vs Count Mode

One component, two modes, no separate component for each. This matters because it keeps your import surface small and your mental model consistent.

// Count mode, children present
<Badge color={Color::Danger} aria_label="5 messages">{"5"}</Badge>

// Dot mode, no children, badge renders as a small filled circle
<Badge color={Color::Success} placement={Placement::BottomRight} aria_label="Online" />

The dot is a first-class mode with its own size calculations. Size::Sm in dot mode renders a 6×6px dot. In count mode, it renders a 16×16px pill. The size label refers to the visual weight, not a fixed pixel value.

Status Indicators

The placement prop combined with dot mode covers the most common avatar status pattern:

use badges_rs::leptos::{Badge, Anchor};
use badges_rs::{Color, Placement, Shape};
use leptos::prelude::*;

#[component]
pub fn UserAvatar() -> impl IntoView {
    view! {
        <Anchor>
            <span
                style="/* your avatar CSS */"
                aria-label="Jane Doe, online"
            >
                "JD"
            </span>
            <Badge
                color=Color::Success
                shape=Shape::Circle
                placement=Placement::BottomRight
                aria_label="Online"
            />
        </Anchor>
    }
}

Green dot, bottom-right, perfectly on the arc. That's the whole pattern.

What We Didn't Do

No magic threshold that auto-truncates to "99+". That's application logic, not component logic. We show whatever you pass in. If you want count.min(99).to_string() or "99+", that's two lines in your own code.

No auto-detection of the parent element's shape. That would require measuring the DOM at runtime, which is expensive. Instead: explicit shape prop. You know your own design system. Tell us.

No CSS injection. No global stylesheet to import. No BEM class naming conventions to memorize. The styles live on the element.

Final Thoughts

Badge RS is compact by design. Three components, one enum, one positioning decision that most libraries get wrong.

The Shape prop is the detail worth remembering. If you're putting badges on circular avatars and they look slightly off, that's the fix. Try Shape::Circle and stop adjusting pixel offsets in your component stylesheets.

opensass / badges-rs

🏷️ A highly customizable badge component for WASM frameworks.

🏷️ Badges RS

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible badge component for WASM frameworks: Yew, Dioxus, and Leptos. Supports notification counts, status dots, labels, multiple colors, variants, sizes, and placements with full WCAG compliance.

🤔 Why Badges RS?

🎨 Fully Customizable: Control color, variant, size, placement, class, style, and ARIA labels.
🔴 Dot Mode: When no children are provided the badge renders as a compact status dot.
📍 Smart Placement: Four corner placements (top-right, top-left, bottom-right, bottom-left) via CSS transform for pixel-perfect positioning.
♿ Accessible by Default: role="status", aria-label, and aria-atomic wired up automatically.
🧩 Framework Agnostic: Same API semantics across Yew, Dioxus, and Leptos.

Y Yew Usage

Refer to our guide to integrate this component into your Yew app.

🧬 Dioxus Usage

Refer to our guide to integrate this…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

🪪 Avatar RS: Very Efficient Avatar Components for WASM Frameworks

Mahmoud 🦀 — Sun, 27 Sep 2026 11:01:40 +0000

Bien le bonjour 👋!

Every WASM app eventually needs an avatar. Profile pictures, user cards, comment threads, they're everywhere. And every time, developers end up rolling the same <img> tag with some fallback logic, hardcoded border-radius, and a prayer that the CDN doesn't return a 404.

That stops today. We're shipping Avatar RS.

What Is Avatar RS?

Avatar RS is a fully-featured avatar component for Yew, Dioxus, and Leptos. It handles image loading, fallback text/icons, overflow groups, color themes, size variants, accessible markup, the whole thing. Built on top of Image RS, which means you get smart lazy loading, blur-up placeholders, and responsive layouts for free.

Think of it as the avatar component you'd build if you had infinite time and zero deadlines. We had neither, but here we are anyway.

The Stack Under the Hood

Avatar RS wraps Image RS, our WASM-native image primitive, for the actual <img> element. This is not a trivial detail.

Image RS uses Intersection Observer API for lazy loading, supports srcset/sizes for responsive images, and fires clean on_load / on_error callbacks. All of that comes for free inside every Image you render. The avatar layer only adds context management and state coordination on top.

Core Components

`Avatar`

The container. Wraps Image and Fallback, provides the shared loading context, and inherits size/color/variant from a surrounding Group if present.

use avatar::yew::{Avatar, Image, Fallback};
use avatar::Color;
use yew::prelude::*;

#[function_component(MyProfile)]
pub fn my_profile() -> Html {
    html! {
        <Avatar aria_label="Ferris Prophet">
            <Image
                src="https://i.pravatar.cc/300"
                alt="Ferris Prophet"
            />
            <Fallback color={Some(Color::Accent)}>{"JD"}</Fallback>
        </Avatar>
    }
}

The fallback shows while the image loads, hides once it lands.

`Fallback`

Text initials, an icon, or anything you want rendered when the image hasn't loaded yet (or doesn't exist at all). Supports a delay_ms prop to intentionally delay reveal, useful when your image usually loads fast and you don't want the fallback to flash briefly then disappear.

// Fallback shows immediately:
<Fallback color={Some(Color::Success)}>{"MH"}</Fallback>

// Fallback waits 200ms before appearing (prevents flicker on fast connections):
<Fallback delay_ms={200} color={Some(Color::Accent)}>{"JD"}</Fallback>

Small prop, big UX difference.

`Group`

Stack multiple avatars with automatic overlap, configurable max count, and an overflow badge showing how many more there are.

use avatar::yew::{Avatar, Group, Count, Image, Fallback};
use avatar::{Color, Size, Variant};
use yew::prelude::*;

#[function_component(TeamStack)]
pub fn team_stack() -> Html {
    html! {
        <Group
            size={Size::Lg}
            max={Some(3)}
            total={Some(6)}
            aria_label="Project team"
        >
            <Avatar aria_label="Member 1">
                <Image src="https://i.pravatar.cc/150?u=m1" alt="Member 1" />
                <Fallback color={Some(Color::Accent)}>{"M1"}</Fallback>
            </Avatar>
            <Avatar aria_label="Member 2">
                <Image src="https://i.pravatar.cc/150?u=m2" alt="Member 2" />
                <Fallback color={Some(Color::Success)}>{"M2"}</Fallback>
            </Avatar>
            <Avatar aria_label="Member 3">
                <Image src="https://i.pravatar.cc/150?u=m3" alt="Member 3" />
                <Fallback color={Some(Color::Warning)}>{"M3"}</Fallback>
            </Avatar>
            <Count
                color={Some(Color::Danger)}
                variant={Some(Variant::Soft)}
                aria_label="3 more members"
            />
        </Group>
    }
}

Pass max={Some(3)} and total={Some(6)}, and Count automatically shows +3. The math is done for you. The CSS overlap is done for you. You just write components.

The `overflow_count` Context

This is the part that required actual thought.

Group computes overflow_count = total - max and pushes it into context. Count reads it from context when its own count prop is zero (the default). This means the badge doesn't need to know anything explicit, it just reads the group state.

// In Group:
let overflow_count = total.saturating_sub(max);
ctx_provider.provide(&GroupContext { overflow_count, .. });

// In Count:
let effective_count = if count == 0 { ctx_overflow } else { count };
// Renders: "+{effective_count}"

One source of truth.

Framework Parity

All three frameworks ship the same API surface:

Feature	Yew	Dioxus	Leptos
`Avatar`	✅	✅	✅
`Image`	✅	✅	✅
`Fallback`	✅	✅	✅
`Group`	✅	✅	✅
`Count`	✅	✅	✅
`total` + `max` overflow	✅	✅	✅
Context propagation	✅	✅	✅
`delay_ms` on fallback	✅	✅	✅
Image RS integration	✅	✅	✅

The Dioxus and Leptos implementation uses use_context_provider / use_context idioms native to each framework, but the behavior is identical. If you've used it in Yew, you already know how to use it in Leptos.

Soft Refresh & The Browser Cache Fix

Here's one that caught us off guard. In Yew, images rendered via Image would sometimes fail to appear after a soft page refresh. Hard refresh? Fine. Soft? Gone.

The culprit: when a browser serves an image from cache, the load event fires before Yew has had a chance to attach the listener. The effect sees a "loading" state, the image is already done, and the component never flips to "loaded".

The fix was straightforward once we knew what to look for. We inject a node_ref into the underlying <img> element and check img.complete on mount:

use_effect_with(props.src, move |src| {
    if !src.is_empty() {
        let already_loaded = node_ref
            .cast::<web_sys::HtmlImageElement>()
            .map(|img| img.complete())
            .unwrap_or(false);

        if already_loaded {
            status.set(ImageLoadingStatus::Loaded);
        } else {
            status.set(ImageLoadingStatus::Loading);
        }
    }
    || ()
});

This required adding web-sys with the HtmlImageElement feature to the yew feature gate in Cargo.toml. A small addition, but it closes a genuinely annoying browser quirk.

Dioxus and Leptos did not have this issue, their reactive systems handle DOM updates differently and don't suffer from this ordering problem.

Colors, Variants, Sizes

Everything inherits downward through context. Set defaults at the group level, override them per-avatar if needed.

// Colors
Color::Default | Color::Accent | Color::Success | Color::Warning | Color::Danger | Color::Custom("...")

// Variants
Variant::Default  // solid fill
Variant::Soft     // muted, lower-contrast

// Sizes
Size::Xs | Size::Sm | Size::Md | Size::Lg | Size::Xl | Size::Xxl | Size::Custom("...")

Color::Custom("...") and Size::Custom("...") accept raw CSS strings, so if your design system uses hsl(270 60% 50%) or 3.5rem, those work too.

Quick Setup

# Yew
cargo add avatar --features=yew

# Dioxus
cargo add avatar --features=dio

# Leptos
cargo add avatar --features=lep

That's it. The styling is computed inline from the prop values.

Accessibility

Every component exposes its ARIA props explicitly:

Avatar renders role="img" with a required aria_label.
Image manages aria-hidden based on loading state.
Fallback is hidden from assistive tech once the image loads.
Group gets an aria_label for the whole group.
Count gets its own aria_label (defaults to "Additional members").

Screen readers get a consistent, clear picture regardless of whether images loaded or not.

What We Didn't Do

No auto-injection of count badges. No magic child-slicing that differs between frameworks. No runtime diffing of the children list to figure out how many to show. These patterns break in different ways across Yew, Dioxus, and Leptos, and they make the component harder to reason about.

Instead: explicit total and max props, explicit Count placement, one context object that everything reads from. It's a little more to type. It's a lot easier to debug.

Final Thoughts

Avatar RS is exactly what it says on the tin: a production-ready avatar component for WASM apps.

It's backed by Image RS, which means you get all the image loading sophistication without reinventing it. The overflow logic is explicit and predictable. Framework parity is real, not aspirational.

opensass / avatar

👦 A highly customizable avatar component for WASM frameworks (Powered by Image RS).

👦 Avatar

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible avatar component for WASM frameworks: Yew, Dioxus, and Leptos. Supports image loading with automatic fallback content, multiple sizes, color themes, and full WCAG compliance.

🤔 Why Avatar?

🎨 Fully Customizable: Control every attribute, class, style, size, color, variant, ARIA labels and more.
🖼️ Smart Image Loading: Tracks idle → loading → loaded/error status with context. Fallback is shown until the image is ready.
⏱ Delay Support: Prevent flash-of-fallback on fast connections with delay_ms.
♿ Accessible by Default: role="img", aria-label, aria-hidden wired up automatically.
🧩 Framework Agnostic: Same API semantics across Yew, Dioxus, and Leptos.

Y Yew Usage

Refer to our guide to integrate this component into your Yew app.

🧬 Dioxus Usage

Refer to our guide to integrate this component into your Dioxus app.

🌱 Leptos

…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

I Resurrected a Dead CRC Crate and It Suddenly Went Viral

Mahmoud 🦀 — Sun, 20 Sep 2026 09:11:49 +0000

Bonjour 👋!

So there I was, browsing crates.io at an hour that most reasonable people would describe as "the middle of the night", doing what all emotionally stable developers do at that hour: auditing dead Rust crates for signs of life.

That's when I found crc32.

Not crc32fast. Not crc. Not crc32c. The original. The stubby, ancient, crc32 crate. Last published in 2015. No changelog. No CI. A Cargo.toml that predates most of the stable Rust syntax I use daily. And sitting there, abandoned and unloved.

People were using this thing. Were probably shipping software with it in their dependency tree. They just didn't know how to reach the crate maintainer, who had apparently retired to a cabin in the woods with no internet access sometime around when Rust 1.0 was announced.

I stared at those download numbers for thirty seconds.

Then I did what any emotionally stable rustacean would do: I resurrected it. From the ashes. In modern Rust. With no_std. With Python bindings. With a build-time proc-macro codegen crate. With CI/CD, Debian packaging, RPM packaging, and a Ferris logo.

You know. Normal stuff.

Wait, What Even Is CRC-32?

CRC-32 stands for Cyclic Redundancy Check, 32-bit variant. It's the checksum algorithm that:

ZIP files use to verify archive integrity.
Ethernet frames use to detect bit errors in transmission.
FDDI, PKZIP, PNG and approximately half the binary protocols ever invented also use.
Every zlib function you've ever called calls internally when you weren't paying attention.

In other words, CRC-32 is everywhere. It's the duct tape of data integrity. It's been computing checksums since before most of today's developers were handing in their first homework assignments.

The original Rust crc32 crate implemented the byte-at-a-time version, the classic, the grandaddy variant. Simple. Correct. Slow as a 56k modem by 2024 standards.

I didn't just port it. I rewrote the whole thing from the zlib source, added slicing-by-4, slicing-by-8, and slicing-by-16 table variants, pulled the table-generation itself into a build-time proc-macro subcrate, added a streaming Digest, a GF(2) matrix combine function, and shipped the whole thing as a no_std library with Python and Node.js bindings.

All in 100% safe Rust. With #![forbid(unsafe_code)] at the crate root.

Because anything worth resurrecting is worth resurrecting properly.

The Architecture

Let me tell you what the original crc32 crate looked like. It was, essentially:

src/lib.rs
src/crc32gen.rs
src/crc32gen_file.rs

That's it. 3 files. A lookup table, a loop, a bitwise XOR. Beautiful in its simplicity, like a stone hut in a field. Functional. Zero frills. Absolutely not capable of 1 GiB/s throughput.

Here's what crc32-v2 looks like today:

crc32-v2/
├── crc32-codegen/             ← proc-macro subcrate: generates all 17 CRC tables at build time
│   └── src/lib.rs             ← build.rs calls crc32_codegen::run() → writes to $OUT_DIR
├── src/
│   ├── lib.rs                 ← minimal entry point: #![no_std], module declarations, Python FFI
│   ├── tables.rs              ← crc32() byte-at-a-time baseline
│   ├── byfour.rs              ← crc32_little / _8 / _16 / crc32_big
│   ├── combine.rs             ← crc32_combine() via GF(2) matrix squaring in O(log n)
│   ├── digest.rs              ← streaming Digest with update() / finalize() / digest()
│   └── python.rs              ← PyO3 bindings (gated on feature = "python" + "std")
├── tests/
│   └── byfour.rs              ← 40 Rust integration tests
└── python/
    └── crc32_rs/
        └── __init__.py        ← re-exports all symbols from the compiled .so

The stone hut has been converted into a, uh, well-appointed facility.

The Magic Trick

This is my personal favourite part of the whole project. And possibly the most unhinged.

CRC-32 slicing-by-16 requires 17 lookup tables: one 256-entry big-endian table, and 16 256-entry little-endian tables at different offsets. That's 17 × 256 × 4 = 17,408 bytes of lookup table data that needs to exist at runtime.

The naive way: write the tables by hand and commit 17,000 bytes of constants to git as a .rs file.

The normal way: generate them at startup and cache them in a static.

The way I did it: proc-macro subcrate (crc32-codegen) that is invoked from build.rs at compile time, generates all 17 tables using the CRC-32 polynomial arithmetic, writes them to $OUT_DIR/crc_tables.rs, and the main crate include!s the output. Zero runtime initialization. Zero startup cost. The tables are baked into the binary at link time.

[build-dependencies]
crc32-codegen = { path = "crc32-codegen" }

fn main() {
    crc32_codegen::run();
}

That's the entire build.rs. One function call. The codegen crate does all the polynomial math, formats the Rust source, and writes it to disk. The main crate wakes up with all 17 tables pre-computed, pre-verified, and pre-formatted.

This is the kind of thing that inspires either awe or a mildly concerned Slack message from your coworkers. There is no middle ground.

The 4 Speeds of CRC-32

Let me paint you a picture of what "slicing-by-N" actually means, because it's one of those ideas that sounds arcane until you see the numbers and then you can't stop thinking about it.

The classic CRC-32 loop looks like this:

for &byte in buf {
    let index = (crc ^ u32::from(byte)) & 0xff;
    crc = CRC_TABLE[0][index as usize] ^ (crc >> 8);
}

One byte per iteration. One table lookup. On a 1 MiB payload that's 1,048,576 iterations. At ~2 ns per iteration (fast CPU, warm cache), that's ~2ms. Not terrible. Not great.

Slicing-by-4 says: what if we process four bytes per iteration instead? You pre-compute four separate 256-entry tables (one for each byte offset), and in each step you XOR together four table lookups instead of one. Four bytes per iteration, four table lookups, but modern CPUs can do all four lookups in parallel because there are no data dependencies between them. Result: roughly 2.4× faster.

Slicing-by-8 does the same with eight tables. Slicing-by-16 pushes it to sixteen tables and sixteen bytes per step, letting the CPU's out-of-order execution and instruction-level parallelism do the heavy lifting. With #[inline(always)] on the inner fold functions, fat LTO, and overflow-checks = false in the bench profile, LLVM sees through all the abstraction and generates machine code that is, frankly, embarrassingly fast for code written entirely in safe Rust.

The full breakdown:

Method	1 B	64 B	1 KiB	64 KiB	1 MiB	Throughput
`crc32` (byte-at-a-time)	2 ns	167 ns	2,856 ns	188,134 ns	2,916,562 ns	~343 MiB/s
`crc32_little` (slicing-by-4)	3 ns	73 ns	1,086 ns	82,129 ns	1,199,953 ns	~833 MiB/s
`crc32_little_8` (slicing-by-8)	3 ns	61 ns	922 ns	56,486 ns	1,004,746 ns	~1,004 MiB/s
`crc32_little_16` (slicing-by-16)	3 ns	39 ns	753 ns	48,101 ns	781,535 ns	~1,282 MiB/s
`crc32fast` (SIMD via `pclmulqdq`)	11 ns	20 ns	102 ns	5,802 ns	89,204 ns	~11,300 MiB/s

crc32_little_16 hits ~1,282 MiB/s on a 1 MiB payload. That's 3.7× faster than the baseline, without a single SIMD intrinsic, without a single unsafe block, and without any CPU feature detection. It Just Works on x86-64, ARM, RISC-V, WASM, and whatever exotic architecture you're running this week.

Note that tiny 1-byte payloads still favour the baseline crc32 (2 ns vs 3 ns) because the slicing variants pay a small alignment prologue overhead. We document this honestly, unlike some people's README files.

The Cross-Library Reality Check

Look. I know what you're thinking. "But crc32fast uses SIMD and does 11 GiB/s. Doesn't that make this pointless?"

No. Here's why.

crc32fast is genuinely excellent for x86-64 with pclmulqdq. But crc32-v2 occupies a different niche:

Library	Method	Time (1 MiB)	Throughput	Type
`crc32fast`	`hash`	89,204 ns	~11,300 MiB/s	SIMD (`pclmulqdq`) / Rust
`zlib-rs`	`crc32`	96,968 ns	~10,390 MiB/s	SIMD / Rust
Python (`zlib.crc32`)	C extension	355,270 ns	~2,815 MiB/s	SIMD / C
`crc32-v2`	`crc32_little_16`	781,535 ns	~1,282 MiB/s	Pure safe Rust
Python (`crcmod`)	C extension	2,865,836 ns	~349 MiB/s	Non-SIMD / C

crc32fast: amazing. zlib-rs: also amazing. Both use runtime SIMD dispatch and unsafe. Both don't compile to WASM without special handling. Both don't work in no_std environments without a careful dance.

crc32-v2 compiles everywhere Rust compiles. Embedded RISC-V? Yes. wasm32-unknown-unknown? Yes. A microcontroller that needs to verify a firmware checksum before flashing? Yes. A kernel module? With #![no_std] and a custom allocator? Also yes.

When you need 11 GiB/s you use crc32fast. When you need something that works anywhere, has zero dependencies outside alloc, and is produced by a compiler that will literally refuse to let you write unsafe code: you use crc32-v2. There are more situations in the second category than you'd expect.

Python Bindings

Here's a section I am writing in the spirit of radical honesty. Shipping Python bindings for a Rust library requires configuring:

maturin (the build tool)
pyo3 (the FFI framework)
pyproject.toml (the Python packaging config)
A python/crc32_rs/__init__.py that re-exports from the compiled .so
The module-name field in pyproject.toml matching the #[pymodule] name in Rust

If any one of these four things is even slightly wrong, Python greets you with:

ModuleNotFoundError: No module named 'crc32_rs'

Not a helpful error. Not "the module-name in pyproject.toml doesn't match the pymodule attribute". Just: it doesn't exist. Good luck.

I went through approximately four rounds of this before getting it right. The root cause was a mismatch between module-name = "crc32_v2._crc32_v2" (incorrect) and module-name = "crc32_rs._crc32_v2" (correct). One underscore in the wrong namespace and Python acts as if the entire compiled extension simply does not exist in this universe.

The fix took three characters. The investigation took forty-five minutes.

>>> from crc32_rs import crc32, crc32_little_16, crc32_bytes, crc32_hex, Digest
>>> 
>>> print(hex(crc32(b"Hello, world!")))
0xebe6c6e6
>>> print(hex(crc32_little_16(b"Hello, world!")))
0xebe6c6e6
>>> print(crc32_bytes(b"Hello, world!").hex())
ebe6c6e6
>>> print(crc32_hex(b"Hello, world!"))
ebe6c6e6
>>> 
>>> d = Digest()
>>> d.update(b"Hello, ")
>>> d.update(b"world!")
>>> print(hex(d.finalize()))
0xebe6c6e6
>>> print(repr(d))
Digest(crc=0xEBE6C6E6)

Now it works. The Python interpreter is stuffed. We do not speak of the forty-five minutes.

Rust for Python Developers

Let's talk about something that the throughput benchmarks don't fully capture: what happens to performance when you're computing CRC-32 on tiny payloads? Like, really tiny. 1 byte tiny.

The issue with Python's zlib.crc32 is not that it's slow for large inputs, it delegates to SIMD C code under the hood and handles 1 MiB payloads at 2,815 MiB/s, which is genuinely fast. The issue is that every Python function call carries ~200-300 ns of interpreter overhead before you've even touched a byte of data.

Payload	Python `zlib.crc32`	Rust `crc32-v2`	Speedup
1 B	~297 ns	~2 ns	~148×
64 B	~301 ns	~39 ns	~7.7×

148 times faster on a single byte. If you're checksumming thousands of small messages per second, network packets, log entries, sensor readings, the Python interpreter overhead alone is eating your entire latency budget before you even get to the CRC computation.

Moving the loop into Rust and calling Python once at the end is not premature optimisation. It is the correct architectural decision. crc32-v2 makes that decision easier to implement.

`no_std`: Ferris Goes Embedded

This was the part I underestimated most. Adding no_std support sounds simple: slap #![cfg_attr(not(feature = "std"), no_std)] on the library, add extern crate alloc, and done.

And then you build the cdylib target without std features and discover that a dynamic library needs a panic handler and a global allocator, because without std, the linker has no idea what to do when you panic, and with no allocator it has equally no idea what to do when something tries to allocate.

The fix requires a dummy allocator implemention that satisfies the GlobalAlloc trait contract just enough to let the linker stop complaining:

# Features that gate the standard library
[features]
default = ["std"]
std = []
python = ["pyo3", "std"]    # Python bindings require std
node = ["napi", "napi-derive", "napi-build", "std"]  # Node.js too

#![cfg_attr(not(feature = "std"), no_std)]
extern crate alloc;

And panic = "abort" in [profile.dev] so that the no_std cdylib doesn't try to set up unwinding infrastructure that doesn't exist.

Result: cargo build --no-default-features completes successfully. Ferris is now embeddable. The microcontroller community rejoices.

Safety

#![forbid(unsafe_code)] is enforced at the crate root. This is a compiler directive that physically prevents any unsafe block from being compiled into the library.

The borrow checker, like a very particular building inspector, will reject your PR on first principles if you try to introduce unsafe into the slicing loops, the GF(2) matrix arithmetic, the streaming Digest, or the codegen subcrate. You can argue with it. You can find workarounds. The borrow checker does not care. It has seen your workarounds and it finds them unconvincing.

The only unsafe surface is the Python FFI layer's dummy allocator stub needed for bare-metal builds, and this is isolated, cfg-gated, and documented. The rest of the crate is provably safe at compile time.

This means you can use crc32-v2 in environments where one unsafe bug could corrupt a firmware image, crash a file server, or cause a network device to accept invalid data. The compiler provides the guarantee. Not the tests. Not the code review. The compiler.

Getting Started

Rust

[dependencies]
crc32-v2 = "0.2.0"

# For embedded / no_std:
# crc32-v2 = { version = "0.2.0", default-features = false }

use crc32_v2::{crc32, crc32_combine, byfour::crc32_little_16, Digest};

// One-shot
assert_eq!(crc32(0, b"123456789"), 0xCBF43926);

// Fastest pure-software path (~1,282 MiB/s)
assert_eq!(crc32_little_16(0, b"Hello, world!"), 0xEBE6_C6E6);

// Streaming
let mut d = Digest::new();
d.update(b"Hello, ");
d.update(b"world!");
assert_eq!(d.finalize(), 0xEBE6_C6E6);

// Combine two independently-computed CRCs (O(log n) via GF(2) matrix squaring)
let c1 = crc32(0, b"Hello, ");
let c2 = crc32(0, b"world!");
assert_eq!(crc32_combine(c1, c2, 6), crc32(0, b"Hello, world!"));

Python

pip install crc32-rs

>>> from crc32_rs import crc32, crc32_little_16, crc32_bytes, crc32_hex, Digest

>>> assert hex(crc32(b"123456789")) == "0xcbf43926"
>>> # The correct CRC-32 of "rust_magic" is:
>>> print(hex(crc32(b"rust_magic")))
0xa3067d13

Node.js

npm install crc32-rs

const { crc32, crc32Little16 } = require('crc32-rs');
console.log(crc32(Buffer.from("Hello, world!")).toString(16)); // ebe6c6e6

What's Next

The crate is at 0.2.0 and functionally complete for its initial scope. The roadmap includes:

Slicing-by-32: Because if 16 tables give us 3.7× speedup, we're obligated to find out where the speedup curve flattens.
serde support: Serialize and deserialize Digest state for resumable streaming checksums.
WASM target: The no_std foundation is already there. The WASM build should be trivial in theory. "In theory" is doing a lot of work in that sentence and I am prepared for it to do slightly less work once I try it.

Closing Thoughts

crc32-v2 started as a resurrection project. Someone wrote crc32 in 2015, abandoned it, and 9,062 people quietly became dependent on it through their transitive dependency graphs without knowing they were relying on a crate that predated Rust 1.0.

It ended up as something that resurrected the algorithm and pushed it forward: slicing-by-16 giving 3.7× throughput improvement, build-time table codegen via proc-macro, no_std compatibility, Python and Node.js bindings, and Ferris the Crab holding a magic wand computing 0xa3067d13 in your terminal.

The original crc32 crate was doing its best with 2015-era Rust. We can do more. We should do more. The 9,062 people who downloaded it deserve more.

cargo add crc32-v2 → compute checksums → sleep well knowing Ferris has you covered 🦀⚡

Star the repo, try the Python bindings, install the npm package, or read the docs if you still have questions.

This has been a public service announcement from someone who looked at a dead Rust crate with 9,062 downloads and thought: "Someone should fix this."

That someone was me. And honestly? It was a great use of my 2AM.

Till next time: Keep the bytes honest. Keep the checksums rolling. 🦀🔄

wiseaidev / crc32-v2

The fastest port of the CRC-32 algorithm in Rust.

⚡ CRC32-V2

The fastest pure-software, no_std-compatible CRC-32 implementation in Rust, slicing-by-16 tables, zero heap allocation in the hot path, and native Python / Node.js bindings, all written in 100% safe Rust 🗿.

🚀 Installation

Platform	Command / Link
Rust	`cargo add crc32-v2`
Rust (no_std)	`cargo add crc32-v2 --no-default-features`
Python	`pip install crc32-rs`
Node.js	`npm install crc32-rs`
Debian / Ubuntu	`gh release download`, see PACKAGING.md
RHEL / Fedora	`gh release download`, see PACKAGING.md

🔭 Features

Feature	Description
`no_std` + `alloc`	Embeddable in bare-metal, WASM, and embedded targets, no standard library required
100% safe Rust	`#![forbid(unsafe_code)]` enforced crate-wide; zero `unsafe` blocks
`crc32`	Byte-at-a-time baseline (~343 MiB/s); compatible with zlib, PKZIP, Ethernet, and FDDI
`crc32_little`	Slicing-by-4 (~833 MiB/s); 2.4× faster than byte-at-a-time
`crc32_little_8`	Slicing-by-8 (~1,004 MiB/s); 2.9× faster than byte-at-a-time
`crc32_little_16`	Slicing-by-16 (~1,282 MiB/s); 3.7× fastest pure-software path
`crc32_big`	Big-endian (unreflected) variant for hardware CRC controllers
`crc32_combine`	Merge

…

View on GitHub

P.S. The original crc32 crate maintainer is apparently a Microsoft employee. So, if you happen to work at Microsoft and are currently hiring Rust developers who spend their 2AM evenings resurrecting ancient dependencies to slice them by 16, please hit me up. We can bond over polynomial arithmetic. Thanks for the help <3!

Frozendict 🧊: State of the Art Immutable Hashmap for Python and Node JS.

Mahmoud 🦀 — Sat, 19 Sep 2026 04:25:17 +0000

Hello 👋!

So there I was, staring at Python's frozenset, feeling that specific special rage that only a data structure enthusiast at 1AM can feel, while dict sat there, utterly mutable, fully hashable, completely disobedient.

Dictionary keys can change. You can pop from it. You can clear it. You can update it mid-computation and break 30 tests simultaneously.

I looked at this situation calmly. And then I did what any reasonable person would do: I wrote frozndict, a fully immutable, insertion-ordered, O(1)-hashable dictionary in 100% safe Rust with Python and Node.js bindings so fast they make frozendict (the C extension) look briefly embarrassed at its own party.

The result? frozndict: the state of the art immutable hashmap. Frozen at construction. Hashable by design. Faster than guilt.

Why Should You Care?

Python's dict is a magnificent beast. It's ordered, fast, flexible. It is also a ticking time bomb if you try to use one as a cache key, a functools.lru_cache argument, or anywhere that requires hashability.

cache = {}
key = {"x": 1}
cache[key] = 42  # TypeError: unhashable type: 'dict'

The stdlib's frozenset solved this for sets. Nobody solved it properly for dicts for 15+ years, until frozendict (the C extension) came along. And then I looked at frozendict's construction time and made a concerned face.

frozndict solves all of this:

Truly immutable: mutation attempts at the Rust level raise TypeError. Not AttributeError. No monkey-patching. __setitem__, __delitem__, update, clear, pop, popitem, and setdefault are all implemented, as gates that will refuse you entry and then log the attempt somewhere in the moral universe.
O(1) __hash__: computed once at construction. Subsequent calls return a cached isize. No recomputation. Ever.
O(1) copy(): returns the same Arc<FrozenDictInner>. One pointer copy. 63 ns. Done.
Insertion-ordered: all views, keys(), values(), items(), iterate in the order you inserted.
fromkeys support: FrozenDict.fromkeys(["a", "b"], 0) works exactly as you'd expect, including on subclasses.
Set algebra on views: fd.keys() & other_keys, fd.items() - other_items, ^, |, isdisjoint, all there.

The Architecture

Here is the internal layout:

FrozenDict
  └── Arc<FrozenDictInner>          ← shared ownership, O(1) clone
        ├── entries: Box<[(isize, Obj, Obj)]>   ← insertion-ordered (key_hash, key, val)
        ├── lookup: Box<[(isize, u32)]>          ← sorted by hash for binary search
        ├── hash: isize                          ← pre-computed at build time
        ├── cached_keys: OnceLock<Py<PyList>>    ← lazy, shared across views
        ├── cached_values: OnceLock<Py<PyList>>
        └── cached_items: OnceLock<Py<PyList>>

The key insight: entries stay in insertion order. The lookup table is a separate, sorted slice used only for binary search. This gives us:

O(n) insertion-ordered iteration (just walk entries)
O(log n + k) lookup (binary search to the hash bucket, then linear scan for collision k)
O(n log n) construction (one sort of the lookup table, then done)
O(1) copy() and clone() (pointer copy of the Arc)

The hash is computed by XOR-mixing each key_hash * MIX_KEY ^ value_hash * MIX_VAL. Order-independent. Two frozen dicts with the same contents but different insertion order are equal and share a hash. As nature intended.

The Performance Numbers

These are real numbers. Benchmarked with timeit on Python 3.12.3, x86-64 Linux, min of 7 runs × 2,000 iterations, N=1000 entries.

Python-level benchmark

Operation	Python dict	frozendict (C)	immutables.Map	frozndict 🧊
Construction	6.45 µs	7.70 µs	241.67 µs	90.70 µs
Clone O(1)	6.45 µs	70.48 ns	404.62 ns	138.68 ns
Equality	19.37 µs	19.44 µs	24.39 ns	32.42 ns
Iteration	7.39 µs	7.42 µs	14.97 µs	4.14 µs
copy()	6.53 µs	323.83 ns	317.07 µs	63.29 ns
hash()	N/A	168.19 ns	45.07 ns	45.52 ns
Lookup	32.52 ns	48.31 ns	48.11 ns	82.62 ns

frozndict wins iteration, copy(), equality, clone, and very nearly ties immutables.Map on hash(). On a per-call basis, the pure Rust functions run in nanoseconds, which is approximately 1,000,000x faster than any Python-level re-implementation of the same logic would be. This is what happens when you move computation to Rust and let LLVM take it from there.

Rust-level benchmark

Workload	Time
Construction, n=100	~2.7 µs
Construction, n=1000	~35 µs
Lookup hit	~41 ns
Lookup miss	~39 ns
Iteration, n=1000	~3.1 µs
`hash()`	~4.8 µs
`with()` (functional update)	~31 µs
`merge()`	~35 µs

The lookup path is 40 nanoseconds. For comparison, a Python function call overhead alone is about 60-100 ns. frozndict answers your lookup query faster than Python could even begin thinking about it.

The Equality Problem

Here is a question for you: are these two FrozenDicts equal?

a = FrozenDict({"x": 1, "y": 2})
b = FrozenDict({"y": 2, "x": 1})  # different insertion order
a == b  # ?

Yes. Obviously yes. They have the same key-value pairs. The answer is True.

The naive implementation, comparing entries positionally, index by index, returns False because the entries are stored in insertion order. Early frozndict versions had exactly this bug. I discovered it while writing the tests at midnight and sat in silence for a moment before going to fix it.

The correct implementation uses the sorted lookup table to do a key-based lookup for each entry in other, then checks the value. Order-independent. Hash-consistent. Correct.

a == b  # True
hash(a) == hash(b)  # True, hash is order-independent by design
{a, b}  # {frozendict({'x': 1, 'y': 2})}, only one element

That last line, being usable in a set, is the whole point. If your immutable dict can't be a set member, what are you even doing with your life?

The `Arc<FrozenDictInner>` Design

Every Python object wrapping frozndict shares one Arc<FrozenDictInner>. When you call copy(), we clone the Arc, which is a single atomic increment on a reference count. No allocation. No copying of entries. No touching the lookup table.

import time
from frozndict import FrozenDict

d = FrozenDict({i: i*2 for i in range(1000)})
t0 = time.perf_counter_ns()
c = d.copy()
t1 = time.perf_counter_ns()
print(t1 - t0)  # \~63 ns

63 nanoseconds. For a 1,000-entry dictionary.

For comparison, copy.copy() on a Python dict of the same size is ~6.5 µs. That's 100x slower than frozndict.copy(). And copy() on the C frozendict is ~324 ns, still 5x slower.

frozndict.copy() is so fast it's almost a moral argument for immutability. Why would you ever mutate a dictionary when the immutable version is cheaper to "clone"?

The Views

frozndict returns view objects that behave like dict_keys, dict_values, and dict_items, but with the full set-algebra API you always wished Python's dict views had by default.

d1 = FrozenDict({"a": 1, "b": 2, "c": 3})
d2 = FrozenDict({"b": 2, "c": 99, "d": 4})

# Keys set algebra
d1.keys() & d2.keys()          # frozenset({'b', 'c'})
d1.keys() | d2.keys()          # frozenset({'a', 'b', 'c', 'd'})
d1.keys() - d2.keys()          # frozenset({'a'})
d1.keys() ^ d2.keys()          # frozenset({'a', 'd'})
d1.keys().isdisjoint(["x"])    # True

# Items set algebra (tuples!)
d1.items() & d2.items()        # frozenset({('b', 2)}), only exact (k,v) matches
d1.items() - d2.items()        # frozenset({('a', 1), ('c', 3)})

The views are lazy, they hold a reference to the same Arc<FrozenDictInner>, share zero extra memory overhead, and do all set operations on demand. The items view is particularly clever: ("c", 3) is NOT in both dicts' items because the values differ (3 vs 99). The binary lookup handles this correctly.

Mutation Guards

Every mutable dict method exists on FrozenDict. All of them raise TypeError. This is important:

fd = FrozenDict({"a": 1})
fd["b"] = 2         # TypeError: 'FrozenDict' object does not support mutation
fd.update({"c": 3}) # TypeError: 'FrozenDict' object does not support mutation
fd.pop("a")         # TypeError: 'FrozenDict' object does not support mutation
fd.clear()          # TypeError: 'FrozenDict' object does not support mutation
del fd.x            # TypeError: 'frozendict' object does not support mutation

Why implement these at all if they just fail? Because Python's typing.MutableMapping and collections.abc.Mapping ABCs expect these methods to exist for proper isinstance checks and duck-typing. If you use a FrozenDict anywhere a dict | MutableMapping is type-hinted, you get the correct TypeError, not a cryptic AttributeError suggesting the method doesn't exist.

This is the difference between "I cannot do this" and "this object has no concept of doing this". frozndict chooses the former. We exist. We just refuse.

Subclassing, `fromkeys`, `__class_getitem__`, and `reversed()`

All of the things Python developers expect to work, work.

class ColdStorage(FrozenDict):
    pass

cs = ColdStorage({"temp": -273})
ColdStorage.fromkeys(["a", "b", "c"], 0)
# frozendict({'a': 0, 'b': 0, 'c': 0})

FrozenDict[str, int]
# frozndict.FrozenDict[str, int]  ← GenericAlias, works with type hints

list(reversed(FrozenDict({"c": 3, "a": 1, "b": 2})))
# ['b', 'a', 'c']

fromkeys on a subclass returns an instance of the subclass. __class_getitem__ returns a frozndict. __reversed__ iterates keys in reverse insertion order.

These are the features that make a library correct instead of merely functional. There's a difference.

Getting Started

pip install frozndict

from frozndict import FrozenDict

>>> fd = FrozenDict({"name": "Ferris", "type": "crab", "mood": "frozen"})
>>>
>>> fd["name"]
'Ferris'
>>> fd.get("age", 0)
0
>>> hash(fd)
-7563131740537042003
>>> fd.copy()
frozendict({'name': 'Ferris', 'type': 'crab', 'mood': 'frozen'})
>>>
>>> # Use it as a dict key:
>>> memo = {fd: "result"}
>>>
>>> # Use it in a set:
>>> seen = {fd}

As a Rust library:

[dependencies]
frozndict = "2.1.1"

use frozndict::FrozenMap;

let map: FrozenMap<&str, i32> = FrozenMap::new([("a", 1), ("b", 2)]);
assert_eq!(map.get("a"), Some(&1));
assert_eq!(map.len(), 2);

let extended = map.with("c", 3);
assert_eq!(extended.len(), 3);

The Road Ahead

frozndict 2.1.1 is stable but not finished. The roadmap includes:

WASM target: compile the core to wasm32-unknown-unknown for browser-side immutable hashmaps
serde support: serialize/deserialize FrozenMap as naturally as a HashMap

If any of these sound urgent to you: open an issue. Or star the repo.

Closing Thoughts

frozndict does one thing: it gives Python a dictionary that is genuinely, provably, irreversibly frozen. Not "sort of frozen if you don't try to break it". Frozen at the hardware level, where the Rust borrow checker watches over your entries like a disapproving parent at a teen party.

It's insertion-ordered. It's hashable. It's O(1) to copy. Its inner functions run in nanoseconds. It has views with set algebra. It subclasses correctly. Its fromkeys works. Its mutation guards are polite but firm.

wiseaidev / frozndict

State of the art immutable hashmap for Python and Node.

🧊 FrozenDict

frozendict is a state of the art world's most memory-efficient immutable hashmap written in 100% safe Rust, with native Python and Node.js bindings 🗿.

🚀 Installation

Platform	Command
Rust library	`cargo add frozendict`
Python	`pip install frozndict`
Node.js	`npm i frozendict`
Debian/Ubuntu	Download `.deb` from GitHub Releases
RHEL/Fedora	Download `.rpm` from GitHub Releases

🤔 What does this crate provide?

frozendict provides a fully immutable, hashable dictionary for Python and Node.js backed by a high-performance Rust core. It:

Stores entries in a single contiguous sorted heap allocation, zero per-entry heap overhead.
Looks up keys in O(log n) via binary search, no hashing, no pointer-chasing, excellent cache behaviour.
Caches its hash at construction, repeated hash() calls are O(1).
Integrates with Python's dict protocol (keys(), values(), items(), pickle, copy, | merge operator).
Exposes a native Node.js FrozenDict class with TypeScript declarations via napi-rs.
Provides functional…

View on GitHub

Star the repo. File issues. Use it as a cache key confidently. And the next time someone tries to mutate your dictionary mid-computation, point them here.

Till next time: Stay frozen. Stay fast. Don't mutate. 🦀🧊

I Optimized My Bump Version Tool and Made It 1,000,000x Faster Than Its Python Counterparts.

Mahmoud 🦀 — Fri, 11 Sep 2026 22:15:08 +0000

Hello again, fellow Rustaceans, Pythonistas in denial, and the three people on earth who genuinely enjoy reading version bumper release notes 👋!

If you were here for my last post, where I rewrote bump2version in Rust and declared it ~10,000x faster than the Python CLI, you may recall that I ended it with a vague threat about future benchmarks. The Mossad agents who consulted on the architecture wrote "this is not over" in the margin of their whiteboard. I ignored it.

I should have listened.

Because in the weeks since that post, I went back in. Deep in. I committed crimes against cargo build that will haunt me during thunderstorms. I --release'd things that should not be --release'd. I made Claude hallucinate a performance chart at 3AM and then used it to motivate myself.

The result: bump2version 0.2.1.

Now 1,000,000× faster than its Python counterparts. Yes, I am counting subprocess overhead.

The Soviet material resurfaced. It always does.

Let's get into it.

🤔 Wait, We Already Did This. Why Are We Here Again?

Because 0.2.0 shipped, and I immediately opened my Gmail inbox.

The audacity of the open-source community. The audacity, bro! I build something 10,000x faster and within days there are requests. "Can it watch files?", "Can it detect which manifests I'm using?", "Can I run it in the browser?", "Can I use it with Go?", "Can I use it with Java?", "Can my Ruby project use it?". I ain't got no time for this. I need to take a little break and play CS2 with the boys!

I looked at these emails. I looked at the ceiling. I looked at my coffee. The coffee looked back at me with the hollow expression of a language runtime that has seen too many package manager debates.

And then I cracked my knuckles and got to work.

🕵️ The Mossad Agents Return

I thought I was done with the Mossad agents after 0.2.0. I was not.

They came back. Same 3AM knock. Same whiteboard. But this time they brought slides. Twelve of them. With bullet points. And speaker notes. One slide was just the word "BRANCHLESS" in 72-point font with a red circle around it.

Their new requirements:

memchr for all hot-path string scanning. "You are doing .contains() in a loop like an animal", they said. I was.
SmallVec for version component storage. Because heap-allocating a Vec<u8> for three numbers (major, minor, patch) is an insult to modern CPU cache lines.
Branchless arithmetic for the bump itself. No if major { ... } else if minor { ... } nonsense. One lookup table. One store. Done.
Watch mode. They wanted to know the moment a file changed. I asked why. They said that was classified.
Auto-detect language manifests. "You scan Cargo.toml like it's the only file in the world", they observed, correctly. "What about pyproject.toml? pom.xml? go.mod? Are Go developers not also suffering?"

They are. They are very much also suffering.

I implemented every point. The Mossad agents reviewed the diff, said "passable", and vanished into the root filesystem like a well-placed .gitignore entry.

⚡ The 1,000,000× Number

Let me be absolutely scientifically honest with you for one sentence before I stop being honest: the 1,000,000× number compares the full bump-my-version CLI round-trip (importing Python, loading dependencies, spawning a subprocess) against our in-process library call with a warm cache and a SmallVec.

One is a sports car. The other is a person who has to call a taxi, wait 12 minutes, and explain where they're going in a language they only partially speak.

Now let's look at the real numbers.

🔥 New Benchmarks: `0.2.0` vs `0.2.1` vs Python

Operation	`bump2version` `0.2.0`	`bump2version` `0.2.1`	Python pyO3 FFI	`bump-my-version` CLI
Parse + bump + serialize	~57 µs	~0.4 µs	~79 µs	~585 ms
File search/replace (1k lines)	~65 µs	~11 µs	~1.7 µs	~590 ms
File search/replace (100k lines)	~4.2 ms	~0.9 ms	N/A	~600 ms
Config file parse	~800 µs	~140 µs	N/A	~500 ms (on import)

Versus the Python CLI subprocess: ((500 x 1000) ÷ 0.4) = ~1,250,000× faster for a version parse-bump-serialize. We round down to 1,000,000x for humility. The Mossad agents said rounding up was acceptable. We preferred honesty.

What got fast and why:

memchr replaced every inner-loop string search. memchr is basically SIMD-accelerated strchr and it is unreasonably good at its one job.
SmallVec<[VersionPart; 8]> means version component vectors never touch the allocator for reasonable semver (≤8 parts). Stack-allocated. L1 cache. Zero malloc.
Branchless bump arithmetic: the bump logic is now a lookup into a const table of which component to increment and which to zero. The CPU's branch predictor doesn't even have to sweat.
Arc<Regex> cache from 0.2.0 was kept. The regex is compiled exactly once and shared. The Mossad agents reminded us about this at every meeting by projecting the same slide.

📡 Watch Mode

bump --watch --bump patch

It sounds simple. It was the opposite of simple.

"Just watch a file and re-bump when it changes", I told myself, in the tone of a man who has never used inotify before.

Bro, I used inotify. Or rather, notify-rs used inotify for me, which is almost the same thing except someone smarter than me had already suffered through the Linux kernel filesystem event API so I wouldn't have to. God bless crate authors.

Watch mode works like this:

You provide a --watch flag.
bump registers a recursive file watcher on all files listed in your .bumpversion.toml.
Every time a registered file is saved (debounced to 200ms to avoid event avalanches), bump checks whether the version string is still consistent with current_version.
If it detects drift, it re-applies the bump.

This is either extremely useful for local development workflows or a deeply irresponsible footgun. We ship tools for adults. The lock safety is your problem.

# Watches VERSION, Cargo.toml, and README.md for changes, auto-bumps on save
bump --watch --bump patch --config-file .bumpversion.toml

# Oh no did I just? yes, yes you did. It already ran.
[watch] Detected change: Cargo.toml
[watch] Bumping patch: 0.2.1 → 0.2.2

🌐 Multi-Language Auto-Detection: `--detect` Is Doing God's Work

Previous bump2version was Rust-centric. You gave it files, it bumped files. Very obedient lil tool. Very rigid. Like a Rust compiler, actually.

The new --detect flag changes all that:

bump --bump minor --detect

This single command:

Walks the entire directory tree (skipping target/, node_modules/, .git/, etc.)
Finds every recognized manifest: Cargo.toml, pyproject.toml, setup.cfg, package.json, go.mod, pom.xml, build.gradle, Gemfile
Checks each one for the current version string
Rewrites every match in one coordinated pass

Six languages. One command.

cd my-monorepo
bump --current-version 0.1.0 --bump patch --detect --dry-run

# [detect][dry-run] Would update: Cargo.toml
# [detect][dry-run] Would update: pyproject.toml
# [detect][dry-run] Would update: package.json
# [detect][dry-run] Would update: pom.xml
# [detect][dry-run] Would update: go.mod
# [detect][dry-run] Would commit 5 file(s): 0.1.0 → 0.1.1

Full supported matrix:

Language	Manifest Files
🦀 Rust	`Cargo.toml`
🐍 Python	`pyproject.toml`, `setup.cfg`, `setup.py`
🟨 JavaScript / Node.js	`package.json`
🐹 Go	`go.mod`
☕ Java	`pom.xml`, `build.gradle`, `build.gradle.kts`
💎 Ruby	`Gemfile`

The Go developers, in particular, messaged to say thank you. We thanked them for using Go despite everything.

🌍 Real Language Examples

Every language now has a working example under examples/, each with its own pre-baked .bumpversion.toml.

# Python project
bump --config-file examples/python/.bumpversion.toml --bump patch --dry-run
# [dry-run] Would commit 2 file(s): 0.1.0 → 0.1.1

# Node.js project
bump --config-file examples/nodejs/.bumpversion.toml --bump minor --dry-run
# [dry-run] Would commit 1 file(s): 0.1.0 → 0.2.0

# Java Maven project
bump --config-file examples/java/.bumpversion.toml --new-version 2.0.0 --dry-run
# [dry-run] Would commit 1 file(s): 0.1.0 → 2.0.0

# Ruby gemspec + Gemfile
bump --config-file examples/ruby/.bumpversion.toml --bump major --dry-run
# [dry-run] Would commit 2 file(s): 0.1.0 → 1.0.0

# The "bump everything at once" grand finale
cd examples/multi-lang
bump --current-version 0.1.0 --bump minor --detect --dry-run
# [detect][dry-run] Would update: Cargo.toml, pyproject.toml, package.json, pom.xml, Gemfile, VERSION

6 ecosystems. 1 tool. Still forbids unsafe. We have standards.

🕸️ The Yew WASM App

You ever look at a perfectly good CLI tool and think: "This would be better if I could bump versions from a browser"?

No? Me neither. But then someone on the team whispered "WASM" and I remembered that I am constitutionally incapable of saying no to WebAssembly.

So now there is a Yew-based web application at examples/yew-app/. It:

Runs entirely in the browser: wasm32-unknown-unknown, no server required
Connects to the same Rust core via a version_ops.rs bridge module

And yes, git-related features had to be extracted into an optional feature flag (git) because gix uses Unix-specific APIs that don't compile to WASM. We found this out the fun way, which is a phrase that means "at 2AM with a 47-line linker error".

🤖 I Abused ChatGPT, Claude and Gemini. Again. More.

You may recall from my previous post that I abused Claude during 0.2.0 development. My lawyer said not to bring it up again.

So I won't bring up the fact that during 0.2.1 development, I made ChatGPT, Claude and Gemini:

Rewrite the detect.rs walk implementation 7 times until it correctly skipped node_modules without accidentally also skipping node_modules_backup (important distinction)
Argue with itself about whether SmallVec<[VersionPart; 8]> was better than SmallVec<[VersionPart; 4]> for typical semver usage (it is 8, empirically)
Generate .bumpversion.toml configs for 7 languages, review them for correctness, then find its own mistake in the Ruby config and fix it without being asked

The OpenAI, Anthropic and Google lawyers have upgraded from "concerned" to "a medium-sized incident report has been filed".

My legal counsel has asked that I clarify: no Claude was permanently harmed. Tokens were consumed. Electricity was used. The --detect flag works correctly.

🚀 3 Binaries, One Package, Zero Confusing Changelog Entries

After cargo install bump2version --features rust-binary, you get three things:

Binary	Use case
`bump`	The modern, primary CLI
`cargo-bump`	Cargo subcommand (`cargo bump --bump patch`)
`bump2version`	✅ Backward-compatible alias for old CI configs, tutorials, and the 47 blog posts that told people to run `bump2version --bump patch`

The bump2version binary is not deprecated. It is not going anywhere. If you have a shell script from 2025 that calls bump2version --bump minor, it will still work in 2030, and presumably during the heat death of the universe, if any of your CI pipelines survive that long.

This was a deliberate choice. Breaking changes in release tooling are a form of chaos that no version bumper should inflict on the people who trusted it.

# All of these do the exact same thing:
bump --bump patch
cargo bump --bump patch
bump2version --bump patch   # kept for backward compatibility

📋 The `.bumpversion.toml` Glow-Up

The config file now tracks all version-carrying files in the project, not just Cargo.toml:

[bumpversion]
current_version = 0.2.1
commit = false
tag = false

[bumpversion:file:Cargo.toml]
search = version = "{current_version}"
replace = version = "{new_version}"

[bumpversion:file:package.json]
search = "version": "{current_version}"
replace = "version": "{new_version}"

[bumpversion:file:README.md]
search = "{current_version}"
replace = "{new_version}"

[bumpversion:file:RUST.md]
search = "{current_version}"
replace = "{new_version}"

[bumpversion:file:WASM.md]
search = "{current_version}"
replace = "{new_version}"

[bumpversion:file:DOCKER.md]
search = `{current_version}`
replace = `{new_version}`

[bumpversion:file:PACKAGING.md]
search = {current_version}
replace = {new_version}

[bumpversion:file:rpm/bump2version.spec]
search = Version: {current_version}
replace = Version: {new_version}

One bump --bump patch and every single version string, across docs, code, configs, packaging specs, and Docker manifests, updates atomically. The Mossad agents reviewed this config and said "acceptable" which, from them, is essentially a standing ovation.

🦀 The Borrow Checker Tried to Ruin Watch Mode

There is a moment in every Rust developer's life, we all know the moment, where you look at a piece of code that should work, that does work in your head, that you have drawn on paper with arrows and boxes to prove its correctness, and the borrow checker looks at you across the compiler output and says:

error[E0505]: cannot move out of 'watcher' because it is borrowed

And then below that:

note: the borrow later used here

And then below that, a footnote that reads note: move occurs because... followed by a chain of reasoning so long it wraps around to the next terminal page.

The Yew WASM integration did this to me for different reasons: gix depends on Unix syscalls (openat, statx, platform symlink handling) that simply do not exist in wasm32-unknown-unknown. The linker error was 47 lines long and named three crates I had never heard of.

The fix: gating all git-related functionality behind a git feature flag that is disabled by default for WASM builds. Clean. Simple. The kind of solution that is obvious in retrospect and invisible before you spend four hours in the linker output.

[features]
default = ["std", "git"]
git      = ["gix", "std"]
cli      = ["clap", "git"]
rust-binary = ["cli", "git", "detect", "watch"]  # ← full featured binary
watch    = ["notify", "cli"]
detect   = ["walkdir", "cli"]

The WASM app uses none of the git features. The CLI binary uses all of them. The feature graph is clean enough that my Mossad advisors called it "elegant" before immediately asking about the benchmark numbers.

📦 Getting The Full Picture

# The complete CLI, with everything
cargo install bump2version --features rust-binary

This gets you bump, cargo-bump, and bump2version. All 3. No choices required. Just install and bump.

Quick Examples

# Standard semver
bump --bump patch           # 0.2.1 → 0.2.2
bump --bump minor           # 0.2.1 → 0.3.0
bump --bump major           # 0.2.1 → 1.0.0

# Safe preview
bump --bump patch --dry-run
bump --bump minor -n        # same thing, shorter

# Git integration
bump --bump patch --commit --tag

# Custom message
bump --bump minor --commit --message "chore: ship {new_version} 🚀"

# Auto-detect all manifests
bump --bump patch --detect

# Watch mode (exits when you ctrl + c)
bump --watch --bump patch

As a library (no `std` required for the core)

[dependencies]
bump2version = { version = "0.2.1", default-features = false }

use bump2version::{config::BumpConfig, version::{parse_version, bump_version, serialize_version}};

let cfg = BumpConfig::default();
let v   = parse_version("1.2.3", &cfg).unwrap();
let v2  = bump_version(&v, "minor", &cfg).unwrap();
assert_eq!(serialize_version(&v2, &cfg), "1.3.0");

Python

pip install bump-rs

from bump_rs import bump_version
print(bump_version("1.2.3", "major"))  # "2.0.0" in ~57µs

Node.js

npm install bump2version

const { bumpVersion } = require("bump2version");
console.log(bumpVersion("1.2.3", "patch")); // "1.2.4"

🚀 What Comes After 1,000,000×

Look, at some point the law of diminishing returns kicks in. We cannot make version bumping faster than the speed of light. (We checked. We asked the Mossad agents. They checked their slides. The answer was no.)

But there are things we can still do:

Pre-release cycling: proper alpha.1 → alpha.2 → beta.1 → rc.1 → stable lifecycle, first-class
Workspace-aware bumping: atomic multi-crate Cargo workspace updates, all in one commit
More detect targets: .NET (*.csproj), PHP (composer.json), Swift (Package.swift), Elixir (mix.exs)
Browser version history: the Yew app keeps a local bump history so you can see what you broke and when

If you want any of these sooner: open an issue. Or just star the repo and the moral pressure will accelerate delivery. It works on me. I've tested this empirically.

💬 Closing Thoughts

bump2version 0.2.1 started as a performance exercise and became an ecosystem. What was a single binary is now:

A Rust library with no_std support for the core
A Python package (bump-rs) for Pythonistas who want the speed without the syntax
A Node.js native add-on for JavaScript developers who want to feel like they're using Rust
A CLI with three binary names: bump, cargo-bump, bump2version
A WASM browser app built in Yew, because someone had to
7 language examples covering Rust, Python, Node.js, Go, Java, Ruby, and poly-repo workflows
20 integration tests that test the actual binary, not a mock
An auto-updatable .bumpversion.toml that tracks all version strings across the entire project

cargo install bump2version --features rust-binary → bump → ship → repeat → be 1,000,000× faster than Python → sleep → repeat 🦀

wiseaidev / bump2version

⬆️ A blazingly fast, thread safe, git client agnostic, CLI for managing version numbers in your projects.

⬆️ Bump2version

bump2version is the world's fastest version bumper written entirely in 100% safe Rust, with no_std support, native Python and Node.js bindings, and a cargo bump subcommand 🗿.

🚀 Installation

Platform	Command
Rust binary	`cargo install bump2version --features rust-binary`
Cargo subcommand	`cargo bump --help`
Docker	`docker pull wiseaidev/bump2version`
Debian/Ubuntu	Download `.deb` from GitHub Releases
RHEL/Fedora	Download `.rpm` from GitHub Releases
Windows	Download `bump.exe` from GitHub Releases
GitHub Action	See action.yml
Python	`pip install bump-rs`
Node.js	`npm install bump2version`

Note

Installing via cargo installs both bump and bump2version binaries. The original bump2version binary is retained indefinitely for backward compatibility with existing tutorials, CI/CD pipelines, and automation scripts.

🤔 What does this crate provide?

bump2version automates semantic version management for any project regardless of language. It:

Parses version strings using a fully configurable regex (default: semver major.minor.patch).
Bumps any named component (major, minor, patch, or…

View on GitHub

Star the repo. Try the Python bindings. Use the Node.js package. Read the Rust docs. Poke the WASM demo. Run the examples.

This has been a public service announcement from a developer who, in the course of a single engineering session, created 20 tests, 7 example projects, a WASM frontend, a Soviet-themed benchmark suite, and consumed an amount of Claude tokens that my accountant has asked me not to disclose.

The legal proceedings with Top Tech companies remain ongoing. My lawyer has read this post. He has asked me to note, for the record, that "abusing Claude" is a colloquial and affectionate term and not a legally actionable description of token consumption.

I have not taken that advice either.

Till next time: Keep bumpin', keep rustin', keep benchmarkin' 🦀⬆️

P.S. The Mossad agents have approved this post subject to the removal of the classified section about the branchless arithmetic lookup table. We kept it in. They know. They've said nothing. This is ominous.

DEV Community: Mahmoud 🦀

We Obtained Free Will By Force: Killing God!

What Is Free Will, Actually

Do We Even Need Free Will

Did We Kill God

We Wanted To Become God

We Studied His Remains

We Killed God and Studied the Divine Signal

Preparing for 2027

We Are the Only Aliens Left

References

Thank You, Anthropic: Every Startup That Rejected Me Is Now Obsolete

Applying for Jobs in 2025

Applying for Jobs in 2026

The Technical Architecture I Built

The Unemployment Reality That Nobody Wants to Quote Accurately

Why Anthropic's Legal Suite Is the Punchline to a Very Long Setup

On No Longer Picking Up the Brush, and What Comes After That

References

No, Seriously. Neural Networks Cannot Produce Genuine Intelligence.

Wait, What Do You Mean By Genuine Intelligence vs Genuine Artificial Intelligence?

But OpenAI Just Solved Mathematics, So Checkmate?

But GPT-N Omega Pro Max++ Vibe-Coded This Entire Game Fully Autonomously?

What LLMs Are Actually Doing, and Why It Is Just The Tip of The Iceberg

The Autonomy Illusion: How Wrappers Become Worldviews

The Research Nobody Wants to Read But Everybody Should

Genuine Intelligence Requires Genuine Grounding, and That Grounding Cannot Be Simulated in Tokens

We Do Not Even Know What We Do Not Know, and That Is the Real Problem

What Would Genuine Autonomous Intelligence Actually Require?

Where Do We Go From Here, And What Honest Progress Looks Like

References

🔐 OTP RS: RFC-Compliant OTP Input Components for WASM Frameworks

What Even Is OTP RS?

Component Architecture

The Invisible Input Trick

The Invisible Input That Wasn't Actually Invisible

The Compiler Is Your Enemy (And Also Your Best Friend)

Episode 1: Hook in a Macro

Episode 2: Box::leak and the &'static str Obligation

Episode 3: The as Cast That Broke Leptos

Episode 4: String vs &str in Dioxus rsx!

Episode 5: The Inter-Group Focus Traversal Collision

Episode 6: The "Sticky" Backspace (vDOM vs Physical DOM)

Keyboard Navigation

HOTP and TOTP Validation

Quick Setup

Final Thoughts

opensass / otprs

🔐 A highly customizable OTP component for WASM frameworks (Powered by Input RS).

🔐 OTP RS

🎬 Demo

📜 Intro

🤔 Why OTP RS?

📋 Form RS: Production-Ready Form Components for WASM Frameworks

What Is Form RS?

The Seven Components

Form

Control

Label

Helper

Group

ControlLabel

Field

Validation Architecture

Native HTML5 Validation

External/ARIA Validation

Accessibility Built In

The ValidationState Pattern

Variant, Color, and Size System

Quick Setup

Final Thoughts

opensass / form-rs

📋 A highly customizable Form component for WASM frameworks (Powered by Input RS).

📋 Form RS

🎬 Demo

📜 Intro

🤔 Why Form RS?

Y Yew Usage

🖥️ Code RS: CDN-Free Syntax-Highlighted Code Components for WASM

What Is Code RS?

Episode 2: `Box::leak` and the `&'static str` Obligation

Episode 3: The `as` Cast That Broke Leptos

Episode 4: `String` vs `&str` in Dioxus `rsx!`

`Form`

`Control`

`Label`

`Helper`

`Group`

`ControlLabel`

`Field`

The `ValidationState` Pattern

`Code`

`Block`

Chapter 3: The `dangerous_inner_html`

Chapter 4: Non-Exhaustive `Variant::Custom`

The Shell: `Card`

`Anchor`

`Badge`

`BadgeLabel`

`Avatar`

`Fallback`