Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

📌 Constraint Decay：LLM 代理在後端程式產生中的結構脆弱性

隨著 LLM 代理在自主編程上的表現日益受到關注，工程師開始質疑：當需求從「功能正確」轉向「必須遵守架構、資料庫、ORM 等結構限制」時，這些模型到底能夠穩定到什麼程度？

🤔 功能正確卻結構任意：現有基準常見的盲點

多數程式碼生成基準只測試端到端行為是否符合預期，鮮少檢查是否同時符合後端系統的結構約束（例如特定的 MVC 架構、資料表關係或 ORM 映射）。這意味著一個在功能測試上通過的解決方案，可能在實際專案中因違反結構規則而無法直接使用。

🧪 統一 API 契約下的 80 個 greenfield 與 20 個 feature 任務，橫跨八個 Web 框架

研究設計採用統一的 API 合約作為基線，在 80 個從零開始的後端產生任務與 20 個功能實作任務上進行評估。任務涵蓋八種常見的 Web 框架，以端到端行為測試與靜態驗證器雙重方式衡量模型對結構約束的遵守程度。

結構需求累積導致顯著效能下降：平均失分 30 點

當結構約束從寬鬆逐步收緊至完整規格時，具備較佳基線表現的代理配置在斷言通過率（assertion pass rate）上平均下降約 30 點；較弱的配置則表現更糟。這種「約束衰減」（constraint decay）表明，結構複雜度是影響 LLM 代理後端代碼品質的關鍵因素。

💡 結構約束的遵守並非自動隨功能正確而提升

結果顯示，僅保證功能正確的基準無法預測模型在實際後端開發中的表現。要讓 LLM 代理在生產環境中可靠，必須專門測量並訓練其對架構、資料庫 schema、ORM 映射等非功能需求的遵守程度。

⚠️ 研究僅靜態驗證與端到端測試，未涵蓋執行時行為或長期維護

評估方式侷限於靜態驗證器與行為測試，未探討生成代碼在執行時的效能、錯誤處理或後續修改的難度。此外，論文未提供開源工具包，限制了社群直接複製或擴展實驗的能力。

🎯 在產品化 LLM 代理前，先測結構約束而非僅看功能

• 在採用 LLM 產生後端程式碼前，應納入結構驗證步驟（例如靜態檢查、schema 比對）。
• 考慮在訓練或提示階段加入結構約束的明確指示，以減少約束衰減的影響。
• 將結構合規性視為獨立的評估指標，與功能正確度並行追蹤。

🔗 論文連結
📝 Constraint Decay: The Fragility of LLM Agents in Backend Code Generation
👤 Francesco Dente , Dario Satriani , Paolo Papotti
🔗 https://arxiv.org/abs/2605.06445

你在使用 LLM 產生後端程式時，是否也遇過「功能通過但結構失敗」的情況？歡迎在留言區分享經驗 👇

#LLM #CodeGeneration #SoftwareEngineering #ConstraintDecay #AI #Backend #HackerNews