Keahlian domain selalu merupakan moat yang sesungguhnya

• Kesulitan dalam perangkat lunak bukanlah mengetik kode, melainkan memahami aturan dunia nyata seperti penggajian dan transportasi untuk membangun model domain; kode adalah hasil dari pemahaman itu
• AI agentik memungkinkan produksi perangkat lunak tanpa pemahaman domain, dan memindahkan bottleneck dari “bisakah membuatnya” menjadi “bisakah menilai apakah ini benar”
• Pakar domain seperti petugas penjadwalan logistik, coder klinis, dan aktuaris asuransi dapat menentukan apakah output sesuai dengan aturan hukum, penagihan, dan operasional meski tidak memahami kode
• Insinyur umum dapat memverifikasi arsitektur dan keandalan, tetapi di area seperti coding klinis, di mana jawaban benar terikat pada pengetahuan domain, mereka bisa melewatkan kesalahan yang tampak masuk akal
• Kemampuan paling berharga adalah penilaian untuk sekaligus memverifikasi kesehatan kode yang dihasilkan dan kebenaran outputnya, sehingga investasi pada keahlian domain menjadi semakin penting bagi insinyur berpengalaman

---

Bottleneck perangkat lunak bergeser dari implementasi ke verifikasi

• Bagian tersulit dalam menulis perangkat lunak bukanlah tindakan mengetik kode itu sendiri, melainkan terlebih dahulu membangun model domain di dalam kepala
  • Sistem penggajian mencakup penyitaan upah, potongan sebelum pajak, dan penanganan saat periode gaji melintasi waktu perubahan upah
  • Aplikasi transportasi mencerminkan feed GTFS, perbedaan antara trip dan route, serta alasan bus yang “tepat waktu” tetap bisa salah
  • Kode adalah hasil pemindahan pemahaman ini, dan memperoleh pemahaman itulah pekerjaan yang sesungguhnya
• AI agentik melemahkan hubungan antara pemahaman domain dan produksi perangkat lunak
  • Kini perangkat lunak bisa diproduksi tanpa harus membangun model domain secara langsung
  • Asumsi yang selama ini menopang seluruh profesi perangkat lunak mulai goyah
• Seperti pandangan tahun lalu, penjelasan bahwa alat seperti ini memperkuat pengembang senior yang punya penilaian memang benar, tetapi belum cukup
  • Perubahan yang lebih spesifik adalah bottleneck berpindah dari “bisakah membuatnya” ke “bisakah menilai apakah ini benar”

Siapa yang pandai menggunakan alat agentik

• Pakar domain bisa menentukan jawaban benar meski tidak memahami kode

  • Orang seperti petugas penjadwalan logistik, coder klinis, dan aktuaris asuransi mungkin tidak bisa membaca stack trace atau menjelaskan perbedaan antara hash map dan list
  • Tetapi ketika melihat jadwal yang dibuat agen, mereka langsung tahu pengemudi mana yang secara hukum tidak boleh mengambil shift tersebut
  • Mereka juga bisa tahu bahwa klaim asuransi dengan kombinasi kode tertentu tidak akan dibayarkan
  • Mereka telah menghabiskan 10 tahun di dalam alur input dan output itu, sehingga mereka tahu output yang benar untuk input yang diberikan
  • Yang diberikan agen kepada mereka adalah kemampuan produksi kode yang sebelumnya kurang mereka miliki, dan yang mereka bawa adalah ground truth yang tidak dimiliki agen

• Insinyur umum mungkin tidak bisa membedakan perangkat lunak yang dibuat dengan baik dan perangkat lunak yang benar

  • Insinyur umum yang kuat memahami arsitektur, keandalan, pengujian, dan cara mencegah sistem runtuh pada pukul 2 pagi
  • Namun dalam domain seperti coding klinis, mereka mungkin tidak bisa membedakan jawaban yang tampak masuk akal tetapi salah dengan jawaban yang benar
  • Agen bisa menghasilkan sesuatu yang dapat dikompilasi dan lolos pengujian yang dipikirkan insinyur, tetapi tetap membuat kesalahan aturan penagihan yang halus dan mahal
  • Insinyur dapat memverifikasi bahwa perangkat lunak dibuat dengan baik, tetapi sulit memverifikasi akurasi ketika kebenaran sepenuhnya ditentukan oleh domain yang tidak ada di dalam kepala mereka

• Sebelum era agen, ada jalur belajar yang menguntungkan bagi insinyur

  • Insinyur bisa mengikuti para ahli, membaca spesifikasi, melakukan kesalahan di lingkungan operasional, lalu perlahan mempelajari domainnya
  • Di banyak bidang, proses ini merupakan inti dari tangga karier
  • Tidak ada jalur yang simetris bagi pakar domain
  • Belajar membuat perangkat lunak yang andal membutuhkan waktu bertahun-tahun, dan ini adalah jalan yang secara praktis sulit mereka tempuh

• Alat agentik hanya meruntuhkan satu sisi jalur itu

  • Kemampuan yang dulu menjadi keunggulan insinyur, yaitu menerjemahkan model domain menjadi kode yang berjalan, kini menjadi murah
  • Kemampuan yang menjadi keunggulan pakar domain, yaitu mengetahui apa yang benar, tidak menjadi murah
  • Kemampuan ini tidak bisa diperoleh hanya lewat prompt, dan tidak ada skill file yang memuat pengetahuan tacit dari orang yang telah menyelesaikan ribuan proses penggajian dengan benar

• Orang yang paling berharga adalah mereka yang bisa memverifikasi di kedua lapisan

  • Orang yang tahu apakah kode yang dihasilkan itu sehat, dan juga tahu apakah jawaban yang dikeluarkan kode itu benar, akan menjadi yang paling penting
  • Alasan seseorang bisa menulis pengujian seperti “pengemudi tidak boleh melebihi 11 jam” adalah karena ia mengetahui aturannya
  • Alasan ia juga bisa menilai apakah pengujian itu sendiri bermakna adalah karena ia tahu apa yang sedang diuji
  • Agen melakukan pekerjaan menyalin dan menuangkan, sementara manusia melakukan penilaian pada dua lapisan: kode dan domain
  • Investasi penting bagi insinyur berpengalaman adalah memperoleh model yang dalam dan tervalidasi tentang domain nyata
  • Nilai dari kemampuan mekanis untuk mengubah ide yang jelas menjadi kode yang rapi telah turun drastis
  • Yang tetap langka adalah pemahaman mendalam tentang industri nyata, alat, sistem regulasi, dan proses fisik
  • Seseorang perlu memilih satu domain dan mempelajarinya sebagaimana dulu mempelajari bahasa pemrograman atau framework
  • Bagian yang tidak bisa digantikan agen, dan yang nilainya kini paling meningkat, adalah keahlian domain

[GN⁺]

Komentar Hacker News

• Saya tidak tahu berapa banyak lagi omong panjang yang dibutuhkan sampai kita mengakui bahwa di level individu, bagaimana seharusnya AI digunakan itu belum diketahui siapa pun
  Awalnya dibilang cukup jadi developer yang bagus lalu belajar memakai AI, lalu berikutnya katanya kemampuan merancang arsitektur, lalu setelah itu selera yang menentukan segalanya, dan sekarang katanya yang penting hanya pakar domain
  Sampai peningkatan atau stagnasi AI berada dalam kondisi yang stabil dan bisa diprediksi, tafsiran seperti ini akan terus tidak berarti dan besar kemungkinan salah

  • Semakin lama saya makin yakin bahwa alat AI membuat pengembangan perangkat lunak jadi lebih sulit
    Ini jadi lebih sulit karena ambang batas untuk hal-hal yang mungkin dilakukan naik jauh lebih tinggi. Developer individu sekarang bisa menangani proyek yang jauh lebih sulit, dan pada akhirnya batasannya selalu waktu; AI membantu kita menyelesaikan lebih banyak hal dalam waktu yang diberikan
    Tetapi hal yang bisa diselesaikan dalam waktu itu sendiri kini jauh lebih sulit. Kita harus memahami jauh lebih banyak hal, dan harus keluar jauh dari zona aman yang akrab sebelum era AI
    Dulu wajar menghabiskan beberapa hari untuk refactor codebase atau menyiapkan rilis fitur kecil karena itu menyentuh area sistem yang tidak akrab atau mengharuskan belajar library baru
    Berkat coding agent, kurva belajar itu memang bisa didaki jauh lebih cepat, tetapi tetap saja harus didaki sendiri. Dan jumlah informasi yang masuk juga jauh lebih besar
    Jika Anda khawatir pekerjaan Anda akan diambil vibe coder nonteknis, respons yang benar adalah membuat perangkat lunak jauh lebih baik daripada mereka. Untuk itu dibutuhkan keterampilan lebih besar, ambisi lebih besar, dan pengalaman lebih banyak, dan itu tidak mudah
  • LLM hanyalah alat tambahan di gudang senjata. Ia tidak mahakuasa dan harus ditangani dengan hati-hati seperti alat lain
    Analogi yang sejauh ini terasa paling pas bagi saya adalah membandingkan obeng bor listrik modern dengan perlengkapan lama seperti obeng atau hand drill
    Dibandingkan peralatan lama, hasil menakjubkan bisa didapat dalam waktu yang sangat singkat
    Misalnya, anekdot mengejutkan seperti “saya menyelesaikan pemasangan lantai yang biasanya memakan waktu seharian hanya dalam 1 jam, sambil beberapa kali istirahat merokok” jadi mungkin. Kalau pakai nail gun mungkin selesai dalam setengah waktu, tetapi nanti lantainya akan sulit diangkat kembali dan biayanya bisa jadi hampir dua kali lipat
    Saya juga memakai beberapa LLM on-premise dan punya akses ke model-model lain, jadi sepertinya suatu hari analogi ini akan meluas sampai ke perbedaan antar merek
    Tetapi saya tidak berpikir obeng bor listrik akan mencari pekerjaan baru. Obeng bor listrik bukan tukang kayu atau pekerja lapangan, dan tanpa manusia alat itu tidak ada gunanya
  • Ingat hype pemrograman berorientasi objek 20 tahun lalu? Kita masih membersihkan kode di codebase kita yang dipenuhi pattern secara serampangan oleh orang-orang yang cuma membolak-balik buku GoF tanpa tahu kenapa pattern itu dipakai
    Saya rasa 20 tahun lagi kita akan membersihkan sampah yang ditulis bersama Claude
    https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
  • Bahkan sebelum AI, ada juga kasus ketika menjadi pakar domain lebih berharga daripada menjadi developer perangkat lunak yang hebat
    Pada 2018 saya melihat seseorang yang sama sekali tidak punya pengalaman coding membuat alat yang menghasilkan uang lumayan hanya setelah ngoding selama sebulan, semata-mata karena dia memahami pasar niche tertentu
    Dia menunjukkan sebagian kodenya, dan itu seberantakan program pertama saya, tetapi memang memecahkan masalah nyata
  • Ini terasa mirip dengan cara penonton atau orang awam menilai olahraga profesional
    Misalnya mereka bilang, “untuk jago olahraga, Anda perlu simetri yang sempurna, dan itu sangat berkorelasi dengan stabilitas perkembangan saat janin. Semakin tinggi simetri, semakin sempurna perkembangannya”
    Lalu beberapa tahun kemudian muncul kabar bahwa salah satu kaki Bruce Lee ternyata cukup lebih pendek daripada yang lain, dan Usain Bolt juga punya perkembangan asimetris yang mirip
    Lalu mereka memutar balik klaim awal dengan mengatakan itu hanya kasus pengecualian dan tidak memengaruhi aturan umum
    Buat saja sesuatu yang menarik, dan mungkin itu akan berhasil

• Baru-baru ini saya meninjau aplikasi yang hampir jadi dibuat dengan vibe coding. Pemiliknya bilang aplikasi itu hampir siap rilis dan hanya butuh pengecekan cepat
  Setelah diperiksa, desain databasenya berantakan. Beberapa fitur berjalan dan beberapa tidak. Saya menjelaskan bagian yang hilang dan kenapa itu rusak. Seperti di tulisan aslinya, orang itu adalah pakar domain
  Bulan lalu saja dia menghabiskan miliaran token, dan alat-alatnya berkembang cepat. Tetapi memberi AI kepada pakar domain tidak berarti software engineer jadi tidak diperlukan lagi
  Pakar domain bisa membuat perangkat lunak dengan AI, dan software engineer bisa mempelajari domain dengan AI. Keduanya membawa keahlian yang berbeda

  • Arah yang saya tuju pada akhirnya tampaknya lebih dekat ke platform engineer
    Pekerjaannya menjadi membuat guardrail, validasi, library prompt, agent, dan review manual untuk melindungi para pakar domain saat mereka mulai menggunakan coding agent
    Ini sedikit mirip dukungan pelanggan internal T2/T3 atau support engineer. Perannya bukan menyelesaikan 100% masalah rutin secara langsung, melainkan menangkap titik berbahaya, edge case yang aneh, dan memastikan semua konfigurasi sudah benar
    Tentu saja, akhirnya juga harus menangani banyak perhatian lintas bidang
  • Pengalaman saya juga mirip. LLM memudahkan menjelajahi domain lain, tetapi tidak menjadikan Anda ahli di domain tersebut. Pengetahuan domain yang mendalam tetap dibutuhkan
    Meski begitu, sebagai alat untuk cepat mencoba dan menggali ide baru, LLM sangat bagus. Kalau Anda punya rasa ingin tahu, itu juga bisa menjadi akselerator belajar yang luar biasa
  • Saya kurang paham bagian “bulan lalu saja dia menghabiskan miliaran token”
    Saya memakai Claude Code (Opus 4.6, pengaturan usaha maksimum) sepanjang hari, tetapi tetap tidak paham bagaimana itu bisa terjadi. Saya juga penasaran apakah tingkat penggunaan sebesar itu benar-benar memberikan hasil yang sepadan
    Mungkin saya yang kurang tahu, tetapi saya benar-benar tidak paham bagaimana itu bisa sampai sebesar itu
  • Keahlian domain yang dipadukan dengan pola pikir QA yang konsisten mungkin bisa menggantikan software engineer, tetapi pola pikir QA yang konsisten itu langka

• Ada contoh yang sangat bagus yang baru-baru ini saya alami
  Saya sedang dalam perjalanan memancing, dan saya bertanya kepada kapten apakah dia mau melihat apakah aplikasi gratis yang sedang saya kerjakan (https://oceanconnect.ca) bisa membantu pekerjaannya
  Saya tidak begitu paham bagaimana orang menggunakan data kelautan di laut. Saya juga tidak benar-benar tahu apa yang ingin mereka ketahui, atau mengapa. Pertanyaan dan informasi tentang bagaimana orang memakai data, dan apa yang bisa kami lakukan dengan data itu, mengalir deras dan saya sama sekali tidak siap, dan mendapatkan sudut pandang itu benar-benar keren dan menarik
  Itu mengingatkan saya lagi bahwa model tidak sama dengan sistem yang diabstraksikannya, dan pengetahuan untuk mengembangkan model hampir tidak ada kaitannya dengan pengetahuan untuk menggunakannya
  Orang ini punya pengetahuan luar biasa tentang bagaimana menggunakan data cuaca di atas air. Dalam beberapa hal, dia bahkan lebih memahami datanya daripada saya, dan meskipun dia mungkin tidak menyadarinya atau tidak memahami representasi digitalnya, rasanya kalau saja dia bisa memrogram, dia akan jauh lebih mampu membuat aplikasi yang berguna untuk orang-orang seperti dirinya
  Saya jadi berpikir, kalau orang-orang seperti ini menaruh ide mereka ke layar dengan LLM di depan mereka, mereka bisa membuat sesuatu yang benar-benar luar biasa. Kalau suatu saat ada pendanaan, saya ingin mewawancarai orang-orang yang pergi ke laut setiap hari untuk menyempurnakan produknya. Pengetahuan domain itu sangat spesifik, dan orang-orang yang telah hidup puluhan tahun dalam domain yang kompleks tahu hal-hal yang sama sekali tidak akan pernah kita duga

• Generalis perangkat lunak yang digambarkan dalam tulisan ini juga punya keahlian domain. Domain itu adalah perangkat lunak
  Kalau sekarang Anda adalah insinyur perangkat lunak generalis yang hebat, Anda tidak akan lari ke domain acak mana pun hanya demi menghindari AI. Perangkat lunak adalah domain Anda, dan Anda akan tetap berada di dalamnya sementara domain itu meluas dan berubah bentuk

  • Betul. Selain itu, sekarang ada kekuatan super baru bernama AI, dan itu memungkinkan kita masuk ke hampir domain apa pun dan dengan cepat meningkatkan keahlian. Menurut saya arah tulisan ini justru terbalik

• Mungkin kabar baiknya adalah bahkan akuntan ahli spreadsheet terbaik di Barat pada akhirnya tetap membutuhkan sejumlah pengalaman pemrograman untuk melakukan verifikasi
  Anda bisa bertanya ke LLM, “kode ini melakukan apa, dan saat Y apakah hasilnya selalu X,” tetapi itu hanya menumpuk satu masalah verifikasi di dalam masalah verifikasi lain

• Intinya sejak awal memang bukan kode
  Setelah 5 tahun terakhir membuat perangkat lunak untuk venture capital dan private equity, tulisan ini benar-benar terasa relevan. Menulis kode sejauh ini adalah bagian paling mudah dari pekerjaan saya, dan bagian yang sulit adalah rekayasa keuangan serta konteks yang subtil untuk memahami apa yang sebenarnya dibutuhkan pelanggan perusahaan
  Kami sering bercanda bahwa kalau bisa, kami ingin merekrut akuntan dana senior lalu mengajari mereka pemrograman. Masalahnya, hampir tidak ada orang seperti itu. Membuat engineer memahami detail akuntansi dana sampai cukup untuk mewujudkannya ke dalam perangkat lunak juga sulit

  • Kalau hanya punya keahlian domain tanpa kemampuan teknis, pada titik tertentu hasil terbaiknya paling-paling adalah utang teknis yang sangat besar
    Faktanya, kira-kira setengah karier saya dihabiskan untuk membereskan hal-hal yang “punya cukup pengetahuan domain untuk menutup tiket atau epik, tetapi akhirnya meninggalkan banyak utang teknis”
    Misalnya, walaupun punya pengetahuan domain, orang tetap bisa salah, tidak tahu cara yang lebih baik, tidak menindaklanjuti umpan balik, atau lebih buruk lagi, tidak memeriksa ulang apa yang ditulis agen coding, jadi saya harus meninjau PR dengan sangat teliti
    Saya juga sering harus me-refactor hal-hal yang “secara teknis benar tetapi ditulis dengan sangat buruk sampai menimbulkan timeout atau membuat manajer/DBA marah”
    Insinyur perangkat lunak yang benar-benar bagus punya kemampuan dan kemauan untuk mempelajari domain, tetapi harus ada cara untuk mempelajarinya. Ada perusahaan, tim, atau rekan kerja yang memungkinkan itu, dan ada juga tempat yang hanya bilang itu penting tetapi pada akhirnya Anda cuma bisa menebaknya dari JIRA dan dari celetukan orang-orang non-IT di rapat
    Menurut saya perubahan paradigma besar dalam 5 tahun terakhir adalah bahwa sebagian besar perusahaan berharap orang bekerja sampai batas maksimal, tetapi justru kontraproduktif karena tidak memberi ruang untuk percakapan penting
    Budaya adalah variabel besar. Setidaknya ada tempat-tempat di mana Anda bisa ngobrol sebentar dengan orang di sebelah atau dengan mudah menjadwalkan rapat, dan ada juga tempat yang terasa seperti Anda harus membuat petisi di change.org hanya untuk meminta waktu berdiskusi dengan layak
    Meski begitu, inti argumennya benar. Pada akhirnya kebutuhan lebih penting daripada kode. Ada juga tempat di mana semua kebutuhan sudah terpenuhi dan tim sudah menyetujui keputusan desain, tetapi lalu seseorang yang tidak hadir sepanjang implementasi kembali dan menunda fitur hanya karena tidak suka cara penulisannya
    Lalu tahu-tahu Anda mendapati “proses batch” melakukan %numberOfRecord%*10 insert, ditambah query tambahan karena model data yang dirancang buruk, dan melakukan SQL upsert dengan cara terburuk yang bisa dibayangkan. Yaitu mengambil dulu dari DB, lalu menambahkan record untuk di-insert jika belum ada. Sambil terus melakukan hal-hal yang makin mencurigakan atas nama “peningkatan performa”, alih-alih memikirkan ulang pola query di lapisan data. Saya pernah melihat ini lebih dari sekali sepanjang karier saya

• Setiap kali saya membaca tulisan yang sangat umum dan terdengar seperti saran menghadapi AI, saya teringat bahwa industri perangkat lunak mirip dengan industri konstruksi
  Industri ini tidak akan pernah benar-benar rapi, tidak akan sepenuhnya teroptimasi, dan pada akhirnya selalu harus bersifat kustom. Karena ia harus menyesuaikan diri dengan realitas yang punya selera, konteks, dan lokalitas yang sangat berbeda-beda
  Sesekali memang bisa muncul alat atau bahan baku yang bagus

• Saya dulu berpikir parit pertahanan perangkat lunak yang sesungguhnya terletak pada tidak adanya kebutuhan nyata akan pengetahuan atau pengalaman yang luas baik tentang sistem maupun domain
  Menyalin selera dan efek jaringan jauh lebih sulit. Faktanya, bahkan sebelum vibe coding, startup yang didanai VC dan kaya talenta serta sumber daya pun jarang berhasil mendapatkan posisi yang mapan di pasar
  Itulah sebabnya orang usia 20-an bisa bersaing dengan para ahli dari berbagai bidang. Reaksi penolakan saat ini menurut saya adalah lahirnya orang-orang “punya X tahun pengalaman industri” seperti yang lazim kita lihat di industri matang lainnya

• Saya bekerja sebagai analis, dan di grup kami sekitar 20% analis memiliki kemampuan teknis yang kuat, yaitu kemampuan software engineering, sedangkan sisanya adalah analis tradisional atau pakar domain
  Selama setahun terakhir saya melihat analis nonteknis memanfaatkan model AI untuk bagian pengembangan dan produktivitas pengembangan alat internal meningkat
  Sebelumnya, hampir semuanya dikembangkan dengan Tableau. Itu adalah cara yang paling mudah diakses bagi orang yang bukan developer untuk membuat alat yang berfungsi
  Beberapa hari lalu pun seorang analis di grup kami mempresentasikan alat yang sedang dia kerjakan, yang pada dasarnya merupakan port laporan Tableau menjadi aplikasi yang lebih fleksibel

  • Grup kami perlahan mengganti Tableau dengan alat yang kami buat sendiri, dan peningkatan performanya sangat besar
    Rasanya perusahaan-perusahaan BI seperti ini akan berada dalam masalah besar. Terutama perusahaan seperti Tableau yang bahkan membuat hal sederhana seperti histogram nyaris mustahil untuk digambar menurut saya

• Teman saya adalah seorang insinyur elektro dan baru-baru ini melampaui rating catur FIDE 2000. Dia sudah bermain catur selama 30 tahun, dan bahkan mendirikan klub catur saat SMA. Di kampus dia hanya sedikit belajar pemrograman sambil menangani mikrokontroler
  Saya lebih dekat ke pekerja serabutan infrastruktur/administrasi dengan gelar ilmu komputer, dan sudah menekuni pemrograman sebagai hobi selama 30 tahun. Rating Lichess saya bahkan di hari terbaik pun hanya 1000
  Kami pernah mengadakan kompetisi bot catur. Aturannya open-book, bebas memakai AI untuk pemrograman, dan boleh memanfaatkan apa pun seperti opening book atau endgame table. Saya mengalahkannya telak, tetapi di catur papan sungguhan saya hanya pernah menang dua kali dalam 20 tahun
  Dia akan mengalahkan 99% pemain acak di dunia nyata, sedangkan saya mungkin hanya bisa mengalahkan sekitar 20%
  Saya tidak yakin persis apa yang ingin saya katakan, tetapi rasanya sekarang pengetahuan domain mungkin bukan lagi segalanya. Atau mungkin domainnya sendiri yang sudah berubah

  • Dari sudut pandang AI, tampaknya pemahaman yang paling moderat adalah bahwa ada domain yang dangkal, misalnya catur, dan ada domain yang dalam
  • Saya tidak tahu apa hubungan kemampuan benar-benar bermain catur, selain beberapa prinsip sederhana, dengan menulis algoritme penelusuran pohon permainan yang efisien
    Kamu menantangnya dalam kompetisi pemrograman, dan kamu yang jauh lebih berpengalaman sebagai programmer itulah yang menang. Bahkan jika AI boleh digunakan, menurut saya pengetahuan domainmulah yang menjadi faktor penentu di sini