Vibe Coding Smart Contracts: Where AI Helps and Where It Fails

Vibe coding means describing what you want and accepting whatever the model writes, as long as it runs. For a landing page, that is a reasonable workflow. For a contract holding user funds, it is not.

AI models write plausible code. On-chain, plausible is the dangerous category: code that compiles and passes its own tests, then fails under conditions nobody described in the prompt.

Why contracts are a different environment

Deployed code is final. There is no hotfix. Upgradeable proxies exist, but they add their own failure modes, such as storage layout collisions and an admin key that becomes the new single point of failure.

Every public function is an attack surface. Anyone can call it, with any input, in any order, several times within one transaction. Flash loans give that caller large amounts of capital for the duration of the transaction at almost no cost.

Bugs are paid for in the asset itself. A bug in a web app crashes a page. A bug in a vault empties the vault.

A prompt describes intended behaviour. Security depends on unintended behaviour. Generated code breaks in the gap between the two.

Where generated code typically fails

Mixed eras. Models learn from years of public Solidity, much of it written for older compilers and library versions. The output can combine them: SafeMath on a compiler that already checks overflow, OpenZeppelin 4.x import paths in a 5.x project, authorization based on tx.origin. Some of this fails to compile. Some of it compiles and is wrong.

Manipulable prices. Ask for "the current token price" and a model will often read it from a DEX pool's reserves. A flash loan can move that value within a single transaction, which is how many oracle exploits have worked. The fix is a time-weighted or external oracle with sanity bounds. The prompt rarely mentions this, so the code rarely includes it.

Token assumptions. Generated code tends to assume every ERC-20 follows the standard. Not all do. USDT's transfer does not return a boolean. Fee-on-transfer tokens deliver less than the amount sent. USDC uses 6 decimals, not 18. Each assumption is a line of arithmetic that is correct for the test token and wrong in production.

Rounding direction. In vault share math, rounding decides who absorbs the remainder. Round in the depositor's favour and an attacker can extract value repeatedly. The ERC-4626 first-depositor inflation attack is the known example. A model will pick a direction. It usually won't tell you it made a decision.

Partial reentrancy protection. Most models add a reentrancy guard. Fewer account for read-only reentrancy, where another protocol reads your contract's state mid-transaction, while it is temporarily inconsistent.

Why the generated tests don't catch it

When one model writes both the contract and the tests, the tests share the contract's assumptions. Standard token, honest caller. Everything passes. Coverage looks good.

Useful testing starts from invariants: statements that must hold after any sequence of calls. A user can always withdraw what the accounting says they own. Shares never represent more value than the vault holds. Fuzzing and invariant tests, both supported in Foundry, then try to break those statements with random call sequences.

Writing good invariants requires understanding the protocol's economics. That is design work, and it has to be done by someone who understands the system. For the design side, see Common Smart Contract Design Mistakes and DeFi Protocol Security: The 7 Most Common Vulnerabilities.

Where AI earns its place

In the hands of an engineer who can verify the output, AI is a real productivity tool. Sensible uses:

• Scaffolding tests and deployment scripts

• Explaining unfamiliar code, such as a dependency or a protocol you integrate with

• First-pass review that flags candidate issues for a human to confirm or dismiss

• NatSpec comments and documentation

• Gas optimisation ideas, verified against benchmarks

The rule: the engineer owns every line. If nobody on the team can explain why a line exists and what it does with hostile input, it is not ready for mainnet, whoever or whatever wrote it.

At Base58, our in-house engineers write the code and answer for it. Where AI tools are used, they support that work.

What to ask a development team

A competent team answers these without hesitation.

• Who wrote the contracts, and can they walk you through every external call?

• Which invariants are tested, and how?

• Which non-standard token behaviours does the code handle?

• Where do prices come from, and what happens if that source is manipulated or stale?

• Is an independent audit planned, and is it in the budget? How Much Does Smart Contract Development Cost covers what that typically adds.