Kesimpulan dalam 5 detik
Yang benar-benar berguna dalam otomatisasi AI bukanlah jawaban pertama yang cepat. Yang penting adalah sedikitnya pekerjaan ulang sampai benar-benar selesai.
Sebuah sistem produksi artikel, setelah dirombak habis-habisan selama beberapa hari sampai sekitar seminggu, berubah dari sekadar "alat yang menyuruh AI menulis lalu menyimpannya" menjadi pabrik otonom kecil yang punya pemantauan, eksekusi ulang, kontrol bentrok, penyimpanan di tengah jalan, isolasi kegagalan, gerbang kualitas, dan pengelolaan bukti.
Yang berhasil dalam perombakan besar itu adalah memakai ultra di awal setiap perubahan desain besar. Ini mode yang tidak hanya membuat GPT-5.6 Sol berpikir lebih dalam, tetapi juga menjalankan beberapa pekerjaan secara paralel.
Sekali jalan memang berat. Tapi setelah itu berkurang kejadian seperti "ternyata bagian ini rusak", "eksekusi paralel bikin kecelakaan", "tidak ada bukti", dan "harus mengulang semuanya lagi". Hasilnya, total waktu jadi lebih pendek.
Dalam bahasa pabrik: waktu siklusnya panjang, tapi tingkat pengerjaan ulangnya rendah, sehingga total lead time-nya pendek.
Peringatan dulu: Level 6 dan Level 7 bukan peringkat yang berlaku di seluruh dunia
Level 6 dan Level 7 di artikel ini bukan level game dan bukan standar ISO. Keduanya hanyalah label yang saya buat untuk sistem ini supaya tingkat kematangan otomatisasi mudah dijelaskan.
Dasar pemikirannya dekat dengan "komputasi otonom" (autonomic computing) yang sudah lama diteliti IBM. IBM merumuskan ciri utama sistem otonom sebagai kemampuan mengatur diri sendiri, memperbaiki diri sendiri, mengoptimalkan diri sendiri, dan melindungi diri sendiri.
Di artikel ini, saya menyebut tahap ketika sistem kembali ke kondisi yang benar dengan sendirinya sebagai Level 6, dan tahap ketika sistem juga mencari cara kerja yang lebih baik secara mandiri dalam batas aman sebagai Level 7.
Awalnya cuma "menyuruh AI menulis artikel". Tahu-tahu blognya tumbuh pagar
Otomatisasi artikel yang biasa itu sederhana:
- Jalan pada jam yang ditentukan.
- AI membuat teksnya.
- Disimpan ke file.
- Diunggah ke GitHub.
- Kalau gagal, manusia yang memeriksa.
Itu saja sudah cukup berguna.
Namun ketika jumlah artikel bertambah, bahasanya jadi 12, dan audit kualitas, tautan internal, pembaruan, sampai keputusan terbit ikut diotomatisasi, masalahnya berubah.
Inti persoalannya bukan lagi "bisakah menulis?", melainkan hal-hal seperti ini:
- Bagaimana kalau dua worker (program yang menjalankan tugas) menyentuh artikel yang sama secara bersamaan?
- Kalau mati di tengah jalan, lanjut dari mana?
- Bagaimana agar pekerjaan yang gagal tidak dicoba ulang selamanya?
- Jangan-jangan hasil pemeriksaan lama dipakai ulang seolah-olah hasil yang baru?
- Apakah AI sembarangan bilang "sudah dicek manusia"?
- Siapa yang menahan penerbitan dalam kondisi yang tidak boleh terbit?
- Bagaimana caranya agar seluruh pabrik tidak berhenti walau layanan eksternal mati?
- Nilainya tertulis "100", tapi apakah angka 100 itu benar-benar mengukur kondisi saat ini?
Kalau sudah sampai sini, ini bukan lagi "otomatisasi blog".
Ini sistem produksi kecil yang bahan bakunya adalah konten.
Level 6: Rusak pun, kembali sendiri ke kondisi yang benar
Singkatnya, Level 6 di pabrik ini adalah mekanisme yang secara otonom kembali ke jawaban benar yang sudah ditetapkan.
Unsur utamanya seperti berikut.
| Mekanisme | Kalau dijelaskan untuk anak SMP |
|---|---|
| desired state | Menetapkan "jawaban yang benar" dalam bentuk yang bisa dibaca mesin |
| reconciliation | Membandingkan kondisi sekarang dengan jawaban benar, lalu memperbaiki kalau berbeda |
| lease / fencing | Mencegah dua pihak mengerjakan pekerjaan yang sama secara bersamaan |
| checkpoint | Menyimpan secara resmi sampai mana pekerjaan sudah selesai |
| CAS | Tidak menimpa kondisi baru dengan kondisi lama |
| transactional outbox | Menangani ketidakcocokan saat proses utama berhasil tetapi hanya notifikasinya yang gagal |
| retry / quarantine | Mencoba ulang kegagalan sementara dan mengisolasi data "beracun" |
| safe publication gate | Tidak mengizinkan terbit sampai syarat kualitas terpenuhi |
| failure injection | Sengaja merusak untuk menguji apakah pemulihan benar-benar berjalan |
| observability | Membuat apa yang berjalan dan apa yang gagal bisa diukur |
Dalam salah satu cuplikan operasional, 21 syarat desain Level 6 semuanya PASS dan skor implementasi kontrolnya 100. Di sisi lain, skor jaminan yang mencakup pengukuran eksternal, konfirmasi manusia, dan rekam jejak jangka panjang seluruh worker sekitar 69%, penerbitan masih HOLD, dan Level 7 masih OFF.
Di sinilah poin pentingnya.
Nilai 100 pada implementasi dan nilai 100 yang benar-benar membuat tenang untuk ditinggal itu dua hal yang berbeda.
Sekalipun semua tes lulus, bukti bahwa sistem benar-benar berjalan selama seminggu, sebulan, atau setengah tahun tidak bisa dibuat tanpa waktu.
Penalaran mendalam Sol dan Ultra: "satu orang berpikir lama" versus "banyak orang bekerja paralel"
Menurut penjelasan resmi OpenAI, GPT-5.6 Sol punya max yang membuatnya bernalar mendalam, dan ultra adalah pengaturan berkemampuan tinggi yang mengoordinasikan beberapa agen dalam jalur kerja paralel.
Perumpamaannya begini.
Kalau Sol disuruh berpikir mendalam
Seorang perancang andal dikurung di ruang rapat.
"Tidak usah buru-buru. Baca semua kode dan semua dokumen. Cari kontradiksinya. Pikirkan sampai tuntas."
Ini sangat kuat.
Kalau Ultra
Perancang, pelaksana, pencari bug, si perusak, dan penguji bergerak bersamaan, lalu hasilnya digabung di akhir.
Singkatnya, bukan kecerdasannya yang sekadar dua kali lipat, melainkan arah hal-hal yang terlewat jadi tersebar.
Pada angka yang dipublikasikan OpenAI, di Terminal-Bench 2.1 GPT-5.6 Sol mendapat 88,8% dan Sol Ultra 91,9%. Selisihnya 3,1 poin, tetapi dilihat dari sisi kegagalan, turun dari 11,2% menjadi 8,1%, jadi secara hitungan sederhana tingkat kegagalan berkurang sekitar 28%. Tentu ini hanya satu evaluasi, bukan berarti di semua pekerjaan kegagalan turun 28%.
Meski begitu, untuk pekerjaan yang bisa dibagi-bagi seperti "membaca repositori raksasa, merancang, mengimplementasikan, merusak, lalu memverifikasi ulang", arah perbedaan ini mudah terlihat.
Kenapa Ultra yang berat justru akhirnya lebih cepat?
Waktu sampai selesai kira-kira bisa dipikirkan begini:
total lead time = implementasi pertama + pengerjaan ulang + tes ulang + penanganan insiden + perbaikan salah paham
Kebanyakan orang hanya melihat suku pertama, "implementasi pertama".
Karena itu AI yang menjawab dalam 30 menit tampak cepat, dan yang butuh 2 jam tampak lambat.
Tetapi kalau versi 2 jam itu menghapus 6 jam pengerjaan ulang yang akan muncul belakangan, versi 2 jam justru lebih cepat.
Di manufaktur pun sama.
Pabrik yang memproduksi cepat lalu banyak menolak barang saat inspeksi, pada akhirnya kalah cepat dari pabrik yang sejak awal meningkatkan kemampuan prosesnya sehingga tidak menghasilkan barang cacat.
Yang menarik dari "Ultra sekali pukul" kali ini adalah sebagian besar masalah yang ditemukan belakangan bukan masalah yang menuntut desain dasar dibongkar ulang.
Yang dirapikan di tahap-tahap berikutnya misalnya hal-hal seperti ini:
- Saya ingin melihat dalam satu halaman bukti bahwa semua worker benar-benar memproses data asli.
- Jangan pakai 50/50 yang lama sebagai 50/50 audit yang baru.
- Jangan menulis tinjauan AI sebagai tinjauan manusia.
- Kalau tidak ada pengukuran eksternal, tulis "tidak diketahui".
- Kalau worker tidak melakukan apa-apa, tetapi itu NOOP yang benar (memang tidak ada yang perlu dikerjakan dan sengaja diam), jangan dianggap gagal.
Ini bukan soal "tiangnya terbalik, jadi rumahnya harus dibangun ulang".
Ini lebih mirip bagian pengendali mutu yang masuk ke pabrik yang sudah jadi, lalu rewel sampai ke label pipa dan kalibrasi alat ukur.
Kenapa "Ultra satu penggorengan" berhasil
Bukan berarti semuanya sempurna dalam sekali jalan.
Lebih tepatnya, karena gagasan desain awalnya cukup benar, perbaikan sesudahnya cukup bersifat lokal.
Yang besar pengaruhnya adalah sejak awal pertanyaan-pertanyaan berikut sudah dimasukkan ke dalam desain:
- Bagaimana kalau dijalankan bersamaan?
- Bagaimana kalau mati di tengah jalan?
- Bagaimana kalau diproses dua kali?
- Bagaimana kalau menulis sambil memegang kondisi lama?
- Bagaimana kalau hanya API eksternal yang mati?
- Bagaimana kalau data yang gagal berputar tanpa henti?
- Bagaimana kalau pemeriksaannya sendiri rusak?
- Bagaimana kalau ada celah untuk berbohong bahwa "semua berhasil"?
Biasanya hal-hal ini dipelajari satu per satu lewat gangguan di produksi.
Kali ini, saya lebih dulu menciptakan "kecelakaan kerja virtual".
Jatuhkan server di dalam tes sebelum jatuh sungguhan. Buat CI yang menangis sebelum manusia yang menangis.
Gagasan ini cocok juga dengan chaos engineering. Di sana, kondisi normal didefinisikan dalam bentuk yang bisa diukur, kegagalan yang terjadi di dunia nyata sengaja dimasukkan, lalu diperiksa apakah kondisi normal itu runtuh.
Seberapa hebat ini dibandingkan yang ada di dunia?
Bagian ini sebaiknya jangan dilebih-lebihkan.
Mengatakan "ini sistem terkuat di dunia" jelas berlebihan.
Tapi ini juga bukan sekadar "menulis blog pakai AI".
Penempatannya kira-kira begini:
| Pembanding | Jaraknya |
|---|---|
| Menyuruh AI menulis artikel lalu menyimpannya | Jauh di depan |
| Otomatisasi berurutan ala Zapier / n8n | Satu tingkat lebih maju dalam pemulihan kegagalan dan kontrol bentrok |
| Backend serius sebuah SaaS pribadi | Banyak unsur desain yang sepadan |
| Platform otomatisasi internal perusahaan kecil-menengah | Layak dibandingkan |
| Layanan komersial matang dengan SRE (insinyur keandalan) khusus | Masih di bawah dalam rekam jejak operasi jangka panjang, pemantauan eksternal, dan jaminan keamanan |
| Infrastruktur raksasa setingkat Google atau Amazon | Skalanya beda alam |
Yang aneh untuk proyek pribadi adalah kode yang tumbuh untuk urusan cara bersikap saat gagal ternyata lebih banyak daripada fitur menulis artikelnya.
Kalau lease, fencing, CAS, outbox, quarantine, dan failure injection sudah tinggal di pabrik artikel, ini bukan lagi blog, tapi pusat logistik.
Level 7: Kepala pabrik mulai mencoba usulan perbaikan sendiri
Di Level 6, "jawaban yang benar" ditentukan oleh manusia.
Kalau rusak, dikembalikan ke jawaban itu.
Di Level 7, dalam batas jawaban yang benar, sistem mencari sendiri cara kerja yang lebih baik.
Gambarannya seperti ini:
- Mengukur kualitas, kecepatan, biaya, waktu tunggu, dan tingkat kegagalan sekaligus.
- Membuat syarat keamanan mustahil diubah.
- Mencoba prompt dan urutan proses baru di shadow (uji coba paralel yang tidak memengaruhi produksi).
- Kalau tampak bagus, diperluas sebagai canary (rilis bertahap): 5%, 20%, 100%.
- Kalau kualitas turun, otomatis dikembalikan.
- Saat keandalan buruk, hanya eksperimen yang dihentikan, produksi normal tetap jalan.
- Mencatat di buku besar eksperimen apa yang dicoba, apa yang bagus, dan mengapa diadopsi.
Ini dekat dengan gabungan self-optimization dalam komputasi otonom IBM, error budget milik Google SRE (seberapa banyak kegagalan yang masih boleh ditoleransi sebelum harus mengerem), serta canary dan rollback milik AWS.
Namun, tidak perlu langsung memasang Level 7 di produksi sekarang.
Alasannya sederhana: saya masih mengumpulkan rekam jejak jangka panjang Level 6.
Kalau masih memeriksa apakah peralatannya stabil lalu bilang ke kepala pabrik AI "mulai hari ini kecepatan lini juga boleh kamu ubah sendiri", mencari akar masalah jadi merepotkan.
Kalau mau mengerjakan sesuatu sekarang, yang lebih dulu bukan Level 7 itu sendiri, melainkan penguatan observasi yang merangkum kerja nyata semua worker dalam satu halaman.
Bulan ketika kamu membayar, jadikan "bulan investasi peralatan"
Tidak banyak alasan memakai Ultra untuk pekerjaan ringan sehari-hari.
Untuk perbaikan kecil, audit rutin, atau pemrosesan worker yang sudah baku, Sol biasa atau penalaran mendalam sering kali sudah cukup.
Ultra jitu untuk pekerjaan yang kalau gagal pengerjaan ulangnya besar:
- Perancangan ulang seluruh sistem
- Refactoring skala besar
- Penataan ulang susunan worker
- Perancangan pemantauan dan pemulihan
- Peninjauan ulang batas keamanan
- Fondasi shadow untuk Level 7
- Penambahan tes dan failure injection dalam jumlah besar
Jadi cara pakai yang masuk akal adalah menjalankan pabrik seperti biasa, mengumpulkan tema perombakan besar, lalu berinvestasi peralatan sekaligus pada saat mode tingkat atas bisa dipakai.
Daripada melihat biaya langganan AI sebagai "iuran bulanan agar sedikit lebih pintar tiap hari", lihatlah sebagai biaya proyek untuk membangun ulang fondasi sekaligus.
Dengan cara pandang ini, nilai model berat tidak perlu dibandingkan hanya dari harga per jawaban.
Pelajaran terbesar dari sekitar seminggu ini
Pelajaran terbesarnya: jangan menilai kepintaran AI hanya dari tingkat ketepatan jawaban.
Dalam pekerjaan nyata, lima hal ini yang berpengaruh:
- Ketepatan desain awal: apakah nanti tidak perlu membongkar semuanya?
- Kemampuan menyanggah: apakah ia bisa menghancurkan usulannya sendiri?
- Paralelisme: apakah desain, implementasi, tes, dan audit bisa dipisah dan dikerjakan bersamaan?
- Kejelasan bukti: bukan "rasanya sudah jalan", tetapi bisa meninggalkan catatan apa yang benar-benar berjalan.
- Kemampuan pulih: apakah bisa kembali tanpa memanggil manusia setelah gagal?
Artinya, pabrik AI yang baik bukanlah "pabrik yang tidak pernah gagal".
Pabrik yang berasumsi akan gagal, tidak berhenti walau gagal, tidak melaporkan keberhasilan palsu, dan bisa kembali dari titik mana pun.
Kesimpulan: Cepat artinya cepat sampai akhir
Kalau alasan bisa sampai sejauh ini dalam sekitar seminggu hanya dijawab "AI-nya cepat sekali", intinya terlewat.
Yang berhasil adalah menaruh sumber daya komputasi yang tebal pada desain awal, lalu kembali ke operasi biasa yang murah.
Ultra bukan tombol jawaban ajaib. Lebih mirip alat yang menghapus pengerjaan ulang dengan cara membayarnya di muka.
Walau sekali proses lambat, kalau total waktu sampai selesai pendek, itu cepat.
Dan yang dibutuhkan di tahap sekarang bukan buru-buru memasang Level 7 yang lebih pintar.
Melainkan membiarkan Level 6 berjalan sendiri sebentar, dan melihat apakah ia benar-benar terus bekerja sendiri.
Kalau pabriknya terlihat menganggur, saat itulah wewenang perbaikan bisa diserahkan kepada kepala pabrik AI.
Untuk sekarang, memberi kepala pabrik tombol untuk mengubah kecepatan lini sesuka hati itu terlalu seru.
Referensi (7)
- OpenAI, GPT-5.6: https://openai.com/index/gpt-5-6/
- OpenAI, GPT-5.6 (versi Jepang): https://openai.com/ja-JP/index/gpt-5-6/
- IBM Research, Autonomic computing: https://research.ibm.com/publications/autonomic-computing-architectural-approach-and-prototype
- IBM Research, Utility functions: https://research.ibm.com/publications/achieving-self-management-via-utility-functions
- Google SRE, Error Budget Policy: https://sre.google/workbook/error-budget-policy/
- Principles of Chaos Engineering: https://principlesofchaos.org/
- AWS, Amazon ECS canary deployments: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/canary-deployment.html
