4 posts
AI 寫程式遵循一條驗證梯度。後端在毫秒內完成驗證。網頁端需要幾分鐘。行動端需要幾小時。回饋循環的速度與確定性直接決定了 AI 寫程式在各技術層的實際效果與可靠程度。驗證速度沿著光譜遞減，決定了 AI 編碼在哪裡能自主迭代、在哪裡必須仰賴人類的判斷。
AI 模型自己寫程式這件事本身並不有趣。有趣的是它生成程式碼之後發生的事：模型能以多快的速度知道程式碼是否正確？生成與驗證之間的回饋循環有多緊密？ 這個循環決定了一切。它決定了模型能否迭代自己的輸出，決定了人類能否在不手動檢查的情況下信任輸出，也決定了 AI 寫程式究竟在哪些領域行得通。…
AI 程式設計對能從任何混亂中恢復的精英團隊有效。其他人得到的只有恐懼、失敗的 CI，以及被放棄的實驗。差距不在於模型。
觀察兩個團隊使用同一個 AI 模型，你會看到兩種完全不同的結果。 第一個團隊向模型下達提示，要求構建一個畫面。輸出接近正確，但不完全對。樣式偏離了 Figma 檔案。狀態管理碰到了不該碰的檔案。建置在本機通過，但在 CI…
大多數團隊嘗試 AI 輔助寫碼，交付的程式碼未能通過 QA，然後放棄。問題不在模型，而在於缺乏讓 AI 輸出值得信賴的防護機制。
大多數嘗試 AI 輔助寫碼的團隊，走的是同一條軌跡。 他們一開始充滿熱情。模型在幾分鐘內生成一項功能，他們交付出去。QA 捕捉到一個錯誤，於是他們交付一個修復。QA 又捕捉到另一個錯誤，這次是在一個本該毫無關聯的 module 裡。那個修復牽涉了十四個檔案，然後 QA 又發現了另外三個問題。…
AI 程式開發工具擅長生成第一版。真正的工程挑戰從第四版開始——當團隊需要在不破壞其他一切的情況下修改某些東西。
每個 AI 程式開發的展示都遵循相同的弧線。有人對模型下達提示。一個能運作的應用程式就這樣出現了。觀眾印象深刻。 他們確實該如此。速度是真的。能力是真的。有 AI 參與時，第一版確實交付得更快。 問題是，第一版從來都不是困難的部分。 軟體工程的成本不集中在初始創建。它集中在第四、第五、第六次迭代：…