一位開發者在Hacker News上發帖傾訴，稱使用AI編寫代碼是一場噩夢。AI過度聚焦當前任務，對更改是否破壞系統其他部分漠不關心，長上下文等同於即時腦損傷。這一帖子引發了數十條討論。
多位開發者對此表示認同。有人指出，AI最令人痛苦的習慣是只添加代碼而非修改或刪除現有代碼，導致文件中充斥著addData、addDataNew、addDataForAddData這樣的重複函數。AI生成的代碼往往缺乏對現有系統的理解，無法復用正確的抽象，也無力承擔變更後的完整調用鏈。
一位開發者將AI比作過度防禦性編程的典型，經常添加不必要的tryexcept塊來掩蓋本應暴露的錯誤。還有開發者描述了AI編碼的生產力悖論：啟動一個任務後等待3到5分鐘，再啟動下一個再等待，這種循環不足以讓人真正投入工作，卻打斷了深度思考的流程。
針對這些問題，社區總結出多種應對策略。首先是計劃先行：讓AI掃描項目並創建實現計劃的markdown文件，在新會話中讓AI按照計劃執行，而非一次性要求它解決問題。其次是規則約束：在AGENTS.md文件中定義架構不可妥協的規則，要求AI在標記任務完成前必須運行測試。第三是上下文管理：使用具有100萬token上下文窗口的模型，或將會話拆分為規劃和實現兩個階段，將掃描階段的上下文壓縮到單個文件中。
有開發者引用了Anthropic的一項研究，該研究將開發者分為輔導加手寫代碼組和AI最大化組，發現前者在速度和系統理解方面表現更好，且成本更低。不過也有人指出，該研究的對象是初級開發者，樣本數較小，最有成效的AI使用方式可能是資深開發者利用AI加速工作流，同時仔細審查輸出。
一位開發者總結道，LLM的好壞取決於訓練數據中代碼庫的平均質量。如果將AI當作放手不管的開發者，從流程中移除人類，得到的就是代碼泛濫。但沒有人強迫我們這樣使用它，速度的減慢恰恰是將人類專業知識和判斷力融入其中的必要代價。當LLM準備好讓人類退出循環時，我們會知道，因為那時我們都會失業。在此之前，我們的角色是充當質量瓶頸，而不是打開閘門。
（示意圖）
Hacker News社區正在討論一種「新型人機分工」模式，規劃出一個未來趨勢——「AI負責做不完美的 reference design（參考設計），人類負責真正的工業級落地」。
