00:00:00Meskipun kode Claude adalah salah satu alat paling hebat untuk pengembangan AI,
00:00:03mengapa alat ini terkadang gagal dalam tugas tertentu? Dan di antara fitur-fitur yang
00:00:08baru saja dirilis Anthropic serta alur kerja yang kami bangun di sekitarnya, cara
00:00:12penggunaan alat ini terlihat sangat berbeda dibanding beberapa minggu lalu. Tim kami menggunakan
00:00:16kode Claude setiap hari, bukan hanya untuk pengembangan, tapi juga riset, mengelola pipeline
00:00:21produksi, dan mengotomatiskan tugas-tugas non-kode. Mari saya tunjukkan semua
00:00:26yang telah kami temukan. Anthropic baru saja menambahkan perintah "insights" untuk kode Claude. Fitur ini menganalisis
00:00:31semua sesi kode Claude Anda sebelumnya dalam periode tertentu dan menghasilkan laporan. Laporan tersebut
00:00:36menganalisis gaya kerja Anda, mengkritik pola kerja Anda, menyoroti apa yang sudah benar
00:00:40dan apa yang belum, serta memberi tahu cara memperbaikinya. Fokus utama kami adalah mengidentifikasi
00:00:45di mana letak kesalahannya karena dari sanalah kita bisa belajar memperbaiki diri. Laporan itu menyoroti
00:00:49area dengan hambatan terbesar dan menyarankan fitur yang bisa ditambahkan untuk membuat
00:00:54alur kerja lebih baik. Contohnya, ada sesi di mana agen utama terus-menerus menarik
00:00:58daftar tugas dalam waktu lama saat kami menggunakan tim agen. Hal ini membuat sesi berjalan terlalu lama
00:01:03dan kami harus menghentikannya sendiri. Untuk mencegah hal ini di masa depan, kita bisa menyalin instruksi ini
00:01:07ke dalam cloud.md agar setiap kali kita menggunakan kode Claude dengan multi-agen, Claude tidak melakukan polling
00:01:12tanpa henti dan segera bertindak. Kita bisa mengimpor tips ini ke proyek kita untuk alur kerja mendatang agar
00:01:17pengalaman kita dengan kode Claude semakin baik dari waktu ke waktu. Tim kami telah menghabiskan banyak waktu
00:01:22bekerja dengan kode Claude, dan langkah terpenting tetaplah seberapa baik Anda memberikan konteks kepada agen.
00:01:26Ini bisa berupa kebutuhan proyek yang dipecah menjadi bagian-bagian kecil atau dokumentasi kerangka kerja dan
00:01:30pustaka yang Anda gunakan karena saat Anda memberikan konteks yang tepat, kesalahan hampir tidak ada
00:01:35karena agen tahu apa yang harus dilakukan. Untuk dokumentasi proyek, kami lebih suka menggunakan Claude untuk menulisnya
00:01:39daripada melakukannya sendiri. Kami memberikan instruksi khusus kepada Claude yang berisi semua informasi
00:01:44yang diperlukan untuk memecah ide proyek menjadi dokumen yang dibutuhkan. Kami memintanya membuat
00:01:48empat dokumen yang masing-masing berfokus pada aspek spesifik aplikasi. Yang paling penting adalah PRD
00:01:53yang berisi informasi tentang kebutuhan dan cakupan proyek. Lalu ada architecture.md
00:01:57yang berisi format data, struktur file, API, dan semua detail arsitektur yang tertulis lengkap.
00:02:02Kemudian decision.md yang berisi semua keputusan yang dibuat Claude selama pembuatan proyek ini
00:02:08sebagai referensi di masa mendatang. Dan yang paling penting adalah feature.json yang berisi
00:02:12semua fitur dalam format JSON khusus. Ini berisi detail setiap fitur secara efisien
00:02:17dan kriteria penyelesaian fitur, lengkap dengan kunci "passes" untuk
00:02:22melacak apa yang sudah diimplementasikan dan apa yang belum. Sekarang setelah tugas besar Anda dipecah
00:02:27menjadi bagian-bagian kecil, kita perlu memberikan dokumentasi tentang alat apa yang dibutuhkan untuk implementasi melalui
00:02:31Context 7 MCP. Alat ini memiliki dokumentasi untuk semua pustaka dan kerangka kerja serta diperbarui
00:02:36secara berkala agar agen dapat mengambil dokumen terbaru dan menutupi celah antara pengetahuan model dan
00:02:41pembaruan saat ini. Menyiapkan MCP hanya butuh beberapa langkah. Setelah terinstal, alat ini
00:02:46menggunakan fitur dari Context 7 dan mengambil informasi pustaka secara langsung. Ini memungkinkannya menggunakan
00:02:50dokumentasi terbaru, mencegah kesalahan kode akibat ketidakcocokan dependensi, dan menghasilkan
00:02:55implementasi yang lebih akurat. Fitur lain yang jarang dimanfaatkan adalah "hooks". Hooks dalam kode Claude
00:03:00adalah perintah shell yang dijalankan pada titik tertentu dalam siklus hidup. Ada banyak jenis yang dipicu pada
00:03:05waktu tertentu seperti awal sesi, sebelum alat digunakan, atau setelah alat digunakan. Namun bagian terpentingnya
00:03:11adalah mengaturnya dengan kode keluar (exit code) tertentu. Kode keluar ini memberi tahu kode Claude apakah harus lanjut,
00:03:16memblokir, atau mengabaikan tindakan. Kode keluar 0 berarti berhasil. Kode keluar 2 berarti kesalahan yang memblokir. Jadi
00:03:22setiap kali Claude mencoba melakukan sesuatu yang tidak seharusnya, ia akan menemui kode keluar 2, menerima pesan kesalahan,
00:03:27dan dapat memperbaiki dirinya sendiri. Kode keluar selain keduanya bersifat tidak memblokir, ditampilkan dalam mode verbose,
00:03:32dan eksekusi berlanjut. Kode keluar 2 ini penting karena dengannya, Anda bisa mengontrol
00:03:37perilaku agen. Jika Anda pernah mencoba pengembangan berbasis tes (TDD) menggunakan kode Claude,
00:03:41Anda mungkin menyadari bahwa ia cenderung memodifikasi file tes jika gagal memenuhinya. Untuk mencegah
00:03:46hal itu, kami menyiapkan hook khusus yang dipicu sebelum alat digunakan (pre-tool use). Hook ini melindungi skrip tes
00:03:50agar tidak dimodifikasi. Jika direktori yang ingin dikerjakan adalah folder tes atau mengandung kata "test",
00:03:55ia akan menampilkan pesan kesalahan yang menyatakan modifikasi folder tes tidak diizinkan dan mengembalikan
00:04:00kode keluar 2. Dengan hook ini, saat kami meminta Claude menjalankan tes dan tes tersebut
00:04:05gagal, ia mencoba mengubah file tes tersebut. Tapi skrip memblokirnya dan pesan "terblokir dari modifikasi"
00:04:10muncul. Ini menghentikan Claude mengedit file yang tidak seharusnya diedit. Jika Anda pernah bekerja
00:04:15dengan MCP, Anda tahu bahwa hal itu membuat jendela konteks menjadi penuh. Dan saat mengerjakan proyek skala besar,
00:04:19jumlah MCP yang terhubung meningkat. Akhirnya semua alat MCP memenuhi jendela konteks
00:04:25dan menjadi sangat berat. Untuk tujuan ini, kode Claude memiliki mode eksperimental MCP CLI yang mengatasi hal ini.
00:04:31Kami mengaktifkan tanda eksperimental MCP CLI. Begitu diaktifkan, semua MCP yang sebelumnya muncul
00:04:36di konteks menghilang dan tidak ada lagi jendela konteks yang termakan oleh alat MCP. Pertanyaannya adalah
00:04:41bagaimana cara mengakses alat-alat tersebut jika sudah tidak ada di memori. Alih-alih memuat semua
00:04:45skema alat di awal, kode Claude menggunakan info MCP CLI dan panggilan MCP CLI untuk menjalankan semua MCP
00:04:52yang terhubung melalui bash. Dengan tanda tersebut, saat kami memberikan perintah, alih-alih memanggil
00:04:56alat MCP secara langsung, ia memanggilnya melalui alat MCP CLI dan menjalankannya sebagai perintah bash, bukan
00:05:03alat MCP. Dengan cara ini, alat hanya dimuat saat dibutuhkan, mencegah kepenuhan konteks. Selain itu,
00:05:08jika Anda menyukai konten kami, silakan tekan tombol hype karena itu membantu kami membuat lebih banyak
00:05:13konten seperti ini dan menjangkau lebih banyak orang. Di video sebelumnya, kami menekankan penggunaan
00:05:18git agar semua pekerjaan agen terlacak dalam kontrol versi. Anda juga bisa mengembalikan perubahan jika agen
00:05:23tidak mengimplementasikan sesuatu dengan benar. Kami juga punya video saat menggunakan git untuk menjalankan agen pada tugas
00:05:28jangka panjang yang bisa Anda tonton di kanal ini. Kami menggunakan agen paralel untuk bekerja pada worktree
00:05:32yang berbeda sehingga mereka bisa membuat semua fitur proyek sambil tetap terisolasi satu sama lain.
00:05:37Dengan begitu, kita bisa menggabungkan hasilnya nanti tanpa gangguan karena agen yang bekerja
00:05:41pada file yang sama akan menyebabkan konflik. Branch kurang disukai karena sering memicu konflik. Agen
00:05:46sulit berpindah branch karena branch berbagi direktori kerja yang sama, sedangkan worktree tidak.
00:05:50Jadi kami memberikan instruksi di mana kami menyediakan beberapa fitur yang perlu diimplementasikan
00:05:55dan menentukan bahwa setiap agen harus bekerja di worktree terpisah. Claude menggunakan agen berbeda
00:05:59untuk setiap worktree dan mengimplementasikan fitur secara terisolasi meskipun deskripsi tugasnya
00:06:03saling tumpang tindih di beberapa titik. Setelah Claude mengimplementasikan semua fitur dengan benar di
00:06:08branch terpisah, kami memintanya menggabungkan hasilnya agar semua fitur berada dalam satu direktori kerja.
00:06:13Kini, mode ketat (strict mode) sangat penting untuk mengalihkan beban pemeriksaan kesalahan ke agen. Ini adalah
00:06:18sesuatu yang harus Anda siapkan untuk bahasa pemrograman apa pun yang Anda gunakan karena ini mendeteksi bug
00:06:22saat proses build, bukan saat pengguna menemukannya di runtime. Karena bahasa utama kami adalah TypeScript,
00:06:26kami selalu mengaktifkan mode ketat di proyek kami. Ini mengaktifkan pemeriksaan nilai null dan tipe
00:06:31implisit, serta memastikan pengetikan yang ketat, yang berarti lebih sedikit kesalahan runtime. Hal ini penting
00:06:36bagi agen AI karena mereka tidak punya cara bawaan untuk menangkap kesalahan runtime. Mode ketat meminimalkan
00:06:41risiko kegagalan runtime dan memastikan kompiler yang menangani masalah tersebut. Agen dapat
00:06:46mengandalkan log kesalahan di terminal untuk menerapkan perbaikan. Selain pengujian proyek melalui
00:06:51skrip, ada lapisan pengujian tambahan yang layak ditambahkan. Anda menulis user story yang
00:06:56menjelaskan cara pengguna berinteraksi dengan sistem untuk memandu proses pengujian setelah
00:07:00aplikasi selesai dibuat. Kami sebenarnya mendefinisikan user story sebelum mengimplementasikan proyek karena ini menetapkan
00:07:05standar yang harus diikuti dalam implementasi. Menggunakan sebuah prompt, Claude menulis beberapa cerita
00:07:10di dalam folder yang berisi semua kemungkinan interaksi pengguna dengan sistem. Setiap cerita
00:07:15menonjolkan aspek spesifik aplikasi, prioritasnya, dan kriteria penerimaan untuk diuji oleh agen.
00:07:21User story tersebut mencakup semua skenario pengujian termasuk kasus terbaik dan kasus ekstrem. Cerita-cerita
00:07:26ini memberi tahu agen cara berinteraksi dengan sistem yang baru saja dibangun dan dengan instruksi
00:07:31yang tepat, agen mana pun bisa menerapkan prinsip yang sama pada aplikasi yang sedang dibangun
00:07:35dan memenuhi ekspektasi pengguna dengan lebih baik. Dengan dokumentasi cerita tersebut, kami meminta
00:07:40Claude mengimplementasikannya satu per satu dan memintanya memulai dari jalur optimal yang tercantum di setiap
00:07:45cerita, sambil memastikan semua kasus ekstrem tertangani. Dengan cara ini, implementasi memiliki lebih sedikit celah
00:07:50dan kepuasan pengguna yang lebih baik secara keseluruhan. Semua tips yang kami bicarakan tersedia dalam
00:07:55bentuk templat siap pakai di AI Labs Pro. Bagi yang belum tahu, ini adalah komunitas yang
00:08:00baru saja kami luncurkan di mana Anda mendapatkan templat, prompt, serta semua perintah dan skill yang bisa
00:08:05langsung dipasang ke proyek Anda. Jika Anda merasa konten kami bermanfaat dan ingin mendukung kanal ini,
00:08:10inilah cara terbaik untuk melakukannya. Tautan ada di deskripsi.
00:08:14Kita perlu memanfaatkan paralelisasi sebanyak mungkin karena inilah cara agen mempercepat
00:08:20alur kerjanya dan mengimplementasikan hal-hal yang tidak perlu saling menunggu. Kita tahu Claude secara otomatis
00:08:25mendeteksi apakah tugas bisa berjalan paralel atau berurutan dan memutuskannya sendiri, tapi
00:08:29tidak ada salahnya membuat agen sendiri. Kami juga membahas kemampuan agen ini di video
00:08:34sebelumnya tentang cara menggunakan agen untuk mempercepat alur kerja, namun kecepatan ini berimbas
00:08:39pada peningkatan penggunaan token. Meski begitu, upaya paralelisasi sangatlah sepadan. Pada suatu waktu
00:08:43kami sedang meneliti dampak peningkatan Opus 4.6 menggunakan model yang sama dan ia terus
00:08:49berhalusinasi tentang fakta meskipun kami sudah memberikan sumbernya. Ia terus menulis informasi yang salah dan kami harus
00:08:54memperbaikinya berulang kali. Melakukan riset ini terasa sia-sia karena kami harus terus memperbaiki
00:08:58semuanya sendiri. Untuk mencegah hal ini terulang, kami menggunakan agen paralel. Kami menyiapkan tugas riset
00:09:03di mana kami ingin membandingkan kemampuan agent swarm dari KimiK 2.5 dan agent swarm Claude.
00:09:09Kami menggunakan dua agen: satu untuk riset dan satu lagi untuk memeriksa fakta agen riset tersebut. Ide
00:09:14utamanya adalah membuat kedua agen berkomunikasi untuk memastikan temuannya akurat sehingga
00:09:19kami tidak perlu melakukannya sendiri. Dalam pengaturan ini, satu agen melakukan tugas sementara yang lain
00:09:24menganalisisnya secara kritis, memberikan cara kerja adversarial. Agen riset mulai lebih dulu dan
00:09:28pemeriksa fakta tertahan sampai agen riset menghasilkan draf pertama. Setelah draf pertama
00:09:33selesai, pemeriksa fakta mulai memverifikasinya. Ia segera mengidentifikasi banyak ketidakakuratan data
00:09:38yang dicantumkan agen riset dan kami tidak perlu lagi menemukannya secara manual. Kedua agen terus
00:09:43berkomunikasi dan menjaga proses pemeriksaan fakta tetap ketat. Satu agen khusus bertugas
00:09:47menegur agen lainnya jika ada informasi yang salah. Ada banyak tugas yang bisa dijalankan dengan sistem adversarial
00:09:52seperti ini. Bukan hanya riset, tapi juga pekerjaan pengembangan di mana satu agen mengimplementasikan fitur
00:09:57dan yang lain meninjau implementasi tersebut berdasarkan rencana. Menurut pencipta Claude Code,
00:10:02agen bekerja lebih baik jika memiliki cara untuk memverifikasi pekerjaannya sendiri. Ide intinya adalah memberikan
00:10:07agen "mata", artinya kemampuan untuk memeriksa apakah fitur yang diimplementasikan sudah benar dan memenuhi
00:10:12ekspektasi. Karena agen ini berbasis terminal, mereka tidak bisa mengidentifikasi masalah yang terjadi
00:10:17saat runtime, terutama di sisi klien. Kami menggunakan beberapa cara untuk memverifikasi pekerjaan agen.
00:10:21Yang pertama adalah ekstensi Claude Chrome yang menyediakan alat berbasis browser seperti penangkapan DOM, pemeriksaan
00:10:26log konsol, dan lainnya. Alat lainnya adalah Puppeteer MCP. Alat ini berguna karena berjalan di
00:10:31browser terpisah yang tidak berisi sesi Anda yang ada, tidak seperti ekstensi Claude Chrome. Ini
00:10:36terisolasi dan tidak mengganggu sesi Anda saat ini sehingga Anda mendapatkan lapisan privasi tambahan.
00:10:41Tapi pilihan utama kami adalah agen browser dari Vercel. Ini bukan MCP melainkan alat CLI yang
00:10:46memberikan agen kemampuan pengujian browser. Alat ini bisa menavigasi, mengambil tangkapan layar, dan
00:10:51lainnya. Berbeda dengan alat lain, ia tidak menavigasi hanya berdasarkan tangkapan layar. Melainkan menggunakan
00:10:56accessibility tree di mana setiap elemen memiliki referensi unik. Ini meringkas seluruh DOM dari ribuan
00:11:01token menjadi sekitar 200 hingga 400 token sehingga jauh lebih hemat konteks. Itulah masalah utama
00:11:07pada ekstensi Claude Chrome yang berhasil diatasi oleh agen browser. Ekstensi tersebut memuat seluruh DOM ke dalam
00:11:12jendela konteks dan menghabiskannya dengan cepat. Kami juga menambahkan instruksi di Claude.md agar Claude
00:11:17mengandalkan agen browser terlebih dahulu sebelum menggunakan pengujian berbasis MCP. Jadi Claude menggunakan agen browser
00:11:23sebagai metode verifikasi utama. Tapi ada sudut pandang lain di sini. Pengujian memang penting, tapi ada
00:11:28cara untuk mengurangi kesalahan tanpa melibatkan tes atau peninjauan kode. Kami meminta Claude memprediksi hal-hal
00:11:33yang belum terjadi. Kami meminta Claude memeriksa implementasi dan mengidentifikasi area di mana
00:11:38aplikasi bisa gagal. Ini berhasil karena kita memberi kesempatan Claude untuk memprediksi potensi masalah dengan
00:11:43mencocokkan pola kegagalan yang pernah ada di aplikasi lain, meskipun kita sendiri belum menemukannya
00:11:47lewat pengujian. Ini mendorong Claude untuk melihat kode dari sudut pandang yang berbeda dari
00:11:52sebelumnya. Saat kami memintanya melakukan itu, ia mengidentifikasi celah kritis yang lolos dari proses pengujian
00:11:57berlapis kami dan menemukan 18 masalah yang bisa berakibat buruk di produksi. Padahal proses pengujian
00:12:01kami tidak menangkapnya. Masalah itu hanya bisa diidentifikasi saat kami mendorong Claude untuk melihat
00:12:06proyek dari sudut lain. Itu membawa kita ke akhir video ini. Jika Anda ingin mendukung
00:12:10kanal ini dan membantu kami terus membuat video seperti ini, Anda bisa melakukannya melalui tombol super thanks
00:12:15di bawah. Seperti biasa, terima kasih telah menonton dan sampai jumpa di video berikutnya.