【新智元導讀】100%是用Codex寫的。還有內部爆料說,Codex讓他們僅用三天時間就搭出了伺服器,三周就發佈了APP。人類程式設計師,真的要退出歷史舞台了?
矽谷的空氣裡再次充滿了躁動,而這一次的震源中心,回到了OpenAI。
OpenAI的奇點時刻,也要來了?
就在剛剛,X被一條爆料徹底刷屏——
Codex,已經正式接管了OpenAI研究員「Roon」100%的程式碼編寫工作!
Roon發出了感慨萬千的宣告:
程式設計一直很痛苦,然而卻是必經之路。我很高興,它終於結束了。
我驚訝於自己竟然這麼快就擺脫了程式設計的陰影,而且一點都不懷念它。甚至我有點遺憾,從前的電腦為什麼不是這樣的。
早在去年12月,Claude Code之父Boris Cherny就曾投下一枚震撼彈——
自己對Claude Code的貢獻100%都是由Claude Code完成的。
這一「套娃式」的自我進化,直接引爆了矽谷的自動編碼狂潮。
面對如此巨大的蛋糕,OpenAI顯然不會拱手相讓。
如今,反擊已經開始。
在剛剛過去的周末,Sam Altman已經公開預告:接下來一個月會發佈一堆關於Codex編碼模型的新產品。
社區的風向也開始發生微妙的轉變。
一些資深開發者評論道:在90%的情況下,GPT-5.2-Codex都能一次性完成我提出的請求。
Claude雖然不錯,但它偶爾會偷偷插入「壞程式碼」;相比之下,OpenAI的新方案更像蘋果——主打一個開箱即用。
看來,Codex和Claude Code的大戰,已經一觸即發!
OpenAI研究員Roon的這個爆料,也讓網友們直言:AI終於到達了這個奇點!
看來,人類直接手寫程式碼的時代,真的結束了。
經過多年的模型迭代與資料積累,我們似乎真的站在了一個臨界點上:
人類直接手寫程式碼,正在變得不再有任何意義,甚至是一種效率的浪費。
在Roon的評論區,人們開始集體對程式設計時代說再見。
是的,我熱愛電腦,熱愛軟體開發,對我而言,程式設計只是實現目標的手段,僅此而已。
複雜的語法只是是我們為了讓邏輯得以執行而必須付出的昂貴代價。
如今,這些中間商終於可以退場了。
激進的觀點開始湧現。
甚至有人建議,既然不需要人類閱讀程式碼了,我們就該讓模型跳過人類可讀的彙編語言,直接使用機器程式碼。
今天的程式設計就像曾經的打孔卡一樣,應該永遠消失了。
與此同時,另一個炸裂的消息從OpenAI內部流出——
一位研究員爆料,在Codex的輔助下,他們僅用了三天時間,就從零搭建了OpenAI的MCP伺服器,並完成了規模驗證。
不僅如此,他們還在3周內推出了Sora的Android應用;此外,還有一大波由Codex建構、甚至由Codex自我稽核的內部工具正在排隊上線。
如果沒有Codex的話,很難想像OpenAI能以如此驚人的速度發佈產品。
有趣的是,這位大佬似乎還玩起了Claude Code之父的梗:
過去30天,我花了大量時間稽核Plan和PR,幾乎沒寫一行程式碼!
有人評價,這正是「起飛」第一階段的樣子。
而下一步,或許就是真正的端到端AI自主研究。
還有人問,確定你們這不是行銷?
這位研究者詳細解釋說,絕對不是。
具體的使用過程是這樣的:
首先,他會花很多時間來撰寫規格說明,並在腦海中構想輸出應該是什麼樣子。
然後,會啟動一個「4×Codex」的雲端並行任務。這樣不僅可以一次性看到多種不同的變體,也能補上自己一開始遺漏的細節。
接下來,就是讓Codex自己發揮。等它跑完,人類再介入進行測試和驗證。
既然「人機協作」的範式已經改變,那麼承載這種範式的工具自然也要升級。
面對Anthropic在的步步緊逼,OpenAI顯然有備而來。
就在今天,Codex CLI連續推送了兩次更新,版本號直接來到了0.91.0。
其中,Codex 0.9.0帶來了最受大家期待的功能——Plan Mode(計畫模式)!
Code模式是Codex的默認體驗,它的工作方式和其他AI智能體一樣。
這點咱們就不多費口舌了。
但Plan模式則完全不同,它將程式設計任務拆解為兩個截然不同的階段:
第一階段:理解意圖(明確目標、劃定範圍、識別約束條件、制定驗收標準)
第二階段:技術規格(生成決策完備的實施方案)
在這種模式下,輸出的內容非常詳盡,無需任何後續追問即可直接執行。
Plan模式最聰明的地方在於:它堅持「證據優先探索」。
在開口問問題之前,Codex會先在你的程式碼庫中進行2次以上的針對性搜尋,檢查配置、Schema結構、程序入口等。
此外,Plan模式還可以呼叫全套工具:
它可以(並且將會)呼叫各種技能、子智能體和後台終端,從而建構高層級的實施計畫。
當Codex確實需要你輸入時,它是結構化的,而且只有關鍵且聚焦的問題:
· 儘可能提供選項
· 總是包含一個推薦選項(對新手極其友好)
· 只問那些會實質性改變計畫的問題
為了實現這一互動,它利用了新的request_user_input工具。
這個工具會暫停執行流程,拋出一道有針對性的多項選擇題,並支援你在選擇時補充反饋或上下文。
更貼心的是,一旦它在任何時候檢測到歧義,尤其是當你在引導它時指令模糊,它會立即停下來確認,而不是盲目執行。
現在,開發流程變成了這樣:
使用者請求一個計畫 -> AI研究程式碼庫與規劃 -> 針對性詢問使用者 -> AI完善並完成計畫 -> 提示是否執行?
看起來完美無缺,對吧?Codex負責思考,Codex負責執行,Codex負責填滿你的GitHub。
但就在我們為這種極致的效率歡呼時,一個被忽視的深淵正在腳下裂開——
在這個新時代,最大的懸念不再是誰在寫程式碼,而是誰來稽核程式碼。
當AI火力全開,每天向倉庫甩出10+個PR時,人類開發者面臨的實際上是一場針對注意力的DDoS攻擊。
AI生成程式碼是毫秒級的,而人類理解程式碼上下文是分鐘級甚至小時級的。
這種「生產與審查的極度不對稱」帶來了兩個可怕的後果:
利益衝突顯而易見,但我們需要看透這一層。
Claude Code的創造者吹捧自己的工具天經地義——這是商業的本能。
但作為受眾,我們不能把「Demo裡的完美世界」當成日常。
畢竟,Demo不會展示偵錯三小時都找不到的競態條件,也不會展示由於上下文丟失導致的邏輯斷層。
除此之外,資料裡還藏著一個迷人的悖論。
Ars Technica曾報導稱,開發者對AI工具的使用量在漲,信任度卻在跌。
為什麼?因為AI正在跨越「恐怖谷」。
以前的AI程式碼爛得很明顯,現在的AI程式碼爛得很隱蔽——它引用了不存在的庫,或者在一個極其邊緣的Case上埋了雷。
人們用得越多,踩的坑越多,信得自然越少。
正如Jaana Dogan所警示的,我們正在面臨軟體工程「瑣碎化」的風險。
前者廉價如塵土,後者珍貴如黃金。
問題從來不是AI能不能寫程式碼,而是它寫的程式碼,是不是我們系統真正需要的,以及我們是否有能力維護它。
無論我們是否準備好,這個時代已經來了。對於不同的人群,這意味著完全不同的生存法則。
AI編碼工具不是「即將來臨」,它們已經破門而入。
問題在於,如何在不丟失自身核心價值的前提下整合它們。
技術大牛們依然在做那些艱難的思考工作,AI只是接過了「打字員」的工作。
如果你只會「搬運程式碼」,那你確實該慌了。
「技術工作」與「非技術工作」的邊界正在消融。
Claude Cowork這類工具創造了新物種。曾經需要開發者才能搞定的任務,可能很快只需要你能清晰描述出你想要什麼。
清晰描述需求的能力,將成為新的程式語言。
雖然OpenAI的研究員和Claude Code的創造者都在宣稱AI包辦了100%的程式碼,但請記住——
那是他們的實驗室環境,不是你的生產環境。
唯一可以確定的是,我們正在經歷從「寫程式碼」到「指揮寫程式碼」的不可逆的轉變。
而且,正在加速。 (新智元)