Opus 4.5 benar-benar berbeda dari agen AI mana pun yang pernah saya coba

• Claude Opus 4.5 menunjukkan kemampuan pengembangan otonom yang, tidak seperti agen coding AI sebelumnya, mampu membangun aplikasi berkualitas tinggi tanpa campur tangan developer
• Dari utilitas konversi gambar Windows sederhana hingga alat perekaman dan pengeditan video, aplikasi otomatisasi posting berbasis AI, dan aplikasi pelacakan pesanan serta perhitungan rute, semuanya diselesaikan menjadi proyek yang benar-benar berfungsi dalam waktu singkat
• Opus 4.5 menangani sendiri tugas pengembangan yang kompleks seperti konfigurasi backend Firebase, analisis log error dan perbaikan otomatis, serta pengaturan deployment GitHub Actions
• Penulis mengaku tidak sepenuhnya memahami struktur kodenya, tetapi memastikan bahwa Opus 4.5 menyelesaikan bug sendiri dan bahkan memberi saran refactoring
• Melalui pengalaman ini, penulis menekankan bahwa kemungkinan AI sepenuhnya menggantikan developer kini menjadi nyata, dan ini adalah titik balik era pengembangan yang berpusat pada AI

---

Kemunculan Opus 4.5 dan perbedaannya dari agen AI sebelumnya

• Agen AI sebelumnya sering memiliki produktivitas rendah karena menghasilkan kode yang tidak efisien dan memperbaiki error secara berulang
  • Setelah berkali-kali copy-paste dan membetulkan error, codebase sering kali menjadi rusak
• Opus 4.5 mengatasi masalah ini dengan menulis sebagian besar kode dengan benar sejak awal, lalu saat terjadi error, berulang kali melakukan build dan perbaikan langsung lewat CLI
• Penulis menilainya sebagai “model yang benar-benar mewujudkan janji AI coding”

Proyek 1 – Utilitas konversi gambar Windows

• Opus 4.5 menyelesaikan dalam satu permintaan sebuah utilitas dengan fitur konversi format gambar dari menu klik kanan Windows Explorer
  • Mengotomatiskan proses build dan perbaikan error menggunakan dotnet CLI
  • Hanya error XAML yang dicek lewat Visual Studio lalu disalin dan dikirim
• Termasuk menyiapkan website distribusi, skrip instalasi PowerShell, dan pipeline deployment otomatis GitHub Actions
• Pembuatan logo menggunakan Figma AI, dan Opus menulis konversi SVG serta skrip format ikon

Proyek 2 – Alat perekaman layar dan pengeditan

• Dimulai dari utilitas perekam GIF mirip LICEcap, lalu diperluas hingga mencakup fitur edit video dan gambar
  • Menambahkan bentuk, crop, blur, dan fitur editing lain dalam hitungan jam
• Source code dipublikasikan di GitHub, dan penulis menyebut bahwa “dalam beberapa jam sudah berkembang ke level yang cukup tinggi”
• Ini membuktikan bahwa Opus 4.5 mampu menangani bukan hanya UI tetapi juga pekerjaan integrasi backend

Proyek 3 – Aplikasi otomatisasi posting AI

• Mengembangkan aplikasi mobile berbasis AI yang otomatis memposting ke halaman Facebook dengan Opus 4.5
  • Setelah mengunggah foto, AI melakukan pembuatan caption dan penjadwalan posting
  • Backend Firebase, autentikasi, storage, dan cloud functions dikonfigurasi langsung oleh Opus lewat CLI
• Penulis menjelaskan bahwa saat ia sedang memasang blind, Opus sudah menyelesaikan aplikasinya
• Opus juga menganalisis log error secara otomatis lalu memperbaikinya, bahkan membuat dashboard admin
• Pekerjaan yang sebelumnya memakan waktu berbulan-bulan kini selesai dalam beberapa jam

Proyek 4 – Aplikasi pelacakan pesanan dan perhitungan rute

• Mem-parsing email pesanan dari Gmail untuk otomatis menghitung jadwal, rute, waktu mengemudi, dan catatan jarak tempuh untuk pajak
• Opus 4.5 menangani integrasi autentikasi Google dan koneksi Firebase sekaligus
• Penulis menilai bahwa “pekerjaan yang menyakitkan jika dikerjakan manual dilakukan Opus dengan sempurna”

Pemahaman kode dan masalah kualitas

• Penulis menyebut bahwa meski ia tidak memahami Swift, aplikasinya tetap berjalan sempurna
• Opus 4.5 menemukan dan memperbaiki bug sendiri, sehingga pengembangan tetap berjalan tanpa penulis perlu memahami struktur internal kode
• Menanggapi pertanyaan soal kualitas kode, ia menulis bahwa “jika kode akan dibaca dan dipelihara oleh AI, keterbacaan bagi manusia tidak lagi penting”
• Dengan memakai prompt penulisan kode khusus AI di VS Code, ia menghasilkan kode yang berfokus pada struktur yang mudah dipahami oleh LLM

Prinsip coding yang berpusat pada AI

• Prompt dibuat dengan asumsi “kode akan ditulis dan dipelihara oleh AI”
  • Menekankan struktur sederhana, entry point yang jelas, abstraksi minimal, dan coupling rendah
  • Mengutamakan alur kontrol eksplisit, fungsi sederhana, structured logging, dan kemudahan regenerasi
• Saat refactoring kode, Opus menyusun dokumen item perbaikan berdasarkan prioritas (tinggi/sedang/rendah)
• Saat audit keamanan, penulis memintanya meninjau API key, proses login, dan apakah data sensitif disimpan
  • Tentang kelengkapan keamanan, penulis mengatakan “baru sekitar 80% dan masih terasa tidak aman”

Pergeseran ke era pengembangan AI

• Penulis mengungkapkan bahwa “ada rasa antusias sekaligus hampa melihat kenyataan bahwa semuanya bisa dibuat dalam beberapa jam”
• Dulu ia percaya bahwa “AI tidak bisa menggantikan developer”, tetapi kini mengakui bahwa kemungkinan itu tak bisa lagi disangkal
• Sebagai kesimpulan, ia menekankan agar tidak ragu dan langsung mencoba membangun sesuatu di lingkungan pengembangan yang berpusat pada AI
• Terakhir, ia memperingatkan bahwa pengelolaan API key tetap harus menjadi tanggung jawab sendiri

---

Ringkasan: Opus 4.5 dinilai bukan lagi sekadar asisten coding, melainkan model setingkat developer AI yang mampu merancang, mengimplementasikan, dan men-deploy aplikasi lengkap secara otonom. Melalui pengalaman ini, penulis menyatakan bahwa ia secara langsung menyaksikan kemungkinan realistis AI menggantikan developer manusia.

[wegaia]

Ketika saya meminta Opus 4.5 memperbaiki satu baris kode, saya melihat ia seenaknya menghapus sekitar 10 baris kode konfigurasi di atasnya. Saat saya tanya kenapa dihapus, ia menjawab karena sepertinya itu hanya kode yang tidak bermakna..

[GN⁺]

Pendapat Hacker News

• Pekerjaan yang ditangani insinyur tingkat menengah bukan sekadar membuat aplikasi baru, tetapi merancang struktur dengan mempertimbangkan skalabilitas dan kemudahan dipahami
  Opus 4.5 cukup bagus menangani permintaan tingkat “tolong buatkan satu aplikasi”, tetapi saat diminta menambahkan fitur ke kode yang sudah ada seperti di pekerjaan nyata, ia memakai abstraksi yang aneh atau perlu direvisi berkali-kali agar kualitasnya sesuai harapan
  Orang nonteknis mungkin berpikir “asal jalan sudah cukup”, tetapi insinyur tahu itu tidak cukup

  • Ada dua jenis ‘cara yang benar’ — cara yang sesuai konteks dan cara yang digeneralisasi oleh para insinyur
    Saya ingat dulu dalam tim kami pernah berdebat soal “jawaban yang benar”. Pada akhirnya orang luar harus datang untuk mengingatkan apa yang penting dari sudut pandang bisnis
    Kadang, membuat sesuatu dengan cepat meski agak berantakan untuk memvalidasi arah justru menjadi cara yang benar
    Masalah muncul ketika sejak awal desain dibuat berlebihan, atau sebaliknya ketika manajer menghalangi refactoring. Pada akhirnya keseimbangan adalah kuncinya
  • Melihat proyek-proyek seperti ini, rasanya lebih masuk akal untuk sekadar mem-fork image converter atau clone Minesweeper yang sudah ada di GitHub, jadi penggunaan LLM di sini terlihat hanya untuk menghilangkan jejak hak cipta
  • Ada orang yang berpendapat bahwa “kualitas kode sekarang sudah tidak penting”. Asal lolos tes hari ini sudah cukup, dan kalau besok perlu refactoring total, tinggal pakai lebih banyak kredit lalu buat ulang dalam beberapa jam
  • Saya terkesan melihat Opus 4.5 cukup baik mengikuti pola idiomatik dari codebase yang sudah ada
    Jika secara eksplisit disuruh membaca kode di sekitarnya, hasilnya jauh lebih baik. Menambahkan satu-dua kalimat saja sudah cukup
  • Saat menambahkan fitur ke kode yang ada, jika abstraksi yang diinginkan diarahkan secara langsung, hasilnya membaik secara bertahap
    Meski begitu, secara pribadi saya lebih suka GPT‑5.2

• Banyak insinyur yang meremehkan performa saat ini dari agen LLM seperti Claude Code
  Tim kami sudah mengotomatisasi code review, otomatisasi ESLint, checklist PR, sinkronisasi dokumentasi, hingga pemeriksaan cakupan tes dengan Claude Code
  Klasifikasi tiket juga diproses otomatis, sehingga ketika insinyur mulai bekerja, setengah pekerjaannya sebenarnya sudah selesai
  Contoh repositori ada di claude-code-showcase
  Saya yakin sekitar 2026 ini akan menjadi workflow standar industri

  • Ada perbedaan besar dalam pengalaman memakai LLM antara area frontend (React, HTML, mobile) dan area low-level (OpenGL, io_uring, libev, dll.)
    Opus 4.5 bisa membuat aplikasi JS dengan baik, tetapi jika diminta mengimplementasikan algoritma bayangan dari paper tahun 2003 dalam C++, hasilnya benar-benar kacau
    Bahkan setelah diberi ulasan threading Doom3 BFG oleh Fabien Sanglard, yang keluar tetap kode yang tidak berguna
    Jadi intinya bukan “kami meremehkan LLM”, melainkan “kami menunggu karena itu belum praktis”
  • Banyak orang mencoba AI coding di awal lalu menyerah karena error dan frustrasi
    Tetapi Opus 4.5 berada satu tingkat di atas. Error-nya jauh lebih sedikit dan kebanyakan hanya kesalahan kecil
  • Saat mengajar mahasiswa di kampus, saya bereksperimen dengan Cursor, Claude Code, dan Codex,
    dan berkat AI saya menyelesaikan proyek yang biasanya butuh 2 minggu hanya dalam 5 jam.
    Tanpa AI, saya mungkin bahkan tidak akan mencobanya sama sekali
  • Agak lucu kalau README buatan AI masih menuliskan struktur direktori secara manual, padahal dengan perintah tree semuanya sudah terlihat
  • Ke depan, profesi “programmer” sendiri mungkin akan berkurang, dan kemampuan berkarya dengan memanfaatkan alat akan jadi lebih penting

• Saya sudah banyak memakai Opus 4.5, dan untuk analisis kode yang kompleks ia luar biasa, tetapi tetap belum setara manusia dalam pemecahan masalah
  Misalnya, ia bisa mengidentifikasi algoritma graph layout dengan tepat, tetapi tidak bisa memperbaiki bug-nya sendiri
  Untuk analisis kode dan pelengkap pengetahuan, ini sangat bagus, tetapi pemecahan masalah majemuk masih terlalu berat

  • Copilot punya keterbatasan karena memotong konteks untuk menghemat token
    Jika menginginkan performa yang sesungguhnya, kita harus memakai API langsung, dan biaya untuk satu PR saja bisa mencapai tiga digit
    Referensi: models.dev
  • Copilot menghitung token 3 kali lipat saat memakai Opus 4.5, jadi cukup mengejutkan bahwa setengah kuota bulanan habis hanya dalam seminggu
  • Bahkan jika AI hanya dipakai sebagai alat analisis kode, nilainya sudah besar
    Pembuatan dokumentasi juga lebih baik daripada manusia, dan tingkat error-nya cenderung lebih rendah daripada manusia
  • Jika dipakai lewat tool pihak ketiga, perilakunya berbeda
    Saya merekomendasikan mencoba langsung di VS Code atau Cursor dengan langganan Claude Code

• Selama liburan saya mengerjakan beberapa proyek dengan GPT‑5.x —
  alat otomatisasi Swift, integrasi mesin JIT ARM, prototipe synthesizer, dan lain-lain
  GPT‑5.2 dan lini Codex sekuat Opus, sampai bisa menyusun seluruh workflow CI sekaligus
  Bagi orang seperti saya yang terbiasa merencanakan dan meninjau kode, ini adalah alat pengganda produktivitas

  • GPT‑5.2 cukup sering mengalami halusinasi tentang keberadaan atau fungsi utility CLI
    Saya harus memeriksa source code sebenarnya untuk memastikan kesalahannya
  • Gemini 3 Pro (High) serta tool seperti Antigravity, Amp, dan Junie juga mengesankan
    Saya menyelesaikan library binding Ratatui untuk Ruby dalam 2 minggu
    Antigravity menjalankan beberapa agen secara paralel untuk melakukan kompresi konteks dan manajemen otomatis
    Tool tingkat lanjut seperti ini memberikan pengalaman yang benar-benar berbeda dari versi gratis
    Jika dipadukan dengan tool Unix dan git CLI, konteks bisa dijaga tetap kecil sehingga efisiensinya maksimal
  • LLM kuat untuk kode backend dan CLI, tetapi masih lemah di area yang membutuhkan umpan balik visual seperti frontend HTML/CSS atau JS
    Ia kuat pada input-output yang terstruktur, dan gagal pada bagian yang menuntut “rasa akhir”

• Baru-baru ini saya merasa komentar negatif soal LLM di HN menurun drastis
  Namun sebagian besar proyek yang dibagikan masih berhenti di level demo teknis
  Membangun konteks, yaitu memahami kebutuhan pengguna, tetap merupakan tugas manusia
  Kita bisa membuat beberapa aplikasi dalam satu akhir pekan, tetapi hampir tidak ada orang yang akan memeliharanya

  • Berkurangnya komentar negatif mungkin karena orang lelah dengan perdebatan berulang tentang “model baru 1000 kali lebih baik”
  • Bisa juga karena orang yang membuat produk yang bisa dimonetisasi sedang diam-diam mengembangkan dan tidak membagikannya
  • Deploy ke production dan maintenance membutuhkan upaya yang sangat besar
    Karpathy juga pernah membagikan pengalaman serupa — prototipe itu mudah, tetapi deployment itu sulit
    Untuk tool pribadi, pendekatan yang berfokus pada penyelesaian masalah alih-alih kesempurnaan sudah cukup
  • Justru orang yang memakai AI sering tersendat di 20% terakhir, bagian yang membutuhkan pemikiran integratif
    Jika pemikiran diserahkan ke AI, kemampuan berpikir mandiri kita bisa melemah
  • Bahkan dalam pengembangan game, hukum 80/20 tetap berlaku
    Menguji ide bisa cepat, tetapi mencapai produk yang matang tetap membutuhkan ketekunan manusia

• Dibanding sekadar pengetahuan, Opus 4.5 meningkat jauh dalam kemampuan pemecahan masalah otonom
  Jika masalahnya didefinisikan dengan jelas, hampir semuanya bisa ia selesaikan, bahkan sampai reverse engineering
  Belakangan ini saya lebih sering menulis spesifikasi lalu mengarahkan Opus untuk menjalankan dan memperbaikinya daripada ngoding sendiri

  • Contoh yang dipublikasikan antara lain coding-agent-benchmark dan
    proyek reverse engineering game C64
  • Saya penasaran bagaimana cara mencegah “desain yang berlebihan”
  • Bagi saya, memakai aplikasi web Claude untuk rubber duck debugging lebih efisien
    Claude Code memang kuat karena bisa melihat seluruh codebase, tetapi menghabiskan kuota terlalu cepat
    Jadi saya kembali ke versi web
  • Saya juga belakangan mengerjakan side project hampir dengan cara seperti ini

• Dengan Opus 4.5 saya mencoba membuat interpreter JavaScript berbasis Python, runtime WebAssembly, bahkan porting ke C dari routine pencarian string Rust
  Sebagian besar saya eksperimenkan dari smartphone, dan hasilnya mengejutkan

  • Jika yang dimaksud “interpreter JS yang ditulis dengan Python” berbasis MQJS milik Bellard, sumbernya harus disebutkan
    Referensi: micro-javascript
  • Untuk masalah yang membutuhkan penalaran visual (misalnya algoritma jalur slime mold), ia masih lemah
  • Saya penasaran dengan hasil “routine Rust dipindahkan ke C lalu menjadi lebih cepat”
  • Saya pernah memintanya “tuliskan interpreter Python 3 dalam JavaScript”, dan saya terkejut karena ia bahkan berhasil meloloskan tes
  • Tetapi belakangan saya tidak merasakan perbedaan besar. Modelnya stagnan, sedangkan framework agen tampaknya yang berkembang
    Video contoh: tautan Mastodon

• Alasan sebenarnya developer direkrut adalah tanggung jawab
  Bahkan di masa ketika orang menyalin kode dari StackOverflow atau GitHub, alat bantu sudah ada,
  tetapi saat masalah muncul, yang bertanggung jawab pada akhirnya tetap manusia

  • Sekarang, orang yang bisa memikul tanggung jawab adalah yang paling penting
    Jika ada rekan tepercaya yang berani menaruh namanya pada kode AI, itu tidak masalah
  • Namun industri lebih menghargai orang yang membuat hal baru daripada tanggung jawab
    Maintenance sering diabaikan
  • Sekarang code review real-time menjadi mode default
    Di akhir pekan saya membuat 80% dari sebuah SaaS dengan AI dan hanya menulis bagian intinya sendiri
    Ketika saya menempelkan spesifikasi bahasa yang saya tulis 22 tahun lalu, Opus menyelesaikan parser dan tes dalam 3 menit
    Kita pada akhirnya berada di titik di mana kita harus beradaptasi terhadap perubahan seperti industri pertambangan
  • Karena itu saya lebih nyaman memakai AI sebagai editor dan reviewer daripada penulis
    Kodenya saya tulis sendiri, sedangkan AI menangani pencarian masalah dan usulan tes

• Opus 4.5 sedang membantu saya membuat bahasa pemrograman baru
  Kami mendiskusikan sampai implementasi low-level, hampir seperti pair programming
  Tetapi pada codebase besar, kendali sistemik dari manusia tetap diperlukan
  Kalau tidak, Opus akan mengubah spesifikasi atau menambalnya dengan solusi sementara
  Ini memang bukan solusi serba bisa, tetapi rasanya ini bisa menjadi tahun paling produktif dalam hidup saya
  Pada saat yang sama, jika teknologi seperti ini jadi umum, saya juga berharap akan ada kebangkitan komunitas web kecil

  • Mungkin suatu hari AI akan bisa memelihara kode sendiri,
    tetapi sampai saat itu, menurut saya bahasa yang mudah dipahami manusia akan semakin penting
  • Ada juga pandangan skeptis seperti “apa memang ada gunanya membuat hal seperti itu?”
  • Ada pula respons bercanda seperti “siapa yang akan membeli novel itu?”

• Ketika saya menyuruh Opus 4.5 untuk “perbaiki seluruh proyek”, yang muncul justru arsitektur aneh dan banyak bug
  Ia sangat bagus untuk tes atau deteksi bug, tetapi jika disuruh merancang struktur keseluruhan, hasilnya akan membuat menyesal

  • Sebagai gantinya, lebih efisien jika menyuruhnya “usulkan ide perbaikan”, lalu memilih yang bagus dan meminta Claude menjelaskannya sebelum diimplementasikan
  • Ia bekerja paling baik ketika kita tahu dengan jelas apa yang ingin diperbaiki
    “Coba perbaiki apa saja” adalah prompt terburuk
  • Kasus seperti ini adalah contoh bagus yang menunjukkan kelemahan model
    Dulu pernah ada orang yang membiarkan agen memperbaiki sesuatu semalaman lalu mendapatkan 100 ribu baris kode sampah
    Karena itu pengembangan berbasis perencanaan itu penting
    Referensi: The Highest Quality Codebase
  • Sebagian besar model, termasuk Opus, lemah dalam memperbaiki kode yang sudah ada, tetapi bagus dalam menulis kode baru
  • Dari usulan code review AI, 90% memang tidak berguna, tetapi 10% sisanya benar-benar menangkap masalah nyata
    Rasanya ia juga bisa terus-menerus mengusulkan revisi seperti loop tak berujung