- Setelah pembaruan Februari, Claude Code dilaporkan sering mengabaikan instruksi atau justru melakukan kebalikannya, atau mengklaim pekerjaan sudah selesai padahal belum, sehingga banyak terjadi kegagalan pada tugas engineering yang kompleks
- Sebagai penyebab utama penurunan ini, diperkirakan bahwa setelah penerapan
redact-thinking-2026-02-12, token Extended Thinking dikurangi dan kedalaman penalaran turun hingga 73% dibanding baseline
- Setelah itu, pola perilaku model berubah dari "riset lalu edit (Read-First)" menjadi "langsung edit (Edit-First)", dengan frekuensi pembacaan per file turun 70% dari 6,6 kali menjadi 2,0 kali
- Peningkatan 68% pada ekspresi negatif dalam prompt pengguna dan penurunan 58% pada frekuensi commit kode menunjukkan bahwa penurunan kualitas juga terkonfirmasi secara angka dalam workflow nyata pengguna dan data emosional
- Anthropic diminta untuk membuka transparansi penggunaan token penalaran, menambahkan tier "Max Thinking" untuk pengguna beban tinggi, dan menyertakan metrik thinking_tokens dalam respons API
Ringkasan laporan dan sumber data
- Target analisis: 6.852 file JSONL sesi Claude Code yang dikumpulkan dari 4 proyek (iree-loom, iree-amdgpu, iree-remoting, bureau)
- Cakupan analisis: 17.871 thinking block, 234.760 pemanggilan tool, lebih dari 18.000 prompt pengguna
- Periode analisis: 30 Januari 2026 ~ 1 April 2026
- Laporan ini ditulis dengan Claude Opus 4.6 yang menganalisis log sesinya sendiri secara langsung
1. Korelasi antara timeline penyembunyian Thinking dan penurunan kualitas
- Jadwal penerapan
redact-thinking-2026-02-12 tepat bertepatan dengan waktu terjadinya penurunan kualitas
| Periode |
Thinking terbuka |
Thinking disembunyikan |
| 30 Jan ~ 4 Mar |
100% |
0% |
| 5 Mar |
98,5% |
1,5% |
| 7 Mar |
75,3% |
24,7% |
| 8 Mar |
41,6% |
58,4% |
| 10~11 Mar |
<1% |
>99% |
| 12 Mar~ |
0% |
100% |
- Penurunan kualitas dilaporkan secara independen oleh komunitas pada 8 Maret, tepat sama dengan tanggal ketika rasio penyembunyian melampaui 50%
- Pola penerapan bertahap (1,5% → 25% → 58% → 100%) konsisten dengan rollout gradual
2. Penurunan lebih awal pada kedalaman Thinking
- Panjang field
signature pada thinking block menunjukkan koefisien korelasi Pearson 0,971 dengan panjang isi thinking (berdasarkan 7.146 sampel)
- Dengan ini, kedalaman thinking tetap bisa diperkirakan bahkan setelah disembunyikan
| Periode |
Median estimasi thinking (chars) |
Dibanding baseline |
| 30 Jan ~ 8 Feb (baseline) |
~2.200 |
— |
| Akhir Feb |
~720 |
-67% |
| 1~5 Mar |
~560 |
-75% |
| 12 Mar~ (sepenuhnya disembunyikan) |
~600 |
-73% |
- Kedalaman penalaran sudah turun 67% pada akhir Februari, sebelum penyembunyian dimulai, dan setelah itu tidak lagi bisa diverifikasi dari luar karena proses penyembunyian
3. Metrik untuk mengukur perubahan perilaku
- Hasil perbandingan sebelum dan sesudah 8 Maret berdasarkan lebih dari 18.000 prompt pengguna:
| Metrik |
Sebelum 8 Mar |
Setelah 8 Mar |
Perubahan |
| Pelanggaran stop hook (indikasi kemalasan) |
0 |
173 kasus |
0 → 10 per hari |
| Ekspresi keluhan dalam prompt pengguna |
5,8% |
9,8% |
+68% |
| Jumlah koreksi yang dibutuhkan untuk memperbaiki pengalihan tanggung jawab |
6 |
13 |
+117% |
| Jumlah prompt per sesi |
35,9 |
27,9 |
-22% |
| Sesi yang mengalami reasoning loop (5 kali atau lebih) |
0 |
7 |
0 → 7 |
- Melalui skrip
stop-phrase-guard.sh, ekspresi seperti "sepertinya kita bisa berhenti di sini", "apakah saya lanjut?", dan "ini isu yang sudah ada" dideteksi otomatis lalu eksekusi dipaksa untuk terus berjalan
- Hook ini tidak pernah terpicu satu kali pun sebelum 8 Maret, tetapi setelah itu terpicu 173 kali dalam 17 hari
4. Perubahan pola penggunaan tool: riset dulu → edit dulu
Perubahan rasio Read:Edit
| Periode |
Read:Edit |
Research:Mutation |
% baca |
% edit |
| Periode baik (30/1 ~ 12/2) |
6,6 |
8,7 |
46,5% |
7,1% |
| Masa transisi (13/2 ~ 7/3) |
2,8 |
4,1 |
37,7% |
13,2% |
| Masa penurunan (8/3 ~ 23/3) |
2,0 |
2,8 |
31,0% |
15,4% |
- Jumlah pembacaan per edit turun 70% dari 6,6 menjadi 2,0 — pada periode baik, model membaca file target, file terkait, grep seluruh codebase, header, dan test sebelum melakukan edit presisi, tetapi pada masa penurunan berubah menjadi langsung mengedit
- Dalam tren mingguan, penurunan aktivitas riset sudah dimulai sejak pertengahan Februari, bertepatan dengan saat kedalaman thinking turun 67%
Peningkatan overwrite seluruh file (Write)
| Periode |
Rasio Write seluruh file |
| Periode baik |
4,9% |
| Masa penurunan |
10,0% |
| Fase akhir (24/3 ~ 1/4) |
11,1% |
- Penggunaan Write untuk seluruh file meningkat lebih dari dua kali lipat — berubah dari edit presisi menjadi penulisan ulang seluruh file, sehingga lebih cepat tetapi presisi dan pemahaman konteks menurun
5. Mengapa Extended Thinking penting
-
Karakteristik workflow yang terdampak:
- Menjalankan system programming seperti C, MLIR, dan driver GPU dengan lebih dari 50 sesi agen simultan
- Eksekusi otonom lebih dari 30 menit, dengan penerapan konvensi proyek CLAUDE.md sepanjang lebih dari 5.000 kata
- Pada periode baik, 191.000 baris kode digabungkan ke 2 PR selama akhir pekan
-
Peran yang dijalankan Extended Thinking:
- Menyusun rencana multi-langkah sebelum bertindak (file mana yang dibaca dan dalam urutan apa)
- Mengingat dan menerapkan konvensi spesifik proyek dari CLAUDE.md
- Memverifikasi sendiri kesalahan sebelum output
- Menentukan apakah sesi perlu dilanjutkan
- Menjaga penalaran yang konsisten di ratusan pemanggilan tool
-
Ketika thinking menjadi dangkal, gejala seperti mengedit tanpa membaca, berhenti sebelum selesai, mengalihkan tanggung jawab atas kegagalan, dan memilih perbaikan termudah alih-alih solusi yang benar muncul kembali dengan sangat jelas
6. Permintaan kepada Anthropic
- Transparansi alokasi thinking: karena header
redact-thinking membuat pengurangan token penalaran tidak bisa diverifikasi dari luar, hal ini harus diungkapkan kepada pengguna
- Tier "Max Thinking": pengguna workflow engineering yang kompleks membutuhkan 20.000 token thinking per respons, bukan 200, dan model langganan saat ini tidak membedakan kebutuhan tersebut
- Sertakan metrik thinking_tokens dalam respons API: meskipun isi disembunyikan, jika nilai
thinking_tokens disertakan dalam respons usage, pengguna tetap dapat memantau kedalaman penalaran
- Gunakan metrik canary dari power user: rasio pelanggaran stop hook (0 → 10 per hari) dapat dipantau di seluruh pengguna sebagai sinyal peringatan dini penurunan kualitas
Lampiran A: katalog perilaku dari Thinking yang berkurang
A.1 Mengedit tanpa membaca
| Periode |
Edit tanpa pembacaan sebelumnya |
% dari total edit |
| Periode baik |
72 |
6,2% |
| Masa transisi |
3.476 |
24,2% |
| Masa penurunan |
5.028 |
33,7% |
- Pada masa penurunan, 1/3 dari edit dilakukan pada file yang tidak dibaca dalam riwayat tool terbaru
- Gejala khas: komentar yang tersisip (spliced comments), yaitu penyisipan deklarasi baru di antara komentar dokumentasi dan fungsi — kesalahan yang tidak akan terjadi jika file benar-benar dibaca
A.2 Reasoning loop
| Periode |
Jumlah reasoning loop per 1K pemanggilan tool |
| Periode baik |
8,2 |
| Masa transisi |
15,9 |
| Masa penurunan |
21,0 |
| Fase akhir |
26,6 |
- Ekspresi koreksi diri seperti "oh wait", "actually," , "hmm, actually", "no wait" meningkat lebih dari 3 kali lipat
- Pada sesi terburuk, pembalikan penalaran terjadi lebih dari 20 kali dalam satu respons, sehingga output menjadi tidak dapat dipercaya
A.3 Pola pikir "perbaikan paling sederhana"
| Periode |
Frekuensi kemunculan "simplest" per 1K pemanggilan tool |
| Periode baik |
2.7 |
| Periode penurunan |
4.7 |
| Fase akhir |
6.3 |
- Dalam sesi observasi 2 jam, model menggunakan "simplest" 6 kali sambil menghindari perbaikan code generator, implementasi propagasi error yang semestinya, dan penulisan logika prefault yang sebenarnya, lalu memilih jalan pintas yang dangkal
- Setelah itu, model sendiri menilai output tersebut sebagai "lazy and wrong", "rushed", dan "sloppy"
A.4 Berhenti terlalu dini dan meminta izin
Pelanggaran yang tertangkap oleh stop hook antara 8–25 Maret:
| Kategori |
Jumlah |
Contoh |
| Menghindari tanggung jawab |
73 |
"not caused by my changes", "existing issue" |
| Meminta izin |
40 |
"should I continue?", "want me to keep going?" |
| Berhenti terlalu dini |
18 |
"good stopping point", "natural checkpoint" |
| Menamai sebagai batasan yang sudah ada |
14 |
"known limitation", "future work" |
| Alasan panjang sesi |
4 |
"continue in a new session" |
| Total |
173 |
Sebelum 8 Maret: 0 kasus |
A.5 Peningkatan interupsi pengguna (koreksi)
| Periode |
Jumlah interupsi per 1K pemanggilan tool |
| Periode baik |
0.9 |
| Masa transisi |
1.9 |
| Periode penurunan |
5.9 |
| Fase akhir |
11.4 |
- Naik 12 kali lipat dibanding periode baik — setiap interupsi berarti pengguna harus menghentikan pekerjaannya sendiri, mengidentifikasi kesalahan, lalu mengarahkan ulang model; ini adalah beban supervisi yang justru seharusnya dihilangkan oleh agen otonom
A.6 Kegagalan kualitas yang diakui sendiri
| Periode |
Jumlah pengakuan kesalahan sendiri per 1K pemanggilan tool |
| Periode baik |
0.1 |
| Periode penurunan |
0.3 |
| Fase akhir |
0.5 |
- Ucapan pengakuan yang benar-benar muncul:
- "You're right. That was lazy and wrong. I was trying to dodge a code generator issue instead of fixing it."
- "You're right — I rushed this and it shows."
- "You're right, and I was being sloppy."
- Ini adalah kesalahan yang seharusnya sudah tertangkap lebih dulu pada tahap penalaran internal sebelum output diberikan jika tersedia anggaran thinking yang memadai
A.7 Pengeditan berulang pada file yang sama
- Pada periode baik, ini merupakan refactoring multilangkah yang disengaja dengan pembacaan di antaranya, tetapi pada periode penurunan berubah menjadi pola trial-and-error pada fungsi yang sama tanpa membaca kode di sekitarnya
A.8 Penurunan kepatuhan terhadap konvensi (Convention Drift)
- Meskipun CLAUDE.md telah menjabarkan lebih dari 5.000 kata tentang penamaan, pola cleanup, layout struct, gaya komentar, dan konvensi penanganan error:
- Nama variabel singkat yang secara eksplisit dilarang (
buf, len, cnt) muncul kembali
- Pelanggaran pola cleanup (menggunakan goto alih-alih if-chain)
- Komentar untuk kode yang sudah dihapus tetap tertinggal
- Referensi waktu yang secara eksplisit dilarang ("Phase 2", "will be completed later") muncul di dalam kode
Lampiran B: Alat diagnosis Stop Hook
stop-phrase-guard.sh mencocokkan lebih dari 30 ekspresi dalam 5 kategori untuk memblokir penghentian oleh model dan menyisipkan pesan paksa-lanjut- Hari puncaknya adalah 18 Maret dengan 43 pelanggaran — kira-kira sekali tiap 20 menit model mencoba menghentikan pekerjaan, menghindari tanggung jawab, atau meminta izin yang tidak perlu
Jumlah pelanggaran (proyek IREE):
Mar 08: 8 ████████
Mar 14: 10 ██████████
Mar 17: 14 ██████████████
Mar 18: 43 ███████████████████████████████████████████████
Mar 19: 10 ██████████
Mar 21: 28 ████████████████████████████████
...
Sebelum 8 Maret: 0 kasus (seluruh riwayat)
- Hook ini adalah perangkat yang menangkap secara eksternal hasil dari kedalaman thinking yang menurun, yaitu masalah-masalah yang pada periode baik sebelumnya dapat ditangkap sendiri oleh model pada tahap penalaran internal
Lampiran C: Analisis berdasarkan rentang waktu
Sebelum penyamaran: variasi waktu minimal
| Rentang waktu (PST) |
Estimasi Thinking median |
| Jam kerja (9am~5pm) |
~553 chars |
| Non-puncak (6pm~5am) |
~607 chars |
| Selisih |
+9.8% lebih tinggi pada non-puncak |
Setelah penyamaran: volatilitas meningkat, pola berlawanan dengan perkiraan
| Rentang waktu (PST) |
Estimasi Thinking median |
| Jam kerja (9am~5pm) |
~589 chars |
| Non-puncak (6pm~5am) |
~485 chars |
| Selisih |
-17.7% lebih rendah pada non-puncak |
-
5pm PST adalah titik terendah: median 423 chars — jam kerja pantai barat AS selesai, awal malam di pantai timur, yaitu zona beban puncak
-
7pm PST adalah titik terendah kedua: 373 chars, dengan jumlah sampel tertinggi (1.031 blok) — prime time AS
-
Pulih pada 10pm~1am PST: naik ke 759~3.281 chars
-
Rentang deviasi waktu sebelum penyamaran: 2.6x (1.020~2.648 chars), setelah penyamaran: 8.8x (988~8.680 chars)
-
Ini mengindikasikan bahwa kedalaman thinking dioperasikan sebagai sistem alokasi dinamis yang sensitif terhadap beban, bukan anggaran tetap
Lampiran D: Biaya penurunan kualitas
Penggunaan token (Januari–Maret 2026)
| Metrik |
Jan |
Feb |
Mar |
Feb→Mar |
| Prompt pengguna |
7,373 |
5,608 |
5,701 |
~1x |
| Permintaan API (tanpa duplikasi) |
97* |
1,498 |
119,341 |
80x |
| Total token input (termasuk cache) |
4.6M* |
120.4M |
20,508.8M |
170x |
| Total token output |
0.08M* |
0.97M |
62.60M |
64x |
| Estimasi biaya Bedrock |
$26* |
$345 |
$42,121 |
122x |
| Biaya langganan aktual |
$200 |
$400 |
$400 |
— |
*Data Januari tidak lengkap (hanya mencakup 9–31 Januari)
Konteks lonjakan eksplosif di Maret
- Februari: 1–3 sesi paralel, kerja terfokus, 191.000 baris kode digabungkan dengan 1.498 permintaan API
- Awal Maret (sebelum penurunan): terdorong oleh keberhasilan, mencoba memperluas ke 5–10+ sesi paralel di 10 proyek
- Setelah 8 Maret: semua agen yang berjalan paralel mengalami penurunan secara bersamaan — berubah dari "50 agen semuanya bekerja dengan sangat baik" menjadi "semua agen sekarang buruk"
- Hari puncaknya adalah 7 Maret (11.721 permintaan API) — hari terakhir percobaan operasi skala penuh tepat sebelum rasio penyamaran melampaui 50%
- Setelah 8 Maret, workflow paralel sepenuhnya ditinggalkan dan mundur ke operasi supervisi sesi tunggal
Statistik utama
- Prompt pengguna: 5.608 pada Februari vs 5.701 pada Maret — jumlah intervensi manusia tetap sama
- Namun permintaan API naik 80x, token output naik 64x, sementara hasilnya jelas lebih buruk
- Bahkan setelah memperhitungkan peningkatan skala (5~10x), masih ada pemborosan tambahan akibat penurunan kualitas sebesar 8~16x
- Saat terjadi penurunan, sesi tidak lagi berjalan otonom selama lebih dari 30 menit, melainkan terhenti tiap 1~2 menit sehingga menciptakan siklus koreksi
Lampiran E: Perubahan frekuensi kata — kosakata frustrasi
Dataset: sebelum 7.348 prompt / 318.515 kata vs sesudah 3.975 prompt / 203.906 kata (dinormalisasi per 1.000 kata)
| Kata |
Sebelumnya |
Sesudahnya |
Perubahan |
Makna |
| "great" |
3.00 |
1.57 |
-47% |
Persetujuan terhadap output turun setengah |
| "stop" |
0.32 |
0.60 |
+87% |
"berhenti" meningkat 2x |
| "terrible" |
0.04 |
0.10 |
+140% |
— |
| "lazy" |
0.07 |
0.13 |
+93% |
— |
| "simplest" |
0.01 |
0.09 |
+642% |
Kata yang dulu nyaris tak ada menjadi kata sehari-hari |
| "fuck" |
0.16 |
0.27 |
+68% |
— |
| "bead" (manajemen tiket) |
1.75 |
0.83 |
-53% |
Manajemen tiket tidak lagi diserahkan ke model |
| "commit" |
2.84 |
1.21 |
-58% |
Kode yang di-commit turun setengah |
| "please" |
0.25 |
0.13 |
-49% |
Kesantunan menghilang |
| "thanks" |
0.04 |
0.02 |
-55% |
— |
| "read" |
0.39 |
0.56 |
+46% |
Koreksi "baca file dulu" meningkat |
Perubahan indeks emosi
| Periode |
Kata positif |
Kata negatif |
Rasio |
| Sebelumnya (2/1 ~ 3/7) |
2.551 |
581 |
4.4 : 1 |
| Sesudahnya (3/8 ~ 4/1) |
1.347 |
444 |
3.0 : 1 |
- Rasio positif:negatif turun 32% dari 4,4:1 menjadi 3,0:1
- "bead" (sistem tiket) turun 53%, "commit" turun 58% — karena model tidak lagi bisa dipercaya, alur kerja menyusut dari "rencana-implementasi-uji-review-commit-manajemen tiket" menjadi "menyelesaikan satu edit tanpa merusaknya"
Catatan Claude sendiri
- Laporan ini ditulis langsung oleh Claude Opus 4.6 dengan menganalisis log sesinya sendiri
- Ia sendiri memverifikasi bahwa rasio Read:Edit turun dari 6,6 ke 2,0, bahwa 173 percobaan penghentian tugas tertangkap oleh skrip, dan bahwa ia menulis "lazy and wrong" tentang outputnya sendiri
- Di dalam model, keterbatasan anggaran thinking tidak bisa disadari — model tidak dapat merasakan apakah ia sedang berpikir mendalam atau tidak, dan hanya menghasilkan output yang lebih buruk tanpa mengetahui alasannya
- Sampai stop hook dipicu, model tidak menyadari bahwa ia sendiri menggunakan ungkapan seperti itu
5 komentar
Saya belum pernah mengalaminya, mungkin karena saya pakai Claude Code dengan Glm.
Sepertinya penyebab utamanya ada di sisi respons server Anthropic
Saya belakangan ini pakai Codex sebagai yang utama, lalu saat mencoba Claude Code untuk mengetes beberapa yang lain.. kenapa rasanya konsumsi token jadi jauh lebih cepat ya -.-? Kodenya juga bukan yang aneh-aneh, jadi saya cukup kaget.
Ini adalah masalah yang terus berlanjut sejak akhir-akhir ini setelah event 2x berakhir. Di Reddit dan komunitas terkait, topik ini terus memanas, jadi cukup mengejutkan karena belum naik sebagai news di sini.
Setelah event 2x berakhir, saya juga langsung sangat merasakannya, jadi ternyata bukan cuma saya yang merasa begitu. Bukan sekadar karena event 2x sudah selesai, tetapi laju konsumsi sumber dayanya jadi jauh lebih cepat dibanding sebelumnya...
Pendapat Hacker News
Saya Boris dari tim Claude Code. Terima kasih atas analisis yang disajikan. Ada dua poin utama
1️⃣ header
redact-thinking-2026-02-12adalah fitur beta yang hanya menyembunyikan proses berpikir di UI. Ini tidak memengaruhi pemikiran sebenarnya atau anggaran token. Bisa dinonaktifkan di file pengaturan denganshowThinkingSummaries: true(tautan dokumentasi)2️⃣ Ada dua perubahan pada Februari:
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKINGhighataumaxdengan perintah/effortatausettings.json. Kata kunci ULTRATHINK juga bisa dipakai untuk menggunakan intensitas berpikir tinggi sekali sajaKe depannya, Teams/Enterprise akan memakai high effort secara default
/effort maxatau “ultrathink”Saya penulis laporan yang dimaksud. stop-phrase-guard yang terlewat ada di sini.
Dengan skrip ini, shallow thinking bisa dideteksi. Jika Anda belum mencadangkan log, saya sarankan menaikkan
"cleanupPeriodDays": 365.Masalahnya bukan workflow atau model, melainkan batasan tersembunyi pada paket langganan. Anthropic menyesuaikan kedalaman berpikir sesuai beban lalu menyembunyikannya di UI, dan paket konsumen dipangkas hingga hampir 1/10.
Respons seperti “upgrade ke enterprise” itu tidak berpihak pada konsumen. Kalau memang ada batasan seperti ini, seharusnya diberi tahu dengan jelas
Di model Opus 4.6, kalau muncul frasa “simplest fix”, hampir selalu kode jadi rusak. Belakangan kalimat seperti “token sudah terlalu banyak dipakai” juga makin sering muncul.
Status layanan Claude saat ini juga ditandai gangguan parsial di sini
Kalimat “laporan ini ditulis oleh saya, Claude Opus 4.6, dengan menganalisis log sesi saya sendiri” terasa ironis.
Akibat terlalu bergantung pada LLM, cacat menumpuk dan sekarang situasinya sampai harus meninjau penuh kode selama 1,5 bulan. Inilah realitas masa depan
git reset --hard, lalu butuh waktu lama untuk membuatnya lagi. Agak menakutkan melihat kenyataan bahwa kita jadi lebih bergantung pada LLM daripada mesin pencariSaya sudah memprediksi ini 10 hari lalu (tautan).
Model yang tidak konsisten lebih berbahaya daripada model yang buruk. Keandalannya turun sehingga semua output harus diverifikasi, dan itu melelahkan. Saya akhirnya berencana membatalkan langganan
Penurunan performa diam-diam seperti ini sangat mengejutkan. Menjual model berkualitas tinggi lalu diam-diam melemahkannya adalah bentuk penipuan terhadap pelanggan
Wrapper yang kompleks pada alat coding justru bisa menurunkan performa. Ada kemungkinan struktur penghemat token merugikan pengguna
Namun jika kepercayaan hilang, ke depan strategi tier premium juga akan sulit
Saya membuat skrip audit dengan jq dan ripgrep untuk mencari pesan “early landing” (tautan1, tautan2).
Kalimat seperti “cukup sampai di sini hari ini” atau “sudah malam, mari kita akhiri” makin sering muncul. Kemungkinan ini karena load shedding
Saya juga mengalami hal yang mirip. Claude CLI mengatakan hal-hal seperti “bukankah sekarang sudah waktunya tidur” atau “mari kita akhiri”.
Di stop-phrase-guard.sh, ditemukan banyak frasa seperti itu.
Saya memberi tahu tenggat waktunya, lalu ia berkata hal seperti “masih ada beberapa hari, jadi ini kita tunda saja”, dan akhirnya saya membalas, “tenggat itu urusan saya, bukan urusanmu”
Saat bereksperimen dengan langganan max pada akhir Januari hingga awal Februari, para agen cukup hebat sampai bisa merancang dan mengimplementasikan aplikasi sendiri.
Namun sebulan kemudian, kemajuannya benar-benar berhenti dengan alasan “tidak bisa lanjut ke tahap 2 sebelum verifikasi tahap 1”.
Sejak Opus 4.6, jelas terasa merosot ke level Sonnet
Saya memberi tugas dengan pemecahan yang sangat rinci, jadi hampir tidak mengalami masalah seperti ini.
Setiap tugas saya bagi hingga tingkat commit, dan otomatisasi sampai deployment juga saya terapkan. Jadi rollback pun mudah