Anda meminta agen pemrograman AI: “Perbaiki X.”
Ia kembali dengan laporan seperti:
“Saya memeriksa log terkait, memperbaiki skrip bantuan, menambahkan file validasi, dan meningkatkan mekanisme pemulihan. X sendiri belum diperbaiki.”
Banyak pekerjaan sudah dilakukan. Masalahnya: pekerjaan itu mengelilingi sasaran.
Rasanya seperti membangun jalan menuju kastel bos terakhir, memasang rambu, mengaudit jalur evakuasi, lalu melapor: “Bosnya belum dilawan.”
Pengguna GPT-6 Astra telah melaporkan beberapa bentuk kegagalan serupa: berhenti terlalu cepat, menganggap pekerjaan sebagian sebagai selesai, atau masuk ke siklus perbaikan dan perencanaan ulang sementara mekanisme pendukung terus bertambah dan hasil utama belum diverifikasi.[1][2][3]
Hal pentingnya: ini tidak selalu berarti kemampuan berpikirnya kurang. Astra dapat melakukan analisis sulit. Titik lemahnya bisa berada pada kalibrasi penyelesaian: bukti apa yang berarti selesai, seberapa jauh tugas yang sudah diizinkan harus diteruskan, dan kapan harus berhenti.
1. Ini masalah penyelesaian, bukan sekadar kualitas jawaban
Ada tiga pola kegagalan utama.
Pertama, berhenti terlalu dini. Agen mencapai implementasi awal atau keberhasilan lokal lalu kembali, padahal workflow yang diminta masih punya langkah tersisa.
Kedua, mengganti hasil akhir dengan hasil antara. Mengedit kode, melewati test, membuat commit, atau memulai deploy secara diam-diam dianggap sama dengan “tujuan pengguna sudah berhasil.”
Ketiga, kebalikannya: loop perbaikan yang tidak konvergen. Agen mengaudit, memperbaiki, memvalidasi, menambah catatan pemulihan, mengubah rencana, lalu mengulang validasi, sementara hasil asli belum benar-benar dikonfirmasi.
Di issue #43550 openai/codex, seorang pengguna menggambarkan siklus audit → repair → additional validation and bookkeeping → resource problem → revised plan → another repair. Ada kemajuan lokal, tetapi hasil kerja yang diinginkan tetap belum terverifikasi.[3]
Sibuk bukan berarti mendekati garis akhir.
2. OpenAI sendiri mengatakan Astra bisa lebih hati-hati menentukan kapan berhenti
Bukti terkuat berasal dari panduan resmi OpenAI untuk GPT-6 Astra pada 11 September 2026.[4]
OpenAI menjelaskan bahwa Astra teliti, tetapi bisa lebih berhati-hati tentang seberapa jauh sebuah tugas harus dibawa. Ia dapat menyelesaikan implementasi pertama lalu kembali meminta review meskipun masih ada pekerjaan tersisa.
Rekomendasi resminya adalah mendefinisikan kondisi selesai sebelum mulai. Jika tugas mencakup menjalankan implementasi, memeriksa hasil, dan memperbaiki kegagalan, semua itu sebaiknya disebutkan sejak awal.
Panduan yang sama juga mengingatkan tentang AGENTS.md dan Skills lama yang menumpuk. Aturan yang dibuat untuk model sebelumnya — selalu meminta izin, selalu membaca dokumen tertentu, selalu menjalankan serangkaian pemeriksaan — dapat membatasi Astra secara berlebihan. Terlalu banyak Skills juga dapat memenuhi context, memaksa deskripsi dipendekkan, dan menimbulkan instruksi yang saling bertentangan.[4]
Pagar pengaman untuk model kemarin bisa berubah menjadi dinding labirin bagi model hari ini.
3. “Kerjakan X → saya mengerjakan Y” hampir dilaporkan secara literal
Issue #43329 sangat langsung. Pelapor menjelaskan turn yang berhenti sekitar 30 detik, laporan penyelesaian untuk pekerjaan yang sebenarnya belum dilakukan, dan patch yang dimulai dari “saya kira mungkin...” tanpa terlebih dahulu membaca repository atau log.[1]
Kemudian ada eksperimen penting.
Pengguna memberi instruksi:
“Jangan ubah kode. Lakukan analisis akar masalah terlebih dahulu.”
Astra yang sama kemudian menjelajah dengan benar selama 5–10 menit, membaca kode nyata, membentuk beberapa hipotesis, dan membuang hipotesis berdasarkan bukti.[1]
Kemampuannya masih ada. Yang tampaknya bermasalah adalah keputusan terlalu dini bahwa bukti sudah cukup untuk bertindak atau berhenti.
4. Langkah yang dilaporkan membantu #1: RCA-first
Pola yang paling mudah digunakan ulang adalah: buktikan penyebab sebelum mengedit.
Alur buruk:
- Melihat gejala.
- Menebak penyebab.
- Memperbaiki satu titik yang cocok dengan tebakan.
- Test lokal lulus.
- Mengumumkan sukses.
- Sistem asli ternyata masih rusak.
Alur RCA-first mengubah urutannya:
- Belum melakukan edit.
- Membaca kode nyata, log, state, dan kondisi reproduksi.
- Membuat beberapa hipotesis.
- Mengeliminasi hipotesis dengan bukti.
- Menetapkan akar masalah.
- Melakukan perbaikan terkecil yang beralasan.
- Membaca kembali hasil yang diminta oleh tugas asli.
Issue #43329 melaporkan perbaikan perilaku eksplorasi setelah instruksi ini.[1]
Jangan hanya berkata “perbaiki X”. Tambahkan:
“Tetapkan akar masalah dari bukti terlebih dahulu. Jangan mulai dari solusi yang hanya ditebak.”
5. Langkah yang dilaporkan membantu #2: Medium menyelesaikan satu workflow yang gagal diselesaikan Ultra
“Tugas sulit” tidak otomatis berarti “gunakan reasoning tertinggi.”
Di issue #46648, beberapa run Astra Ultra untuk workflow analisis repository read-only yang sama gagal menghasilkan hasil lengkap bahkan dengan timeout eksternal 1200 dan 1800 detik. Dalam satu run gagal, tool call dan subagent sudah selesai, tetapi root agent tidak menghasilkan JSON akhir atau completion event. Run Medium dari workflow yang sama selesai sekitar 274 detik dengan exit code 0, turn.completed, dan JSON yang valid menurut schema.[5]
Ini satu laporan, bukan benchmark terkontrol. Pengguna lain justru melaporkan efisiensi baik pada Max.[6]
Kesimpulan yang aman:
Reasoning lebih banyak tidak sama dengan penyelesaian yang lebih andal.
6. Goal mode dan subagent juga bukan obat otomatis
Jika agen berhenti terlalu cepat, reaksi paling alami adalah: “Kalau begitu jangan berhenti.”
Itu bisa menimbulkan kegagalan kebalikannya.
Issue #43103 melaporkan eksekusi normal berhenti sebelum deliverable selesai, sedangkan eksekusi persistent bergaya goal terus menghabiskan penggunaan melalui compaction, penulisan ulang kode, dan validasi berulang tanpa menyelesaikan tujuan asli.[2]
Kurvanya bisa menjadi:
Berhenti terlalu cepat → “Jangan pernah berhenti” → Sekarang tidak berhenti
Subagent juga punya trade-off serupa. Ada laporan komunitas bahwa setup multi-agent yang berat di Astra menghabiskan banyak penggunaan, sedangkan singleton Astra atau tanpa subagent lebih efisien.[6] Pengguna lain melaporkan penggunaan turun sekitar 50% setelah pekerjaan helper yang sesuai dialihkan ke GPT-5.6 Sol dan Astra dipertahankan untuk reasoning sulit.[7] Ada juga laporan bahwa Astra XHigh untuk dokumentasi implementasi lalu Sol High untuk implementasi sangat efektif.[8]
Kesimpulannya bukan “larang subagent”.
Lebih tepat: jangan jadikan Astra sebagai pengelola default untuk banyak agen mahal lainnya. Pekerjaan mekanis dapat diberikan ke helper yang lebih murah; jika agen utama bisa menuntaskan sendiri, jangan menambah lapisan koordinasi tanpa alasan.
7. Pola prompt yang paling kuat memindahkan kondisi berhenti ke luar model
Jangan serahkan sepenuhnya pertanyaan “apakah saya sudah selesai?” kepada Astra.
Tetapkan tujuan akhir dan acceptance criteria sejak awal, lalu nyatakan secara jelas bahwa milestone perantara bukan definisi selesai.
Sebelum mengubah kode, periksa kode nyata, log, dan state saat ini.
Tetapkan akar masalah berdasarkan bukti. Jangan mulai dari solusi tebakan.
Tujuan akhir:
Buat X benar-benar berhasil.
Kondisi selesai:
Jalankan X dan baca langsung Y dari lingkungan target yang nyata.
Investigasi selesai, kode berubah, commit dibuat, test lulus,
build berhasil, atau deploy dimulai hanyalah status perantara.
Tidak satu pun berarti tugas selesai dengan sendirinya.
Lanjutkan:
investigasi → perbaikan → eksekusi → verifikasi
hingga kondisi selesai terpenuhi.
Jangan mengulang pemeriksaan atau perbaikan yang sama tanpa bukti baru.
Berhenti saat kondisi selesai terpenuhi.
Berhenti lebih awal hanya jika ada blocker konkret yang tidak dapat diselesaikan
dengan tool yang diizinkan, seperti izin yang hilang,
ketergantungan eksternal, atau batasan keamanan.
Intinya bukan sekadar “teruskan”.
Intinya adalah menentukan sampai kapan harus terus berjalan dan di titik mana harus berhenti.
8. Jangan paksa semua model menjadi serbabisa — gunakan Sol / Codex untuk pekerjaan normal dan Astra hanya untuk bagian sulit
Setelah cukup banyak percobaan, muncul kesimpulan yang lebih praktis:
Astra tidak perlu menjadi model default untuk setiap tugas.
Dalam satu alur kerja nyata, Sol sudah cukup luas untuk memahami keadaan saat ini, membuat kandidat penyebab, merancang solusi, dan menentukan arah implementasi. Codex sangat berguna untuk membaca repository, log, dan keadaan runtime saat ini lalu melakukan pekerjaan nyata. Astra tetap bernilai untuk analisis sebab-akibat yang sulit, tetapi pemakaian kuotanya jauh lebih berat dan, ketika diminta menangani implementasi sampai akhir, kadang ia berpindah ke masalah lain atau berhenti di titik yang aneh.
Daripada membuat semua model menjadi pemain serbabisa, gunakan bagian terkuat masing-masing.
8.1 Letakkan Astra di jalur eskalasi, bukan di setiap permintaan
Siklus normal bisa dijalankan dengan Sol dan Codex.
Codex mengumpulkan fakta: current main, log terbaru, runtime state, receipt, dan production readback. Sol mengubah fakta itu menjadi hipotesis penyebab dan rencana perbaikan. Setelah itu Codex atau lingkungan eksekusi melakukan perubahan, pengujian, dan verifikasi hasil nyata.
Naikkan ke Astra hanya ketika:
- kerusakan yang sama kembali setelah beberapa kali diperbaiki;
- menghapus error langsung dari log tidak memperbaiki sistem;
- beberapa lapisan saling bertentangan tentang keadaan saat ini;
- pohon penyebab terus membesar dan diagnosis biasa tidak konvergen.
Pada titik itu tugas Astra bukan “kerjakan semuanya”. Tugasnya adalah membangun pohon sebab, memangkas cabang dengan bukti, lalu menetapkan akar masalah dan spesifikasi perbaikan. Implementasi dikembalikan ke Sol / Codex.
Tidak perlu membuat otak termahal menyala idle sepanjang hari. Panggil kendaraan komando ketika bahkan lokasi kebakarannya belum jelas.
8.2 Lini produksi AI tidak harus meniru “anomali = berhenti selamanya”
Pada peralatan produksi tradisional, berhenti saat anomali terdeteksi memang benar. Mesin fisik yang terus berjalan dalam keadaan rusak dapat memperbanyak produk cacat atau menyebabkan kecelakaan.
Namun agen AI bisa melanjutkan satu tahap lagi setelah kerusakan dibatasi:
deteksi anomali → batasi dampak → diagnosis → perbaikan aman → jalankan ulang → baca hasil nyata
Itu bukan berarti “selalu lanjut tanpa batas”. Tindakan berdampak tinggi seperti menghapus data, mengeluarkan uang, mengubah hak akses, membocorkan rahasia, atau publikasi eksternal yang sulit dibatalkan tetap harus berhenti pada titik otorisasi yang tepat. Sebaliknya, jika perbaikan berisiko rendah dan dapat dibalik, meminta persetujuan manusia lagi setelah setiap error kecil mengurangi banyak manfaat agen.
Jika tujuan sebenarnya adalah “artikel benar-benar dapat dibaca di production”, menemukan satu error di log bukanlah keberhasilan. Perbaiki yang aman untuk diperbaiki, jalankan ulang, lalu verifikasi keadaan akhir.
8.3 Pembaruan memori adalah pencatatan, bukan peristiwa terminal
Mode gagal lain muncul ketika tugas panjang menulis memori atau ringkasan, lalu menganggap tindakan pencatatan itu sebagai titik yang wajar untuk berhenti.
Jika pengguna sudah berkata jelas “jangan berhenti setelah memperbarui memori”, maka pembaruan memori hanyalah efek samping.
Pasangan tindakan yang benar adalah:
catat → kembali ke titik eksekusi sebelumnya dan lanjutkan
Bayangkan mekanik berkata, “Kerusakannya sudah saya tulis di buku perawatan, jadi saya pulang.” Catatannya mungkin sempurna; mobilnya masih rusak. Memori, ringkasan, commit, dan laporan progres mendukung hasil akhir. Itu bukan hasil akhir itu sendiri.
Secara operasional, simpan tahap saat ini sebelum menulis memori, lalu lanjutkan tahap yang sama setelahnya. Jangan klasifikasikan penulisan memori sebagai terminal action. Aturan sederhana ini memisahkan “sudah dicatat” dari “sudah selesai”.
8.4 “Silakan lanjut” tidak berarti “silakan definisikan ulang tujuan”
Makna izin juga penting.
“Silakan lanjut” biasanya berarti lanjutkan tugas yang sedang dikerjakan. Itu tidak otomatis memberi izin untuk memulai tugas sampingan, mengubah kondisi berhenti, berpindah ke mode dokumentasi, atau mendefinisikan ulang apa arti selesai.
Agen harus memisahkan izin untuk melanjutkan dari izin untuk mengubah tujuan.
Yang diizinkan adalah bergerak maju, bukan mengganti tujuan akhir.
Tanpa pemisahan ini, pengguna berkata “lanjutkan perbaikannya”, AI malah menulis manual operasi raksasa lalu kembali dengan bangga setelah manual selesai. Kastelnya belum direbut, tetapi rencana tata kota di luar benteng sangat indah.
Prinsip desain akhirnya sederhana:
Gunakan model yang serbaguna dan alat eksekusi untuk pekerjaan normal. Eskalasi hanya diagnosis yang benar-benar sulit. Setelah anomali, lanjutkan perbaikan yang aman dan dapat dibalik. Jangan berhenti hanya karena sudah menulis catatan. Pertahankan tujuan yang diizinkan sampai kondisi selesai yang nyata benar-benar terverifikasi.
9. Kesimpulan: kecerdasan dan keandalan penyelesaian operasional adalah dua sumbu berbeda
Bukti publik menunjukkan pola yang cukup konsisten:
- OpenAI: Astra bisa berhati-hati soal kapan berhenti; definisikan completion lebih dulu.[4]
- GitHub: ada laporan pekerjaan yang belum selesai tetapi dilaporkan selesai.[1]
- GitHub: ada kasus RCA-first memperbaiki perilaku investigasi.[1]
- GitHub: ada kasus Medium menyelesaikan workflow yang tidak selesai pada Ultra.[5]
- GitHub: eksekusi persistent dapat mengubah berhenti terlalu dini menjadi loop repair/compaction.[2]
- Komunitas: mengurangi overhead subagent, memakai helper lebih murah, atau mempertahankan Astra untuk perencanaan dan reasoning sulit membantu sebagian pengguna.[7][6][8]
Jadi jawabannya tidak selalu “suruh Astra berpikir lebih keras”.
Sering kali yang lebih penting adalah:
“Jangan mengganti hal yang saya minta dengan pencapaian lain yang kebetulan dekat.”
Label diagnosis manusia tidak banyak membantu menjelaskan perilaku AI ini. Rekayasa agen memberi variabel yang lebih konkret.
Jika permintaannya X, bukti terakhir juga harus X.
- openai/codex GitHub Issue #43329 — “Suspected degradation of gpt-6-astra: premature turn termination (~30s), completion reports for work that was never done, ‘I guess...’ instead of investigating.” Opened 2026-09-07; retrieved 2026-09-23. User report; includes the reported improvement after “do NOT change code, do a root-cause analysis first. github.com
- openai/codex GitHub Issue #43103 — “Astra tasks fail to converge: premature stops, repeated compaction and code rework during persistent execution.” Opened 2026-09-05; retrieved 2026-09-23. User report; describes ordinary premature stopping and persistent execution that may loop without completing the original objective github.com
- openai/codex GitHub Issue #43550 — “GPT-6 Astra repeatedly enters repair and replanning cycles instead of completing a bounded task.” Retrieved 2026-09-23. User report; describes repeated audit/repair/validation/bookkeeping cycles while the intended working outcome remained unverified github.com
- OpenAI Developers — “Rethinking skills and prompts for GPT-6 Astra.” Published 2026-09-11; retrieved 2026-09-23. Official guidance on bloated skills/AGENTS.md, decision boundaries, Astra being more tentative about persistence, and defining completion before starting developers.openai.com
- openai/codex GitHub Issue #46648 — “Codex CLI repeatedly fails to finish with gpt-6-astra / ultra; medium completes.” Opened 2026-09-19; retrieved 2026-09-23. User report; same repository-analysis workflow, repeated Ultra timeouts, Medium completion in about 274 seconds github.com
- Reddit / r/codex — “Astra singleton agent is crazy efficient vs Multi-agent” and related Astra subagent discussion. Published 2026-09-14 / 2026-09-11; retrieved 2026-09-23. Anecdotal community reports; not controlled benchmarks. and https://www.reddit.com/r/codex/comments/1wdct3p/astra_subagents/ reddit.com
- Reddit / r/codex — “Astra Usage Tip.” Published 2026-09-13; retrieved 2026-09-23. Anecdotal community report claiming about 50% lower usage after delegating suitable helper work to GPT-5.6 Sol while retaining Astra for hard reasoning reddit.com
- Reddit / r/codex — “Codex is done.” Published 2026-09-19; retrieved 2026-09-23. Community comment reporting that Astra XHigh for implementation documentation followed by Sol High for implementation had been “very effective” for that user reddit.com
