即便AI程式碼能執行，我也拒絕它的理由

隨著實現速度越來越快，真正的瓶頸已經轉移到了審查AI生成的程式碼量上。我不僅指的是同事（及其智慧體）的拉取請求，也包括自己使用編碼助手後產生的差異。即使遵循良好的實踐——比如從計劃模式開始，將大任務分解成多個階段，交付小改動——在審查自己並未深入思考的程式碼時，我仍然會感到認知過載。

在編碼助手出現之前，當我接到一個任務時，我會先探索程式碼庫，思考不同的解決方案，進行實驗，然後才實現。這個過程可能需要花費數天時間來整合所有上下文。當我最終提交拉取請求時，信心更高，向同事解釋每個改動也更加容易。

我必須承認，即使有AI的幫助，完成大任務仍然需要數天時間。很多時候，我會拒絕AI做出的所有改動並重新開始。第一次會話和第二次會話之間的區別不在於LLM模型，而在於螢幕後面的人。有了更多時間來整合我試圖解決的問題，我可以引導智慧體走向更好的解決方案，而不是被它牽著走。

我越來越多地因為以下原因拒絕AI程式碼：當我無法用自己的話解釋這個方案時；當改動量比問題本身還大時；當它在證明需要之前就引入了抽象時；當它在本地能執行但讓系統更難理解時；以及當我更信任輸出而不是自己的理解時。

工程師們過快接受AI生成的改動並不罕見，這正是我主張在AI審查之外還必須有人工審查的原因。現實是，能執行並透過CI的程式碼仍然可能是糟糕的解決方案，而工程一直關乎實現適當、可擴充套件且可維護的方案。

我已經使用編碼助手一段時間了，儘管它們令人印象深刻，但仍然需要優秀的工程師引導它們走向優秀的解決方案。是的，編碼助手可以透過不止寫程式碼的方式來幫助完成這項任務，但這並不意味著它們已經能夠以可持續的方式自主完成。