一萬小時氛圍編程經歷：我對Reddit熱帖《我們如何在FAANG氛圍編程》的反應

最近Reddit上有一個關於在大公司生產環境中使用AI編程的熱門話題。

很多人說AI會犯錯誤。是的，這是真的。但他們只關注陰暗面而不是光明面。根據我自己的經驗，以及AI教父、諾貝爾獎得主Geoffrey Hinton的相似觀點，當前大型語言模型的架構是人類大腦的模擬器。

所以你可以看到AI就像你的同事。

就個人而言，在我的公司，我把AI用於一切：規劃、用戶研究、客戶支持、寫代碼和博客文章。我們還把AI用於你無法想像的事情，比如審查我們的日常工作和代碼審查。

我可以給你一個非常具體的例子。蘋果的App Store審核員經常對細節很瘋狂，隨意因為一些隨機的事情給我們拒絕。蘋果對App Store審核指導原則有非常隨意和不穩定的規則。他們有時會拒絕你，有時會通過，即使他們有擔憂，因為審核員是外包的，他們並不太在乎，但他們需要證明自己的價值。那麼我們作為工程師如何處理蘋果的隨意拒絕呢？

這很容易。現在100%可能。通常他們會因為一些隨機問題拒絕，比如"不能允許麥克風按鈕，它只能被繼續"，諸如此類的廢話。

由於他們所謂的隱私考慮或者可能是App Store體驗的穩定性，這是廢話。目前我們有一個更好的方法來處理App Store拒絕，基本上就是使用AI來修復他們提到的問題，同時保持我們應用的功能。我最近收到了關於Apple登錄支持和一些權限請求措辭的拒絕。AI可以在10分鐘內修復這些問題，然後我在另外10分鐘內提交到App Store進行處理。所以最終變成等待App Store人工審核幾個小時或幾天，這很糟糕，對吧？

這實際上就是我在微軟做全職專業人員時的生活，也是因為各種隨機的事情。有時是一個非常重要的客戶，有時請求來自我的經理、副總裁，甚至CEO。

你不會相信這一點：大多數軟件工作任務都不那麼有價值。我認為只有10%甚至1%是真正有價值的、真正有創意的。其他99%都是垃圾。

例如，蘋果建立他們的審核指導原則就像繁文縟節，不是為了任何東西，只是為了證明App Store的價值。我相信如果沒有iOS App Store，如果人們可以在他們昂貴的設備上安裝任何他們想要的東西，這個世界會好一萬億倍。

那麼為什麼我們要浪費生命使用AI來解決這種垃圾問題？為什麼我們不能把這種事情外包給AI？就去做吧。你不需要任何人的許可來使用AI。

原始內容：

# 我們如何在FAANG氛圍編程。

嘿，朋友們。我想在這裡發佈這個，因為我看到很多來自那些不相信AI輔助編程可以用於生產代碼的人的抨擊。這根本不是真的。

為了一些背景，我是一個有超過十年經驗的AI軟件工程師，其中一半時間在FAANG或類似公司。我職業生涯的前半段是系統工程師，不是開發者，儘管我已經編程大約15年了。

無論如何，這就是我們開始如何使用AI進行生產代碼。

1. 你總是先從技術設計文檔開始。這是大部分工作發生的地方。設計文檔開始時是一個提案文檔。如果你能讓足夠的利益相關者同意你的提案有價值，你就可以繼續發展系統設計本身。這包括完整的架構、與其他團隊的集成等。

2. 在啟動開發工作之前進行設計評審。這是讓你的團隊設計文檔被高級工程師徹底審查的地方。這很好。我認為這是在前期承擔痛苦。

3. 如果你通過了評審，你現在可以啟動開發工作。前幾周花在為將由個別開發團隊構建的每個子系統做更多文檔。

4. 積壓開發和衝刺規劃。這是開發人員與產品經理和技術項目經理合作，敲定個別開發人員將要處理的離散任務和順序。

5. 軟件開發。最後，我們現在可以開始鍵盤上手，開始處理任務票據。這是AI成為力量倍增器的地方。我們使用測試驅動開發，所以我讓AI編碼代理首先為我將要構建的功能編寫測試。只有然後我開始使用代理來構建功能。

6. 代碼提交評審。我們有一個兩個開發人員批准流程，然後代碼才能合併到主分支。AI在協助評審方面也顯示出很大的前景。

7. 在暫存中測試。如果暫存良好，我們推送到生產。

總的來說，我們看到從功能提案到它投入生產的速度提高了約30%。這對我們來說是巨大的。

TL;DR：總是從紮實的設計文檔和架構開始。從那裡分塊構建。總是先寫測試。