29 poin oleh GN⁺ 2026-05-31 | 7 komentar | Bagikan ke WhatsApp
  • Kesulitan dalam perangkat lunak bukanlah mengetik kode, melainkan memahami aturan dunia nyata seperti penggajian dan transportasi lalu membangun model domain; kode adalah hasil dari pemahaman itu
  • AI agentik memungkinkan produksi perangkat lunak bahkan 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 menilai apakah output sesuai dengan aturan hukum, penagihan, dan operasional meski tidak memahami kode
  • Insinyur generalis dapat memverifikasi arsitektur dan keandalan, tetapi di bidang seperti pengodean klinis, yang jawaban benarnya terikat pada pengetahuan domain, mereka bisa luput dari kesalahan yang tampak meyakinkan
  • Kemampuan paling bernilai adalah penilaian untuk memverifikasi sekaligus kewarasan kode yang dihasilkan dan kebenaran outputnya; bagi insinyur berpengalaman, investasi pada keahlian domain menjadi semakin penting

Memahami domain, bukan menulis kode, adalah inti persoalan

  • Dalam pengembangan perangkat lunak, bagian yang sulit bukanlah menulis kode, melainkan lebih dulu membangun model cara kerja domain di dalam kepala
  • Kode adalah transkripsi dari pemahaman itu, dan proses memperoleh pemahaman itulah pekerjaan yang sebenarnya
  • Contoh konkret

    • Sebelum meluncurkan sistem penggajian, perlu memahami potongan sita (garnishment), potongan pra-pajak, serta penanganan saat periode gaji melintasi waktu perubahan tarif upah
    • Sebelum meluncurkan aplikasi transportasi umum, perlu mempelajari apa itu feed GTFS, mengapa trip dan route berbeda, dan bagaimana bus yang “tepat waktu” tetap bisa salah

Agentic AI memutus mata rantai itu

  • Agentic AI memutus hubungan antara pembangunan model dan produksi perangkat lunak, sehingga perangkat lunak bisa dibuat tanpa model tersebut
  • Ini meruntuhkan asumsi yang selama ini menjadi dasar penataan seluruh profesi
  • Pandangan tahun lalu menyatakan bahwa alat ini memperkuat developer senior yang punya daya menilai; itu benar, tetapi tidak lengkap
  • Perubahan yang benar-benar teramati adalah bahwa kendala utama berpindah dari “bisakah membuatnya” menjadi “bisakah menilai apakah ini benar”

Perbandingan dua tipe orang

  • Pakar domain (tanpa latar belakang perangkat lunak)

    • Orang seperti petugas penjadwalan logistik, coder klinis, dan aktuaris asuransi; mereka tidak bisa membaca stack trace dan juga tidak bisa menjelaskan perbedaan hashmap dan list
    • Namun ketika melihat jadwal yang dihasilkan agen, mereka segera tahu bahwa tidak ada pengemudi yang secara hukum boleh mengambil shift itu, atau bahwa penagihan pada kode tersebut tidak akan pernah dibayar
    • Karena selama 10 tahun hidup di antara input dan output, mereka tahu output yang benar untuk input yang diberikan, dan agen melengkapi secara tepat kemampuan produksi kode yang selama ini kurang pada mereka
    • Yang mereka bawa adalah ground truth yang tidak bisa diberikan agen
  • Insinyur generalis kuat tanpa pengalaman domain

    • Mereka bisa merancang apa saja, dan memahami keandalan, pengujian, serta cara memastikan sistem tidak runtuh pada pukul 2 pagi
    • Namun ketika ditempatkan pada pengodean klinis, mereka tidak bisa membedakan jawaban salah yang tampak masuk akal dari jawaban yang benar
    • Agen menghasilkan aturan penagihan (billing rule) yang salah namun halus dan mahal, meski kodenya dapat dikompilasi dan lolos pengujian yang ditulisnya sendiri
    • Insinyur tidak memiliki oracle, sehingga mereka bisa memverifikasi bahwa perangkat lunaknya dibuat dengan baik, tetapi tidak bisa memverifikasi bahwa itu akurat — karena akurasi didefinisikan oleh domain yang tidak mereka miliki dalam kepala

Asimetri: hanya satu jalur yang runtuh

  • Sebelum hadirnya agen, insinyur memiliki jalur yang tidak dimiliki petugas penjadwalan — dengan mengikuti pakar, membaca spesifikasi, dan mengalami kesalahan di lingkungan operasional, mereka bisa pelan-pelan menyerap model domain
  • Di banyak bidang, jalur ini adalah tangga karier itu sendiri; sementara pakar domain tidak punya jalur setara berupa kerja bertahun-tahun untuk mempelajari perangkat lunak yang andal
  • Alat agentik hanya meruntuhkan satu dari dua jalur itu
    • Keunggulan insinyur dalam menerjemahkan model domain ke kode kini menjadi murah
    • Keunggulan pakar domain dalam mengetahui apa yang benar tidak demikian, dan tidak bisa dicapai lewat prompt
    • Tidak ada file keterampilan yang memuat pengetahuan implisit (tacit knowledge) dari seseorang yang pernah memproses ribuan penggajian

Talenta yang bisa memverifikasi kedua lapisan

  • Dalam dunia baru ini, orang paling bernilai adalah mereka yang memiliki kedua keterampilan itu dan dapat memverifikasi pada kedua lapisan
  • Mereka tahu bahwa kode yang dihasilkan itu kokoh, dan sekaligus tahu bahwa jawaban yang dikeluarkan kode itu benar
  • Karena memahami aturannya, mereka dapat menulis pengujian yang mengodekan bahwa “pengemudi tidak boleh melebihi 11 jam”, dan karena tahu apa yang sedang diuji, mereka dapat menilai bahwa pengujian itu memang bermakna
  • Agen menangani transkripsi, sementara manusia menangani dua kali penilaian

Taruhan bagi insinyur berpengalaman

  • Bagi insinyur senior yang memikirkan ke mana harus berinvestasi dalam beberapa tahun ke depan, inilah arah taruhannya
  • Keterampilan mekanis untuk mengubah ide yang jelas menjadi kode yang rapi akan turun nilainya secara drastis
  • Yang tetap langka adalah model yang dalam dan terverifikasi tentang suatu domain nyata, dan itulah yang harus dikejar
    • Pilih satu dari industri, produk keuangan, sistem regulasi, atau proses fisik, lalu pelajari domain itu sebagaimana dulu Anda mempelajari bahasa pemrograman atau framework
    • Inilah bagian yang tidak bisa digantikan oleh agen, dan kini justru memiliki nilai terbesar

7 komentar

 
xguru 2026-06-01

Keterampilan mekanis untuk mengubah ide yang jelas menjadi kode yang bersih nilainya memang turun drastis

Tapi saya juga merasa ini terlalu meremehkan kode.
Pengembangan perangkat lunak itu sendiri juga merupakan sebuah domain, dan menjadi mahir di dalamnya juga merupakan keahlian profesional.
Perangkat lunak yang dibuat AI mungkin bisa menyelesaikan masalah secara fungsional, tetapi tidak bisa benar-benar menyempurnakannya, dan seperti halnya tetap dibutuhkan orang untuk mengisi bagian itu.

 
heycalmdown 2026-06-01

Sama dengan pendapat yang muncul di komentar Hacker News berikut.

Generalis perangkat lunak yang digambarkan dalam tulisan ini juga punya keahlian domain. Domain itu adalah perangkat lunak.

Menurut saya, ini sejalan dengan pendapat tersebut.

 
roxie 27 hari lalu

Saya agak punya pandangan yang berbeda terhadap pendapat xguru.

Mari kita ambil Excel sebagai contoh. Secara umum, ada tingkat kemampuan yang dibutuhkan untuk pekerjaan kantor, dan begitu melewati itu, kebanyakan orang tidak merasa perlu belajar lebih jauh. Memang ada orang yang sangat mahir menggunakan Excel seperti ini, tetapi itu benar-benar kasus yang luar biasa.

Dalam kasus kode juga — meski sekarang belum seperti itu — saya sempat berpikir mungkin ini bisa terbelah menjadi dua jalur seperti itu. Sebagian kecil orang yang membuat produk yang benar-benar kompleks, dan sebagian besar lainnya yang menggunakannya seperti mengendarai sepeda.

 
xguru 27 hari lalu

Hm? Orang yang mahir menggunakan Excel tentu tidak diremehkan.
Tapi kalau dibilang nilai dari aktivitas coding itu sendiri menurun, kesannya memang seperti meremehkan.

Menurut saya, hanya karena sesuatu digunakan seperti naik sepeda, bukan berarti pantas mengatakan kepada orang yang membuat produk kompleks bahwa nilai Anda tidak seberapa.

 
roxie 27 hari lalu

Saya setuju dengan poin yang Anda sampaikan,

yang dimaksud adalah teknologi dan kode yang layak disebut perangkat lunak kompleks akan berkurang. Jika hal-hal yang bisa dibuat ringan dengan AI semakin bertambah.

Meminjam ungkapan dari ringkasan GeekNews: tampaknya kode yang tidak bisa digantikan oleh agen akan semakin berkurang dari hari ke hari.

 
devpain 2026-06-01

Bagian itu berada dalam kondisi di mana nyaris tidak ada lagi pengetahuan tacit, dan karena pakar domain kelas atas merancang agen lalu menanamkannya ke dalam model,,, saat ini pentingnya pengetahuan domain memang ditekankan, tetapi saya tidak yakin apakah klaim yang sama masih akan disampaikan 1 tahun lagi. Pada akhirnya pengetahuan tacit sedikit demi sedikit berpindah menjadi prompt, dan model akan menyaring pengetahuan tacit yang ditambahkan pengguna ke dalam prompt lalu menyuntikkannya kembali ke model. Model agen yang sudah dibekali pengetahuan tacit tentu akan bernilai, tetapi menurut saya bahkan ini pun akan diperdagangkan di pasar. Agen yang memiliki pengetahuan domain jauh lebih kaya di bidang tersebut.
Dalam 1 tahun ke depan, saya memperkirakan bahwa melampaui orkestrasi, yang akan menjadi kriteria penilaian adalah manajemen agen (seperti perusahaan).

 
GN⁺ 2026-05-31
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