Perubahan workflow coding
- Pada November 2024, komposisinya adalah 80% manual+autocomplete dan 20% agent coding, tetapi pada Desember rasio ini berbalik menjadi 80% agent coding dan 20% revisi/touch-up
- Secara praktis, ini menjadi situasi programming dalam bahasa Inggris, yaitu memberi instruksi secara verbal kepada LLM tentang kode apa yang harus ditulis
- Ada bagian yang terasa memukul ego, tetapi kemampuan menangani software dalam unit "aksi kode" berskala besar sangatlah berguna
- Jika beradaptasi dengannya, mengaturnya, mempelajari cara pakainya, dan memahami apa yang bisa/tidak bisa dilakukan, hasilnya jadi lebih efektif
- Ini adalah perubahan paling besar pada workflow coding dasar dalam sekitar 20 tahun karier pemrograman, dan itu terjadi hanya dalam beberapa minggu
- Diperkirakan hal serupa sedang terjadi pada cukup banyak engineer (persentase dua digit), tetapi kesadaran publik umum tampaknya masih di kisaran persentase satu digit awal
IDE / agent swarm / kemungkinan error
- Hype seperti "tidak perlu IDE lagi" atau "agent swarm" menurutnya masih berlebihan untuk saat ini
- Model masih membuat kesalahan, dan jika ada kode yang benar-benar penting maka harus diawasi dengan mata elang, sehingga tetap perlu membuka IDE besar di sampingnya
- Sifat kesalahannya berubah: bukan lagi sekadar syntax error, melainkan kesalahan konseptual yang halus seperti yang mungkin dibuat developer junior yang agak ceroboh dan tergesa-gesa
- Jenis error yang paling umum: membuat asumsi yang salah atas nama pengguna lalu langsung melanjutkan tanpa konfirmasi
- Masalah tambahan:
- tidak mampu mengelola kebingungan
- tidak meminta klarifikasi
- tidak mengungkap ketidakkonsistenan
- tidak menyajikan trade-off
- tidak membantah saat seharusnya membantah
- masih agak cenderung sycophantic
- Dalam plan mode hasilnya lebih baik, tetapi tetap dibutuhkan plan mode inline yang ringan
- Ada juga kecenderungan terlalu mengomplekskan kode dan API, membengkakkan abstraksi, serta tidak membersihkan dead code setelah pekerjaan selesai
- Terkadang ia mengimplementasikan struktur yang tidak efisien, gemuk, dan rapuh sepanjang 1000 baris, lalu ketika ditanya, "bukankah ini bisa dilakukan seperti ini?" ia langsung menjawab, "tentu saja!" dan memangkasnya menjadi 100 baris
- Masih ada kasus di mana ia mengubah/menghapus komentar dan kode yang tidak disukai atau tidak cukup dipahami, walau tidak relevan dengan tugas
- Masalah-masalah ini tetap muncul bahkan setelah memasukkan instruksi ke CLAUDE.md dan mencoba perbaikan sederhana
- Meski begitu, ini tetap merupakan peningkatan yang sangat besar, dan sangat sulit kembali ke coding manual
- Workflow saat ini: beberapa sesi Claude Code di window/tab ghostty di sisi kiri, dan IDE di sisi kanan untuk memeriksa kode serta mengedit manual
Kegigihan
- Sangat menarik melihat agent terus menempel pada suatu masalah tanpa henti
- Ia tidak lelah dan tidak patah semangat, terus mencoba bahkan dalam situasi yang bagi manusia mungkin sudah lama ditinggalkan untuk dikerjakan nanti
- Menyaksikannya bergulat dengan sesuatu dalam waktu lama lalu akhirnya berhasil setelah 30 menit terasa seperti momen "merasakan AGI"
- Ini membuat kita sadar bahwa stamina adalah bottleneck utama pekerjaan, dan saat memegang LLM, kapasitas ini meningkat drastis
Peningkatan kecepatan
- Tidak jelas bagaimana mengukur "speed-up" dari bantuan LLM
- Hal yang tadinya ingin dikerjakan memang terasa jauh lebih cepat, tetapi efek utamanya adalah jadi mengerjakan jauh lebih banyak hal daripada rencana awal:
- berbagai hal yang dulu tidak layak untuk dikoding kini menjadi layak dibuat
- kini bisa menyentuh kode yang sebelumnya tidak bisa dikerjakan karena keterbatasan pengetahuan/skill
- Ini memang speed-up, tetapi kemungkinan lebih besarnya adalah expansion
Leverage
- LLM sangat unggul dalam menjalankan loop sampai tujuan tertentu terpenuhi, dan di situlah sebagian besar keajaiban yang terasa seperti "AGI" berada
- Jangan beri tahu secara rinci apa yang harus dilakukan; berikan kriteria keberhasilan lalu amati
- Biarkan ia menulis test terlebih dahulu lalu membuatnya lulus
- Masukkan Browser MCP ke dalam loop
- Minta ia menulis algoritme naif yang kemungkinan sangat akurat lebih dulu, lalu minta optimasi tanpa mengorbankan akurasi
- Jika pendekatan diubah dari imperatif ke deklaratif, agent bisa menjalankan loop lebih lama dan menghasilkan leverage yang lebih besar
Keseruan
- Hal yang tidak terduga adalah pemrograman menjadi lebih menyenangkan ketika bersama agent
- Pekerjaan membosankan ala mengisi bagian kosong hilang, dan yang tersisa adalah bagian kreatifnya
- Kebuntuan/stagnasi (fase yang tidak menyenangkan) berkurang, dan terasa lebih berani — karena selalu ada cara untuk terus membuat kemajuan positif bersama
- Ada juga orang yang merasakan sebaliknya: coding dengan LLM akan membelah antara engineer yang suka aktivitas coding itu sendiri dan engineer yang suka membuat sesuatu
Atrofi
- Ia menyadari kemampuan menulis kode secara manual mulai mengalami atrofi secara perlahan
- Generasi (menulis kode) dan diskriminasi (membaca kode) adalah kemampuan yang berbeda di otak
- Karena banyak detail sintaks kecil dalam pemrograman, seseorang bisa kesulitan menulis tetapi tetap bisa melakukan code review tanpa masalah
Slopacolypse
- Ia memperkirakan 2026 akan menjadi tahun Slopacolypse — banjir konten AI berkualitas rendah — di GitHub, Substack, arXiv, X/Instagram dan pada dasarnya di semua media digital
- Di luar perbaikan nyata yang sesungguhnya, akan muncul jauh lebih banyak teater produktivitas AI yang penuh hype (kalau itu masih mungkin)
Pertanyaan
- Apa yang sedang terjadi pada "engineer 10X"? — bagaimana rasio produktivitas antara engineer rata-rata dan engineer terbaik? Ada kemungkinan rasio ini meningkat tajam
- Dengan dibekali LLM, apakah generalis akan semakin mengungguli spesialis? LLM jauh lebih hebat dalam mengisi kekosongan (mikro) daripada strategi besar (makro)
- Seperti apa rasa coding dengan LLM di masa depan? Apakah seperti bermain StarCraft? Atau seperti bermain Factorio, atau memainkan musik?
- Seberapa banyak bagian masyarakat yang menjadi bottleneck karena kerja pengetahuan digital?
TLDR
- Kemampuan agent LLM seperti Claude dan Codex sekitar Desember 2025 melewati semacam ambang konsistensi, memicu phase shift dalam software engineering dan bidang terkait
- Bagian kecerdasannya terasa tiba-tiba jauh melampaui hal-hal lain — integrasi (tools, knowledge), kebutuhan akan workflow organisasi baru, proses, dan adopsi yang lebih luas
- Tahun 2026 akan menjadi tahun berenergi tinggi saat industri mencerna kemampuan baru ini
15 komentar
Tampaknya juga telah dirilis versi skills yang meningkatkan cara kerja Claude Code berdasarkan isi tulisan ini.
Karpathy-Inspired Claude Code Guidelines : https://github.com/forrestchang/andrej-karpathy-skills
Ini pertanyaan yang terus terlintas, tetapi bagi orang yang sudah terbiasa dengan coding manual, mengawasi LLM memang bagus; namun untuk orang yang baru belajar, rasanya akan sulit menilai apakah ini benar atau tidak jika mereka hanya menatap kode yang dibuat LLM.
Dulu, apakah orang yang menulis dengan assembler juga berpikir seperti, bagaimana mungkin bisa percaya compiler yang mengeluarkan output assembly yang kacau saat compiler pertama kali muncul?
Mungkin saat itu juga, meski menulis dengan C, mereka tetap coding sambil mengarahkan agar output assembly-nya keluar sesuai yang mereka inginkan.
Saya juga penasaran apakah di era AI, jika teknologinya makin maju, hasil akhir yang lengkap nantinya benar-benar bisa keluar dengan baik hanya lewat bahasa alami tanpa pengawasan manusia.
Sepertinya bahkan saat orang masih menulis kode sendiri, kalau tidak belajar kita juga tidak tahu apa yang salah wkwk
Para ahli assembly sampai sekarang masih mengkritik compiler. Pada akhirnya yang penting adalah bahwa dalam situasi yang membutuhkan optimasi ekstrem, spesialis seperti itu memang tetap diperlukan; jika diterapkan ke AI, meski AI berkembang sejauh apa pun, bisa jadi tetap sulit mengalahkan orang yang benar-benar piawai menulis kode pada level ekstrem. Namun secara umum, sudah tidak ada manusia yang bisa mengalahkan AI. Akan menarik kalau ada pertandingan AlphaCode sebagai momen AlphaGo sekali lagi.
Sepertinya tidak masalah jika ada upaya untuk menganalisis dan memahami kode yang dihasilkannya.
Compiler agak berbeda sebagai konsep; karena ia menghasilkan assembly berbasis aturan, itu berada di ranah deterministik, sehingga setelah ditinjau sekali biasanya masalah yang sama tidak terulang. Namun LLM berada di ranah probabilistik, jadi selalu ada kemungkinan masalah yang sama muncul lagi.
Mungkin akurasi probabilistik ini nantinya akan berkembang hingga mendekati 100 persen, tetapi jika permintaan dalam bahasa alami itu sendiri tidak presisi, pada akhirnya hasilnya juga akan tidak presisi, jadi menurut saya hasil akhir yang
baikpada akhirnya tetap bergantung pada manusia.Saya juga khawatir dengan para junior yang sudah mengenal LLM sejak masih mahasiswa. Saya juga merasa pool perekrutan junior belakangan ini sedikit memburuk, tapi itu pun sulit dibuktikan...
Secara pribadi, saya merasa kalau hanya punya pengetahuan CS saja, bukankah perbedaannya tidak terlalu besar?
Atau mungkin karena cara saya memakainya sekarang terasa seperti pair programming dengan teman yang tangannya sangat cepat dan mengetikkan semua kode untuk saya...
Pada akhirnya, saat mendalami pengembangan, pasti akan tiba saatnya kita perlu memahami bagian dalam dari lapisan abstraksi
Kesenjangan antara prompt bahasa alami dan kode yang dihasilkan terlalu besar, jadi tampaknya sulit untuk masuk dari prompt ke dalam lapisan abstraksi LLM
Saat ini, kita menyampaikan konsep spesifikasi yang ada di kepala kita ke LLM lewat prompt, lalu membaca ulang kode yang ditulis untuk memverifikasinya
Jadi ini terasa lebih seperti meninjau kode yang ditulis orang lain, bukan seperti masuk ke bagian dalam abstraksi
Sepertinya saya terlalu meremehkan 20% itu.
Baru-baru ini saya menemui bug yang tidak bisa diselesaikan AI... memang bukan serba bisa, tapi saya sadar selama ini saya menganggapnya seolah serba bisa.
Aduh... wkwk
Saya sangat setuju. Dalam proyek terbaru, saya telah meng-commit sekitar 100 ribu baris (jumlah kode sebenarnya lebih banyak) dan rata-rata menggunakan 2–3 agen. Sepertinya sekitar 95% ditulis oleh agen.
Namun, pengelolaan terhadap pengujian atau kode mati tetap diperlukan, dan detail tentang kasus uji serta kondisi keberhasilan pengujian juga dibutuhkan. Pengelolaan mengenai apa yang harus dikerjakan dan sampai sejauh mana itu penting. Untuk itu, bukan hanya rencana, tetapi juga arsitektur yang menyediakan harness serta pengaturan seperti Rules perlu terus diperbarui.
Komentar Hacker News
Menarik melihat agen terus mencoba tanpa lelah
GPU dan NPU bekerja panas, dan kita bahkan menyerahkan data yang biasanya tidak akan kita bagikan
Saat ini terlihat seperti pertukaran yang nyaman, tetapi dalam jangka panjang ada risiko membesarnya ketergantungan dan masalah sosial
Pada akhirnya, ini bisa menjadi struktur yang membuat kita bergantung pada gatekeeper raksasa ini
Saat bekerja dengan AI, masalah yang lebih besar daripada penyusutan otak tampaknya adalah berubah menjadi kepuasan diri dan kelesuan
Awalnya dopamin naik karena hasil yang cepat, tetapi semakin berulang, semakin terasa AI menarik arah proyek sesuka hatinya
Pada akhirnya, eksperimen kreatif yang saya inginkan menghilang, dan saya tersedot ke dalam gravitasi ruang laten AI
Ini seperti doomscrolling, sebuah loop adiktif yang membuat kita terus ingin melihat output berikutnya
Saya sedang membuat game multipemain dengan Rust dan Bevy, dan walaupun kodenya berjalan baik, itu menjadi kode yang tidak saya pahami
Dulu saya pasti harus memahami alatnya sepenuhnya untuk bisa sampai sejauh ini, tetapi sekarang saya sudah membuat game yang setengah jadi namun bahkan tidak tahu apa itu ECS
Kalau memikirkan pemeliharaan atau respons darurat, ini benar-benar kondisi yang berbahaya
Sekarang kita fokus mempelajari model, dan mulai lupa cara berpikir sendiri
Cara memakai LLM terus berubah, jadi pada akhirnya kita seperti berdiri di atas treadmill belajar yang tak pernah selesai
Meski ada jeda panjang, rasa dan nalurinya tetap tertinggal, dan saat kembali melakukannya, kemampuan itu cepat kembali
Kalau LLM tidak tahu, mereka langsung menyerah, dan makin banyak developer yang tidak mau membaca dokumentasi
Bahkan ketika dokumentasinya dibaca langsung dan ditunjukkan sampai dengan screenshot, mereka masih meragukan dengan berkata “apa ini benar?”
Demi kepuasan singkat, kita terus melempar prompt dan menunggu “kali ini apa yang akan keluar”
Coding dengan LLM menjadi titik pembeda antara ‘orang yang suka coding’ dan ‘orang yang suka membangun’
Saya tipe builder yang suka menghasilkan sesuatu, jadi perubahan ini menyenangkan
Sebaliknya, orang yang menikmati coding itu sendiri merasa tidak nyaman dengan arus ini
Daya tarik pemrograman ada pada proses menyusun masalah dan mengeksekusinya sendiri
Sekarang rasanya “bukan saya yang coding, melainkan saya yang menyuruh,” jadi minatnya berkurang
Dulu juga ada pertentangan seperti compile vs interpret, typed vs untyped, rilis cepat vs maintainability
Pada akhirnya, software yang berhasil selalu melewati proses berpindah dari tahap awal yang kacau ke tahap perluasan yang stabil
Saya masih belum yakin apakah AI membantu proses ini, atau justru membuatnya lebih rumit
Yang mereka nikmati bukan hanya hasil akhirnya, tetapi proses menyusun struktur sistem
Rekan tim manusia punya tanggung jawab dan kepercayaan, sedangkan LLM tidak
Gagasan bahwa AI dapat membawa peningkatan produktivitas 10x terasa menarik
DevOps mengubah cara kolaborasi antara development dan operations untuk membentuk tim berkinerja tinggi, dan ini menghasilkan efek yang mendekati versi tim dari 10X
Untuk menggunakan AI coding dengan baik, seperti DevOps, dibutuhkan proses membangun kepercayaan lewat perbaikan berkelanjutan, perubahan workflow, serta otomatisasi/verifikasi
Seperti DevOps yang tidak bisa menyebar luas tanpa pembelajaran konsep baru dan perubahan budaya tim, AI coding juga bisa lambat diadopsi meski punya potensi 10X jika tidak ada pembelajaran/perubahan budaya
Untuk bisa mapan, dibutuhkan pendidikan dan perubahan budaya engineering
Saya merasa LLM tidak berguna pada codebase berskala besar
Terutama pada kode yang kompleks dan penuh interaksi, hampir tidak membantu
Memasukkannya ke codebase besar/kompleks yang sudah ada berisiko, kecuali perubahannya terbatas dan ditinjau dengan sangat cermat
Pada struktur sederhana, memberi daftar file dan menyerahkan implementasi ke agen memang mengesankan, tetapi saat kompleksitas naik, prompt harus turun menjadi instruksi yang makin rinci agar hasilnya tetap baik
Berbeda dari model sebelumnya, sekarang ia benar-benar membantu bahkan di monorepo yang kompleks
Bandingkan apakah hasilnya lebih baik daripada anggota tim baru yang bekerja dengan informasi yang sama
Codebase internal komersial menjadi berantakan karena pengembangan berulang yang menyesuaikan kebutuhan pelanggan, asumsi awal dan kebutuhan makin lama makin menyimpang, dan utang teknis pun muncul
Jika Anda memakai LLM untuk merapikan lewat refactor seperti memisahkan helper, modularisasi, atau rename agar sesuai kebutuhan saat ini, setelah itu perilaku agen menjadi lebih mudah diprediksi
Perlu alur bertahap: merapikan requirement/acceptance criteria/user story dalam markdown, lalu menulis rencana secara rinci, dan baru lanjut ke implementasi
Titik saat ketekunan dan stamina AI melampaui batas manusia terasa mengesankan
Bahkan dalam riset, grit lebih terkait dengan keberhasilan daripada kecerdasan
Selama anggaran mengizinkan, LLM punya ketekunan yang nyaris tak terbatas
Dalam beberapa bulan terakhir, performa AI justru terasa seperti mundur
Ia lupa aturan, dan menghasilkan perencanaan berlebihan serta kode yang overengineered
Namun untuk frontend (HTML + Tailwind), tetap berguna
Rasanya ekspektasi berlebihan terhadap IDE atau agent swarm masih terlalu dini
Saat membuat aplikasi iPhone, saya kagum pada kemampuan Claude menghasilkan kode dari prompt bahasa Inggris
> Coding dengan LLM akan membagi engineer menjadi mereka yang menyukai aktivitas coding itu sendiri dan mereka yang menyukai membangun sesuatu.
Kalau saya juga merangkum cerita-cerita yang saya dengar dari sekitar, pada akhirnya memang terasa terbagi seperti ini.