WEBVTT 00:00:00.460 --> 00:00:06.760 Siap untuk 10 hari Microsoft 365, Copilot, AI, Azure, dan orang-orang yang membentuk masa depan kerja. 00:00:07.740 --> 00:00:12.000 Januari ini, M365 CUN kembali dan kami hadir lebih besar. 00:00:12.820 --> 00:00:18.200 Bergabunglah dengan kami dalam sesi langsung demo dunia nyata dan pengetahuan praktis dari MVP serta pakar industri di seluruh dunia. 00:00:18.920 --> 00:00:21.140 Tanpa slide yang umum, tanpa jargon yang tidak habisnya. 00:00:21.980 --> 00:00:28.560 Kami menangani tantangan nyata, Copilot Studio, agen AI, fabrik, keamanan, tata kelola, dan otomatisasi. 00:00:28.560 --> 00:00:34.420 Baik Anda seorang profesional IT, pengembang, atau pemimpin bisnis, ada sesi yang dirancang untuk Anda. 00:00:35.200 --> 00:00:40.100 Dengan 10 hari penuh, Anda dapat menjelajahi berbagai teknologi dan terhubung dengan komunitas global. 00:00:40.900 --> 00:00:44.320 Tonton langsung dan bawa wawasan praktis kembali ke organisasi Anda. 00:00:45.140 --> 00:00:48.940 Januari 2021, 10 hari, satu komunitas Microsoft. 00:00:49.440 --> 00:00:50.580 Pendaftaran sudah dibuka sekarang. 00:00:51.880 --> 00:00:55.240 Buka M365 Con.net dan amankan tempat Anda hari ini. 00:00:55.240 --> 00:00:58.240 Itu M365 Con.net. 00:01:00.100 --> 00:01:04.760 Bergabunglah sekarang di M365 Con.net dan sampai jumpa secara langsung di bulan Januari. 00:01:05.240 --> 00:01:11.960 Jika Anda pernah membuka solusi dan langsung merasa kewalahan dengan jaring file, referensi, dan bug yang menunggu untuk menjepak Anda, Anda tidak sendirian. 00:01:12.380 --> 00:01:14.800 Kebanyakan pengembang bekerja secara aktif menambah di sana memperbaiki bug. 00:01:15.060 --> 00:01:19.740 Mode agen GitHub Copilot bertujuan untuk menahan konteks yang lebih luas dan mengordinasikan perubahan di seluruh file. 00:01:19.740 --> 00:01:25.080 Dalam video ini, kami akan mendemonstrasikan bagaimana alur kerja itu terlihat di dalam proyek nyata podcast.net dan Azure. 00:01:25.520 --> 00:01:28.160 Kami akan menunjukkan solusi langsung dan menunjukkan sebelum dan sesudah perubahan. 00:01:28.560 --> 00:01:36.280 Anda akan melihat cara menghasilkan kode multifile dengan beban lebih sedikit, mengatasi kesalahan lintas file lebih cepat, dan akan menggunakan spesifikasi bahasa sederhana untuk membuat kerangka fitur. 00:01:36.280 --> 00:01:40.940 Dan sebelum kita sampai di sana, mari kita mulai dengan biaya tersembunyi dari siklus debugging yang sering kita alami setiap hari. 00:01:42.040 --> 00:01:43.420 Biaya tersembunyi dari debugging tambah sulam. 00:01:43.820 --> 00:01:45.900 Anda duduk untuk memperbaiki kesalahan yang terlihat cukup sederhana. 00:01:46.660 --> 00:01:49.800 Aplikasi tidak dapat dibangun, dan konsol menandai baris dalam file proyek utama Anda. 00:01:50.460 --> 00:01:56.200 Anda mengubah metode tersebut, menyusun ulang, dan mengenat telah menyelesaikannya sampai pesan yang sama muncul kembali dalam bentuk yang sedikit lebih. 00:01:56.420 --> 00:01:59.200 Setengah jam berlalu sebelum Anda menemukan masalah yang sebenarnya. 00:01:59.820 --> 00:02:02.000 Dependensi yang hilang terselip di folder proyek lain. 00:02:02.000 --> 00:02:07.280 Saat referensi diperbaiki dan Anda menerapkan ulang, sebagian besar sore Anda telah habis untuk tambah sulam. 00:02:07.560 --> 00:02:09.800 Pekerjaan fitur yang Anda rencanakan ditunda hingga besok. 00:02:10.260 --> 00:02:11.800 Pola ini sangat umum sehingga terasa normal. 00:02:12.380 --> 00:02:15.600 Di permukaan Anda merasa maju karena setiap bug yang Anda basmi terasa seperti kemenang. 00:02:16.100 --> 00:02:17.420 Pada praktiknya Anda berputar-putar. 00:02:17.860 --> 00:02:20.360 Siklusnya adalah kode, kompilasi kesalahan perbaikan ulang. 00:02:20.820 --> 00:02:26.660 Waktu bejam-jam hilang untuk mengejar jejak sebab dan akibat, dan hasil akhirnya adalah kemajuan reaktif bukan perbaikan yang beraktif. 00:02:27.100 --> 00:02:29.420 Berapa banyak dari Anda yang kehilangan satu sore kan siklus yang persis seperti ini? 00:02:29.420 --> 00:02:31.900 Tulis satu baris komentar, saya akan membaca belasan-belasan teratas. 00:02:32.500 --> 00:02:36.940 Hal yang membuat siklus ini melelahkan adalah perangkat di sekitar kita terus berkembang, sementara polanya tidak. 00:02:37.760 --> 00:02:41.280 Editor menambah fitur baru, framework berevolusi, dan integrasi semakin dalam. 00:02:41.640 --> 00:02:43.500 Namun, debanging tetap menuntut pendekatan reaktif. 00:02:44.120 --> 00:02:46.400 Ini seperti mencoba menahan api yang membesar dengan seember air. 00:02:47.480 --> 00:02:52.300 Setiap kobaran di tangan yang satu juga, namun kondisi dasar penyebabnya tetap ada, hampir menjamin munculnya api berikutnya. 00:02:53.040 --> 00:02:55.220 Dan dengan setiap perpindahan tab, biaya tersebutnya pun meningkat. 00:02:55.220 --> 00:02:59.460 Anda berpindah dari kelas layanan ke file konfigurasi, lalu melompat ke grafik dependensi. 00:03:00.160 --> 00:03:04.160 Setiap perpindahan menarik Anda keluar dari alur logika apapun yang sedang Anda pegang, memaksa pengaturan ulang mental. 00:03:04.560 --> 00:03:09.500 Ini bukan hanya soal detik yang terbuang saat berpindah jendela, melainkan beban mental untuk membangun kembali konteks berulang kali. 00:03:10.100 --> 00:03:12.680 Sepanjang hari, pengaturan ulang kecil itu menumpuk menjadi sesuatu yang berat. 00:03:13.120 --> 00:03:16.520 Bagi pengembang individu, kelahan ini muncul sebagai rasa frustrasi dan waktu yang terlalu. 00:03:17.260 --> 00:03:19.880 Bagi tim yang mengerjakan proyek skala perusahaan, dampaknya berlipat ganit. 00:03:19.880 --> 00:03:26.020 Lingkaran debaging menghambat tujuan sprint, menunda peluncuran fitur, dan membuka backlog yang tumbuh lebih cepat daripada yang diselesaikan. 00:03:26.880 --> 00:03:30.620 Pemuatan utang teknis hanyalah efek samping lain dari jam kerja yang hilang akibat pemadaman api. 00:03:31.620 --> 00:03:35.720 Banyak tim melaporkan bahwa sebagian besar waktu pengembangan mereka tersedot ke dalam debaging reaktif. 00:03:36.080 --> 00:03:37.220 Itu bukanlah bagian menarik dari teknik. 00:03:37.820 --> 00:03:41.520 Tidak ada yang merencanakan peta jalan untuk mengejar ketidakcocokan dependensi yang sama sebanyak 5 kali. 00:03:41.520 --> 00:03:43.900 Namun di sini bandwit terbuang minggu demi minggu. 00:03:43.900 --> 00:03:50.900 Ketika memperbaiki kesalahan menjadi definisi kemajuan, membangun fitur baru menjadi sekunder dan arsitektur menderita secara diam-diam di latar belakang. 00:03:51.640 --> 00:03:55.160 Kenyataan yang tidak nyaman adalah bahwa debaging tambal sulam tidak hanya memperlambat segalanya. 00:03:55.680 --> 00:03:58.180 Hal itu memperkuat budaya reaktif alih-alih desain. 00:03:58.720 --> 00:04:01.420 Anda menghabiskan waktu untuk memadamkan api, bukan membangun sistem. 00:04:01.840 --> 00:04:07.880 Itu mungkin menjaga produk tetap hidup dalam jangka pendek, tetapi membatasi seberapa jauh tim dapat berskala dan seberapa percaya diri mereka untuk merilisnya. 00:04:08.140 --> 00:04:09.680 Jadi mari kita berhenti sinak pada gaman api. 00:04:10.480 --> 00:04:12.160 Lari ke titik panas, siram air, lanjut lagi. 00:04:12.160 --> 00:04:14.560 Masalahnya bukan karena pengembang tidak alih-alih itu. 00:04:15.020 --> 00:04:15.460 Mereka ahli. 00:04:16.160 --> 00:04:17.700 Masalahnya adalah apinya tidak pernah menampan. 00:04:18.200 --> 00:04:24.420 Api itu hanya berpindah-pindah, berkobat di file baru, proyek baru, konfigurasi baru, membuat semua orang berada dalam mode respons, bukan mode kreasi. 00:04:25.180 --> 00:04:28.760 Hal itu menimbulkan pertanyaan, apa yang terjadi jika sikus tersebut tidak hanya dibebankan pada Anda? 00:04:29.440 --> 00:04:35.940 Bagaimana jika bagian yang berulang, lingkaran pelacakan, perpindahan, dan penambalan bisa dikelola secara berbeda sementara Anda tetap fokus membangun? 00:04:36.580 --> 00:04:40.520 Karena meskipun tekanan dari pemadaman api itu jelas, ada titik tekanan lain yang belum kita sentuh. 00:04:40.520 --> 00:04:47.700 Beban sesungguhnya muncul saat proyek Anda bukan sekadar satu file atau satu mode, yaitu saat perbaikan yang Anda butuhkan mencakup beberapa lapisan sekaligus. 00:04:48.400 --> 00:04:53.700 Bayangkan saat Anda membuka sebuah solusi di mana logikanya tersebar di berbagai proyek, layanan, dan pustaka. 00:04:53.700 --> 00:04:59.800 Bagian yang Anda perlukan ada di tiga tempat sekaligus, dan menjaga alurnya di kepala adalah tantangan tersendiri. 00:05:01.240 --> 00:05:03.500 Kekacauan multifile versus kendali konteks AI 00:05:03.500 --> 00:05:08.020 Saat proyek mencakup banyak lapisan, tantangan sebenarnya bukanlah menulis kode. 00:05:08.620 --> 00:05:10.680 Tantangannya adalah menjaga semua bagian yang bergerak agar tetap selamat. 00:05:10.680 --> 00:05:15.620 Disinilah ketegangan antara kekacauan multifile dan kendali konteks berbasis AI terlihat paling jelas. 00:05:16.320 --> 00:05:18.800 Ambil contoh solusi internet besar dengan belasan proyek atau lebih. 00:05:19.400 --> 00:05:21.920 Setiap fitur baru biasanya menyentuh lapisan yang berbeda secara bersama. 00:05:22.320 --> 00:05:27.380 Pengontrol di satu tempat, layanan di tempat lain, dan sekumpulan file konfigurasi yang berbeda di tempat yang berbeda. 00:05:27.380 --> 00:05:35.100 Sebelum menulis satu baris kode, Anda menghabiskan waktu menulisuri referensi dan meriksa dependensi berharap perubahan kecil tidak menyebabkan kerusakan tak terduga di bagian lain. 00:05:36.140 --> 00:05:37.420 Alur kerja itu bukanlah pengecualian. 00:05:37.740 --> 00:05:41.780 Itu hal normal dalam aplikasi perusahaan, terutama saat layanan Azure dan integrasinya mulai terlibat. 00:05:42.920 --> 00:05:44.440 Struktur sistem seperti ini tidaklah data. 00:05:45.360 --> 00:05:49.180 Antarmuka, pemeta injeksi dependensi, dan referensi lintas proyek semuanya berperan. 00:05:49.820 --> 00:05:57.140 Dengan Azure, beberapa dependensi berada sepenuhnya di luar folder solusi seperti function apps, bending service bus, pengaturan sumber daya, dan koneksi. 00:05:57.380 --> 00:05:57.940 Penyimpanan 00:05:57.940 --> 00:06:03.720 Anda harus mengordinasikan kode di IDE, file konfigurasi di disk, dan layanan yang didefinisikan di cloud. 00:06:04.460 --> 00:06:05.960 Semua itu tidak peduli bahwa Anda ingin lebih sedikit. 00:06:06.460 --> 00:06:09.900 Tiap kali Anda beralih kontek, Anda menghabiskan energi untuk menyusun kembali gambaran besarnya. 00:06:10.640 --> 00:06:12.840 Kebanyakan dari kita mencoba menjaga kontek tersebut dalam memori. 00:06:13.160 --> 00:06:16.620 Awalnya terasa bisa dikelola, tapi seiring berkembangnya proyek, kesalahan mulai menyelinap. 00:06:16.620 --> 00:06:19.520 Anda menambahkan metode baru di layanan tetapi lupa registrasi DE-nya. 00:06:19.880 --> 00:06:25.080 Anda membuat kode Azure function dan baru menyadari kemudian bahwa bending belum ditambahkan ke host.json atau template penerapan. 00:06:25.080 --> 00:06:28.360 Tidak ada yang memberitahu Anda sampai saat runtime ketika Anda sedang dibangin alimbang. 00:06:28.940 --> 00:06:30.220 Kode itu sendiri bukan abangin yang sebut. 00:06:30.540 --> 00:06:31.740 Yang sulit adalah koordinasi lintas web. 00:06:32.080 --> 00:06:37.080 Semua orang tahu rasanya berpindah-pindah tab dari pengontrol ke layanan, lalu ke model, kemudian ke file konfigurasi, 00:06:37.320 --> 00:06:41.560 lalu kembali lagi hanya untuk lupa alasan Anda membuka file tersebut. 00:06:41.700 --> 00:06:44.420 Itu adalah gangguan kecil yang berulang puluhan kali dalam sehari. 00:06:45.100 --> 00:06:48.280 Interaksi tersebut menumpuk, menciptakan hambatan yang menghambat kemajuan nyata. 00:06:48.880 --> 00:06:51.760 Hasilnya adalah pengiriman yang lebih lambat, bukan karena penulisan kodenya lambat, 00:06:51.760 --> 00:06:56.380 tetapi karena menjaga semuanya tetap sinkron mengulas fokus, beban kerja tambahan ini semakin besar dalam kue Cloud First. 00:06:57.240 --> 00:07:04.260 Azure menempatkan pengaturan utama di berbagai tempat, file, konfigurasi lokal, variabel lingkungan, template ARM atau BCHAP, 00:07:04.540 --> 00:07:05.700 ya pipeline CI per CD. 00:07:06.980 --> 00:07:10.520 Apa yang terlihat sebagai permintaan fitur tunggal seringkali tersebar di empat lapisan abstraksi? 00:07:11.440 --> 00:07:12.420 Flexitas ini bukanlah pilihan. 00:07:12.920 --> 00:07:14.760 Hal ini sudah menjadi bagian dari cara ekosistem bekerja. 00:07:15.420 --> 00:07:17.740 Nah, disinilah agent mode hadir sebagai sebuah perubahan potensial. 00:07:17.740 --> 00:07:22.320 Alia membiarkan Anda mengatur semuanya, fitur ini dirancang untuk menampung konteks yang lebih luas di berbagai file. 00:07:23.140 --> 00:07:26.620 Itu berarti saat Anda meminta perubahan pada satu lapisan, lapisan lainnya tidak akan terbaik. 00:07:27.380 --> 00:07:32.000 Dalam demo ini, saya akan membuat fungsi Azure baru dan menunjukkan bagaimana agent membantu dengan membuat isi metode, 00:07:32.220 --> 00:07:34.200 menyusun konfigurasi bending, memperbarui host. 00:07:35.620 --> 00:07:37.640 JSON bahkan menyarankan registrasi dia yang tepat. 00:07:38.100 --> 00:07:41.080 Biasanya itu adalah proses multilangkah yang tersebar di berbagai file berbeda. 00:07:41.420 --> 00:07:43.240 Agen dapat menyederhanakannya menjadi satu alur kerja. 00:07:43.240 --> 00:07:47.740 Ini bukan tentang menggantikan penilaian Anda, tetapi tentang menghilangkan tugas administratif yang berulang 00:07:47.740 --> 00:07:49.840 agar Anda bisa fokus pada pilihan desain yang sebenarnya. 00:07:50.840 --> 00:07:53.840 Manusia bisa menyimpan kerangka kasar di kepala atau mencoretnya di papan tulis. 00:07:54.760 --> 00:07:57.480 AI dapat melacak detail demi detail file tanpa kehilangan alurnya. 00:07:58.440 --> 00:08:01.620 Apa yang terasa sebagai beban kognitif besar bagi kita hanyalah konteks dasar bagi agen. 00:08:02.360 --> 00:08:06.880 Perbedaannya dalam prakteknya adalah beralih dari menyulap banyak tab keperubahan terorkestrasi yang tetap sinkron. 00:08:06.940 --> 00:08:10.120 Saya juga akan menampilkan pull request atau div yang dibuat agen selama demo 00:08:10.120 --> 00:08:12.460 agar Anda bisa melihat dengan jelas editan apa saja yang dilakukan. 00:08:12.460 --> 00:08:13.900 Visibilitas itu sangat penting. 00:08:14.220 --> 00:08:15.760 Anda mendapatkan kendali penuh untuk meninjau 00:08:15.760 --> 00:08:18.820 dan menyetujui sementara tugas berat memperbarui banyak file dilakukan untuk Anda. 00:08:19.040 --> 00:08:21.360 Jadi, daripada menghabiskan sore untuk menyambungkan fragment, 00:08:21.540 --> 00:08:22.760 Anda cukup mengarahkan perubahan sekali, 00:08:22.900 --> 00:08:25.360 mengonfirmasi pembaruan yang dihasilkan dan beralih ke desain tingkat tinggi. 00:08:26.480 --> 00:08:29.260 Keringanan yang dirasakan bukan hanya karena hemat klik atau ketikan, 00:08:29.400 --> 00:08:31.620 melainkan karena tetap fokus pada penyelesaian masalah nyata 00:08:31.620 --> 00:08:33.620 daripada melusuri bagaimana belasan file terhubung. 00:08:34.460 --> 00:08:36.420 Keunggulan ini terlihat paling jelas saat ada yang rusak 00:08:36.420 --> 00:08:38.280 karena meski dengan penanganan konteks yang lebih kuat, 00:08:38.280 --> 00:08:41.600 sistem bisa gagal, konfigurasi melenceng, dan referensi yang tidak cocok muncul kembali. 00:08:42.400 --> 00:08:44.080 Dan disitulah ujian berikutnya dimulai, 00:08:44.280 --> 00:08:46.600 bagaimana kesalahan dilacak dan diselesaikan setelah muncul. 00:08:47.400 --> 00:08:49.320 Dari perburung kesalahan hingga perbaikan otonom, 00:08:49.720 --> 00:08:51.700 pikirkan seberapa sering Anda menemui pesan kesalahan 00:08:51.700 --> 00:08:53.140 yang mengarah langsung ke satu file saja, 00:08:53.720 --> 00:08:55.600 Anda mengikuti stack trace ke metode yang disebutkan, 00:08:55.700 --> 00:08:57.840 melakukan sedikit penyesuaian, lalu menekan tombol rebuild. 00:08:58.500 --> 00:09:00.000 Itu terasa seperti solusi yang jelas, 00:09:00.100 --> 00:09:03.100 sampai kesalahan yang sama muncul kembali dalam bentuk yang sedikit berbeda. 00:09:03.740 --> 00:09:06.000 Saatilah Anda menyadari bahwa stack trace hanya menunjukkan dijalani. 00:09:06.000 --> 00:09:07.840 Masalah sebenarnya ada di tempat lain, 00:09:07.960 --> 00:09:09.340 mungkin di kelas mendukung atau tersembunyi 00:09:09.340 --> 00:09:11.560 dalam file konfigurasi yang belum Anda buka sepanjang minggu. 00:09:12.080 --> 00:09:14.120 Setiap pengembang pernah menghadapi pengalaman perhatian seperti itu. 00:09:14.380 --> 00:09:15.580 Apa yang terlihat sebagai masalah sebenarnya 00:09:15.580 --> 00:09:16.940 bukan di mana perbaikan yang harus dilakukan. 00:09:17.140 --> 00:09:19.380 Hal ini menghabiskan waktu dengan Anda menyesuaikan satu hal 00:09:19.380 --> 00:09:20.060 membangun ulang alaman. 00:09:20.620 --> 00:09:22.000 Kemudian kesalahan baru menyambut Anda, 00:09:22.120 --> 00:09:23.480 membawa ke file lain penyesuaian lain, 00:09:23.560 --> 00:09:25.000 penyesuaian lain, dan pembangun. 00:09:25.000 --> 00:09:27.120 Lingkaran ini tampak produktif karena Anda bergerak, 00:09:27.200 --> 00:09:28.100 mengetik, menyusun ulang. 00:09:28.320 --> 00:09:29.240 Tetapi di baliknya ini, 00:09:29.460 --> 00:09:31.620 lebih berupa coba-coba daripada penyelesaian nyata. 00:09:31.620 --> 00:09:34.180 Siklus itu bisa menelan waktu berjam-jam, 00:09:34.320 --> 00:09:36.180 menyisakan perbaikan kecil di permukaan 00:09:36.180 --> 00:09:38.340 tanpa kemajuan nyata pada fitur yang Anda kerjakan. 00:09:38.960 --> 00:09:40.260 Biaya sebenarnya di sini adalah peluang. 00:09:41.160 --> 00:09:43.240 Saat terjebak dalam ritme membangun dan mencoba ulang, 00:09:43.400 --> 00:09:44.860 Anda tidak memecahkan masalah bisnis 00:09:44.860 --> 00:09:47.000 atau merilis fungsionalitas yang ditunggu pengguna. 00:09:48.120 --> 00:09:50.040 Momentum habis untuk menebak-nebak, bukan merancang. 00:09:50.220 --> 00:09:51.540 Rasanya aktif saat itu, 00:09:51.740 --> 00:09:53.800 tetapi jam-jam tersebut tidak berarti banyak 00:09:53.800 --> 00:09:55.460 selain menjaga sistem agar tidak rusak. 00:09:56.580 --> 00:09:57.240 Dalam sebuah tim, 00:09:57.340 --> 00:09:59.060 pergerakan dangkal ini memperlambat segalanya 00:09:59.060 --> 00:10:01.240 dan menciptakan tumpukan fitur yang terus tertunda. 00:10:02.400 --> 00:10:04.460 Di sinilah alur kerja agen mulai terlihat berbeda. 00:10:05.160 --> 00:10:06.500 Ide-nya bukan berhenti pada satu baris 00:10:06.500 --> 00:10:07.900 yang disorot oleh pelacaan tumpukan setiap tes. 00:10:08.500 --> 00:10:08.980 Sebaliknya, 00:10:09.180 --> 00:10:11.100 ia dirancang untuk memiliki konteks tingkat sistem. 00:10:11.520 --> 00:10:13.580 Bertanya bukan hanya apa yang harus dilakukan file ini, 00:10:13.960 --> 00:10:15.520 tetapi urutan perubahan apa yang diperlukan 00:10:15.520 --> 00:10:17.500 di bagian terkait untuk memulihkan konsistensi. 00:10:18.480 --> 00:10:19.120 Dalam prakteknya, 00:10:19.200 --> 00:10:20.340 itu berarti Anda mungkin melihatnya 00:10:20.340 --> 00:10:22.020 mengusuhkan pengeditan yang mencakup beberapa file. 00:10:22.400 --> 00:10:23.020 Sebagai contoh, 00:10:23.020 --> 00:10:24.140 Anda akan melihat dalam demo 00:10:24.140 --> 00:10:26.060 bahwa ketika sebuah metode memerlukan perubahan, 00:10:26.240 --> 00:10:28.660 ia dapat menyarankan pengeditan yang cocok di konfigurasi terkait 00:10:28.660 --> 00:10:29.680 atau tempat penyebaran lain 00:10:31.620 --> 00:10:33.440 dari pelengkapan otomatis autocomplik ke sesuatu yang lebih luk. 00:10:34.140 --> 00:10:35.820 Pelengkapan otomatis menyelesaikan baris 00:10:35.820 --> 00:10:37.460 sementara agen berkoordinasi antar file 00:10:37.460 --> 00:10:38.760 dan koordinasi itu paling penting 00:10:38.760 --> 00:10:40.460 saat kesalahan tidak berada di satu tempat. 00:10:41.000 --> 00:10:42.000 Ambil skenario azur yang umum. 00:10:42.680 --> 00:10:43.980 Anda membuat aplikasi fungsi baru, 00:10:44.100 --> 00:10:45.080 tetapi setelah diterapkan, 00:10:45.240 --> 00:10:46.040 pemicu antrean gagal 00:10:46.040 --> 00:10:47.800 karena pengingkatan tidak cocok dengan tanda tangan metode. 00:10:48.380 --> 00:10:48.820 Biasanya, 00:10:49.160 --> 00:10:50.420 Anda memeriksa log, 00:10:50.540 --> 00:10:51.840 mencari tahu pengingkatan mana yang salah, 00:10:52.000 --> 00:10:52.380 menyesuaikan. 00:10:52.880 --> 00:10:53.800 JSON fungsi secara manual 00:10:53.800 --> 00:10:55.240 bahkan mungkin mengubah template infrastruktur 00:10:55.240 --> 00:10:56.620 jika nilainya juga tidak cocok di sana. 00:10:56.620 --> 00:10:58.800 Setiap langkah adalah 00:10:58.800 --> 00:10:59.580 pengejaran terpisah 00:10:59.580 --> 00:11:00.200 dan setiap perbaikan 00:11:00.200 --> 00:11:01.280 memicu pengunjian ulangan lainnya. 00:11:02.080 --> 00:11:02.800 Dengan moda agen, 00:11:02.900 --> 00:11:03.700 alur kerjanya berbeda. 00:11:04.160 --> 00:11:05.520 Ia dapat mengusulkan perubahan kode, 00:11:05.680 --> 00:11:07.280 membuat pengikatan JSON fungsi yang tepat, 00:11:07.400 --> 00:11:08.360 dan menampilkan pengeditan 00:11:08.360 --> 00:11:09.240 untuk skrip penyebaran 00:11:09.240 --> 00:11:10.060 jika tidak selaras. 00:11:10.720 --> 00:11:11.820 Anda meninjau mengonfirmasi 00:11:11.820 --> 00:11:12.520 dan melangkah maju 00:11:12.520 --> 00:11:13.640 tanpa menghabiskan berjam-jam 00:11:13.640 --> 00:11:14.520 menyatukan setiap lapisan 00:11:14.520 --> 00:11:15.840 dan kepercayaan kuncinya di sini. 00:11:16.120 --> 00:11:17.100 Tidak seorang pun boleh merasa 00:11:17.100 --> 00:11:17.880 seolah ada pengeditan 00:11:17.880 --> 00:11:18.740 terjadinya terbaik. 00:11:19.060 --> 00:11:20.100 Itulah mengapa alur peninjauan itu. 00:11:20.560 --> 00:11:21.100 Dalam demo ini, 00:11:21.180 --> 00:11:22.040 kita akan melalui bersama-sama. 00:11:22.500 --> 00:11:23.400 Agen menyarankan perubahan 00:11:23.400 --> 00:11:24.320 yang terkoordinasi tersebut. 00:11:24.580 --> 00:11:25.380 Kita akan membuka div 00:11:25.380 --> 00:11:26.620 untuk memeriksa dengan saksama 00:11:26.620 --> 00:11:27.840 apa yang dihasilkan, 00:11:28.480 --> 00:11:29.400 menjalankan unit tes kita, 00:11:29.540 --> 00:11:30.640 memvalidasi build secara lokal, 00:11:30.780 --> 00:11:31.960 lalu memutuskan apakah akan menerima 00:11:31.960 --> 00:11:32.940 atau menolak suntikan tersebut. 00:11:33.520 --> 00:11:34.380 Siklus validasi tersebut 00:11:34.380 --> 00:11:35.040 membuat Anda tetap 00:11:35.040 --> 00:11:35.740 memegang kendali penuh 00:11:35.740 --> 00:11:36.900 sembari menghilangkan pekerjaan kasar. 00:11:37.560 --> 00:11:38.280 Perlu ditekankan, 00:11:38.480 --> 00:11:39.400 agen memang dapat membantu 00:11:39.400 --> 00:11:40.140 bergerak lebih cepat, 00:11:40.140 --> 00:11:41.160 tetapi mereka tidak menggantikan 00:11:41.160 --> 00:11:41.920 praktek rekaya SMA. 00:11:42.380 --> 00:11:43.360 Anda tetap harus memperlakukan 00:11:43.360 --> 00:11:44.220 tinjauan kode dan CI 00:11:44.220 --> 00:11:45.380 sebagai gerbang yang tidak bisa diterima. 00:11:45.680 --> 00:11:46.620 Biarkan AI mengurangi waktu 00:11:46.620 --> 00:11:47.260 yang Anda habiskan 00:11:47.260 --> 00:11:48.100 untuk pekerjaan detektif, 00:11:48.220 --> 00:11:48.840 tetapi tetap gunakan 00:11:48.840 --> 00:11:49.600 pemeriksaan otomatis 00:11:49.600 --> 00:11:50.320 dan tinjauan manusia 00:11:50.320 --> 00:11:51.080 sebagai jaring pengaman. 00:11:51.580 --> 00:11:52.280 Keseimbangan tersebut 00:11:52.280 --> 00:11:53.440 memecahkan masalah kepercayaan 00:11:53.440 --> 00:11:54.400 dan memastikan peningkatan 00:11:54.400 --> 00:11:55.420 kecepatan tidak merusak stabil. 00:11:56.020 --> 00:11:56.800 Perbedaan kecepatan ini 00:11:56.800 --> 00:11:57.460 bukanlah teoretis. 00:11:57.980 --> 00:11:58.660 Jika mengejar error 00:11:58.660 --> 00:11:59.280 dan patching manual 00:11:59.280 --> 00:12:00.500 bisa memakan waktu setengah hari, 00:12:00.600 --> 00:12:01.260 saran terkoordinasi 00:12:01.260 --> 00:12:01.920 bisa memangkasnya 00:12:01.920 --> 00:12:02.820 menjadi hitungan menit. 00:12:03.840 --> 00:12:05.020 Dan waktu yang didapatkan kembali 00:12:05.020 --> 00:12:05.980 mengalik ke pekerjaan 00:12:05.980 --> 00:12:07.200 yang benar-benar ingin Anda fokuskan. 00:12:07.800 --> 00:12:08.960 Fitur yang disadari pengguna Anda 00:12:08.960 --> 00:12:09.900 keputusan arsitektur 00:12:09.900 --> 00:12:11.000 yang meningkatkan basis kode Anda. 00:12:11.860 --> 00:12:12.880 Alih-alih memadamkan api 00:12:12.880 --> 00:12:13.360 saat runtime, 00:12:13.500 --> 00:12:14.100 Anda bisa merancang 00:12:14.100 --> 00:12:15.100 dengan percaya diri sejak awal. 00:12:15.600 --> 00:12:16.340 Jadi siklus debaging 00:12:16.340 --> 00:12:16.800 tidak perlu lagi 00:12:16.800 --> 00:12:17.540 meneminasi hari Anda. 00:12:18.440 --> 00:12:19.000 Dengan agen 00:12:19.000 --> 00:12:19.480 yang menyarankan 00:12:19.480 --> 00:12:20.240 pembaruan intas file, 00:12:20.360 --> 00:12:21.380 Anda beralih dari pencarian 00:12:21.380 --> 00:12:21.960 yang tidak terarah 00:12:21.960 --> 00:12:23.260 ke ritme tinjau dan setujui. 00:12:23.980 --> 00:12:25.020 Anda berhenti berputar-putar 00:12:25.020 --> 00:12:25.540 mencari error 00:12:25.540 --> 00:12:26.720 dan mulai memperlakukan debaging 00:12:26.720 --> 00:12:27.680 sebagai langkah terstruktur 00:12:27.680 --> 00:12:28.680 yang hampir otomatis 00:12:28.680 --> 00:12:29.640 dalam alur kerja Anda. 00:12:30.480 --> 00:12:30.960 Perubahan itu 00:12:30.960 --> 00:12:32.080 mengosongkan ruang kognitif 00:12:32.080 --> 00:12:32.680 dan jam kalender 00:12:32.680 --> 00:12:33.420 untuk membangun fitur 00:12:33.420 --> 00:12:34.440 bukan sekadar menambil kekurangan. 00:12:34.940 --> 00:12:36.100 Dan begitu memperbaiki error 00:12:36.100 --> 00:12:37.440 tidak lagi sekadar manajer gejala 00:12:37.440 --> 00:12:38.080 itu membuka pintu 00:12:38.080 --> 00:12:39.120 menuju sesuatu yang lebih besar. 00:12:39.760 --> 00:12:40.780 Bagaimana Anda bisa memulai fitur 00:12:40.780 --> 00:12:41.460 secara keseluruhan 00:12:41.460 --> 00:12:42.540 dengan cara terstruktur yang sama? 00:12:42.960 --> 00:12:44.460 Bayangkan jika alur kerja yang sama 00:12:44.460 --> 00:12:46.420 yang mengusulkan perbaikan terkoordinasi 00:12:46.420 --> 00:12:47.900 juga dapat mengambil spesifikasi 00:12:47.900 --> 00:12:48.540 bahasa sederhana 00:12:48.540 --> 00:12:50.120 dan membentuk struktur kerja di sekitarnya. 00:12:50.820 --> 00:12:51.860 Disitulah tahap pengembangan 00:12:51.860 --> 00:12:52.740 selanjutnya dimulai. 00:12:53.560 --> 00:12:54.260 Pengembangan berbasis 00:12:54.260 --> 00:12:55.280 spesifikasi tambahan barang. 00:12:55.280 --> 00:12:56.760 Salah satu perubahan 00:12:56.760 --> 00:12:57.340 paling menarik 00:12:57.340 --> 00:12:58.260 muncul saat Anda berhenti 00:12:58.260 --> 00:12:59.040 berpikir hanya dalam 00:12:59.040 --> 00:12:59.900 hal-file dan metode 00:12:59.900 --> 00:13:01.140 lalu mulai membingkai 00:13:01.140 --> 00:13:02.400 pekerjaan dalam bahasa sederhana. 00:13:03.220 --> 00:13:04.040 Disitulah pengembangan 00:13:04.040 --> 00:13:04.920 berbasis spesifikasi 00:13:04.920 --> 00:13:05.680 tambahan-bahan barang. 00:13:06.260 --> 00:13:06.960 Bayangkan menulis 00:13:06.960 --> 00:13:07.820 permintaan fitur sederhana. 00:13:08.480 --> 00:13:09.820 Tambahkan alur kerja pelaporan 00:13:09.820 --> 00:13:11.100 yang menghasilkan ringkasan bulanan 00:13:11.100 --> 00:13:11.740 menyimpannya 00:13:11.740 --> 00:13:12.700 dan menyediakannya 00:13:12.700 --> 00:13:13.760 melalui halaman admin. 00:13:14.500 --> 00:13:15.400 Alih-alih hanya mendapatkan 00:13:15.400 --> 00:13:16.820 beberapa potongan kode terisolasi 00:13:16.820 --> 00:13:18.000 Anda mendapatkan struktur kerja 00:13:18.000 --> 00:13:18.720 yang sudah dipetakan 00:13:18.720 --> 00:13:19.580 di seluruh aplikasi Anda. 00:13:20.060 --> 00:13:21.140 Kontroller dibuat setapnya, 00:13:21.140 --> 00:13:21.840 model dibuat, 00:13:21.940 --> 00:13:22.740 layanan didaftarkan, 00:13:22.860 --> 00:13:23.940 dan konfigurasi dihubungkan. 00:13:24.640 --> 00:13:25.300 Perubahan dari 00:13:25.300 --> 00:13:26.060 menggambarkan niat 00:13:26.060 --> 00:13:27.140 hingga melihat kerangka konkret 00:13:27.140 --> 00:13:28.000 muncul di proyek Anda 00:13:28.000 --> 00:13:29.300 adalah saat pendekatan ini 00:13:29.300 --> 00:13:30.400 akhirnya terasa praktis 00:13:30.400 --> 00:13:31.280 bukan teoretis. 00:13:31.600 --> 00:13:32.040 Bukan teoret. 00:13:32.360 --> 00:13:33.440 Dalam pengaturan tradisional, 00:13:33.680 --> 00:13:34.400 pengembangan yang mengutamakan 00:13:34.400 --> 00:13:35.480 spesifikasi memiliki reputasi. 00:13:35.640 --> 00:13:36.800 Di organisasi besar, 00:13:36.960 --> 00:13:37.620 ini biasanya berarti 00:13:37.620 --> 00:13:38.840 dokumen persyaratan yang panjang, 00:13:38.980 --> 00:13:39.940 lembar desain multi halaman, 00:13:40.060 --> 00:13:40.700 dan diagram kaku 00:13:40.700 --> 00:13:41.740 yang memperlambat semua orang. 00:13:42.280 --> 00:13:42.920 Hal itu masuk akal 00:13:42.920 --> 00:13:43.920 di industri yang diatur ketat 00:13:43.920 --> 00:13:45.180 atau team yang tersebar secara global. 00:13:45.180 --> 00:13:46.340 Tetapi untuk pengkodian sehari-hari 00:13:46.340 --> 00:13:47.580 sebagian besar pengembang melewatkannya. 00:13:47.900 --> 00:13:49.140 Menulis dan memelihara spesifikasi 00:13:49.140 --> 00:13:49.840 meletal menambah biaya 00:13:49.840 --> 00:13:50.420 yang tidak punya waktu 00:13:50.420 --> 00:13:51.700 atau kesabaran untuk dikualasi waktu. 00:13:52.200 --> 00:13:53.280 Ini adalah beban tambahan 00:13:53.280 --> 00:13:54.360 di atas pengiriman fitur 00:13:54.360 --> 00:13:55.300 dan seiring mendekatnya 00:13:55.300 --> 00:13:55.840 tenggat waktu, 00:13:56.040 --> 00:13:56.700 upaya ekstra itu 00:13:56.700 --> 00:13:57.780 biasanya dikorbankan. 00:13:58.340 --> 00:13:58.880 Ironnya jelas, 00:13:58.980 --> 00:13:59.620 pengembang sebenarnya 00:13:59.620 --> 00:14:00.580 suka berpikir dalam keberan 00:14:00.580 --> 00:14:01.100 yang lebih luas. 00:14:01.940 --> 00:14:03.020 Mengetahui struktur lebih awal 00:14:03.020 --> 00:14:03.760 terasa melegakan. 00:14:04.320 --> 00:14:05.320 Masalahnya bukan pada niatnya, 00:14:05.380 --> 00:14:05.960 melainkan pemulihan. 00:14:06.460 --> 00:14:07.260 Begitu spesifikasi 00:14:07.260 --> 00:14:08.640 mulai tidak sinkron dengan kenyataan, 00:14:08.640 --> 00:14:10.080 pemeliharaannya menjadi beban. 00:14:10.720 --> 00:14:11.360 Itulah sebabnya 00:14:11.360 --> 00:14:12.220 banyak pekerjaan nyata 00:14:12.220 --> 00:14:13.480 cenderung ke arah improvisasi 00:14:13.480 --> 00:14:14.460 daripada desain lengkap 00:14:14.460 --> 00:14:15.280 bahkan di perusahaan 00:14:15.280 --> 00:14:16.020 yang secara teknis 00:14:16.020 --> 00:14:17.280 mendukung perencanaan matang. 00:14:18.080 --> 00:14:19.600 Alur kerja agen menawarkan alternatif. 00:14:20.460 --> 00:14:21.580 Alih-alih menuntut dokumen desain 00:14:21.580 --> 00:14:22.100 yang sempurna, 00:14:22.360 --> 00:14:22.940 agen bisa membantu 00:14:22.940 --> 00:14:23.940 menerjemahkan spesifikasi 00:14:23.940 --> 00:14:24.520 bahasa awal menjadi 00:14:24.520 --> 00:14:25.620 kerangka yang bisa Anda sempurnakan. 00:14:26.680 --> 00:14:28.140 Anda tidak butuh diagram UML 00:14:28.140 --> 00:14:29.780 atau peta antar muka tulisan tangan. 00:14:30.320 --> 00:14:31.060 Anda cukup berkata 00:14:31.060 --> 00:14:31.980 buat modul laporan 00:14:31.980 --> 00:14:33.120 dengan endpoint API baru, 00:14:33.380 --> 00:14:34.440 tautkan ke penyimpanan 00:14:34.440 --> 00:14:36.320 dan amankan akses berbasis peran, 00:14:36.320 --> 00:14:37.760 lalu sistem akan menghasilkan 00:14:37.760 --> 00:14:38.660 dasar di seluruh file 00:14:38.660 --> 00:14:39.680 solusi.net Anda. 00:14:40.620 --> 00:14:41.560 Dalam demo ini, 00:14:41.680 --> 00:14:42.380 saya akan membacakan 00:14:42.380 --> 00:14:43.460 spesifikasi bahasa awal, 00:14:43.720 --> 00:14:44.720 lalu menunjukkan file 00:14:44.720 --> 00:14:45.760 yang dibuat agen, 00:14:45.860 --> 00:14:46.760 pengontrol, model, 00:14:46.980 --> 00:14:47.880 dan pendaftaran layanan, 00:14:48.060 --> 00:14:49.040 serta menunjukkan bagian 00:14:49.040 --> 00:14:50.420 yang masih perlu perbaikan manual. 00:14:51.340 --> 00:14:51.740 Dengan begitu, 00:14:51.820 --> 00:14:52.960 Anda bisa menirai kualitasnya sendiri. 00:14:53.860 --> 00:14:54.820 Ini menciptakan jalan tengah 00:14:54.820 --> 00:14:56.080 di antara dua mode pengembang. 00:14:56.980 --> 00:14:57.500 Di satu sisi, 00:14:57.640 --> 00:14:58.520 ada vibe coding cepat, 00:14:58.600 --> 00:14:58.860 bebas, 00:14:58.980 --> 00:14:59.360 namun rapuh 00:14:59.360 --> 00:15:00.360 untuk sistem jangka panjang. 00:15:01.260 --> 00:15:01.780 Di sisi lain, 00:15:01.780 --> 00:15:03.520 ada desain berbasis spesifikasi, 00:15:03.920 --> 00:15:05.240 andal namun sangat lambat. 00:15:06.320 --> 00:15:07.200 Dengan dukungan agen, 00:15:07.320 --> 00:15:08.080 Anda menguraikan ide 00:15:08.080 --> 00:15:08.960 dengan kata-kata alami, 00:15:09.100 --> 00:15:09.620 kerangka muncul, 00:15:09.900 --> 00:15:10.800 dan Anda bisa beriterasi 00:15:10.800 --> 00:15:11.740 hampir sedepat vibe coding 00:15:11.740 --> 00:15:12.900 sambil tetap mendapatkan manfaat 00:15:12.900 --> 00:15:13.980 dari struktur yang terorganisir. 00:15:14.440 --> 00:15:15.140 Mari kita ambil contoh 00:15:15.140 --> 00:15:15.800 alur kerja pelaporan. 00:15:16.340 --> 00:15:16.860 Biasanya, 00:15:17.020 --> 00:15:17.800 Anda harus membuat model, 00:15:18.160 --> 00:15:19.020 membangun layanan data, 00:15:19.480 --> 00:15:20.320 menyambungkan pengontrol, 00:15:20.480 --> 00:15:21.320 mengonfigurasi keamanan, 00:15:21.400 --> 00:15:22.280 dan menghubungkan semuanya 00:15:22.280 --> 00:15:22.920 saat startup. 00:15:23.760 --> 00:15:24.800 Itu berarti harus berpindah-pindah 00:15:24.800 --> 00:15:25.380 antar banyak file 00:15:25.380 --> 00:15:26.480 dan berharga konsistensi tercek. 00:15:27.140 --> 00:15:27.940 Dengan pendekatan ini, 00:15:28.040 --> 00:15:29.400 kerangka kerja terpasang sekaligus. 00:15:29.820 --> 00:15:30.860 Penghematan nyata datang 00:15:36.320 --> 00:15:36.780 membuatnya. 00:15:37.240 --> 00:15:37.620 Tentu saja, 00:15:37.780 --> 00:15:38.820 selalu ada pertanyaan tentangnya. 00:15:39.400 --> 00:15:40.340 Apakah ia akan memaksakan 00:15:40.340 --> 00:15:41.720 bui leplet atau mengambilkan konvensi? 00:15:42.460 --> 00:15:43.160 Dalam prakteknya, 00:15:43.240 --> 00:15:44.360 agen seringkali mencerminkan 00:15:44.360 --> 00:15:45.720 pola proyek yang ada dalam sarannya. 00:15:46.680 --> 00:15:47.040 Dalam demo, 00:15:47.140 --> 00:15:47.980 Anda akan melihat kedua sisi. 00:15:48.980 --> 00:15:50.000 Bagian di mana ia menyamai 00:15:50.000 --> 00:15:51.020 struktur pengontrol tim kami 00:15:51.020 --> 00:15:51.660 dengan sempurna, 00:15:51.820 --> 00:15:52.640 dan bagian di mana 00:15:52.640 --> 00:15:53.580 tebakannya meleset. 00:15:54.460 --> 00:15:55.220 Campuran itu penting. 00:15:55.700 --> 00:15:56.120 Anda akan tahu 00:15:56.120 --> 00:15:56.820 apa yang bisa dipercaya 00:15:56.820 --> 00:15:57.980 dan apa yang masih perlu disesuaikan. 00:15:58.480 --> 00:15:59.120 Hasil akhirnya bukanlah 00:15:59.120 --> 00:16:00.040 kode yang seringkan seperti dicatakan. 00:16:00.440 --> 00:16:01.800 Ini tetap terasa seperti proyek Anda 00:16:01.800 --> 00:16:02.760 hanya dengan pekerjaan penyusunan 00:16:06.320 --> 00:16:07.320 yang dapat dikembangkan 00:16:07.320 --> 00:16:08.500 untuk pertumbuhan di masa depan. 00:16:09.040 --> 00:16:09.820 Alih-alih pekerjaan, 00:16:09.900 --> 00:16:10.900 spesifikasi terbatas 00:16:10.900 --> 00:16:11.940 pada arsitek yang sabar 00:16:11.940 --> 00:16:12.600 membuat diagram. 00:16:12.820 --> 00:16:13.480 Ini menjadi alat 00:16:13.480 --> 00:16:14.360 bagi pengembang manapun 00:16:14.360 --> 00:16:15.300 yang ingin bereksperimen 00:16:15.300 --> 00:16:15.780 dengan cepat 00:16:15.780 --> 00:16:16.860 tanpa mengorbankan keteraturan. 00:16:18.140 --> 00:16:19.220 Dan ketika ini menjadi bagian 00:16:19.220 --> 00:16:20.380 dari alur kerja harian Anda, 00:16:20.540 --> 00:16:21.800 spesifikasi tidak lagi terasa 00:16:21.800 --> 00:16:23.080 seperti langkah formal perusahaan, 00:16:23.180 --> 00:16:24.520 melainkan seperti singkatan yang ringan. 00:16:25.100 --> 00:16:26.320 Anda mendeskripsikan niat Anda, 00:16:26.420 --> 00:16:27.540 sistem menyiapkan dasar-dasarnya, 00:16:27.740 --> 00:16:29.160 dan Anda fokus membentuk detailnya. 00:16:29.680 --> 00:16:30.520 Dampak yang lebih besar 00:16:30.520 --> 00:16:31.280 tidak hanya datang 00:16:31.280 --> 00:16:32.340 dari kode yang Anda hasilkan, 00:16:32.340 --> 00:16:33.400 tetapi dari apa arti 00:16:33.400 --> 00:16:34.340 penghematan waktu tersebut 00:16:34.340 --> 00:16:34.980 minggu demi minggu. 00:16:35.460 --> 00:16:36.540 Lebih banyak waktu untuk fitur 00:16:36.540 --> 00:16:37.180 lebih sedikit beban 00:16:37.180 --> 00:16:37.760 dalam pengaturan. 00:16:38.400 --> 00:16:39.400 Hal itu membawa kita langsung 00:16:39.400 --> 00:16:40.300 ke pertanyaan yang paling 00:16:40.300 --> 00:16:41.540 diperlukan oleh setiap pengembang. 00:16:41.960 --> 00:16:42.520 Apa sebenarnya 00:16:42.520 --> 00:16:43.560 dampak perubahan ini 00:16:43.560 --> 00:16:44.660 terhadap produktivitas? 00:16:45.680 --> 00:16:46.640 Keuntungan produktivitas 00:16:46.640 --> 00:16:48.360 Pertanyaan sebenarnya bukan 00:16:48.360 --> 00:16:49.180 apakah Anda menghemat 00:16:49.180 --> 00:16:50.280 beberapa menit di sana-sini, 00:16:50.440 --> 00:16:51.720 tetapi bagaimana perubahan kecil itu 00:16:51.720 --> 00:16:52.880 terakumulasi menjadi jam 00:16:52.880 --> 00:16:54.000 yang berhati sepanjang minggu. 00:16:55.100 --> 00:16:56.260 Inilah keuntungan produktivitas. 00:16:56.740 --> 00:16:57.400 Mendapatkan kembali 00:16:57.400 --> 00:16:58.380 waktu yang biasa terbuang 00:16:58.380 --> 00:16:59.360 tanpa disadari akibat 00:16:59.360 --> 00:17:00.060 peralihan konteks, 00:17:00.140 --> 00:17:00.860 siklus build berulang, 00:17:00.960 --> 00:17:01.680 dan penambaran manual. 00:17:02.480 --> 00:17:03.280 Kebanyakan pengembang 00:17:03.280 --> 00:17:04.460 menerima kerugian kecil itu 00:17:04.460 --> 00:17:05.420 sebagai bagian dari pekerja. 00:17:05.860 --> 00:17:06.580 10 menit di sini 00:17:06.580 --> 00:17:07.680 mencari nilai konfigurasi, 00:17:07.940 --> 00:17:09.220 15 menit lagi menjalankan ulang 00:17:09.220 --> 00:17:10.140 setelah referensi terlewat 00:17:10.140 --> 00:17:10.940 atau berpindah antar file 00:17:10.940 --> 00:17:11.660 untuk memperiksa koneksi. 00:17:12.260 --> 00:17:12.720 Sendiri-sendiri, 00:17:12.800 --> 00:17:13.460 hal itu terasa kecil. 00:17:13.980 --> 00:17:14.900 Namun, jika dicumlahkan 00:17:14.900 --> 00:17:15.740 sepanjang sprint penuh, 00:17:15.840 --> 00:17:16.560 hal itu membentuk 00:17:16.560 --> 00:17:17.640 seberapa banyak nilai aktual 00:17:17.640 --> 00:17:18.200 yang dikirimkan. 00:17:18.760 --> 00:17:19.500 Apa yang tampak seperti 00:17:19.500 --> 00:17:20.080 gerakan rutin 00:17:20.080 --> 00:17:21.060 menyembunyikan hambatan nyata 00:17:21.060 --> 00:17:21.800 pada di masa pengiriman. 00:17:21.800 --> 00:17:23.020 Beban tersembunyi 00:17:23.020 --> 00:17:23.640 bukanlah pada waktu 00:17:23.640 --> 00:17:24.980 kompilasi atau kecepatan mengetik, 00:17:25.440 --> 00:17:26.420 melainkan pada ritma berhenti 00:17:26.420 --> 00:17:27.540 mulai yang mengganggu konsentrasi. 00:17:27.760 --> 00:17:28.880 Setiap kali Anda berpindah 00:17:28.880 --> 00:17:29.700 dari satu file ke file lain, 00:17:29.780 --> 00:17:30.660 otak Anda melakukan riset. 00:17:31.220 --> 00:17:32.140 Reset tersebut memiliki hari. 00:17:32.600 --> 00:17:33.320 Melimpahkan koreksi 00:17:33.320 --> 00:17:34.020 berulang ke agen 00:17:34.020 --> 00:17:35.300 akan meringankan beban tersebut. 00:17:36.040 --> 00:17:36.800 Alih-alih terus-menerus 00:17:36.800 --> 00:17:37.740 membangun ulang konteks 00:17:37.740 --> 00:17:38.780 Anda mencurahkan fokus 00:17:38.780 --> 00:17:39.580 di tempat yang penting, 00:17:39.740 --> 00:17:40.640 yakni memecahkan 00:17:40.640 --> 00:17:41.620 masalah desain yang lebih besar. 00:17:42.440 --> 00:17:43.280 Banyak tim tidak melacak 00:17:43.280 --> 00:17:43.860 biaya mikro ini 00:17:43.860 --> 00:17:44.720 karena tidak muncul 00:17:44.720 --> 00:17:45.320 di tiket jira 00:17:45.320 --> 00:17:46.240 atau rewayat git. 00:17:46.240 --> 00:17:47.860 Pekerja yang tidak membuatkan 00:17:47.860 --> 00:17:48.580 hasil tidak tercatat 00:17:48.580 --> 00:17:49.760 tetapi tetap menghabiskan energi. 00:17:50.400 --> 00:17:51.260 Dan seiring skala besok 00:17:51.260 --> 00:17:51.660 yang meningkat, 00:17:51.760 --> 00:17:52.120 keseakan ini 00:17:52.120 --> 00:17:53.200 tidak hanya bertambah secara linear. 00:17:53.660 --> 00:17:54.540 Semakin banyak lapisan 00:17:54.540 --> 00:17:55.260 berarti semakin banyak 00:17:55.260 --> 00:17:56.360 dependensi yang harus diingat 00:17:56.360 --> 00:17:57.120 dan semakin besar 00:17:57.120 --> 00:17:58.060 kemungkinan kehilangan waktu 00:17:58.060 --> 00:17:58.920 hanya untuk menyelaraskan 00:17:58.920 --> 00:17:59.920 struktur sebelum bisa berlanjut. 00:18:00.360 --> 00:18:00.980 Alur kerja agen 00:18:00.980 --> 00:18:01.660 mengubah perhitungan 00:18:01.660 --> 00:18:02.320 dengan menargetkan 00:18:02.320 --> 00:18:03.280 penguras waktu ini secara langsung. 00:18:03.580 --> 00:18:04.080 Mereka tidak hanya 00:18:04.080 --> 00:18:04.780 mengisi stop metode 00:18:04.780 --> 00:18:05.320 dengan lebih jauh. 00:18:05.600 --> 00:18:06.260 Mereka mengurangi 00:18:06.260 --> 00:18:07.080 siklus pencarian, 00:18:07.240 --> 00:18:07.740 penambalan, 00:18:07.880 --> 00:18:08.620 dan menjalankan ulang 00:18:08.620 --> 00:18:09.600 yang menghabiskan waktu sore har. 00:18:09.900 --> 00:18:10.460 Tim yang menggunakan 00:18:10.460 --> 00:18:11.140 alur kerja agen 00:18:11.140 --> 00:18:12.000 melaporkan waktu tunggu 00:18:12.000 --> 00:18:12.520 yang lebih singkat 00:18:12.520 --> 00:18:13.240 untuk membuka blokir 00:18:13.240 --> 00:18:13.800 dalam banyak kasus. 00:18:14.260 --> 00:18:14.820 Dalam video ini, 00:18:14.940 --> 00:18:15.800 kami akan mendemonstrasikan 00:18:15.800 --> 00:18:16.760 satu tugas sebelum sesudah 00:18:16.760 --> 00:18:18.000 agar Anda dapat melilai dampaknya. 00:18:18.560 --> 00:18:19.260 Saya akan mencatat 00:18:19.260 --> 00:18:20.000 waktu yang dibutuhkan 00:18:20.000 --> 00:18:20.840 untuk mengimplementasikan 00:18:20.840 --> 00:18:21.700 fitur Azure yang sama 00:18:21.700 --> 00:18:22.180 secara manual 00:18:22.180 --> 00:18:23.000 lalu melakukannya lagi 00:18:23.000 --> 00:18:23.480 dengan agen 00:18:23.480 --> 00:18:24.340 agar Anda bisa melihat 00:18:24.340 --> 00:18:25.740 peningkatan produktivitas secara nyata. 00:18:26.240 --> 00:18:27.140 Dari sudut pandang bisnis, 00:18:27.260 --> 00:18:27.840 nilainya terlihat 00:18:27.840 --> 00:18:28.720 pada kecepatan proyek. 00:18:29.460 --> 00:18:30.140 Siklus yang lebih cepat 00:18:30.140 --> 00:18:30.820 bukan sekadar tentang 00:18:30.820 --> 00:18:31.620 kepuasan pengembang. 00:18:32.180 --> 00:18:32.800 Hal ini menentukan 00:18:32.800 --> 00:18:33.800 apakah fitur dari sekarang 00:18:33.800 --> 00:18:34.240 atau tertunda 00:18:34.240 --> 00:18:35.040 beberapa kuartal ke depan. 00:18:35.500 --> 00:18:36.140 Ini memengaruhi 00:18:36.140 --> 00:18:36.720 utang teknis 00:18:36.720 --> 00:18:37.440 karena lebih sedikit 00:18:37.440 --> 00:18:38.240 peretasan dan negasi 00:18:38.240 --> 00:18:38.980 yang menempuk di backup. 00:18:40.620 --> 00:18:41.360 Alur yang lebih lancar 00:18:41.360 --> 00:18:42.300 membuat tim bergerak maju 00:18:42.300 --> 00:18:42.820 dengan bersih 00:18:42.820 --> 00:18:43.820 alih-alih spring sebelumnya. 00:18:45.240 --> 00:18:45.960 Konsistensi tersebut 00:18:45.960 --> 00:18:46.760 menghasilkan lebih sedikit 00:18:46.760 --> 00:18:47.400 pemadaman masalah 00:18:47.400 --> 00:18:48.320 dan pengiriman yang lebih kuat 00:18:48.320 --> 00:18:48.720 seiring waktu. 00:18:49.200 --> 00:18:50.060 Ada juga faktor manusia. 00:18:50.660 --> 00:18:51.280 Satu hari yang hilang 00:18:51.280 --> 00:18:52.100 untuk mengejar kesalahan 00:18:52.100 --> 00:18:53.100 membuat insinyur menampunker. 00:18:53.680 --> 00:18:54.220 Begitu adalah 00:18:54.220 --> 00:18:55.260 pekerjaan desain yang bersih 00:18:55.260 --> 00:18:55.900 menjadi lebih sulit, 00:18:55.900 --> 00:18:56.500 detail terlewat 00:18:56.500 --> 00:18:57.300 dan kesalahan mulai muncul. 00:18:58.100 --> 00:18:58.720 Dengan mengalihkan 00:18:58.720 --> 00:18:59.860 perbaikan teknis ke agen, 00:19:00.040 --> 00:19:00.860 pengembang tetap waspada 00:19:00.860 --> 00:19:01.760 untuk durasi yang lebih lama. 00:19:02.700 --> 00:19:03.480 Fokus ekstra tersebut 00:19:03.480 --> 00:19:04.640 meningkatkan produktivitas 00:19:04.640 --> 00:19:05.480 dan kualitas sekaligus. 00:19:06.300 --> 00:19:07.380 Saat Anda tidak terbebani 00:19:07.380 --> 00:19:08.300 oleh hambatan berulang, 00:19:08.440 --> 00:19:09.420 Anda bebas berpikir luas 00:19:09.420 --> 00:19:09.980 dan merencanakan 00:19:09.980 --> 00:19:10.800 dengan lebih efektif. 00:19:11.200 --> 00:19:12.080 Perbedaannya dalam praktik 00:19:12.080 --> 00:19:12.680 terlihat seperti ini. 00:19:13.140 --> 00:19:13.780 Fungsi Azure baru 00:19:13.780 --> 00:19:14.520 dengan banyak binding 00:19:14.520 --> 00:19:15.440 dan integrasi layanan 00:19:15.440 --> 00:19:16.220 bisa memakan waktu 00:19:16.220 --> 00:19:16.940 hingga dua hari penuh 00:19:16.940 --> 00:19:17.900 jika dilakukan sendiri. 00:19:18.860 --> 00:19:19.800 Antara konfigurasi, 00:19:19.920 --> 00:19:20.320 pengujian, 00:19:20.480 --> 00:19:21.700 dan pelacakan balik referensi 00:19:21.700 --> 00:19:22.300 yang tidak cocok, 00:19:22.300 --> 00:19:23.660 tugas menjadi berlarut-larut. 00:19:24.380 --> 00:19:25.160 Dengan bantuan agen, 00:19:25.360 --> 00:19:25.800 fungsi yang sama 00:19:25.800 --> 00:19:26.920 bisa selesai dalam setengah hari. 00:19:27.640 --> 00:19:28.400 Bukan karena mengambil 00:19:28.400 --> 00:19:28.960 jalan pintas, 00:19:29.060 --> 00:19:29.840 tetapi karena pengaturan 00:19:29.840 --> 00:19:30.900 antar file dan orkestrasi 00:19:30.900 --> 00:19:31.720 berhasil dengan konsisten 00:19:31.720 --> 00:19:32.200 sejak awal. 00:19:32.600 --> 00:19:33.560 Lini masa menjadi singkat 00:19:33.560 --> 00:19:34.280 dengan menghilangkan 00:19:34.280 --> 00:19:34.860 awal yang salah 00:19:34.860 --> 00:19:35.720 dan upaya yang berlebihan. 00:19:36.340 --> 00:19:36.940 Beberapa pengembang 00:19:36.940 --> 00:19:37.960 menyuarakan kekhawatiran mewah. 00:19:38.300 --> 00:19:39.280 Apakah bergantung pada AI 00:19:39.280 --> 00:19:40.240 untuk menangani pemeliharaan 00:19:40.240 --> 00:19:40.800 akan menumpulkan 00:19:40.800 --> 00:19:41.520 keterampilan Anda sendiri? 00:19:41.760 --> 00:19:42.600 Perspektif itu seringkali 00:19:42.600 --> 00:19:43.480 melewatkan nampak geser. 00:19:44.160 --> 00:19:45.240 Melimpahkan pengaturan berulang 00:19:45.240 --> 00:19:46.320 tidak melemahkan keahlian Anda, 00:19:46.460 --> 00:19:47.140 melainkan menjaganya 00:19:47.140 --> 00:19:48.200 untuk desain dan arsitektur 00:19:48.200 --> 00:19:48.820 di mana penilaian 00:19:48.820 --> 00:19:49.720 menciptakan daya ungkit. 00:19:50.300 --> 00:19:50.780 Kenyataannya, 00:19:50.900 --> 00:19:51.640 Anda mendapatkan ruang 00:19:51.640 --> 00:19:52.560 untuk melatih pemecahan 00:19:52.560 --> 00:19:53.420 masalah tingkat tinggi 00:19:53.420 --> 00:19:54.340 alih-alih membuang energi 00:19:54.340 --> 00:19:55.180 untuk koreksi teknis. 00:19:55.540 --> 00:19:56.300 Jika Anda mencobanya, 00:19:56.400 --> 00:19:57.180 komentari berapa jam 00:19:57.180 --> 00:19:57.960 yang berhasil Anda hemat 00:19:57.960 --> 00:19:58.520 dalam satu sprint. 00:19:58.920 --> 00:20:00.180 Saya akan menarik tanggapan menarik 00:20:00.180 --> 00:20:00.960 dalam video yang mendatang. 00:20:01.360 --> 00:20:02.380 Mendengar bagaimana tim lain 00:20:02.380 --> 00:20:03.300 mengalami perubahan ini 00:20:03.300 --> 00:20:04.340 memberi semua orang gambaran 00:20:04.340 --> 00:20:04.880 yang lebih baik 00:20:04.880 --> 00:20:05.740 tentang nilai sebenarnya 00:20:05.740 --> 00:20:06.780 di luar demo dan contoh. 00:20:07.520 --> 00:20:08.080 Catalan peringatan 00:20:08.080 --> 00:20:09.260 otomatisasi memang membantu 00:20:09.260 --> 00:20:10.240 tetapi keamanan tetap tentu. 00:20:10.800 --> 00:20:11.860 Selalu jalankan pengujian Anda 00:20:11.860 --> 00:20:12.840 dan gunakan tinjauan kode 00:20:12.840 --> 00:20:13.800 untuk memvalidasi perubahan 00:20:13.800 --> 00:20:14.340 yang dibuat lagi. 00:20:14.920 --> 00:20:15.680 Perjalanan pekerjaan 00:20:15.680 --> 00:20:16.120 yang menyembuhkan 00:20:16.120 --> 00:20:16.600 akan berkurang 00:20:16.600 --> 00:20:17.260 tetapi tetap jaga 00:20:17.260 --> 00:20:18.060 batasan keamanan yang ada. 00:20:18.540 --> 00:20:19.300 Perbedaan kecepatan 00:20:19.300 --> 00:20:20.100 hanya akan membuatkan hasil 00:20:20.100 --> 00:20:21.000 jika kualitas tetap tentu. 00:20:21.400 --> 00:20:22.240 Pengujian yang kuat 00:20:22.240 --> 00:20:23.080 dan tinjauan PR 00:20:23.080 --> 00:20:23.900 yang cerdas melindungi 00:20:23.900 --> 00:20:24.520 jalur rilis Anda 00:20:24.520 --> 00:20:25.640 dari otomatisasi yang rapat. 00:20:26.280 --> 00:20:27.060 Hasilnya bukan tentang 00:20:27.060 --> 00:20:28.000 menghasilkan baris kode 00:20:28.000 --> 00:20:28.560 dengan cepat, 00:20:28.860 --> 00:20:29.820 tetapi tentang memberi ruang 00:20:29.820 --> 00:20:30.800 untuk menciptakan solusi 00:20:30.800 --> 00:20:31.340 yang lebih kuat 00:20:31.340 --> 00:20:32.380 dengan lebih sedikit 00:20:32.380 --> 00:20:32.880 dan lebih sedikit.