LLM sedang menggerus karier software engineering saya, dan saya tidak tahu harus berbuat apa

• Alat pengembangan berbasis LLM kini terlibat mulai dari penulisan dokumen desain, rencana implementasi, penulisan kode, hingga debugging, sehingga melemahkan diferensiasi dari keahlian backend pembayaran dan finansial yang dibangun selama 10 tahun
• Pengetahuan domain di area finansial dan pembayaran sebelumnya menjadi daya saing berdasarkan pengalaman dengan kepatuhan PCI, buku besar double-entry, escrow, rekonsiliasi, siklus hidup pembayaran, dan idempoten transfer bank, tetapi model mulai menangkap keterkaitan dalam struktur sistem dan memicu guncangan pertama
• Dengan Claude Code, Codex, MCP, DataDog MCP, dan lain-lain, otomatisasi debugging meluas; beberapa bug bisa diselesaikan hanya dari stack trace dan konteks Sentry, lalu akhirnya 90% bug sistem terdistribusi dapat ditangani dalam sekali tembak
• Pilar yang tersisa, yaitu kualitas kode dan arsitektur, juga diperkecil menjadi sekadar “taste”, dan arahnya menuju penerimaan codebase kelas C dan D yang ditangani LLM, alih-alih codebase kelas A dan B yang nyaman dibaca manusia
• Untuk menjaga employability jangka panjang, keahlian harus dipindahkan ke area yang tidak mudah dikuasai LLM, tetapi beralih ke pekerjaan riset dibatasi oleh negara tempat tinggal, ketatnya persaingan lamaran, kondisi keluarga, dan kemungkinan RSI

---

Latar belakang karier

• Seorang software engineer profesional dengan pengalaman 10 tahun; memulai dari web frontend karena debugging terasa lebih mudah, lalu beralih ke backend
• Secara kebetulan mendapat peran pengembangan software di domain finansial, pembukuan (bookkeeping), dan pemrosesan pembayaran, serta merasakan otonomi yang tinggi dalam hubungan yang dekat dan terbuka dengan Product Manager dan para pemangku kepentingan
• Mengumpulkan pengetahuan domain seperti kepatuhan PCI (PCI compliance), buku besar double-entry (double-entry ledgers), escrow, rekonsiliasi (reconciliation), siklus hidup pembayaran (payment lifecycles), dan idempoten transfer bank (bank transfer idempotency)
• Strategi karier menjadi pakar domain adalah pilihan yang jelas untuk membedakan diri lewat keahlian di bidang yang menunjukkan tanda-tanda meningkatnya kebutuhan akan pakar domain

Pilar pertama yang mulai runtuh: pengetahuan spesifik domain

• Tahun lalu pindah ke perusahaan di bidang finansial; perusahaan-perusahaan sebelumnya memang kuat di elemen pembayaran dan finansial, tetapi tidak berfokus murni pada finansial
• Perusahaan baru sepenuhnya merangkul AI dan sejak hari pertama menyediakan akun ChatGPT dan Claude Enterprise, serta mendorong penggunaan AI untuk riset, eksplorasi, dan coding
  • Namun, ada syarat bahwa setiap baris kode yang masuk ke production harus ditinjau langsung dan dipertanggungjawabkan sendiri
• Proyek pertama adalah mengerjakan ulang sistem pembayaran online lawas yang berantakan, tugas yang diberikan karena pengalaman membangun sistem serupa sebelumnya
• Design Docs yang ditulis sebelum coding harus bisa dibaca baik oleh engineer maupun Product Manager, sehingga lebih menuntut perspektif arsitektur daripada analisis teknis mendalam
• Design Docs pertama ditulis dengan bantuan AI seminimal mungkin; saat itu LLM disebut sebagai “stochastic parrots”, pandangan yang kini tidak lagi dipertahankan
• Umpan balik dari manajer: kode dikirim dengan kecepatan yang baik, tetapi penulisan Design Docs terlalu lama dan AI harus lebih banyak dipakai
• Saat itu model belum sebaik sekarang, tetapi tetap cukup efektif untuk mempercepat penulisan dan pengambilan keputusan
• Itulah momen ketika nilai dari pengetahuan bertahun-tahun tentang trade-off implementasi, cara kerja acquiring, dan bagaimana menyusun idempoten untuk mencegah penagihan ganda mulai turun
  • Model masih perlu diarahkan, tetapi sudah bisa menangkap keterkaitan tentang bagaimana sistem seharusnya disusun, padahal itulah bagian tersulit yang biasanya baru terbentuk di kepala setelah bertahun-tahun pengalaman praktik
• Karena ada begitu banyak tulisan penjelas di web, dokumentasi teknis, dan artikel blog tentang penerapan alat teknis di domain ini, model dinilai bisa menyerap semua itu sebagai data pelatihan
• Masih ada harapan bahwa area tempat manusia akan tetap unggul adalah debugging, dan pengalaman dengan race condition di environment operasional serta debugging sistem terdistribusi menjadi dasar keyakinan akan employability jangka panjang

Pilar kedua yang mulai runtuh: debugging dan sistem terdistribusi

• Setelah mahir membantu penulisan dokumen dan rencana implementasi, LLM juga menjadi semakin baik dalam menulis kode, dan tren ini membesar dengan hype Claude Code pada paruh kedua 2025 serta kemunculan Codex
• Sebelumnya pun LLM sudah dipakai setiap hari untuk menulis unit test, tetapi belum cukup dipercaya untuk menangani implementasi penuh
• Mengadopsi lebih banyak AI untuk penulisan kode terasa seperti langkah berikutnya yang alami, dan karena deployment ke production serta kepuasan pengguna disukai sama besarnya dengan coding, ini menjadi pertukaran yang bisa diterima
• LLM memang semakin mahir menulis kode, tetapi belum mampu men-debug kekacauan yang ditinggalkan model atau manusia, sehingga perannya masih terasa lebih besar daripada sekadar mengarahkan robot
• Setelah hadirnya MCP, workflow berbasis agen, dan Claude 4.5, pilar debugging pun mulai goyah
• Claude 4.5 mampu menyelesaikan sekitar 60% bug hanya dari stack trace dan sedikit konteks; dalam sebagian besar kasus, cukup dengan tautan Sentry yang mengaktifkan Sentry MCP
  • Kadang tetap menghasilkan solusi yang terdengar masuk akal tetapi sepenuhnya salah
• Pada titik ini, keraguan terhadap mesin berhenti, setelah menyaksikan Claude Code menyelesaikan dalam sekali jalan bug yang dulu akan menghabiskan satu hari penuh untuk di-debug
• Setelah itu, dengan 4.6, 4.7, GPT 5.5, Opus 4.8, dan hadirnya DataDog MCP, CLI mulai bisa menyelesaikan bug sistem terdistribusi dalam sekali tembak
  • Termasuk bug yang dulu tak terpecahkan, bug yang dulu akan membutuhkan dua hari debugging penuh waktu, hingga bug sistem terdistribusi dengan observabilitas terdistribusi yang buruk
  • Sekitar 90% bug seperti race condition yang aneh, corner case tak terduga, masalah integrasi pihak ketiga, dan edge case API yang tidak terdokumentasi dapat diselesaikan dalam sekali tembak
• Masih tetap dibutuhkan orang untuk meninjau kode dan mengarahkan robot, sehingga status pekerjaan masih terjaga, tetapi kini hanya menjadi engineer komoditas
• Keahlian domain finansial dan pembayaran, intuisi debugging, serta pengetahuan sistem terdistribusi telah berubah menjadi pengetahuan yang bisa diprompt agar senior engineer lain dapat mengarahkan LLM untuk mencapainya
• Berbeda dari ajaran lama bahwa generalis dan spesialis sama-sama punya tempat, pasar kini bergerak ke arah menjadikan semua orang generalis
  • Jika semua orang menjadi generalis dan permintaan tidak mengikutinya, harga generalis akan turun, sementara permintaan sendiri sedang menyusut

Pilar ketiga yang belum runtuh: kualitas kode dan arsitektur

• Pilar yang masih tersisa adalah kualitas kode dan arsitektur software, yang kini diperkecil menjadi sekadar “taste”
• Sepanjang karier selalu menyukai refactoring, mementingkan kode yang baik, dan punya pengalaman menegosiasikan waktu untuk itu di dalam sprint
• Menikmati diskusi tentang trade-off dan struktur codebase pada topik-topik seperti DDD, Hexagonal, dan Clean Architecture
• Agen sangat lemah sebagai alat untuk menjaga codebase tetap rapi
  • Tanpa pengarahan, masalah circular dependency cepat muncul
  • Menambahkan kode duplikat, memasukkan komentar yang tidak perlu, mencampur pure function dan side effect, serta mengabaikan prinsip SOLID
• Kemampuan ini seharusnya menjadi area yang menjaga employability manusia, tetapi industri justru mengecilkannya menjadi kata “taste” dan bergerak ke dunia yang semakin kurang peduli pada pentingnya pengorganisasian kode
• Manusia masih berperan untuk mengarahkan agen agar mencegah codebase spageti dengan graf circular dependency
• Tidak menginginkan codebase kelas F yang rusak setiap kali sesuatu diperbaiki, tetapi kelas C atau D kini sudah dianggap cukup dapat diterima
• Alasan codebase kelas A atau B tidak lagi diperlukan adalah karena codebase kini dibangun agar bisa ditangani LLM, bukan agar dibaca manusia
• Jika source code kini ditulis untuk dibaca mesin, maka masuk akal juga untuk mulai mengarahkan pilihan kepada mesin
• Pengetahuan tentang kualitas kode dan arsitektur juga sedang mengalami penurunan nilai, dan waktu yang dihabiskan untuk membaca buku, latihan nyata, berdiskusi dengan engineer, dan menulis ADR terasa semakin sia-sia

Jadi sekarang harus apa

• Untuk sementara, pekerjaan tampaknya masih aman (setidaknya di perusahaan saat ini), tetapi prospek jangka panjang tidak jelas
• Dalam jangka panjang, nilai dari hal-hal yang dipelajari dengan investasi 10 tahun—atau lebih jika menghitung pengalaman nonprofesional—terus menurun
• Pilar keahlian terakhir pun telah diperkecil menjadi “taste”
• Sekitar 8 bulan lalu, di perusahaan saat ini terjadi PHK yang menurut penjelasan perusahaan tidak terkait AI, dan mantan rekan-rekan kerja yang hebat yang terdampak masih terus mencari kerja
  • Banyak dari mereka menghadapi masalah yang sama: keahlian domain saja tidak lagi cukup untuk membedakan diri
• Perusahaan kini kembali merekrut untuk beberapa peran, tetapi keakraban dengan domain tidak lagi menjadi faktor pembeda yang kuat
  • Dulu lowongan ditulis dalam bentuk “Software Engineer - Area”, tetapi sekarang hanya “Software Engineer”, dan penempatan tim dilakukan setelah tawaran diterima
• Bagi engineer hebat yang tidak sempat membangun pengalaman domain mendalam, perubahan ini justru membuka peluang kerja yang lebih baik
• Sebaliknya, engineer hebat yang sepanjang hidup mengumpulkan pengetahuan domain kini bersaing di jalur yang sama
• Satu-satunya pilihan untuk menjaga employability jangka panjang adalah memindahkan keahlian domain ke area yang tidak mudah dikuasai LLM dengan baik
• Ada pertimbangan untuk kembali ke universitas, belajar matematika, statistika, dan Machine Learning tingkat lanjut, lalu melamar posisi riset di frontier lab
  • Di negara tempat tinggal tidak ada frontier lab, dan sedikit lembaga riset yang ada pun dibanjiri pelamar
  • Situasi keluarga membuat pindah ke negara lain sulit dilakukan
  • Bahkan pada saat perpindahan itu mungkin dilakukan, ada kemungkinan RSI (recursive self-improvement) justru membuat peneliti menjadi tidak diperlukan
• Sampai-sampai muncul pikiran untuk mengubah hobi pertukangan kayu menjadi pekerjaan, sebagai gambaran betapa buntu situasinya

[GN⁺]

Komentar Hacker News

• Apa? Saya mengarahkan LLM sepanjang hari, tapi sama sekali tidak akan setuju menjadi penanggung jawab produk keuangan
  Pilar pertama masih tetap berdiri. Mungkin penulis tidak menyadari pengaruh dirinya sendiri, tetapi dari bukti PR yang dibatalkan, saya tahu bahwa ketika saya melangkah ke luar area yang saya pahami secara mendalam, saya tidak lagi bisa membedakan apakah agen itu sedang mengoceh. Bahkan agen terbaik kami, yang menurut penulis bahkan punya akses ke sistem terdistribusi, juga sering salah, berpandangan sempit, dan terus melakukan hal bodoh. Pada akhirnya, keahlian para engineer di timlah yang mengembalikannya ke jalur yang benar

  • Saya menulis dengan akun sementara untuk menghindari identitas saya terungkap. Saya bekerja di FinTech yang membuat produk teregulasi dan punya akses ke Mythos
    Mythos dengan percaya diri menyimpulkan bahwa sebagian codebase kami melanggar regulasi tertentu, dan mengatakan bahwa jika dioperasikan dengan cara sekarang akan menimbulkan risiko serius. Namun itu tidak benar, dan ia berhalusinasi tentang persyaratan regulasi. Saya bisa tahu karena kode tersebut sudah ditinjau oleh penasihat hukum manusia. Katanya ini model tercanggih yang tersedia saat ini. Saya banyak memakai AI generatif untuk membantu menulis kode, tetapi bahkan dalam jangka menengah pun kita tidak bisa mengandalkan alat seperti ini untuk benar-benar membangun produk keuangan yang patuh regulasi. Itu benar-benar gila. Memang banyak perusahaan FinTech memakai agen untuk meningkatkan kecepatan, tetapi jika itu dipakai untuk meluncurkan produk tanpa ada manusia yang benar-benar mendalaminya, berarti mereka menanggung risiko yang sangat besar
  • Anda bilang “keahlian para engineer di tim mengembalikannya ke jalur yang benar”, tapi bagaimana Anda bisa yakin rekan kerja Anda tidak lebih ahli daripada Anda?
    Sebelum LLM, di kebanyakan perusahaan masih ada ruang bagi engineer hebat dan engineer biasa untuk bekerja bersama. Setelah LLM, hanya engineer “terbaik” yang bisa bertahan. Engineer biasa tidak lagi dibutuhkan. Mengingat karakter HN, kebanyakan engineer yang membaca tulisan ini akan menganggap dirinya termasuk 10–5% teratas di perusahaan/kota/negaranya, jadi merasa dirinya bukan engineer “biasa” yang akan terkena dampak adopsi LLM. Secara statistik, kemungkinan besar itu salah. Pada akhirnya ini soal ego. Kemungkinan besar Anda bukan rockstar, dan pada akhirnya LLM bisa mengambil pekerjaan Anda. Seperti biasa, yang menang hanya perusahaan dan para eksekutif, sementara kebanyakan dari kita ada di ujung paling bawah rantai dan akan dirugikan
  • Pada PR dengan kebutuhan yang kompleks, waktu sampai PR awal jadi memang jauh lebih singkat, tetapi setelah itu saya melihat ping-pong antara reviewer dan developer mulai terjadi
    Dalam kasus saya, developer melakukan vibe coding pada sebagian pekerjaan, lalu karena tidak punya pemahaman mendalam tentang requirement maupun kodenya sendiri, perlu beberapa kali bolak-balik untuk memperbaikinya. Ini bisa dibilang masalah manusia, tetapi efek bersih yang saya lihat seperti ini. Untuk kasus yang kompleks, pola lama “waktu menulis PR yang cukup panjang + waktu review yang cukup panjang” tampaknya berubah menjadi “waktu menulis PR yang sangat singkat + waktu review yang lebih panjang”. Saya tidak tahu apakah dalam kasus seperti ini ada manfaat nyata. Kadang bahkan jika kodenya benar secara fungsional, ia jadi bertele-tele dengan terlalu banyak fungsi perantara, dan rasanya itu akan memengaruhi review-review berikutnya
  • Sayangnya, seluruh industri terkait software sedang menerima LLM/generasi kode. Bank, FinTech, asuransi, semuanya begitu
    Saya juga punya kekhawatiran yang sama, tetapi sering diabaikan atau disamarkan dengan kalimat seperti, “jangan khawatir, kecepatan delivery dan ROI sepadan kok”
  • Saya tidak tahu berapa lama lagi pernyataan “saya mengarahkan LLM sepanjang hari, tapi tidak akan setuju menjadi penanggung jawab produk keuangan” bisa bertahan di perusahaan tertentu
    Secara pribadi, semua perusahaan FinTech yang saya temui tampaknya sudah punya semacam akun AI untuk developer sejak tahun lalu. Bahkan di tempat seperti Jane Street, ada karyawan yang menulis blog dan mengatakan bahwa mereka pada dasarnya mengarahkan agen. Menurut Anda, berapa lama lagi perusahaan Anda bisa bertahan?

• Saya sering melihat komentar seperti, “Pekerjaan kita aman karena AI tidak bisa melakukan X dengan akurasi 80~100%.”
  Saya tidak ingin terdengar terlalu pesimistis, tetapi model berkembang dengan cepat. Jika sekitar 3 tahun lalu seseorang menjelaskan kondisi saat ini dan berkata, “model membuat seluruh aplikasi MVP hanya dengan satu prompt dalam waktu sekitar 30 menit,” itu akan terdengar seperti fiksi ilmiah. Hambatan yang kini dihadapi model, seperti menurunkan tingkat halusinasi, menjamin kepatuhan terhadap aturan, dan menjaga codebase tetap rapi, tampaknya tidak terlalu jauh dari kata terpecahkan. Mengambil informasi tertentu juga sudah sebagian dimungkinkan lewat beberapa server MCP/RAG. Saya khawatir tentang masa depan software engineer. Jika cacat-cacat ini teratasi, di mana posisi pekerjaan ini nanti? Menjadi peran yang mendelegasikan pekerjaan ke model AI? Sayangnya, ini tidak memerlukan keahlian bertahun-tahun, jadi ini pedang bermata dua. Meninjau output AI? Tinggal minta model menjelaskan setiap baris yang tidak dipahami. Seperti halnya manusia penghitung digantikan oleh komputer digital, saya rasa kita akan melihat gelombang PHK yang lebih besar lagi. Melakukan perhitungan matematika rumit di kepala bisa jadi tantangan yang menyenangkan, tetapi jauh lebih lambat dan lebih banyak kesalahannya dibanding komputer. Demikian pula, membuat kode dengan tangan akan terlihat sebagai “tantangan” yang menyenangkan, dan AI akan tampak sebagai kalkulator modern

  • Saya sangat menyarankan untuk menonton klip singkat ini
    https://youtu.be/5eqRuVp65eY?si=3fLT6S5q2OIUcu6r
  • Pernyataan bahwa model berkembang cepat, dan bahwa 3 tahun lalu kondisi sekarang akan terdengar seperti fiksi ilmiah, sepenuhnya benar
    Banyak hal akan terus membaik secara besar-besaran. Namun, jika melihat sejarah modern tentang disrupsi besar yang diciptakan teknologi, ada pola yang berulang. Seperti longsoran salju atau banjir bandang, perubahan drastis seperti ini sering kali dimulai dari satu atau lebih terobosan penting dalam teknologi tertentu. Kecepatan perubahan di awal memang cepat dan liar, tetapi kemudian melambat secara bertahap saat buah yang paling mudah dipetik sudah diambil dan hambatan serta friksi baru muncul di wilayah baru. Pada fase awal seperti ini, mengekstrapolasi laju perubahan luar biasa belakangan ini langsung ke masa depan biasanya memiliki daya prediksi yang rendah. Ledakan ekstrem yang tiba-tiba cenderung kembali ke garis tren jangka panjang. Disrupsi LLM saat ini bisa dilihat berasal dari penelitian sejak 2010 yang menumpuk hingga makalah transformer tahun 2017, lalu dengan cepat memicu riset di sekitarnya. Jika begitu, mungkin saat ini kita berada di pertengahan atau akhir fase ledakan tajam LLM. Laju terobosan mendasar dan luas yang mengangkat semua aplikasi LLM jelas telah melambat, dan banyak penemuan berdampak besar belakangan ini berada pada perluasan ke area tertentu, optimasi, tuning, dan productization. Ini bukan berarti besok tidak akan ada terobosan setingkat transformer lagi, tetapi secara historis angsa hitam jarang datang bergerombol
  • Mengapa Anda mengira ini akan berhenti pada PHK developer? Jika perusahaan software menjadi bergantung pada penyedia LLM untuk menjalankan bisnis mereka, saya rasa kita bisa melihat keruntuhan besar-besaran perusahaan-perusahaan ini secara global, dari produk on-premise hingga SaaS
    Pelanggan tidak lagi membeli tool software seperti sekarang, dan bisa membuat sendiri semua software yang mereka butuhkan secara internal atau lewat konsultan prompt engineering. Dunia bisa menjadi sangat berbeda
  • Apa teorinya tentang kapan AI mencapai 100%? Apakah PM dan analis bisnis yang akan membuat semua software?
    Atau hanya ada sekitar 700 perusahaan pendiri tunggal di seluruh dunia dan semua orang lain tidak bisa bekerja? Ini Matrix?
  • Jika Anda benar-benar mengira model membaik sampai sejauh itu, itu nyaris delusional
    Produktivitas tidak meningkat sebanyak itu sejak Claude 3.5 dirilis. Saya punya akses tak terbatas ke semua LLM, tetapi sebagian besar sampah, dan saya justru lebih banyak membuat daripada menghemat. Satu-satunya orang yang diuntungkan alat ini adalah mereka yang ingin cepat-cepat memproduksi hasil berkualitas rendah. Jika Anda tidak setuju, berarti Anda juga orang seperti itu

• Jalur karier saya sangat mirip dengan penulis. Anehnya, bagian yang oleh penulis dianggap sebagai pilar pertama yang runtuh justru sekarang tampak paling utuh
  LLM berulang kali gagal pada kekhususan bisnis kami. Hal-hal seperti pajak daerah, detail prosedur akuntansi, dan kekhasan implementasi ledger kami. LLM sangat bagus untuk refactoring, konversi antarbahasa, dan melacak bug pada kode yang sudah ada, tetapi saat mengulang dan memperluas domain kami, selalu ada banyak bagian yang salah secara halus. Mungkin karena perusahaan-perusahaan tempat saya bekerja sengaja menangani area yang rumit untuk membangun moat. Ini perusahaan yang bertahan karena tidak ada buku untuk membuat salinannya, dan know-how tetap tersimpan secara internal. Selain itu, jika ini FinTech tempat manajer mendorong pembuatan dokumen desain dengan cepat memakai AI, itu terasa terlalu ceroboh untuk bisnis yang menangani uang. Terutama ketika ada banyak transaksi kecil, sangat mudah sampai jutaan unit salah dialokasikan. Bug seperti ini benar-benar sulit ditangani. Memperbaiki logika hanyalah tahap pertama; setelah itu Anda harus memperbaiki data yang salah hitung di database yang immutable, lalu menangani prosedur regulasi dan komunikasi pelanggan. Perbaikannya kemudian menjadi jebakan yang harus dipertimbangkan fitur baru dan observability. Semacam, “ingat bahwa lonjakan pada data tanggal 2 Februari terjadi karena insiden X”

  • Saat benar-benar membuat sesuatu yang belum pernah dibuat sebelumnya, Anda tidak bisa menyerahkan keputusan arsitektur kepada LLM
    Saya membuat beberapa produk berbasis simulasi fisika, murni berdasarkan first principles. Tetapi jika diserahkan tanpa riset aktif, pemikiran, dan verifikasi, LLM akan membuat kode komputasi yang ratusan digit orde lebih lambat, sambil memasukkan jalur alternatif dan jalan pintas yang konyol, sehingga hasil akhirnya menjadi komputasi yang tidak berguna. Ini mungkin terjadi sekitar 95% dari waktu. Pengawasan sangat penting, dan pemikiran arsitektural masih belum bisa di-outsource. Yang bisa di-outsource hanyalah eksekusinya
  • Kekhususan pajak daerah, prosedur akuntansi, dan implementasi ledger adalah keahlian domain, dan tidak selalu membutuhkan software engineer
    Tentu saja, software engineer senior sering kali menjadi ahli di sini, tetapi itu tidak wajib. Secara tradisional, akan berguna bagi produksi tanpa gesekan jika engineer bisa menangani sekitar 90% pekerjaan tanpa harus bertanya kepada ahli bisnis, tetapi inti yang dibahas tulisan aslinya justru bahwa “tradisi” itu telah berakhir. Di dunia baru, pekerjaan engineer senior bukan memiliki keahlian domain itu secara langsung, melainkan membuat agen memiliki atau memperoleh keahlian tersebut, dan memastikan bahwa hasilnya benar dengan cara yang bisa diverifikasi. Engineer senior yang berpegang pada keyakinan bahwa keahlian domain bisnis tingkat tinggi akan menjaga mereka tetap aman akan segera menemui jalan buntu, sama seperti junior yang tidak bertransisi
  • Saya bahkan tidak bisa membuat Claude atau GPT-5 secara konsisten menyusun flowchart untuk use case umum. Apalagi untuk hal yang spesifik domain
    Mereka punya kosakata yang dalam sehingga terdengar seolah tahu lebih banyak daripada kenyataannya. Mereka sangat bagus dalam menulis kode dan men-debug error yang terlihat, tetapi itu setengahnya juga berkat test harness
  • Teknik untuk menyelaraskan pemahaman bersama antara fitur produk dan regulasi yang harus dicerminkan fitur itu bersama LLM mungkin bisa membantu
    Ide intinya adalah memberikan dokumen kepada LLM, lalu membiarkannya mengajukan banyak pertanyaan untuk menghilangkan ambiguitas dan kemungkinan salah paham. Saya sarankan melihat Skills. Ini sangat membantu. https://www.youtube.com/watch?v=6BB6exR8Zd8
  • Perusahaan kami juga banyak menangani regulasi kompleks dan implementasi sistem yang sangat spesifik domain, dan dulu AI juga kesulitan di sini
    Kami bisa menyelesaikan masalah itu dengan file claude.md/agents.md yang tertata rapi. Kami juga mengimplementasikan supermemory.ai di dalamnya, sehingga keputusan baru yang diambil selalu diingat kembali oleh agen AI setiap kali memulai sesi baru

• Saya selalu teringat kutipan Steve Jobs yang terkenal, “ide itu murah”
  Eksekusi adalah segalanya, dan jika LLM terdepan memecahkan eksekusi, maka ide kini menjadi gerbang menuju kelimpahan. Namun kelimpahan itu sendiri tidak menjamin adanya “daya lekat”. Yang sering terlewat adalah kemauan manusia untuk tetap bertahan pada hal itu dan kepedulian untuk benar-benar memperhatikannya. Banyak orang tidak cukup peduli atau tidak cukup menginginkannya untuk membuat, memelihara, dan memilikinya. V1 mungkin bisa dirilis lebih cepat, tetapi bisakah itu terus dipoles dan dijalankan? Contoh yang bagus terlihat pada alat musik AI Suno. Sekarang hasilnya sudah cukup bagus. Banyak orang bermain-main dengan dunia kecil mereka sendiri lalu cepat lelah dan pergi, dan hanya sedikit kreator yang produktif yang tersisa lalu mengubahnya menjadi lingkungan yang “terasa seperti pekerjaan”. Skala dan keekonomian delegasi serta eksekusi mungkin telah berubah, tetapi masih banyak faktor yang perlu dipertimbangkan

  • Saya sudah sedikit mencoba Suno, dan saya tidak setuju dengan pernyataan bahwa itu “menghasilkan karya yang benar-benar bagus”
    Bahkan sebagai orang dengan wawasan musik yang terbatas, saya merasa begitu, jadi kemungkinan besar para musisi akan jauh lebih kritis. Beberapa kali pertama memang mengesankan, dan melodinya juga catchy. Dulu ada bagian yang terdengar aneh di latar, tetapi sebagian besar sudah diperbaiki. Namun setelah puluhan lagu, semuanya mulai terdengar mirip. Semuanya generik, lagunya tidak bercerita, dan rasanya seperti musik latar iklan korporat. Saya juga tidak banyak berhasil meski menulis prompt dengan lebih presisi, dan detail yang seharusnya membuat lagu menarik kebanyakan diabaikan. Hasil yang paling menarik justru muncul saat saya membuatnya keluar jalur seperti karena bug. Ketika saya memintanya mencampur dua genre yang sangat berbeda, hasilnya terasa ganjil dengan nuansa gelisah yang saya tidak ingat pernah dengar sebelumnya. Tapi untuk mengolahnya lebih lanjut selalu sulit, dan ia terus cenderung kembali ke hasil yang generik serta mengabaikan instruksi detail. Suno bisa melakukan remix. Ini mirip dengan kode. LLM sangat bagus untuk porting sesuatu yang sudah bekerja agar berjalan dalam bahasa lain. Tetapi kalau hanya diberi ide, ia gagal pada bagian yang orisinal. Untuk membuat LLM benar-benar mewujudkan ide dengan tepat, kita harus memberi terlalu banyak arahan, sampai akhirnya kita melawan ambiguitas bahasa alami dan itu nyaris sama seperti menulis kode sendiri
  • LLM terdepan tidak “memecahkan” eksekusi
    Eksekusi bisa dipecahkan jika Anda mendorongnya cukup jauh dan memiliki sistem yang bisa menghasilkan kode yang benar-benar berjalan. Tetapi itulah tepatnya engineering. Dalam kondisi default saat ini, masih sangat jauh dari mampu menggantikan engineering. Mungkin 3 tahun lagi bisa. Pergerakannya cepat. Tetapi hari ini juga Anda belum bisa hanya berkata “tolong buatkan compiler Rust yang lebih baik” lalu bersandar dan menerima hasilnya
  • Suno adalah contoh yang bagus. Saya menulis lirik untuk banyak lagu dan “memproduserinya” dengan Suno, tetapi tetap butuh puluhan sampai ratusan remix/cover/perpanjangan revisi atau banyak waktu di editor sampai keluar suara yang saya inginkan
    Lagu-lagunya saya suka dan layak saya dengarkan di playlist saya, tetapi tidak mendapat respons besar di algoritma Suno. Saya juga tidak banyak mempromosikannya di tempat lain, dan saat saya unggah pun hasilnya hanya beberapa like. Saya tidak kecewa. Saya membuat musik untuk diri saya sendiri, dan membagikannya hanyalah efek samping. Kesimpulan yang saya dapat dari sini adalah bahwa membuat orang peduli dan menikmati sesuatu yang saya buat tetap membutuhkan banyak kerja. Harus dipasarkan, harus dibawa ke hadapan orang, dan harus dibuat agar mereka memperhatikannya. Saya juga yakin itu perlu dihubungkan dengan video, cerita, persona, atau semacam vibe agar ada alasan untuk menyukainya. Untuk membuatnya “melekat”, semua itu harus diulang pada audiens yang sama, dan mereka harus dibuat terbiasa dengannya. Jadi dibutuhkan konsistensi, dan Anda harus benar-benar peduli pada apa yang ingin Anda jual. Sebelum orang-orang melekat, saya sendiri harus lebih dulu melekat
  • https://x.com/chamath/status/2033385903520129161
    https://en.wikipedia.org/wiki/Sturgeon%27s_law
    Hukum Sturgeon mengatakan bahwa “90% dari segala sesuatu adalah sampah”. Aforisme ini diciptakan oleh penulis dan kritikus fiksi ilmiah Amerika, Theodore Sturgeon, saat membela nilai genre tersebut. Sturgeon berpendapat bahwa di bidang apa pun, sebagian besar karya berkualitas rendah, sehingga fiksi ilmiah tidak secara khusus lebih rendah dari yang lain
  • Bisa jelaskan lebih lanjut tentang alat musik AI?
    Kesan saya, alat seperti ini dipakai seolah-olah menghasilkan semuanya sekaligus dalam satu kali jalan. Saya tidak terlalu paham musik, tetapi bagi seniman tampaknya dibutuhkan banyak hal yang tidak saya ketahui, seperti tahap perantara, pemisahan track, kustomisasi instrumen, dan lain-lain. Tanpa hal-hal seperti itu, menurut saya akan sulit dipakai untuk pekerjaan profesional

• Saya tidak sepenuhnya setuju dengan tulisan ini. Vibe coder tidak akan bisa merancang, mengembangkan, dan mengimplementasikan sistem dengan kompleksitas menengah tanpa membuat semuanya berantakan
  Bagian besar dari kemampuan menggunakan aplikasi seperti Claude dengan baik adalah pemahaman konseptual dan pengalaman terhadap konsep-konsep ilmu komputer. Hal-hal seperti itu sama sekali tidak dimiliki oleh vibe coder. Kalau mereka punya, mereka tidak akan menjadi vibe coder

• Jika “tidak tahu harus melakukan apa”, ya tinggal menunggangi ombak
  Saya juga menungganginya saat situs web/aplikasi web menjadi ombaknya. Saya masuk ke industri perangkat lunak sebelum internet ada, dan terus berganti tunggangan. Tidak ada kata terlalu tua untuk mempelajari teknologi baru. Ombak baru menciptakan jenis pekerjaan dan pekerja baru. Tinggal jadi salah satunya. Tunggangi binatang buasnya, kuasai alatnya. Ini cuma permainan yang sama datang lagi

  • Setuju
    Kalau ada keterampilan yang permintaannya konsisten, itu adalah kemampuan menyusun struktur di dalam kepala untuk hal apa pun: pekerjaan baru, proses baru, orang baru, dan seterusnya. Saya bekerja sebagai prototipe machinist, dan lewat pekerjaan itu saya memahami serta mengembangkan kemampuan ini sebagai alat yang tajam. Buat yang tidak familier, prototipe machinist adalah orang yang melakukan apa pun yang diperlukan untuk membuat komponen yang rumit dalam tenggat mingguan yang pendek. Logam, plastik, apa saja. Anda jadi mahir cepat terbiasa dengan proses, mesin perkakas, dan material. Kalau melakukan itu cukup lama, Anda jadi bisa menyerap informasi baru dengan sangat cepat, dan memahami pekerjaan jauh lebih cepat serta lebih akurat daripada banyak orang. Siapa pun bisa mulai. Cukup punya rasa ingin tahu dan buat sesuatu. Lalu buat lebih banyak lagi. Bagikan apa yang Anda buat, dan buatlah hal yang diinginkan orang lain
  • Secara umum masyarakat memang terasa lebih bergejolak, tetapi pada dasarnya lagu dan tariannya yang sama terus berulang
    Pada tahun 90-an dan 00-an ada ombak “pemrograman berorientasi objek akan mengubah segalanya”. Hal-hal yang sebelumnya sudah berhasil dilakukan ratusan kali, sekarang dilakukan dengan berorientasi objek. Menulis kode terkait pesawat? Saya benar-benar pernah mendengar di kampus bahwa Anda tinggal membeli objek pesawat mahakuasa yang melakukan semua hal tentang pesawat. Ternyata OOP bukan solusi untuk segalanya? Lalu ada code generation, coba jalankan Ruby on Rails. Bikin situs web dalam 2 detik. Code generation ada di mana-mana. Lalu arahnya makin aneh dan muncullah TDD. Saya pernah melihat percakapan sungguhan yang seolah mengatakan kalau Anda tidak melakukan TDD, Anda engineer yang begitu buruk sampai pantas dipenjara. Bukan, bukan TDD, katanya BDD-lah jawabannya. Lean, eh Agile, eh agile huruf kecil, tapi itulah awalnya, eh Scrum, eh XML, tunggu itu dekade lalu, JSON, dan akhirnya SAFe. Dan sekarang jadi “sudah lihat chatbot ini?”. Setiap putaran membawa hal baik kalau Anda memperhatikan. Tapi juga membawa banyak hype dan kecemasan. Tinggal bereksperimen dan belajar. Satu hal yang tidak berubah bagi saya adalah bahwa hampir semua orang lebih memilih mati daripada memikirkan dengan hati-hati hasil jika impian mereka benar-benar terwujud. Selama itu tetap benar, orang akan terus membayar seseorang untuk menunggangi naga tren yang dibesar-besarkan menggantikan mereka
  • Anda bilang “kuasai alatnya”, tetapi proposisi nilai dari alat-alat ini justru adalah bahwa tidak ada keterampilan atau penguasaan yang perlu dibangun
    Seluruh alur pabrik hasil berkualitas rendah, eh maksudnya alur “AI-native”, seperti ini. “Wah, saya membujuk chatbot untuk membuat sesuatu yang sama sekali tidak saya pahami. Saya hebat sekali dalam pekerjaan!” Ini seperti piala partisipasi untuk aktivitas membuat sesuatu. Ada hal lain yang membuatnya, dan saya mengambil kreditnya padahal saya sendiri tidak terlalu paham. Tidak ada imbal hasil majemuk dari upaya saya. Tidak ada pelajaran yang dipetik. Tidak ada pemahaman yang terbangun. Tidak ada wawasan yang bisa mengarah ke inovasi masa depan. Tidak ada diferensiasi. Cuma berteriak ke kehampaan sampai pikiran mati rasa, lalu mesin slot memuntahkan campuran berkualitas rendah yang “kelihatannya cukup bagus”, dan besok diulang lagi. Kalau itu permainannya, saya keluar. Senang sih kalau orang lain menikmatinya, tetapi mengira ada bentuk penguasaan di sini itu delusi. Satu-satunya syarat untuk “sukses” dengan alat ini adalah berhenti peduli dan menyerah

• Saya pernah memposting ini sebelumnya, tetapi layak diposting lagi
  Saya mengerjakan DevOps di perusahaan yang sangat agresif dalam penggunaan LLM. Kira-kira tahapannya seperti ini. Mencoba menyuruh LLM melakukan “banyak hal”, menyuruhnya melakukan lebih banyak lagi, menjalankan banyak agen, kembali lagi ke satu agen tetapi menyuruhnya membuat alat, lalu beralih ke alat deterministik yang bisa dipakai manusia maupun LLM. Alasannya begini. Dalam deployment dan testing, alat deterministik memberi jawaban biner dan dapat diulang. Kalau terjadi insiden, selalu bisa kembali ke alat yang bisa dijalankan manusia. Juga lebih cepat. Skrip sederhana berjalan dalam kurang dari 30 detik, sementara “omong kosong yang terdengar masuk akal” tampaknya selalu butuh 2–3 menit. Pada akhirnya saya kembali ke tulisan ini. https://spawn-queue.acm.org/doi/10.1145/3194653.3197520 Intinya, “buat daftar tugas, tulis skrip untuk tiap tugas, gabungkan skrip menjadi fungsi, lalu fungsi itu menjadi sistem.” Tambahan lagi, kalau dibiarkan sesuka hati, LLM dengan senang hati akan membuat kode. Anda bisa menambahkan tes untuk memastikan tesnya berjalan. Dulu kita juga melakukan itu pada kode buatan manusia. Anda juga bisa membaca kodenya. Saat membaca kode itu, Anda akan mendapati bahwa sambil membuat kode yang berjalan, ia kadang juga melakukan hal yang benar-benar gila. Manusia juga begitu sih, tapi itu cerita lain. Pada akhirnya Anda tetap harus memeriksa apakah sistem yang dihasilkan masuk akal. Singkatnya, coding mungkin sudah mati, tetapi software engineering masih hidup dan berlari kencang

  • Pendekatan ini memang benar
    Anda bisa menyuruh LLM besar melakukan segalanya. Itu mungkin, dan memang dilakukan. Tetapi biayanya sangat mahal dan lambat. Sebaliknya, kalau Anda memakai AI untuk membuat alat agar sebanyak mungkin tugas dalam proses ditangani secara deterministik, lalu AI-nya memakai alat itu, hasilnya jauh lebih cepat dan murah. Bonusnya, pada akhirnya Anda bahkan bisa membuang AI cloud yang mahal dan menjalankannya dengan model lokal kecil/menengah

• Jika gambaran masa depan dari penulis benar, insinyur perangkat lunak yang kompeten akan aman
  Pengetahuan domain bisa dipelajari jauh lebih cepat daripada cara menerapkan prinsip rekayasa yang baik. Insinyur yang daya saing utamanya adalah pengetahuan domain mungkin sebenarnya tidak begitu unggul dalam rekayasa itu sendiri. Meski begitu, mereka tetap bisa mencari pekerjaan di area lain dalam industri yang membutuhkan pengetahuan domain yang telah mereka bangun

  • Seminggu lalu di thread lengkap, ada yang mengatakan bahwa keahlian domain selalu merupakan moat yang sesungguhnya: https://news.ycombinator.com/item?id=48340411
  • Saya tidak yakin pernyataan bahwa pengetahuan domain bisa dipelajari jauh lebih cepat daripada prinsip rekayasa yang baik itu benar secara umum
    Banyak insinyur perangkat lunak bagus yang bersikap pongah seolah pengetahuan domain itu mudah didapat, lalu merusak banyak sistem ERP. Sebagian besar IT pada dasarnya memang pekerjaan memasukkan aturan bisnis ke dalam sistem
  • Saya agak tidak setuju. Pengetahuan domain pada level besar memang bisa dipelajari cepat, tetapi untuk memolesnya menjadi pemahaman yang bernuansa dengan mempertimbangkan kompleksitas, khususnya dalam organisasi yang unik dan sering kali tidak dianggap sebagai “perusahaan pengembang perangkat lunak”, bisa memakan waktu bertahun-tahun hingga puluhan tahun
    Meski begitu, saya masih melihat dan mereview kode dari pengembang perangkat lunak “spesialis” yang tidak mengikuti praktik rekayasa perangkat lunak yang baik. Pernyataan bahwa insinyur yang kekuatan utamanya adalah pengetahuan domain mungkin tidak unggul dalam rekayasa juga berlaku sama untuk insinyur yang tidak punya pengetahuan domain. Setidaknya itu pengalaman saya. Mungkin kami hanya sedang sial
  • Pengembangan dan perolehan pengetahuan domain yang bernilai adalah proses yang sulit, berisiko, mahal, dan lambat
    Karena pengetahuan domain yang bernilai bukanlah pengetahuan kemarin, melainkan pengetahuan hari ini dan besok. Dalam bidang yang pengetahuan domainnya penting, hal itu terjalin erat dengan rekayasa. Anda tentu tidak akan menugaskan Jeff Dean mengembangkan Unreal Engine dari nol. Meski begitu, tetap ada banyak prinsip rekayasa perangkat lunak yang belum sepenuhnya diinternalisasi atau dijalankan dengan baik oleh para pakar pengetahuan domain. Selama pengetahuan domain bernilai, keadaan ini juga akan terus ada. Karena rekayasa perangkat lunak sendiri juga merupakan sebuah domain
  • Apakah pengetahuan domain bisa dipelajari lebih cepat? Saya justru berpendapat sebaliknya
    Metodologi bisa diperbaiki jauh lebih cepat daripada memperoleh keahlian khusus. Yang pertama adalah persoalan pendekatan, jadi bisa dipaksakan dan ditingkatkan dengan cepat. Yang kedua bergantung pada kecenderungan belajar orang tersebut, kapasitasnya, dan waktu yang tersedia saat itu, dan tidak bisa dipaksakan melebihi dukungan yang wajar. Selain itu, sifatnya juga terakumulasi dengan sendirinya, sehingga kurva belajar di awal jauh lebih curam

• Saya memakai Claude Code dan Opus 4.7, dan masalahnya bukan kode yang dihasilkan salah, melainkan cenderung menulis terlalu banyak
  Cara memikirkan fitur tertentu lalu menempatkannya agar paling pas dengan kode yang ada masih tetap bernilai. Claude sering memilih satu lapisan dalam stack, misalnya lapisan presentasi, lalu memaksa semuanya masuk ke sana. Beberapa minggu kemudian saat data yang sama dibutuhkan di tempat lain, Claude tidak bisa memakai ulang kode di lapisan layanan dan malah melakukan semacam “transplantasi”. Jika manusia tidak cukup memperhatikan, jumlah kode jadi dua kali lipat dan logika pun terduplikasi. Sepertinya alat AI seperti Claude tidak akan segera membaik dalam hal ini. Di tempat saya bekerja, sudah ada tekanan untuk mengurangi penggunaan Opus 4.7 demi menghemat biaya. Seseorang bahkan mengatakan bahwa untuk “perbaikan bug sederhana” sebaiknya pakai model yang lebih kecil. Kadang mungkin bisa, tetapi seberapa sering kita benar-benar tahu sejak awal bahwa itu perbaikan bug yang sederhana? Jika biaya terus naik, minat untuk menulis “semua kode” dengan alat ini tampaknya akan berkurang. Kalau orang beralih ke model yang lebih murah dan kurang efektif, kemungkinan tekanan untuk tidak mereview kode itu juga akan hilang. Kita lihat saja nanti akan berujung ke mana, tetapi mungkin perubahan yang terjadi tidak akan sedramatis yang ditakutkan penulis

  • Saya setuju dengan kritik bahwa AI menulis terlalu banyak kode
    Hanya dengan menyuruh AI mengurangi jumlah baris kode produksi menjadi setengah dan memeriksa apakah ada library lain yang bisa dipakai ulang, hasilnya sudah sangat mengejutkan efektif. Sepertinya kita juga bisa membuat bot refactoring yang mencari duplikasi lalu mengekstraknya. Saat ini memang belum tersedia secara bawaan, tetapi jelas bukan berarti itu mustahil
  • Saya juga melihat masalah kode menjadi terlalu banyak
    Namun pertanyaan terbukanya adalah apakah terlalu banyak kode itu benar-benar masalah. Alat-alat ini sekarang sudah menjadi bagian dari hidup. Jika masalah bisa diselesaikan atau di-debug lebih cepat, dan perangkat lunaknya punya lebih sedikit bug, maka mungkin itu bukan terlalu banyak kode, melainkan jumlah baris kode yang memang pas
  • Belum lama ini ada situasi di codebase dengan dua fungsi, fooBar() dan fooBarExtended()
    Yang kedua memiliki parameter tambahan dan fitur yang dibutuhkan untuk masalah saat ini. Namun alih-alih memanggil fungsi itu, Claude terus mencoba menambahkan parameter perluasan yang sama ke fungsi pertama. Bahkan setelah diberi tahu untuk tidak melakukannya, nanti ia mengusulkan hal yang sama lagi, dan kadang itu benar-benar menjengkelkan

• Apa pun pandangan kita tentang masa depan industri ini, saya rasa sulit mencari kesuksesan karier yang lebih besar di pertukangan kayu artisan daripada di perangkat lunak artisan

  • Pasar furnitur/kabinet kustom sudah cukup berat, dan pertukangan kayu adalah hobi yang terlalu umum di kalangan programmer, jadi kalau banyak dari kita terjun ke sana, pasar akan cepat sekali kelebihan pasokan secara parah
    Saya pernah disuruh mencoba menjual furnitur yang saya buat, tetapi jawaban saya selalu sama. Saya sudah pernah melakukan kesalahan mengubah hobi menjadi pekerjaan, dan saya tidak berniat mengulangi kesalahan itu. Setidaknya perangkat lunak masih membayar cukup baik
  • Itu tergantung Anda memandang pertukangan kayu sebagai apa
    Ada orang yang bekerja dengan saya yang membuat dek, taman, karavan, gudang, pagar, dan semacamnya, dan dia menghasilkan uang yang sangat bagus. Tentu saja, demi adil, dia juga memang sangat ahli
  • Saya punya rumah bersejarah dengan pintu berbentuk unik yang dipahat dengan tangan
    Kusen pintunya membusuk dan saya membayar tukang kayu 4 ribu dolar untuk membuat penggantinya. Mengganti pintunya sendiri akan dengan mudah menelan biaya 25 ribu dolar. Jika Anda pindah ke distrik bersejarah besar dengan banyak pintu ukir tangan, Anda bisa menghasilkan uang lumayan
  • Sebagian sangat kecil dari pasar, mungkin bahkan kurang dari 1%, masih bersedia membayar untuk barang buatan tangan. Kalau sepenuhnya modern tetapi bernuansa retro, malah jadi nilai tambah. Misalnya keyboard steampunk
    Tetapi persentase pasar yang ingin membayar untuk perangkat lunak buatan tangan tepatnya adalah 0%
  • Lihat saja layoffs.fyi. Anda kemungkinan besar akan segera di-PHK. Kalau bukan besok, beri saja beberapa tahun lagi sampai AI jadi lebih baik. Ini adalah jalan menurun satu arah
    Bukan pertukangan kayu, melainkan bertani. Anda harus punya lahan dan menanam makanan sendiri. Satu-satunya cara bertahan adalah sama sekali tidak ikut berpartisipasi dalam ekonomi