- Agentic coding adalah pendekatan di mana manusia membuat kebutuhan dan rencana, lalu beberapa agen coding mengerjakannya, tetapi strukturnya terus memperlebar jarak antara kode yang dihasilkan dan di-commit dengan manusia
- Pendekatan ini hanya berhasil jika pengembang berpengalaman dapat meninjaunya secara kritis pada level arsitektur, tetapi penggunaan AI yang berlebihan dapat menimbulkan utang kognitif (cognitive debt) yang melemahkan kemampuan yang dibutuhkan untuk itu
- Seperti paradoks pengawasan yang dibahas dalam riset Anthropic, untuk menggunakan Claude secara efektif dibutuhkan kemampuan coding untuk mengawasinya, dan penggunaan agen coding justru dapat melemahkan kemampuan itu sendiri
- LLM cenderung digunakan untuk meningkatkan jumlah kode yang dihasilkan dalam waktu tertentu, alih-alih memperdalam pemahaman dan menjaga keringkasan; kebutuhan yang ambigu diisi dengan asumsi atau halusinasi, sehingga memicu lebih banyak review, perbaikan, dan penggunaan token
- Gangguan Claude dan fluktuasi biaya token menyingkap ketergantungan pada vendor dan ketidakpastian biaya; AI lebih cocok dipakai sebagai alat bantu perencanaan, dokumentasi, riset, dan delegasi terbatas daripada sebagai orkestrator yang menggantikan implementasi, agar utang pemahaman bisa dikurangi
Trade-off struktural
- Agen coding berguna dan kuat, tetapi sudah ada trade-off yang perlu dihitung secara kuantitatif dan praktis
- Untuk meredam ambiguitas yang berasal dari sifat AI yang non-deterministik, kompleksitas sistem di sekitarnya meningkat
- Keterampilan banyak pengembang bisa mengalami kemunduran
- Gangguan pada vendor tertentu, seperti insiden Claude Code, dapat menghentikan seluruh tim
- Biaya karyawan bersifat tetap, tetapi biaya token dapat terus berubah dan meningkat
- Agar pendekatan ini berhasil, pengembang berpengalaman harus mampu berpikir kritis pada level arsitektur dan menemukan masalah dalam ribuan baris kode hasil generasi sebelum masalah itu membesar
- Namun, alat AI dapat berdampak negatif pada pemikiran kritis dan kejernihan kognitif yang dibutuhkan untuk itu, sehingga utang kognitif (cognitive debt) bisa membesar
Bukan sekadar abstraksi baru yang sederhana
- Tafsir bahwa ini hanyalah “programmer naik ke lapisan abstraksi yang lebih tinggi” tidaklah cukup
- Ambiguitas yang makin tinggi tidak otomatis berarti abstraksi tingkat lebih tinggi
- Ketika FORTRAN, compiler, dan bahasa tingkat tinggi muncul, juga ada kekhawatiran tentang bug, ketidakstabilan, penurunan efisiensi, dan bertambahnya unsur “sihir”
- Kekhawatiran di masa lalu kebanyakan bersifat normatif dan teoretis tentang apa yang akan hilang saat teknologi baru diterima, tetapi alat AI sudah menunjukkan dampak nyata hanya dalam beberapa tahun sejak kemunculannya
- Dampaknya tidak terbatas pada pengembang junior, tetapi juga terlihat pada pengembang dengan pengalaman lebih dari 10 tahun
- Pengembang junior menghadapi kurva belajar yang lebih curam karena semakin jarang menangani kode secara langsung dan terdorong ke peran meninjau kode hasil generasi
- Code review memang penting, tetapi itu hanya setengah dari proses belajar; jika gesekan saat menulis dan men-debug kode sendiri hilang, kemampuan belajar akan sangat melemah
- Karena fenomena ini butuh waktu untuk diteliti, bukti anekdotal tetap penting untuk memahami situasi secara real-time, tetapi ada juga materi pendukung seperti laporan MIT Media Lab dan laporan terkait Microsoft
Mengapa perubahan kali ini berbeda
- Pengembang C++ yang pindah ke Java atau Python tidak sampai mengeluhkan “brain fog”, dan administrator sistem yang pindah ke AWS juga tidak merasa kehilangan kemampuan memahami jaringan
- Fenomena engineer senior yang berpindah ke peran manajerial, lalu makin jarang coding dan lama-lama menjadi “rusty”, bukanlah hal baru
- Dalam jalur lama, engineer mengumpulkan pengalaman coding, gesekan, dan pemecahan masalah selama puluhan tahun sebelum berpindah ke peran yang lebih banyak menangani keputusan arsitektur daripada sintaks
- Sekarang, bahkan tanpa pengalaman jangka panjang seperti itu, para pengembang berpindah ke workflow tingkat lebih tinggi yang menuntut mereka mengelola agen AI
- Masalahnya, workflow semacam ini menuntut keterampilan yang sama seperti yang biasanya diperoleh dari pengalaman puluhan tahun
- Engineer senior pun bukan pengecualian
- Simon Willison mengatakan bahwa meski ia adalah pengembang dengan pengalaman hampir 30 tahun, tanpa “model mental yang kokoh” tentang apa yang bisa dilakukan aplikasi dan bagaimana cara kerjanya, penalaran menjadi semakin sulit seiring bertambahnya fitur
Paradoks orkestrator yang terampil
- Riset terbaru Anthropic membahas “paradoks pengawasan” sebagai risiko dari sering memakai agen coding
- Intinya, untuk menggunakan Claude secara efektif dibutuhkan pengawasan, dan untuk mengawasi Claude dibutuhkan keterampilan coding yang justru bisa dilemahkan oleh penggunaan AI yang berlebihan
- Sandor Nyako, yang mengelola 50 engineer di LinkedIn, melihat kemunduran keterampilan menyebar di dalam organisasi dan meminta timnya untuk tidak memakai AI pada “pekerjaan yang memerlukan pemikiran kritis atau pemecahan masalah”
- Menurutnya, untuk membangun keterampilan seseorang harus mengalami kesulitan dan melatih otot berpikir mendalam tentang masalah, dan tanpa pemikiran kritis akan sulit mempertanyakan apakah AI benar atau tidak
- Standar “penggunaan berlebihan” juga tidak jelas, tetapi riset berbasis data dan materi anekdotal menunjukkan bahwa keterampilan bisa melemah dengan cepat bahkan dalam hitungan bulan
- Penggunaan agen coding menciptakan kontradiksi: ia melemahkan keterampilan yang justru dibutuhkan untuk mengelola agen itu dengan baik
LLM mempercepat bagian yang salah
- Tidak berarti kita memang harus selalu menulis kode lebih cepat
- Terutama, tidak perlu mempercepat pembuatan kode yang belum benar-benar dipahami, atau kode dalam jumlah besar yang tidak mungkin direview secara wajar dalam waktu masuk akal
- Sebelum AI, prioritas pengembang yang baik umumnya seperti berikut
- Memahami hubungan antara kode dan codebase
- Memastikan kesesuaian dengan standar yang efisien dan terdokumentasi
- Meminimalkan jumlah baris kode yang dibutuhkan untuk mencapai tujuan sambil menjaga keterbacaan
- Mempertimbangkan waktu pemrosesan
- Agentic coding dan LLM pada praktiknya membalik prioritas ini
- Kapabilitas dan pola penggunaan saat ini cenderung berfokus pada peningkatan kecepatan dengan menambah volume kode yang dihasilkan dalam jangka waktu tertentu
- Kecepatan adalah produk sampingan alami dari tingkat keterampilan yang tinggi, tetapi jika dipaksakan, hasilnya bisa berupa penurunan akurasi
- LLM memang bisa digunakan untuk meningkatkan pemahaman mendalam dan keringkasan, tetapi penerapan yang dipaksakan dan demam penggunaan berorientasi token di seluruh organisasi menunjukkan bahwa penggunaan nyata sering tidak mengarah ke sana
Coding juga merupakan perencanaan
- Sebagian pengembang merencanakan dan berpikir lebih baik lewat kode
- Berpikir dan bekerja lewat kode bukan sekadar kerja ulang yang hampa, melainkan proses yang memaksa seseorang memikirkan keamanan, performa, pengalaman pengguna, dan maintainability pada level teknis
- Dax, pembuat OpenCode, mengatakan dalam wawancara terkait Spec Driven Development bahwa saat mengerjakan tugas yang baru atau sulit, ia mengetahui apa yang harus dilakukan lewat proses mengetik kode sendiri
- Ia lebih suka membentuk konsep dengan menyentuh langsung tipe, interaksi antar fungsi, dan struktur folder, daripada menulis spesifikasi raksasa terlebih dahulu
- Apa yang diucapkan manusia tidak selalu sama dengan maksud sebenarnya, dan LLM mengisi ambiguitas dengan asumsi atau halusinasi
- Akibatnya muncul lebih banyak review, lebih banyak perbaikan oleh agen, lebih banyak penggunaan token, dan keterputusan yang makin besar dari hasil yang dibuat
- Sebaliknya, bahkan jika prompt yang ditulis sangat jelas dan terstruktur, LLM tetap dapat menghasilkan method yang berhalusinasi
- Karena LLM bukan compiler melainkan mesin prediksi token berikutnya, kita tidak bisa mengganti sistem deterministik dengan sistem probabilistik lalu berharap ambiguitas menjadi nol
- Bahkan pengembang senior yang proaktif memakai AI mulai melihat keterputusan ini sebagai masalah yang kian membesar
Ketergantungan vendor dan ketidakpastian biaya
- Saat Claude mengalami gangguan, muncul posting tentang sebagian pengembang dan tim engineering yang ikut terhenti
- Sebagian workflow dan kemampuan coding sudah mencapai tingkat ketergantungan besar pada vendor AI tertentu
- Keahlian yang dulu cukup dijalankan dengan keyboard dan editor teks kini memerlukan langganan penyedia model AI
-
Biaya token sulit diprediksi
- Penyedia model menerima subsidi besar, dan model itu sendiri berdiri di atas fondasi yang terus berubah
- Setiap rilis model baru cenderung mengulang pola benchmark tinggi, hype berlebihan, lalu keluhan setelah dipakai nyata bahwa modelnya “di-nerf”
- Keluhan bahwa pekerjaan yang sama kini menghabiskan token 2–3 kali lebih banyak juga ikut muncul
- Biaya karyawan bisa diketahui, tetapi biaya token sulit diprediksi per hari, per bulan, maupun per tahun
- Jika seluruh tim menjadikan agentic coding sebagai default, akun biaya harus dijaga sangat fleksibel
- Primeagen mengatakan bahwa jika memakai workflow agentic sepenuhnya, “penyedia model pada dasarnya memiliki Anda”
- Ini bisa menciptakan struktur industri di mana biaya konsumsi token harus dibayar hanya untuk melakukan hal-hal yang sebelumnya dikerjakan lewat pemikiran kritis dan kemampuan memecahkan masalah
- Ini bukan sekadar ketergantungan pada vendor produk, melainkan mendekati ketergantungan vendor atas kapasitas keterampilan seluruh industri
- Fondasi finansial dan intelektualnya bisa goyah kapan saja, dan LLM lokal belum siap menyerap tingkat penggunaan seperti itu
- Ini bukan persoalan teoretis, tetapi sudah diberitakan dan bahkan disorot langsung oleh penyedia model
- Riset Anthropic lainnya menyebut kemampuan debugging turun tajam 47%
- Jika AI diadopsi secara agresif di tempat kerja, khususnya software engineering, orang bisa bersandar pada AI demi hasil cepat tanpa membangun keterampilan inti untuk debugging saat masalah benar-benar muncul
Pendekatan yang menurunkan peran AI
- LLM bisa menjadi alat yang sangat kuat untuk belajar dan meningkatkan kemampuan
- LLM dapat membantu mengeksplorasi konsep dan teknik dengan lebih dalam dan lebih luas, serta menguji ide baru dengan upaya lebih kecil dibanding sebelumnya
- Alat pembuat kode sendiri bukan hal baru
- Emmet, autocomplete, dan snippet adalah alat untuk mengurangi penulisan manual dan menghasilkan kode
- COBOL juga berusaha memuat lebih banyak perintah dengan lebih sedikit penulisan melalui kata-kata bergaya bahasa Inggris seperti
MOVE, WRITE
- Moto jQuery juga adalah “write less, do more”
- LLM bisa dipandang sebagai tambahan lain dalam jajaran alat pembuat kode semacam itu
- Perbedaan pentingnya terletak pada penggunaan LLM dan agen coding sebagai proses pendukung
- Ada cara untuk memakai AI dalam brainstorming tahap perencanaan sambil tetap terlibat aktif dalam implementasi, sehingga produktivitas meningkat tanpa mengorbankan keterampilan individu
- Jika delegasi dilakukan hanya saat perlu, keuntungan produktivitas dapat diraih sambil mengurangi utang pemahaman
Pola penggunaan sehari-hari
- Gunakan LLM untuk membuat spesifikasi dan rencana, tetapi implementasi tetap dipimpin manusia
- Ini adalah cara membalik workflow “orkestrasi”, dengan porsi coding langsung antara 20% hingga 100% tergantung pekerjaannya
- Saat memakai model pun, sering kali tetap menulis pseudocode untuk memperkecil jarak antara permintaan dan kode hasil generasi
- Model digunakan untuk membuat kode sementara, dokumentasi interaktif, dan alat riset
- Gunakan seperti alat delegasi yang bertanggung jawab: untuk bertanya, mengulangi, merefaktor, dan memperjelas pendekatan
- Jangan hasilkan kode lebih banyak dari yang bisa direview sekaligus
- Jika terlalu banyak untuk direview, perlambat, pecah pekerjaannya, dan bila perlu refactor sendiri agar hasil akhirnya dipahami secara menyeluruh
- Jangan menyerahkan implementasi kepada LLM atau agen jika Anda belum pernah melakukannya sendiri atau tidak mampu melakukannya tanpa bantuan
- Pengecualiannya adalah untuk tujuan pendidikan atau tutorial, dan hasilnya sering kali kemudian dibuang
- Singkatnya, AI sebaiknya dipakai seperti Ship’s Computer di Star Trek, bukan seperti Data
Bekerja lebih baik, bukan sekadar lebih cepat
- Peningkatan produktivitas dari model memang nyata
- Pada saat yang sama, gesekan dan pemahaman yang muncul dari menangani pekerjaan secara langsung dan sering juga benar-benar penting
- Upaya untuk mendemokratisasi coding tanpa memahami coding telah berulang kali gagal
- Untuk memahami kode, seseorang harus berhadapan langsung dengan kode itu
- Jika tidak terus terlibat dan menulis kode, pemahaman dan keterhubungan itu bisa hilang
- Saat pemahaman hilang, kemampuan untuk mengelola agen dengan lebih baik juga melemah, dan fase coding AI menjadi masa transisi yang aneh serta penuh stres yang sebenarnya tidak perlu
Ini bisa menjadi eksperimen yang lebih besar
- Arus saat ini tampak seperti eksperimen berskala besar lain yang sedang dijalankan pada diri sendiri tanpa benar-benar memahami dampak jangka panjangnya
- Saat media sosial diadopsi pun, implikasi jangka panjangnya belum dipahami, dan kemudian muncul berbagai masalah seperti defisit perhatian yang meluas
- Kali ini, yang dipertaruhkan lebih berbahaya
- Jeremy Howard, pendiri fast.ai, mengatakan bahwa siapa pun yang bertaruh sepenuhnya pada agen AI sedang menjamin dirinya menjadi tidak berguna
- Jika seluruh proses berpikir dialihdayakan ke komputer, proses untuk meningkatkan kemampuan, belajar, dan menjadi lebih kompeten pun akan berhenti
1 komentar
Komentar Hacker News
Selama beberapa tahun terakhir bekerja dengan coding agentik, saya belajar lebih banyak tentang bahasa, sistem, dan alat yang saya pakai dibanding saat memprogram langsung dengan tangan selama 35 tahun
Kemampuan untuk menentukan sistem, teknik, dan pendekatan masih jauh lebih baik pada saya dibanding alat ini, tetapi alat-alat ini seperti intern yang sangat berpengetahuan yang tahu banyak detail remeh. Pengalamannya minim dan mereka antusias membuat kesalahan, tetapi setidaknya di awal mereka menerima umpan balik dan menindaklanjutinya. Hanya saja mereka tidak benar-benar memahami dan menginternalisasikannya, jadi sering lupa
Anggapan bahwa Anda harus tahu semua hal yang Anda kerjakan itu sangat naif. Jika Anda bekerja di dua tim atau lebih, akan banyak bagian yang tidak Anda pahami sepenuhnya, dan jika codebase-nya tua, hampir semua bagiannya bisa terasa asing. Dalam monorepo raksasa yang dibangun selama puluhan tahun, Anda sudah beruntung jika benar-benar memahami bahkan bagian yang oleh semua orang dianggap sebagai area keahlian Anda
Orang yang membuat klaim seperti ini biasanya sangat junior, atau hampir selalu bekerja sendirian, atau terasa seperti memegang satu proyek selama 20 tahun. Siapa pun yang bekerja di tim atau organisasi besar tidak bisa bilang mereka tahu seluruh codebase, dan orang yang melakukan pemrograman agentik juga sama. Namun, Anda bisa bertanya pada agen dan mendapat jawaban, dan sebagai orang yang seumur hidup membaca kode orang lain, saya juga bisa membaca kode yang ditulis LLM. Saya sama sekali tidak peduli apakah kode buruk ditulis mesin atau manusia, dan setidaknya mesin menerima umpan balik saya lalu bertindak
Saya sudah melihat banyak tim software yang benar-benar terhenti karena tidak bisa menyelesaikan masalah sepele begitu tiba-tiba dibutuhkan keterampilan tambahan seperti bahasa level rendah, assembly, algoritme yang tidak umum, atau protokol jaringan
Sebaliknya, kadang mereka buntu bukan karena tak mampu menafsirkan apa yang dilihat, tetapi karena menggunakan sesuatu yang black box seperti library proprietari atau OS proprietari, sehingga tidak bisa menggali ke dalam dan tidak punya cara memverifikasi bagaimana ia benar-benar bekerja
Karena itu, meski sangat jarang dibutuhkan, saya rasa harus selalu dimungkinkan untuk mengetahui semuanya tentang apa pun yang sedang kita kerjakan
Yang penting adalah tidak takut mempelajari sisa sistem, dan menjaga indeks
Di atas segalanya, Anda harus bisa memahami apa pun dengan cepat. Dengan begitu Anda bisa menangani banyak hal secara luas. Saat perlu, gali dalam; saat perlu, sapu dari level tinggi, dan ambil tingkat kedalaman yang tepat sesuai masalah
Dulu di kampus, mahasiswa ilmu komputer diajari rekayasa secara umum. Ketika saya bertanya, “Kapan saya perlu tahu teknik kimia atau sistem kontrol analog?”, jawabannya, “Mungkin tidak akan pernah dipakai. Tapi Anda harus bisa memahaminya cukup cepat untuk mengoding, lalu melupakannya nanti. Kami memberi Anda fondasi yang kokoh”
Ini juga berlaku persis di dalam codebase besar
Alat seperti git-ai [0] menangkap sesi LLM, mengaitkan setiap edit file dengan aksi agen tertentu, dan memungkinkan agen menelusuri percakapan di sekitar potongan kode tertentu, yaitu apa prompt dari pengguna, apa penalaran LLM yang menghasilkan kode itu, dan seterusnya. Ini bisa mengubah keseimbangan, tetapi belum dipakai luas
[0] https://usegitai.com/
Sebagai developer senior dengan pengalaman lebih dari 25 tahun, belakangan ini saya dilempar ke rapat dengan gaya “bisa masuk 5 menit?” dan saya benar-benar benci rapat seperti itu, ketika Anda ditarik masuk di tengah tanpa konteks apa pun
Pertanyaan ditembakkan cepat tanpa pengantar, dan itu tentang salah satu dari puluhan integrasi eksternal. Lebih buruk lagi, pihak sana memakai istilah internal mereka sendiri yang berbeda dari kami
Karena saya sangat bergantung pada model saat membuat integrasi-integrasi ini, saya sangat kesulitan memahami pertanyaannya. Itu pekerjaan yang sangat membosankan, dan ada spesifikasi eksternal yang tebal tersedia
Saya tetap positif karena merasa bahwa tanpa model, integrasi seperti ini mungkin tidak akan selesai bahkan kalau diberi waktu 10 kali lebih lama. Tetapi sekarang saya benar-benar mempertimbangkan apakah perlu mendokumentasikan ulang poin-poin “aha” agar momen tidak nyaman seperti ini tidak terulang
Saya belum pernah merasa sebodoh dan sememalukan ini dalam rapat, dan satu-satunya yang bisa saya katakan hanyalah, “Itu akan saya cek dan saya jawab, yang ini juga, yang itu juga”
Utang kognitif itu nyata, dan secara pribadi lebih menyakitkan daripada utang teknis. Utang teknis dibagi seluruh tim, tetapi utang kognitif bersifat personal, dan jika yang menciptakannya adalah saya sendiri, saya seharusnya lebih paham
Ke depan, saya akan menganggap pekerjaan belum selesai kalau saya belum membuat daftar istilah Markdown model flashcard 5 menit seperti “ini apa”, “itu apa”
Sebagai developer senior, Andalah orang yang harus menginjak rem pada perilaku yang tidak Anda sukai. Anda punya otoritas. Anda bisa bilang, “Pertanyaan yang menarik. Untuk memberi pandangan saya, saya butuh lebih banyak konteks. Bisakah Anda jelaskan singkat arsitektur sistemnya, atau masalah nyata apa yang ingin diselesaikan dengan pendekatan ini?”
Saat diperlakukan seperti itu, menjawab “Untuk menjawab pertanyaan ini dengan benar, saya perlu meninjau dokumentasi dan kode” adalah jawaban yang sepenuhnya wajar, dan cukup diplomatis
Rapat yang tidak memandang keahlian sebagai sesuatu yang dibangun, melainkan sekadar alat untuk mengonfirmasi bias konfirmasi yang kreatif, memang tidak menyenangkan
Untuk menemukan masalah dalam kode yang dihasilkan, developer harus benar-benar peduli. Banyak developer, terutama di perusahaan besar, sudah cukup melepaskan diri dari pekerjaannya dan hanya mencari cara menutup tiket serta melempar tanggung jawab dengan upaya sekecil mungkin
Developer seperti itu, bahkan kalau mereka kompeten, tidak akan berusaha memahami kode hasil generasi sampai cukup dalam untuk menemukan masalah yang dilewatkan agen. Terutama di tengah demam kecepatan yang didorong AI seperti sekarang
Kode hasil generasi memang terdengar masuk akal secara linguistik, tetapi sering meniru idiom umum secara incoherent tanpa sadar, sehingga bug nyata bisa tersembunyi secara kebetulan dengan cara yang bahkan sulit dibayangkan oleh programmer manusia biasa, bahkan yang buruk sekalipun
Karena LLM tidak punya evaluasi internal, reviewer harus menilai ini baris demi baris dengan mempertimbangkan hal tersebut, dan harus membangun ulang dari nol alasan tersembunyi serta pengetahuan implisit yang sejak awal memang tidak dimiliki LLM. Akibatnya waktu mahal bisa habis terseret ke hal-hal yang sebenarnya bukan masalah
Pada titik ini, sering kali investasinya lebih besar daripada menulis dari awal
Mungkin sekarang perusahaan-perusahaan membeli AI sampah, dan di langkah berikutnya dijanjikan “solusi” untuk itu. Kapitalisme berjalan persis seperti yang diperkirakan
Rasanya tulisan ini agak meleset dari inti
Kalau Anda banyak memakai AI, memang ada kehilangan keterampilan
Tetapi saya ingin mengakui gajah janggal di ruangan ini. AI membuat orang terlalu cepat. Bukan berarti output yang cepat itu buruk, tetapi output dan kode melaju lebih cepat daripada pemahaman menyeluruh dan pengalaman yang menghasilkan kode itu. Sistem memberi imbalan kepada orang yang bisa berbicara tentang nilai bisnis, alih-alih kepada orang yang membangun dengan keputusan aman berdasarkan pengetahuan mendalam
AI itu baik dan bisa menghasilkan solusi yang baik juga, tetapi pada akhirnya ia tidak tahu apa yang sedang dilakukannya, dan bahkan dalam skenario terbaik pun membutuhkan pengarah yang kuat
Kita sedang berada di kubangan pengembangan yang digerakkan bisnis, dan keputusan buruk tidak cukup mendapat hukuman reputasi yang keras
Dengan kata lain, saya tidak yakin kehilangan keterampilan itu masalah sebesar itu. Bisa jadi ini hanya tanda bahwa sifat pekerjaan kita sedang berubah. Mungkin kita akan masuk ke masa ketika kemampuan memahami arsitektur yang baik lebih dihargai daripada kemampuan menghafal standar C++ dan memakai ratusan fitur dengan benar
Dalam pengembangan biasa, kita cenderung lebih sering bolak-balik mempertanyakan “apakah kita benar-benar ingin membuat ini” dan “apa yang bisa salah jika begini”, idealnya sebelum PR disetujui atau sebelum merge/deploy. Sebagian dari itu sekarang bergeser menjadi “nanti lihat siapa yang mengeluh”. Seperti kata pepatah, satu ons pencegahan lebih baik daripada satu pon pengobatan
Selain itu, kodenya bukan C++ idiomatis proyek tersebut, dan LLM sepenuhnya mengabaikan API yang sudah ada. Memang bisa diperbaiki dan maintainer seharusnya menangkapnya, tetapi jumlah kode yang dihasilkan membuat semua orang harus menghabiskan terlalu banyak energi
Tulisan blog seperti ini nyaris pasti ditulis dengan bantuan AI, dan topik ini sudah bertahun-tahun menjadi bahan komentar di sini dan di seluruh internet. Penyusutan keterampilan adalah kekhawatiran serius, dan sejak 2022 sudah berulang kali dikatakan oleh semua orang yang skeptis terhadap AI, tetapi sebagian orang dan sebagian tempat tampaknya memang tidak peduli
Kalau sampai pada titik di mana Anda hanya menarik tuas mesin sampah tanpa wawasan terhadap kode, maka bisa dibilang wajar jika atasan bertanya mengapa Anda harus dibayar lebih dari 50 ribu dolar per tahun
Memakai AI untuk bergerak lebih cepat berarti mengoptimalkan hal yang salah. Di semua tempat saya bekerja, “menulis kode” sendiri selalu memakan waktu paling sedikit dibanding semua pekerjaan lain yang dibutuhkan untuk mengirim fitur
Ambil contoh fitur yang bisa dikoding dalam sehari. Pertama, semuanya harus direncanakan melalui ritual perencanaan entah Agile atau Waterfall versi perusahaan, pekerjaan dipecah, tiket JIRA dibuat, dan ditentukan siapa yang mengerjakan. Ini saja bisa butuh beberapa hari atau beberapa minggu. Lalu harus menulis dokumen desain berisi rancangan usulan dan mendapat review dari rekan atau anggota tim; untuk fitur yang substansial ini bisa memakan satu minggu lagi. Jika melibatkan banyak tim, tambahkan satu minggu lagi untuk mendapatkan persetujuan dan kesepakatan desain dari tim-tim itu. Di beberapa tempat, Anda juga perlu persetujuan untuk mulai bekerja, yang bisa menambah beberapa hari lagi tergantung jadwal dan ketersediaan pemberi persetujuan
Setelah itu, Anda menulis kodenya dalam satu hari dan meloloskan tes
Lalu ada code review, banyak bolak-balik dengan tim, beberapa iterasi, dan mungkin review tambahan. Ini bisa memakan beberapa hari atau beberapa minggu lagi. Di perusahaan yang lebih besar, Anda juga harus melewati segala macam review dari departemen lain seperti legal, privasi, performa, aksesibilitas, dan QA. Walaupun dilakukan paralel, mari tambahkan 2 minggu lagi secara konservatif. Terakhir, Anda mendorongnya ke staging dan perlu masa inkubasi tertentu di antara dogfooder internal agar yakin semuanya berjalan baik. Tambah 1 minggu. Sekarang fitur itu siap naik dari staging ke production, tetapi perusahaan yang serius tidak pernah langsung melepas apa pun ke 100% production. Persentasenya dinaikkan perlahan sambil memeriksa umpan balik dan metrik untuk berjaga-jaga jika perlu rollback. Sampai rilis penuh bisa memakan 2 minggu lagi
Jadi dalam fitur yang dari desain sampai rilis memakan sekitar dua bulan, kita ribut berusaha mengubah bagian yang memakan satu hari menjadi 5 menit
Saat membuat software, ingatlah bahwa ia adalah snapshot dari pemahaman terhadap masalah. Ia memberi tahu semua orang, termasuk diri Anda di masa depan, tentang pendekatan, kejelasan, dan kecocokan solusi terhadap masalah yang dihadapi. Jadi pilihlah dengan bijak apa yang ingin Anda katakan
Ungkapan tentang fitur yang memakan dua bulan dari desain sampai rilis, tetapi kita sibuk memotong bagian satu harinya menjadi 5 menit, sangat tepat
Pekerjaan seperti ini dulunya merupakan bagian yang tidak kecil dari keseharian semua engineer di perusahaan yang stabil. Entah disebut “platform engineering” atau apa pun, area ini sudah mati
Selain itu, ide-ide yang secara teknis berisiko dan sebelumnya tidak dicoba karena imbalannya tidak sebanding dengan risiko serta upaya, kini jadi terjangkau. Ini bukan sekadar “bergerak lebih cepat”, tetapi kecepatan untuk mencoba sesuatu mengubah sifat proses engineering itu sendiri
Jika software engineer menjadi cukup murah, banyak kebutuhan akan proses ini menghilang. Perusahaan yang sudah punya proses seperti ini akan kesulitan karena sangat sulit membongkar birokrasi tersebut, tetapi perusahaan yang dari awal tidak punya atau mampu menyingkirkannya akan mendapat keunggulan kompetitif yang besar
Ini bukan hal baru. Startup selalu bersaing dengan perusahaan mapan lewat kecepatan eksekusi. Yang baru adalah kemampuan mempertahankan kecepatan itu lebih lama
Review seperti legal, privasi, performa, aksesibilitas, dan QA juga semuanya sedang menjadi target. Jika perusahaan bisa mengalihkan tanggung jawab hukum atas review-review ini ke penyedia eksternal, mereka akan melakukannya
[0] Untuk sementara, abaikan saja ironi bahwa banyak bagian dari proses ini pada akhirnya dibebankan kepada karyawan yang justru tadinya ingin dihemat waktunya
Big Tech memang punya banyak prosedur megah seperti itu, tetapi perusahaan kecil bisa bergerak cepat dan kasar
Kualitas kode pada akhirnya bergantung pada Anda
Tidak ada yang mencegah Anda bekerja berulang kali dengan agen sampai kodenya mencapai kualitas yang persis sama seperti jika Anda menulisnya sendiri
Tulisan seperti ini cukup membuat frustrasi. Tetapi biaya token yang disebut penulis memang nyata dan berisiko
Saya memakai alat AI untuk brainstorming pendekatan dan kadang menghasilkan kode, tetapi pengetikan sebenarnya saya lakukan sendiri. Dengan begitu, seiring waktu kemungkinan saya melupakan mekanisme dan bahasa pemrograman jadi lebih kecil
Jujur, kalau semuanya hanya soal mem-prompt LLM untuk menulis kode lalu mereviewnya, saya rasa saya tidak akan mau jadi maintainer open source. Rasanya sama sekali tidak memuaskan
Kalau untuk pekerjaan berbayar sungguhan, saya penasaran bagaimana cara saya memakai LLM akan berubah. Saya menjadi software developer karena saya mencintai teknologi ini sendiri. Saya suka proses membangun, memakai otak untuk mengubah ide menjadi kode. Kalau pekerjaannya hanya mem-prompt LLM, saya tidak tahu apakah saya akan tetap bertahan di profesi ini. Setidaknya saya mungkin mulai melihat opsi pindah karier
Saya memakai cara ini untuk kode yang harus saya rawat. Meski begitu, model tetap sering menyelipkan banyak informasi salah, jadi kadang masih kena juga. Biasanya itu hal yang dulu benar tetapi sekarang salah
Untuk skrip sekali pakai atau skrip yang mudah diverifikasi, saya biarkan ia menghasilkan kode, tetapi saya minta agar tidak overengineer atau mencoba menangani semua edge case. Untuk skrip, sering kali lebih mudah dipahami jika langkah yang gagal dibiarkan error begitu saja agar terlihat jelas
Saya menghindari bahasa seperti PowerShell yang menurut saya sulit dibaca, dan lebih suka menghasilkan sesuatu yang cukup pendek untuk muat di layar sehingga bisa dibaca dan dipahami seluruhnya. Python, Bash, dan Batch adalah bahasa skrip yang paling sering saya pakai
Saya masih menolak lebih dari 50% saran AI. Karena terlalu generik, atau memindahkan kode tanpa alasan, atau kadang memang salah
Yang lucu adalah teknologi ini seolah hanya salah satu dari dua hal
Bisa menjadi teknologi untuk manajer, yang memungkinkan pendelegasian tanpa keahlian tetapi tanpa kemampuan mengetahui apakah hasilnya salah atau bahkan mustahil, atau menjadi teknologi untuk coder yang memang punya keahlian tetapi perlahan kehilangan keahlian itu
Jadi saya tidak benar-benar tahu ini untuk siapa selain VC dan pemegang saham sampai kuartal berikutnya
Sedikit di luar topik, tetapi lucu bahwa tulisan itu mengatakan Spec Driven Development adalah masa depan
Secara teknis, kita dulu sudah melakukan itu di era Waterfall. Saya agak merindukan masa ketika dokumentasi yang baik masih ada. Selama 10 tahun terakhir, mungkin lebih, saya sering hanya menerima tiket JIRA satu baris yang nyaris tidak menjelaskan apa pun, sehingga saya harus menelepon orang untuk bertanya
Saya masih menghindari bekerja dengan AI. Saya mungkin akan mencoba beberapa model lokal untuk eksperimen, tetapi saya menolak membayar sesuatu yang dibuat dengan membongkar karya orang lain. Dan sejauh ini model lokal tidak memenuhi harapan