我對Vibe編程有點興趣，但如果你不懂常規編程，我不知道該如何進行Vibe編程。
我最喜歡 Claude 的程式碼。我覺得 Codex 的程式碼往往過於複雜，而且不太遵循具體的指示。
最困難的部分在於模型會編寫大量程式碼，其中許多都是冗餘且粗糙的（傳統意義上的粗糙）。但好處是，你可以輕鬆寫一百萬個單元測試。 （實際上，我從 gpt-3.5 開始就一直使用 LLM 來進行單元測試。）
這算是一種很有意思的模式。例如，在我一直在做的這個小玩具應用程式中，大約有 15 個地方會觸發應用程式滾動到某個元素。每個地方都編寫了完全相同的 7 行程式碼來執行此操作。而我的做法是…
我寫了一個名為 scrollToElement 的函數，然後在需要捲動到某個元素時呼叫該函數。但它無論滾動到哪裡，都只會重複執行相同的 7 行程式碼。它似乎沒有想到要重構這段程式碼。這顯然很糟糕。然而，
它似乎能夠毫無問題地根據需要修改這 15 段相同的程式碼，而且其行為經過了充分的測試覆蓋，即使漏掉了一段，測試也會失敗，它會找到錯誤並進行修復。這在美學上很糟糕，但功能足夠好。
直到我開始認真閱讀程式碼，我才注意到這個問題。通常來說，你會盡量避免像這樣重複程式碼（DRY 原則），因為它會引入脆弱性和 bug，但這裡似乎沒有出現這種情況。雖然這仍然很糟糕，但它也引出了一些有趣的問題…
比如說，如果你遇到一個精力無限、能寫出無數程式碼的人，是不是稍微詳細一點的寫法比較好呢？我自己的許多做法都是出於一種美學偏好，即用盡可能少的程式碼實現盡可能多的功能，但這可能並不適用於LLM程式碼。
當然，這種模型不可能擁有無限的續航力。它需要花錢，而且實際上可能比我付的錢還要多。