在最近一集的Dwarkesh Podcast中，人工智慧研究員Andrej Karpathy（前 Tesla 人工智慧與 Autopilot Vision 總監）分享了他關於 AI 輔助編碼的經驗和觀點。他所討論的內容引起了我的共鳴 —— 許多程式設計師會認同他所描述的相同緊張關係和權衡。

下面我將介紹 Andrej 的主要觀點（如果您好奇，也可以查看完整的訪談）。

程式設計風格

Andrej 描述了當今三種廣泛的編碼方法：

• 老派的 scratch 模式：完全手動編寫所有內容，完全忽略 AI 工具。

• 具有自動完成功能的混合模式：您編寫主要的邏輯，但依靠自動完成或 AI 建議來處理樣板程式碼。您仍然確切地知道事情應該如何運作 —— AI 只是幫助實現一些細節。

• Vibe coding：您提示類似「請實現這個」的內容，並讓模型完成繁重的工作，然後按 Enter 鍵。

Andrej 將自己定位於第二種陣營：他自己編寫大部分邏輯，並在有意義時使用自動完成功能。

AI 輔助程式碼的優缺點

目前的人工智慧編碼模型擅長建立只是複製貼上的樣板程式碼。

人工智慧編碼模型也擅長網路上已有的東西。例如，如果您正在用 Go 構建一個 HTTP 伺服器，它可以幫助輕鬆建立基本的 HTTP 伺服器程式碼，因為這非常標準，因為這些模型已經在許多此類程式碼上進行了訓練。

人工智慧編碼模型降低了新語言的可訪問性。例如，如果您有一個非常熟悉的 Python 專案，並且想要在您不擅長的 Rust 中重新實現它（為了效能），那麼這非常適合編碼模型來提供幫助。

雖然編碼模型確實具有所有這些優點，但它們也存在一些缺陷。以下是 Andrej 分享的一些：

它們不斷誤解程式碼，因為它們的記憶體中有太多程式碼以某種方式執行操作，這可能不適用。一個例子

So the way to synchronize, so we have eight GPUs that are all doing forward backwards. The way to synchronize gradients between them is to use a distributed data parallel container of PyTorch, which automatically does all the, as you're doing the backward, it will start communicating and synchronizing gradients. I didn't use DDP because I didn't want to use it because it's not necessary. So I threw it out. And I basically wrote my own synchronization routine that's inside the step of the optimizer. And so the models were trying to get me to use the DDP container, and they were very concerned about, this gets way too technical, but I wasn't using that container because I don't need it, and I have a custom implementation of something like it.

編碼模型也喜歡弄亂樣式，有時它們太過於防禦。它們會建立大量的 try-catch 語句，而程式設計師編寫的程式碼已經具有安全的假設。這通常會導致非常複雜和混亂的實現。

它們偶爾也會使用已棄用的 API。還有一件令人煩惱的事情是，人們需要在需要的內容上輸入太多的英文，然後等待實現。

總體而言，Andrej 認為完全使用 AI 輔助編碼模型編寫程式碼並不是一個好主意。它們有好的部分，但仍然有很多需要改進的地方。