Latest / M365.FM – Podcast Microsoft 365, Copilot & AI Bahasa Indonesia / AI agentik mengubah DevOps: cara agen AI mentransformasi .NET, Azure, dan produktivitas developer (Sulih Suara AI)

Transcript

AI agentik mengubah DevOps: cara agen AI mentransformasi .NET, Azure, dan produktivitas developer (Sulih Suara AI) · M365.FM – Podcast Microsoft 365, Copilot & AI Bahasa Indonesia

• 0:00
  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?
• 0:08
  Itulah intinya AI-Gen yang sedang berkembang saat ini.
• 0:11
  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.
• 0:20
  Di akhir video, Anda akan mengetahui satu eksperimen kecil untuk dicoba di alur kerja.net Anda minggu ini.
• 0:24
  Namun sebelum bahas penerapan dan hasilnya, kita perlu melihat apa yang membuat AI-Gen berbeda dari alat pelengkap otomatis yang sudah Anda kenal.
• 0:33
  Apa yang membuat AI-Gen berbeda?
• 0:35
  Jadi, yang membedakan AI-Gen bukan sekadar kemampuan menghasilkan kode, melainkan cara kerjanya yang menyerupai sistem rekan kerja dengan kemampuan berbeda.
• 0:42
  Untuk memahaminya, kita bisa membaginya ke dalam tiga sifat utama.
• 0:44
  Cara setiap agen menyimpan konteks dan memori, cara koordinasi antara agen layaknya sebuah tim, dan perbedaan antara otomatisasi sederhana dengan otonomi adaptif sejati.
• 0:52
  Pertama, mari kita lihat apa yang membuat agen individu istimewa konteks, memori, dan orientasi tujuan.
• 0:58
  Pelengkap otomatis tradisional memprediksi kata atau baris berikutnya, tetapi langsung melupakan segalanya setelah prediksi dibuat.
• 1:04
  Sebaliknya, agen AI memiliki pemahaman terhadap proyek yang lebih luas.
• 1:08
  Ia mengingat apa yang sudah dicoba atau letak kode, dan menyesuaikan hasilnya saat ada perubahan.
• 1:13
  Ketekunan tersebut membuatnya lebih mirip bekerja dengan pengembang junior, seseorang yang belajar seiring waktu alih-alih hanya menebak keinginan Anda saat itu juga.
• 1:20
  Perbedaan utamanya di sini terletak pada prediksi proses perancana.
• 1:23
  Alih-alih bereaksi terhadap setiap ketika secara terpisah, agen tetap melecak tujuan dan beradaptasi seiring perkembangan situasi.
• 1:29
  Selanjutnya adalah bagaimana beberapa agen bekerjasama.
• 1:31
  Salah pahaman besar adalah menganggap AI agen sebagai skrip atau makro pengembangan yang hanya mengotomatisasi tugas rutin.
• 1:36
  Padahal dalam proyek perangkat lunak nyata pekerjaan terbagi peran.
• 1:39
  Arsitek, peninjau, penguji, operator, agen dapat mencerminkan pembagian ini masing-masing menangani satu bagian siku hidup dengan ingatan dan konsistensi yang sempurna.
• 1:48
  Bayangkan satu agen yang dikhususkan untuk desain sistem, mengusulkan pola arsitektur dan kerangka kerja yang sesuai dengan tujuan bisnis.
• 1:55
  Agen lain meninjau perubahan kode, mendeteksi masalah sambil tetap memahami riwayat keseluruhan proyek.
• 1:59
  Agen ketiga dapat memperluas cakupan pengujian berdasarkan data pengguna, membuat kasus uji tanpa perlu Anda minta.
• 2:06
  Setiap agen terspesialisasi, namun mereka berkoordinasi seperti tim, selalu tersedia, konsisten, dan mudah disesuaikan tergantung beban kerja.
• 2:12
  Di saat manusia kehilangan energi, konteks, atau fokus, agen tetap stabil dan mengingat detail dengan presisi.
• 2:18
  Poin terakhir adalah perbedaan antara otomatisasi dan otonomi.
• 2:22
  Otomatisasi sudah lama ada dalam pengembangan perangkat lunak.
• 2:24
  Bayangkan skrip, pipeline CA plus CD, dan tempat.
• 2:26
  Semua untuk kaku kerancangannya.
• 2:28
  Mereka mengikuti instruksi tepat selangkah demi selangkah, tetapi rusak saat kondisi berubah secara tak terduga.
• 2:33
  Otonomi mengambil pendekatan yang berbeda.
• 2:36
  Agen AI dapat merespons perubahan secara langsung, menyesuaikan diri saat versi dependensi berubah atau mempertimbangkan ulang pilihan layanan saat kendala biaya muncul.
• 2:44
  Alih-alih mengeksekusi jalur yang telah ditentukan mereka membuat keputusan dalam kondisi yang dinamis.
• 2:48
  Ini adalah peralihan dari eksekusi statis kepemecahan masalah yang adaptif.
• 2:51
  Efek lanjutannya adalah agen-agen ini tidak lagi sekadar menunggu perintah.
• 2:55
  Mereka dapat mengusulkan solusi saat masalah muncul, menyoroti risiko sebelum masuk ke produksi, dan menyusun rencana yang menghemat waktu pengaturan berjam-jam.
• 3:03
  Jika GitHub Copilot saat ini bisa mengisi cuplikan kode, versi masa depan bertindak lebih seperti kontributor proyek,
• 3:08
  menyusun peta jalan, menyarankan strategi rilis, bahkan menandai keputusan arsitektur yang mungkin menyebabkan masalah nantinya.
• 3:13
  Itu tidak berarti setiap penyebar akan berjalan tanpa input manusia.
• 3:17
  Tetapi hal ini dapat secara signifikan mengurangi intervensi berulang,
• 3:20
  dan memberi pengembang lebih banyak waktu untuk fokus pada bagian kreatif yang berinaik tinggi dari sebuah proyek.
• 3:25
  Untuk memperjelas cara penyampaian sebelumnya di bidang ini,
• 3:27
  Alih-alih mengatakan apa yang terjadi jika penyediaan sumber daya azure sama sekali tidak membutuhkan manusia.
• 3:31
  Pernyataan yang lebih akurat adalah alat-alat ini dapat mengurangi jumlah pengaturan manual yang diperlukan
• 3:37
  sambil tetap menjaga batas pengamanan utama di bawah hendali manusia.
• 3:41
  Hasilnya tetap transformatif, tanpa menyeratkan bahwa pengawasan manusia menghilang sepenuhnya.
• 3:46
  Kesadaran yang lebih besar adalah bahwa AI Genic bukan sekadar pelakin lain yang percepat tugas di sana-sini.
• 3:51
  AI ini mulai berfungsi layaknya anggota tim sungguhan menangani pekerjaan latar belakang
• 3:55
  agar pengembang tidak terjebak mengejar detail yang bisa dilacak oleh mitra yang selalu aktif.
• 3:59
  Kapasitas seluruh tim meningkat karena domain utama memiliki agen digital yang bekerja bersama spesialis manusia.
• 4:06
  Memahami teorinya memang penting, tetapi yang benar-benar berarti adalah bagaimana hal ini terjadi di lingkungan yang familiar.
• 4:11
  Jadi inilah celah rasa yang ingin tahu kita.
• 4:12
  Apa yang sebenarnya berubah pada hari pertama, proyek baru ketika agen sudah aktif sejak awal?
• 4:17
  Selanjutnya, kita akan melihat skenario kokan di dalam ekosistem.net
• 4:20
  di mana perubahan tersebut mulai muncul bahkan sebelum Anda menulis baris kode pertama.
• 4:24
  Membayangkan kembali alur kerja pengembang di.net.
• 4:27
  Dalam pengembangan internet, perubahan yang paling terlihat dimulai dari cara proyek dimulai.
• 4:32
  Membayangkan kembali alur kerja pengembang di sini bermuara pada tiga keuntungan taktis.
• 4:37
  Ding arsitektur yang lebih cepat, kritik tingkat proyek saat Anda bekerja, dan penurunan yang nyata dalam kelelahan pengaturan.
• 4:42
  Pertama adalah scaffolding yang lebih cepat.
• 4:44
  Daripada membuka visual studio dan menatap solusi kosong,
• 4:47
  agen AI dapat mengusulkan opsi arsitektur yang sesuai dengan kebutuhan spesifik Anda.
• 4:51
  Saat menencanakan web api dengan pembaruan real-time,
• 4:54
  agen menyarankan desain berlapis yang bersih dan menunjukkan bagaimana signal R dapat masuk ke dalam alur tersebut.
• 4:58
  Untuk aplikasi keuangan, ia menyiapkan entity framework dengan keamanan tipi yang kuat
• 5:01
  dan integrasi Azure Active Directory bahkan sebelum Anda membuat satu folder pun.
• 5:04
  Bahkan sebelum Anda membuat satu folder pun.
• 5:06
  Hal yang biasanya memakan waktu diskusi atau berjam-jam riset kini diringkas menjadi beberapa titik awal yang telah disesuaikan.
• 5:11
  Namun ini bukanlah cetak biru final.
• 5:13
  Ini anilet.
• 5:13
  Tim harus memvalidasi setiap saran dengan menjalankan daftar periksa singkat.
• 5:16
  Apakah autentikasi sudah memiliki persyaratan?
• 5:19
  Apakah login sudah terhubungan?
• 5:20
  Apakah kasus uji dasar sededek?
• 5:22
  Tata kelola yang ringan tersebut memastikan kecepatan tidak mengorbankan stabilitas.
• 5:26
  Keuntungan kedua adalah kritik yang berlanjut.
• 5:29
  Anggap ini bukan sebagai pelengkap kode,
• 5:31
  melainkan sebagai penasihat yang menjaga keselarasan desain.
• 5:34
  Jika Anda membuat pola repository untuk akses data,
• 5:36
  agen akan menandai jika Anda mulai melenceng dari pemisahan fungsi separation of concern.
• 5:40
  Saat menambahkan pengontrol baru,
• 5:41
  ia mengusulkan unit tes yang sesuai atau menyoroti ketidak konsistenan dengan bagian proyek lainnya.
• 5:45
  Alih hanya memberikan boilerplate,
• 5:48
  ia mendorong bentuk sistem Anda ke arah pola yang sudah dipelihara di setiap komit.
• 5:52
  Untuk eksperimen praktis,
• 5:53
  cobalah mengaktifkan copilot di Visual Studio pada prototipe kecil ASPAT & NETCORE.
• 5:58
  Kemudian bandingkan berapa lama waktu yang dibutuhkan untuk melayani permintaan pertama,
• 6:01
  satu endpoint dengan autentikasi dan penyimpanan data dibandingkan melakukannya secara menuang.
• 6:06
  Ini bukan jaminan penghematan waktu,
• 6:07
  tetapi menjalankan latihan berdampingan di lingkungan Anda sendiri seringkali menjadi cara tercepat
• 6:11
  untuk mengukur apakah agen ini memberikan dampak nyata.
• 6:13
  Keuntungan ketiga adalah perkurangnya pengaturan dan beban kognit.
• 6:17
  Banyak pekerjaan awal proyek bersifat repetitif,
• 6:20
  seperti menghubungkan middleware,
• 6:21
  autentikasi, menarik paket Nougat,
• 6:23
  mengatur logging dengan application insights,
• 6:24
  dan menulis pipeline YAML.
• 6:26
  Agen dapat langsung membuat kerangka bagian-bagian tersebut,
• 6:28
  termasuk step integrasi uji yang mengetahui dependensi apa saja yang tersedia.
• 6:32
  Hal ini tidak menghilangkan kendali Anda,
• 6:33
  tetapi mengalihkan kemana energi Anda digunakan.
• 6:35
  Daripada berkutat dengan file konfigurasi sepanjang hari,
• 6:38
  Anda menghabiskan waktu untuk menerapkan logika bisnis yang benar-benar penting.
• 6:40
  Kelelahan akibat pekerjaan pengaturan akan hilang
• 6:43
  memberikan ruang bagi keputusan desain kreatif daripada tugas-tugas mekanis.
• 6:47
  Hal yang membedakannya dari otomatisasi tradisional adalah fleksibilitasnya.
• 6:50
  Templat proyek memberikan Anda pengaturan default yang start.
• 6:53
  Agen menyesuaikan kerangkanya berdasarkan tujuan bisnis yang Anda tetapkan.
• 6:56
  Jika Anda membangun aplikasi kolaborasi,
• 6:58
  strategi cacing seperti redis dan desain berbasis event dengan Azure Service Bus
• 7:02
  akan muncul dalam rencana kerangka kerja.
• 7:04
  Jika Anda beralih ke beban kerja terjadwal,
• 7:06
  layanan latar belakang dan pengurusan antren akan muncul sebagainya.
• 7:08
  Responsifitas tersebut membedakan AI agen dari sekadar skrip
• 7:11
  menawarkan rekomendasi yang mencerminkan peran anggota tim senior
• 7:14
  dalam membantu memandu keputusan awal.
• 7:16
  Kontras dengan penggunaan copilot saat ini sangatlah jelas.
• 7:19
  Saat ini, kebanyakan pengembang melihatnya sebagai cara
• 7:21
  untuk mempercepat sintaks umum atau kode boilerplate.
• 7:24
  Mereka mengajukan pertanyaan.
• 7:25
  Alat tersebut melengkapi barisku.
• 7:27
  Dengan kemampuan agen,
• 7:28
  alat tersebut mulai memperisaran di tingkat sistem,
• 7:30
  menawarkan alternatif yang sedar konteks,
• 7:32
  dan menampilkan pertukaran yang lebih awal dalam siklus.
• 7:34
  Ompatannya adalah di sekadar membuat cuplikan kode
• 7:37
  menjadi mengkurasi desain yang bisa diterapkan.
• 7:39
  Dan itu mengubah tidak hanya cara kode ditulis,
• 7:41
  tetapi bagaimana tim bingkai keseluruhan solusi
• 7:43
  sebelum mereka berkomitmen pada satu arah.
• 7:46
  Semua ini tidak menghilangkan kebutuhan akan penilaian manusia.
• 7:49
  Agen dapat menyarankan kerangka kerja,
• 7:50
  dependensi, dan praktek,
• 7:51
  tetapi verifikasinya tetap menjadi tanggung.
• 7:53
  Anggap setiap rekomendasi sebagai draft proposal.
• 7:56
  Terima bagian yang selaras dengan standar Anda,
• 7:58
  revisi yang tidak sesuai,
• 7:59
  dan ambil pelajaran untuk iterasi proyek berikutnya.
• 8:01
  AI menangani pekerjaan berat yang repetitif,
• 8:04
  sementara anggota tim tetap fokus
• 8:05
  menjelaraskan pilihan teknologi dengan strategi.
• 8:08
  Sejauh ini, kita telah melihat bagaimana
• 8:09
  agen membentuk kembali pengalaman pungkodean.
• 8:11
  Di dalam internet itu sendiri,
• 8:13
  tetapi keterlibatan agen tidak berakhir
• 8:14
  pada desain solusi atau perancah proyek.
• 8:16
  Setelah dasar-dasarnya siap,
• 8:18
  kecerdasan yang sama mulai meluas kepenyediaan,
• 8:20
  penyebaran, dan pengolahan infrastruktur
• 8:22
  yang diandalkan aplikasi tersebut.
• 8:24
  Disitulah transformasi besar lain yang mulai terbentuk
• 8:26
  dan tidak terbatas pada alur kerja pengembang lokal.
• 8:28
  Ini tentang lingkungan cloud yang melingkupinya.
• 8:32
  Agen cloud yang menjalankan Azure dengan autopilot.
• 8:34
  Jadi, mari kita alihkan fokus ke apa yang terjadi
• 8:36
  ketika manajemen Azure itu sendiri
• 8:37
  mulai berjalan dengan autopilot berkat bantuan agen.
• 8:40
  Cara awal diskusi ini dibingkai seringkali terdengar
• 8:41
  seperti fiksi ilmiah.
• 8:42
  Apa yang terjadi ketika penyediaan sumber daya Azure
• 8:44
  sama sekali tidak membutuhkan manusia dalam prosesnya?
• 8:47
  Cara yang lebih baik untuk memikirkannya adalah seperti ini.
• 8:50
  Apa yang terjadi ketika penyediaan rutin
• 8:52
  dan deteksi penyimpangan
• 8:53
  memerlukan lebih sedikit intervensi manual
• 8:54
  karena agen mengelola tugas berulang
• 8:56
  di bawah batasan yang ditentukan?
• 8:58
  Pergeseran itu penting
• 9:00
  karena ini bukan tentang menyingkirkan orang
• 9:01
  melainkan tentang mengalihkan pekerjaan repetitif
• 9:03
  sambil tetap menjaga pengawasan.
• 9:05
  Jika Anda pernah membangun lingkungan Azure yang serius
• 9:07
  Anda sudah tahu betapa berantakannya hal itu.
• 9:09
  Anda harus berjibaku dengan template, script, dan nyamal pipeline
• 9:12
  sambil berpindah-pindah antara perintah CLE
• 9:14
  demi kecepatan dan portal untuk pengecualian.
• 9:17
  Setiap jalan pintas menjadi utang teknis
• 9:18
  yang menunggu untuk muncul.
• 9:20
  VM yang dibiarkan menyala di luar jam kerja
• 9:22
  biaya membengkak tanpa disadari
• 9:23
  atau akun penyimpanan kerekspo saat seharusnya tidak.
• 9:25
  Dan dalam operasi kelaut, kesalahan kecil sekalipun menciptakan masalah besar.
• 9:29
  Tagihan yang melonjak, wilayah yang melemahkan ketahanan
• 9:32
  atau kesenjangan kepatuhan yang Anda temukan pada waktu yang paling buruk.
• 9:35
  Ini adalah tinitas yang dihindari oleh kebanyakan tim
• 9:37
  dan disinilah agen mulai terasa seperti teknisi deployment autonom.
• 9:40
  Ide-nya sederhana.
• 9:42
  Anda memberikan tujuan tingkat bisnis, persyaratan kinerja,
• 9:44
  kebutuhan pemulihan, aturan kepatuhan, toleransi anggaran,
• 9:48
  dan agen menerjemahkannya tersebut menjadi konfigurasi infrastruktur.
• 9:52
  Alih-alih berpindah antar banyak konsol
• 9:53
  atau menyambungkan ID secara manual,
• 9:55
  Anda melihat template IISC yang sudah diselaraskan dengan tujuan Anda.
• 9:58
  Selanjutnya, agen yang sama terus memantau.
• 10:00
  Menjalankan pemeriksaan kepatuhan.
• 10:02
  Menimbulasikan kemungkinan kesalahan konfigurasi
• 10:04
  dan menerapkan perbaikan sebelum masalah meluas ke produksi.
• 10:07
  Perbedaan dari otomatisasi yang ada terletak pada kemampuan adaptasi.
• 10:11
  Pipeline CI persidih normal menganggap definisi IAML Anda sebagai aturan mutlak.
• 10:16
  Semua berjalan lancar sampai kenyataan berubah,
• 10:18
  ada pembaruan dependensi,
• 10:19
  lonjakan permintaan mendadak atau mandat kepatuhan baru,
• 10:21
  lalu instruksi statis itu rusak
• 10:23
  atau memproses sesuatu yang terlihat valid
• 10:24
  tetapi tidak memenuhi kebutuhan bisnis.
• 10:27
  Pipeline berbasis agen berperilaku berbeda.
• 10:29
  Akin menganggap definisi tersebut sebagai dasar
• 10:31
  tetapi memperbarunya saat kondisi berubah.
• 10:33
  Alih-alih menunggu seseorang untuk menskalakan layanan
• 10:35
  atau menyesuaikan distribusi regional
• 10:37
  agar memperhatikan pola beban,
• 10:39
  memprediksi ambang batas yang mungkin terjadi,
• 10:41
  dan menyediakan kapasitas tambahan sebelumnya.
• 10:44
  Adaptabilitas tersebut membuat skenario jadi lebih minim kesalahan dalam praktik.
• 10:47
  Bayangkan sebuah aplikasi internet yang melayani lalu lintas bagian besar.
• 10:50
  Seminggu kemudian, pengguna baru muncul di Eropa.
• 10:53
  Latensi meningkat,
• 10:53
  tetapi tidak ada yang memperhitungkan wilayah lain dalam IAML Asli.
• 10:56
  Otomatisasi tradisional mengembaikan.
• 10:58
  Anda baru menyadarinya setelah keluhan dan log muncul.
• 11:00
  Sebaliknya, agen menandai pola tersebut,
• 11:03
  menyebarkan replika di Eropa,
• 11:04
  dan segera mengonfigurasi perutean melalui Azure Front Door.
• 11:07
  Agen tidak hanya menyebarkan lalu pergi begitu saja.
• 11:09
  Agen terus menyelaraskan sumber daya dengan niat.
• 11:11
  Hampir seperti operator 24.7 yang tidak pernah lelah.
• 11:14
  Manfaat nyata melampaui sekadar penskalaan.
• 11:16
  Keamanan dan kepatuhan dibangun ke dalam siklus tersebut.
• 11:19
  Itu bisa berupa agen yang mengamati kontener penyimpanan
• 11:21
  yang terekspos tanpa sengaja,
• 11:22
  lalu menguncinya secara otomatis
• 11:24
  atau mendeteksi penyimpanan pada basis data patch VM
• 11:26
  dan mengembalikannya ke posisi semula.
• 11:28
  Ini adalah tugas frekuensi tinggi dengan visibilitas rendah
• 11:31
  yang biasanya baru diketahui manusia nanti
• 11:32
  dan setelah melalui banyak upaya.
• 11:34
  Dengan mendorongnya ke siklus berkelanjutan,
• 11:36
  Anda tidak menghilangkan operator Anda mebebaskan.
• 11:38
  Mereka.
• 11:39
  Alih-alih menghabiskan energi untuk memadamkan masalah,
• 11:41
  mereka fokus pada pencanaan dan strategi tingkat yang lebih tinggi.
• 11:44
  Dan itu adalah nuansa yang pengawasan manusia tidak hilang.
• 11:46
  Peran Anda berubah dari memperiksa kotak baris demi baris
• 11:49
  menjadi mendefinisikan pedoman sejak awal.
• 11:51
  Wilayah mana yang diizinkan?
• 11:53
  Biaya mana yang dapat diterima?
• 11:54
  Standar kepatuhan mana yang tidak boleh dilanggar?
• 11:56
  Mar.
• 11:56
  Langkah praktis begitu manapun yang ingin menguji ini adalah
• 11:59
  dengan menetapkan batasan kebijakan sejahat ini.
• 12:02
  Tetapkan plafon biaya, tentukan wilayah yang disetujui
• 12:04
  dan tambahkan batas yang kepatuhan.
• 12:06
  Akan kemudian bertindak sebagai penegak,
• 12:08
  bukan operator tanpa batas.
• 12:09
  Itulah prinsip dasarnya.
• 12:11
  Anda tetap memegang kendali atas arah strategi
• 12:13
  sementara agen menjalankan detail perlindungan dalam skala besar.
• 12:16
  Ini juga bukan berarti Anda menyerahkan produksi
• 12:17
  ke tangan agen pada hari pertama.
• 12:19
  Jika Anda menghindari risiko,
• 12:20
  mulailah di lingkungan uji yang terkendali.
• 12:22
  Berikan beban kerja yang tidak kritis kepada agen
• 12:24
  atau pilih satu layanan seperti infrastruktur penyimpanan
• 12:27
  atau logging dan biarkan agen mengelola drift
• 12:28
  serta provisioning di sana.
• 12:30
  Dengan cara ini, Anda membangun kepercayaan
• 12:32
  terhadap cara agen menafsirkan batasan
• 12:33
  sebelum memperluas jangkauannya.
• 12:35
  Anggap ini sebagai menjalankan proyek percontohan
• 12:36
  dengan cukupan yang jelas dan risiko rendah.
• 12:38
  Persis seperti cara sebagian besar praktek DevOps
• 12:40
  yang andal berkembang.
• 12:41
  Pada intinya, pendekatan agen untuk Azure IRC
• 12:44
  tidak seperti menulis lusinan skrip statis,
• 12:47
  melainkan mengelola daftar periksa yang dinamis.
• 12:49
  Hasilkan templat,
• 12:50
  jalankan pemeriksaan prapenyebaran,
• 12:52
  pantau drift, dan usulkan perbaikan.
• 12:54
  Semuanya di bawah batasan yang Anda konfigurasi.
• 12:56
  Pendekatan ini cukup terstruktur untuk dipercaya,
• 12:58
  namun cukup fleksibel untuk berkembang
• 12:59
  saat kondisi berubah.
• 13:01
  Tentu saja, penyediaan dan penskalaan infrastruktur
• 13:03
  hanyalah satu sisi dari keandalan.
• 13:05
  Masalah yang lebih sulit seringkali muncul kemudian.
• 13:07
  Itu memastikan kode yang Anda sebarkan
• 13:08
  kelingkungan tersebut benar-benar bertahan
• 13:10
  dalam kondisi dunia nyata.
• 13:12
  Dan disitulah tantangan berikutnya
• 13:13
  mau yang muncul,
• 13:14
  yaitu masalah menangkap bug yang tidak dilihat manusia
• 13:16
  sampai bug tersebut sudah ada di produksi.
• 13:18
  Pengujian otonom bug yang terdapatkan oleh manusia.
• 13:21
  Pengujian hanya mencakup apa yang dapat dipikirkan manusia.
• 13:23
  Dan itulah batasan utamanya.
• 13:25
  Sebagian besar kegagalan produksi
• 13:26
  tidak berasal dari apa yang diantisipasi,
• 13:28
  tetapi dari apa yang luput dari imajinasi manusia.
• 13:30
  Agen pengujian otonom mengisi celah ini
• 13:32
  dengan berfokus pada kasus tepi
• 13:34
  dan kondisi dinamis yang tidak akan pernah masuk
• 13:35
  ke dalam rangkaian pengujian biasa.
• 13:38
  Aplikasi .net diajur mungkin berkinerja sempurna
• 13:41
  di bawah beban berat selama uji stres terencana,
• 13:43
  tetapi perkenalkan peristiwa penskalaan,
• 13:46
  instans baru yang aktif di tengah lalu lintas,
• 13:48
  dan tiba-tiba kesalahan penanganan sesi muncul.
• 13:50
  Kecuali seseorang merancang tes kursus
• 13:51
  untuk tumpang tindi tersebut,
• 13:52
  hal itu akan luput dari perhatian.
• 13:54
  Agen otonom mendeteksi anomali tersebut,
• 13:56
  mengisolasinya,
• 13:57
  dan membuat tes regresi baru di sekitar kondisi tersebut.
• 13:59
  Lain kali saat penskalaan terjadi,
• 14:01
  pengaman itu sudah ada,
• 14:02
  mengubah apa yang tadinya merupakan risiko tersembunyi
• 14:03
  menjadi skenario yang dipantau.
• 14:05
  Contoh lainnya adalah mutasi input.
• 14:07
  Penguji manusia biasanya mendesain dengan data yang aman
• 14:09
  atau dapat diprediksi.
• 14:10
  Nama pengguna yang valid,
• 14:12
  payload API yang benar,
• 14:13
  atau kasus tepi yang jelas seperti string kosong.
• 14:16
  Sebaliknya,
• 14:16
  agen mulai bereksperimen
• 14:17
  dengan variasi yang tidak terpikirkan oleh pengembang.
• 14:20
  Permintaan yang terlalu besar,
• 14:22
  pengodean aneh,
• 14:23
  jeda tipis di antara panggilan multilangkah.
• 14:25
  Dengan melakukan itu,
• 14:26
  agen dapat micu kegagalan yang akan terawatkan sepenuhnya
• 14:27
  oleh rangkaian pengujian manual.
• 14:29
  Nilainya bukan hanya pada kecepatan,
• 14:30
  tetapi pada keagaman.
• 14:31
  Agen menjelajahi sudut-sudut aneh ruang input lebih cepat
• 14:34
  daripada kasus yang ditulis oleh manusia.
• 14:37
  Apa yang mendapatkan pergeseran ini
• 14:38
  dari otomatisasi tradisional
• 14:39
  adalah cara rangkaian pengujian berkembang.
• 14:41
  Paket regresi yang dirancang oleh manusia
• 14:43
  cenderung statis.
• 14:44
  Ini mencerminkan pengetahuan dan asumsi tim
• 14:46
  pada saat tertentu.
• 14:48
  Agen mengubahnya menjadi proses yang berkeluar.
• 14:50
  Mereka memperluas rangkaian saat sistem berubah,
• 14:52
  selalu mencari kondisi yang belum terpikirkan.
• 14:55
  Alih-alih pengembang bersusah payah
• 14:57
  memperbarui skrip yang rapuh setelah setiap iterasi.
• 14:59
  Kasus baru dihasilkan secara dinamis
• 15:00
  dari pengamatan nyata perilaku sistem.
• 15:03
  Namun, ada catatan penting.
• 15:05
  Tidak setiap tes yang dihasilkan agen layak
• 15:06
  dimasukkan ke dalam rangkaian permainan.
• 15:08
  Tes yang tidak stabil atau tidak relevan
• 15:10
  dapat menumpuk dengan cepat membuang waktu
• 15:11
  dan merusak percayaan pada otomatisasi.
• 15:14
  Itulah mengapa tata klubur penting.
• 15:15
  Tim membutuhkan proses penjauan.
• 15:17
  Pemembang atau insinyur QA
• 15:18
  harus memvalidasi setiap usulan tes
• 15:19
  untuk stabilitas dan relevansi bisnis
• 15:21
  sebelum memindahkannya ke paket regresi yang stabil.
• 15:24
  Seperti otomatisasi lainnya,
• 15:26
  pengawasan memastikan alat ini meningkatkan keandalan alih-alih
• 15:28
  menenggelamkan tim dalam kebisingan.
• 15:31
  Kesalahpahaman lain yang perlu diluruskan
• 15:33
  adalah gagasan bahwa agen memperbaiki bug.
• 15:35
  Mereka tidak menulis ulang kode produksi
• 15:37
  atau menambah kekurangan secara manis.
• 15:38
  Yang mereka lakukan dengan sangat baik adalah
• 15:39
  memunculkan skenario yang dapat direproduksi
• 15:41
  dengan detail diagnostik yang jelas.
• 15:43
  Bagi pengembang, memiliki serangkaian langkah
• 15:45
  yang ditangkap agen membuat perbedaan
• 15:46
  antara berjam-jam menebak-nebak
• 15:47
  dan penyelesaian cepat.
• 15:48
  Dalam beberapa kasus, agen dapat menyarankan
• 15:50
  kemungkinan perbaikan berdasarkan pola yang diketahui
• 15:52
  namun keputusan akhir dan perubahan tetap di tangan manusia.
• 15:55
  Dilihat dari cara ini, pembagian kerja menjadi berbersih.
• 15:58
  Mesin melakukan penemuan,
• 15:59
  manusia melakukan penilaian dan perbaikan.
• 16:01
  Dampak bisnis di sini adalah berkurangnya pemadaman kebakaran.
• 16:04
  Tim melihat lebih sedikit tiket larut malam,
• 16:06
  lebih sedikit regresi yang muncul kembali setelah rilis
• 16:08
  dan penurunan waktu yang signifikan untuk reproduksi langkah.
• 16:12
  Keanahan kinerja tertangkap di lingkungan terpendali
• 16:14
  bukan muncul pertama kali di depan pengguna akhir.
• 16:17
  Kesalahan keamanan terungkap saat pengujian internal.
• 16:20
  Bukan setelah pemindahan kepatuan atau latihan penetrasi.
• 16:23
  Pergeseran itu membuka ruang bagi QIA
• 16:24
  untuk fokus pada pertanyaan tingkat tinggi
• 16:26
  seperti kegunaan, kelancaran alur kerja, dan aksesibilitas.
• 16:29
  Ada yang tidak dapat dinilai secara berarti oleh mesin otonom mana pun.
• 16:32
  Bagi praktisi yang tertarik mencoba,
• 16:34
  mulai latihan yang kecil.
• 16:35
  Jalankan agen pengujian otonom terhadap lingkungan staging
• 16:38
  atau preproduksi selama durasi yang ditentukan.
• 16:41
  Bandingkan daftar masalah yang ditemukannya dengan backlog Anda saat ini.
• 16:44
  Anggap latihan ini sebagai pengumpulan data.
• 16:46
  Apakah teman baru tersebut benar-benar belum?
• 16:48
  Apakah mereka tempat tinggi dengan teks yang art?
• 16:49
  Apakah mengungkapkan titik buta yang penting bagi bisnis Anda?
• 16:52
  Dengan cara ini, Anda mengukur laba atas investasi,
• 16:54
  bukan mempertaruhkan kualitas rilis Anda pada teknik yang belum terbukti.
• 16:58
  Dan ketika tim menjalankan proyek percontohan semacam ini,
• 17:00
  sebuah pola pun muncul.
• 17:02
  Manfaat jangka panjangnya sebenarnya bukan hanya menangkap lebih banyak bug,
• 17:04
  tetapi seberapa cepat pelajaran tersebut dapat diumparkan kembali
• 17:07
  ke dalam siklus pengembangan yang lebih luas.
• 17:09
  Setiap anomali yang ditangkap, setiap wawasan yang dicatat,
• 17:11
  mewakili pengetahuan yang tidak seharusnya hilang di akhir sprint.
• 17:14
  Pertanyaannya adalah bagaimana kecerdasan itu disimpan, dibagikan, dan diteruskan,
• 17:18
  agar kesalahan yang sama tidak terulang dengan nama, proyek yang berbeda.
• 17:22
  Menutup siklus kecerdasan dalam DevOps
• 17:24
  Dalam DevOps, salah satu masalah tersulung untuk dipecahkan adalah
• 17:27
  betapa cepatnya pengetahuan sprint.
• 17:29
  Masalah dicatat post-mortem ditulis,
• 17:31
  namun saat proyek berikutnya dimulai,
• 17:33
  banyak dari pelajaran tersebut tidak kembali ke dalam alur kerja.
• 17:36
  Menutup siklus kecerdasan dalam DevOps berarti menghentikan siklus kehilangan tersebut
• 17:39
  dan memastikan apa yang dipelajari T benar-benar meningkatkan apa yang akan datang.
• 17:43
  AI agen mendukung hal ini dengan terhubung ke tempat
• 17:44
  di mana pengetahuan sudah mengalir.
• 17:47
  Titik integrasi pertama adalah menyerap log dan termetrik.
• 17:50
  Alih-alih meminta insinyur menyisir dasmur atau insiden yang diarsipkan,
• 17:53
  agen terus memindai metrik tingkat kesalahan dan jejak kinerja
• 17:56
  menghubungkan anomali di seluruh rilis.
• 18:00
  Yang kedua adalah menganalisis rewired pull request dan tinjauan kode.
• 18:03
  Keputusan yang dibuat dalam komentar seringkali berisi konteks
• 18:06
  tentang pertimbangan atau risiko yang tidak pernah masuk ke dalam dokumentasi.
• 18:09
  Dengan memproses percakapan tersebut,
• 18:11
  agen menestarikan alasan mengapa sesuatu terjadi bukan hanya apa yang digabung.
• 18:14
  Yang ketiga adalah mempetakan kegagalan yang diamati kerekomenasi arsitek.
• 18:18
  Jika strategi cacing tertentu berulang kali menyebabkan pembengkakan memori
• 18:21
  atau jika pola penskalaan memicu waktu habis,
• 18:23
  wawasan tersebut dimunculkan selama perencanaan
• 18:24
  sebelum keselama perencanaan sebelum kesalam sistem ber.
• 18:28
  Bersama-sama titik integrasi ini meningkatkan memori institusional
• 18:30
  tanpa menjanjikan kesempurna.
• 18:32
  Nilainya bukan karena agen dengan sempurna mengingat setiap detail,
• 18:35
  tetapi karena mereka meningkatkan peluang pelajaran masa
• 18:37
  lalu muncul kembali pada waktu yang tepat.
• 18:39
  Pengawasan manusia terpenting.
• 18:41
  Pengembang harus memvalidasi relevansi wawasan yang dimunculkan.
• 18:44
  Dan organisasi harus menjadwalkan audit rutin
• 18:46
  atas apa yang ditangkap agen
• 18:47
  untuk menghindari penyimpangan atau kebisian yang masuk ke sistem.
• 18:51
  Dengan tinjauan yang cermat,
• 18:52
  kecerdasan tersebut menjadi dapat ditindak lanjut di alih yang bingungkan.
• 18:55
  Tata kelola adalah bagian lain yang tidak boleh dilewatkan.
• 18:56
  Memasukkan log, pull request, dan hasil penderapan ke dalam sistem agen
• 19:00
  menimbulkan pertanyaan seputar privasi, retensi, dan kepatuhan.
• 19:04
  Tidak semua artefak harus hidup selamanya,
• 19:06
  dan tidak semua data harus dapat diakses oleh setiap peran.
• 19:09
  Sebelum meluncurkan lapisan memori semacam ini,
• 19:11
  tin perlu menentukan batas retensi,
• 19:12
  data yang jelas, menetapkan kebijakan akses,
• 19:15
  dan memastikan akses, dan memastikan data sensitif dibersihkan atau disamarkan.
• 19:18
  Tanpa batasan tersebut, Anda berisiko membuat repository bayangan rewrite perusahaan
• 19:22
  yang tidak terkelola,
• 19:22
  yang justru menyulitkan audit alih-alih mendukungnya.
• 19:25
  Ya, bagi pengembang, dampak yang paling terlihat muncul selama dimulainya proyek.
• 19:29
  Alih-alih ingatan samar tentang apa yang salah terakhir kali,
• 19:31
  wawasan muncul langsung dalam konteksnya.
• 19:34
  Mulai api web.net baru,
• 19:35
  dan sistem mungkin akan mengingatkan tahun lalu,
• 19:38
  ustaga cacing ini menyebabkan kebocoran memori saat dimuat,
• 19:41
  pertimbangkan alternatif lain.
• 19:43
  Atau saat perencanaan, sistem bisa menandai bahwa
• 19:45
  pola injeksi dependensi tertentu menciptakan ketidakstabilan.
• 19:48
  Pengingat ini tepat waktu,
• 19:49
  bukan retorspektif sehingga mengalihkan fokus dari bereaksi terhadap masalah menjadi mencegahnya.
• 19:52
  Begitulah kecerdasan proyek terakumulasi alih-alih tereset setiap kali sprint baru dimulai.
• 19:57
  Hal ini juga mengubah sifat retorspektif.
• 20:00
  Retrospektif tradisional mengumpulkan umpan balik pada satu titik waktu lalu beralihkan.
• 20:04
  Dengan agen yang terlibat,
• 20:05
  pengetahuan itu tidak akan disimpan begitu saja.
• 20:07
  Pengetahuan tersebut terus dimasukkan kembali ke dalam siklus pengembangan.
• 20:10
  Log dari bulan ini,
• 20:11
  anomali penskalaan dari kuartal lalu,
• 20:13
  atau regresi kinerja yang dicatat dua tahun lalu,
• 20:15
  semuanya menjadi dasar rekomendasi yang dibuat hari ini.
• 20:17
  Dengan menjadikan setiap rilis bagian dari siklus pelatihan berkelanjutan,
• 20:21
  tim mengurangi kemungkinan kegagalan yang sama terulang kembali.
• 20:24
  Tetap saja hasil harus diukur,
• 20:25
  akan diasumsikan.
• 20:26
  Langkah awal yang sederhana adalah mengintegrasikan agen
• 20:29
  dengan satu sumber telemetri seperti log aplikasi atau fit APM
• 20:31
  dan menjalankannya selama dua sprint.
• 20:33
  Kemudian bandingkan,
• 20:34
  apakah agen memunculkan pola yang tidak Anda sedari?
• 20:36
  Apakah pola tersebut memicu perubahan nyata pada kode atau infrastruktur?
• 20:39
  Dan apakah kualitas rilis meningkat secara terukur?
• 20:42
  Jika jawabannya ya,
• 20:43
  maka memperluas keriwayi PR atau pemetaan arsitektur sangat masuk akal.
• 20:47
  Tidak, eksperimen itu sendiri akan mengungkap apa yang perlu disesuaikan,
• 20:50
  baik dalam sumber data tata kelola atau proses peninjauan.
• 20:53
  Ciring waktu, keuntungannya akan bersifat kumulatif.
• 20:55
  Dengan meningkatkan memori institusional,
• 20:57
  kecepatan rilis menjadi stabil,
• 20:59
  arsitektur menjadi lebih tangguh,
• 21:00
  dan energi rekayasa tidak terbuang untuk menemukan kembali jebakan lama.
• 21:05
  Pengetahuan tidak lagi hilang begitu saja,
• 21:07
  melainkan terakumulasi sebagai sumber daya yang dapat dipercaya oleh tim.
• 21:10
  Dan pada titik itu, peran agen di AI terlihat berbeda.
• 21:13
  Ini bukan sekadar pembantu di satu tahap pengembangan.
• 21:15
  Sistem ini mulai menyatukan seluruh proses,
• 21:16
  meneruskan pelajaran ke depan alih-alih membiarkannya ke dalam luar saat.
• 21:20
  Kontinuitas itulah yang mengubah DevOps
• 21:22
  dari serangkaian tugas terisolasi menjadi siklus hidup yang lebih terhubung,
• 21:25
  menyiapkan panggung bagi perubahan luas
• 21:26
  yang kini terjadi di seluruh tim perangkat rungat.
• 21:30
  Agentic AI menandakan perubahan praktis dalam pengembangan?
• 21:33
  Konsep, ini bukan asisten kode,
• 21:35
  melainkan sistem yang membawa memori, konteks,
• 21:37
  dan tujuan di seluruh siklus hidup pengembangan.
• 21:39
  Aplikasi, titik masuk paling jelas bagi tim.net dan Azure
• 21:41
  adalah pembuatan kerangka proyek baru
• 21:42
  membiarkan agen menangani penyediaan rutin
• 21:44
  dan bereksperimen dengan pengujian otomatis,
• 21:46
  dan bereksperimen dengan pembuatan pengujian otomatis.
• 21:48
  Dampak, jika dilakukan kan cermat,
• 21:50
  hal ini akan menyederhanakan alur kerja,
• 21:52
  mengurangi beban pengaturan,
• 21:53
  dan menurunkan peluang kegagalan yang sama terulang di berbagai proyek.
• 21:56
  Langkah selanjutnya terbaik adalah mengujinya di lingkungan Anda sendiri.
• 21:59
  Coba aktifkan co-pilot pada perwaru pekecil
• 22:01
  atau jalankan agen di lingkungan staging.
• 22:03
  Lalu pantau satu metrik,
• 22:04
  waktu yang dihemat, bagian ditemukan,
• 22:05
  atau drift yang dicegah.
• 22:07
  Jika Anda memiliki tantangan DevOps berulang yang memperlambat tim Anda,
• 22:09
  tulis di kolom komentar agar yang lain bisa sering berbagi.
• 22:12
  Dan jika Anda ingin saran yang lebih mendalam
• 22:14
  tentang danaat Azure dan adopsi AI,
• 22:16
  berlanggananlah untuk pembahasan selanjutnya.
• 22:18
  Hasilnya mungkin terlihat kecil di awal,
• 22:19
  tetapi akan meningkat seiring dengan tata kelola pengawasan
• 22:21
  dan literasi yang konsisten.