TL;DR: Kami menjalankan setiap model pengkodean AI utama melalui pengujian dunia nyataSolusi Teknologi Mercury tugas pengembangan — front-end dan back-end. Peringkat: Fable > Kimi K3 > Claude Opus 4.8 > Grok 4.5 > Codex 5.5 > Kimi 2.7 > Claude Opus 4.6 > GLM 5.2 > MiniMax. Fable menang. Bukan karena ini model terbesar, tetapi karena ia memahami seperti apa "selesai" itu.
James di sini, CEO dari Solusi Teknologi Mercury. Dari kantor saya di Cyberport, Hong Kong — 17 Juli 2026
Saya menghabiskan dua minggu terakhir melakukan sesuatu yang seharusnya sudah saya lakukan berbulan-bulan yang lalu: menguji setiap model pengkodean AI utama terhadap pekerjaan nyata.
Bukan tolok ukur. Bukan LeetCode. Bukan "tulis fungsi Python untuk mengurutkan daftar." Pekerjaan nyata. Komponen React yang perlu menangani kasus tepi. Titik akhir API yang perlu terintegrasi dengan layanan pihak ketiga. Migrasi basis data yang tidak boleh kehilangan data. Hal-hal yang benar-benar rusak di produksi.
Inilah yang kami pelajari.
Metodologi: Tanpa Tolok Ukur, Hanya Pertempuran
Kami memberikan setiap model tugas yang sama:
1. Front-end:Bangun dasbor responsif dengan visualisasi data waktu nyata, penanganan kesalahan, dan kepatuhan aksesibilitas
2. Backend:Rancang API dengan batasan laju yang memiliki otentikasi, caching, dan penurunan yang elegan di bawah beban
3. Integrasi:Sambungkan keduanya dengan tipe TypeScript yang tepat, batas kesalahan, dan status pemuatan
Tidak ada yang memandu. Tidak ada "pikir langkah demi langkah" petunjuk. Hanya spesifikasi yang akan diterima seorang insinyur senior pada Senin pagi.
Kami mencetak pada empat dimensi:
• Kebenaran: Apakah itu berfungsi tanpa bug?
• Kelengkapan: Apakah itu menangani kasus tepi, atau hanya jalur yang bahagia?
• Pemeliharaan: Dapatkah insinyur lain membaca dan memodifikasi ini dalam enam bulan?
• Kecepatan: Berapa lama dari prompt hingga kode yang dapat dikirim?
Peringkat: Apa yang Menang dan Mengapa
1. Fable — Kuda Hitam yang Menyelesaikan "Selesai"
Fable menduduki peringkat teratas dalam daftar kami, dan sejujurnya, saya tidak melihat ini datang. Ini bukan model yang paling banyak dibicarakan. Ini tidak memiliki jumlah parameter terbesar. Tapi inilah yang dilakukan Fable lebih baik daripada siapa pun:itu memahami perbedaan antara "kode yang dikompilasi" dan "kode yang dikirim."
Pada tugas front-end kami, Fable menghasilkan batasan kesalahan tanpa diminta. Itu menambahkan kerangka pemuatan. Itu menyertakan label ARIA yang tepat untuk pembaca layar. Ketika kami meminta untuk back-end, itu membangun pembatasan laju dengan pemutus sirkuit dan strategi cadangan untuk ketika cache gagal.
Ini adalah model yang berpikir seperti insinyur senior, bukan junior yang baru saja belajar sintaksis.
Kecepatannya juga sangat luar biasa. Fable menyelesaikan rangkaian tiga tugas kami dalam 12 menit. Yang tercepat berikutnya adalah Kimi K3 dalam 18 menit.
Mengapa Fable menang: Ini menghasilkan kode siap produksi. Bukan kode demo. Bukan kode tutorial. Kode yang menangani kasus tepi yang hanya Anda pikirkan setelah pemadaman produksi pertama Anda.
2. Kimi K3 — Kuda Kerja yang Andal
Kimi K3 adalah model yang sebenarnya saya percayai untuk kode produksi. Ini tidak se"cerdas" Fable — itu tidak akan mengejutkan Anda dengan solusi elegan yang tidak Anda pikirkan. Tapi itu juga tidak akan mengejutkan Anda dengan bug.
Jendela konteks 1M adalah fitur pembunuh yang sebenarnya. Kami memberi makan seluruh basis kode kami (47K baris) dan memintanya untuk menambahkan fitur. Itu memahami pola, mengikuti konvensi, dan menghasilkan kode yang terlihat seperti ditulis oleh tim kami.
Di mana Kimi K3 bersinar: Tugas konteks panjang, refactoring kode warisan, mempertahankan konsistensi di seluruh proyek besar. Ini adalah model yang Anda inginkan ketika "berfungsi" lebih penting daripada "wow."
Pertukaran:K3 lebih lambat daripada Fable dalam tugas greenfield. Dibutuhkan waktu untuk membaca konteks, memahami pola, dan menghasilkan kode yang sesuai. Namun, waktu itu terbayar ketika Anda tidak sedang memperbaiki kegagalan integrasi misterius tiga hari kemudian.
3. Claude Opus 4.8 — Sang Teoretikus
Opus 4.8 adalah model terpandai di ruangan. Ia akan menjelaskan mengapa arsitektur Anda salah, menyarankan tiga alternatif yang lebih baik, dan menulis makalah putih tentang tradeoff-nya. Ini juga merupakan model yang paling mungkin untuk merancang endpoint CRUD sederhana menjadi sistem terdistribusi dengan event sourcing.
Masalah Opus: Ini terlalu berpikir. Diberikan tugas yang seharusnya memakan waktu 30 menit, Opus 4.8 akan menghabiskan 20 menit untuk dokumen desain, 15 menit untuk implementasi, dan kemudian menyarankan Anda untuk merombak seluruh basis kode agar sesuai dengan pola baru.
Ketika Anda membutuhkan penalaran mendalam — algoritma kompleks, keputusan arsitektur, analisis keamanan — Opus 4.8 tidak tertandingi. Ketika Anda perlu mengirimkan pada hari Jumat, itu menjadi beban.
Pemeriksaan realitas biaya: Opus 4.8 mahal. Seperti, "mungkin kita harus merekrut insinyur lain" mahal. Dengan harga $65,75 per 1000 tugas di papan peringkat Aider, ini adalah alat premium untuk masalah premium.
4. Grok 4.5 — Si Kecepatan dengan Catatan
Grok 4.5 cepat. Seperti, sebenarnya cepat. Itu menghasilkan tugas front-end kami dalam waktu kurang dari 8 menit. Kodenya berfungsi. Itu terlihat baik.
Tapi ketika kami menguji stres back-end — menyerangnya dengan permintaan bersamaan, mensimulasikan kegagalan cache, menguji kasus tepi — kode Grok mulai retak. Itu menangani jalur bahagia dengan indah. Jalur tidak bahagia? Tidak begitu banyak.
Grok adalah model untuk prototyping, bukan produksi.Jika Anda perlu memvalidasi sebuah ide dalam satu sore, Grok memberikan solusi. Jika Anda perlu tidur nyenyak mengetahui bahwa API Anda tidak akan gagal pada pukul 3 pagi, carilah tempat lain.
Faktor xAI:Integrasi Grok dengan data X/Twitter memberikannya keunggulan dalam konteks waktu nyata. Namun untuk pemrograman murni, keunggulan itu tidak diterjemahkan menjadi kualitas kode yang lebih baik.
5. Codex 5.5 — Sang Spesialis
Codex 5.5 adalah apa yang terjadi ketika Anda mengoptimalkan sebuah model untuk satu hal dan satu hal saja: generasi kode. Ini adalah pemrogram murni terbaik dalam daftar ini. Sintaksnya sempurna. Polanya idiomatik. Nama variabelnya benar-benar masuk akal.
Tapi tanyakan padanya untuk menjelaskan mengapa ia memilih pendekatan tertentu, atau untuk mempertimbangkan implikasi bisnis dari keputusan teknis, dan ia akan diam. Codex menulis kode. Ia tidak memikirkan kode.
Gunakan Codex ketika: Anda tahu persis apa yang Anda inginkan dan hanya perlu mengetiknya dengan cepat. Ini adalah autocomplete termahal di dunia — dan terkadang, itu persis apa yang Anda butuhkan.
Ekosistem OpenAI: Codex 5.5 bersinar ketika Anda sudah berada di dalam tumpukan OpenAI. Integrasinya dengan ChatGPT, keakraban dengan keluaran gaya GPT, API yang konsisten — ini adalah pilihan yang nyaman, bukan yang berani.
6. Kimi 2.7 — Veteran Solid
Kimi 2.7 adalah model yang kami gunakan sebelum K3 ada. Ini dapat diandalkan, konsisten, dan dapat diprediksi. Ini tidak akan membuat Anda terkesima, tetapi juga tidak akan merusak basis kode Anda.
Penilaian yang jujur: Jika Anda memiliki akses ke K3, tidak ada alasan untuk menggunakan 2.7. Jendela konteks saja (256K vs 1M) membuat K3 menjadi kategori alat yang berbeda. Tetapi untuk tim yang menggunakan rencana lama atau dengan integrasi warisan, 2.7 masih merupakan insinyur yang sangat kompeten.
Harga sudah tepat: Dengan $1,24 per 1000 tugas di papan peringkat Aider, Kimi 2.7 adalah juara anggaran. Ini bukan yang terbaik, tetapi ini adalah yang terbaik nilai untuk tim yang tidak membutuhkan teknologi terbaru.
7. Claude Opus 4.6 — Generasi Sebelumnya
Opus 4.6 terasa seperti pratayang dari kecemerlangan 4.8 tanpa penyempurnaan. Ini memiliki kecenderungan yang sama untuk berpikir berlebihan, tetapi dengan akurasi yang lebih rendah. Ambisi arsitektural yang sama, tetapi dengan lebih banyak bug.
Lewati saja. Jika Anda berada di ekosistem Anthropic, langsung saja ke 4.8. Jarak antara 4.6 dan 4.8 bukanlah peningkatan bertahap — ini adalah kelas model yang berbeda.
8. GLM 5.2 — Penantang Regional
GLM 5.2 adalah model terbaik yang belum pernah Anda dengar — kecuali jika Anda berada di China. Model ini menangani kebutuhan bahasa Mandarin kami lebih baik daripada model Barat mana pun, dan pemahamannya tentang ekosistem API lokal (WeChat, Alipay, DingTalk) benar-benar mengesankan.
Tapi untuk pengembangan umum? Ini baik-baik saja. Tidak hebat. Baik. Kode berfungsi, tetapi konservatif. Itu tidak akan menyarankan pola modern. Itu tidak akan mengoptimalkan untuk kinerja. Itu akan memberi Anda solusi yang dapat dikompilasi dan dijalankan, sekitar tahun 2022.
Sudut pandang Zhipu AI: GLM didukung oleh Zhipu AI, salah satu laboratorium LLM terkemuka di China. Untuk tim yang membangun untuk pasar China, kesadaran budaya dan regulasi GLM adalah keuntungan yang nyata. Untuk yang lainnya, ini adalah sebuah keingintahuan.
9. MiniMax — Pekerjaan yang Sedang Berlangsung
MiniMax berada di bagian bawah daftar kami, dan saya merasa buruk tentang hal itu karena tim jelas berusaha. Tapi berusaha tidak sama dengan mengirim.
Kode yang dihasilkan adalah... fungsional. Itu dikompilasi. Itu dijalankan. Tapi itu melewatkan kasus tepi yang ditangkap oleh model lain. Penanganan kesalahan sangat minimal. Tipe TypeScriptnya longgar. Ketika kami memintanya untuk merombak demi kinerja, itu membuat kode menjadi lebih lambat.
MiniMax mungkin akan sampai di sana.Tapi saat ini, itu belum siap untuk pengembangan produksi.
Lanskap LLM Tiongkok:MiniMax adalah bagian dari bidang yang ramai yang mencakup Qwen, DeepSeek, dan GLM. Dalam perusahaan itu, ia berjuang untuk membedakan diri. Selisih kualitas kode antara MiniMax dan DeepSeek-V3.2 (74,2% di Aider) sangat mencolok.
Pola yang Tidak Ada yang Membicarakan
Inilah yang paling mengejutkan saya: model terbaik bukanlah model terbesar.
Fable tidak berjalan dengan jumlah parameter terbesar. Kimi K3 bukan yang paling mahal untuk dioperasikan. Tetapi keduanya memahami sesuatu yang terlewatkan oleh model yang lebih besar: pengiriman adalah pola pikir, bukan kemampuan.
Model-model yang menduduki puncak daftar kami memiliki satu sifat yang sama: mereka menghasilkan kode seolah-olah orang lain harus memeliharanya. Mereka menambahkan komentar. Mereka menangani kesalahan. Mereka memikirkan kasus tepi yang hanya muncul pada pukul 2 pagi di hari Sabtu.
Model-model yang gagal? Mereka menghasilkan kode seperti wawancara coding — selesaikan masalah, lulus tes, lanjutkan. Itu bukan cara perangkat lunak bekerja. Itu cara perangkat lunak rusak.
**Prinsip Pengiriman:** Kode terbaik bukanlah kode yang paling cerdas. Itu adalah kode yang masih masuk akal ketika penulis aslinya sedang berlibur dan basis data produksi terbakar.
Apa yang Dikatakan Benchmark (Dan Mengapa Kami Mengabaikannya)
Saya menyebutkan bahwa kami tidak menggunakan benchmark. Tetapi saya memeriksanya setelah tes kami, untuk melihat apakah pengalaman kami sesuai dengan data papan peringkat.
Papan Peringkat Aider LLM (aider.chat/docs/leaderboards) menceritakan kisah yang menarik:
| Model | Skor Aider | Biaya per 1K Tugas | Gaya | |-------|-------------|-------------------|-------| | GPT-5 (tinggi) | 88.0% | $29.08 | diff | | o3-pro (tinggi) | 84.9% | $146.32 | diff | | Gemini 2.5 Pro (32k berpikir) | 83.1% | $49.88 | diff-fenced | | Grok 4 (tinggi) | 79.6% | $59.62 | diff | | DeepSeek-V3.2-Exp | 74.2% | $1.30 | diff | | Claude Opus 4 (32k berpikir) | 72.0% | $65.75 | diff | | Kimi K2 | 59.1% | $1.24 | diff | | Grok 3 Beta | 53.3% | $11.03 | diff | | GPT-4.1 | 52.4% | $9.86 | diff | | Claude 3.5 Sonnet | 51.6% | $14.41 | diff |
Pola: Model-model yang paling mahal (o3-pro seharga $146.32, Opus 4 seharga $65.75) tidak menjamin hasil terbaik. GPT-5 seharga $29.08 mengungguli keduanya. DeepSeek seharga $1.30 memberikan 74.2% — hampir menyamai 72.0% dari Opus 4 dengan biaya 1/50.
Pengalaman kami sejalan dengan ini. Fable dan Kimi K3 bukanlah model-model termahal yang kami uji. Tapi mereka adalah yang secara konsisten memberikan kode yang dapat dikirim.
Apa Artinya Ini untuk Tim Anda
Jika Anda sedang membangun perangkat lunak pada tahun 2026, berikut adalah saran saya:
1. Gunakan Fable untuk proyek greenfield.Ketika Anda memulai dari nol dan perlu bergerak cepat tanpa merusak segalanya, intuisi "insinyur senior" Fable tidak tertandingi.
2. Gunakan Kimi K3 untuk pekerjaan warisan.Jendela konteks 1M berarti ia benar-benar dapat memahami basis kode Anda yang ada, bukan hanya menghasilkan kode baru yang mengabaikan konvensi Anda.
3. Gunakan Opus 4.8 untuk keputusan arsitektur.Ketika Anda merancang sistem yang perlu diskalakan, ketika keamanan penting, ketika Anda membuat taruhan teknis senilai jutaan dolar — kedalaman Opus layak untuk dipikirkan secara berlebihan.
4. Hentikan penggunaan segala sesuatu yang lain untuk produksi.Grok untuk prototipe. Codex untuk pelengkapan otomatis. Tetapi jangan kirim kode mereka kepada pengguna tanpa tinjauan serius.
5. Pertimbangkan persamaan biaya.Di Mercury, kami menjalankan beberapa model secara paralel untuk tugas-tugas kritis. Biaya menggunakan Kimi K3 ($1,24/1K tugas) dibandingkan dengan Opus 4.8 ($65,75/1K tugas) berarti kami dapat melakukan iterasi 50x lebih banyak dengan anggaran yang sama. Itu bukan hanya lebih murah — itu lebih cepat.
Gambaran Besar
Kami sedang menyaksikan komoditisasi pengkodean secara langsung. Jarak antara "Saya bisa menulis kode" dan "Saya bisa mengirim produk" semakin menyusut. Seorang Builder dengan Fable atau Kimi K3 dapat melakukan apa yang dulunya memerlukan tim yang terdiri dari lima orang.
Tapi inilah masalahnya: model-model ini semakin baik dalam pengkodean lebih cepat daripada kebanyakan insinyur yang semakin baik dalam menggunakannya.
Insinyur yang berhasil di tahun 2026 bukanlah mereka yang menulis paling banyak baris. Mereka adalah orang-orang yang mengajukan pertanyaan yang tepat, meninjau kode yang dihasilkan secara kritis, dan tahu kapan harus menerima saran AI dan kapan harus menolaknya.
Model adalah alatnya. Penilaian tetap milik Anda.
Atau seperti yang akan dikatakan Yang Wen-li: "Cara paling efektif untuk menang adalah membuat musuh kehilangan kemauan untuk bertarung." Di tahun 2026, musuhnya adalah kompleksitas. Model-model yang menang adalah yang membuat kompleksitas dapat dikelola.
Solusi Teknologi Mercury: Percepat Digitalitas.
