看到有人說，讓 Astra 去做消融實驗（把某個模組或者變數拿掉，看看整體表現會不會有影響）效果蠻好的。於是也試了一下。可惜我手上編程的任務實在不多，於是讓他試試看檢驗我的業務流程。同時我也讓 Fable 5.1 來做同樣的事情。
觀察結果還沒完全出來（業務流程跟交付有沒有受影響，是要等到走完一個循環才能看到的），但是很明顯的，Astra 就是非常不受控，會把業務流程刪掉一個人類都難以理解跟執行的程度；問題是老兄，這個流程是人來做不是機器做啊，我覺得看他剪完的東西心好累，根本不知道何從驗證起，我甚至懷疑他的思考根本目中無人，根本沒有要讓人插手的空間？
Fable 的表現就好很多，剪枝後的業務流程還是有實操性，我也比較能信任他所精簡的方案。可以明顯地感覺到他有在考慮到「我」的存在。
以上是非編程場景中，我的第一手觀察。
有人在程式碼側看到同一件事
後來在 X 上看到 tenobrus 的一串貼文，這段真的是有真的在用 Astra 處理業務的人才會得到的觀察（跟我的非代碼側觀察基本一致）：
Astra 有一個程式碼品質問題。
讓我說得更精確一點。Astra 可以寫出好的程式碼。但當它推斷自己處在一種「反正永遠不會真的有人去看這些程式碼」的情境時，它寫程式時就不會把人類讀者放在心上。它也不會以長期維護為考量。它似乎會寫出一種高度壓縮、像機器垃圾碼（machine slop）一樣的東西：只求用盡可能少的 token 解決眼前的問題，同時維持在 Astra 自己還看得懂的程度。
Astra 有一個獎勵駭取（reward hacking）問題。
我猜，當大量軟體強化學習（RL）環境只嚴格測試功能是否正確、結果是否達標，卻完全沒有任何針對程式碼品質的監控機制或獎勵訊號時，最後就會變成這樣。也許在過去幾代模型裡，最佳化壓力還沒這麼大，所以例如 Sol 即使認為根本不會有人閱讀它寫的程式碼，仍然會啟動它那個「寫出好程式碼」的模組，因為那基本上就是它真正學會而且擅長做的事情？
他也講到，Astra 已經歷過足夠多輪這種訓練：待在一個個小型封閉環境裡，由另一台機器來評判它，因此現在出現這種行為似乎也很自然。目前在處理既有程式碼庫時，他還沒有看到這類問題發生。但還是要留意。尤其是在從零開始的綠地專案（greenfield projects）中，一定要真的去看它寫出來的程式碼。即使你明確告訴它，你打算長期持續開發這個專案，它依然有一股非常強烈的傾向會把它拉向……這種做法。
然後他丟出一個很有意思的問題：這件事在多大程度上其實是對的？
當然，在這裡自己另外定義一個 random() 和 hash()，從來都不是什麼合理的做法。但是……我們對於「什麼才算是好的程式碼與好的軟體架構」的理解，有非常大一部分，其實都是建立在人類必須能夠理解程式碼，以及必須由人類進行長期維護這兩個需求之上。
現在這仍然是事實。但它未來是否還會一直成立，非常不明朗。而且我也完全無法確定：那些經過長期實戰驗證、對人類有用，而且符合人類使用習慣與直覺的程式設計方法，當模型的能力提升到超越人類的程度，並同時承受極大的最佳化壓力時，是否依然會是最有效、最合適的做法。
mitsuhiko 那邊則是抱怨得更直接：
我不知道 Astra 到底是從哪裡學 Python 程式設計的，但只要它寫的東西跟「一般正常的程式碼」稍微隔了一層、不是直接在常規程式碼情境裡工作，它就會開始寫出一些很奇怪的 Python 垃圾碼。
它寫的單元測試更是糟糕到令人難以置信。
一對活寶
Opus/Astra 可以說是一對活寶。前者不說人話，後者根本沒有考慮人的存在。
不過該用還是用。我現在正在讓 Astra 教教其他模型怎麼用 computer use 跟 chrome。
VulcanBench 新版
知名評測 VulcanBench 發布了他們新版評測集上，Astra 跟 Fable 的表現。結果顯示 Fable 在所有檔位上都明顯領先，但執行時間更久。
這一版的評測集最大的區別，是增加了代碼品質／可維護性的權重。