**耶穌，掌管方向盤。 🚗
還有 Github Copilot，使用 IDE。 💻**
Github 表示，92% 的美國開發者都在使用 Copilot。
什麼。嚴重地？
什麼時候聽過 92% 的人口使用單一事物？
當然，除非…你說全世界100%的人都消耗過一氧化二氫。
（這條線只有一種變黑的方式。不要去那裡。👀）
和我一起快速旅行，我將談論：
🔥 當機器在 2024 年佔領世界時
經過谷歌快速搜尋後，似乎大多數開發人員都在使用人工智慧輔助來編寫程式碼。如果我說我根本沒有使用人工智慧來編寫程式碼，那我就是在撒謊。當然，我有。我並不住在岩石下。
我發現開發人員對與第三方雲端服務共享程式碼相關資料的想法感到奇怪，這些第三方雲端服務通常沒有 SOC2（或類似的東西）認證，並且充其量只能做出模糊且無法證明的隱私聲明。
Github Copilot（和 Copilot 聊天）、Bito.ai 以及 VS Code 市場上的其他幾個 AI 程式碼擴充的安裝量已超過 3000 萬。瘋狂的！ 🤯
然後是我。我還沒有將人工智慧輔助納入我的常規程式碼工作流程中。當然，我有幾次在 GPT 的幫助下編寫了一些樣板檔案。但那些時候是個例外。像 Github Copilot 這樣的東西，或任何類型的程式碼審查、程式碼產生工具、PR 建立或提交協助，都不屬於我的 IDE 或 CLI 流程的一部分。
也許它會隨著時間而改變。我們拭目以待。
“但為什麼？”
😟我真正擔心的是
答案很簡單。 👇
1.我擔心我的程式設計技能會生疏
我擔心如果我太習慣人工智慧的幫助，我編寫和閱讀程式碼的方式將會受到影響。
我擔心我會開始忽略程式碼中的缺陷，否則我可以發現這些缺陷。
我將開始認為人工智慧產生的程式碼是理所當然的。
尋找 API、內建方法或其他文件將開始變得像一件苦差事。
我擔心……我會開始滑倒。
2. 我不願意與第三方服務分享我的所有程式碼
公司可以非常聰明地從你提供的資料中推斷出一些事情。有時他們會知道你的家人不知道的事。
敏感的業務邏輯可能會洩漏給第三方服務，最終可能會被用來做出我不滿意的推論，或者只是…直接洩漏？我的意思是，軟體總是被駭客攻擊。
我認為我很合理地認為我不想以不受限制的方式向第三方公司公開像程式碼這樣敏感的東西。即使那家公司是微軟，因為即使他們也搞砸了。
👀 從經驗豐富的開發人員的角度來看
這也不是我獨有的想法！
1. 經驗豐富的開發人員往往不想依賴「拐杖」來寫程式碼。
我甚至很高興與不想在 IDE 上使用彩色主題的高級開發人員合作，因為他們認為這會損害他們掃描、閱讀或偵錯程式碼的能力！ （這對我來說也有點太多了）
畢竟，「程式設計技能」不僅僅是編寫程式碼。
2. 老開發者看過各種軟體被駭、資料外洩等。
我的意思是，十多年來， haveibeenpwned.com每年都會向您發送有關您的憑證、電子郵件和其他資料外洩的電子郵件…很多時候來自價值數十億美元的公司…
當你無數次聽到「當你不為產品付費時，你就是產品」 ，然後又得到另一家將資料出售給第三方的公司的支持...
是啊……會很累。
只需斷開盡可能多的電線即可輕鬆回到石器時代。
“老開發人員”？我是……我變老了嗎？
不，我才 22 歲，現在已經是 2016 年了……對吧？正確的？
順便說一句，標題中問題的答案是👆這個。恭喜！貼文結束了！轉到下一個…
Buuuuut…如果你想繼續閱讀…
🚶 讓我們退後一步......
我認為我的擔心可能被誇大了。
現在讓我們把整個資料隱私的角度放在一邊，因為這本身就是一個我非常熱衷的另一個主題。
我個人沒有足夠的資料來經驗說使用人工智慧輔助會帶來我擔心的厄運……它會將我從今天的樣子降級為SDE1 。
但我已經看到了模式。
我見過人工智慧生成的低於標準品質的程式碼經過程式碼審查並最終出現在
main分支上。我見過一些函式庫函數在沒有正確理解存在什麼或存在什麼替代方案的情況下被使用，只是因為LLMs產生了它。
我什至見過為解決某個問題而生成的程式碼，對於該問題，程式碼庫中已經存在一個實用程式函數，但沒有使用它，因為知道這個實用程式的存在比要求GPT 為您生成它要多得多的工作。
💎 ~~鑽石是~~ 糟糕的程式碼是永遠的
“等一下……我以前看過這部電影！”
LLM 是一個相當新的事物…但是💩程式碼是永恆的！
每一個。單身的。開發。曾經。在沒有完全理解或尋找替代方案的情況下使用了函式庫函數。你和我都對此有罪。 （什麼？您認為
Array.prototype.sort是對任何內容進行排序的最佳方式？在大多數情況下它就足夠了！）一段邏輯總是被重新發明（重新複製貼上）！只是之前它來自StackOverflow ，現在它來自 ChatGPT 。
🤷 那麼，有什麼好大驚小怪的呢？
“使用 ChatGPT 會讓我成為一個糟糕的程式設計師嗎？”
我想不是。
重點是您只需要關心您建立的內容。
為您所建造的東西感到自豪。
🤖 LLM/AI 到底適合什麼？
LLM 本身並不是邪惡的。
事實上，如果負責任地使用它們，它們會非常有用：
品質程式碼：LLMs可能會處理不太勤奮的開發人員不會考慮的邊緣情況。
綜合測試：LLMs可能會編寫比某些開發人員編寫的測試更全面的測試。
綜合類型：它甚至可能比普通開發人員自己編寫的類型或可能具有編寫技能的類型更「完整」地編寫類型。
然而，開發人員有責任確保程式碼輸出受到保護和良好監控。一個不在乎的人在歷史上的任何時候都會做得很糟糕。LLMs的存在並沒有改變這一點。
😎 真正給予 a*ck 的藝術
有很多開發者對此並不關心。
但你不是這樣的開發者。你確實關心。
否則你就不會在這裡開發並學習人們的經驗。
我最近寫了一篇關於新開發人員在職涯中應該關心什麼成長的文章。它不僅僅是程式碼。
https://dev.to/middleware/going-from-sde1-to-sde2-and-beyond-what-it-actually-takes-1cld
也許我會在 VSCode 中引入一些 AI。
我認為這只是時間問題，而不是是否有問題。
更重要的是……只要我關心確保我的程式輸出可讀、高效能、高品質且易於審查，我想我會沒事的，你也一樣。
👇 PS
如果您想要一個我非常關心的範例，並且具有出色的程式碼 💪 和…不太出色的程式碼 🤣，請查看我們的開源儲存庫！
它可以讓您了解交付程式碼需要多長時間、PR 陷入審查循環的次數以及您的團隊交付程式碼的整體情況。
https://github.com/middlewarehq/middleware
原文出處：https://dev.to/middleware/why-i-dont-use-ai-as-my-copilot-47k3
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式