AI編程命門浮現，大批開發者居然會不審查代碼

在此次AI浪潮下，程序員是否會像畫師一樣大批失業，已經成為了這兩年前程序員社區里的熱點話題。但在兩年之后，許多程序員不僅不擔心AI可能會取代他們，反而一個個都化身為AI的忠實粉絲。如今Cursor、GitHub Copilot、CodeWhisperer、Trae等AI編程工具已經成為了大量程序員日常工作中的一部分，可是用AI寫代碼真的就沒有代價嗎？

日前，一份由軟件供應鏈平臺Cloudsmith發布的報告，就揭示了AI在代碼生成領域的迅速普及所帶來的影響。在這份報告中顯示，使用AI的開發者中有42%的代碼是由AI生成，其中16.6%的開發者依賴AI貢獻大部分代碼，甚至有3.6%代碼完全是由AI生成。

這一報告中同時還指出，AI生成代碼的背后也存在隱憂，開發者普遍擔憂AI可能會加劇開源惡意軟件的威脅，有79.2%的受訪者認為AI將增加環境中惡意軟件的數量，其中30%認為威脅將顯著上升。此外值得一提的是，Cloudsmith發現有超過1/3的開發者沒有在每次部署前審查AI生成的代碼，從而導致大量未經審查的代碼被直接部署在生產環境。

AI編程工具被程序員群體快速接納，乃至對其出現盲目信任的原因其實也很簡單，因為“敏捷開發、快速迭代”是科技公司的生命線，“效率就是生命”更是成為許多科技公司高管的座右銘。而AI編程就是一個效率放大器，它們像是24小時不休息的編程伙伴，可有效加快開發進度。

以“通義靈碼”為例，阿里方面是這樣介紹它的，在傳統開發模式下，程序員每天需要耗費大量精力編寫重復性代碼、調試優化、編寫代碼注釋，這些工作大幅擠壓了核心業務代碼編寫的時間，有了通義靈碼作為“代碼助理”，開發者就能從編寫代碼的繁瑣工作中解放出來，使得他們能夠專注于更具創造性的工作，例如設計更高效的算法、解決復雜的技術問題、開發新的產品。

大家不妨想象一下，作為一位開發者，如果你有一個24小時在線的編程助手，它能理解自然語言描述，并幫你寫出高質量的代碼，還能解釋復雜代碼的邏輯，甚至幫你debug，那么你又有什么理由不喜歡它呢？其實Cursor、CodeWhisperer被大規模應用是有現實基礎的，因為它們確實成為了程序員的“免費牛馬”。

可問題是，如今大量的程序員似乎對于AI的信任度過高。事實上，早在去年夏季，也就是Claude 3.5 Sonnet等一批高性能AI模型發布，讓使用Claude 3.5的Cursor開始有了可用性之后，HakerNews、Reddit就同步出現了一批吐槽AI代碼的帖子。

其中就有開發者表示，在他為客戶解決技術問題的過程中發現，有相當多的BUG源于客戶使用了AI編程工具直接生成的代碼。由于AI幻覺的存在，AI編程工具就會出現各種低級錯誤，例如訪問不存在的端口，或是試圖從不存在的API中讀取數據。

由于AI的幻覺問題導致AI生成的代碼也會有BUG，但AI本身的高技術屬性極具迷惑性，很容易就讓使用者盲目相信AI的輸出。更重要的是，程序員使用AI編程工具是為了提升效率，這就意味著他們在使用AI編程工具時往往缺乏debug的意識。因為代碼校驗不僅是對數據和來源的核查，還包括了編程思路的審查。

如果AI生成的代碼還需要人工來核校，又與“重復造輪子”有什么區別呢？正是秉承著這樣的認識，一大批AI生成的代碼在未經開發者審查的情況下，就被部署到了生產環境中。如此一來，一個更嚴重的問題就浮出了水面，那就是AI究竟能不能擔責？

顯而易見，如今業界的共識是AI不擔責，那么一旦出現問題就只能是使用AI編程工具的程序員承擔責任了。所以只需要有一次AI編寫的代碼導致嚴重BUG，給相關企業造成重大損失，AI編程工具的熱潮可能就會結束。

從某種意義上來說，如今部分程序員對于AI編程工具的認知，出現了矯枉過正的情況。以當前的技術水平，AI編程工具更像是智能輔助駕駛中的“人機共駕”，絕不能排除人類的存在，它只能成為一個代碼補全工具，而非純粹的代碼生成工具。

【本文圖片來自網絡】