- Di tengah arus optimasi proses, ekspektasi yang tidak realistis terhadap AI makin meluas, tetapi sekadar mengadopsi AI tidak serta-merta meningkatkan kecepatan pemrosesan
- Penyebab sebenarnya mengapa pengembangan perangkat lunak memakan waktu lama bukanlah kecepatan menulis kode, melainkan proses mengubah kebutuhan yang ambigu menjadi definisi masalah yang jelas
- Pembuatan kode dengan AI juga menghadapi masalah upstream yang sama, dan keterlibatan mendalam dari pakar domain serta pakar produk tetap mutlak diperlukan untuk hasil yang akurat
- Dalam contoh perbandingan penggunaan AI, proses handholding yang sering dihilangkan justru menciptakan kesenjangan produktivitas yang nyata, dan pengembang manusia pun akan mengalami lonjakan produktivitas jika diberi dokumentasi rinci yang sama
- Untuk benar-benar mempercepat proses, seperti pelajaran dari The Goal, prioritas utamanya adalah "memberikan input yang dapat diprediksi dan berkualitas tinggi ke titik bottleneck"
Optimasi proses dan ekspektasi AI di tengah perlambatan pasar
- Saat pasar melambat, sebagian besar organisasi cenderung fokus pada optimasi proses setidaknya sebagian; belakangan ini, unsur AI dan ekspektasi yang tidak realistis ikut ditambahkan ke dalamnya
- The Toyota Way dan The Goal mengingatkan bahwa banyak upaya optimasi proses mudah salah paham soal apa yang seharusnya menjadi fokus
- Bagian yang memakan waktu paling lama bisa menjadi sinyal untuk mulai melakukan perbaikan, tetapi itu tidak berarti masalah benar-benar berasal dari sana
- Jika hanya berharap dengan menambah orang atau AI akan meningkatkan kecepatan secara besar-besaran, kita justru gagal melihat mengapa pekerjaan terlambat
- Untuk mempercepat proses, pertama-tama perlu dipastikan apakah pelaksana kerja benar-benar memiliki input dan kondisi yang dibutuhkan untuk memulai dan menyelesaikan pekerjaan
Bottleneck visual
- Melalui contoh diagram Gantt, kita bisa melihat secara visual bahwa tahap yang paling lama adalah pengembangan perangkat lunak
- Biasanya BPMN yang digunakan, tetapi untuk memudahkan penjelasan di sini digunakan diagram Gantt
- Jika tujuannya adalah meningkatkan throughput proyek, pendekatan untuk terlebih dahulu melihat tahap yang paling lama pada dasarnya benar
- Masalahnya ada pada cara orang mencoba menyelesaikannya
- Menambah tenaga kerja ke masalah tersebut (throw people at the problem)
- Mengasumsikan AI akan membuatnya jauh lebih cepat
- Yang justru tidak diperiksa adalah "mengapa tahap ini memakan waktu lama", dan yang lebih penting, lamanya waktu tidak berarti penyebab masalah ada di tahap tersebut
Menyelesaikan masalah dari upstream
- Contohnya menggunakan pengembangan perangkat lunak, tetapi ini berlaku sama untuk semua proses yang memakan waktu lebih lama dari yang diinginkan
- Pengembangan perangkat lunak tidak menjadi lebih cepat hanya dengan meningkatkan kecepatan mengetik; kalau begitu semua orang pasti sudah ikut kursus mengetik
- Inti pengembangan perangkat lunak adalah menerjemahkan masalah menjadi solusi yang bisa diselesaikan komputer secara otomatis, sebisa mungkin dengan cara yang aman dan dapat diskalakan
- Untuk itu, dibutuhkan pemahaman menyeluruh atas masalah
- Jika lebih dekat ke pendekatan waterfall, dibutuhkan dokumen fitur atau dokumen cakupan
- Jika menggunakan agile, dibutuhkan iterasi berkelanjutan dengan pakar domain
- Yang benar-benar memperlambat pengembangan adalah proses memahami apa arti permintaan feature yang ambigu dan hanya memiliki judul
- Bahkan permintaan "kirim email ke pengguna setelah penjualan selesai (send mail to user once sale is completed)" pun belum merupakan kebutuhan yang bisa langsung diimplementasikan
- Email memang bisa dikirim, tetapi apa yang harus dimasukkan ke dalam email itu?
- Jika ada masalah dalam proses penjualan, apakah email error juga harus dikirim?
- Kapan tepatnya penjualan dianggap "selesai"?
Klaim bahwa semuanya bisa diserahkan ke AI
- Klaim yang sering terdengar adalah bahwa pembuatan kode dengan AI akan melewati tahap pengembangan, dan pengembang perangkat lunak hanya perlu berperan sebagai manajer proyek
- Banyak orang berharap tahap pengembangan perangkat lunak yang selama ini panjang akan digantikan oleh tahap pengembangan dengan AI selama sekitar 3 hari
- Orang-orang memang punya gambaran seperti apa hasil pengembangan dengan AI yang mereka harapkan, tetapi pada praktiknya tidak bekerja seperti itu; ia tetap menghadapi isu upstream yang sama
- Benar bahwa AI dapat menghasilkan kode dengan cepat (apakah itu hal yang baik adalah perdebatan terpisah), tetapi generasi yang cepat tidak sama dengan generasi kode yang benar
- Hal yang selalu diabaikan dalam perbandingan pengembangan manusia vs AI adalah proses handholding yang diperlukan agar AI bekerja dengan benar
- Pendekatan ini mungkin bisa lebih cepat daripada cara lama, tetapi itu bukan perbandingan yang adil
- Agar pengembangan dengan AI berhasil, dibutuhkan keterlibatan yang jauh lebih dalam dari pakar domain dan pakar produk
- Semua fitur harus ditulis hingga detail yang sangat kecil
- Setiap perbaikan bug juga harus dirinci secara mendetail mengenai hasil yang diinginkan
- Inilah tepatnya yang sejak awal selalu diminta oleh para pengembang perangkat lunak, yaitu ringkasan rinci tentang masalah dan hasil akhir yang diinginkan
- Jika pengembang manusia diberi jumlah dokumen feature/scope yang sama, produktivitas mereka juga akan meningkat tajam
Cara yang benar-benar meningkatkan kecepatan proses
- Untuk meningkatkan kecepatan proses, kita harus memastikan bahwa orang yang harus mengerjakan sesuatu benar-benar memiliki semua sarana untuk melakukannya
- Jika proses persetujuan hukum berjalan lambat, pertama-tama lihatlah apa yang dibutuhkan untuk memulai proses persetujuan hukum tersebut
- Jika orang harus mengejar lima pihak hanya karena dokumennya tidak lengkap, menambah lebih banyak pengacara ke departemen tidak akan membuat proses menjadi lebih cepat
- Salah satu pelajaran besar dari The Goal adalah bahwa bottleneck harus menerima input yang dapat diprediksi dan berkualitas tinggi
- "bottlenecks should receive predictable, high-quality inputs"
- Titik awal pertama dalam otomatisasi proses seharusnya bukan bottleneck itu sendiri, melainkan meningkatkan kualitas input dan prediktabilitas yang akan diterima bottleneck
1 komentar
Opini Hacker News
Ada yang bilang sejak awal yang diinginkan pengembangan perangkat lunak adalah “menerima penjelasan rinci tentang masalah dan hasil yang diinginkan”, tetapi sebenarnya itu sendiri adalah rekayasa perangkat lunak
Bahkan pada 2026, gagasan bahwa dengan requirement dan spesifikasi yang cukup rinci kita bisa membuat solusi sempurna sekaligus harus ditinggalkan
Dalam pengalaman saya, berkat AI kita jadi bisa mengiterasi fitur atau ide jauh lebih cepat, dan sekarang hambatan terbesar kebanyakan muncul dari penyelarasan dan koordinasi dengan tim lain
Jika ingin mempercepat proses, menurut saya kita harus menurunkan biaya koordinasi dan memberi individu maupun tim lebih banyak wewenang untuk menilai dan mengeksekusi
Bahkan Anthropic, meski punya spesifikasi sempurna, implementasi referensi, dan ribuan tes buatan manusia selama bertahun-tahun, tetap tidak bisa membuat sesuatu yang sesederhana compiler C yang bekerja
Model saat ini, bahkan dengan spesifikasi sempurna dan tes sempurna, belum cukup mampu untuk membuat perangkat lunak operasional yang tidak sepele tanpa pengawasan teliti dari manusia
Tanpa spesifikasi sempurna dan paket tes sempurna yang ditulis langsung oleh manusia, itu akan lebih sulit lagi, dan mungkin baru akan memungkinkan sekitar 2027
Saya sering menerima pekerjaan yang terpikir sore hari oleh orang produk, dan mereka hanya memikirkan jalur normal, kadang bahkan hanya sebagian darinya
Karena ini perusahaan global, kami harus mematuhi regulasi dan hukum di tiap negara, lalu setelah fitur diimplementasikan, kami diberi tahu “sebenarnya di 90% pasar tempat kita beroperasi, secara hukum kita tidak boleh melakukan ini”, lalu kami menambahkan fitur penonaktifan lagi
Setelah itu mereka kembali dengan, “di sebagian pasar itu sebenarnya bisa jika melalui prosedur regulasi, jadi tolong implementasikan seperti itu”
Karena tenggat sudah mepet, akhirnya solusi harus ditambal secara serampangan
Ini bukan rekayasa perangkat lunak, bahkan tidak ada kaitannya dengan perangkat lunak itu sendiri
Tugas software engineer adalah menerima daftar requirement lalu mencari cara mencapainya, dan pengumpulan requirement bukanlah masalah rekayasa perangkat lunak
Perangkat lunak adalah implementasi, produk adalah perilaku, dan perilaku dari apa yang akan dibangun seharusnya sudah diketahui sebelum mulai membangunnya dengan serius
Kalau seseorang menunda seminggu saja dan melakukan due diligence, kita bisa merancang struktur yang skalabel, mudah diperluas, mudah dirawat, dan membuat masa depan jauh lebih nyaman
Sudah lebih dari 40 tahun sejak saya menulis program pertama, dan saya belum pernah melihat kasus di mana spesifikasi diselesaikan dulu lalu perangkat lunak ditulis dan semuanya berjalan baik
Dalam rekayasa yang tidak sepele, bagian tersulit adalah memahami masalah, dan versi awal perangkat lunak adalah cara untuk sampai pada pemahaman itu
Karena itu saya rasa “pabrik perangkat lunak” berbasis AI tidak akan pernah benar-benar bekerja dengan baik
Pada akhirnya itu kembali menjadi waterfall, dengan arsitek menulis diagram UML lalu menyerahkan pekerjaan implementasi yang pada dasarnya sederhana kepada tim programmer, tetapi yang diimplementasikan justru hal yang salah
AI sangat bagus untuk bergerak cepat dari versi pertama yang salah ke versi kedua yang sedikit kurang salah
Hanya saja jangan lupa bahwa misi intinya adalah memahami masalah yang sedang ingin diselesaikan
Kalau hanya menerima spesifikasi rinci, saya cuma robot coding, dan pekerjaan seperti itu saya serahkan ke junior
Seperti dulu, pekerjaan saya adalah membaca requirement itu, memahaminya, dan memverifikasinya terhadap realitas yang saya ketahui
Hal yang sama berlaku untuk kode
Setidaknya selama 20 tahun terakhir, inti dari rekayasa perangkat lunak adalah jangan percaya siapa pun, dan itu tidak berubah serta tetap memakan banyak waktu dan usaha
Saat LLM pertama kali muncul, sepertinya orang-orang berpikir mereka cukup bilang hal seperti “buatkan klon Facebook”
Sekarang mereka mulai sadar bahwa requirement harus ditulis lebih presisi dan didefinisikan lebih baik
Inilah yang sejak dulu menjadi bottleneck perangkat lunak
Dulu saat bekerja saya benar-benar menerima requirement seperti “ambil datanya lalu berikan ke pengguna”
Tidak ada definisi data apa, disimpan di mana, atau harus dikembalikan dalam format seperti apa, jadi saya harus menghabiskan banyak waktu dengan orang produk untuk mencari tahu apa yang sebenarnya mereka inginkan
Untuk mendapatkan hasil yang baik dari LLM, hal serupa juga diperlukan, dan requirement yang ambigu menghasilkan keluaran yang ambigu
Mereka mengisi template tentang masalah apa yang ada dan mengapa, misalnya field X ada di backend tetapi tidak ada di frontend, lalu menjelaskan data akan diambil dari mana dan bagaimana, serta apa acceptance criteria-nya
Dulu mereka tidak melakukan ini karena malas atau berpikir “nanti developer yang urus”
Setelah itu developer bisa menyalin isi tiket Jira tersebut ke agen LLM pilihan mereka, atau membiarkan LLM membacanya otomatis lewat Atlassian MCP
Ini sangat membantu developer dan membuat requirement jauh lebih jelas
Jujur saja, kalau melihat tahap awalnya, rasanya PM sudah setengah jalan mengimplementasikan fitur, jadi mungkin di masa depan PM akan mengerjakan semuanya sendiri dan beberapa developer akan tersisa lebih mirip SDET daripada implementer penuh
Di sana dia menjelaskan dengan tepat karakteristik inti vibe coding dan pengalaman yang sedang kita alami sekarang
Intinya, setelah sukses awal di beberapa domain yang dipilih dengan hati-hati, ketika meluas ke luar domain itu, yang muncul adalah peningkatan produktivitas yang masuk akal tetapi tidak revolusioner
https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...
Saya tidak pernah memakai prompt yang mendekati “buatkan klon Facebook”, melainkan menjelaskan bagaimana sesuatu itu harus bekerja
Misalnya, saya pernah meminta skrip Python yang membaca
/etc/hosts, mencari nilai host tertentu yang dikonfigurasi di.conf, memberi nama pada tiap konfigurasi, menentukan environment saat ini, lalu membuat ikon di kanan atas GNOME bawaan Ubuntu 22 yang jika diklik menampilkan daftar nama konfigurasi, dan saat dipilih akan membackup/etc/hostslalu hanya mengubah baris hostname tertentuDari situ saya hampir langsung mendapatkan pengalih environment app indicator GNOME sederhana, dan setelah memperbaiki beberapa baris, sebagian besar sudah bekerja
Kalau Anda memberi LLM spesifikasi yang layak, hasilnya bagus, dan bahkan kalau Anda membuat DSL palsu untuk menjelaskan apa yang diinginkan, modelnya tetap bisa memahami
Alasan proses sebelumnya tidak berjalan adalah karena penulis requirement tidak memahami niat bisnis atau ceroboh, sehingga menghasilkan requirement yang ambigu atau buruk
LLM hanya membuat requirement ambigu atau buruk yang sama itu terlihat meyakinkan, dan masalahnya akan muncul begitu digali lebih dalam
Akan muncul pertanyaan seperti “apa maksudnya ‘mengambil data’?”
LLM justru akan langsung berkata, “Tentu! Berikut kode lengkap untuk mengambil data dan memberikannya ke pengguna,” lalu selesai
Artikel ini berasumsi bahwa AI hanya memengaruhi tahap development, padahal itu jelas tidak benar
AI bisa mempercepat semua tahap, termasuk ideasi, legal, dokumentasi, pengembangan, dan deployment
Dalam ideasi, kita bisa bertukar ide, membandingkannya dengan knowledge base, dan membuat dokumen desain; dalam dokumentasi, AI bisa menghasilkan sebagian besar isi dokumen
Development tentu saja demikian, dan dalam deployment AI bisa membuat deployment manifest, alat pengujian, serta pengetahuan terkait platform cloud
Semua tahap bisa menjadi lebih baik dan lebih cepat dengan AI, mungkin tidak seluruhnya tetapi banyak bagiannya
Hal yang sama juga berlaku pada development: ada bagian memahami masalah dan merancang solusi yang lebih baik daripada siapa pun, tetapi ada juga bagian yang murni pekerjaan remeh
Jika kita sudah tahu sebuah tombol harus melakukan X, maka mendesain tombol itu, menempatkannya, memikirkan edge case untuk keadaan hover dan press, lalu menghubungkannya ke backend adalah pekerjaan remeh yang bisa dilewati, dan prinsip yang sama berlaku di hampir semua tahap
Saat ingin menambahkan fitur penting baru, biasanya kita harus rapat berhari-hari, berminggu-minggu, bahkan berbulan-bulan dengan pihak operasional untuk memahami bagaimana pekerjaan mengalir di antara sistem X, Y, Z dan pengecualian penting apa saja yang ada
Misalnya subset A diproses begini dan B begitu, tetapi di langkah terakhir kedua grup digabung, kecuali C yang memerlukan proses khusus 97
Berdasarkan pemahaman itu, barulah muncul perancangan solusi sistem lintas beberapa sistem, campuran antara sistem internal dan sistem vendor, dengan tingkat kustomisasi yang berbeda-beda sehingga bentuk solusi akhir terdorong ke banyak arah
Mempercepat coding jelas bernilai, tetapi itu hanya satu potongan dari teka-teki, dan LLM saat ini belum membantu dalam mengumpulkan informasi domain dan mendefinisikan solusi
Ada satu hal lagi: sekarang orang-orang dari lebih banyak peran bisa membuat alat perangkat lunak untuk menyelesaikan masalah yang dulu mereka paksa selesaikan lewat prosedur manual
Kami adalah produsen kecil, jadi bukan proyek perusahaan raksasa yang memerlukan pengalaman rekayasa perangkat lunak mendalam, tetapi alat perangkat lunak sederhana di mana-mana mulai meningkatkan proses dan produktivitas
Saat penanggung jawab pengiriman akhirnya bisa menyelesaikan masalah dengan alat khusus yang sebelumnya menghabiskan banyak jam kerja manual, hasilnya benar-benar luar biasa
Kami banyak memakai AI dalam pengembangan perangkat lunak, tetapi kami tidak merilis lebih cepat, bahkan rasanya justru lebih lambat karena alasan yang sama atau alasan lain
Rasanya aneh seperti menunggu utopia datang, tetapi itu tidak kunjung datang, dan juga sulit menunjuk tepatnya di mana masalahnya
Justru ketidakcocokan pendapat dan ketidakpercayaan seperti ini menciptakan peluang dan celah di pasar
Jika rata-rata IQ orang yang terlibat dalam proyek adalah 140, maka AI dengan IQ 150 bisa mereplikasi setiap individu di seluruh pipeline
Mereka yang bilang AI tidak bisa melakukan ini atau itu harus menerima fakta bahwa kesenjangan IQ ini terus membesar secara monoton
Di satu sisi, ini tulisan yang rapi dan tepat menggambarkan apa yang dipikirkan dan dilihat di lapangan oleh banyak orang yang mengerjakan pekerjaan teknis di organisasi besar
Saya 110% setuju dengan penulisnya dan berharap orang lain juga memahami isi tulisan ini
Di sisi lain, di HN maupun di tempat kerja nyata, rasanya saya sudah puluhan kali membicarakan hal seperti ini belakangan ini
Para pemimpin punya insentif sosial dan finansial untuk berpura-pura bahwa AI benar-benar akan mempercepat segalanya, jadi mereka tidak akan diyakinkan hanya dengan satu tulisan blog
Karena itu sekarang saya cuma menunggu sampai proyek AI mereka gagal atau berjalan lambat seperti proyek-proyek sebelumnya, lalu berharap mereka belajar sesuatu
Saya bahkan jadi enggan membagikan tulisan seperti ini di kantor, karena rasanya hal-hal yang tidak sejalan dengan status quo tidak terlalu diterima
Menurut saya materi visual dan Gantt chart justru adalah bahasa ala PM yang benar-benar dipahami para PM
Selama eksekutif C-level dan investor terus memberi sinyal inovasi, ini memang tidak akan selesai dalam waktu dekat, tetapi hal seperti itu juga tidak bisa bertahan selamanya
Jadi akhir-akhir ini saya mengurus kebun dan menghabiskan waktu dengan proyek coding pribadi memakai alat agentic
Mulai dari membuat database OLTP berkinerja tinggi dari nol, lingkungan pemrograman persisten relasional-logis baru, sampai synthesizer berbasis matematika yang aneh dan soft processor FPGA
Hal-hal biasa yang dikerjakan orang-orang biasa
Jadi saya tahu apa yang bisa dilakukan alat-alat ini ketika ada di tangan satu orang, dan itu benar-benar mengagumkan
Tetapi ketika mendengar teman-teman yang masih bekerja di perusahaan bercerita tentang kuota token minimum, leaderboard “star AI coder”, “jangan review code”, dan “jangan coding manual”, saya hanya bisa menggeleng
Saya sempat mengambil sedikit pekerjaan kontrak di musim dingin dan itu cukup oke, tetapi code review sudah merosot jadi semacam duel antar-LLM sementara si pendiri vibe coding seluruh proyek baru tiap akhir pekan
Alat-alat ini kurang bagus untuk kerja tim atau rekayasa perangkat lunak tim yang sesungguhnya
Saya rasa saya akan mundur saja dan menonton sampai industrinya merapikan diri
Tempat kerja yang layak mungkin hanya yang bisa berkata “pelan-pelan saja!” dan punya orang-orang tua bijak yang cukup aman untuk mengatakannya
Sementara itu saya jual satu ikat rhubarb hasil panen di Hamilton, Ontario seharga 5 dolar
Ada juga asparagus, dan jumlahnya banyak sekali
Ada dualitas yang menarik
Untuk hal-hal yang sudah saya kuasai, LLM relatif tidak terlalu berpengaruh, tetapi untuk hal-hal yang tidak saya kuasai, dampaknya benar-benar game changer
Perusahaan besar bisa merekrut hampir semua peran yang dibutuhkan proyek, jadi efek keseluruhannya kemungkinan relatif kecil
Paling banter satu orang bisa mengerjakan lima peran secara setengah-setengah untuk menekan biaya tenaga kerja, dengan konsekuensi produk yang lebih buruk
Kombinasi keuntungan jangka pendek dan biaya jangka panjangnya sudah mudah ditebak
Tetapi bagi studio kecil atau pengembang indie, LLM adalah perubahan besar
Mampu mengerjakan lima peran meski setengah-setengah adalah lompatan yang jauh lebih besar daripada bertahan tanpa peran itu, bergantung pada aset pihak ketiga atau konten lain, atau yang lebih buruk lagi, mengimprovisasi dengan hasil mengerikan
Lihat saja hampir semua UI program yang jelas-jelas ditata oleh programmer tanpa desainer
Atau kasus ketika seseorang mencoba meniru sesuatu dari Dribbble tetapi kemampuannya tidak cukup
Dengan AI, tiba-tiba Anda bisa menyalin segala sesuatu dan semua orang dengan cukup meyakinkan, dan sebenarnya begitulah hampir seluruh cara kerja AI
Ini terdengar seperti definisi textbook
Bagi saya pribadi justru kebalikannya
LLM hanya membantu ketika saya sudah tahu persis apa yang sedang saya lakukan
Orang tampaknya tidak terlalu memahami bahwa pengembangan perangkat lunak yang tidak sepele itu bahkan bukan 50% coding
Tahap coding biasanya justru salah satu yang paling mudah dan diberikan ke developer junior
Di organisasi besar, sebagian besar perubahan produk melintasi banyak sistem dan operasi manusia
Senior dan mid-level biasanya menghabiskan waktu untuk menyelaraskan ulang prioritas lokal menjadi susunan baru di dalam entitas sibernetik yang sudah ada, lalu mendapatkan persetujuan dari tim lain yang juga punya prioritas masing-masing terhadap visi baru itu
Ini secara alami melibatkan banyak trade-off dan politik
Engineer senior akan berjuang keras agar tidak menambah “beban” pada sistem yang menjadi tanggung jawab mereka, dan untuk mencegah scope creep atau penyimpangan dari arah yang ingin mereka tuju
Karena itu dibutuhkan kompromi, atau harus dieskalasikan ke manajemen untuk memilih prioritas
Mungkin AI juga bisa menyelesaikan ini, tetapi itu pekerjaan yang jauh lebih sulit
Sekarang ia adalah pemanggil alat, jadi agen coding bisa menjalankan lint, pengecekan tipe, tes, memperbaiki error yang muncul, menggali platform observabilitas seperti Sentry untuk menemukan akar masalah, menjalankan benchmark untuk mencari kode lambat atau hot path, membaca dan menerapkan dokumen migrasi untuk versi mayor baru dari library yang digunakan agar sistem tetap mutakhir
Jika hal-hal ini tidak diatur sedemikian rupa agar memberi tekanan balik pada agen dan membuatnya lebih memahami sistem, maka ia hanya akan tetap menjadi penulis kode LLM yang bodoh
Tetapi dengan model dan harness yang membaik cepat, jelas ia bisa melangkah jauh lebih jauh dari itu
Tulisan ini secara umum benar, dan memberi petunjuk tentang di mana harus fokus jika ingin AI benar-benar mempercepat proses
Misalnya, seorang manajer produk mengatakan ia membayangkan masa depan di mana jika setelah rapat dengan stakeholder tidak keluar prototipe interaktif, maka itu dianggap gagal, dan saya rasa arahnya tepat
Prediksi lain saya adalah vibe coding akan menjadi “Excel 2.0”
Ini akan memungkinkan pembuatan aplikasi percakapan secara cukup self-service, dan membuat IT masuk ke perang tanpa akhir untuk mengubahnya menjadi sesuatu dengan jaminan keamanan yang lebih baik, kontrol akses dan logging yang layak, skalabilitas, manajemen perubahan, dan seterusnya
Dalam sudut pandang sejarah yang lebih besar, setiap pergeseran revolusioner pada awalnya menghasilkan kuda uap
Saat mesin uap ditemukan, orang membayangkan masa depan transportasi sebagai benda berbentuk kuda yang digerakkan uap dan menarik kereta lama yang sudah ada
Baru kemudian kita memahami fungsi transportasi secara terpisah dari bentuknya
Awalnya saya mulai memakai istilah kuda uap saat membicarakan MOOC, karena MOOC adalah ide kuda uap yang sangat khas
Membuat prototipe tidak memerlukan kode
Sama seperti menangkap sebuah adegan tidak selalu membutuhkan aktor dan kamera; beberapa sketsa saja sudah cukup
Gantt yang ditampilkan adalah contoh model waterfall atau metodologi lain yang menganggap perangkat lunak punya tujuan akhir yang tetap
Saat ini 99,999% perangkat lunak tidak dibangun seperti itu
Dalam pengembangan perangkat lunak modern, tidak ada garis akhir
Setiap dua minggu bisnis mengubah apa yang harus dilakukan perangkat lunak
Fitur baru, integrasi baru, fitur yang diubah, komponen yang ditingkatkan atau diganti, skala yang lebih besar, hosting yang berbeda terus bermunculan
Setelah beberapa tahun, perangkat lunak berubah secara mendasar, sementara kualitas dan pengujian terlempar ke luar jendela
Bukan hanya soal menangani perubahan dengan tambal sulam, tetapi juga penderitaan tanpa henti melawan entropi
Perangkat lunak menjadi makhluk hidup yang terluka, gaya hidupnya berubah, dan menua
Perusahaan menjadi penjaga monster seperti perawat kebun binatang yang berusaha menjaga hewan depresi tetap hidup
Manusia adalah makhluk kebiasaan, jadi dengan AI pun semua masalah yang sama akan tetap muncul
Hanya saja semuanya akan bergerak sedikit lebih cepat dan code review mungkin membuat kodenya sedikit lebih baik
Pada saat yang sama, ketiadaan tes yang baik dan keinginan untuk deploy lebih cepat akan membuat segalanya sedikit lebih buruk
Hasil tarik-menarik ini adalah kualitas perangkat lunak yang kurang lebih sama, tetapi bergerak sedikit lebih cepat
Pada akhirnya proses memang akan menjadi lebih cepat, tetapi sisanya tetap menyakitkan sehingga hampir tidak ada yang benar-benar merasakannya
Bahkan mungkin semua orang hanya akan burnout lebih cepat
Ada alasan mengapa sesuatu itu kompleks, dan tanpa menghapus alasan itu, Anda tidak bisa menghapus kompleksitasnya
Anda tidak bisa menyelesaikan masalah bisnis hanya dengan alat
Terkait pernyataan “AI bisa menghasilkan kode dengan cepat, tetapi itu tidak berarti menghasilkan kode yang benar”, sebenarnya kodenya hampir selalu benar
Yang biasanya tidak saya suka adalah cara kode itu ditambahkan
Kalau Anda cukup mengenal codebase, ada semacam ritual tentang di mana harus menambahkan sesuatu, bagaimana menamainya, seberapa banyak komentar yang perlu ditulis dan di mana
Saat agen gagal melakukan itu dengan benar, orang seperti saya jadi kesal, dan tampaknya bahkan menuliskannya di AGENTS.md pun tetap gagal
Soal “jika developer manusia diberi jumlah dokumen fitur/cakupan yang sama, produktivitasnya akan melonjak”, saya sudah hampir 20 tahun bekerja di IT dan tidak pernah percaya itu benar-benar bisa terjadi
Kalaupun terjadi, itu terlalu jarang untuk layak dibahas
Coba bandingkan usaha yang diperlukan untuk meniru sistem yang sudah ditulis dengan usaha yang diperlukan untuk membuat sistem itu dari nol
Terutama jika inputnya adalah bug atau masalah performa, model sering berhalusinasi dan salah diagnosis kalau tidak diarahkan
Meski begitu, jika Anda mengawasi apa yang dilakukannya dan mendorongnya ke arah yang benar, ia cukup bagus untuk analisis akar masalah dan investigasi, serta bisa meningkatkan efisiensi
Dibanding mesin, manusia punya batas dalam mencerna dan menganalisis informasi, jadi menurut saya peningkatan produktivitas juga memang punya plafon
AI tidak harus mem-bypass proses, tetapi tetap bisa mempercepatnya
AI bisa membantu refactoring, menulis boilerplate, menemukan error yang belum pernah dilihat sebelumnya, dan hal-hal yang tidak ditangkap linter
Banyak komentar tampaknya tidak memakai proses standar yang sudah dikenal, atau mengasumsikan bahwa kalau memakai AI maka standar itu tidak perlu diikuti
Apakah kita bisa merilis lebih banyak kode dan fitur? Tentu saja bisa, jika ada requirement yang baik dan pengujian yang memadai
Semua kode yang ditulis AI tetap harus direview dan dites, serta dipisah menjadi commit dan pull request yang terpisah
Orang yang mengajukan PR ribuan baris adalah tanda bahaya
Tanpa AI pun kita tidak akan melakukannya, jadi kenapa saat memakai AI justru begitu
Satu-satunya pengecualian yang umum diketahui hanyalah penulisan ulang besar-besaran atau refactoring besar, tetapi bahkan saat itu pun menurut saya harus ada commit individual yang bisa di-switch agar proses perubahannya bisa dilihat dan penilaian yang lebih baik bisa dibuat
Kalau seseorang menunjukkan satu commit atau PR raksasa sekali jadi, saya akan menolaknya
Itu harus dipecah menjadi bagian-bagian yang bisa diaudit oleh developer biasa