- Tentang mengapa sulit menggantikan developer dengan AI
- Banyak berita mengatakan AI akan menggantikan developer, tetapi dalam membangun perangkat lunak, bagian tersulit bukanlah coding melainkan membuat requirement yang jelas dan akurat
- "Itu bukan bug, itu fitur. Eh, tunggu sebentar, ternyata bug"
- Requirement yang tidak jelas melahirkan bug
- "Jika AI ingin menggantikan developer, klien harus bisa menjelaskan dengan tepat apa yang mereka inginkan. Kita aman"
Realitas AI: catur vs. mobil otonom
- AI telah berhasil dimanfaatkan di domain seperti catur, yang aturannya terbatas dan jelas, tetapi mobil otonom merupakan tantangan yang jauh lebih kompleks bagi AI karena variabel dan situasi pengecualiannya nyaris tak terbatas
- Di bidang teknologi, standar umumnya adalah availability 5 atau 6 angka 9 (99.999% hingga 99.9999%)
- Biaya untuk mencapai 99% tidak terlalu besar. 99% berarti situs web Anda down kurang dari 3 hari per tahun (87,6 jam)
- Tetapi setiap kali satu angka 9 ditambahkan, biaya untuk mencapainya meningkat secara eksponensial
- Untuk mencapai 99.9999%, downtime harus hanya 31,5 detik per tahun (99.9% = 526 menit/8,76 jam, 99.99% = 52 menit, 99.999% = 5,2 menit)
- Ini membutuhkan perencanaan dan upaya yang sangat besar, dan tentu saja mahal
- Seberapa pun bagusnya AI, selalu ada risiko kecelakaan
- Kita tidak tahu seberapa besar tingkat kecelakaan yang bisa ditoleransi, tetapi setidaknya harus setara dengan manusia
AI tidak bisa membuat perangkat lunak, hanya bisa membuat kode
- Membuat dan memelihara perangkat lunak memiliki lebih banyak kesamaan dengan mengemudi daripada dengan catur
- Ada sangat banyak variabel, dan aturan ditentukan melalui pertimbangan
- Saat membuat perangkat lunak, tentu ada hasil yang diinginkan, tetapi itu tidak sesederhana catur
- Perangkat lunak hampir tidak pernah benar-benar selesai. Ini adalah exercise berkelanjutan di mana fitur terus ditambahkan dan bug diperbaiki
- Berbeda dengan perangkat lunak, permainan catur selesai begitu Anda menang atau kalah
- Dalam pengembangan perangkat lunak, kita memiliki alat untuk membuat desain perangkat lunak menjadi seperti mesin aturan pada catur: spesifikasi teknis
- Dalam kondisi terbaik, spesifikasi teknis ini memprediksi perilaku pengguna dan alur program
- Namun, kasus seperti ini jarang terjadi. Terlalu sering kita menerima wishlist sebagai spesifikasi fitur, atau wireframe yang ditulis di atas serbet, atau dokumen requirement yang tidak jelas, lalu diminta mengambil keputusan terbaik sendiri
- Lebih parah lagi, requirement berubah dan kadang diabaikan
- Requirement yang mustahil. Artikel asli menceritakan contoh proyek survei COVID lewat SMS di tempat tanpa WIFI. Seharusnya proyek itu memang tidak dijalankan
- Apakah AI benar-benar bisa menangani situasi seperti itu?
- Agar AI bisa membuat perangkat lunak yang fungsional, kita harus benar-benar tahu apa yang kita inginkan dan mampu mendefinisikannya dengan jelas dan akurat
- Dalam 10 tahun terakhir, industri perangkat lunak telah beralih dari waterfall ke agile
- Dalam waterfall, stakeholder mengira mereka tahu apa yang mereka inginkan dan bisa mendokumentasikannya, tetapi pendekatan itu gagal karena ketika produk akhir diserahkan, mereka sangat kecewa
- Agile adalah solusi untuk proses ini
- AI mungkin paling cocok untuk menulis ulang perangkat lunak yang sudah kita miliki ke hardware yang lebih baru dan bahasa baru
- Masih banyak tempat yang menggunakan perangkat lunak yang ditulis dalam COBOL, tetapi hampir tidak ada lagi yang mempelajari bahasa itu
- AI mungkin bisa membuat ulang perangkat lunak yang sudah ada lebih cepat daripada manusia, tetapi itu karena seseorang sebelumnya sudah memikirkan bagaimana perangkat lunak tersebut seharusnya dibuat
- AI bisa membangun perangkat lunak dengan cukup baik jika kita memakai proses waterfall yang kita sebut sebagai death march
- Siapa yang buruk dalam waterfall? Manusialah itu
- Bukan hanya bagian menulis dokumen yang kemudian diberikan kepada tim programmer, tetapi juga semua hal sebelum itu
- AI bisa melakukan beberapa hal yang menakjubkan, tetapi AI tidak bisa membaca pikiran Anda atau memberi tahu apa yang sebenarnya Anda inginkan
8 komentar
Saya rasa ini berlaku bukan hanya untuk pengembangan perangkat lunak, tetapi juga untuk seluruh bidang yang memiliki kekhawatiran terhadap AI secara umum.
Sepertinya teknologi untuk mengotomatisasi verifikasi requirement akan berkembang pesat. Otomatisasi testing tampaknya akan semakin bersinar... Apakah dunia di mana manusia hanya mengelola test case kini akan datang....
"Siapa yang paling mengerikan dalam waterfall? Tentu saja manusia"
Sebagai orang yang pernah mengalaminya, saya sangat relate
Saya sudah membaca tulisan yang bagus ini, sekarang mari kita pergi merapikan issue.
Meski AI mungkin sulit menggantikan developer, bukankah kalau developer hanya melempar beberapa keyword, pengodeannya bisa dikerjakan AI?
"ngoding dengan mulut" yang dulu cuma dibicarakan sebagai lelucon mungkin bisa jadi kenyataan..
Bukankah sekarang pengembangan seperti ini dilakukan dengan memanfaatkan Copilot atau AI lainnya?
Kalau menulis dalam bahasa Inggris isi yang diperlukan di komentar, alat itu akan membuatkannya sendiri, jadi kita tinggal mengecek apakah hasilnya sesuai dengan yang diinginkan atau tidak.
Saya sangat setuju dengan isi ini. Saya pikir insinyur perangkat lunak masa depan semuanya akan memiliki kemampuan ala TPM, dan akan dituntut untuk memilikinya.