Trust, but Verify: Pair Programming with AI for Secure Smart Contracts
Author
Codes For Tomorrow
Codes For Tomorrow is a team of protocol engineers building Layer 1 networks, on-chain protocols and MPC wallets for enterprises.
Introduction
Smart contract development sits at the intersection of code and finance. A single faulty line can permanently lock user funds or let an attacker drain millions. At the same time, artificial intelligence (AI) coding assistants promise a real productivity gain: GitHub markets Copilot as an "AI pair programmer," and the appeal is obvious, with autocompleted Solidity functions, unit tests written for you, and documentation summarized on demand. Over-reliance on that automation is where the danger starts. Our position is to trust AI enough to use its speed, and to verify every output before it goes onchain.
AI's role: assistant, not architect
What code suggestions actually are
AI coding assistants excel at pattern matching. They read comments, function names, and surrounding code, then generate syntactically plausible completions. The "AI pair programmer" label oversells what that is. A human pairing partner debates design decisions and challenges your architecture; an AI assistant offers plausible code and moves on. Its value is in accelerating code generation, not in replacing critical thinking. That holds even as assistants have grown from inline suggestions into agentic tools that plan changes, edit files, and run their own tests. Throughput is higher, but the judgment about what a contract should do, and what it must never allow, still comes from the engineers.
Security boundaries of AI code suggestions
GitHub's own documentation warns that Copilot's inline suggestions can generate code that looks syntactically correct but may not be secure. Suggestions are bounded by the training data, and languages with few public examples, like Solidity, yield lower-quality output. Copilot can also reproduce insecure patterns, because it learned from public code that contains bugs. An academic evaluation of Copilot found that roughly 40% of generated programs were vulnerable. That study dates from Copilot's first generation and deliberately targeted vulnerability-prone scenarios, and models have improved since, but the core lesson holds: generated code inherits the flaws of the public code it learned from, and improvement is not a guarantee. A separate study that generated 250 smart contracts with GPT-4 and DeepSeek-Coder concluded that although the AI-written contracts were syntactically sound, they "still suffer from critical security vulnerabilities, making them unsuitable for fully autonomous development". The takeaway is that AI belongs in the autocomplete role, useful for boilerplate but never trusted for secure logic.
Limitations with Solidity and smart contracts
Large language models are trained on datasets dominated by popular languages like JavaScript and Python. Solidity, by contrast, accounts for about 0.01% of The Stack v2 dataset [VERIFY: link added (SolContractEval); SME confirm]. Researchers behind SolContractEval, a contract-level Solidity benchmark, found that models perform worse on Solidity tasks than on general-purpose languages, and that they struggle with complex logic, inter-contract dependencies, and version-sensitive syntax [VERIFY: link added; SME confirm]. AI suggestions for smart contract code are therefore often naive, missing design patterns such as access-control modifiers, reentrancy guards, or gas-saving patterns. Developers have to design the contract architecture themselves and treat AI suggestions as starting points.
When AI helps: ideas, explanations, and perspective
Brainstorming and conceptual assistance
AI chatbots and coding assistants are good at high-level explanations and at exploring alternative designs. An engineer can ask, "Explain the difference between upgradeable proxies and the diamond standard," and get a concise summary. A chatbot can propose different data structures or point to established libraries, though it is limited by its knowledge cutoff in a space that moves quickly. This kind of use draws on the model's broad knowledge without handing it responsibility for correctness.
Prompt engineering and context
The quality of code generation tracks the quality and specificity of the prompt. A GitHub guide on prompt writing notes that developers have to supply detailed context: the problem domain, existing code patterns, implementation constraints, and specific file references. A vague prompt like "create a user authentication system" yields generic output, while a prompt that specifies JWT-based authentication, database integration, and middleware structure produces something more relevant. For smart contract development that means stating the Solidity version, the target standard (ERC-20, ERC-721, and so on), the required access-control patterns, and the invariants. Without that context, AI suggestions can misread the requirements or generate insecure patterns.
