Dari Berbantuan AI hingga AI-Native: Membangun Tim Pengembangan Perbatasan — Clare Liguori, AWS
AAI Engineer
Computing/SoftwareManagementInternet Technology
Transcript
00:00:00Clare Liguori: Nama saya Clare Liguori, dan saya adalah Senior Principal Engineer di AWS.
00:00:17Saya sebagian besar bekerja di Kiro, asisten decoding agen kami, tetapi hari ini saya ingin membahas
00:00:23beberapa praktik yang telah kami lihat di dalam Amazon, di tim-tim Amazon, tempat kami melihat
00:00:28hasil yang sangat menarik dari peningkatan produktivitas yang merupakan peningkatan fungsi langkah
00:00:35dari apa yang telah kita lihat dengan AI sejauh ini. Saya telah mengerjakan AI agen selama lebih dari tiga tahun sekarang,
00:00:43dan saya telah melihat evolusi yang terjadi di industri kita dalam hal bantuan
00:00:48pengkodean dengan AI. Pertama, kita memiliki penyelesaian kode sebaris ini yang membantu kita menulis baris berikutnya,
00:00:55mungkin fungsi berikutnya. Kami beralih ke obrolan, mengajukan pertanyaan tentang kode kami. Semua orang mulai melakukan
00:01:02vibe coding sekitar tahun lalu, tetapi sekarang kami mulai melihat fase awal pengadopsian dari
00:01:08apa yang kami sebut pengembangan perbatasan (frontier development). Dan sepenuhnya secara anekdot, berdasarkan pengalaman saya sendiri,
00:01:14saya benar-benar hanya merasa mungkin 10 hingga 20% lebih produktif dengan semua fase ini yang telah
00:01:20datang sebelumnya. Namun sekarang di dalam Amazon, kami telah menjalankan percontohan dengan berbagai tim di seluruh perusahaan,
00:01:27dan kami telah melihat peningkatan produktivitas median 4,5x dan terkadang lebih dari 10x. Jadi,
00:01:34ada sesuatu yang benar-benar berubah sekarang karena kita melihat peningkatan fungsi langkah dalam produktivitas ini.
00:01:40Dan saya ingin mendefinisikan apa yang telah kami sebut pengembang perbatasan di dalam Amazon
00:01:47oleh tiga perilaku yang telah saya lihat. Yang pertama adalah pengkodean tanpa tangan (hands-off coding). Pengembang perbatasan mungkin menulis
00:01:541 hingga 2% dari kode yang mereka hasilkan. Sisanya adalah agen. Yang kedua adalah mereka berinteraksi dengan
00:02:01agen mereka secara jarang. Mereka akan bertujuan agar asisten pengkodean mereka berjalan hingga berjam-jam lamanya tanpa
00:02:08intervensi mereka. Dan yang ketiga adalah mereka meminimalkan waktu idle. Pengembang perbatasan ini cenderung menjalankan
00:02:15beberapa agen secara paralel, menyelesaikan tumpukan tugas. Pertama kalinya saya melihat tim pengembang
00:02:24perbatasan adalah tim Bedrock Mantle. Bedrock adalah layanan hosting model kami. Layanan ini menghosting LLM seperti Claude
00:02:34dan GPT. Dan sekitar tahun lalu kami tahu, atau saya bilang kami, tetapi tim Bedrock tahu bahwa mereka akan
00:02:43perlu membangun bidang data inferensi yang baru. Tetapi mereka memperkirakannya 30 orang selama 18 bulan. Ini adalah layanan
00:02:52yang sangat besar. Dan butuh waktu untuk membangun yang baru, memigrasikan pelanggan, memigrasikan model
00:02:58ke sana. Dan mereka memutuskan untuk mundur selangkah. Mereka mengambil enam orang dan mereka membangunnya dalam 76 hari dengan Kiro.
00:03:06Jadi ini adalah pencapaian yang besar. Ini adalah pertama kalinya kami melihat hal seperti itu di dalam Amazon.
00:03:12Jadi ini benar-benar tim perintis yang membuktikan bahwa adalah mungkin untuk mendapatkan peningkatan hingga 20x. Sekarang mereka melihat
00:03:21pada commit, dan saya akan membahas beberapa cara lain bagaimana kami mengukur peningkatan produktivitas. Tetapi
00:03:27ada satu masalah dengan cerita ini, yaitu ya, itu dibangun dengan enam orang. Itu dibangun
00:03:34dengan beberapa insinyur papan atas secara harfiah di perusahaan, termasuk dua insinyur terkemuka. Jadi ini
00:03:40bukan sembarang tim yang terdiri dari enam orang. Mereka adalah ahli dalam sistem terdistribusi, ahli dalam LLM dan
00:03:49arsitekturnya. Jadi cerita ini luar biasa dan menyebar seperti api di seluruh Amazon. Tetapi itu juga
00:03:57sangat tidak dapat dicapai untuk banyak tim. Ada banyak pertanyaan tentang, apakah ini benar-benar dapat direproduksi
00:04:03pada tim lain? Jadi eksperimen lain yang ingin saya bicarakan adalah sprint eksperimental yang dilakukan
00:04:10di organisasi prime video. Mereka mengambil sprint 10 hari dan mereka melakukan eksperimen di mana mereka menempatkan, sekali lagi, enam insinyur
00:04:19di dalam satu ruangan dan membiarkan mereka menjadi liar dengan Kiro. Mereka menurunkan perkiraan waktu pengiriman proyek dari apa yang
00:04:29semula 90 minggu turun menjadi 24 berdasarkan semua kemajuan yang telah mereka buat dalam sprint 10 hari ini.
00:04:36Dan mereka melihat riwayat commit mereka dan mereka melihat apa yang biasa mereka lakukan sebelum
00:04:42sprint 10 hari ini dan berapa banyak commit yang mereka hasilkan hanya dalam 10 hari ini. Jadi sprint ini benar-benar
00:04:49membuktikan bahwa kita dapat mencapai, sekali lagi, setidaknya sesuatu yang mendekati apa yang telah dicapai oleh tim Bedrock Mantle
00:04:58dengan kumpulan insinyur yang berbeda. Tapi sekali lagi, ada tantangan dengan cerita ini, yaitu ada enam
00:05:05insinyur di dalam ruangan tanpa tugas siaga (on-call), rapat terbatas, sangat sedikit gangguan, yang kita semua
00:05:12tahu adalah hal biasa dalam kehidupan seorang insinyur. Dan insinyur senior di tim tersebut telah menghabiskan tiga
00:05:20minggu sebelumnya untuk membuat tugas yang sangat terperinci, kecil, dan tercakup dengan baik dengan persyaratan terperinci agar keenam
00:05:28insinyur tersebut dapat langsung mengerjakannya selama dua minggu tersebut. Jadi ini, sekali lagi, belum tentu kehidupan nyata.
00:05:35Ini adalah sprint terstruktur, satu titik waktu di mana mereka dapat mencapai ini. Tapi sekali lagi,
00:05:41pertanyaannya adalah, apakah ini dapat dicapai pada tim nyata untuk pekerjaan sehari-hari? Jadi Amazon Stores, yang mencakup
00:05:51Amazon.com, semua situs web ritel kami, serta toko fisik kami, melakukan percontohan yang lebih terstruktur.
00:05:59Mereka mengawasi 50 tim yang benar-benar normal, distribusi normal dari orang-orang karier awal, karier menengah,
00:06:07insinyur senior, dan yang bekerja pada sistem yang ada. Bukan hal baru (Greenfield) seperti yang bisa dibangun oleh tim Mantle
00:06:14dari bawah ke atas, melainkan sistem yang ada dengan basis kode yang sudah ada. Dan mereka mengawasi mereka selama
00:06:21sebagian besar tahun lalu, dan mereka menemukan sesuatu yang sangat menarik. Mereka menemukan bahwa ada perbedaan besar
00:06:28dalam peningkatan produktivitas yang mereka lihat antara separuh tim dan separuh lainnya. Dan dalam
00:06:34kasus ini, mereka menggunakan metrik produktivitas kecepatan penerapan ke produksi. Jadi bukan hanya commit, berapa banyak
00:06:41commit yang mereka hasilkan, tetapi seberapa cepat kami mengeluarkan perubahan kepada pelanggan? Seberapa cepat kami
00:06:48dapat mengirimkan barang? Dan mereka melihat bahwa untuk separuh tim, mereka mencapai peningkatan kurang dari 3x. Dan apa yang
00:06:56mereka temukan sebagai perbedaan antara melihat peningkatan produktivitas kurang dari 3x, dan tim-tim yang melihat
00:07:01median 4,5x, dan dalam beberapa kasus lebih dari 10, adalah bagaimana mereka menggunakan alat tersebut. 90% dari tim ini menggunakan Kiro, di antara
00:07:11alat internal lain yang kami miliki. Dan apa yang mereka temukan adalah, ini bukan tentang alatnya, melainkan cara mereka
00:07:18bekerja. Tim yang mencapai peningkatan fungsi langkah secara sengaja mengubah cara mereka bekerja,
00:07:26dan yang lainnya hanya menaburkan Kiro dan beberapa alat lain yang kami miliki di atas cara
00:07:31kerja mereka yang sudah ada. Dan bagi saya setidaknya, ini adalah momen “aha” yang besar, mengapa saya tidak merasakan
00:07:39potensi peningkatan produktivitas yang masif yang dijanjikan oleh AI, ini tentang mengubah cara kita
00:07:47bekerja. Jadi di seluruh percontohan ini, mereka pergi dan mewawancarai tim yang terlibat dalam percontohan, serta beberapa
00:07:55tim lain di tim Bedrock Mantle, di Prime Video, dan mereka menemukan lima kebiasaan. Dan saya menggunakan
00:08:03kata kebiasaan secara sangat spesifik, karena sekali lagi, ini bukan tentang sprint itu, ini tentang melakukan ini dari
00:08:09hari ke hari. Dan apa yang mereka temukan ketika mereka mewawancarai tim-tim ini adalah bahwa itu benar-benar kebiasaan yang harus mereka
00:08:15bangun dari hari ke hari. Ketika kita mengubah cara kerja kita, sulit untuk membangun kebiasaan ini, butuh waktu untuk membangun
00:08:22kebiasaan ini. Jadi mari kita bahas satu persatu. Kebiasaan nomor satu adalah berinvestasi dalam konteks agen.
00:08:30Kita memiliki banyak hal di kepala kita, kita cenderung mentransfer semua hal di kepala kita ke orang lain
00:08:35melalui percakapan Slack, melalui mentor orientasi, hal-hal seperti itu melalui tinjauan kode,
00:08:42melalui stand-up dan perencanaan sprint, dan mereka harus menuliskan semua itu. Dan kebiasaan yang mereka
00:08:50bangun adalah setiap kali agen membuat kesalahan atau melakukan sesuatu yang tidak seperti yang akan Anda lakukan
00:08:55itu. Apa yang saya lewatkan di file keterampilan (skills) saya? Apa yang saya lewatkan di file kemudi (steering) saya yang dibutuhkan agen?
00:09:01Tetapi kemudian seperti yang kita tahu, sepanjang tahun lalu, kita melihat lompatan besar dalam kemampuan dan perilaku model.
00:09:09Sonnet 3.7 di pertengahan tahun lalu memiliki banyak keanehan yang membuat kita harus menaruh banyak larangan (do nots)
00:09:16di file steering kita. Dan sekarang kita tidak perlu melakukan itu sebanyak dengan Opus 4.5 per November lalu,
00:09:23dan kemudian kita telah memiliki enam bulan, lebih dari enam bulan peningkatan sejak saat itu, dengan semua
00:09:29versi baru model yang telah keluar sejak saat itu. Dan jadi pertanyaannya, kebiasaan baru lagi adalah, apakah saya
00:09:35masih memerlukan ini di file steering saya? Atau apakah ini hanya mengembungkan konteks? Yang kedua adalah melambat untuk
00:09:41mempercepat. Di hampir setiap tim yang diwawancarai, mereka melaporkan bahwa produktivitas mereka sebenarnya turun
00:09:48ketika mereka dengan sengaja mengadopsi cara kerja baru. Itu bertentangan dengan intuisi,
00:09:53bertentangan dengan intuisi, bukan? Anda harus melakukan pekerjaan teknik yang disengaja sebelum Anda akan melihat
00:09:59kurva kurva hoki (hockey stick) dalam peningkatan produktivitas. Karena kita harus melakukan pekerjaan nyata di basis kode kita
00:10:05terlebih dahulu agar agen berhasil di sana, terutama di basis kode yang ada (brownfield). Jadi mereka harus
00:10:11membangun konteks agen tersebut, mereka harus meningkatkan pesan kesalahan alat yang ada sehingga model tahu
00:10:17apa yang sedang terjadi ketika itu gagal, mereka membangun alat baru, server MCP baru untuk membantu model tersebut benar-benar menyelesaikan
00:10:24apa yang perlu diselesaikannya. Banyak tim akhirnya merestrukturisasi basis kode mereka sehingga agen
00:10:29dapat bernavigasi dengan lebih mudah. Dan saya bahkan melihat perubahan drastis seperti mengubah bahasa pemrograman
00:10:36dari basis kode tersebut. Seringkali saya melihat tim berjuang dengan Python, dengan JavaScript karena itu adalah
00:10:43bahasa yang tidak bertipe (untyped). Sulit untuk diuji. Tidak ada kesalahan kompiler. Jadi model menebak-nebak dan
00:10:50memberikannya kembali kepada Anda. Oleh karena itu, saya telah melihat tim beralih ke TypeScript. Rust telah menjadi sangat populer
00:10:56di dalam Amazon. Kompiler memberikan pesan kesalahan yang hebat. Anda tidak harus melakukan itu. Tapi saya telah melihat banyak
00:11:03tim membuat perubahan yang disengaja demi keuntungan produktivitas yang dapat mereka lihat.
00:11:09Yang ketiga adalah memberi makan agen, bukan mengasuh agen. Dan bagi saya, ini adalah salah satu momen “aha”
00:11:16tentang mengapa kita melihat peningkatan fungsi langkah dalam produktivitas ini. Jika Anda melakukan vibe coding, jika Anda
00:11:23melakukan percakapan bolak-balik dengan agen Anda sepanjang hari, tentu saja, Anda tidak akan melihat
00:11:30peningkatan produktivitas empat hingga lima kali lipat karena Anda berada di dalam lingkaran (in the loop) sepanjang waktu. Anda mungkin
00:11:36duduk di sana selama 30 detik hingga satu menit menunggu agen menghasilkan kode dan kembali kepada Anda dengan
00:11:42membawa kode untuk ditinjau. Jika Anda duduk di sana menunggunya, maka Anda tidak dapat pergi dan melakukan hal
00:11:48hal-hal lain. Sangat sulit untuk menjalankan agen secara paralel. Sangat sulit untuk menggandakan diri Anda
00:11:55menjadi beberapa agen. Jadi jika percakapan Anda terlihat seperti di sebelah kiri ini, maka Anda sedang
00:12:01mengasuh agen tersebut, alih-alih di sisi kanan di mana Anda memberikan apa yang harus dilakukannya dan bagaimana
00:12:08ia dapat memvalidasi dirinya sendiri. Dan itulah kunci utamanya agar agen dapat mengoreksi diri sendiri dan hanya kembali kepada Anda
00:12:14ketika memenuhi standar kualitas tertentu, ketika benar-benar berjalan, dikompilasi, dan lulus pengujian, ketika
00:12:20dapat diuji, ketika benar-benar memiliki cakupan yang tinggi. Dan tentu saja, tingkat berikutnya adalah memasukkan semua
00:12:26konten ini ke dalam berkas panduan Anda. Sehingga ia melakukannya setiap saat tanpa Anda harus memintanya.
00:12:33Kebiasaan keempat adalah membuat maksud menjadi eksplisit. Di Amazon, kami banyak mempraktikkan pengembangan spektrum.
00:12:40Kami telah membangunnya ke dalam produk Kiro. Dan sangat wajar bagi para insinyur Amazon untuk mengadopsinya
00:12:46di Kiro. Apa yang biasanya saya lihat pada vibe coding alih-alih teknik perbatasan adalah memberikan
00:12:54perintah tingkat tinggi, membiarkan agen menghasilkan banyak kode, lalu melakukan percakapan bolak-balik
00:13:02dengan berkata, Oh, bukan itu maksud saya sebenarnya. Anda belum sepenuhnya tepat menangkap persyaratannya.
00:13:10Tidak, saya sebenarnya tidak ingin membangunnya seperti itu. Ini rancangan teknisnya. Dan saya rasa kurang produktif
00:13:17untuk beriterasi dengan agen mengenai kode ketika maksudnya sendiri tidak tepat. Jadi sering kali kita akan melihat insinyur Amazon
00:13:26melalui proses ini untuk fitur yang ambigu dan kompleks dengan menulis spesifikasi.
00:13:34Dan di Kiro, tentu saja Anda tidak harus menulis seluruh spesifikasi ini, Anda dapat meminta model menghasilkan
00:13:39nya. Namun jauh lebih mudah beriterasi dengan model dalam percakapan bolak-balik mengenai
00:13:46sebuah dokumen daripada mengenai perubahan kode yang tersebar di sekujur basis kode. Yang kelima adalah menggeser pengujian ke kiri.
00:13:56Salah satu kuncinya di sini adalah memberikan umpan balik yang cepat kepada agen, karena itulah yang memungkinkannya bekerja selama berjam-jam
00:14:04dan mengoreksi diri sendiri. Agen pasti akan membuat kesalahan, dan itu tidak masalah. Namun jika Anda memberikan sinyal yang tepat, ia dapat
00:14:12mengoreksi diri dan menghabiskan waktu untuk melakukannya. Jadi saya melihat tim-tim menambahkan linter, pengujian unit,
00:14:20pengujian integrasi, pengujian kinerja, pengujian keamanan. Ini semua adalah hal yang kita tahu seharusnya
00:14:24kita lakukan selama ini. Ini adalah kebersihan dan praktik rekayasa yang baik. Namun kini laba atas investasinya, saya rasa, akhirnya
00:14:32cukup tinggi bagi kita untuk benar-benar berinvestasi di dalamnya. Satu hal yang sering saya lihat dilakukan tim-tim adalah membuat tiruan layanan.
00:14:40Sering kali dengan pengujian integrasi, kita menguji seluruh sistem dari ujung ke ujung, termasuk layanan
00:14:46langsung. Namun kami telah banyak berinvestasi pada layanan tiruan yang berjalan secara lokal dengan respons
00:14:52deterministik, karena hal itu memungkinkan agen melakukan segalanya secara lokal. Melakukan semuanya di laptop Anda tanpa
00:15:01harus menyalakan banyak layanan lain dan terhubung ke layanan awan membuat segalanya jauh lebih cepat.
00:15:07Karena semakin banyak umpan balik cepat yang bisa didapat agen, berarti semakin banyak putaran yang dapat
00:15:14dilakukannya dan semakin produktif agen Anda sendiri. Jadi secara keseluruhan, inilah beberapa
00:15:21kebiasaan yang telah kami lihat. Namun tentu saja, saya akan lalai jika mengatakan bahwa jika Anda mengadopsi semua kebiasaan ini,
00:15:28Anda akan mencapai nirwana, Anda akan menjadi organisasi teknik paling produktif di dunia
00:15:35yang pernah ada. Segala sesuatunya masih sulit. Kami masih berada di fase pengadopsi awal dan tim-tim masih
00:15:42mempelajarinya. Jadi satu hal yang kami lihat di tim-tim kami secara organisasi adalah risiko
00:15:48kelelahan kerja. Saya tidak menciptakan istilah ini, saya lupa siapa yang mengatakannya di konferensi mana, tetapi FOMAT itu nyata. Kami telah melihat
00:15:56para insinyur terjaga hingga larut malam, mencoba mendapatkan perintah sempurna yang akan membuat
00:16:03agen mereka berjalan selama berjam-jam semalaman sehingga mereka bangun di pagi hari dengan perubahan kode yang sudah siap. Beban kognitif
00:16:09meningkat saat Anda menjalankan beberapa agen ini secara paralel, Anda terus-menerus berpindah di antara
00:16:15tab terminal. Dan kami melihat bahwa meninjau keluaran AI sering kali lebih sulit bagi sebagian orang daripada
00:16:22benar-benar menulisnya, terutama pada awal karier. Insinyur senior telah menghabiskan sebagian besar
00:16:29karier mereka untuk meninjau kode orang lain. Namun insinyur awal karier belum memiliki kemampuan itu. Jadi meninjaunya
00:16:37dapat terasa memberikan beban kognitif yang jauh lebih besar daripada yang biasa mereka rasakan saat benar-benar menulisnya. Hal lainnya
00:16:44adalah perubahan organisasi. Jadi sudah sulit untuk mengubah cara kerja kita sebagai insinyur. Cara kita
00:16:52menghabiskan sepanjang hari berubah sepenuhnya ketika kita menjadi insinyur perbatasan. Namun organisasi juga harus
00:16:58berubah untuk mendukung tim teknik perbatasan. Salah satu yang sangat sering saya lihat adalah menerima untuk melambat
00:17:07demi mempercepat. Dan saya sendiri pernah bersalah atas hal ini. Rekan-rekan pemimpin saya telah bersalah atas hal ini dengan mengatakan,
00:17:14nah, kalian sekarang sudah punya perangkat AI dan modelnya sangat luar biasa sekarang. Kenapa kalian tidak bergerak lebih cepat?
00:17:22Dan itu karena Anda harus meluangkan waktu dua bulan tersebut untuk berinvestasi pada basis kode Anda guna mencari
00:17:29praktik terbaik terbaik untuk tim Anda guna melakukan perubahan kebiasaan yang sulit pada tim Anda. Dan jika Anda terus-menerus mengharapkan
00:17:38pengiriman fitur setiap bulan, karena sekarang kita memiliki model-model luar biasa ini, dan kita melihat
00:17:44semua perusahaan ini di X mengatakan bagaimana mereka mengirimkan 20 PR sehari, kita harus melambat untuk mempercepat.
00:17:54Yang kedua adalah terlalu luas cakupannya di dalam organisasi dengan terlalu cepat. Saya pikir jika kita
00:18:01mengharapkan semua tim dalam organisasi besar untuk langsung menjadi tim perbatasan segera, kita tidak akan mendapatkan
00:18:08pembelajaran yang kita peroleh dari jalur perintis, dari eksperimen sprint, dari tim pilot
00:18:16di dalam Amazon. Dan kini tantangan bagi kita adalah bagaimana kita memperluasnya? Dan itulah fokus tahun 2026.
00:18:22Bagi Amazon adalah bagaimana memperluas ini ke lebih banyak tim dan 2.000 tim berikutnya alih-alih 50 tim.
00:18:31Dan saya pikir ketika Anda menerapkannya terlalu cepat, Anda memiliki banyak tim yang tidak tahu apa yang mereka
00:18:37lakukan. Anda belum punya waktu untuk menemukan praktik terbaik untuk organisasi Anda sendiri, konteks
00:18:43yang dibutuhkan oleh organisasi Anda. Dan yang terakhir adalah Anda akan menemukan hambatan baru.
00:18:49Sebelumnya menulis kode secara manual adalah hambatannya. Saya mendapati bahwa di dalam Amazon, kami menemukan
00:18:58kecepatan pengambilan keputusan menjadi hambatan baru. Semakin banyak waktu yang Anda habiskan untuk meninjau keputusan
00:19:05untuk benar-benar membangun produk baru, semakin lambat proses pembuatan produk tersebut sekarang karena kodenya hanya butuh satu hingga dua bulan untuk ditulis.
00:19:12Semua proses peninjauan yang terkait dengan peluncuran produk menjadi hambatan.
00:19:20Ketika dulu butuh waktu sembilan hingga 12 bulan untuk membangun produk baru, hal itu tidak terlalu bermasalah secara keseluruhan
00:19:27jika butuh waktu dua bulan untuk mengambil keputusan membangun produk lalu dua bulan untuk
00:19:33menyetujui peluncurannya. Namun sekarang hal-hal itulah hambatannya. Itulah proses terlama. Jadi Anda mendapati semua
00:19:40hal ini yang memperlambat Anda. Seringkali saya mendapati tim teknik perbatasan menghabiskan lebih banyak waktu
00:19:48membuat keputusan daripada menulis kode. Jadi semakin cepat Anda bisa mengambil keputusan, terutama keputusan
00:19:54yang mudah dibatalkan, maka akan semakin baik. Jadi satu kesimpulan besar saya untuk semua orang di sini adalah bahwa rekayasa
00:20:03perbatasan adalah tentang mengubah cara kerja Anda secara sengaja. Dan itu sulit. Itu butuh waktu.
00:20:10Itu membentuk kebiasaan baru dan cara kerja baru. Dan itu berlaku di setiap tim teknik serta
00:20:18organisasi Anda. Jadi saya mendorong Anda untuk memikirkan bagaimana Anda berinteraksi dengan perangkat AI dan bagaimana hal itu dapat
00:20:27berubah untuk membebaskan diri Anda dari keharusan terlibat terus-menerus. Terima kasih. Saya akan tinggal sebentar jika ada yang punya
00:20:34pertanyaan di belakang. Tapi terima kasih atas waktunya hari ini.