How I Use AI Tools as a Web3 Developer

It’s been about a year since I started integrating AI tools seriously into my development workflow. I resisted for longer than I should have — partly scepticism, partly the classic developer ego thing of “I should be able to figure this out myself”. Eventually I caved, and I have thoughts.

What Actually Helps

Boilerplate and scaffolding. Asking an AI to generate a basic ERC-721 contract or a standard API handler is genuinely useful. Not because I can’t write it, but because starting from a skeleton and modifying it is faster than starting from a blank file every time. The generated code is usually sensible enough to be a good starting point.

Explaining unfamiliar code. I work with a fair bit of code I didn’t write — open source contracts, legacy services, other people’s ABIs. Pasting a function and asking “what does this do and what should I watch out for?” saves a lot of time jumping between documentation tabs.

Writing tests. I dislike writing tests for obvious-behaviour functions. AI is surprisingly good at generating unit test cases, including edge cases I might have glossed over. I still review everything but the coverage improves noticeably.

What Doesn’t Work Well

Anything bleeding-edge or niche. If you’re working with a protocol that launched six months ago, or a new L2 with limited public documentation, the AI will confidently give you outdated or hallucinated information. This is dangerous in Web3 where a wrong address or incorrect contract ABI loses real money. I always cross-reference with official docs for anything chain-specific.

Auditing smart contracts. I have seen developers paste their Solidity into an AI and treat the response as a security review. Please don’t do this. AI can catch obvious patterns but it misses subtle re-entrancy issues, business logic bugs, and protocol-specific edge cases. Use proper auditing tools and if it’s going to hold real value — get an actual audit.

Architecture decisions. Great for tactics, not great for strategy. Asking “how do I implement this function” works. Asking “how should I structure this entire system” tends to produce generic advice that doesn’t account for your specific constraints.

My Current Stack

I mostly use Claude for code explanations and Go/Solidity generation, and GitHub Copilot for autocomplete while I’m typing. They serve different purposes and work well together. I turn Copilot off sometimes when I’m in “deep thinking” mode because the autocomplete starts to feel like it’s steering my thoughts rather than following them.

The Bigger Picture

I think the honest answer is: AI tools make the boring parts of development faster, which frees up time for the parts that actually require thinking. For Web3 specifically, the “require thinking” parts are non-trivial — the security surface is large and the cost of mistakes is high. So my approach is to use AI for speed on the low-risk stuff, and stay cautious on anything that touches user funds or sensitive logic.

It’s a tool. A pretty useful one. But it’s not a replacement for understanding what you’re building.

身為 Web3 開發者,我怎麼使用 AI 工具

距離我開始認真把 AI 工具融入開發工作流程,大概已經一年了。我抵抗了比應該更長的時間——一部分是懷疑,一部分是那種「這個我自己應該搞得定」的開發者自尊心。最後還是投降了,然後有些想法想記下來。

真的有用的地方

樣板程式碼與腳手架。 請 AI 生成一個基本的 ERC-721 合約,或標準的 API handler,真的很有用。不是因為我不會寫,而是從一個骨架開始修改,比每次面對空白檔案快多了。生成的程式碼通常夠好,足以作為起點。

解釋不熟悉的程式碼。 我工作中會接觸到很多不是我寫的程式碼——開源合約、舊系統、別人的 ABI。把一個函式貼進去問「這在做什麼,有什麼要注意的?」,省了很多在文件分頁之間跳來跳去的時間。

寫測試。 我不喜歡為那些行為很明顯的函式寫測試。AI 很擅長生成單元測試案例,包括一些我可能會略過的邊緣情況。我還是會全部看過,但覆蓋率明顯提高了。

效果不好的地方

任何很新或很小眾的東西。 如果你在用六個月前才發布的協議,或文件很少的新 L2,AI 會很有自信地給你過時或是幻覺出來的資訊。在 Web3 裡這很危險——一個錯誤的地址或合約 ABI 會導致真實的資金損失。任何跟鏈相關的東西,我都一定會對照官方文件確認。

智能合約審計。 我看過有開發者把 Solidity 貼給 AI,然後把回應當成安全審查的結果。請不要這樣做。AI 可以抓到明顯的模式,但它會漏掉微妙的重入攻擊(re-entrancy)漏洞、商業邏輯錯誤,以及特定協議的邊緣情況。用正規的審計工具,如果要放真實資金,就找真正的審計。

架構決策。 戰術問題問得很好,策略問題問得不太行。「這個函式怎麼實作」有用,「這整個系統應該怎麼設計」得到的往往是通用建議,沒辦法考慮你的具體限制。

我現在的工具組合

我主要用 Claude 來解釋程式碼和生成 Go/Solidity,用 GitHub Copilot 在打字的時候自動補全。它們服務不同的目的,搭配起來效果不錯。Copilot 我有時候會關掉,在「深度思考」模式的時候——因為自動補全開始感覺像是在引導我的思路,而不是跟著我走。

更大的圖景

說實在的:AI 工具讓開發裡那些無聊的部分變快了,這釋放出時間來處理真正需要思考的部分。對 Web3 來說,「需要思考的部分」並不簡單——攻擊面很大,犯錯的代價很高。所以我的做法是,在低風險的事情上用 AI 加速,在任何碰到使用者資金或敏感邏輯的地方保持謹慎。

這是個工具,一個相當有用的工具。但它不能取代對你在建構什麼的理解。