Latest / M365.FM – Podcast Microsoft 365, Copilot & AI Bahasa Indonesia / Hentikan Debugging Tambal Sulam: Mode Agen GitHub Copilot untuk .NET dan Azure (Sulih Suara AI)

Transcript

Hentikan Debugging Tambal Sulam: Mode Agen GitHub Copilot untuk .NET dan Azure (Sulih Suara AI) · M365.FM – Podcast Microsoft 365, Copilot & AI Bahasa Indonesia

0:00
Siap untuk 10 hari Microsoft 365, Copilot, AI, Azure, dan orang-orang yang membentuk masa depan kerja.
0:07
Januari ini, M365 CUN kembali dan kami hadir lebih besar.
0:12
Bergabunglah dengan kami dalam sesi langsung demo dunia nyata dan pengetahuan praktis dari MVP serta pakar industri di seluruh dunia.
0:18
Tanpa slide yang umum, tanpa jargon yang tidak habisnya.
0:21
Kami menangani tantangan nyata, Copilot Studio, agen AI, fabrik, keamanan, tata kelola, dan otomatisasi.
0:28
Baik Anda seorang profesional IT, pengembang, atau pemimpin bisnis, ada sesi yang dirancang untuk Anda.
0:35
Dengan 10 hari penuh, Anda dapat menjelajahi berbagai teknologi dan terhubung dengan komunitas global.
0:40
Tonton langsung dan bawa wawasan praktis kembali ke organisasi Anda.
0:45
Januari 2021, 10 hari, satu komunitas Microsoft.
0:49
Pendaftaran sudah dibuka sekarang.
0:51
Buka M365 Con.net dan amankan tempat Anda hari ini.
0:55
Itu M365 Con.net.
1:00
Bergabunglah sekarang di M365 Con.net dan sampai jumpa secara langsung di bulan Januari.
1:05
Jika Anda pernah membuka solusi dan langsung merasa kewalahan dengan jaring file, referensi, dan bug yang menunggu untuk menjepak Anda, Anda tidak sendirian.
1:12
Kebanyakan pengembang bekerja secara aktif menambah di sana memperbaiki bug.
1:15
Mode agen GitHub Copilot bertujuan untuk menahan konteks yang lebih luas dan mengordinasikan perubahan di seluruh file.
1:19
Dalam video ini, kami akan mendemonstrasikan bagaimana alur kerja itu terlihat di dalam proyek nyata podcast.net dan Azure.
1:25
Kami akan menunjukkan solusi langsung dan menunjukkan sebelum dan sesudah perubahan.
1:28
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.
1:36
Dan sebelum kita sampai di sana, mari kita mulai dengan biaya tersembunyi dari siklus debugging yang sering kita alami setiap hari.
1:42
Biaya tersembunyi dari debugging tambah sulam.
1:43
Anda duduk untuk memperbaiki kesalahan yang terlihat cukup sederhana.
1:46
Aplikasi tidak dapat dibangun, dan konsol menandai baris dalam file proyek utama Anda.
1:50
Anda mengubah metode tersebut, menyusun ulang, dan mengenat telah menyelesaikannya sampai pesan yang sama muncul kembali dalam bentuk yang sedikit lebih.
1:56
Setengah jam berlalu sebelum Anda menemukan masalah yang sebenarnya.
1:59
Dependensi yang hilang terselip di folder proyek lain.
2:02
Saat referensi diperbaiki dan Anda menerapkan ulang, sebagian besar sore Anda telah habis untuk tambah sulam.
2:07
Pekerjaan fitur yang Anda rencanakan ditunda hingga besok.
2:10
Pola ini sangat umum sehingga terasa normal.
2:12
Di permukaan Anda merasa maju karena setiap bug yang Anda basmi terasa seperti kemenang.
2:16
Pada praktiknya Anda berputar-putar.
2:17
Siklusnya adalah kode, kompilasi kesalahan perbaikan ulang.
2:20
Waktu bejam-jam hilang untuk mengejar jejak sebab dan akibat, dan hasil akhirnya adalah kemajuan reaktif bukan perbaikan yang beraktif.
2:27
Berapa banyak dari Anda yang kehilangan satu sore kan siklus yang persis seperti ini?
2:29
Tulis satu baris komentar, saya akan membaca belasan-belasan teratas.
2:32
Hal yang membuat siklus ini melelahkan adalah perangkat di sekitar kita terus berkembang, sementara polanya tidak.
2:37
Editor menambah fitur baru, framework berevolusi, dan integrasi semakin dalam.
2:41
Namun, debanging tetap menuntut pendekatan reaktif.
2:44
Ini seperti mencoba menahan api yang membesar dengan seember air.
2:47
Setiap kobaran di tangan yang satu juga, namun kondisi dasar penyebabnya tetap ada, hampir menjamin munculnya api berikutnya.
2:53
Dan dengan setiap perpindahan tab, biaya tersebutnya pun meningkat.
2:55
Anda berpindah dari kelas layanan ke file konfigurasi, lalu melompat ke grafik dependensi.
3:00
Setiap perpindahan menarik Anda keluar dari alur logika apapun yang sedang Anda pegang, memaksa pengaturan ulang mental.
3:04
Ini bukan hanya soal detik yang terbuang saat berpindah jendela, melainkan beban mental untuk membangun kembali konteks berulang kali.
3:10
Sepanjang hari, pengaturan ulang kecil itu menumpuk menjadi sesuatu yang berat.
3:13
Bagi pengembang individu, kelahan ini muncul sebagai rasa frustrasi dan waktu yang terlalu.
3:17
Bagi tim yang mengerjakan proyek skala perusahaan, dampaknya berlipat ganit.
3:19
Lingkaran debaging menghambat tujuan sprint, menunda peluncuran fitur, dan membuka backlog yang tumbuh lebih cepat daripada yang diselesaikan.
3:26
Pemuatan utang teknis hanyalah efek samping lain dari jam kerja yang hilang akibat pemadaman api.
3:31
Banyak tim melaporkan bahwa sebagian besar waktu pengembangan mereka tersedot ke dalam debaging reaktif.
3:36
Itu bukanlah bagian menarik dari teknik.
3:37
Tidak ada yang merencanakan peta jalan untuk mengejar ketidakcocokan dependensi yang sama sebanyak 5 kali.
3:41
Namun di sini bandwit terbuang minggu demi minggu.
3:43
Ketika memperbaiki kesalahan menjadi definisi kemajuan, membangun fitur baru menjadi sekunder dan arsitektur menderita secara diam-diam di latar belakang.
3:51
Kenyataan yang tidak nyaman adalah bahwa debaging tambal sulam tidak hanya memperlambat segalanya.
3:55
Hal itu memperkuat budaya reaktif alih-alih desain.
3:58
Anda menghabiskan waktu untuk memadamkan api, bukan membangun sistem.
4:01
Itu mungkin menjaga produk tetap hidup dalam jangka pendek, tetapi membatasi seberapa jauh tim dapat berskala dan seberapa percaya diri mereka untuk merilisnya.
4:08
Jadi mari kita berhenti sinak pada gaman api.
4:10
Lari ke titik panas, siram air, lanjut lagi.
4:12
Masalahnya bukan karena pengembang tidak alih-alih itu.
4:15
Mereka ahli.
4:16
Masalahnya adalah apinya tidak pernah menampan.
4:18
Api itu hanya berpindah-pindah, berkobat di file baru, proyek baru, konfigurasi baru, membuat semua orang berada dalam mode respons, bukan mode kreasi.
4:25
Hal itu menimbulkan pertanyaan, apa yang terjadi jika sikus tersebut tidak hanya dibebankan pada Anda?
4:29
Bagaimana jika bagian yang berulang, lingkaran pelacakan, perpindahan, dan penambalan bisa dikelola secara berbeda sementara Anda tetap fokus membangun?
4:36
Karena meskipun tekanan dari pemadaman api itu jelas, ada titik tekanan lain yang belum kita sentuh.
4:40
Beban sesungguhnya muncul saat proyek Anda bukan sekadar satu file atau satu mode, yaitu saat perbaikan yang Anda butuhkan mencakup beberapa lapisan sekaligus.
4:48
Bayangkan saat Anda membuka sebuah solusi di mana logikanya tersebar di berbagai proyek, layanan, dan pustaka.
4:53
Bagian yang Anda perlukan ada di tiga tempat sekaligus, dan menjaga alurnya di kepala adalah tantangan tersendiri.
5:01
Kekacauan multifile versus kendali konteks AI
5:03
Saat proyek mencakup banyak lapisan, tantangan sebenarnya bukanlah menulis kode.
5:08
Tantangannya adalah menjaga semua bagian yang bergerak agar tetap selamat.
5:10
Disinilah ketegangan antara kekacauan multifile dan kendali konteks berbasis AI terlihat paling jelas.
5:16
Ambil contoh solusi internet besar dengan belasan proyek atau lebih.
5:19
Setiap fitur baru biasanya menyentuh lapisan yang berbeda secara bersama.
5:22
Pengontrol di satu tempat, layanan di tempat lain, dan sekumpulan file konfigurasi yang berbeda di tempat yang berbeda.
5:27
Sebelum menulis satu baris kode, Anda menghabiskan waktu menulisuri referensi dan meriksa dependensi berharap perubahan kecil tidak menyebabkan kerusakan tak terduga di bagian lain.
5:36
Alur kerja itu bukanlah pengecualian.
5:37
Itu hal normal dalam aplikasi perusahaan, terutama saat layanan Azure dan integrasinya mulai terlibat.
5:42
Struktur sistem seperti ini tidaklah data.
5:45
Antarmuka, pemeta injeksi dependensi, dan referensi lintas proyek semuanya berperan.
5:49
Dengan Azure, beberapa dependensi berada sepenuhnya di luar folder solusi seperti function apps, bending service bus, pengaturan sumber daya, dan koneksi.
5:57
Penyimpanan
5:57
Anda harus mengordinasikan kode di IDE, file konfigurasi di disk, dan layanan yang didefinisikan di cloud.
6:04
Semua itu tidak peduli bahwa Anda ingin lebih sedikit.
6:06
Tiap kali Anda beralih kontek, Anda menghabiskan energi untuk menyusun kembali gambaran besarnya.
6:10
Kebanyakan dari kita mencoba menjaga kontek tersebut dalam memori.
6:13
Awalnya terasa bisa dikelola, tapi seiring berkembangnya proyek, kesalahan mulai menyelinap.
6:16
Anda menambahkan metode baru di layanan tetapi lupa registrasi DE-nya.
6:19
Anda membuat kode Azure function dan baru menyadari kemudian bahwa bending belum ditambahkan ke host.json atau template penerapan.
6:25
Tidak ada yang memberitahu Anda sampai saat runtime ketika Anda sedang dibangin alimbang.
6:28
Kode itu sendiri bukan abangin yang sebut.
6:30
Yang sulit adalah koordinasi lintas web.
6:32
Semua orang tahu rasanya berpindah-pindah tab dari pengontrol ke layanan, lalu ke model, kemudian ke file konfigurasi,
6:37
lalu kembali lagi hanya untuk lupa alasan Anda membuka file tersebut.
6:41
Itu adalah gangguan kecil yang berulang puluhan kali dalam sehari.
6:45
Interaksi tersebut menumpuk, menciptakan hambatan yang menghambat kemajuan nyata.
6:48
Hasilnya adalah pengiriman yang lebih lambat, bukan karena penulisan kodenya lambat,
6:51
tetapi karena menjaga semuanya tetap sinkron mengulas fokus, beban kerja tambahan ini semakin besar dalam kue Cloud First.
6:57
Azure menempatkan pengaturan utama di berbagai tempat, file, konfigurasi lokal, variabel lingkungan, template ARM atau BCHAP,
7:04
ya pipeline CI per CD.
7:06
Apa yang terlihat sebagai permintaan fitur tunggal seringkali tersebar di empat lapisan abstraksi?
7:11
Flexitas ini bukanlah pilihan.
7:12
Hal ini sudah menjadi bagian dari cara ekosistem bekerja.
7:15
Nah, disinilah agent mode hadir sebagai sebuah perubahan potensial.
7:17
Alia membiarkan Anda mengatur semuanya, fitur ini dirancang untuk menampung konteks yang lebih luas di berbagai file.
7:23
Itu berarti saat Anda meminta perubahan pada satu lapisan, lapisan lainnya tidak akan terbaik.
7:27
Dalam demo ini, saya akan membuat fungsi Azure baru dan menunjukkan bagaimana agent membantu dengan membuat isi metode,
7:32
menyusun konfigurasi bending, memperbarui host.
7:35
JSON bahkan menyarankan registrasi dia yang tepat.
7:38
Biasanya itu adalah proses multilangkah yang tersebar di berbagai file berbeda.
7:41
Agen dapat menyederhanakannya menjadi satu alur kerja.
7:43
Ini bukan tentang menggantikan penilaian Anda, tetapi tentang menghilangkan tugas administratif yang berulang
7:47
agar Anda bisa fokus pada pilihan desain yang sebenarnya.
7:50
Manusia bisa menyimpan kerangka kasar di kepala atau mencoretnya di papan tulis.
7:54
AI dapat melacak detail demi detail file tanpa kehilangan alurnya.
7:58
Apa yang terasa sebagai beban kognitif besar bagi kita hanyalah konteks dasar bagi agen.
8:02
Perbedaannya dalam prakteknya adalah beralih dari menyulap banyak tab keperubahan terorkestrasi yang tetap sinkron.
8:06
Saya juga akan menampilkan pull request atau div yang dibuat agen selama demo
8:10
agar Anda bisa melihat dengan jelas editan apa saja yang dilakukan.
8:12
Visibilitas itu sangat penting.
8:14
Anda mendapatkan kendali penuh untuk meninjau
8:15
dan menyetujui sementara tugas berat memperbarui banyak file dilakukan untuk Anda.
8:19
Jadi, daripada menghabiskan sore untuk menyambungkan fragment,
8:21
Anda cukup mengarahkan perubahan sekali,
8:22
mengonfirmasi pembaruan yang dihasilkan dan beralih ke desain tingkat tinggi.
8:26
Keringanan yang dirasakan bukan hanya karena hemat klik atau ketikan,
8:29
melainkan karena tetap fokus pada penyelesaian masalah nyata
8:31
daripada melusuri bagaimana belasan file terhubung.
8:34
Keunggulan ini terlihat paling jelas saat ada yang rusak
8:36
karena meski dengan penanganan konteks yang lebih kuat,
8:38
sistem bisa gagal, konfigurasi melenceng, dan referensi yang tidak cocok muncul kembali.
8:42
Dan disitulah ujian berikutnya dimulai,
8:44
bagaimana kesalahan dilacak dan diselesaikan setelah muncul.
8:47
Dari perburung kesalahan hingga perbaikan otonom,
8:49
pikirkan seberapa sering Anda menemui pesan kesalahan
8:51
yang mengarah langsung ke satu file saja,
8:53
Anda mengikuti stack trace ke metode yang disebutkan,
8:55
melakukan sedikit penyesuaian, lalu menekan tombol rebuild.
8:58
Itu terasa seperti solusi yang jelas,
9:00
sampai kesalahan yang sama muncul kembali dalam bentuk yang sedikit berbeda.
9:03
Saatilah Anda menyadari bahwa stack trace hanya menunjukkan dijalani.
9:06
Masalah sebenarnya ada di tempat lain,
9:07
mungkin di kelas mendukung atau tersembunyi
9:09
dalam file konfigurasi yang belum Anda buka sepanjang minggu.
9:12
Setiap pengembang pernah menghadapi pengalaman perhatian seperti itu.
9:14
Apa yang terlihat sebagai masalah sebenarnya
9:15
bukan di mana perbaikan yang harus dilakukan.
9:17
Hal ini menghabiskan waktu dengan Anda menyesuaikan satu hal
9:19
membangun ulang alaman.
9:20
Kemudian kesalahan baru menyambut Anda,
9:22
membawa ke file lain penyesuaian lain,
9:23
penyesuaian lain, dan pembangun.
9:25
Lingkaran ini tampak produktif karena Anda bergerak,
9:27
mengetik, menyusun ulang.
9:28
Tetapi di baliknya ini,
9:29
lebih berupa coba-coba daripada penyelesaian nyata.
9:31
Siklus itu bisa menelan waktu berjam-jam,
9:34
menyisakan perbaikan kecil di permukaan
9:36
tanpa kemajuan nyata pada fitur yang Anda kerjakan.
9:38
Biaya sebenarnya di sini adalah peluang.
9:41
Saat terjebak dalam ritme membangun dan mencoba ulang,
9:43
Anda tidak memecahkan masalah bisnis
9:44
atau merilis fungsionalitas yang ditunggu pengguna.
9:48
Momentum habis untuk menebak-nebak, bukan merancang.
9:50
Rasanya aktif saat itu,
9:51
tetapi jam-jam tersebut tidak berarti banyak
9:53
selain menjaga sistem agar tidak rusak.
9:56
Dalam sebuah tim,
9:57
pergerakan dangkal ini memperlambat segalanya
9:59
dan menciptakan tumpukan fitur yang terus tertunda.
10:02
Di sinilah alur kerja agen mulai terlihat berbeda.
10:05
Ide-nya bukan berhenti pada satu baris
10:06
yang disorot oleh pelacaan tumpukan setiap tes.
10:08
Sebaliknya,
10:09
ia dirancang untuk memiliki konteks tingkat sistem.
10:11
Bertanya bukan hanya apa yang harus dilakukan file ini,
10:13
tetapi urutan perubahan apa yang diperlukan
10:15
di bagian terkait untuk memulihkan konsistensi.
10:18
Dalam prakteknya,
10:19
itu berarti Anda mungkin melihatnya
10:20
mengusuhkan pengeditan yang mencakup beberapa file.
10:22
Sebagai contoh,
10:23
Anda akan melihat dalam demo
10:24
bahwa ketika sebuah metode memerlukan perubahan,
10:26
ia dapat menyarankan pengeditan yang cocok di konfigurasi terkait
10:28
atau tempat penyebaran lain
10:31
dari pelengkapan otomatis autocomplik ke sesuatu yang lebih luk.
10:34
Pelengkapan otomatis menyelesaikan baris
10:35
sementara agen berkoordinasi antar file
10:37
dan koordinasi itu paling penting
10:38
saat kesalahan tidak berada di satu tempat.
10:41
Ambil skenario azur yang umum.
10:42
Anda membuat aplikasi fungsi baru,
10:44
tetapi setelah diterapkan,
10:45
pemicu antrean gagal
10:46
karena pengingkatan tidak cocok dengan tanda tangan metode.
10:48
Biasanya,
10:49
Anda memeriksa log,
10:50
mencari tahu pengingkatan mana yang salah,
10:52
menyesuaikan.
10:52
JSON fungsi secara manual
10:53
bahkan mungkin mengubah template infrastruktur
10:55
jika nilainya juga tidak cocok di sana.
10:56
Setiap langkah adalah
10:58
pengejaran terpisah
10:59
dan setiap perbaikan
11:00
memicu pengunjian ulangan lainnya.
11:02
Dengan moda agen,
11:02
alur kerjanya berbeda.
11:04
Ia dapat mengusulkan perubahan kode,
11:05
membuat pengikatan JSON fungsi yang tepat,
11:07
dan menampilkan pengeditan
11:08
untuk skrip penyebaran
11:09
jika tidak selaras.
11:10
Anda meninjau mengonfirmasi
11:11
dan melangkah maju
11:12
tanpa menghabiskan berjam-jam
11:13
menyatukan setiap lapisan
11:14
dan kepercayaan kuncinya di sini.
11:16
Tidak seorang pun boleh merasa
11:17
seolah ada pengeditan
11:17
terjadinya terbaik.
11:19
Itulah mengapa alur peninjauan itu.
11:20
Dalam demo ini,
11:21
kita akan melalui bersama-sama.
11:22
Agen menyarankan perubahan
11:23
yang terkoordinasi tersebut.
11:24
Kita akan membuka div
11:25
untuk memeriksa dengan saksama
11:26
apa yang dihasilkan,
11:28
menjalankan unit tes kita,
11:29
memvalidasi build secara lokal,
11:30
lalu memutuskan apakah akan menerima
11:31
atau menolak suntikan tersebut.
11:33
Siklus validasi tersebut
11:34
membuat Anda tetap
11:35
memegang kendali penuh
11:35
sembari menghilangkan pekerjaan kasar.
11:37
Perlu ditekankan,
11:38
agen memang dapat membantu
11:39
bergerak lebih cepat,
11:40
tetapi mereka tidak menggantikan
11:41
praktek rekaya SMA.
11:42
Anda tetap harus memperlakukan
11:43
tinjauan kode dan CI
11:44
sebagai gerbang yang tidak bisa diterima.
11:45
Biarkan AI mengurangi waktu
11:46
yang Anda habiskan
11:47
untuk pekerjaan detektif,
11:48
tetapi tetap gunakan
11:48
pemeriksaan otomatis
11:49
dan tinjauan manusia
11:50
sebagai jaring pengaman.
11:51
Keseimbangan tersebut
11:52
memecahkan masalah kepercayaan
11:53
dan memastikan peningkatan
11:54
kecepatan tidak merusak stabil.
11:56
Perbedaan kecepatan ini
11:56
bukanlah teoretis.
11:57
Jika mengejar error
11:58
dan patching manual
11:59
bisa memakan waktu setengah hari,
12:00
saran terkoordinasi
12:01
bisa memangkasnya
12:01
menjadi hitungan menit.
12:03
Dan waktu yang didapatkan kembali
12:05
mengalik ke pekerjaan
12:05
yang benar-benar ingin Anda fokuskan.
12:07
Fitur yang disadari pengguna Anda
12:08
keputusan arsitektur
12:09
yang meningkatkan basis kode Anda.
12:11
Alih-alih memadamkan api
12:12
saat runtime,
12:13
Anda bisa merancang
12:14
dengan percaya diri sejak awal.
12:15
Jadi siklus debaging
12:16
tidak perlu lagi
12:16
meneminasi hari Anda.
12:18
Dengan agen
12:19
yang menyarankan
12:19
pembaruan intas file,
12:20
Anda beralih dari pencarian
12:21
yang tidak terarah
12:21
ke ritme tinjau dan setujui.
12:23
Anda berhenti berputar-putar
12:25
mencari error
12:25
dan mulai memperlakukan debaging
12:26
sebagai langkah terstruktur
12:27
yang hampir otomatis
12:28
dalam alur kerja Anda.
12:30
Perubahan itu
12:30
mengosongkan ruang kognitif
12:32
dan jam kalender
12:32
untuk membangun fitur
12:33
bukan sekadar menambil kekurangan.
12:34
Dan begitu memperbaiki error
12:36
tidak lagi sekadar manajer gejala
12:37
itu membuka pintu
12:38
menuju sesuatu yang lebih besar.
12:39
Bagaimana Anda bisa memulai fitur
12:40
secara keseluruhan
12:41
dengan cara terstruktur yang sama?
12:42
Bayangkan jika alur kerja yang sama
12:44
yang mengusulkan perbaikan terkoordinasi
12:46
juga dapat mengambil spesifikasi
12:47
bahasa sederhana
12:48
dan membentuk struktur kerja di sekitarnya.
12:50
Disitulah tahap pengembangan
12:51
selanjutnya dimulai.
12:53
Pengembangan berbasis
12:54
spesifikasi tambahan barang.
12:55
Salah satu perubahan
12:56
paling menarik
12:57
muncul saat Anda berhenti
12:58
berpikir hanya dalam
12:59
hal-file dan metode
12:59
lalu mulai membingkai
13:01
pekerjaan dalam bahasa sederhana.
13:03
Disitulah pengembangan
13:04
berbasis spesifikasi
13:04
tambahan-bahan barang.
13:06
Bayangkan menulis
13:06
permintaan fitur sederhana.
13:08
Tambahkan alur kerja pelaporan
13:09
yang menghasilkan ringkasan bulanan
13:11
menyimpannya
13:11
dan menyediakannya
13:12
melalui halaman admin.
13:14
Alih-alih hanya mendapatkan
13:15
beberapa potongan kode terisolasi
13:16
Anda mendapatkan struktur kerja
13:18
yang sudah dipetakan
13:18
di seluruh aplikasi Anda.
13:20
Kontroller dibuat setapnya,
13:21
model dibuat,
13:21
layanan didaftarkan,
13:22
dan konfigurasi dihubungkan.
13:24
Perubahan dari
13:25
menggambarkan niat
13:26
hingga melihat kerangka konkret
13:27
muncul di proyek Anda
13:28
adalah saat pendekatan ini
13:29
akhirnya terasa praktis
13:30
bukan teoretis.
13:31
Bukan teoret.
13:32
Dalam pengaturan tradisional,
13:33
pengembangan yang mengutamakan
13:34
spesifikasi memiliki reputasi.
13:35
Di organisasi besar,
13:36
ini biasanya berarti
13:37
dokumen persyaratan yang panjang,
13:38
lembar desain multi halaman,
13:40
dan diagram kaku
13:40
yang memperlambat semua orang.
13:42
Hal itu masuk akal
13:42
di industri yang diatur ketat
13:43
atau team yang tersebar secara global.
13:45
Tetapi untuk pengkodian sehari-hari
13:46
sebagian besar pengembang melewatkannya.
13:47
Menulis dan memelihara spesifikasi
13:49
meletal menambah biaya
13:49
yang tidak punya waktu
13:50
atau kesabaran untuk dikualasi waktu.
13:52
Ini adalah beban tambahan
13:53
di atas pengiriman fitur
13:54
dan seiring mendekatnya
13:55
tenggat waktu,
13:56
upaya ekstra itu
13:56
biasanya dikorbankan.
13:58
Ironnya jelas,
13:58
pengembang sebenarnya
13:59
suka berpikir dalam keberan
14:00
yang lebih luas.
14:01
Mengetahui struktur lebih awal
14:03
terasa melegakan.
14:04
Masalahnya bukan pada niatnya,
14:05
melainkan pemulihan.
14:06
Begitu spesifikasi
14:07
mulai tidak sinkron dengan kenyataan,
14:08
pemeliharaannya menjadi beban.
14:10
Itulah sebabnya
14:11
banyak pekerjaan nyata
14:12
cenderung ke arah improvisasi
14:13
daripada desain lengkap
14:14
bahkan di perusahaan
14:15
yang secara teknis
14:16
mendukung perencanaan matang.
14:18
Alur kerja agen menawarkan alternatif.
14:20
Alih-alih menuntut dokumen desain
14:21
yang sempurna,
14:22
agen bisa membantu
14:22
menerjemahkan spesifikasi
14:23
bahasa awal menjadi
14:24
kerangka yang bisa Anda sempurnakan.
14:26
Anda tidak butuh diagram UML
14:28
atau peta antar muka tulisan tangan.
14:30
Anda cukup berkata
14:31
buat modul laporan
14:31
dengan endpoint API baru,
14:33
tautkan ke penyimpanan
14:34
dan amankan akses berbasis peran,
14:36
lalu sistem akan menghasilkan
14:37
dasar di seluruh file
14:38
solusi.net Anda.
14:40
Dalam demo ini,
14:41
saya akan membacakan
14:42
spesifikasi bahasa awal,
14:43
lalu menunjukkan file
14:44
yang dibuat agen,
14:45
pengontrol, model,
14:46
dan pendaftaran layanan,
14:48
serta menunjukkan bagian
14:49
yang masih perlu perbaikan manual.
14:51
Dengan begitu,
14:51
Anda bisa menirai kualitasnya sendiri.
14:53
Ini menciptakan jalan tengah
14:54
di antara dua mode pengembang.
14:56
Di satu sisi,
14:57
ada vibe coding cepat,
14:58
bebas,
14:58
namun rapuh
14:59
untuk sistem jangka panjang.
15:01
Di sisi lain,
15:01
ada desain berbasis spesifikasi,
15:03
andal namun sangat lambat.
15:06
Dengan dukungan agen,
15:07
Anda menguraikan ide
15:08
dengan kata-kata alami,
15:09
kerangka muncul,
15:09
dan Anda bisa beriterasi
15:10
hampir sedepat vibe coding
15:11
sambil tetap mendapatkan manfaat
15:12
dari struktur yang terorganisir.
15:14
Mari kita ambil contoh
15:15
alur kerja pelaporan.
15:16
Biasanya,
15:17
Anda harus membuat model,
15:18
membangun layanan data,
15:19
menyambungkan pengontrol,
15:20
mengonfigurasi keamanan,
15:21
dan menghubungkan semuanya
15:22
saat startup.
15:23
Itu berarti harus berpindah-pindah
15:24
antar banyak file
15:25
dan berharga konsistensi tercek.
15:27
Dengan pendekatan ini,
15:28
kerangka kerja terpasang sekaligus.
15:29
Penghematan nyata datang
15:36
membuatnya.
15:37
Tentu saja,
15:37
selalu ada pertanyaan tentangnya.
15:39
Apakah ia akan memaksakan
15:40
bui leplet atau mengambilkan konvensi?
15:42
Dalam prakteknya,
15:43
agen seringkali mencerminkan
15:44
pola proyek yang ada dalam sarannya.
15:46
Dalam demo,
15:47
Anda akan melihat kedua sisi.
15:48
Bagian di mana ia menyamai
15:50
struktur pengontrol tim kami
15:51
dengan sempurna,
15:51
dan bagian di mana
15:52
tebakannya meleset.
15:54
Campuran itu penting.
15:55
Anda akan tahu
15:56
apa yang bisa dipercaya
15:56
dan apa yang masih perlu disesuaikan.
15:58
Hasil akhirnya bukanlah
15:59
kode yang seringkan seperti dicatakan.
16:00
Ini tetap terasa seperti proyek Anda
16:01
hanya dengan pekerjaan penyusunan
16:06
yang dapat dikembangkan
16:07
untuk pertumbuhan di masa depan.
16:09
Alih-alih pekerjaan,
16:09
spesifikasi terbatas
16:10
pada arsitek yang sabar
16:11
membuat diagram.
16:12
Ini menjadi alat
16:13
bagi pengembang manapun
16:14
yang ingin bereksperimen
16:15
dengan cepat
16:15
tanpa mengorbankan keteraturan.
16:18
Dan ketika ini menjadi bagian
16:19
dari alur kerja harian Anda,
16:20
spesifikasi tidak lagi terasa
16:21
seperti langkah formal perusahaan,
16:23
melainkan seperti singkatan yang ringan.
16:25
Anda mendeskripsikan niat Anda,
16:26
sistem menyiapkan dasar-dasarnya,
16:27
dan Anda fokus membentuk detailnya.
16:29
Dampak yang lebih besar
16:30
tidak hanya datang
16:31
dari kode yang Anda hasilkan,
16:32
tetapi dari apa arti
16:33
penghematan waktu tersebut
16:34
minggu demi minggu.
16:35
Lebih banyak waktu untuk fitur
16:36
lebih sedikit beban
16:37
dalam pengaturan.
16:38
Hal itu membawa kita langsung
16:39
ke pertanyaan yang paling
16:40
diperlukan oleh setiap pengembang.
16:41
Apa sebenarnya
16:42
dampak perubahan ini
16:43
terhadap produktivitas?
16:45
Keuntungan produktivitas
16:46
Pertanyaan sebenarnya bukan
16:48
apakah Anda menghemat
16:49
beberapa menit di sana-sini,
16:50
tetapi bagaimana perubahan kecil itu
16:51
terakumulasi menjadi jam
16:52
yang berhati sepanjang minggu.
16:55
Inilah keuntungan produktivitas.
16:56
Mendapatkan kembali
16:57
waktu yang biasa terbuang
16:58
tanpa disadari akibat
16:59
peralihan konteks,
17:00
siklus build berulang,
17:00
dan penambaran manual.
17:02
Kebanyakan pengembang
17:03
menerima kerugian kecil itu
17:04
sebagai bagian dari pekerja.
17:05
10 menit di sini
17:06
mencari nilai konfigurasi,
17:07
15 menit lagi menjalankan ulang
17:09
setelah referensi terlewat
17:10
atau berpindah antar file
17:10
untuk memperiksa koneksi.
17:12
Sendiri-sendiri,
17:12
hal itu terasa kecil.
17:13
Namun, jika dicumlahkan
17:14
sepanjang sprint penuh,
17:15
hal itu membentuk
17:16
seberapa banyak nilai aktual
17:17
yang dikirimkan.
17:18
Apa yang tampak seperti
17:19
gerakan rutin
17:20
menyembunyikan hambatan nyata
17:21
pada di masa pengiriman.
17:21
Beban tersembunyi
17:23
bukanlah pada waktu
17:23
kompilasi atau kecepatan mengetik,
17:25
melainkan pada ritma berhenti
17:26
mulai yang mengganggu konsentrasi.
17:27
Setiap kali Anda berpindah
17:28
dari satu file ke file lain,
17:29
otak Anda melakukan riset.
17:31
Reset tersebut memiliki hari.
17:32
Melimpahkan koreksi
17:33
berulang ke agen
17:34
akan meringankan beban tersebut.
17:36
Alih-alih terus-menerus
17:36
membangun ulang konteks
17:37
Anda mencurahkan fokus
17:38
di tempat yang penting,
17:39
yakni memecahkan
17:40
masalah desain yang lebih besar.
17:42
Banyak tim tidak melacak
17:43
biaya mikro ini
17:43
karena tidak muncul
17:44
di tiket jira
17:45
atau rewayat git.
17:46
Pekerja yang tidak membuatkan
17:47
hasil tidak tercatat
17:48
tetapi tetap menghabiskan energi.
17:50
Dan seiring skala besok
17:51
yang meningkat,
17:51
keseakan ini
17:52
tidak hanya bertambah secara linear.
17:53
Semakin banyak lapisan
17:54
berarti semakin banyak
17:55
dependensi yang harus diingat
17:56
dan semakin besar
17:57
kemungkinan kehilangan waktu
17:58
hanya untuk menyelaraskan
17:58
struktur sebelum bisa berlanjut.
18:00
Alur kerja agen
18:00
mengubah perhitungan
18:01
dengan menargetkan
18:02
penguras waktu ini secara langsung.
18:03
Mereka tidak hanya
18:04
mengisi stop metode
18:04
dengan lebih jauh.
18:05
Mereka mengurangi
18:06
siklus pencarian,
18:07
penambalan,
18:07
dan menjalankan ulang
18:08
yang menghabiskan waktu sore har.
18:09
Tim yang menggunakan
18:10
alur kerja agen
18:11
melaporkan waktu tunggu
18:12
yang lebih singkat
18:12
untuk membuka blokir
18:13
dalam banyak kasus.
18:14
Dalam video ini,
18:14
kami akan mendemonstrasikan
18:15
satu tugas sebelum sesudah
18:16
agar Anda dapat melilai dampaknya.
18:18
Saya akan mencatat
18:19
waktu yang dibutuhkan
18:20
untuk mengimplementasikan
18:20
fitur Azure yang sama
18:21
secara manual
18:22
lalu melakukannya lagi
18:23
dengan agen
18:23
agar Anda bisa melihat
18:24
peningkatan produktivitas secara nyata.
18:26
Dari sudut pandang bisnis,
18:27
nilainya terlihat
18:27
pada kecepatan proyek.
18:29
Siklus yang lebih cepat
18:30
bukan sekadar tentang
18:30
kepuasan pengembang.
18:32
Hal ini menentukan
18:32
apakah fitur dari sekarang
18:33
atau tertunda
18:34
beberapa kuartal ke depan.
18:35
Ini memengaruhi
18:36
utang teknis
18:36
karena lebih sedikit
18:37
peretasan dan negasi
18:38
yang menempuk di backup.
18:40
Alur yang lebih lancar
18:41
membuat tim bergerak maju
18:42
dengan bersih
18:42
alih-alih spring sebelumnya.
18:45
Konsistensi tersebut
18:45
menghasilkan lebih sedikit
18:46
pemadaman masalah
18:47
dan pengiriman yang lebih kuat
18:48
seiring waktu.
18:49
Ada juga faktor manusia.
18:50
Satu hari yang hilang
18:51
untuk mengejar kesalahan
18:52
membuat insinyur menampunker.
18:53
Begitu adalah
18:54
pekerjaan desain yang bersih
18:55
menjadi lebih sulit,
18:55
detail terlewat
18:56
dan kesalahan mulai muncul.
18:58
Dengan mengalihkan
18:58
perbaikan teknis ke agen,
19:00
pengembang tetap waspada
19:00
untuk durasi yang lebih lama.
19:02
Fokus ekstra tersebut
19:03
meningkatkan produktivitas
19:04
dan kualitas sekaligus.
19:06
Saat Anda tidak terbebani
19:07
oleh hambatan berulang,
19:08
Anda bebas berpikir luas
19:09
dan merencanakan
19:09
dengan lebih efektif.
19:11
Perbedaannya dalam praktik
19:12
terlihat seperti ini.
19:13
Fungsi Azure baru
19:13
dengan banyak binding
19:14
dan integrasi layanan
19:15
bisa memakan waktu
19:16
hingga dua hari penuh
19:16
jika dilakukan sendiri.
19:18
Antara konfigurasi,
19:19
pengujian,
19:20
dan pelacakan balik referensi
19:21
yang tidak cocok,
19:22
tugas menjadi berlarut-larut.
19:24
Dengan bantuan agen,
19:25
fungsi yang sama
19:25
bisa selesai dalam setengah hari.
19:27
Bukan karena mengambil
19:28
jalan pintas,
19:29
tetapi karena pengaturan
19:29
antar file dan orkestrasi
19:30
berhasil dengan konsisten
19:31
sejak awal.
19:32
Lini masa menjadi singkat
19:33
dengan menghilangkan
19:34
awal yang salah
19:34
dan upaya yang berlebihan.
19:36
Beberapa pengembang
19:36
menyuarakan kekhawatiran mewah.
19:38
Apakah bergantung pada AI
19:39
untuk menangani pemeliharaan
19:40
akan menumpulkan
19:40
keterampilan Anda sendiri?
19:41
Perspektif itu seringkali
19:42
melewatkan nampak geser.
19:44
Melimpahkan pengaturan berulang
19:45
tidak melemahkan keahlian Anda,
19:46
melainkan menjaganya
19:47
untuk desain dan arsitektur
19:48
di mana penilaian
19:48
menciptakan daya ungkit.
19:50
Kenyataannya,
19:50
Anda mendapatkan ruang
19:51
untuk melatih pemecahan
19:52
masalah tingkat tinggi
19:53
alih-alih membuang energi
19:54
untuk koreksi teknis.
19:55
Jika Anda mencobanya,
19:56
komentari berapa jam
19:57
yang berhasil Anda hemat
19:57
dalam satu sprint.
19:58
Saya akan menarik tanggapan menarik
20:00
dalam video yang mendatang.
20:01
Mendengar bagaimana tim lain
20:02
mengalami perubahan ini
20:03
memberi semua orang gambaran
20:04
yang lebih baik
20:04
tentang nilai sebenarnya
20:05
di luar demo dan contoh.
20:07
Catalan peringatan
20:08
otomatisasi memang membantu
20:09
tetapi keamanan tetap tentu.
20:10
Selalu jalankan pengujian Anda
20:11
dan gunakan tinjauan kode
20:12
untuk memvalidasi perubahan
20:13
yang dibuat lagi.
20:14
Perjalanan pekerjaan
20:15
yang menyembuhkan
20:16
akan berkurang
20:16
tetapi tetap jaga
20:17
batasan keamanan yang ada.
20:18
Perbedaan kecepatan
20:19
hanya akan membuatkan hasil
20:20
jika kualitas tetap tentu.
20:21
Pengujian yang kuat
20:22
dan tinjauan PR
20:23
yang cerdas melindungi
20:23
jalur rilis Anda
20:24
dari otomatisasi yang rapat.
20:26
Hasilnya bukan tentang
20:27
menghasilkan baris kode
20:28
dengan cepat,
20:28
tetapi tentang memberi ruang
20:29
untuk menciptakan solusi
20:30
yang lebih kuat
20:31
dengan lebih sedikit
20:32
dan lebih sedikit.