00:00:00[MUSIK]
00:00:21>> Halo semuanya, selamat siang.
00:00:22Saya akan memulai pembicaraan ini dengan sebuah pengakuan.
00:00:26Saya pernah merilis kode yang tidak terlalu saya pahami.
00:00:29Saya membuatnya, mengujinya, menerapkannya, tapi tidak bisa menjelaskan cara kerjanya.
00:00:33Dan masalahnya, saya berani bertaruh Anda semua pun pernah melakukannya.
00:00:37>> [TAWA]
00:00:40>> Jadi, sekarang kita semua bisa mengakui bahwa kita
00:00:41sering merilis kode yang tidak lagi kita pahami, saya ingin mengajak Anda menelusuri,
00:00:44melihat bagaimana hal ini bisa terjadi.
00:00:46Pertama, melihat ke belakang, kita tahu bahwa sejarah cenderung berulang.
00:00:50Kedua, kita telah terjebak dalam sebuah perangkap.
00:00:52Kita mencampuradukkan antara yang "mudah" dengan yang "sederhana".
00:00:55Terakhir, ada solusinya, tapi itu menuntut kita untuk tidak membiarkan pihak lain berpikir untuk kita.
00:01:00Jadi, saya menghabiskan beberapa tahun terakhir di Netflix membantu mendorong adopsi alat bantu AI.
00:01:05Dan harus saya katakan, percepatannya benar-benar nyata.
00:01:07Item backlog yang dulunya memakan waktu berhari-hari, kini selesai dalam hitungan jam.
00:01:10Dan refaktor skala besar yang sudah direncanakan bertahun-tahun akhirnya bisa dikerjakan.
00:01:15Namun, ada satu hal.
00:01:16Sistem produksi yang besar selalu gagal dengan cara yang tidak terduga.
00:01:19Lihat saja apa yang terjadi dengan Cloudflare baru-baru ini.
00:01:21Saat itu terjadi, Anda harus memahami kode yang sedang Anda periksa.
00:01:23Masalahnya sekarang adalah kita menghasilkan kode dengan kecepatan dan volume yang sangat besar.
00:01:28Pemahaman kita sulit untuk mengimbanginya.
00:01:29Sial, saya tahu itu, karena saya sendiri melakukannya.
00:01:34Saya membuat banyak kode, melihatnya, dan berpikir, "Saya tidak tahu apa fungsinya."
00:01:39Tapi pengujiannya lolos, kodenya jalan, jadi saya rilis saja.
00:01:41Intinya, hal ini sebenarnya bukan hal baru.
00:01:44Setiap generasi insinyur perangkat lunak akhirnya akan menemui jalan buntu di mana
00:01:48kompleksitas perangkat lunak telah melampaui kemampuan mereka untuk mengelolanya.
00:01:50Kita bukan yang pertama menghadapi krisis perangkat lunak,
00:01:52tapi kitalah yang pertama menghadapinya pada skala pembuatan yang tak terbatas ini.
00:01:56Mari kita mundur sejenak untuk melihat dari mana semua ini bermula.
00:01:58Di akhir tahun 60-an dan awal 70-an, sekelompok ilmuwan komputer cerdas saat itu
00:02:03berkumpul dan berkata, "Hei, kita sedang dalam krisis perangkat lunak."
00:02:06Kita memiliki permintaan perangkat lunak yang besar, namun kita tidak sanggup memenuhinya.
00:02:11Proyek memakan waktu terlalu lama, dan progresnya sangat lambat.
00:02:15Kita tidak bekerja dengan baik.
00:02:16Lalu Dijkstra melontarkan kutipan yang sangat bagus.
00:02:20Dia berkata, saat kita dulu memiliki komputer yang lemah—saya memparafrasekan kutipan yang lebih panjang—
00:02:23pemrograman hanyalah masalah kecil.
00:02:26Dan sekarang karena kita memiliki komputer raksasa, pemrograman telah menjadi masalah raksasa.
00:02:31Dia menjelaskan bahwa saat tenaga perangkat keras meningkat 1.000 kali lipat,
00:02:34kebutuhan masyarakat akan perangkat lunak pun tumbuh secara proporsional.
00:02:37Sehingga hal itu membebani kita, para pemrogram, untuk mencari cara di antara berbagai metode,
00:02:41bagaimana cara mendukung perangkat lunak sebanyak ini?
00:02:43Siklus seperti ini terus berulang.
00:02:47Di tahun 70-an kita mendapatkan bahasa pemrograman C, sehingga kita bisa menulis sistem yang lebih besar.
00:02:50Di tahun 80-an kita memiliki komputer pribadi, semua orang bisa menulis perangkat lunak.
00:02:53Di tahun 90-an kita mendapatkan pemrograman berorientasi objek.
00:02:56Hierarki bawaan yang memusingkan, terima kasih Java untuk itu.
00:03:00Di tahun 2000-an kita mengenal Agile, dan kita punya sprint serta
00:03:03Scrum Master yang memberi tahu apa yang harus dilakukan, tidak ada lagi metode Waterfall.
00:03:06Di tahun 2010-an kita punya Cloud, Mobile, DevOps, segalanya,
00:03:09perangkat lunak benar-benar menguasai dunia.
00:03:10Dan hari ini kita punya AI, Co-Pilot, Cursor, Claude, Codex, Gemini, dan lain-lain.
00:03:17Kita bisa menghasilkan kode secepat kita mendeskripsikannya.
00:03:19Polanya berlanjut, tetapi skalanya telah benar-benar berubah, sekarang menjadi tak terbatas.
00:03:23Fred Brooks, Anda mungkin mengenalnya dari bukunya, "The Mythical Man-Month".
00:03:29Dia juga menulis makalah pada tahun 1986 berjudul "No Silver Bullet".
00:03:32Di sana ia berargumen bahwa tidak akan ada satu inovasi pun yang akan memberikan kita
00:03:36peningkatan produktivitas perangkat lunak hingga sepuluh kali lipat.
00:03:38Mengapa?
00:03:40Karena menurutnya bagian yang sulit bukanlah mekanisme pengkodean, sintaksis,
00:03:44pengetikan, atau kode boilerplate.
00:03:45Bagian tersulitnya adalah memahami masalah sebenarnya dan merancang solusinya.
00:03:49Tidak ada alat yang bisa menghilangkan kesulitan mendasar tersebut.
00:03:52Setiap alat dan teknik yang kita ciptakan hingga saat ini hanya mempermudah mekanismenya.
00:03:55Namun tantangan intinya,
00:03:57memahami apa yang harus dibangun dan bagaimana cara kerjanya, tetap sama sulitnya.
00:04:00Jadi, jika masalahnya bukan pada mekanismenya, mengapa kita terus mengoptimalkannya?
00:04:06Bagaimana insinyur berpengalaman bisa berakhir dengan kode yang tidak mereka pahami sekarang?
00:04:09Jawabannya, menurut saya, bermuara pada dua kata yang sering kita campuradukkan: sederhana dan mudah.
00:04:14Kita cenderung menggunakannya secara bergantian, tetapi
00:04:16keduanya sebenarnya berarti hal yang sama sekali berbeda.
00:04:18Saya sempat ketahuan saat makan malam pembicara sebagai pengguna Clojure, jadi
00:04:21hal ini cukup jelas di sini.
00:04:23Rich Hickey, pencipta bahasa pemrograman Clojure,
00:04:25menjelaskan hal ini dalam ceramahnya tahun 2011 berjudul "Simple Made Easy".
00:04:29Dia mendefinisikan sederhana (simple) berarti satu lipatan, satu jalinan, dan tanpa kekusutan.
00:04:33Setiap bagian melakukan satu hal dan tidak saling membelit dengan yang lain.
00:04:36Dia mendefinisikan mudah (easy) sebagai sesuatu yang berdekatan, sesuatu yang dalam jangkauan.
00:04:39Apa yang bisa Anda akses tanpa usaha keras?
00:04:41Salin, tempel, rilis.
00:04:43Sederhana adalah tentang struktur.
00:04:45Mudah adalah tentang kedekatan.
00:04:48Masalahnya, kita tidak bisa membuat sesuatu jadi sederhana hanya dengan mengharapkannya.
00:04:51Kesederhanaan membutuhkan pemikiran, desain, dan penguraian.
00:04:54Tetapi kita selalu bisa membuat sesuatu jadi lebih mudah.
00:04:56Cukup dekatkan saja.
00:04:57Instal paket, buat dengan AI, salin solusi dari Stack Overflow.
00:05:03Sudah menjadi sifat manusia untuk mengambil jalan yang mudah.
00:05:06Kita memang sudah terbiasa begitu.
00:05:07Seperti yang saya katakan, menyalin sesuatu dari Stack Overflow itu sangat praktis.
00:05:10Kerangka kerja (framework) yang menangani semuanya dengan cara ajaib, tinggal instal dan pakai.
00:05:14Tapi mudah bukan berarti sederhana.
00:05:15Mudah berarti Anda bisa menambah sesuatu ke sistem Anda dengan cepat.
00:05:18Sederhana berarti Anda bisa memahami pekerjaan yang telah Anda lakukan.
00:05:20Setiap kali kita memilih kemudahan, kita memilih kecepatan sekarang demi kompleksitas nanti.
00:05:24Dan sejujurnya, pertukaran itu dulunya memang berhasil.
00:05:27Kompleksitas yang menumpuk di basis kode kita berjalan cukup lambat sehingga
00:05:31kita masih bisa melakukan refaktor, berpikir ulang, dan membangun kembali saat dibutuhkan.
00:05:34Saya rasa AI telah menghancurkan keseimbangan itu.
00:05:36Karena AI adalah tombol "mudah" yang mutakhir.
00:05:37Ia membuat jalan pintas yang mudah menjadi begitu
00:05:38mulus sehingga kita bahkan tidak lagi mempertimbangkan jalan yang sederhana.
00:05:41Mengapa harus memikirkan arsitektur jika kode bisa muncul seketika?
00:05:44Mari saya tunjukkan bagaimana hal ini terjadi.
00:05:47Bagaimana tugas sederhana berkembang menjadi kekacauan kompleksitas
00:05:50melalui antarmuka percakapan yang kita semua sukai.
00:05:52Ini adalah contoh sederhana, katakanlah kita punya aplikasi,
00:05:55kita ingin menambahkan beberapa autentikasi ke dalamnya.
00:05:57Tinggal bilang tambahkan auth, maka kita mendapatkan file auth.js yang bersih.
00:06:01Setelah beberapa kali iterasi, sampai pada pesan kelima.
00:06:02Lalu Anda berpikir, oke, keren, sekarang kita akan menambahkan OAuth juga,
00:06:04karena sekarang kita sudah punya auth.js dan OAuth.js.
00:06:07Kita terus beriterasi, lalu kita temukan bahwa sesinya rusak.
00:06:11Dan kita menghadapi banyak konflik.
00:06:12Pada saat kita mencapai giliran ke-20, Anda tidak benar-benar sedang berdiskusi lagi.
00:06:15Anda sedang mengelola konteks yang menjadi begitu kompleks sampai Anda sendiri pun tidak ingat
00:06:18semua batasan yang telah Anda tambahkan ke dalamnya.
00:06:20Ada kode mati dari pendekatan-pendekatan yang ditinggalkan.
00:06:22Pengujian yang diperbaiki hanya agar kodenya bisa berjalan.
00:06:25Potongan-potongan dari tiga solusi berbeda karena akhirnya Anda berkata, "Tunggu dulu."
00:06:28Setiap instruksi baru menimpa pola arsitektur yang sudah ada.
00:06:31Kita bilang buat auth-nya jalan di sini, dan ia melakukannya.
00:06:33Saat kita bilang perbaiki eror ini, ia pun melakukannya.
00:06:35Tidak ada hambatan bagi keputusan arsitektur yang buruk.
00:06:38Kode itu berubah bentuk hanya untuk memenuhi permintaan terbaru Anda.
00:06:40Setiap interaksi lebih memilih kemudahan daripada kesederhanaan.
00:06:43Dan kemudahan selalu berarti menambah kompleksitas.
00:06:46Kita tahu hal itu salah, tapi ketika jalan pintasnya semudah ini, kita tetap mengambilnya.
00:06:50Dan kompleksitas ini akan terus menumpuk sampai semuanya terlambat.
00:06:52AI benar-benar membawa konsep kemudahan ini ke titik ekstrem.
00:06:58Tentukan apa yang Anda inginkan, dapatkan kodenya secara instan.
00:07:00Tapi inilah bahayanya.
00:07:02Kode yang dihasilkan memperlakukan setiap pola dalam basis kode Anda sama saja.
00:07:06Saat sebuah agen menganalisis basis kode Anda, setiap baris menjadi pola yang harus dipertahankan.
00:07:10Pengecekan autentikasi di baris 47, itu sebuah pola.
00:07:13Kode gRPC aneh yang bertingkah seperti GraphQL yang mungkin saya tambahkan pada tahun 2019,
00:07:18itu juga dianggap sebagai sebuah pola.
00:07:19Utang teknis (technical debt) tidak dianggap sebagai utang, melainkan hanya sekadar kode biasa.
00:07:22Masalah sebenarnya di sini adalah kompleksitas.
00:07:25Saya tahu saya sudah sering mengucapkan kata itu dalam pembicaraan ini tanpa benar-benar mendefinisikannya.
00:07:29Tapi cara terbaik untuk memahaminya adalah: kompleksitas adalah lawan dari kesederhanaan.
00:07:31Itu berarti segala sesuatunya saling membelit.
00:07:33Dan ketika segala sesuatunya kompleks, segalanya menyentuh satu sama lain.
00:07:36Anda tidak bisa mengubah satu hal tanpa memengaruhi sepuluh hal lainnya.
00:07:41Kembali ke makalah "No Silver Bullet" karya Fred Brooks.
00:07:43Di dalamnya, ia mengidentifikasi dua jenis utama kompleksitas dalam setiap sistem.
00:07:47Ada kompleksitas esensial, yang merupakan kesulitan mendasar
00:07:51dari masalah sebenarnya yang ingin Anda pecahkan.
00:07:53Pengguna perlu membayar, pesanan harus dipenuhi.
00:07:56Ini adalah alasan mengapa sistem perangkat lunak Anda ada sejak awal.
00:08:00Dan kedua, ada ide tentang kompleksitas aksidental.
00:08:03Segala hal lain yang kita tambahkan di sepanjang jalan, seperti solusi sementara, kode defensif,
00:08:06kerangka kerja, atau abstraksi yang dulunya terasa masuk akal.
00:08:09Itu semua adalah hal yang kita susun agar kode itu sendiri bisa berjalan.
00:08:11Dalam basis kode yang nyata, kedua jenis kompleksitas ini ada di mana-mana.
00:08:16Dan mereka menjadi sangat kusut sehingga untuk memisahkannya dibutuhkan konteks,
00:08:19sejarah, dan pengalaman.
00:08:20Hasil keluaran yang dihasilkan AI tidak membuat pembedaan seperti itu.
00:08:24Sehingga setiap pola terus dipertahankan.
00:08:26Berikut adalah contoh nyata dari beberapa pekerjaan yang kami lakukan di Netflix.
00:08:32Saya memiliki sistem yang memiliki lapisan abstraksi yang berada di antara
00:08:35kode otorisasi lama yang kami tulis, katakanlah sekitar lima tahun lalu, dengan sistem auth terpusat yang baru.
00:08:41Kami tidak punya waktu untuk membangun kembali seluruh aplikasi kami, jadi
00:08:42kami hanya memasang semacam perantara (shim) di antaranya.
00:08:44Nah, sekarang karena kita punya AI, ini adalah kesempatan bagus untuk merefaktorisasi kode kita agar menggunakan
00:08:47sistem baru secara langsung, sepertinya permintaan yang sederhana, bukan?
00:08:50Ternyata tidak, kode lama itu sangat terikat erat dengan pola otorisasi
00:08:56lama, seperti pemeriksaan izin yang terjalin dalam logika bisnis,
00:08:59asumsi peran yang tertanam dalam model data, dan panggilan autentikasi yang tersebar di ratusan
00:09:03file; agen AI mulai merefaktorisasi beberapa file, tapi kemudian
00:09:07menemui dependensi yang tidak bisa diurainya, sehingga menjadi tak terkendali dan gagal.
00:09:10Atau lebih buruk lagi, ia mencoba mempertahankan logika yang ada dari sistem lama dan
00:09:16membuatnya ulang menggunakan sistem baru, yang menurut saya juga tidak bagus.
00:09:19Masalahnya adalah, AI tidak bisa melihat celah pemisahnya.
00:09:23Ia tidak bisa mengidentifikasi di mana logika bisnis berakhir dan di mana logika autentikasi dimulai.
00:09:26Segalanya begitu kusut sehingga meskipun dengan informasi yang sempurna pun,
00:09:30AI tidak bisa menemukan jalan keluar yang bersih.
00:09:33Saat kompleksitas aksidental Anda sudah sekusut ini,
00:09:35AI bukanlah bantuan terbaik untuk memperbaikinya.
00:09:38Saya menemukan bahwa AI justru hanya menambah lebih banyak lapisan di atasnya.
00:09:40Kita bisa membedakannya, atau setidaknya kita bisa melakukannya jika kita melambat sejenak untuk berpikir.
00:09:45Kita tahu mana pola yang esensial dan
00:09:47mana yang hanya sekadar cara seseorang menyelesaikannya beberapa tahun lalu.
00:09:50Kita membawa konteks yang tidak bisa disimpulkan oleh AI, tetapi
00:09:53hanya jika kita meluangkan waktu untuk membuat perbedaan ini sebelum kita mulai.
00:09:56Jadi bagaimana Anda benar-benar melakukannya?
00:10:01Bagaimana Anda memisahkan kompleksitas aksidental dan esensial,
00:10:04saat Anda sedang menatap basis kode yang sangat besar?
00:10:07Basis kode tempat saya bekerja di Netflix memiliki sekitar satu juta baris Java, dan
00:10:10layanan utamanya memiliki sekitar lima juta token terakhir kali saya periksa.
00:10:13Tidak ada jendela konteks yang saya miliki yang bisa menampungnya.
00:10:17Jadi ketika saya ingin mengerjakannya, awalnya saya berpikir,
00:10:19mungkin saya bisa menyalin sebagian besar basis kode ini ke dalam konteks dan
00:10:23melihat apakah polanya akan muncul,
00:10:24melihat apakah ia bisa mencari tahu apa yang sedang terjadi.
00:10:26Dan sama seperti refaktorisasi otorisasi sebelumnya,
00:10:29hasilnya justru terjebak dalam kompleksitasnya sendiri.
00:10:31Karena itulah, saya terpaksa mencoba metode lain.
00:10:34Saya harus memilih apa saja yang perlu disertakan: dokumen desain, arsitektur, diagram, apa pun itu.
00:10:37Antarmuka utama, semuanya.
00:10:39Lalu meluangkan waktu menuliskan persyaratan interaksi antar komponen
00:10:42dan pola apa yang harus diikuti.
00:10:43Intinya, saya sedang menyusun spesifikasi.
00:10:45Lima juta token tadi diringkas menjadi spesifikasi 2.000 kata.
00:10:49Langkah selanjutnya bahkan lebih jauh, yaitu menggunakan spesifikasi tersebut
00:10:52untuk membuat rangkaian langkah eksekusi kode yang pasti.
00:10:55Tanpa instruksi yang samar, hanya urutan operasi yang presisi.
00:10:58Saya rasa cara ini menghasilkan kode yang jauh lebih bersih, terfokus, dan mudah dipahami.
00:11:02Jadi, saya mendefinisikannya dulu, lalu merencanakan eksekusinya sendiri.
00:11:05Inilah pendekatan yang sempat saya sebut sebagai kompresi konteks beberapa waktu lalu.
00:11:11Tapi Anda bisa menyebutnya rekayasa konteks, spektrum dalam pengembangan,
00:11:13terserah apa pun sebutannya.
00:11:15Nama itu tidaklah penting.
00:11:16Yang terpenting adalah proses berpikir dan perencanaan menjadi porsi utama pekerjaan.
00:11:20Mari saya tunjukkan bagaimana praktiknya di lapangan.
00:11:22Langkah pertama, fase satu: riset.
00:11:26Saya memasukkan semuanya di awal.
00:11:28Diagram arsitektur, dokumentasi, percakapan Slack.
00:11:31Kita sudah sering membahas soal ini.
00:11:32Tapi intinya, berikan konteks sebanyak mungkin yang relevan
00:11:35dengan perubahan yang akan Anda lakukan.
00:11:36Lalu gunakan AI untuk menganalisis basis kode
00:11:39serta memetakan komponen dan dependensinya.
00:11:42Ini seharusnya bukan proses sekali jadi.
00:11:43Saya suka menguji, misalnya dengan bertanya, "Bagaimana dengan caching-nya?"
00:11:46"Bagaimana sistem menangani kegagalan?"
00:11:47Jika analisisnya salah, saya akan mengoreksinya.
00:11:49Jika ada konteks yang kurang, saya akan menambahkannya.
00:11:51Setiap iterasi akan mempertajam hasil analisisnya.
00:11:55Hasil akhirnya adalah satu dokumen riset tunggal.
00:11:57Isinya: apa yang ada saat ini, apa yang terhubung ke mana,
00:11:59dan bagian mana saja yang akan terdampak oleh perubahan Anda.
00:12:01Eksplorasi berjam-jam diringkas menjadi bacaan beberapa menit saja.
00:12:03Meski Dex sudah menyebutnya tadi pagi, titik pemeriksaan manusia di sini sangatlah krusial.
00:12:09Di sinilah Anda memvalidasi analisis terhadap realitas,
00:12:12momen paling menentukan dalam seluruh proses ini.
00:12:15Temukan kesalahan di sini untuk mencegah bencana nantinya.
00:12:17Lanjut ke fase kedua.
00:12:20Setelah Anda memegang hasil riset yang valid,
00:12:22kita buat rencana implementasi mendetail: struktur kode nyata,
00:12:25signature fungsi, definisi tipe data, dan aliran data.
00:12:28Rencana ini harus bisa diikuti oleh pengembang mana pun.
00:12:30Saya mengibaratkannya seperti mewarnai berdasarkan angka.
00:12:32Anda harus bisa memberikannya kepada teknisi paling junior dan berkata, "Kerjakan ini."
00:12:35Dan jika mereka menyalinnya baris demi baris, kodenya harus langsung berjalan.
00:12:38Langkah ini adalah saat kita mengambil banyak keputusan arsitektural yang penting.
00:12:43Memastikan logika yang rumit sudah benar.
00:12:45Memastikan persyaratan bisnis mengikuti praktik yang baik.
00:12:50Memastikan batasan layanan tepat, pemisahan yang bersih,
00:12:52dan mencegah keterkaitan antar komponen yang tidak perlu.
00:12:54Kita mendeteksi masalah sebelum terjadi karena kita pernah mengalaminya.
00:12:57AI tidak punya pengalaman itu.
00:12:59AI menganggap setiap pola sebagai sebuah keharusan.
00:13:01Keunggulan utama dalam langkah ini adalah kecepatan peninjauan.
00:13:05Kita bisa memvalidasi rencana ini dalam hitungan menit dan tahu persis apa yang akan dibangun.
00:13:10Untuk mengimbangi kecepatan pembuatan kode yang kita inginkan,
00:13:13kita harus mampu memahaminya dengan kecepatan yang sama.
00:13:18Terakhir, fase implementasi. Kini setelah kita punya rencana jelas
00:13:22berdasarkan riset yang kuat, fase ini seharusnya cukup sederhana.
00:13:26Dan itulah poin utamanya.
00:13:28Saat AI memiliki spesifikasi yang jelas, konteksnya tetap bersih dan terfokus.
00:13:31Kita pun terhindar dari tumpukan kompleksitas akibat percakapan yang panjang.
00:13:32Alih-alih 50 pesan berisi kode yang terus berubah,
00:13:36kita hanya punya tiga output terfokus, yang masing-masing sudah divalidasi.
00:13:38Tidak ada pendekatan yang ditinggalkan, tidak ada pola yang bentrok,
00:13:41atau momen "tunggu, sebenarnya begini" yang menyisakan kode sampah di mana-mana.
00:13:44Bagi saya, keuntungan nyata dari cara ini adalah Anda bisa menggunakan AI di latar belakang
00:13:48untuk melakukan banyak pekerjaan, karena Anda sudah melakukan semua proses berpikirnya di awal.
00:13:52AI bisa memulai implementasi, sementara Anda mengerjakan hal lain,
00:13:56lalu kembali untuk memeriksanya.
00:13:59Dan peninjauan ini cepat karena Anda hanya memverifikasi apakah kodenya sesuai rencana,
00:14:01bukan mencoba memahami apakah ada hal baru yang dikarang oleh AI.
00:14:04Intinya, kita tidak menggunakan AI untuk berpikir menggantikan kita.
00:14:07Kita menggunakannya untuk mempercepat bagian mekanis
00:14:12sambil tetap mempertahankan kemampuan kita untuk memahaminya.
00:14:15Riset jadi lebih cepat, perencanaan lebih matang, dan implementasi lebih bersih.
00:14:17Namun proses berpikir, sintesis, dan pengambilan keputusan tetap ada di tangan kita.
00:14:21Ingat soal refaktor otorisasi yang saya bilang tidak bisa ditangani AI?
00:14:26Sekarang kami sedang mengerjakannya
00:14:34dan mulai menunjukkan kemajuan yang bagus.
00:14:37Hal ini terjadi bukan karena kami menemukan perintah prompt yang lebih baik.
00:14:39Kami sadar bahwa kami bahkan tidak bisa langsung melakukan riset, perencanaan, dan implementasi.
00:14:42Kami terpaksa melakukan perubahan itu secara manual.
00:14:45Tanpa AI, hanya membaca kode, memahami dependensi,
00:14:46dan mencoba mengubahnya untuk melihat bagian mana yang rusak.
00:14:49Migrasi manual itu sejujurnya sangat melelahkan, tapi sangat krusial.
00:14:52Proses itu mengungkap semua kendala tersembunyi, aturan yang harus tetap berlaku,
00:14:53dan layanan mana yang akan rusak jika otorisasi diubah.
00:14:59Hal-hal yang tidak akan muncul meski dilakukan analisis kode sedalam apa pun.
00:15:02Lalu kami masukkan pull request dari migrasi manual tersebut ke dalam proses riset kami
00:15:05dan menjadikannya sebagai landasan untuk riset selanjutnya.
00:15:09Dengan begitu, AI bisa melihat seperti apa migrasi yang bersih itu.
00:15:14Masalahnya, setiap entitas ini sedikit berbeda, jadi kami harus terus memeriksanya dan bertanya,
00:15:19"Apa yang harus kita lakukan untuk bagian ini?"
00:15:23Beberapa data dienkripsi, beberapa tidak.
00:15:27Kami harus memberikan konteks tambahan itu berkali-kali melalui banyak iterasi.
00:15:29Setelah itu, barulah kami bisa membuat rencana yang mungkin berhasil dalam sekali coba.
00:15:32Dan kata kuncinya adalah "mungkin", karena kami masih terus memvalidasi,
00:15:35menyesuaikan, dan menemukan kasus-kasus khusus.
00:15:41Pendekatan tiga fase ini bukanlah sihir.
00:15:45Ini berhasil hanya karena kami melakukan satu migrasi secara manual.
00:15:47Kami harus benar-benar paham sebelum menuangkannya ke dalam proses kami.
00:15:55Saya tetap percaya tidak ada solusi instan.
00:15:57Bukan soal prompt yang lebih baik, model yang lebih hebat, atau spesifikasi yang lebih detail.
00:16:01Kuncinya adalah memahami sistem Anda cukup dalam sehingga Anda bisa mengubahnya dengan aman.
00:16:02Lalu, mengapa harus melakukan semua kerumitan ini?
00:16:06Kenapa tidak terus mencoba dengan AI sampai berhasil?
00:16:09Bukankah lama-lama modelnya akan cukup kuat dan semuanya beres?
00:16:11Bagi saya, sekadar "berhasil" itu tidak cukup.
00:16:15Ada perbedaan antara kode yang sekadar lulus pengujian dengan kode yang bertahan di tahap produksi.
00:16:18Antara sistem yang berfungsi hari ini dengan
00:16:21sistem yang masih bisa diubah oleh orang lain di masa depan.
00:16:24Masalah sebenarnya adalah kesenjangan pengetahuan.
00:16:27Saat AI bisa menghasilkan ribuan baris kode dalam hitungan detik,
00:16:28memahaminya bisa memakan waktu berjam-jam, bahkan berhari-hari jika rumit.
00:16:31Bahkan mungkin tidak akan pernah terpahami jika kodenya terlalu berantakan.
00:16:34Ini adalah poin yang menurut saya jarang dibicarakan orang saat ini.
00:16:38Setiap kali kita melewatkan proses berpikir demi mengejar kecepatan pembuatan kode,
00:16:41kita tidak hanya menambah kode yang tidak kita mengerti.
00:16:45Kita juga kehilangan kemampuan untuk mengenali masalah.
00:16:48Insting yang memperingatkan, "Hei, ini mulai rumit," akan tumpul
00:16:52saat Anda tidak memahami sistem Anda sendiri.
00:16:56Kemampuan mengenali pola datang dari pengalaman.
00:16:58Saat saya melihat arsitektur yang berbahaya,
00:17:00itu karena saya pernah terjaga jam tiga pagi untuk menanganinya.
00:17:03Saat saya mendorong solusi yang lebih sederhana,
00:17:09itu karena saya pernah harus memelihara kode alternatif buatan orang lain.
00:17:11AI menghasilkan apa yang Anda minta.
00:17:12AI tidak membawa pelajaran dari kegagalan masa lalu.
00:17:16Pendekatan tiga fase ini menjembatani celah tersebut.
00:17:17Cara ini meringkas pemahaman menjadi artefak yang bisa kita tinjau secepat kecepatan AI.
00:17:21Tanpanya, kita hanya menumpuk kompleksitas lebih cepat daripada yang bisa kita pahami.
00:17:23AI mengubah segalanya tentang cara kita menulis kode, tapi sejujurnya,
00:17:25saya rasa AI tidak mengubah alasan mengapa perangkat lunak bisa gagal.
00:17:29Setiap generasi menghadapi krisis perangkat lunaknya sendiri.
00:17:33Generasi Dijkstra menghadapinya dengan menciptakan disiplin rekayasa perangkat lunak,
00:17:37dan sekarang kita menghadapinya dengan pembuatan kode yang tak terbatas.
00:17:39Saya rasa solusinya bukanlah alat atau metodologi baru.
00:17:44Tapi mengingat apa yang sudah lama kita ketahui: bahwa perangkat lunak adalah upaya manusia.
00:17:47Bagian tersulit bukanlah mengetik kodenya.
00:17:50Tapi mengetahui apa yang harus diketik sejak awal.
00:17:54Pengembang yang akan sukses bukanlah mereka yang menghasilkan kode paling banyak.
00:17:56Melainkan mereka yang memahami apa yang mereka bangun,
00:18:01yang masih bisa melihat celahnya, dan yang sadar saat mereka menyelesaikan masalah yang salah.
00:18:05Itulah peran kita.
00:18:06Hanya kita yang bisa melakukannya.
00:18:09Saya ingin menutup dengan sebuah pertanyaan, dan menurut saya pertanyaannya bukan
00:18:13apakah kita akan menggunakan AI atau tidak.
00:18:15Itu sudah pasti terjadi.
00:18:18Keputusannya sudah bulat.
00:18:19Bagi saya, pertanyaannya adalah apakah kita masih akan memahami sistem kita sendiri
00:18:20saat AI menulis sebagian besar kode kita.
00:18:21Terima kasih.
00:18:25>> [TEPUK TANGAN]
00:18:26[MUSIK]
00:18:28Le navire a déjà levé l'ancre.
00:18:30Pour moi, la question sera de savoir si nous comprendrons encore nos propres systèmes
00:18:33lorsque l'IA écrira la majeure partie de notre code.
00:18:35Merci.
00:18:37>> [APPLAUDISSEMENTS]
00:18:39[MUSIQUE]