WEBVTT 00:00:00.000 --> 00:00:08.020 Bagaimana jika tim pengembangan perangkat lunak Anda memiliki rekan tambahan yang tidak pernah lelah belajar lebih cepat dari siapapun dan mengerjakan tugas membosankan tanpa mengeluh dan mengerjakan tugas membosankan tanpa mengeluh? 00:00:08.160 --> 00:00:10.360 Itulah intinya AI-Gen yang sedang berkembang saat ini. 00:00:11.120 --> 00:00:19.940 Dalam video ini, pertama kita akan mendefinisikan apa arti AI-Gen, lalu menunjukkan cara kerjanya di alur kerja.net dan Azure, serta mengeksplorasi dampaknya bagi produktivitas tim Anda. 00:00:20.960 --> 00:00:24.840 Di akhir video, Anda akan mengetahui satu eksperimen kecil untuk dicoba di alur kerja.net Anda minggu ini. 00:00:24.840 --> 00:00:31.640 Namun sebelum bahas penerapan dan hasilnya, kita perlu melihat apa yang membuat AI-Gen berbeda dari alat pelengkap otomatis yang sudah Anda kenal. 00:00:33.120 --> 00:00:34.400 Apa yang membuat AI-Gen berbeda? 00:00:35.240 --> 00:00:41.560 Jadi, yang membedakan AI-Gen bukan sekadar kemampuan menghasilkan kode, melainkan cara kerjanya yang menyerupai sistem rekan kerja dengan kemampuan berbeda. 00:00:42.260 --> 00:00:44.840 Untuk memahaminya, kita bisa membaginya ke dalam tiga sifat utama. 00:00:44.840 --> 00:00:52.480 Cara setiap agen menyimpan konteks dan memori, cara koordinasi antara agen layaknya sebuah tim, dan perbedaan antara otomatisasi sederhana dengan otonomi adaptif sejati. 00:00:52.480 --> 00:00:57.940 Pertama, mari kita lihat apa yang membuat agen individu istimewa konteks, memori, dan orientasi tujuan. 00:00:58.660 --> 00:01:03.800 Pelengkap otomatis tradisional memprediksi kata atau baris berikutnya, tetapi langsung melupakan segalanya setelah prediksi dibuat. 00:01:04.620 --> 00:01:08.080 Sebaliknya, agen AI memiliki pemahaman terhadap proyek yang lebih luas. 00:01:08.760 --> 00:01:12.900 Ia mengingat apa yang sudah dicoba atau letak kode, dan menyesuaikan hasilnya saat ada perubahan. 00:01:13.860 --> 00:01:20.220 Ketekunan tersebut membuatnya lebih mirip bekerja dengan pengembang junior, seseorang yang belajar seiring waktu alih-alih hanya menebak keinginan Anda saat itu juga. 00:01:20.220 --> 00:01:23.080 Perbedaan utamanya di sini terletak pada prediksi proses perancana. 00:01:23.440 --> 00:01:28.480 Alih-alih bereaksi terhadap setiap ketika secara terpisah, agen tetap melecak tujuan dan beradaptasi seiring perkembangan situasi. 00:01:29.080 --> 00:01:30.960 Selanjutnya adalah bagaimana beberapa agen bekerjasama. 00:01:31.500 --> 00:01:36.380 Salah pahaman besar adalah menganggap AI agen sebagai skrip atau makro pengembangan yang hanya mengotomatisasi tugas rutin. 00:01:36.960 --> 00:01:39.740 Padahal dalam proyek perangkat lunak nyata pekerjaan terbagi peran. 00:01:39.740 --> 00:01:47.740 Arsitek, peninjau, penguji, operator, agen dapat mencerminkan pembagian ini masing-masing menangani satu bagian siku hidup dengan ingatan dan konsistensi yang sempurna. 00:01:48.340 --> 00:01:54.200 Bayangkan satu agen yang dikhususkan untuk desain sistem, mengusulkan pola arsitektur dan kerangka kerja yang sesuai dengan tujuan bisnis. 00:01:55.200 --> 00:01:59.500 Agen lain meninjau perubahan kode, mendeteksi masalah sambil tetap memahami riwayat keseluruhan proyek. 00:01:59.500 --> 00:02:05.760 Agen ketiga dapat memperluas cakupan pengujian berdasarkan data pengguna, membuat kasus uji tanpa perlu Anda minta. 00:02:06.380 --> 00:02:12.200 Setiap agen terspesialisasi, namun mereka berkoordinasi seperti tim, selalu tersedia, konsisten, dan mudah disesuaikan tergantung beban kerja. 00:02:12.900 --> 00:02:17.680 Di saat manusia kehilangan energi, konteks, atau fokus, agen tetap stabil dan mengingat detail dengan presisi. 00:02:18.720 --> 00:02:21.320 Poin terakhir adalah perbedaan antara otomatisasi dan otonomi. 00:02:22.060 --> 00:02:23.800 Otomatisasi sudah lama ada dalam pengembangan perangkat lunak. 00:02:24.340 --> 00:02:26.640 Bayangkan skrip, pipeline CA plus CD, dan tempat. 00:02:26.940 --> 00:02:28.280 Semua untuk kaku kerancangannya. 00:02:28.280 --> 00:02:33.120 Mereka mengikuti instruksi tepat selangkah demi selangkah, tetapi rusak saat kondisi berubah secara tak terduga. 00:02:33.920 --> 00:02:35.360 Otonomi mengambil pendekatan yang berbeda. 00:02:36.180 --> 00:02:42.840 Agen AI dapat merespons perubahan secara langsung, menyesuaikan diri saat versi dependensi berubah atau mempertimbangkan ulang pilihan layanan saat kendala biaya muncul. 00:02:44.100 --> 00:02:47.680 Alih-alih mengeksekusi jalur yang telah ditentukan mereka membuat keputusan dalam kondisi yang dinamis. 00:02:48.540 --> 00:02:51.260 Ini adalah peralihan dari eksekusi statis kepemecahan masalah yang adaptif. 00:02:51.840 --> 00:02:55.040 Efek lanjutannya adalah agen-agen ini tidak lagi sekadar menunggu perintah. 00:02:55.040 --> 00:03:02.340 Mereka dapat mengusulkan solusi saat masalah muncul, menyoroti risiko sebelum masuk ke produksi, dan menyusun rencana yang menghemat waktu pengaturan berjam-jam. 00:03:03.240 --> 00:03:08.020 Jika GitHub Copilot saat ini bisa mengisi cuplikan kode, versi masa depan bertindak lebih seperti kontributor proyek, 00:03:08.620 --> 00:03:13.760 menyusun peta jalan, menyarankan strategi rilis, bahkan menandai keputusan arsitektur yang mungkin menyebabkan masalah nantinya. 00:03:13.760 --> 00:03:17.180 Itu tidak berarti setiap penyebar akan berjalan tanpa input manusia. 00:03:17.460 --> 00:03:20.160 Tetapi hal ini dapat secara signifikan mengurangi intervensi berulang, 00:03:20.440 --> 00:03:24.260 dan memberi pengembang lebih banyak waktu untuk fokus pada bagian kreatif yang berinaik tinggi dari sebuah proyek. 00:03:25.280 --> 00:03:27.260 Untuk memperjelas cara penyampaian sebelumnya di bidang ini, 00:03:27.460 --> 00:03:31.660 Alih-alih mengatakan apa yang terjadi jika penyediaan sumber daya azure sama sekali tidak membutuhkan manusia. 00:03:31.660 --> 00:03:37.420 Pernyataan yang lebih akurat adalah alat-alat ini dapat mengurangi jumlah pengaturan manual yang diperlukan 00:03:37.420 --> 00:03:39.940 sambil tetap menjaga batas pengamanan utama di bawah hendali manusia. 00:03:41.740 --> 00:03:45.640 Hasilnya tetap transformatif, tanpa menyeratkan bahwa pengawasan manusia menghilang sepenuhnya. 00:03:46.380 --> 00:03:51.040 Kesadaran yang lebih besar adalah bahwa AI Genic bukan sekadar pelakin lain yang percepat tugas di sana-sini. 00:03:51.860 --> 00:03:55.760 AI ini mulai berfungsi layaknya anggota tim sungguhan menangani pekerjaan latar belakang 00:03:55.760 --> 00:03:59.520 agar pengembang tidak terjebak mengejar detail yang bisa dilacak oleh mitra yang selalu aktif. 00:03:59.520 --> 00:04:05.340 Kapasitas seluruh tim meningkat karena domain utama memiliki agen digital yang bekerja bersama spesialis manusia. 00:04:06.420 --> 00:04:10.760 Memahami teorinya memang penting, tetapi yang benar-benar berarti adalah bagaimana hal ini terjadi di lingkungan yang familiar. 00:04:11.180 --> 00:04:12.200 Jadi inilah celah rasa yang ingin tahu kita. 00:04:12.640 --> 00:04:16.420 Apa yang sebenarnya berubah pada hari pertama, proyek baru ketika agen sudah aktif sejak awal? 00:04:17.400 --> 00:04:20.680 Selanjutnya, kita akan melihat skenario kokan di dalam ekosistem.net 00:04:20.680 --> 00:04:24.160 di mana perubahan tersebut mulai muncul bahkan sebelum Anda menulis baris kode pertama. 00:04:24.980 --> 00:04:27.200 Membayangkan kembali alur kerja pengembang di.net. 00:04:27.200 --> 00:04:31.680 Dalam pengembangan internet, perubahan yang paling terlihat dimulai dari cara proyek dimulai. 00:04:32.660 --> 00:04:36.240 Membayangkan kembali alur kerja pengembang di sini bermuara pada tiga keuntungan taktis. 00:04:37.100 --> 00:04:41.820 Ding arsitektur yang lebih cepat, kritik tingkat proyek saat Anda bekerja, dan penurunan yang nyata dalam kelelahan pengaturan. 00:04:42.760 --> 00:04:44.020 Pertama adalah scaffolding yang lebih cepat. 00:04:44.740 --> 00:04:47.400 Daripada membuka visual studio dan menatap solusi kosong, 00:04:47.700 --> 00:04:51.260 agen AI dapat mengusulkan opsi arsitektur yang sesuai dengan kebutuhan spesifik Anda. 00:04:51.260 --> 00:04:53.860 Saat menencanakan web api dengan pembaruan real-time, 00:04:54.160 --> 00:04:58.360 agen menyarankan desain berlapis yang bersih dan menunjukkan bagaimana signal R dapat masuk ke dalam alur tersebut. 00:04:58.780 --> 00:05:01.800 Untuk aplikasi keuangan, ia menyiapkan entity framework dengan keamanan tipi yang kuat 00:05:01.800 --> 00:05:04.520 dan integrasi Azure Active Directory bahkan sebelum Anda membuat satu folder pun. 00:05:04.880 --> 00:05:06.140 Bahkan sebelum Anda membuat satu folder pun. 00:05:06.440 --> 00:05:11.080 Hal yang biasanya memakan waktu diskusi atau berjam-jam riset kini diringkas menjadi beberapa titik awal yang telah disesuaikan. 00:05:11.380 --> 00:05:12.620 Namun ini bukanlah cetak biru final. 00:05:13.020 --> 00:05:13.480 Ini anilet. 00:05:13.920 --> 00:05:16.760 Tim harus memvalidasi setiap saran dengan menjalankan daftar periksa singkat. 00:05:16.760 --> 00:05:18.940 Apakah autentikasi sudah memiliki persyaratan? 00:05:19.460 --> 00:05:20.500 Apakah login sudah terhubungan? 00:05:20.660 --> 00:05:22.020 Apakah kasus uji dasar sededek? 00:05:22.940 --> 00:05:25.880 Tata kelola yang ringan tersebut memastikan kecepatan tidak mengorbankan stabilitas. 00:05:26.520 --> 00:05:28.040 Keuntungan kedua adalah kritik yang berlanjut. 00:05:29.040 --> 00:05:30.660 Anggap ini bukan sebagai pelengkap kode, 00:05:31.000 --> 00:05:33.320 melainkan sebagai penasihat yang menjaga keselarasan desain. 00:05:34.380 --> 00:05:36.520 Jika Anda membuat pola repository untuk akses data, 00:05:36.520 --> 00:05:39.820 agen akan menandai jika Anda mulai melenceng dari pemisahan fungsi separation of concern. 00:05:40.200 --> 00:05:41.480 Saat menambahkan pengontrol baru, 00:05:41.600 --> 00:05:45.520 ia mengusulkan unit tes yang sesuai atau menyoroti ketidak konsistenan dengan bagian proyek lainnya. 00:05:45.520 --> 00:05:47.760 Alih hanya memberikan boilerplate, 00:05:48.200 --> 00:05:51.500 ia mendorong bentuk sistem Anda ke arah pola yang sudah dipelihara di setiap komit. 00:05:52.240 --> 00:05:53.400 Untuk eksperimen praktis, 00:05:53.560 --> 00:05:57.780 cobalah mengaktifkan copilot di Visual Studio pada prototipe kecil ASPAT & NETCORE. 00:05:58.680 --> 00:06:01.860 Kemudian bandingkan berapa lama waktu yang dibutuhkan untuk melayani permintaan pertama, 00:06:01.860 --> 00:06:05.480 satu endpoint dengan autentikasi dan penyimpanan data dibandingkan melakukannya secara menuang. 00:06:06.060 --> 00:06:07.480 Ini bukan jaminan penghematan waktu, 00:06:07.780 --> 00:06:11.480 tetapi menjalankan latihan berdampingan di lingkungan Anda sendiri seringkali menjadi cara tercepat 00:06:11.480 --> 00:06:13.940 untuk mengukur apakah agen ini memberikan dampak nyata. 00:06:13.940 --> 00:06:16.960 Keuntungan ketiga adalah perkurangnya pengaturan dan beban kognit. 00:06:17.860 --> 00:06:20.400 Banyak pekerjaan awal proyek bersifat repetitif, 00:06:20.480 --> 00:06:21.560 seperti menghubungkan middleware, 00:06:21.660 --> 00:06:23.180 autentikasi, menarik paket Nougat, 00:06:23.320 --> 00:06:24.780 mengatur logging dengan application insights, 00:06:24.940 --> 00:06:25.960 dan menulis pipeline YAML. 00:06:26.760 --> 00:06:28.800 Agen dapat langsung membuat kerangka bagian-bagian tersebut, 00:06:28.800 --> 00:06:31.860 termasuk step integrasi uji yang mengetahui dependensi apa saja yang tersedia. 00:06:32.260 --> 00:06:33.600 Hal ini tidak menghilangkan kendali Anda, 00:06:33.760 --> 00:06:35.260 tetapi mengalihkan kemana energi Anda digunakan. 00:06:35.440 --> 00:06:37.720 Daripada berkutat dengan file konfigurasi sepanjang hari, 00:06:38.080 --> 00:06:40.940 Anda menghabiskan waktu untuk menerapkan logika bisnis yang benar-benar penting. 00:06:40.940 --> 00:06:43.660 Kelelahan akibat pekerjaan pengaturan akan hilang 00:06:43.660 --> 00:06:46.740 memberikan ruang bagi keputusan desain kreatif daripada tugas-tugas mekanis. 00:06:47.320 --> 00:06:50.220 Hal yang membedakannya dari otomatisasi tradisional adalah fleksibilitasnya. 00:06:50.760 --> 00:06:52.680 Templat proyek memberikan Anda pengaturan default yang start. 00:06:53.340 --> 00:06:56.260 Agen menyesuaikan kerangkanya berdasarkan tujuan bisnis yang Anda tetapkan. 00:06:56.500 --> 00:06:58.660 Jika Anda membangun aplikasi kolaborasi, 00:06:58.780 --> 00:07:02.100 strategi cacing seperti redis dan desain berbasis event dengan Azure Service Bus 00:07:02.100 --> 00:07:03.520 akan muncul dalam rencana kerangka kerja. 00:07:04.120 --> 00:07:05.880 Jika Anda beralih ke beban kerja terjadwal, 00:07:06.020 --> 00:07:08.460 layanan latar belakang dan pengurusan antren akan muncul sebagainya. 00:07:08.460 --> 00:07:11.660 Responsifitas tersebut membedakan AI agen dari sekadar skrip 00:07:11.660 --> 00:07:14.500 menawarkan rekomendasi yang mencerminkan peran anggota tim senior 00:07:14.500 --> 00:07:16.120 dalam membantu memandu keputusan awal. 00:07:16.880 --> 00:07:18.860 Kontras dengan penggunaan copilot saat ini sangatlah jelas. 00:07:19.460 --> 00:07:21.700 Saat ini, kebanyakan pengembang melihatnya sebagai cara 00:07:21.700 --> 00:07:23.840 untuk mempercepat sintaks umum atau kode boilerplate. 00:07:24.280 --> 00:07:25.340 Mereka mengajukan pertanyaan. 00:07:25.440 --> 00:07:26.460 Alat tersebut melengkapi barisku. 00:07:27.160 --> 00:07:28.160 Dengan kemampuan agen, 00:07:28.460 --> 00:07:30.280 alat tersebut mulai memperisaran di tingkat sistem, 00:07:30.620 --> 00:07:32.060 menawarkan alternatif yang sedar konteks, 00:07:32.120 --> 00:07:34.360 dan menampilkan pertukaran yang lebih awal dalam siklus. 00:07:34.360 --> 00:07:37.220 Ompatannya adalah di sekadar membuat cuplikan kode 00:07:37.220 --> 00:07:39.000 menjadi mengkurasi desain yang bisa diterapkan. 00:07:39.660 --> 00:07:41.520 Dan itu mengubah tidak hanya cara kode ditulis, 00:07:41.660 --> 00:07:43.780 tetapi bagaimana tim bingkai keseluruhan solusi 00:07:43.780 --> 00:07:45.440 sebelum mereka berkomitmen pada satu arah. 00:07:46.260 --> 00:07:48.360 Semua ini tidak menghilangkan kebutuhan akan penilaian manusia. 00:07:49.040 --> 00:07:50.520 Agen dapat menyarankan kerangka kerja, 00:07:50.620 --> 00:07:51.500 dependensi, dan praktek, 00:07:51.600 --> 00:07:53.200 tetapi verifikasinya tetap menjadi tanggung. 00:07:53.900 --> 00:07:55.780 Anggap setiap rekomendasi sebagai draft proposal. 00:07:56.480 --> 00:07:58.220 Terima bagian yang selaras dengan standar Anda, 00:07:58.220 --> 00:07:59.320 revisi yang tidak sesuai, 00:07:59.440 --> 00:08:01.720 dan ambil pelajaran untuk iterasi proyek berikutnya. 00:08:01.720 --> 00:08:04.480 AI menangani pekerjaan berat yang repetitif, 00:08:04.560 --> 00:08:05.760 sementara anggota tim tetap fokus 00:08:05.760 --> 00:08:07.720 menjelaraskan pilihan teknologi dengan strategi. 00:08:08.140 --> 00:08:09.700 Sejauh ini, kita telah melihat bagaimana 00:08:09.700 --> 00:08:11.480 agen membentuk kembali pengalaman pungkodean. 00:08:11.920 --> 00:08:12.900 Di dalam internet itu sendiri, 00:08:13.040 --> 00:08:14.580 tetapi keterlibatan agen tidak berakhir 00:08:14.580 --> 00:08:16.220 pada desain solusi atau perancah proyek. 00:08:16.860 --> 00:08:17.940 Setelah dasar-dasarnya siap, 00:08:18.040 --> 00:08:20.080 kecerdasan yang sama mulai meluas kepenyediaan, 00:08:20.400 --> 00:08:22.120 penyebaran, dan pengolahan infrastruktur 00:08:22.120 --> 00:08:23.600 yang diandalkan aplikasi tersebut. 00:08:24.540 --> 00:08:26.560 Disitulah transformasi besar lain yang mulai terbentuk 00:08:26.560 --> 00:08:28.540 dan tidak terbatas pada alur kerja pengembang lokal. 00:08:28.540 --> 00:08:30.780 Ini tentang lingkungan cloud yang melingkupinya. 00:08:32.260 --> 00:08:33.880 Agen cloud yang menjalankan Azure dengan autopilot. 00:08:34.420 --> 00:08:36.120 Jadi, mari kita alihkan fokus ke apa yang terjadi 00:08:36.120 --> 00:08:37.400 ketika manajemen Azure itu sendiri 00:08:37.400 --> 00:08:39.320 mulai berjalan dengan autopilot berkat bantuan agen. 00:08:40.080 --> 00:08:41.920 Cara awal diskusi ini dibingkai seringkali terdengar 00:08:41.920 --> 00:08:42.780 seperti fiksi ilmiah. 00:08:42.780 --> 00:08:44.720 Apa yang terjadi ketika penyediaan sumber daya Azure 00:08:44.720 --> 00:08:46.480 sama sekali tidak membutuhkan manusia dalam prosesnya? 00:08:47.640 --> 00:08:49.780 Cara yang lebih baik untuk memikirkannya adalah seperti ini. 00:08:50.480 --> 00:08:52.140 Apa yang terjadi ketika penyediaan rutin 00:08:52.140 --> 00:08:53.140 dan deteksi penyimpangan 00:08:53.140 --> 00:08:54.920 memerlukan lebih sedikit intervensi manual 00:08:54.920 --> 00:08:56.620 karena agen mengelola tugas berulang 00:08:56.620 --> 00:08:57.920 di bawah batasan yang ditentukan? 00:08:58.540 --> 00:09:00.180 Pergeseran itu penting 00:09:00.180 --> 00:09:01.700 karena ini bukan tentang menyingkirkan orang 00:09:01.700 --> 00:09:03.500 melainkan tentang mengalihkan pekerjaan repetitif 00:09:03.500 --> 00:09:04.720 sambil tetap menjaga pengawasan. 00:09:05.220 --> 00:09:07.120 Jika Anda pernah membangun lingkungan Azure yang serius 00:09:07.120 --> 00:09:08.980 Anda sudah tahu betapa berantakannya hal itu. 00:09:09.640 --> 00:09:12.320 Anda harus berjibaku dengan template, script, dan nyamal pipeline 00:09:12.320 --> 00:09:14.500 sambil berpindah-pindah antara perintah CLE 00:09:14.500 --> 00:09:16.340 demi kecepatan dan portal untuk pengecualian. 00:09:17.160 --> 00:09:18.660 Setiap jalan pintas menjadi utang teknis 00:09:18.660 --> 00:09:19.440 yang menunggu untuk muncul. 00:09:20.200 --> 00:09:22.000 VM yang dibiarkan menyala di luar jam kerja 00:09:22.000 --> 00:09:23.300 biaya membengkak tanpa disadari 00:09:23.300 --> 00:09:25.160 atau akun penyimpanan kerekspo saat seharusnya tidak. 00:09:25.160 --> 00:09:28.980 Dan dalam operasi kelaut, kesalahan kecil sekalipun menciptakan masalah besar. 00:09:29.860 --> 00:09:32.020 Tagihan yang melonjak, wilayah yang melemahkan ketahanan 00:09:32.020 --> 00:09:34.580 atau kesenjangan kepatuhan yang Anda temukan pada waktu yang paling buruk. 00:09:35.560 --> 00:09:37.680 Ini adalah tinitas yang dihindari oleh kebanyakan tim 00:09:37.680 --> 00:09:40.500 dan disinilah agen mulai terasa seperti teknisi deployment autonom. 00:09:40.500 --> 00:09:41.680 Ide-nya sederhana. 00:09:42.200 --> 00:09:44.820 Anda memberikan tujuan tingkat bisnis, persyaratan kinerja, 00:09:44.980 --> 00:09:47.740 kebutuhan pemulihan, aturan kepatuhan, toleransi anggaran, 00:09:48.060 --> 00:09:51.060 dan agen menerjemahkannya tersebut menjadi konfigurasi infrastruktur. 00:09:52.060 --> 00:09:53.620 Alih-alih berpindah antar banyak konsol 00:09:53.620 --> 00:09:54.960 atau menyambungkan ID secara manual, 00:09:55.100 --> 00:09:57.520 Anda melihat template IISC yang sudah diselaraskan dengan tujuan Anda. 00:09:58.540 --> 00:10:00.320 Selanjutnya, agen yang sama terus memantau. 00:10:00.760 --> 00:10:02.140 Menjalankan pemeriksaan kepatuhan. 00:10:02.540 --> 00:10:04.540 Menimbulasikan kemungkinan kesalahan konfigurasi 00:10:04.540 --> 00:10:07.220 dan menerapkan perbaikan sebelum masalah meluas ke produksi. 00:10:07.220 --> 00:10:10.780 Perbedaan dari otomatisasi yang ada terletak pada kemampuan adaptasi. 00:10:11.480 --> 00:10:15.060 Pipeline CI persidih normal menganggap definisi IAML Anda sebagai aturan mutlak. 00:10:16.000 --> 00:10:17.880 Semua berjalan lancar sampai kenyataan berubah, 00:10:18.080 --> 00:10:19.220 ada pembaruan dependensi, 00:10:19.380 --> 00:10:21.520 lonjakan permintaan mendadak atau mandat kepatuhan baru, 00:10:21.700 --> 00:10:23.080 lalu instruksi statis itu rusak 00:10:23.080 --> 00:10:24.680 atau memproses sesuatu yang terlihat valid 00:10:24.680 --> 00:10:26.480 tetapi tidak memenuhi kebutuhan bisnis. 00:10:27.460 --> 00:10:29.320 Pipeline berbasis agen berperilaku berbeda. 00:10:29.320 --> 00:10:31.560 Akin menganggap definisi tersebut sebagai dasar 00:10:31.560 --> 00:10:33.160 tetapi memperbarunya saat kondisi berubah. 00:10:33.820 --> 00:10:35.780 Alih-alih menunggu seseorang untuk menskalakan layanan 00:10:35.780 --> 00:10:37.320 atau menyesuaikan distribusi regional 00:10:37.320 --> 00:10:39.080 agar memperhatikan pola beban, 00:10:39.340 --> 00:10:41.020 memprediksi ambang batas yang mungkin terjadi, 00:10:41.340 --> 00:10:43.160 dan menyediakan kapasitas tambahan sebelumnya. 00:10:44.260 --> 00:10:46.980 Adaptabilitas tersebut membuat skenario jadi lebih minim kesalahan dalam praktik. 00:10:47.280 --> 00:10:49.800 Bayangkan sebuah aplikasi internet yang melayani lalu lintas bagian besar. 00:10:50.360 --> 00:10:52.460 Seminggu kemudian, pengguna baru muncul di Eropa. 00:10:53.040 --> 00:10:53.800 Latensi meningkat, 00:10:53.980 --> 00:10:56.320 tetapi tidak ada yang memperhitungkan wilayah lain dalam IAML Asli. 00:10:56.940 --> 00:10:58.280 Otomatisasi tradisional mengembaikan. 00:10:58.780 --> 00:11:00.640 Anda baru menyadarinya setelah keluhan dan log muncul. 00:11:00.640 --> 00:11:02.960 Sebaliknya, agen menandai pola tersebut, 00:11:03.060 --> 00:11:04.240 menyebarkan replika di Eropa, 00:11:04.560 --> 00:11:06.840 dan segera mengonfigurasi perutean melalui Azure Front Door. 00:11:07.300 --> 00:11:08.860 Agen tidak hanya menyebarkan lalu pergi begitu saja. 00:11:09.180 --> 00:11:11.000 Agen terus menyelaraskan sumber daya dengan niat. 00:11:11.840 --> 00:11:14.060 Hampir seperti operator 24.7 yang tidak pernah lelah. 00:11:14.500 --> 00:11:16.140 Manfaat nyata melampaui sekadar penskalaan. 00:11:16.980 --> 00:11:18.880 Keamanan dan kepatuhan dibangun ke dalam siklus tersebut. 00:11:19.480 --> 00:11:21.640 Itu bisa berupa agen yang mengamati kontener penyimpanan 00:11:21.640 --> 00:11:22.760 yang terekspos tanpa sengaja, 00:11:22.760 --> 00:11:24.580 lalu menguncinya secara otomatis 00:11:24.580 --> 00:11:26.800 atau mendeteksi penyimpanan pada basis data patch VM 00:11:26.800 --> 00:11:28.300 dan mengembalikannya ke posisi semula. 00:11:28.300 --> 00:11:31.220 Ini adalah tugas frekuensi tinggi dengan visibilitas rendah 00:11:31.220 --> 00:11:32.840 yang biasanya baru diketahui manusia nanti 00:11:32.840 --> 00:11:34.020 dan setelah melalui banyak upaya. 00:11:34.900 --> 00:11:36.340 Dengan mendorongnya ke siklus berkelanjutan, 00:11:36.480 --> 00:11:38.140 Anda tidak menghilangkan operator Anda mebebaskan. 00:11:38.440 --> 00:11:38.740 Mereka. 00:11:39.680 --> 00:11:41.560 Alih-alih menghabiskan energi untuk memadamkan masalah, 00:11:41.680 --> 00:11:43.720 mereka fokus pada pencanaan dan strategi tingkat yang lebih tinggi. 00:11:44.040 --> 00:11:46.420 Dan itu adalah nuansa yang pengawasan manusia tidak hilang. 00:11:46.880 --> 00:11:49.080 Peran Anda berubah dari memperiksa kotak baris demi baris 00:11:49.080 --> 00:11:50.800 menjadi mendefinisikan pedoman sejak awal. 00:11:51.740 --> 00:11:52.780 Wilayah mana yang diizinkan? 00:11:53.100 --> 00:11:53.880 Biaya mana yang dapat diterima? 00:11:54.040 --> 00:11:55.800 Standar kepatuhan mana yang tidak boleh dilanggar? 00:11:56.300 --> 00:11:56.480 Mar. 00:11:56.480 --> 00:11:59.540 Langkah praktis begitu manapun yang ingin menguji ini adalah 00:11:59.540 --> 00:12:01.580 dengan menetapkan batasan kebijakan sejahat ini. 00:12:02.040 --> 00:12:04.380 Tetapkan plafon biaya, tentukan wilayah yang disetujui 00:12:04.380 --> 00:12:05.620 dan tambahkan batas yang kepatuhan. 00:12:06.540 --> 00:12:08.000 Akan kemudian bertindak sebagai penegak, 00:12:08.140 --> 00:12:09.420 bukan operator tanpa batas. 00:12:09.880 --> 00:12:10.700 Itulah prinsip dasarnya. 00:12:11.360 --> 00:12:13.420 Anda tetap memegang kendali atas arah strategi 00:12:13.420 --> 00:12:15.840 sementara agen menjalankan detail perlindungan dalam skala besar. 00:12:16.260 --> 00:12:17.900 Ini juga bukan berarti Anda menyerahkan produksi 00:12:17.900 --> 00:12:19.040 ke tangan agen pada hari pertama. 00:12:19.640 --> 00:12:20.680 Jika Anda menghindari risiko, 00:12:20.820 --> 00:12:22.080 mulailah di lingkungan uji yang terkendali. 00:12:22.880 --> 00:12:24.860 Berikan beban kerja yang tidak kritis kepada agen 00:12:24.860 --> 00:12:27.040 atau pilih satu layanan seperti infrastruktur penyimpanan 00:12:27.040 --> 00:12:28.820 atau logging dan biarkan agen mengelola drift 00:12:28.820 --> 00:12:29.860 serta provisioning di sana. 00:12:30.520 --> 00:12:32.040 Dengan cara ini, Anda membangun kepercayaan 00:12:32.040 --> 00:12:33.480 terhadap cara agen menafsirkan batasan 00:12:33.480 --> 00:12:34.380 sebelum memperluas jangkauannya. 00:12:35.140 --> 00:12:36.960 Anggap ini sebagai menjalankan proyek percontohan 00:12:36.960 --> 00:12:38.560 dengan cukupan yang jelas dan risiko rendah. 00:12:38.800 --> 00:12:40.700 Persis seperti cara sebagian besar praktek DevOps 00:12:40.700 --> 00:12:41.500 yang andal berkembang. 00:12:41.500 --> 00:12:44.740 Pada intinya, pendekatan agen untuk Azure IRC 00:12:44.740 --> 00:12:46.860 tidak seperti menulis lusinan skrip statis, 00:12:47.020 --> 00:12:48.720 melainkan mengelola daftar periksa yang dinamis. 00:12:49.780 --> 00:12:50.560 Hasilkan templat, 00:12:50.880 --> 00:12:52.280 jalankan pemeriksaan prapenyebaran, 00:12:52.480 --> 00:12:53.840 pantau drift, dan usulkan perbaikan. 00:12:54.040 --> 00:12:55.780 Semuanya di bawah batasan yang Anda konfigurasi. 00:12:56.780 --> 00:12:58.500 Pendekatan ini cukup terstruktur untuk dipercaya, 00:12:58.600 --> 00:12:59.740 namun cukup fleksibel untuk berkembang 00:12:59.740 --> 00:13:00.460 saat kondisi berubah. 00:13:01.240 --> 00:13:03.260 Tentu saja, penyediaan dan penskalaan infrastruktur 00:13:03.260 --> 00:13:04.540 hanyalah satu sisi dari keandalan. 00:13:05.300 --> 00:13:07.020 Masalah yang lebih sulit seringkali muncul kemudian. 00:13:07.320 --> 00:13:08.780 Itu memastikan kode yang Anda sebarkan 00:13:08.780 --> 00:13:10.340 kelingkungan tersebut benar-benar bertahan 00:13:10.340 --> 00:13:11.300 dalam kondisi dunia nyata. 00:13:12.200 --> 00:13:13.440 Dan disitulah tantangan berikutnya 00:13:13.440 --> 00:13:13.940 mau yang muncul, 00:13:14.120 --> 00:13:16.080 yaitu masalah menangkap bug yang tidak dilihat manusia 00:13:16.080 --> 00:13:17.800 sampai bug tersebut sudah ada di produksi. 00:13:18.860 --> 00:13:20.700 Pengujian otonom bug yang terdapatkan oleh manusia. 00:13:21.240 --> 00:13:23.520 Pengujian hanya mencakup apa yang dapat dipikirkan manusia. 00:13:23.820 --> 00:13:24.960 Dan itulah batasan utamanya. 00:13:25.380 --> 00:13:26.540 Sebagian besar kegagalan produksi 00:13:26.540 --> 00:13:28.080 tidak berasal dari apa yang diantisipasi, 00:13:28.220 --> 00:13:30.260 tetapi dari apa yang luput dari imajinasi manusia. 00:13:30.920 --> 00:13:32.680 Agen pengujian otonom mengisi celah ini 00:13:32.680 --> 00:13:34.080 dengan berfokus pada kasus tepi 00:13:34.080 --> 00:13:35.940 dan kondisi dinamis yang tidak akan pernah masuk 00:13:35.940 --> 00:13:37.280 ke dalam rangkaian pengujian biasa. 00:13:38.780 --> 00:13:41.800 Aplikasi .net diajur mungkin berkinerja sempurna 00:13:41.800 --> 00:13:43.640 di bawah beban berat selama uji stres terencana, 00:13:43.780 --> 00:13:46.120 tetapi perkenalkan peristiwa penskalaan, 00:13:46.300 --> 00:13:47.900 instans baru yang aktif di tengah lalu lintas, 00:13:48.100 --> 00:13:49.760 dan tiba-tiba kesalahan penanganan sesi muncul. 00:13:50.460 --> 00:13:51.780 Kecuali seseorang merancang tes kursus 00:13:51.780 --> 00:13:52.720 untuk tumpang tindi tersebut, 00:13:52.840 --> 00:13:53.980 hal itu akan luput dari perhatian. 00:13:54.760 --> 00:13:56.360 Agen otonom mendeteksi anomali tersebut, 00:13:56.460 --> 00:13:56.960 mengisolasinya, 00:13:57.160 --> 00:13:59.200 dan membuat tes regresi baru di sekitar kondisi tersebut. 00:13:59.780 --> 00:14:00.940 Lain kali saat penskalaan terjadi, 00:14:01.020 --> 00:14:01.860 pengaman itu sudah ada, 00:14:02.040 --> 00:14:03.880 mengubah apa yang tadinya merupakan risiko tersembunyi 00:14:03.880 --> 00:14:04.920 menjadi skenario yang dipantau. 00:14:05.260 --> 00:14:06.520 Contoh lainnya adalah mutasi input. 00:14:07.220 --> 00:14:09.040 Penguji manusia biasanya mendesain dengan data yang aman 00:14:09.040 --> 00:14:10.020 atau dapat diprediksi. 00:14:10.940 --> 00:14:11.760 Nama pengguna yang valid, 00:14:12.220 --> 00:14:13.140 payload API yang benar, 00:14:13.260 --> 00:14:14.980 atau kasus tepi yang jelas seperti string kosong. 00:14:16.060 --> 00:14:16.540 Sebaliknya, 00:14:16.700 --> 00:14:17.900 agen mulai bereksperimen 00:14:17.900 --> 00:14:19.980 dengan variasi yang tidak terpikirkan oleh pengembang. 00:14:20.680 --> 00:14:21.760 Permintaan yang terlalu besar, 00:14:22.000 --> 00:14:22.680 pengodean aneh, 00:14:23.000 --> 00:14:24.640 jeda tipis di antara panggilan multilangkah. 00:14:25.440 --> 00:14:26.040 Dengan melakukan itu, 00:14:26.040 --> 00:14:27.980 agen dapat micu kegagalan yang akan terawatkan sepenuhnya 00:14:27.980 --> 00:14:28.920 oleh rangkaian pengujian manual. 00:14:29.240 --> 00:14:30.480 Nilainya bukan hanya pada kecepatan, 00:14:30.540 --> 00:14:31.260 tetapi pada keagaman. 00:14:31.260 --> 00:14:34.240 Agen menjelajahi sudut-sudut aneh ruang input lebih cepat 00:14:34.240 --> 00:14:36.540 daripada kasus yang ditulis oleh manusia. 00:14:37.040 --> 00:14:38.160 Apa yang mendapatkan pergeseran ini 00:14:38.160 --> 00:14:39.360 dari otomatisasi tradisional 00:14:39.360 --> 00:14:40.840 adalah cara rangkaian pengujian berkembang. 00:14:41.140 --> 00:14:43.180 Paket regresi yang dirancang oleh manusia 00:14:43.180 --> 00:14:44.080 cenderung statis. 00:14:44.680 --> 00:14:46.340 Ini mencerminkan pengetahuan dan asumsi tim 00:14:46.340 --> 00:14:47.240 pada saat tertentu. 00:14:48.340 --> 00:14:49.960 Agen mengubahnya menjadi proses yang berkeluar. 00:14:50.520 --> 00:14:52.540 Mereka memperluas rangkaian saat sistem berubah, 00:14:52.540 --> 00:14:54.400 selalu mencari kondisi yang belum terpikirkan. 00:14:55.700 --> 00:14:57.040 Alih-alih pengembang bersusah payah 00:14:57.040 --> 00:14:59.040 memperbarui skrip yang rapuh setelah setiap iterasi. 00:14:59.040 --> 00:15:00.980 Kasus baru dihasilkan secara dinamis 00:15:00.980 --> 00:15:02.480 dari pengamatan nyata perilaku sistem. 00:15:03.680 --> 00:15:04.740 Namun, ada catatan penting. 00:15:05.360 --> 00:15:06.960 Tidak setiap tes yang dihasilkan agen layak 00:15:06.960 --> 00:15:08.280 dimasukkan ke dalam rangkaian permainan. 00:15:08.880 --> 00:15:10.380 Tes yang tidak stabil atau tidak relevan 00:15:10.380 --> 00:15:11.960 dapat menumpuk dengan cepat membuang waktu 00:15:11.960 --> 00:15:13.560 dan merusak percayaan pada otomatisasi. 00:15:14.160 --> 00:15:15.180 Itulah mengapa tata klubur penting. 00:15:15.560 --> 00:15:16.640 Tim membutuhkan proses penjauan. 00:15:17.000 --> 00:15:18.260 Pemembang atau insinyur QA 00:15:18.260 --> 00:15:19.980 harus memvalidasi setiap usulan tes 00:15:19.980 --> 00:15:21.440 untuk stabilitas dan relevansi bisnis 00:15:21.440 --> 00:15:23.940 sebelum memindahkannya ke paket regresi yang stabil. 00:15:24.900 --> 00:15:26.160 Seperti otomatisasi lainnya, 00:15:26.160 --> 00:15:28.840 pengawasan memastikan alat ini meningkatkan keandalan alih-alih 00:15:28.840 --> 00:15:30.920 menenggelamkan tim dalam kebisingan. 00:15:31.680 --> 00:15:33.180 Kesalahpahaman lain yang perlu diluruskan 00:15:33.180 --> 00:15:35.040 adalah gagasan bahwa agen memperbaiki bug. 00:15:35.600 --> 00:15:37.000 Mereka tidak menulis ulang kode produksi 00:15:37.000 --> 00:15:38.200 atau menambah kekurangan secara manis. 00:15:38.460 --> 00:15:39.940 Yang mereka lakukan dengan sangat baik adalah 00:15:39.940 --> 00:15:41.620 memunculkan skenario yang dapat direproduksi 00:15:41.620 --> 00:15:42.880 dengan detail diagnostik yang jelas. 00:15:43.400 --> 00:15:45.140 Bagi pengembang, memiliki serangkaian langkah 00:15:45.140 --> 00:15:46.540 yang ditangkap agen membuat perbedaan 00:15:46.540 --> 00:15:47.720 antara berjam-jam menebak-nebak 00:15:47.720 --> 00:15:48.440 dan penyelesaian cepat. 00:15:48.880 --> 00:15:50.820 Dalam beberapa kasus, agen dapat menyarankan 00:15:50.820 --> 00:15:52.760 kemungkinan perbaikan berdasarkan pola yang diketahui 00:15:52.760 --> 00:15:55.200 namun keputusan akhir dan perubahan tetap di tangan manusia. 00:15:55.960 --> 00:15:57.780 Dilihat dari cara ini, pembagian kerja menjadi berbersih. 00:15:58.360 --> 00:15:59.300 Mesin melakukan penemuan, 00:15:59.420 --> 00:16:00.880 manusia melakukan penilaian dan perbaikan. 00:16:01.400 --> 00:16:03.360 Dampak bisnis di sini adalah berkurangnya pemadaman kebakaran. 00:16:04.220 --> 00:16:06.220 Tim melihat lebih sedikit tiket larut malam, 00:16:06.560 --> 00:16:08.560 lebih sedikit regresi yang muncul kembali setelah rilis 00:16:08.560 --> 00:16:11.080 dan penurunan waktu yang signifikan untuk reproduksi langkah. 00:16:12.640 --> 00:16:14.680 Keanahan kinerja tertangkap di lingkungan terpendali 00:16:14.680 --> 00:16:16.940 bukan muncul pertama kali di depan pengguna akhir. 00:16:17.660 --> 00:16:19.680 Kesalahan keamanan terungkap saat pengujian internal. 00:16:20.300 --> 00:16:22.420 Bukan setelah pemindahan kepatuan atau latihan penetrasi. 00:16:23.220 --> 00:16:24.820 Pergeseran itu membuka ruang bagi QIA 00:16:24.820 --> 00:16:26.260 untuk fokus pada pertanyaan tingkat tinggi 00:16:26.260 --> 00:16:28.940 seperti kegunaan, kelancaran alur kerja, dan aksesibilitas. 00:16:29.720 --> 00:16:31.920 Ada yang tidak dapat dinilai secara berarti oleh mesin otonom mana pun. 00:16:32.620 --> 00:16:33.860 Bagi praktisi yang tertarik mencoba, 00:16:34.000 --> 00:16:34.940 mulai latihan yang kecil. 00:16:35.800 --> 00:16:38.380 Jalankan agen pengujian otonom terhadap lingkungan staging 00:16:38.380 --> 00:16:40.440 atau preproduksi selama durasi yang ditentukan. 00:16:41.640 --> 00:16:44.160 Bandingkan daftar masalah yang ditemukannya dengan backlog Anda saat ini. 00:16:44.820 --> 00:16:46.060 Anggap latihan ini sebagai pengumpulan data. 00:16:46.620 --> 00:16:47.800 Apakah teman baru tersebut benar-benar belum? 00:16:48.140 --> 00:16:49.540 Apakah mereka tempat tinggi dengan teks yang art? 00:16:49.540 --> 00:16:51.780 Apakah mengungkapkan titik buta yang penting bagi bisnis Anda? 00:16:52.400 --> 00:16:54.660 Dengan cara ini, Anda mengukur laba atas investasi, 00:16:54.960 --> 00:16:57.760 bukan mempertaruhkan kualitas rilis Anda pada teknik yang belum terbukti. 00:16:58.140 --> 00:17:00.440 Dan ketika tim menjalankan proyek percontohan semacam ini, 00:17:00.560 --> 00:17:01.480 sebuah pola pun muncul. 00:17:02.040 --> 00:17:04.640 Manfaat jangka panjangnya sebenarnya bukan hanya menangkap lebih banyak bug, 00:17:04.720 --> 00:17:07.000 tetapi seberapa cepat pelajaran tersebut dapat diumparkan kembali 00:17:07.000 --> 00:17:08.460 ke dalam siklus pengembangan yang lebih luas. 00:17:09.480 --> 00:17:11.800 Setiap anomali yang ditangkap, setiap wawasan yang dicatat, 00:17:11.880 --> 00:17:14.020 mewakili pengetahuan yang tidak seharusnya hilang di akhir sprint. 00:17:14.020 --> 00:17:18.280 Pertanyaannya adalah bagaimana kecerdasan itu disimpan, dibagikan, dan diteruskan, 00:17:18.500 --> 00:17:21.580 agar kesalahan yang sama tidak terulang dengan nama, proyek yang berbeda. 00:17:22.780 --> 00:17:24.120 Menutup siklus kecerdasan dalam DevOps 00:17:24.120 --> 00:17:27.180 Dalam DevOps, salah satu masalah tersulung untuk dipecahkan adalah 00:17:27.180 --> 00:17:28.400 betapa cepatnya pengetahuan sprint. 00:17:29.660 --> 00:17:31.180 Masalah dicatat post-mortem ditulis, 00:17:31.300 --> 00:17:33.000 namun saat proyek berikutnya dimulai, 00:17:33.160 --> 00:17:35.420 banyak dari pelajaran tersebut tidak kembali ke dalam alur kerja. 00:17:36.020 --> 00:17:39.280 Menutup siklus kecerdasan dalam DevOps berarti menghentikan siklus kehilangan tersebut 00:17:39.280 --> 00:17:42.160 dan memastikan apa yang dipelajari T benar-benar meningkatkan apa yang akan datang. 00:17:43.000 --> 00:17:44.940 AI agen mendukung hal ini dengan terhubung ke tempat 00:17:44.940 --> 00:17:46.440 di mana pengetahuan sudah mengalir. 00:17:47.360 --> 00:17:49.620 Titik integrasi pertama adalah menyerap log dan termetrik. 00:17:50.640 --> 00:17:53.640 Alih-alih meminta insinyur menyisir dasmur atau insiden yang diarsipkan, 00:17:53.820 --> 00:17:56.680 agen terus memindai metrik tingkat kesalahan dan jejak kinerja 00:17:56.680 --> 00:17:59.360 menghubungkan anomali di seluruh rilis. 00:18:00.160 --> 00:18:03.120 Yang kedua adalah menganalisis rewired pull request dan tinjauan kode. 00:18:03.760 --> 00:18:06.100 Keputusan yang dibuat dalam komentar seringkali berisi konteks 00:18:06.100 --> 00:18:08.860 tentang pertimbangan atau risiko yang tidak pernah masuk ke dalam dokumentasi. 00:18:09.280 --> 00:18:11.020 Dengan memproses percakapan tersebut, 00:18:11.140 --> 00:18:13.860 agen menestarikan alasan mengapa sesuatu terjadi bukan hanya apa yang digabung. 00:18:14.620 --> 00:18:17.460 Yang ketiga adalah mempetakan kegagalan yang diamati kerekomenasi arsitek. 00:18:18.020 --> 00:18:21.020 Jika strategi cacing tertentu berulang kali menyebabkan pembengkakan memori 00:18:21.020 --> 00:18:22.900 atau jika pola penskalaan memicu waktu habis, 00:18:23.000 --> 00:18:24.760 wawasan tersebut dimunculkan selama perencanaan 00:18:24.760 --> 00:18:27.200 sebelum keselama perencanaan sebelum kesalam sistem ber. 00:18:28.120 --> 00:18:30.720 Bersama-sama titik integrasi ini meningkatkan memori institusional 00:18:30.720 --> 00:18:31.920 tanpa menjanjikan kesempurna. 00:18:32.740 --> 00:18:35.160 Nilainya bukan karena agen dengan sempurna mengingat setiap detail, 00:18:35.160 --> 00:18:37.320 tetapi karena mereka meningkatkan peluang pelajaran masa 00:18:37.320 --> 00:18:38.840 lalu muncul kembali pada waktu yang tepat. 00:18:39.360 --> 00:18:40.380 Pengawasan manusia terpenting. 00:18:41.160 --> 00:18:43.960 Pengembang harus memvalidasi relevansi wawasan yang dimunculkan. 00:18:44.560 --> 00:18:46.560 Dan organisasi harus menjadwalkan audit rutin 00:18:46.560 --> 00:18:47.700 atas apa yang ditangkap agen 00:18:47.700 --> 00:18:50.200 untuk menghindari penyimpangan atau kebisian yang masuk ke sistem. 00:18:51.260 --> 00:18:52.140 Dengan tinjauan yang cermat, 00:18:52.220 --> 00:18:54.480 kecerdasan tersebut menjadi dapat ditindak lanjut di alih yang bingungkan. 00:18:55.100 --> 00:18:56.940 Tata kelola adalah bagian lain yang tidak boleh dilewatkan. 00:18:56.940 --> 00:19:00.620 Memasukkan log, pull request, dan hasil penderapan ke dalam sistem agen 00:19:00.620 --> 00:19:03.720 menimbulkan pertanyaan seputar privasi, retensi, dan kepatuhan. 00:19:04.420 --> 00:19:05.960 Tidak semua artefak harus hidup selamanya, 00:19:06.240 --> 00:19:08.400 dan tidak semua data harus dapat diakses oleh setiap peran. 00:19:09.220 --> 00:19:11.120 Sebelum meluncurkan lapisan memori semacam ini, 00:19:11.260 --> 00:19:12.780 tin perlu menentukan batas retensi, 00:19:12.940 --> 00:19:14.920 data yang jelas, menetapkan kebijakan akses, 00:19:15.060 --> 00:19:18.320 dan memastikan akses, dan memastikan data sensitif dibersihkan atau disamarkan. 00:19:18.660 --> 00:19:22.140 Tanpa batasan tersebut, Anda berisiko membuat repository bayangan rewrite perusahaan 00:19:22.140 --> 00:19:22.820 yang tidak terkelola, 00:19:22.820 --> 00:19:25.080 yang justru menyulitkan audit alih-alih mendukungnya. 00:19:25.080 --> 00:19:28.860 Ya, bagi pengembang, dampak yang paling terlihat muncul selama dimulainya proyek. 00:19:29.320 --> 00:19:31.780 Alih-alih ingatan samar tentang apa yang salah terakhir kali, 00:19:31.940 --> 00:19:33.460 wawasan muncul langsung dalam konteksnya. 00:19:34.380 --> 00:19:35.440 Mulai api web.net baru, 00:19:35.660 --> 00:19:37.620 dan sistem mungkin akan mengingatkan tahun lalu, 00:19:38.360 --> 00:19:41.040 ustaga cacing ini menyebabkan kebocoran memori saat dimuat, 00:19:41.600 --> 00:19:42.560 pertimbangkan alternatif lain. 00:19:43.060 --> 00:19:45.060 Atau saat perencanaan, sistem bisa menandai bahwa 00:19:45.060 --> 00:19:47.400 pola injeksi dependensi tertentu menciptakan ketidakstabilan. 00:19:48.140 --> 00:19:49.080 Pengingat ini tepat waktu, 00:19:49.080 --> 00:19:52.860 bukan retorspektif sehingga mengalihkan fokus dari bereaksi terhadap masalah menjadi mencegahnya. 00:19:52.860 --> 00:19:56.940 Begitulah kecerdasan proyek terakumulasi alih-alih tereset setiap kali sprint baru dimulai. 00:19:57.920 --> 00:19:59.420 Hal ini juga mengubah sifat retorspektif. 00:20:00.180 --> 00:20:03.420 Retrospektif tradisional mengumpulkan umpan balik pada satu titik waktu lalu beralihkan. 00:20:04.040 --> 00:20:05.020 Dengan agen yang terlibat, 00:20:05.260 --> 00:20:06.820 pengetahuan itu tidak akan disimpan begitu saja. 00:20:07.360 --> 00:20:09.860 Pengetahuan tersebut terus dimasukkan kembali ke dalam siklus pengembangan. 00:20:10.520 --> 00:20:11.340 Log dari bulan ini, 00:20:11.820 --> 00:20:13.180 anomali penskalaan dari kuartal lalu, 00:20:13.360 --> 00:20:15.140 atau regresi kinerja yang dicatat dua tahun lalu, 00:20:15.140 --> 00:20:17.360 semuanya menjadi dasar rekomendasi yang dibuat hari ini. 00:20:17.360 --> 00:20:21.120 Dengan menjadikan setiap rilis bagian dari siklus pelatihan berkelanjutan, 00:20:21.280 --> 00:20:23.520 tim mengurangi kemungkinan kegagalan yang sama terulang kembali. 00:20:24.360 --> 00:20:25.460 Tetap saja hasil harus diukur, 00:20:25.580 --> 00:20:26.160 akan diasumsikan. 00:20:26.840 --> 00:20:29.240 Langkah awal yang sederhana adalah mengintegrasikan agen 00:20:29.240 --> 00:20:31.800 dengan satu sumber telemetri seperti log aplikasi atau fit APM 00:20:31.800 --> 00:20:32.940 dan menjalankannya selama dua sprint. 00:20:33.300 --> 00:20:34.040 Kemudian bandingkan, 00:20:34.200 --> 00:20:35.980 apakah agen memunculkan pola yang tidak Anda sedari? 00:20:36.540 --> 00:20:39.180 Apakah pola tersebut memicu perubahan nyata pada kode atau infrastruktur? 00:20:39.180 --> 00:20:41.400 Dan apakah kualitas rilis meningkat secara terukur? 00:20:42.320 --> 00:20:43.220 Jika jawabannya ya, 00:20:43.520 --> 00:20:46.460 maka memperluas keriwayi PR atau pemetaan arsitektur sangat masuk akal. 00:20:47.360 --> 00:20:50.100 Tidak, eksperimen itu sendiri akan mengungkap apa yang perlu disesuaikan, 00:20:50.800 --> 00:20:53.000 baik dalam sumber data tata kelola atau proses peninjauan. 00:20:53.900 --> 00:20:55.580 Ciring waktu, keuntungannya akan bersifat kumulatif. 00:20:55.840 --> 00:20:57.560 Dengan meningkatkan memori institusional, 00:20:57.700 --> 00:20:58.940 kecepatan rilis menjadi stabil, 00:20:59.180 --> 00:21:00.540 arsitektur menjadi lebih tangguh, 00:21:00.680 --> 00:21:04.260 dan energi rekayasa tidak terbuang untuk menemukan kembali jebakan lama. 00:21:05.760 --> 00:21:07.180 Pengetahuan tidak lagi hilang begitu saja, 00:21:07.180 --> 00:21:09.980 melainkan terakumulasi sebagai sumber daya yang dapat dipercaya oleh tim. 00:21:10.440 --> 00:21:12.640 Dan pada titik itu, peran agen di AI terlihat berbeda. 00:21:13.160 --> 00:21:14.820 Ini bukan sekadar pembantu di satu tahap pengembangan. 00:21:15.340 --> 00:21:16.780 Sistem ini mulai menyatukan seluruh proses, 00:21:16.780 --> 00:21:19.300 meneruskan pelajaran ke depan alih-alih membiarkannya ke dalam luar saat. 00:21:20.600 --> 00:21:22.480 Kontinuitas itulah yang mengubah DevOps 00:21:22.480 --> 00:21:25.240 dari serangkaian tugas terisolasi menjadi siklus hidup yang lebih terhubung, 00:21:25.520 --> 00:21:26.960 menyiapkan panggung bagi perubahan luas 00:21:26.960 --> 00:21:28.740 yang kini terjadi di seluruh tim perangkat rungat. 00:21:30.160 --> 00:21:32.560 Agentic AI menandakan perubahan praktis dalam pengembangan? 00:21:33.600 --> 00:21:35.060 Konsep, ini bukan asisten kode, 00:21:35.120 --> 00:21:37.120 melainkan sistem yang membawa memori, konteks, 00:21:37.220 --> 00:21:38.700 dan tujuan di seluruh siklus hidup pengembangan. 00:21:39.100 --> 00:21:41.500 Aplikasi, titik masuk paling jelas bagi tim.net dan Azure 00:21:41.500 --> 00:21:42.860 adalah pembuatan kerangka proyek baru 00:21:42.860 --> 00:21:44.520 membiarkan agen menangani penyediaan rutin 00:21:44.520 --> 00:21:46.240 dan bereksperimen dengan pengujian otomatis, 00:21:46.520 --> 00:21:48.460 dan bereksperimen dengan pembuatan pengujian otomatis. 00:21:48.820 --> 00:21:50.420 Dampak, jika dilakukan kan cermat, 00:21:50.540 --> 00:21:52.200 hal ini akan menyederhanakan alur kerja, 00:21:52.360 --> 00:21:53.400 mengurangi beban pengaturan, 00:21:53.580 --> 00:21:56.100 dan menurunkan peluang kegagalan yang sama terulang di berbagai proyek. 00:21:56.520 --> 00:21:58.900 Langkah selanjutnya terbaik adalah mengujinya di lingkungan Anda sendiri. 00:21:59.500 --> 00:22:01.280 Coba aktifkan co-pilot pada perwaru pekecil 00:22:01.280 --> 00:22:02.980 atau jalankan agen di lingkungan staging. 00:22:03.180 --> 00:22:04.100 Lalu pantau satu metrik, 00:22:04.320 --> 00:22:05.520 waktu yang dihemat, bagian ditemukan, 00:22:05.640 --> 00:22:06.360 atau drift yang dicegah. 00:22:07.000 --> 00:22:09.700 Jika Anda memiliki tantangan DevOps berulang yang memperlambat tim Anda, 00:22:09.700 --> 00:22:12.020 tulis di kolom komentar agar yang lain bisa sering berbagi. 00:22:12.640 --> 00:22:14.300 Dan jika Anda ingin saran yang lebih mendalam 00:22:14.300 --> 00:22:16.040 tentang danaat Azure dan adopsi AI, 00:22:16.140 --> 00:22:17.800 berlanggananlah untuk pembahasan selanjutnya. 00:22:18.400 --> 00:22:19.740 Hasilnya mungkin terlihat kecil di awal, 00:22:19.820 --> 00:22:21.880 tetapi akan meningkat seiring dengan tata kelola pengawasan 00:22:21.880 --> 00:22:22.740 dan literasi yang konsisten.