氛圍編碼是指透過提示大型語言模型（LLM），告訴它要建立什麼應用程式、試用後再提示修改，但完全不查看 LLM 所產生的任何程式碼。這種技術可供不具備任何程式設計知識的人使用。然而，所產生的軟體通常會出現維護性、正確性與安全性方面的問題，因此最適合用於針對有限受眾所撰寫的一次性軟體。

這個詞彙由經驗豐富的程式設計師 Andrej Karpathy 於 2025 年 2 月在 X 平台上的一篇文章中提出：

有一種新的編碼方式，我稱之為「氛圍編碼」，也就是你完全沉浸在氛圍中，擁抱指數級成長，並忘記程式碼的存在。這是因為 LLM（例如搭配 Sonnet 的 Cursor Composer）已經變得太強大。而且我只用 SuperWhisper 跟 Composer 對話，幾乎不用碰鍵盤。我會提出一些很蠢的請求，例如「把側邊欄的內距減少一半」，因為我懶得去找那段程式碼。我總是「全部接受」，不再閱讀差異內容。當出現錯誤訊息時，我只會直接複製貼上，通常就能修復。程式碼的規模已經超出我平常的理解範圍，我得花不少時間才能真正讀懂。有時 LLM 無法修復錯誤，我就只能想辦法繞過，或是隨機提出修改，直到問題消失。這對週末的一次性專案來說還不錯，但還是挺有趣的。我正在建立一個專案或網頁應用程式，但這其實不算真正的編碼——我只是看東西、說東西、執行東西、複製貼上東西，然後它大多都能正常運作。

-- Andrej Karpathy

氛圍編碼的核心重點在於 「忘記程式碼的存在」。這正是它發揮效用的關鍵，同時也是其限制所在。

自從 November Inflection 之後，許多程式設計師開始讓 LLM 撰寫所有程式碼，並表示可能再也不會直接撰寫任何一行程式碼。然而他們仍然關心這些程式碼，會進行審查並關注其內部結構。在這種情況下，他們並沒有忘記程式碼的存在，因此我將此稱為 代理式程式設計。可惜「氛圍編碼」這個詞彙真的很受歡迎，許多人用它來指代代理式程式設計。不過我認為，儘管出現快速的 語意擴散，仍值得嘗試將氛圍編碼與代理式程式設計的概念區分開來，因為兩者在使用方式與後果上都有所不同。

由於氛圍編碼者不查看程式碼，因此不需要具備程式設計技能，非常適合沒有程式設計知識的人為自己建立應用程式。有經驗的程式設計師也可能發現，這種方式對於快速開發一次性軟體或原型很有幫助。

氛圍編碼 仍然是新興技術，因此我們正在探索其限制，而這些限制會隨著模型及其 Harness 的複雜度變化而改變。這些限制確實帶來相當大的風險，特別是當氛圍編碼的軟體被廣泛使用或存取敏感資訊時。

或許最嚴重的風險在於安全性。LLM 本質上容易受到攻擊，因為它們為掠奪者提供了龐大的攻擊面。氛圍編碼的應用程式通常可能暴露敏感資訊，甚至是憑證，讓攻擊者深入組織的系統。即使是非程式設計師，也需要了解 致命三要素。

由於很少關注程式碼，氛圍編碼的軟體可能快速產生大量低品質的程式碼。這種程式碼即使對 LLM 而言，也會讓未來的修改與強化變得困難。雖然 LLM 能力的提升可能讓它能處理更大的「義大利麵條式程式碼」，但到目前為止，結構良好的軟體顯然對 LLM 也更有幫助。

LLM 以習慣幻覺化不正確的事實並自信地呈現而聞名。這種習慣也會讓它們建立行為不正確的軟體——而這些錯誤可能不會顯現給使用者。此外，LLM 的非確定性意味著，要求 LLM 強化某些軟體，很可能會讓它在不應因新請求而改變的程式碼部分引入錯誤。因此，我們應該對 LLM 產生的軟體抱持懷疑態度，它仍然可能有用，但我們需要了解其中的風險。

總體而言，氛圍編碼的軟體最適合用於僅供作者或了解並接受相關風險的密切合作夥伴使用的一次性軟體。對於更複雜、被更廣泛使用、且風險後果更嚴重的程式碼，不應採取「忘記」的態度。