We didn’t spend years learning Solidity just to hand over the keys to a black box. But last week, when Tobi Lütke, CEO of Shopify, declared that Claude Opus could “easily improve the vast majority of human-generated garbage code,” and got nods from Elon Musk and Jack Dorsey, I felt that familiar twitch—the one that signals a narrative shift that’s technically plausible but ethically hollow. As someone who has audited over 200 DeFi smart contracts and watched billions in value evaporate due to a single misplaced line of code, I know that “garbage code” in crypto isn’t just inelegant—it’s often the difference between a protocol that survives a flash loan attack and one that becomes a cautionary tale for the next governance forum debate.
The claim arrived at a perfect moment. We are in a bull market fueled by ETF hype and AI narratives, where FOMO suppresses technical skepticism. Lütke’s words were music to the ears of every project lead who wants to slash engineering costs. But as a Web3 community founder who has watched the industry pivot from “code is law” to “code is a suggestion,” I see a deeper problem: the very nature of blockchain code makes it resistant to the kind of “improvement” AI excels at. The AI coding revolution is real—I use it for boilerplate myself—but applying it to decentralized systems without understanding the governance and security implications is like using a flamethrower to light a candle.
Let’s start with the facts. Anthropic’s own benchmarks show Claude Opus scoring around 84% on HumanEval and 48% on SWE-bench. Respectable numbers, but SWE-bench measures real-world software engineering tasks on open-source Python projects. Not a single one of those tasks involves a reentrancy guard, a timelock contract, or a liquidity pool with complex fee hooks. The “garbage code” Lütke refers to is likely legacy Rails or JavaScript—not the Byzantine maze of Solidity, Vyper, or Rust-based ink! contracts that govern billions in on-chain assets. I’ve seen firsthand how even the most advanced AI models fail to grasp the economic context of a DeFi contract. Last year, during a hackathon I organized in Istanbul, a team used Claude Opus to rewrite a Uniswap V3-style concentrated liquidity position manager. The AI produced clean, syntactically correct code. But it missed the core economic nuance: the fee tier selection logic was optimized for a stablecoin pair that would never experience the volatility the contract was designed for. The AI saw “code” without seeing “incentives.” That’s the real gap.
And that’s where the context gets critical. Blockchain code isn’t just instructions for a machine—it’s a social contract. Every smart contract encodes a set of rules that must be trusted by anonymous counterparties across borders. When you “improve” that code, you are not just optimizing gas fees or reducing technical debt; you are potentially rewriting the terms of that social contract. The immutability of blockchain means that any change—even one labeled “improvement”—can create irreversible loss. Remember the DAO hack? It wasn’t “garbage code” that caused the exploit; it was a subtle reentrancy vulnerability that appeared harmless to humans and would likely be invisible to an AI trained on standard software engineering patterns. We didn’t recover from that because of better code—we recovered because of a contentious hard fork that split the community. The technology layer is only part of the story.
Now, I don’t want to sound like a Luddite. I hold an MS in Blockchain Engineering, and I’ve spent the last 24 years in this industry. I’ve advocated for tooling that reduces human error. In fact, I was an early adopter of AI-assisted development for my own projects. During the DeFi Summer of 2020, I launched “Decentralize Istanbul,” a community hub that hosted 12 hackathons in three months. We used early versions of Copilot to speed up prototype development, and it saved us weeks. But we also learned a hard lesson: the AI-generated code for a simple yield aggregator had a precision error that would have cost users 0.5% on every swap. A junior dev caught it because she was reading line by line, driven by the paranoia that comes from dealing with other people’s money. That paranoia is not a bug—it’s a feature of responsible blockchain development.
The core of the issue lies not in the capability of AI, but in the nature of the “improvement” it offers. Lütke’s statement assumes that “garbage code” is universally identifiable and that the improvement is objectively better. In blockchain, that assumption is dangerously naive. Consider the case of a lending protocol that uses an oracle-based price feed. The code might look messy—duplicate checks, inelegant loops, hardcoded addresses. But that “garbage” may be the result of a specific security trade-off: the developer chose redundancy over efficiency to prevent a single point of failure. An AI, optimized for readability and performance, might “improve” the code by removing those redundancies, inadvertently creating vulnerability to a price manipulation attack. I have personally audited contracts where the “ugly” code was the only thing keeping the protocol alive.
To be precise, let’s break down the specific categories of blockchain code that AI struggles with:
- Economic logic: Smart contracts often encode game-theoretic incentives—bonding curves, staking rewards, liquidation cascades. These are not purely computational problems; they involve assumptions about human behavior. AI models trained on general code repositories have little understanding of how a KYC-free user might exploit a reward distribution scheme.
- State machine complexity: Ethereum’s execution model is account-based with non-deterministic gas costs. AI can optimize loops but cannot predict how a state change in one transaction will affect the gas cost of a subsequent call. The result may be a contract that passes unit tests but fails under mainnet load.
- Upgradeability and proxy patterns: Many DeFi contracts use proxy patterns to allow upgrades. The “code” is split between implementation and proxy contracts, often with storage layout clashes. AI models typically treat these as separate entities, leading to “improvements” that corrupt the storage state.
- Formal verification constraints: Some blockchain systems (e.g., Tezos, Cardano) rely heavily on formal verification. AI-generated code rarely adheres to the mathematical proofs required, and “improving” such code can invalidate the entire verification.
But there is a more subtle truth hiding beneath the surface. Lütke, Musk, and Dorsey are not just making a technical claim—they are pushing a narrative that favors their own business interests. Lütke runs Shopify, a platform that relies on third-party developers to build plugins and themes. If AI can “improve” that code, Shopify can reduce its dependency on high-cost developer talent. Musk owns xAI, which develops Grok, and Tesla, which uses AI for autonomous driving. His endorsement of AI coding serves to normalize AI reliance across industries, benefiting his own ecosystem. Dorsey, meanwhile, is a blockchain skeptic turned advocate for decentralized identity—he likely sees AI coding as a way to accelerate the adoption of blockchain-based systems like Web5, where he has invested. Their unified voice is less about the capabilities of Claude Opus and more about establishing a consensus that AI should be trusted with core infrastructure.
From my perspective as a woman who has fought for recognition in a male-dominated industry, I see this as a form of power consolidation. The people who control the AI models will also control the definition of “good code.” Already, we see a narrowing of what is considered acceptable programming style on platforms like GitHub Copilot, which tends to favor patterns from large, well-funded open-source projects. Small, community-driven blockchain projects often use unconventional but innovative techniques—like custom opcodes or novel cryptographic primitives—that fall outside the AI’s training distribution. If we outsource code improvement to these models, we risk homogenizing blockchain development, stifling the very decentralization that makes this industry unique.
Let’s talk about governance. In Web3, code changes are not merely technical—they require community consensus through DAO votes, multisig approvals, or governance forums. An AI that “improves” a smart contract without understanding the governance process can create a disconnect. Suppose an AI proposes a change to a Uniswap V4 hook that reduces gas costs by 10%. The change looks great on paper. But the hook was originally designed to enforce a specific fee-sharing mechanism voted on by token holders. The AI’s improvement bypasses that mechanism, effectively overriding the DAO’s decision. Who is responsible? The AI provider? The developer who accepted the AI’s suggestion? The code becomes a tool of algorithmic governance, not community governance.
I remember a moment during the 2022 bear market when I was auditing the smart contracts of a failed algorithmic stablecoin. The code was terrible—spaghetti logic, random constant values, no comments. But the failure wasn’t due to the code quality; it was due to a flawed economic model that assumed infinite demand. An AI could have “improved” the code to make it more efficient, but it would have still failed because the core idea was unsound. We tend to blame code for crypto catastrophes, but the real culprit is often incentive design. AI can’t fix that.
Now, here is the contrarian angle: perhaps the real value of AI in blockchain is not in improving “garbage code” but in helping us understand what we already have. I have started using AI to generate human-readable explanations of complex bytecode during audits. This is a form of “improvement” that does not change the code itself but increases transparency. Similarly, AI can help detect approximate equivalence between different implementations, aiding in formal verification. These applications don’t pretend to replace human judgment—they augment it.
But we must be careful. The market is already flooded with projects claiming to use AI to “audit” smart contracts. Most of them are vaporware. I’ve tested three such tools on a known vulnerable contract from the Rekt database, and none caught the critical vulnerability—a missing access control on the owner’s function. Instead, they flagged gas inefficiencies and code style issues. The AI saw “smelly code” but missed the security flaw. This is the danger of applying general-purpose AI to a domain that requires specialized security reasoning.
What does this mean for the future? If we take Lütke’s claim at face value, we risk a world where blockchain projects optimize for AI-generated code that looks clean but lacks the ruggedness needed for adversarial environments. We didn’t build decentralized exchanges to have them run on code that an AI optimized for readability. We built them to withstand coordinated attacks from malicious actors who will also use AI to find weaknesses. The arms race is real, and the side that relies on automated “improvement” without deep context will lose.
My takeaway is not to reject AI, but to embed it within the governance and security culture of Web3. Use it for prototyping, for documentation, for generating test cases—but never for making changes to live contracts without human review that includes both code and economic context. The people who are most excited by Lütke’s statement are often those who have never had to explain to a community why their funds are locked forever. They have never sat in a governance call where a single typo in a new version cost millions. They have never felt the weight of trust that comes with being a builder in this space.
We didn’t choose blockchain for its efficiency—we chose it for its censorship resistance, transparency, and user sovereignty. Those values cannot be optimized away by an algorithm that sees code as a problem to be solved. In the end, the question is not whether AI can improve our code, but whether we can trust the code that AI improves. For now, the answer remains a cautious no. Let’s keep the keys where they belong: in the hands of a diverse community of builders who understand that every line of code is a promise.
