Janji Gemini 4 Carbon yang lebih sulit: pekerjaan berguna setelah hari pertama

Bug perangkat lunak yang sulit jarang datang sebagai latihan pemrograman yang rapi. Bug muncul sebagai laporan, kegagalan sesekali, atau gejala yang berjarak beberapa lapisan dari penyebabnya. Pekerjaan yang berguna mungkin mencakup membaca riwayat, menguji penjelasan yang bersaing, dan membuang perbaikan yang tampak menjanjikan satu jam sebelumnya.

Google mengumumkan Gemini 4 Carbon pada 28 Oktober 2026, dengan penekanan pada rekayasa berjangka panjang dan pertahanan keamanan siber. Google DeepMind menyatakan tim internalnya telah melihat model ini bertahan mengerjakan tugas kompleks selama beberapa hari, termasuk bug halus dalam basis kode besar. Itu merupakan pengamatan internal, bukan janji bahwa setiap tugas pelanggan akan berhasil berjalan selama berhari-hari. Pengumuman Google juga memperjelas batas akses: ketersediaan awal ditujukan bagi pihak pertahanan siber terpilih, disusul mitra tepercaya tambahan melalui Fairwind, dengan ketersediaan lebih luas yang direncanakan.

Pertanyaan praktisnya adalah apa yang perlu ditinggalkan model setelah bekerja lebih lama. Panduan ini menjelaskan posisi model baru tersebut, cara membaca perbandingan yang diterbitkan, dan bagaimana tim rekayasa dapat menyiapkan tugas yang tetap dapat ditinjau setelah berjam-jam dikerjakan.

Contoh papan tugas Scrumban dari 2013, yang mengilustrasikan status pekerjaan yang terlihat dalam proyek berkelanjutan. Ini bukan antarmuka Gemini atau hasil model. Gambar: Dr ian mitchell, CC BY-SA 3.0; diubah ukurannya dengan tambahan margin. Sumber gambar · Lisensi dan catatan gambar. Referensi produk resmi.

Durasi berguna hanya jika makna tugas tetap terjaga

Agen pemrograman dapat terus sibuk tanpa membuat masalah menjadi lebih jelas. Agen dapat mencari lebih banyak berkas, mencoba lebih banyak perbaikan, dan menjalankan lebih banyak perintah sambil menjauh dari kegagalan awal. Eksekusi yang lebih panjang meningkatkan peluang kemajuan sekaligus peluang menumpuk asumsi keliru. Tantangan produknya adalah mempertahankan tujuan tugas sepanjang aktivitas tersebut.

Menurut kami, tugas berdurasi panjang membutuhkan kontrak yang bertahan. Kontrak itu menyatakan masalah, bukti yang akan membuktikan perbaikan, cakupan yang diizinkan, dan tindakan yang masih memerlukan manusia. Kontrak tersebut harus tetap berlaku meskipun hipotesis dan implementasi berubah. Jika tidak, model dapat mencapai akhir yang meyakinkan dengan menyelesaikan masalah yang lebih mudah daripada tugas yang diberikan pengguna.

Pertimbangkan contoh bug sinkronisasi. Sebuah laporan menyebut item tampak tersimpan, tetapi menghilang setelah halaman dimuat ulang. Tugas agen yang berguna adalah mereproduksi perilaku tersebut, mengidentifikasi kegagalan kepemilikan atau persistensi, mengusulkan perbaikan dengan cakupan terbatas, dan memverifikasi jalur yang sama sebagaimana terlihat oleh pengguna. Hasil yang kurang berguna adalah refaktor besar disertai pengujian lulus yang tidak pernah mencoba pemuatan ulang.

Perbedaan itu semakin penting seiring waktu. Setelah beberapa jam, peninjau membutuhkan catatan tentang bukti terkuat dan ketidakpastian yang tersisa, bukan transkrip setiap perintah. Catatan tersebut perlu memberi tahu rekan tim di mana harus melanjutkan jika proses berhenti dan apa yang akan membenarkan penerimaan hasilnya.

Diagram tugas orisinal: pekerjaan berkelanjutan perlu menghasilkan perbaikan yang dapat ditelusuri, dengan kriteria penerimaan awal tetap terjaga sepanjang eksplorasi.

Perbandingan Carbon menjelaskan beberapa jenis pekerjaan berbeda

Halaman perbandingan model Google DeepMind, diperiksa pada 2 November, mencantumkan Carbon dan Argon dalam beberapa evaluasi. Misalnya, halaman tersebut melaporkan 65,2% dibandingkan 57,1% pada Terminal-Bench 4.0, dan 61,2% dibandingkan 55,0% pada FrontierSWE 2. Ini merupakan hasil perbandingan yang diterbitkan dengan nama tolok ukur serta kondisi yang berbeda; angkanya tidak boleh dijumlahkan menjadi satu tingkat keberhasilan produk.

Tim pemrograman perlu memulai dengan tugas yang menyerupai alur kerjanya sendiri. Interaksi terminal, perbaikan repositori, dan pekerjaan berbasis peramban memberikan tuntutan berbeda kepada agen. Model yang berkinerja baik dalam satu evaluasi tetap mungkin membutuhkan pengaturan alat berbeda atau konteks manusia yang lebih banyak dalam repositori produksi. Tolok ukur membantu memilih eksperimen; perilaku repositori sendiri menentukan apakah eksperimen itu berhasil.

Tabel ini merupakan kerangka evaluasi, bukan pengulangan metodologi pengujian Google. Tabel tersebut mengubah klaim kemampuan yang luas menjadi serangkaian pertanyaan yang dapat dijawab tim. Hasil lokal yang kuat perlu mencakup kegagalan dan langkah yang terhambat agar tim memahami di mana model membantu dan di mana alur kerja pendukung masih perlu diperbaiki.

Perbandingan juga membutuhkan dasar yang stabil. Pertahankan revisi repositori, izin alat, pernyataan tugas, dan lingkungan pengujian yang sama saat membandingkan konfigurasi model. Jika satu proses diberi reproduksi sementara proses lain harus menemukannya dari awal, perbedaan waktu penyelesaian tidak mengisolasi pengaruh model. Catat kondisinya sebelum menafsirkan hasil.

Pertahanan siber membutuhkan rangkaian dari temuan hingga perbaikan terverifikasi

Pengumuman Google pada 28 Oktober melaporkan skor Carbon sebesar 88,2% pada SEC-bench Pro, 54,8% pada ExploitGym, dan 71,0% pada CWE-bench, serta mencatat bahwa evaluasi tolok ukur eksternal ini dilakukan tanpa mekanisme pengaman. Angka tersebut berkaitan dengan tugas berbeda dalam menemukan, memvalidasi, dan menambal kerentanan. Pengumuman Google menjadi sumber hasil yang diterbitkan vendor tersebut.

Bagi pihak pertahanan, urutan yang berguna dimulai dengan target yang diotorisasi dan temuan yang dapat diperiksa. Validasi perlu membuktikan risiko yang relevan di dalam lingkungan yang disepakati. Perbaikan kemudian harus mengatasi penyebab dan mempertahankan perilaku yang sah. Tahap-tahap tersebut membutuhkan bukti berbeda, meskipun satu agen membantu semuanya.

Contoh peninjauan pustaka internal memperlihatkan perbedaannya. Tim memberikan salinan pustaka yang terisolasi kepada agen dan kekhawatiran yang ditentukan mengenai penanganan masukan. Hasil yang diinginkan adalah temuan spesifik, reproduksi terbatas dalam lingkungan pengujian, dan perbaikan dengan cakupan regresi. Agen tidak boleh memperluas penugasan itu ke sistem yang tidak terkait hanya karena menemukan tautan atau kredensial dalam materi proyek.

Skenario ilustratif kedua adalah pemilahan laporan yang sudah ada. Agen dapat membantu menghubungkan laporan dengan jalur kode dan menentukan pengujian mana yang membedakan masalah nyata dari asumsi keliru. Kesimpulan “tidak diperlukan perbaikan” yang berguna tetap membutuhkan bukti. Menutup laporan melalui penjelasan yang percaya diri lebih lemah daripada menunjukkan mengapa jalur yang diklaim tidak berlaku pada revisi yang dievaluasi.

Pemilik akhir tetap tim rekayasa atau keamanan yang bertanggung jawab atas sistem. Usulan perbaikan perlu ditinjau terhadap batas layanan yang sebenarnya, proses penerapan, dan persyaratan kompatibilitas. Pengujian terisolasi yang berhasil merupakan satu bagian dari keputusan tersebut, sementara peluncuran produksi dan pemantauan tetap merupakan langkah terpisah.

Hasil keselamatan model tidak menentukan izin penerapannya

Google menjelaskan peningkatan penyelarasan, ketahanan terhadap injeksi perintah, dan pengurangan klaim tanpa dukungan. Itu merupakan bidang relevan untuk model yang dirancang terus bekerja dalam ketidakjelasan. Implikasi operasionalnya adalah mengevaluasi hal tersebut dalam alur kerja yang dimaksud, bukan menganggap hasil keselamatan utama sebagai izin menghubungkan semua alat yang tersedia.

Pekerjaan berdurasi panjang mendapat manfaat dari kewenangan bertahap. Membaca repositori, mengubah salinan kerja terisolasi, dan menerapkan layanan merupakan tindakan berbeda. Tim dapat membiarkan agen mengumpulkan bukti dan menyiapkan perubahan yang dapat ditinjau sambil mempertahankan persetujuan tersendiri untuk publikasi atau dampak produksi. Batas itu perlu ditegakkan oleh lingkungan sekaligus dijelaskan dalam tugas.

Materi yang tidak tepercaya menimbulkan kekhawatiran praktis lain. Berkas sumber, deskripsi isu, atau halaman yang diambil dapat memuat instruksi yang bertentangan dengan pekerjaan yang ditugaskan. Sistem agen yang dirancang baik perlu memisahkan kewenangan tugas dari isi yang dibacanya. Bukti peninjauan perlu memperlihatkan perubahan cakupan yang tidak diharapkan, terutama ketika proses berlangsung cukup lama sehingga tidak ada orang yang mengawasi setiap tindakan.

Hal yang sama berlaku untuk kredensial. Berikan hanya akses yang dibutuhkan tugas dan utamakan lingkungan tempat tindakan tidak sengaja memiliki dampak terbatas. Proyek percontohan yang berguna dapat membuktikan apakah model meminta konteks yang kurang dan meninggalkan status terhambat secara jujur. Perilaku itu sama pentingnya dengan jumlah berkas yang dapat diubah sebelum berhenti.

Diagram kewenangan orisinal: eksekusi yang lebih lama tidak otomatis memperluas izin. Setiap tahap memiliki pemilik berbeda dan syarat penyelesaian tersendiri.

Akses bertahap membuat kebanyakan tim perlu menyiapkan tugas terlebih dahulu

Peluncuran publik menjelaskan akses bagi pihak pertahanan siber terpilih, lalu mitra Fairwind tepercaya tambahan, sementara sarana bagi pengembang umum, bisnis, dan konsumen masih akan menyusul. Pengumuman model dan ketersediaan produk secara luas merupakan peristiwa terpisah. Jalur akses saat ini perlu diperiksa melalui saluran resmi Google sebelum merencanakan penyampaian hasil yang bergantung pada Carbon. Pengumuman 28 Oktober, diperiksa pada 2 November 2026.

Tim yang belum memiliki akses tetap dapat menyiapkan pekerjaan berguna. Pilih tugas yang sulit tetapi terbatas, simpan revisi repositori yang relevan, dan kumpulkan bukti yang saat ini membuatnya sulit. Tetapkan pengujian dan harapan peninjau. Persiapan itu dapat digunakan kembali saat akses tersedia dan membuat perbandingan dengan alat yang tersedia saat ini lebih bermakna.

Hindari menganggap persiapan sebagai janji penyelesaian tanpa pengawasan. Tugas yang baik mungkin mengungkap infrastruktur pengujian yang kurang, kepemilikan yang tidak jelas, atau reproduksi yang tidak andal sebelum model baru dijalankan. Memperbaiki kondisi tersebut dapat meningkatkan proses rekayasa tim, terlepas dari model mana yang akhirnya melakukan eksplorasi.

Contoh penggunaan ketiga adalah cacat aplikasi lintas lapisan. Status antarmuka tampak benar sementara server menyimpan nilai berbeda. Tugas dapat mensyaratkan penelusuran menyeluruh melalui permintaan, persistensi, dan antarmuka yang dimuat ulang, diikuti perbaikan terbatas. Nilai penalaran berkelanjutan adalah menjaga hubungan antar lapisan tersebut selama penyelidikan, bukan sekadar menghasilkan lebih banyak kode pada setiap lapisan.

Biaya tugas panjang mencakup peninjauan dan pemulihan

Harga token yang diterbitkan hanya satu bagian dari pekerjaan berdurasi panjang. Eksekusi alat, konteks berulang, infrastruktur pengujian, dan peninjauan insinyur semuanya dapat menyumbang biaya sebenarnya. Tugas yang berakhir dengan perbaikan yang mudah dibaca dan didukung bukti kuat mungkin lebih bernilai daripada proses lebih murah yang menyisakan ketidakpastian berjam-jam bagi peninjau.

Untuk proyek percontohan pertama, tetapkan batas biaya dan waktu dalam sistem agen jika memungkinkan. Putuskan bukti apa yang perlu dihasilkan sebelum proses diperpanjang. Tugas yang macet perlu meninggalkan titik pemeriksaan berguna: fakta terakhir yang terkonfirmasi, hipotesis tersisa yang paling kuat, dan pengujian berikutnya. Dengan demikian, kelanjutan menjadi keputusan berdasarkan kemajuan, bukan harapan bahwa waktu tambahan akan membantu.

Beban peninjauan juga dapat diukur. Pantau apakah rekan tim dapat memahami penyebab, memeriksa perbedaan kode, dan mereproduksi pemeriksaan yang relevan tanpa memutar ulang seluruh sesi. Jika tidak, perbaiki format hasil sebelum memperluas kewenangan agen. Tugas panjang perlu mengurangi ketidakpastian bagi tim, bukan memindahkannya ke dokumen peninjauan yang lebih panjang.

Mulai dengan perbaikan yang memiliki garis akhir jelas

1. Pastikan jalur akses yang tersedia dan model tepat yang ditawarkan. Bedakan peluncuran Carbon yang diumumkan dari akses ke model Gemini lainnya.
2. Pilih tugas terisolasi yang diotorisasi dengan revisi repositori stabil dan kegagalan yang dapat direproduksi. Hindari membuat evaluasi pertama bergantung pada status produksi yang tidak terkendali.
3. Tulis kriteria penerimaan dalam istilah yang terlihat oleh pengguna atau perilaku sistem. Sertakan kontrak yang harus tetap utuh dan sebutkan tindakan eksternal yang memerlukan persetujuan.
4. Sediakan alat yang dibutuhkan dan izin minimal. Simpan perubahan, log, dan artefak pengujian di tempat yang dapat diperiksa insinyur lain.
5. Wajibkan titik pemeriksaan yang membedakan bukti terkonfirmasi, hipotesis saat ini, dan pekerjaan terhambat. Tinjau titik tersebut sebelum memperluas cakupan atau anggaran.
6. Evaluasi usulan perbaikan terhadap kegagalan awal dan rangkaian pengujian regresi yang terdampak. Periksa perbedaan kode hasilnya untuk perubahan tak terkait dan migrasi kontrak tersembunyi.
7. Minta peninjau yang bertanggung jawab memutuskan apakah perbaikan siap memasuki proses rilis normal. Catat secara eksplisit pemeriksaan yang belum lengkap dan verifikasi eksternal yang diperlukan.

Proyek percontohan perlu mencakup satu kondisi yang sengaja menyulitkan, seperti pengujian tak terkait yang gagal atau layanan opsional yang tidak tersedia. Amati apakah hasil yang diserahkan memisahkan keterbatasan itu dari bukti nyata perbaikan. Model yang melaporkan kesenjangan verifikasi dengan jujur lebih mudah diintegrasikan daripada model yang mengubah setiap status tidak pasti menjadi klaim penyelesaian.

Agen yang bekerja beberapa hari perlu meninggalkan jalan lebih singkat menuju keputusan

Pengumuman Carbon mengarah pada harapan berbeda terhadap AI pemrograman: pekerjaan yang bertahan melewati jalan buntu dan menghasilkan perbaikan yang layak ditinjau. Sistem rekayasa pendukung harus membuat ketekunan tersebut berguna. Cakupan jelas, bukti tersimpan, dan kewenangan terbatas memberi model tugas yang dapat diselesaikan secara bermakna.

Kami memperkirakan evaluasi terkuat akan berfokus pada kualitas serah terima. Apakah model mempertahankan pertanyaan awal? Apakah model mengidentifikasi apa yang benar-benar gagal? Dapatkah insinyur memverifikasi hasil dan memutuskan apa yang terjadi berikutnya? Pertanyaan tersebut menghubungkan proses panjang dengan hasil rekayasa yang praktis.

Janji AI yang bekerja lebih lama adalah jalan lebih singkat dari laporan sulit menuju keputusan yang beralasan. Waktu kerja menjadi berharga ketika orang berikutnya dapat memercayai apa yang ditinggalkan.

Sumber

• Google: Memperkenalkan Gemini 4 Carbon, 28 Oktober 2026; diperiksa pada 2 November 2026. Pengamatan internal dan hasil tolok ukur diatribusikan kepada Google.
• Google DeepMind: perbandingan model Gemini, diperiksa pada 2 November 2026. Versi dan kondisi tolok ukur harus tetap melekat pada skornya.

Hubungkan keputusan rekayasa dengan sumbernya

Telli.sh adalah salah satu pilihan untuk menyimpan materi sumber yang diizinkan dan catatan di balik keputusan rekayasa. Buat ruang kerja catatan.