00:00:00(musik ceria)
00:00:02- Halo semuanya, apa kabar?
00:00:23Menyenangkan sekali, saya Dex.
00:00:25Seperti yang disebutkan di pengantar tadi,
00:00:27saya sudah cukup lama berkutat dengan agen AI.
00:00:29Presentasi kami, "12-Factor Agents", di AI Engineer bulan Juni
00:00:32adalah salah satu presentasi terpopuler sepanjang masa.
00:00:34Sepertinya masuk delapan besar atau semacamnya,
00:00:35salah satu yang terbaik dari AI Engineer bulan Juni.
00:00:38Mungkin saya sempat menyinggung soal rekayasa konteks.
00:00:41Mengapa saya di sini hari ini, apa yang ingin saya bicarakan?
00:00:44Saya ingin membahas salah satu presentasi favorit saya
00:00:46dari AI Engineer bulan Juni,
00:00:47dan saya tahu kita semua mendapat pembaruan dari Igor kemarin,
00:00:49tapi mereka tidak mengizinkan saya mengubah slide,
00:00:50jadi ini akan membahas apa yang Igor sampaikan di bulan Juni.
00:00:54Intinya, mereka mensurvei 100.000 pengembang
00:00:56di berbagai skala perusahaan,
00:00:58dan menemukan bahwa sering kali
00:01:00saat Anda menggunakan AI untuk rekayasa perangkat lunak,
00:01:01Anda melakukan banyak pengerjaan ulang dan perombakan kode.
00:01:04Dan itu tidak berjalan baik untuk tugas-tugas kompleks,
00:01:07atau pada basis kode lama (brownfield).
00:01:08Anda bisa lihat di grafik, pada dasarnya,
00:01:10Anda merilis jauh lebih banyak kode,
00:01:11tapi banyak di antaranya hanya memperbaiki kekacauan
00:01:14yang Anda rilis minggu lalu.
00:01:15Lalu di sisi lain, jika Anda
00:01:18membuat proyek baru (greenfield), seperti dasbor Vercel kecil,
00:01:21hal seperti itu akan berfungsi dengan sangat baik.
00:01:25Tapi jika Anda masuk ke basis kode Java berusia 10 tahun,
00:01:28mungkin hasilnya tidak akan sebagus itu.
00:01:29Dan ini sesuai dengan pengalaman saya.
00:01:30Secara pribadi, dan dari mengobrol dengan banyak pendiri
00:01:32serta insinyur hebat, terlalu banyak kekacauan,
00:01:35seperti pabrik utang teknis, itu tidak akan berhasil di basis kode kami.
00:01:37Mungkin suatu saat nanti, saat modelnya sudah lebih baik.
00:01:40Tapi itulah inti dari rekayasa konteks.
00:01:42Bagaimana kita bisa memaksimalkan model yang ada saat ini?
00:01:44Bagaimana kita mengelola jendela konteks kita?
00:01:46Kami membicarakan hal ini pada bulan Agustus.
00:01:48Saya harus mengakui sesuatu.
00:01:49Pertama kali saya menggunakan Claude Code, saya tidak terkesan.
00:01:53Rasanya seperti, oke, ini sedikit lebih baik,
00:01:54saya mengerti, saya suka UX-nya.
00:01:56Namun sejak saat itu, tim kami menemukan sesuatu
00:01:59sehingga kami benar-benar mampu mencapai
00:02:01throughput dua hingga tiga kali lipat lebih banyak.
00:02:02Dan kami merilis begitu banyak hal sehingga kami tidak punya pilihan
00:02:06selain mengubah cara kami berkolaborasi.
00:02:07Kami merombak total cara kami membangun perangkat lunak.
00:02:11Hanya tim berisi tiga orang, butuh delapan minggu, dan itu sangat sulit.
00:02:12Benar-benar perjuangan yang luar biasa.
00:02:14Tapi sekarang setelah kami menyelesaikannya, kami tidak akan kembali ke cara lama.
00:02:16Inilah masalah "tanpa kekacauan" itu.
00:02:18Saya rasa kami berhasil mencapai sesuatu di sini.
00:02:20Hal ini menjadi sangat viral di Hacker News pada bulan September.
00:02:23Ada ribuan orang yang telah mengunjungi GitHub
00:02:25dan mengambil sistem prompt "research-plan-implement" kami.
00:02:28Jadi tujuannya di sini, yang secara tidak langsung kami temukan,
00:02:31adalah kita butuh AI yang bisa bekerja baik di basis kode lama.
00:02:35Yang bisa menyelesaikan masalah kompleks.
00:02:38Tanpa kekacauan, ya, tidak ada lagi kode asal-asalan.
00:02:40Dan kita harus menjaga keselarasan pemikiran.
00:02:42Saya akan jelaskan lebih lanjut
00:02:43tentang apa artinya itu sebentar lagi.
00:02:44Dan tentu saja, seperti segalanya,
00:02:46kita ingin menggunakan token sebanyak mungkin.
00:02:47Apa yang bisa kita delegasikan secara bermakna ke AI
00:02:50itu sangat, sangat penting.
00:02:52Daya ungkitnya sangat tinggi.
00:02:53Jadi ini adalah rekayasa konteks tingkat lanjut untuk agen pengodean.
00:02:56Saya akan mulai dengan memberikan kerangka pemikiran.
00:02:58Cara paling naif untuk menggunakan agen pengodean
00:03:01adalah meminta sesuatu lalu memberitahunya mengapa itu salah,
00:03:03mengarahkan ulang, dan bertanya terus-menerus
00:03:05sampai Anda kehabisan konteks, menyerah, atau menangis.
00:03:09Kita bisa sedikit lebih cerdas dari itu.
00:03:11Kebanyakan orang menyadari hal ini cukup awal
00:03:13dalam eksplorasi AI mereka: mungkin lebih baik
00:03:17jika Anda memulai percakapan dan arahnya sudah melenceng,
00:03:21Anda cukup membuka jendela konteks baru.
00:03:24Anda katakan, oke, kita tadi lewat jalur itu.
00:03:25Mari kita mulai lagi.
00:03:26Prompt yang sama, tugas yang sama.
00:03:27Tapi kali ini, kita akan lewat jalur ini.
00:03:29Dan jangan ke sana karena itu tidak berhasil.
00:03:31Lalu bagaimana Anda tahu kapan waktunya untuk memulai ulang?
00:03:34Jika Anda melihat ini,
00:03:37(hadirin tertawa)
00:03:39mungkin sudah waktunya untuk memulai ulang, bukan?
00:03:41Inilah yang dikatakan Claude saat Anda memberitahunya bahwa ia melakukan kesalahan.
00:03:45Jadi kita bisa lebih cerdas lagi.
00:03:47Kita bisa melakukan apa yang saya sebut "pemadatan sengaja" (intentional compaction).
00:03:50Pada dasarnya, entah Anda di jalur yang benar atau tidak,
00:03:53Anda bisa mengambil jendela konteks yang ada
00:03:56dan meminta agen tersebut memadatkannya ke dalam file markdown.
00:03:59Anda bisa meninjaunya, Anda bisa menandainya.
00:04:00Dan kemudian saat agen baru dimulai,
00:04:02ia bisa langsung bekerja alih-alih harus melakukan
00:04:04semua pencarian dan pemahaman basis kode
00:04:05serta mengejar ketertinggalan.
00:04:07Apa saja yang masuk ke dalam pemadatan?
00:04:09Pertanyaannya adalah, hal apa yang menghabiskan ruang
00:04:11di jendela konteks Anda?
00:04:13Yaitu mencari file, memahami alur kode,
00:04:17mengedit file, serta hasil pengujian dan build.
00:04:20Dan jika Anda memiliki MCP yang membuang JSON
00:04:22dan sekumpulan UUID ke dalam jendela konteks Anda,
00:04:25tamatlah riwayat Anda.
00:04:26Jadi apa yang harus kita padatkan?
00:04:28Saya akan jelaskan lebih spesifik di sini,
00:04:30tapi ini adalah contoh pemadatan yang sangat bagus.
00:04:31Inilah tepatnya yang sedang kita kerjakan,
00:04:33file dan nomor baris yang tepat
00:04:34yang penting bagi masalah yang sedang kita selesaikan.
00:04:37Mengapa kita begitu terobsesi dengan konteks?
00:04:39Karena LLM pernah dikritik habis-habisan di YouTube soal ini.
00:04:42Mereka bukan fungsi murni karena bersifat nondeterministik,
00:04:45tetapi mereka tidak memiliki status (stateless).
00:04:46Dan satu-satunya cara mendapatkan performa lebih baik dari LLM
00:04:49adalah dengan memasukkan token yang lebih baik
00:04:51dan Anda akan mendapatkan token keluaran yang lebih baik pula.
00:04:52Jadi di setiap putaran perulangan,
00:04:53saat Claude memilih alat berikutnya
00:04:55atau agen pengodean mana pun memilih alat berikutnya,
00:04:56mungkin ada ratusan langkah selanjutnya yang benar
00:04:58dan ratusan langkah selanjutnya yang salah.
00:05:00Tetapi satu-satunya hal yang memengaruhi apa yang keluar selanjutnya
00:05:03adalah apa yang ada dalam percakapan sejauh ini.
00:05:05Jadi kita akan mengoptimalkan jendela konteks ini
00:05:07untuk keakuratan, kelengkapan, ukuran,
00:05:10dan sedikit tentang arah lintasan (trajectory).
00:05:11Dan bagian lintasan ini menarik
00:05:12karena banyak orang berkata,
00:05:13"Saya menyuruh agen melakukan sesuatu
00:05:16dan dia melakukannya dengan salah."
00:05:17"Jadi saya memperbaikinya dan memarahinya,
00:05:18lalu dia melakukan kesalahan lagi."
00:05:20"Lalu saya memarahinya lagi."
00:05:21Dan kemudian LLM melihat percakapan ini,
00:05:23dan berpikir, oke, keren, saya melakukan kesalahan
00:05:24lalu manusia itu memarahi saya,
00:05:25saya salah lagi dan dia memarahi saya lagi.
00:05:26Jadi token yang paling mungkin muncul dalam percakapan ini
00:05:29adalah lebih baik saya melakukan kesalahan
00:05:31agar manusia itu bisa memarahi saya lagi.
00:05:33Jadi berhati-hatilah dengan arah lintasan percakapan Anda.
00:05:35Jika kita membalik logikanya,
00:05:36hal terburuk yang bisa Anda miliki adalah informasi yang salah,
00:05:39lalu informasi yang hilang, dan kemudian terlalu banyak gangguan.
00:05:42Jika Anda suka persamaan, ada satu persamaan sederhana
00:05:44jika Anda ingin memikirkannya seperti ini.
00:05:47Jeff Huntley melakukan banyak penelitian tentang agen pengodean.
00:05:51Dia menjelaskannya dengan sangat baik.
00:05:51Semakin banyak Anda menggunakan jendela konteks,
00:05:53semakin buruk hasil yang akan Anda dapatkan.
00:05:55Ini mengarah pada sebuah konsep.
00:05:56Konsep yang sangat, sangat akademis yang disebut "zona bodoh" (dumb zone).
00:05:59Jadi Anda punya jendela konteks Anda.
00:06:01Anda punya sekitar 168.000 token.
00:06:03Beberapa dicadangkan untuk keluaran dan pemadatan.
00:06:05Ini bervariasi tergantung modelnya,
00:06:07tapi kita gunakan Claude Code sebagai contoh di sini.
00:06:09Di sekitar garis 40% adalah tempat Anda akan mulai
00:06:10melihat adanya penurunan hasil tergantung pada tugas Anda.
00:06:14Jika Anda memiliki terlalu banyak MCP di agen pengodean Anda,
00:06:17Anda melakukan semua pekerjaan Anda di zona bodoh
00:06:18dan Anda tidak akan pernah mendapatkan hasil yang baik.
00:06:21Orang-orang sudah membicarakan hal ini.
00:06:21Saya tidak akan membahas yang satu itu.
00:06:22Hasilnya mungkin berbeda-beda bagi tiap orang.
00:06:23Garis 40% itu tergantung seberapa rumit tugasnya,
00:06:26tapi ini merupakan panduan yang cukup bagus.
00:06:28Jadi kembali ke pemadatan, atau yang mulai sekarang akan saya sebut
00:06:31dengan istilah cerdik: menghindari zona bodoh.
00:06:33Kita bisa menggunakan sub-agen.
00:06:37Jika Anda punya sub-agen front-end, sub-agen back-end,
00:06:39sub-agen QA, dan sub-agen ilmuwan data, tolong hentikan.
00:06:44Sub-agen bukan untuk mempersonifikasi peran manusia.
00:06:47Tujuan mereka adalah untuk mengendalikan konteks.
00:06:49Dan yang bisa Anda lakukan adalah, jika Anda ingin mencari tahu
00:06:51cara kerja sesuatu dalam basis kode yang besar,
00:06:53Anda bisa mengarahkan agen pengodean untuk melakukan ini
00:06:55jika agen tersebut mendukung sub-agen,
00:06:56atau Anda bisa membangun sistem sub-agen Anda sendiri,
00:06:58tapi intinya Anda berkata, "Hei, cari tahu bagaimana ini bekerja."
00:07:00Dan ia bisa mencabangkan jendela konteks baru
00:07:03yang akan melakukan semua pembacaan, pencarian,
00:07:05penemuan, dan pembacaan seluruh file
00:07:07serta memahami basis kode tersebut,
00:07:09lalu hanya mengirimkan kembali pesan yang sangat, sangat ringkas
00:07:13ke agen induknya, seperti,
00:07:14"Hei, file yang kamu cari ada di sini."
00:07:17Agen induk bisa membaca file tunggal itu dan langsung bekerja.
00:07:20Dan ini sangat ampuh.
00:07:22Jika Anda menggunakannya dengan benar,
00:07:23Anda bisa mendapatkan respons yang bagus seperti ini,
00:07:25dan kemudian Anda bisa mengelola konteks Anda dengan sangat baik.
00:07:29Yang bekerja lebih baik daripada sub-agen
00:07:30atau sebuah lapisan di atas sub-agen
00:07:32adalah alur kerja yang saya sebut pemadatan intensional yang sering.
00:07:35Kita akan membahas riset, rencana, implementasi sebentar lagi,
00:07:37tapi intinya adalah Anda terus-menerus
00:07:39menjaga agar jendela konteks Anda tetap kecil.
00:07:41Anda membangun seluruh alur kerja di sekitar manajemen konteks
00:07:45jadi ini hadir dalam tiga fase: riset, rencana, implementasi,
00:07:48dan kita akan mencoba tetap berada di zona pintar sepanjang waktu.
00:07:51Riset adalah tentang memahami
00:07:53cara kerja sistem, menemukan berkas yang tepat,
00:07:55tetap objektif.
00:07:56Ini adalah perintah yang bisa Anda gunakan untuk melakukan riset.
00:07:58Ini adalah hasil dari perintah riset tersebut.
00:08:00Semuanya bersifat sumber terbuka.
00:08:01Anda bisa mengambil dan mencobanya sendiri.
00:08:04Perencanaan, Anda akan menguraikan langkah-langkah pastinya.
00:08:06Anda akan menyertakan nama berkas dan potongan baris kode.
00:08:08Anda harus sangat eksplisit tentang cara kita menguji berbagai hal
00:08:10setelah setiap perubahan.
00:08:11Ini adalah perintah perencanaan yang bagus.
00:08:12Ini adalah salah satu rencana kami.
00:08:13Di dalamnya terdapat potongan kode yang sebenarnya.
00:08:16Dan kemudian kita akan mengimplementasikannya.
00:08:17Dan jika Anda sudah membaca salah satu rencana ini,
00:08:17Anda bisa melihat betapa mudahnya model paling bodoh sekalipun
00:08:20mungkin tidak akan mengacaukan hal ini.
00:08:23Jadi kita langsung saja menjalankan rencananya
00:08:24dan menjaga konteks tetap rendah.
00:08:26Sebagai perintah perencanaan, seperti yang saya katakan,
00:08:27ini adalah bagian yang paling tidak menarik dari proses ini.
00:08:30Saya ingin mempraktikkan hal ini.
00:08:31Jadi yang kami lakukan, saya membuat podcast dengan teman saya Vaibhav
00:08:34yang merupakan CEO dari perusahaan bernama Boundary ML.
00:08:37Dan saya bilang, "Hei, saya akan mencoba memperbaiki sekaligus"
00:08:39"basis kode Rust Anda yang berisi 300.000 baris"
00:08:41"untuk sebuah bahasa pemrograman."
00:08:42Dan seluruh episodenya pun dimulai.
00:08:45Durasinya sekitar satu setengah jam.
00:08:46Saya tidak akan membahas semuanya sekarang,
00:08:47tapi kami membangun serangkaian riset
00:08:48lalu membuangnya karena hasilnya buruk.
00:08:49Lalu kami membuat rencana tanpa riset
00:08:51dan dengan riset, lalu membandingkan semua hasilnya.
00:08:53Itu saat-saat yang menyenangkan.
00:08:54Itu terjadi Senin malam.
00:08:55Selasa pagi, kami sedang berada di acara itu
00:08:57dan CTO-nya sudah melihat PR (Pull Request) tersebut
00:08:59dan tidak menyadari kalau saya melakukannya hanya untuk podcast.
00:09:03Dan pada dasarnya dia bilang, "Ya, ini terlihat bagus."
00:09:04"Kita akan memasukkannya di rilis berikutnya."
00:09:05Dia sedikit bingung.
00:09:08Ini rencananya.
00:09:09Tapi bagaimanapun, ya, terkonfirmasi.
00:09:12Ini berhasil di basis kode Brownfield dan tanpa kecacatan.
00:09:14Tapi saya ingin melihat apakah kita bisa memecahkan masalah kompleks.
00:09:17Vaibhav awalnya masih agak skeptis.
00:09:19Saya duduk, kami duduk selama sekitar tujuh jam di hari Sabtu
00:09:21dan kami mengirimkan 35.000 baris kode ke BAML.
00:09:24Salah satu PR-nya digabungkan sekitar seminggu kemudian.
00:09:26Harus saya akui sebagian dari ini adalah kode yang dihasilkan AI.
00:09:28Anda memperbarui perilakunya,
00:09:29semua berkas utama diperbarui dan sebagainya,
00:09:31tapi kami mengirimkan banyak kode hari itu.
00:09:33Dia memperkirakan itu setara satu hingga dua minggu kerja dalam tujuh jam.
00:09:36Dan itu keren, kita bisa memecahkan masalah kompleks.
00:09:40Ada batasan untuk hal ini.
00:09:41Saya duduk bersama teman saya, Blake.
00:09:42Kami mencoba menghapus dependensi Hadoop dari Parquet Java.
00:09:46Jika Anda tahu apa itu Parquet Java,
00:09:47saya turut prihatin atas apa pun yang menimpa Anda
00:09:50sampai Anda mencapai titik ini dalam karier Anda.
00:09:53Hasilnya tidak berjalan baik.
00:09:55Ini rencananya, ini risetnya.
00:09:57Pada titik tertentu, kami membuang semuanya
00:09:58dan kami benar-benar kembali ke papan tulis.
00:10:00Kami harus benar-benar melakukannya, setelah kami mempelajari
00:10:01di mana letak semua jebakannya,
00:10:03kami kembali ke, oke,
00:10:05bagaimana ini sebenarnya akan digabungkan?
00:10:06Dan ini membawa saya ke poin yang sangat menarik
00:10:09yang akan dibahas Jake nanti.
00:10:11Jangan menyerahkan proses berpikir ke pihak luar.
00:10:13AI tidak bisa menggantikan pemikiran.
00:10:14Ia hanya bisa memperkuat pemikiran yang telah Anda lakukan
00:10:17atau kurangnya pemikiran yang Anda lakukan.
00:10:19Jadi orang-orang bertanya, jadi Dex,
00:10:21ini adalah pengembangan berbasis spek, kan?
00:10:23Tidak, pengembangan berbasis spek itu gagal.
00:10:27Bukan idenya, tapi istilahnya.
00:10:30Istilah itu tidak terdefinisi dengan baik.
00:10:33Ini Brigetta dari ThoughtWorks.
00:10:35Dan banyak orang hanya mengatakan spek
00:10:37padahal maksud mereka adalah perintah yang lebih detail.
00:10:39Ada yang ingat gambar ini?
00:10:41Ada yang tahu ini dari mana?
00:10:43Baiklah, itu referensi yang cukup dalam.
00:10:44Tidak akan pernah ada tahunnya para agen
00:10:46karena adanya difusi semantik.
00:10:47Martin Fowler mengatakan ini pada tahun 2006.
00:10:49Kita membuat istilah bagus dengan definisi yang bagus
00:10:52lalu semua orang menjadi bersemangat
00:10:53dan semua orang mulai mengartikannya menjadi 100 hal berbeda
00:10:56bagi 100 orang berbeda dan akhirnya istilah itu menjadi tidak berguna.
00:10:59Kita menganggap agen sebagai orang, agen sebagai mikrolayanan,
00:11:02agen sebagai chatbot, agen sebagai alur kerja.
00:11:05Dan terima kasih, Simon.
00:11:06Kita kembali ke awal.
00:11:07Agen hanyalah sekumpulan alat dalam sebuah putaran.
00:11:09Ini juga terjadi pada pengembangan berbasis spek.
00:11:11Dulu saya memasang salindia Sean di awal presentasi ini,
00:11:15tapi itu menyebabkan banyak orang
00:11:15fokus pada hal-hal yang salah.
00:11:17Idenya tentang lupakan kodenya, kode sekarang seperti bahasa rakitan
00:11:19dan Anda cukup fokus pada markdown-nya.
00:11:21Ide yang sangat keren, tapi orang-orang bilang pengembangan berbasis spek
00:11:24adalah menulis perintah yang lebih baik, seperti dokumen persyaratan produk.
00:11:26Terkadang itu menggunakan putaran umpan balik yang dapat diverifikasi
00:11:28dan tekanan balik.
00:11:30Mungkin itu memperlakukan kode seperti bahasa rakitan,
00:11:32seperti yang diajarkan Sean kepada kita.
00:11:34Tapi bagi banyak orang, itu hanya menggunakan sekumpulan berkas markdown
00:11:36saat Anda sedang menulis kode.
00:11:37Atau favorit saya, saya baru saja menemukan ini minggu lalu,
00:11:39spek adalah dokumentasi untuk perpustakaan sumber terbuka.
00:11:43Jadi istilah itu sudah hilang.
00:11:44Pengembangan berbasis spek sudah terlalu dilebih-lebihkan dan tidak berguna sekarang.
00:11:48Istilah itu sudah terdifusi secara semantik.
00:11:49Jadi saya ingin membicarakan empat hal
00:11:52yang benar-benar berhasil saat ini, langkah taktis dan praktis
00:11:55yang kami temukan berhasil secara internal dan dengan banyak pengguna.
00:11:59Kita melakukan riset, kita cari tahu cara kerja sistemnya.
00:12:02Kalian ingat film "Memento"?
00:12:03Ini adalah film terbaik tentang rekayasa konteks,
00:12:05seperti yang dikatakan Peter.
00:12:07Pria ini terbangun, dia tidak punya ingatan,
00:12:09dia harus membaca tatonya sendiri untuk mencari tahu siapa dia
00:12:11dan apa yang sedang dia lakukan.
00:12:12Jika Anda tidak memberikan orientasi pada agen, mereka akan mengada-ada.
00:12:17Dan jadi ini adalah tim Anda, ini sangat disederhanakan
00:12:19bagi sebagian besar dari Anda.
00:12:19Kebanyakan dari Anda punya organisasi yang jauh lebih besar dari ini.
00:12:21Tapi katakanlah Anda ingin melakukan pekerjaan di bagian sini.
00:12:23Satu hal yang bisa Anda lakukan adalah menyertakan orientasi
00:12:26ke dalam setiap repositori.
00:12:27Anda memasukkan banyak konteks.
00:12:28Ini repositorinya, begini cara kerjanya.
00:12:29Ini adalah pemadatan dari semua konteks dalam basis kode
00:12:32yang bisa dilihat agen sebelumnya
00:12:34sebelum benar-benar mulai bekerja.
00:12:36Ini menantang karena terkadang dokumennya jadi terlalu panjang.
00:12:39Saat basis kode Anda menjadi sangat besar,
00:12:41Anda harus membuat ini lebih panjang
00:12:43atau Anda harus membuang beberapa informasi.
00:12:45Dan saat Anda sedang membaca ini,
00:12:48Anda akan membaca konteks
00:12:49dari mono-repo raksasa berisi lima juta baris ini
00:12:52dan Anda akan menghabiskan seluruh zona pintar
00:12:53hanya untuk belajar cara kerjanya dan Anda tidak akan bisa
00:12:55melakukan pemanggilan alat yang baik di zona bodoh.
00:12:57Jadi, Anda bisa membagi-bagi ini ke bawah.
00:13:02Anda bisa melakukan apa yang mereka sebut pengungkapan progresif.
00:13:04Anda bisa memecah ini, kan?
00:13:05Anda bisa menaruh berkas di akar setiap repositori
00:13:08dan kemudian di setiap level Anda punya konteks tambahan
00:13:11berdasarkan jika Anda bekerja di bagian ini,
00:13:13inilah yang perlu Anda ketahui.
00:13:15Kami tidak mendokumentasikan berkas itu sendiri
00:13:17karena berkas tersebut adalah sumber kebenarannya.
00:13:18Tapi kemudian saat agen Anda sedang bekerja,
00:13:19Anda menarik konteks akar
00:13:21dan kemudian Anda menarik sub-konteksnya.
00:13:22Kita tidak akan membahas spesifiknya,
00:13:23Anda bisa menggunakan CloudMD untuk ini,
00:13:24Anda bisa menggunakan Hoax untuk ini, atau apa pun.
00:13:26Tapi dengan begitu Anda masih punya banyak ruang di zona pintar
00:13:28karena Anda hanya menarik apa yang perlu Anda ketahui.
00:13:31Masalahnya adalah informasi ini bisa menjadi usang.
00:13:33Jadi setiap kali Anda merilis fitur baru,
00:13:35Anda perlu semacam melakukan validasi cache
00:13:38dan membangun kembali sebagian besar dokumentasi internal ini.
00:13:42Dan Anda bisa menggunakan banyak AI
00:13:43dan menjadikannya bagian dari proses Anda untuk memperbarui ini.
00:13:46Boleh saya ajukan pertanyaan?
00:13:48Di antara kode asli, nama fungsi,
00:13:50komentar, dan dokumentasi,
00:13:51ada yang mau menebak apa yang ada di sumbu y grafik ini?
00:13:57- Sampah. - Sampah.
00:13:58Sebenarnya itu adalah jumlah kebohongan yang bisa Anda temukan
00:14:01di bagian mana pun dari basis kode Anda.
00:14:03Jadi Anda bisa menjadikannya bagian dari proses Anda untuk memperbarui ini,
00:14:06tapi Anda mungkin tidak seharusnya melakukannya karena kemungkinan besar Anda tidak akan sempat.
00:14:08Yang kami sukai adalah konteks padat sesuai permintaan.
00:14:11Jadi jika saya membangun fitur yang berkaitan dengan penyedia SCM
00:14:14serta JIRA dan Linear,
00:14:15saya hanya akan memberinya sedikit arahan.
00:14:17Saya akan bilang, hei, kita akan mengerjakan
00:14:18di bagian basis kode yang sebelah sini
00:14:21dan perintah riset atau perintah garis miring yang baik
00:14:24mungkin akan menggunakan keahlian Anda,
00:14:27meluncurkan sekumpulan sub-agen untuk mengambil irisan vertikal ini
00:14:30meluncurkan banyak sub-agen untuk mengambil potongan vertikal ini
00:14:33melalui basis kode lalu menyusun dokumen riset
00:14:35yang hanyalah cuplikan dari kebenaran yang nyata
00:14:39berdasarkan kode itu sendiri, bagian basis kode yang penting.
00:14:41Kita sedang memadatkan kebenaran.
00:14:43Perencanaan adalah daya ungkit.
00:14:45Perencanaan adalah tentang pemadatan intensi.
00:14:48Dan dalam rencana, kita akan menguraikan langkah-langkah tepatnya.
00:14:50Mari ambil riset kita dan PRD atau tiket bug kita
00:14:52atau apa pun itu.
00:14:54Kita membuat rencana dan kita membuat berkas rencana.
00:14:55Jadi kita memadatkannya lagi.
00:14:58Dan saya ingin berhenti sejenak dan bicara tentang penyelarasan mental.
00:15:00Ada yang tahu untuk apa peninjauan kode (code review) dilakukan?
00:15:05Penyelarasan mental, penyelarasan mental.
00:15:08Ini tentang memastikan semuanya benar dan sebagainya.
00:15:10Tapi yang terpenting adalah bagaimana kita menjaga semua orang
00:15:11di dalam tim memiliki pemahaman yang sama
00:15:14tentang bagaimana basis kode berubah dan alasannya?
00:15:17Dan saya bisa membaca seribu baris Golang setiap minggu.
00:15:18Maaf, saya tidak bisa membaca seribu.
00:15:19Itu sulit, tapi saya bisa melakukannya.
00:15:20Tapi saya tidak mau.
00:15:23Dan seiring pertumbuhan tim, semua kode tetap ditinjau.
00:15:24Bukannya kami tidak membaca kodenya.
00:15:27Tapi saya, sebagai pemimpin teknis dalam tim,
00:15:29saya bisa membaca rencananya dan tetap mendapatkan informasi terbaru.
00:15:30Dan bagi saya, itu sudah cukup.
00:15:32Saya bisa menangkap beberapa masalah lebih awal
00:15:35dan saya tetap memahami bagaimana sistem berevolusi.
00:15:36Mitchell membuat tulisan yang sangat bagus
00:15:38tentang bagaimana dia memasukkan utas AMP-nya
00:15:41pada pull request-nya sehingga Anda tidak hanya melihat,
00:15:43"hei, ini ada tumpukan teks hijau di GitHub,"
00:15:44tapi ini langkah-langkah tepatnya, ini perintahnya,
00:15:46dan hei, saya menjalankan build di akhir dan berhasil.
00:15:49Ini membawa peninjau dalam sebuah perjalanan
00:15:51dengan cara yang tidak bisa dilakukan oleh PR GitHub.
00:15:52Dan saat Anda merilis kode dua hingga tiga kali
00:15:54lebih banyak daripada sebelumnya,
00:15:57menjadi tanggung jawab Anda untuk menemukan cara agar tim tetap
00:16:00memiliki pemahaman yang sama dan menunjukkan langkah-langkah yang dilakukan
00:16:01serta cara kami mengujinya secara manual.
00:16:04Tujuan Anda adalah daya ungkit, jadi Anda ingin kepercayaan tinggi
00:16:06bahwa model tersebut benar-benar akan melakukan hal yang benar.
00:16:08Saya tidak bisa sekadar membaca rencana ini dan tahu apa yang sebenarnya
00:16:11akan terjadi dan perubahan kode apa yang akan dilakukan.
00:16:14Jadi, seiring waktu, kami beralih agar rencana kami menyertakan
00:16:17potongan kode aktual dari apa yang akan berubah.
00:16:18Jadi tujuan Anda adalah daya ungkit.
00:16:19Anda ingin pemadatan intensi
00:16:22dan eksekusi yang andal.
00:16:23Dan, saya punya latar belakang fisika.
00:16:28Kami suka menarik garis melalui pusat puncak dan kurva.
00:16:30Semakin panjang rencana Anda, keandalannya naik,
00:16:31tapi keterbacaannya turun.
00:16:33Ada titik ideal bagi Anda, tim Anda,
00:16:35dan basis kode Anda, Anda harus mencoba menemukannya.
00:16:37Karena saat kita meninjau riset dan rencana tersebut,
00:16:40jika hasilnya bagus, maka kita bisa mendapatkan penyelarasan mental.
00:16:42Jangan menyerahkan proses berpikir kepada pihak luar.
00:16:44Saya sudah katakan ini sebelumnya, ini bukan sihir.
00:16:46Tidak ada perintah (prompt) yang sempurna.
00:16:50Ini tetap tidak akan berhasil jika Anda tidak membaca rencananya.
00:16:53Jadi kami membangun seluruh proses kami di sekitar Anda, sang pembangun,
00:16:55yang berinteraksi bolak-balik dengan agen,
00:16:56membaca rencana saat rencana itu dibuat.
00:16:58Dan kemudian jika Anda butuh tinjauan rekan sejawat,
00:16:58Anda bisa mengirimkannya ke seseorang dan bertanya,
00:17:00"hei, apakah rencana ini terlihat benar?"
00:17:00"Apakah ini pendekatan yang tepat?"
00:17:03"Apakah ini urutan yang tepat untuk memeriksa hal-hal ini?"
00:17:05Jake, sekali lagi, menulis postingan blog yang sangat bagus tentang
00:17:07hal yang membuat implementasi rencana riset menjadi berharga
00:17:11yaitu Anda, manusia di dalamnya, yang memastikan kebenarannya.
00:17:14Jadi jika ada satu hal yang bisa diambil dari pembicaraan ini,
00:17:17itu adalah bahwa baris kode yang buruk tetaplah baris kode yang buruk.
00:17:22Dan bagian rencana yang buruk bisa berarti 100 baris kode yang buruk.
00:17:25Dan baris riset yang buruk, seperti kesalahpahaman
00:17:27tentang cara kerja sistem dan di mana letak berbagai hal,
00:17:29seluruh pekerjaan Anda akan berantakan.
00:17:31Anda akan mengirim model ke arah yang salah.
00:17:34Jadi saat kami bekerja secara internal dan dengan pengguna,
00:17:36kami terus mencoba memindahkan upaya dan fokus manusia
00:17:39ke bagian dengan daya ungkit tertinggi dari alur kerja ini.
00:17:41Jangan menyerahkan proses berpikir kepada pihak luar.
00:17:43Waspadai alat yang hanya mengeluarkan
00:17:45banyak berkas markdown hanya agar Anda merasa senang.
00:17:47Saya tidak akan menyebutkan nama di sini.
00:17:49Terkadang hal ini berlebihan.
00:17:51Dan cara saya memikirkannya adalah seperti,
00:17:54ya, Anda tidak selalu butuh riset, rencana, dan implementasi penuh.
00:17:56Terkadang Anda butuh lebih banyak, terkadang lebih sedikit.
00:17:57Jika Anda hanya mengubah warna tombol,
00:18:00cukup bicara dengan agen dan beri tahu apa yang harus dilakukan.
00:18:04Jika Anda membuat rencana sederhana dan itu fitur kecil,
00:18:07tapi jika membuat fitur menengah di beberapa repositori,
00:18:09maka lakukan satu riset, lalu buatlah rencana.
00:18:10Pada dasarnya, masalah tersulit yang bisa Anda selesaikan,
00:18:13batas kemampuannya akan naik seiring dengan banyaknya context engineering
00:18:15dan pemadatan yang bersedia Anda lakukan.
00:18:18Dan jika Anda berada di tingkat yang lebih tinggi,
00:18:19Anda mungkin harus melakukan lebih banyak.
00:18:21Banyak orang bertanya kepada saya, bagaimana saya tahu
00:18:23seberapa banyak context engineering yang harus digunakan?
00:18:24Itu butuh latihan berulang.
00:18:26Anda akan salah, Anda harus melakukan kesalahan
00:18:27berulang kali sampai terbiasa.
00:18:29Terkadang Anda terlalu berlebihan, terkadang terlalu sedikit.
00:18:32Pilih satu alat dan mulailah berlatih.
00:18:35Saya menyarankan untuk tidak terlalu memusingkan perbandingan antara Claude dan Codex
00:18:36dan semua alat yang berbeda ini.
00:18:40Jadi, saya bukan orang yang suka singkatan.
00:18:42Kami bilang pengembangan berbasis spek (spec driven dev) itu tidak efektif.
00:18:44Menurut saya riset, rencana, dan implementasi bukan sekadar langkah-langkah.
00:18:47Bagian terpenting adalah pemadatan dan context engineering
00:18:48serta tetap berada di zona cerdas.
00:18:50Tapi orang-orang menyebut ini RPI
00:18:52dan tidak ada yang bisa saya lakukan.
00:18:55Jadi waspadalah, tidak ada perintah yang sempurna,
00:18:56tidak ada solusi ajaib.
00:18:58Jika Anda ingin istilah yang lebih keren,
00:19:00Anda bisa menyebutnya harness engineering,
00:19:01yang merupakan bagian dari context engineering
00:19:03dan ini tentang bagaimana Anda berintegrasi dengan titik integrasi
00:19:05pada Codex, Claude, Cursor, atau apa pun,
00:19:07bagaimana Anda menyesuaikan basis kode Anda.
00:19:11Jadi, apa selanjutnya?
00:19:12Saya rasa hal-hal tentang agen pengodean sebenarnya
00:19:13akan menjadi hal yang umum.
00:19:15Orang-orang akan belajar cara melakukan ini dan menjadi lebih baik.
00:19:17Dan bagian tersulitnya adalah bagaimana Anda mengadaptasi tim Anda
00:19:21dan alur kerja Anda dalam SDLC untuk bekerja di dunia
00:19:24di mana 99% kode Anda dibuat oleh AI.
00:19:26Dan jika Anda tidak bisa memahaminya, Anda akan tamat.
00:19:27Karena ada semacam kesenjangan yang tumbuh
00:19:29di mana staf insinyur tidak mengadopsi AI
00:19:31karena itu tidak membuat mereka jauh lebih cepat
00:19:33dan kemudian insinyur tingkat junior dan menengah banyak menggunakannya
00:19:35karena itu menutupi kesenjangan keterampilan
00:19:36dan kemudian itu juga menghasilkan beberapa kode sampah
00:19:38dan kemudian insinyur senior semakin membencinya
00:19:40setiap minggu karena mereka harus membersihkan kode sampah,
00:19:42yang dikirim oleh Cursor seminggu sebelumnya.
00:19:44Ini bukan salah AI,
00:19:46ini bukan salah insinyur tingkat menengah.
00:19:48Perubahan budaya itu sangat sulit
00:19:50dan itu harus datang dari atas agar bisa berhasil.
00:19:52Jadi jika Anda adalah pemimpin teknis di perusahaan Anda,
00:19:54pilih satu alat dan mulailah berlatih.
00:19:56Jika Anda ingin membantu, kami sedang merekrut,
00:19:59kami sedang membangun IDE berbasis agen untuk membantu tim dari segala ukuran
00:20:03mempercepat perjalanan menuju 99% kode buatan AI.
00:20:06Kami akan senang mengobrol jika Anda ingin bekerja sama dengan kami.
00:20:08Kunjungi situs web kami, kirimkan email,
00:20:09atau temui saya di luar ruangan.
00:20:11Terima kasih banyak atas energi Anda semua.
00:20:13(penonton bertepuk tangan)