Trust, but Verify: Pair Programming with AI for Secure Smart Contracts

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.

‍

Designing secure contracts with AI assistance

‍

‍

1. Design first, then generate. Define the contract's goals, threat model, and invariants. Outline the functions, modifiers, and access control yourself, then use AI to draft implementations or documentation.
2. Review suggestions rigorously. Inspect every AI-generated fragment. Copilot's own documentation tells developers to follow secure coding practices and run code reviews, since suggestions can be insecure or incomplete. Cross-reference against established libraries like OpenZeppelin.
3. Avoid blind copy-paste. Pasting output you don't fully understand is easy and tempting. Confirm the logic matches your contract design, and have the model explain anything until it does.
4. Check for hidden vulnerabilities. AI-generated contracts often carry vulnerabilities, so run automated scanners (Slither, Mythril), AI-assisted analysis such as Nethermind's AuditAgent, and manual audits against them. AI on the verification side is held to the same standard as AI on the generation side: its findings are leads for human reviewers, not verdicts.
5. Keep the human in control. AI can suggest variable names and fill in basic functions, but only a person should decide whether a withdrawal function is external or public, or whether an upgradeable pattern fits. Judging context and anticipating economic attack vectors is still human work.

‍

‍

Testing with AI: efficiency vs. verification

‍

The promise and the pitfalls

‍

Generative AI can also produce unit tests. Researchers evaluating ChatGPT for unit test generation found that it often produces tests with compilation errors and incorrect assertions, though passing tests sometimes match human-written ones in coverage and readability. AI-generated tests can be "flat-out wrong," or can verify the current behavior of buggy code rather than the correct behavior, which is the verification versus validation trap. Because these models learn from public code, they reproduce its common bugs and antipatterns.

‍

Trust but verify in testing

‍

• Use AI to draft, not decide. AI can scaffold tests quickly, which raises coverage and saves time, but treat what it produces as a draft. Review the assertions against the specification rather than the current implementation.
• Validate edge cases yourself. AI-generated tests routinely miss boundary conditions and economic edge cases such as flash-loan sequences, rounding errors, and inflation. Those you add by hand.
• Avoid self-fulfilling tests. A model can write a test that asserts an error message that is itself wrong but happens to match the buggy code. Make the tests capture the intended behavior and revert conditions.
• Use AI for fuzzing and idea generation. A model can suggest unusual inputs you would not think of, which makes fuzzing more thorough. Paired with Echidna or Foundry's fuzzers, it speeds the work up.

‍

‍

Verification in the pipeline: AI auditing on every pull request

‍

So far we have treated AI mainly as a generator whose output needs checking, but the same technology works on the verification side. AuditAgent can be added to a CI/CD pipeline through GitHub Actions, so every push and pull request triggers an automated security scan that reports back within minutes, before the code merges. You will get false positives, and in our experience from audits that is less of a drawback than it sounds. Disproving a finding forces you to trace call paths and re-derive invariants at a depth that routine PR review rarely reaches, and that exercise has repeatedly surfaced adjacent issues the original finding never pointed at. Every so often the scan catches a genuine critical before deployment, which in this domain justifies years of triaging noise. The AI does not get the final word on whether code ships, but it guarantees that a tireless, suspicious reviewer looks at every change, and that a human thinks hard about its findings each time.

‍

‍

Cognitive offloading and developer skills

‍

AI reliance is a cognitive risk as much as a technical one, because it changes how we think. Research into cognitive offloading (outsourcing mental work to external aids) shows that while offloading improves immediate performance, it can weaken memory for the offloaded information, and participants who offload tasks tend to do worse on later memory tests. An MIT Media Lab study ("Your Brain on ChatGPT," 2025 preprint) reported that people who used ChatGPT to write essays showed the lowest brain engagement and underperformed on neural, linguistic, and behavioral metrics, leaning more and more on copy-and-paste Over time, overreliance can dull critical thinking and make it harder to recall what your own code actually does. The Harvard Gazette, reporting on that same study, framed the risk as "cognitive atrophy," a shrinking of critical-thinking ability. Use AI for ideation and speed, but keep your own mind in the design, problem-solving, and review, or you risk deskilling yourself.

‍

‍

Conclusion

‍

AI coding assistants are useful: they explain concepts, scaffold boilerplate, and draft tests in seconds. Smart contract development still demands a higher bar. Models trained on public code reproduce its insecure patterns, their Solidity exposure is thin, and the research record shows that generated contracts and tests cannot be trusted without scrutiny. Our approach is therefore trust but verify, and it applies to our own tooling as much as anyone's: AuditAgent speeds up vulnerability discovery, and its output still flows through human auditors. Use AI across the workflow, whether you are brainstorming contract designs, scaffolding functions, or generating tests, but never ship code without manual review, formal verification, and thorough testing [VERIFY: "formal verification" closing reference, confirm scope with FV team]. Keep the human in control and keep your own engineering judgment sharp.