Workflow Coding Agentik LENGKAP Saya untuk Bangun Apa Pun (Tanpa Basa-basi atau Overengineering)

CCole Medin
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00Semua orang tahu bahwa Anda butuh kerangka kerja untuk bekerja dengan agen pengodean, tapi tidak banyak orang
00:00:04yang punya kerangka yang sederhana, benar-benar milik sendiri, dan bisa dikembangkan seiring waktu. Sekarang,
00:00:09ada banyak kerangka kerja yang terlalu rumit di luar sana, di GitHub. Semua sistem multi-agen yang
00:00:15dibuat orang-orang ini, saya menghormati karya mereka, tapi sering kali Anda hanya butuh sesuatu
00:00:19yang sangat sederhana yang bisa menyelesaikan pekerjaan Anda. Karena saya tahu Anda punya ide bagus yang
00:00:24ingin Anda bangun, dan Anda tidak ingin menghabiskan lebih banyak waktu membuat alur kerja pengodean agen daripada
00:00:29waktu yang Anda gunakan untuk mengode, dan itulah yang saya miliki untuk Anda sekarang. Ini adalah kerangka kerja saya yang sangat sederhana
00:00:35yang saya gunakan setiap kali saya memulai proyek baru dengan agen pengodean saya. Nah, Pengembangan
00:00:40Brownfield, mengerjakan basis kode yang sudah ada, sedikit berbeda. Itu untuk video lain. Kali ini,
00:00:45kita fokus pada Pengembangan Greenfield. Kita ingin kerangka kerja sederhana untuk mulai melangkah
00:00:50secepat mungkin, membangun sesuatu yang baru, dan semua yang saya bahas di sini bersifat universal.
00:00:56Prinsip-prinsip ini akan berlaku apa pun agen pengodean yang Anda gunakan. Jadi sebenarnya ada dua
00:01:00bagian dalam video ini, dan saya akan melakukan pembangunan langsung bersama Anda saat saya menjelaskan semuanya
00:01:05di sini agar benar-benar konkret. Dan apa yang saya miliki sekarang di basis kode saya hampir tidak ada apa-apa
00:01:11selain lapisan AI saya. Jadi ada beberapa perintah dan keahlian yang saya bawa. Inilah yang saya gunakan sebagai
00:01:16titik awal untuk setiap proyek saya. Kita akan membuat sesuatu dari nol,
00:01:21jadi kita perlu mulai dengan perencanaan awal, membuat apa yang disebut PRD. Ini adalah
00:01:27cakupan kerja awal yang harus kita buat untuk produk layak minimum (MVP) aplikasi kita. Dan ada
00:01:32banyak hal di sini, menyiapkan lapisan AI awal kita sebelum kita masuk ke pengodean yang sebenarnya.
00:01:37Lalu kita ambil PRD kita dan membaginya menjadi fase-fase kerja, dan kita akan menyelesaikannya
00:01:43dengan putaran PIV. Jadi saya akan jelaskan apa artinya, kita akan lihat contohnya, dan kemudian
00:01:47selama saya melakukan seluruh implementasi ini, saya akan membahas empat aturan emas yang ingin
00:01:52kita ikuti setiap saat. Jadi aturan emas ini akan masuk secara alami saat saya
00:01:57membuat PRD, lapisan AI, dan melakukan putaran PIV. Misalnya, manajemen konteks.
00:02:03Konteks adalah sumber daya Anda yang paling berharga saat bekerja dengan asisten pengodean AI. Itu akan menjadi
00:02:08tema besar di sepanjang video. Juga membuat perintah dan keahlian untuk segalanya serta pola pikir evolusi sistem,
00:02:14karena tujuan kita dengan sistem ini adalah untuk menciptakan sesuatu yang andal dan
00:02:18bisa diulang. Jadi saya akan membicarakannya sambil mempraktikkan semuanya. Saya hanya mencoba menekankan beberapa
00:02:23tema inti yang akan Anda lihat di sepanjang video ini. Ini akan menjadi video yang sangat bernilai. Jadi,
00:02:28kita mulai di sini dengan perencanaan awal kita, membuat apa yang suka saya sebut lapisan AI. Jadi saya akan jelaskan
00:02:34apa itu dan kita akan membangunnya bersama sekarang. Jadi lapisan AI Anda adalah semua aset dalam basis kode
00:02:39Anda yang Anda buat sebagai konteks untuk agen pengodean Anda. Seperti PRD Anda. Apa yang akan kita bangun?
00:02:45Aturan global Anda. Bagaimana cara kita membangunnya? Perintahnya. Jadi kita punya alur kerja yang dapat digunakan kembali untuk
00:02:50agen pengodean kita. Kita akan fokus pada yang utama dulu. Dan juga sub-agen. Jadi kita bisa mendelegasikan
00:02:55tugas riset. Dan secara umum cara saya bekerja dengan lapisan AI saya, dan saya punya sumber daya ini untuk Anda,
00:03:01adalah saya punya sekumpulan perintah yang lebih umum yang akan saya bawa ke proyek baru mana pun. Dan inti dari
00:03:07hal ini adalah seiring basis kode saya berkembang dan saya mulai membangunnya, saya juga akan mengembangkan perintah saya agar
00:03:13lebih kuat untuk kasus penggunaan tertentu, membuatnya lebih spesifik untuk kode saya. Dan itu
00:03:18secara umum adalah rekomendasi saya untuk Anda. Jadi gunakan ini sebagai titik awal jika Anda mau. Saya akan menyertakan
00:03:23tautan ke repositori GitHub di deskripsi. Tujuan menjaga ini tetap sederhana adalah agar Anda
00:03:27bisa mengambilnya sendiri dan dengan mudah mengembangkannya untuk kasus penggunaan dan cara kerja Anda. Itulah mengapa
00:03:33saya merekomendasikan sesuatu seperti ini daripada kerangka kerja yang lebih kompleks seperti Beemad atau kit spek GitHub.
00:03:38Mereka sangat kuat, tapi sulit untuk benar-benar menjadikannya milik sendiri. Saya ingin Anda bisa
00:03:42menjadikan ini milik sendiri. Jadi sekarang saya akan menunjukkan seperti apa proses pembuatan seluruh PRD. Menentukan
00:03:48aturan awal untuk basis kode kita. Kita bahkan akan sedikit menyesuaikan perintah pertama kita. Lalu
00:03:52saya akan membahas tentang sub-agen di sepanjang video. Dan saya tahu kita melakukan banyak perencanaan sebelum kita menulis
00:03:57kode sebenarnya dengan putaran PIV, tapi penting untuk melakukan ini. Melakukan perencanaan di awal
00:04:03mungkin terasa lambat, tapi jika kita membuat rencana yang sangat bagus, seperti punya aturan yang mantap,
00:04:07PRD yang oke, itu berarti semua pengembangan kita setelahnya akan jauh lebih cepat
00:04:13dan lebih andal. Jadi mari kita mulai dengan PRD. Banyak orang menyebutnya spek. Sekali lagi, ini hanya
00:04:18seluruh cakupan kerja untuk membangun versi awal aplikasi kita. Dan setelah itu,
00:04:24saat kita punya fondasi yang bagus, itu beralih ke pengembangan brownfield. Itulah video berikutnya
00:04:28yang akan saya buat. Jadi nantikan saja. Dan apa yang akan saya lakukan di sini dengan kode Claude saya,
00:04:34saya punya proyek yang dasarnya kosong selain lapisan AI saya, adalah saya akan melakukan percakapan santai
00:04:40pada awalnya. Hanya memberitahunya tentang ide saya, mungkin beberapa ide yang saya punya untuk tumpukan teknologi dan
00:04:45arsitekturnya. Anda mulai dengan sangat tidak terstruktur, yang juga memudahkan untuk memulai.
00:04:50Dan kemudian Anda akhirnya sampai pada titik di mana Anda menggunakan percakapan tersebut sebagai konteks untuk membuat
00:04:55PRD yang terstruktur. Dan saya punya perintah yang akan membantu kita menyelesaikannya. Saya akan bahas itu setelah
00:05:01kita sampai di sana, tapi pertama mari kita mulai dengan ide kita. Dan apa yang ingin saya bangun sebagai
00:05:06contoh menyenangkan untuk video ini adalah sesuatu yang mirip dengan Linktree, lebih ke versi hos mandiri
00:05:12di mana Anda bisa menyiapkan halaman arahan Anda sendiri yang punya sekumpulan tautan yang bisa Anda atur.
00:05:16Anda punya analitik seperti rasio klik-tayang pada berbagai tautan Anda. Saya ingin membangun sesuatu
00:05:20seperti ini. Ini contoh yang bagus untuk saat ini karena tidak terlalu sepele di mana Anda bisa
00:05:24langsung mengodenya dengan mudah menggunakan beberapa fitur keren yang bisa kita tambahkan, tapi di sisi lain
00:05:29tidak akan terlalu rumit sampai-sampai kita hampir tidak punya apa-apa di akhir video ini.
00:05:33Jadi saya akan menggunakan alat pengubah ucapan ke teks untuk menyelesaikannya di sini. Saya sangat menyarankan penggunaan
00:05:39sesuatu seperti Aqua Voice. Ini yang saya gunakan. Ada banyak pilihan gratis dan sumber terbuka yang bagus juga.
00:05:43Whisper Flow, Epicenter Whispering, alat-alat hebat yang kita punya di sini, tapi saya suka menggunakan ucapan
00:05:48ke teks karena saya berjanji kepada Anda, saya tidak akan pernah bisa mengetik 226 kata per menit. Jadi saya akan
00:05:54menggunakan alat seperti ini untuk melakukan curah ide besar di awal tentang apa yang ingin saya bangun. Dan ini
00:05:59akan sangat mentah, tapi saya akan melakukan curah ide langsung untuk Anda sekarang dan perhatikan
00:06:03apa yang saya minta untuk dilakukan oleh kode Claude, karena ini sama pentingnya dengan ide-ide yang
00:06:09saya bagikan. Saya juga akan menjelaskan sedikit tentang itu nanti. Dan omong-omong, Anda bisa melakukan ini
00:06:13seluruhnya dengan asisten pengodean AI apa pun. Jadi ini dia. Saya ingin membangun pembuat halaman tautan di bio.
00:06:20Jadi sesuatu yang mirip Linktree, pengguna bisa membuat akun. Mereka bisa membuat
00:06:24halaman arahan mereka sendiri di mana mereka menentukan tautannya. Mereka bisa mengubah urutannya. Saya ingin mereka punya
00:06:29analitik sehingga mereka bisa melihat rasio klik-tayang pada tautan mereka juga. Dan mereka bisa menyesuaikan
00:06:33temanya. Lalu untuk tumpukan teknologinya, saya pikir mungkin seperti Next JS, saya ingin menggunakan Neon untuk
00:06:37basis data saya dan autentikasi Neon. Jadi pastikan untuk menjalankan sub-agen untuk melakukan riset tentang
00:06:43hal itu. Dan untuk arsitekturnya, saya tidak terlalu pilih-pilih. Tentu saja saya ingin rekomendasi Anda
00:06:48untuk itu. Serta bagaimana kita akan menangani tema dan pembangunan tautan, semuanya itu. Dan jadi
00:06:55saya ingin Anda juga menjalankan agen untuk melakukan banyak riset web tentang praktik terbaik untuk
00:07:00membuat aplikasi jenis Linktree ini. Dan kemudian apa yang saya ingin Anda lakukan setelahnya adalah kembali kepada saya
00:07:04dengan banyak pertanyaan sehingga kita bisa sepakat bahkan dengan detail kecil tentang apa yang sedang kita
00:07:10bangun di sini. Oke, bagus sekali. Jadi saya akan mengirimkannya dan itu akan segera ditranskripsi
00:07:14dalam beberapa detik. Nah, itu dia. Dan bum, kita mulai beraksi. Dan hal paling penting
00:07:20yang saya lakukan di sana sebenarnya tepat di bagian akhir saat saya menyuruhnya untuk memberi saya banyak pertanyaan
00:07:25setelah dia melakukan risetnya. Jadi ini sangat penting untuk ditekankan di sini. Tujuan nomor satu Anda
00:07:32untuk perencanaan apa pun dengan agen pengodean adalah mengurangi jumlah asumsi yang dibuat oleh agen
00:07:37pengodean Anda. Karena pada akhirnya, saat agen pengodean membuat kesalahan di basis kode Anda, separuh
00:07:42waktu itu bukan karena kodenya buruk, tapi karena Anda tidak selaras tentang apa sebenarnya yang seharusnya
00:07:48Anda bangun. Pepatah umum mengatakan bahwa satu baris kode buruk hanyalah satu baris kode buruk. Satu baris
00:07:54rencana yang buruk mungkin bisa menjadi seratus baris kode yang buruk. Tapi satu baris yang buruk dalam PRD, itu bisa menjadi seribu
00:08:02baris kode yang buruk karena ketidakselarasan. Jadi saya telah melakukan banyak eksperimen
00:08:08dengan cara untuk mengurangi asumsi seiring berjalannya waktu. Dan meminta agen pengodean untuk
00:08:13memberi saya rentetan pertanyaan telah bekerja dengan sangat luar biasa bagi saya. Karena terutama
00:08:17Kode Claude dengan alat tanya jawab penggunanya, di mana ia bisa memberikan pilihan ganda atau menulis jawaban sendiri.
00:08:23Kita akan lihat itu sebentar lagi. Ini sangat kuat. Mereka melakukan tugas yang sangat baik dalam memikirkan semua kasus
00:08:28tepi dan detail kecil yang mungkin bahkan tidak kita pikirkan. Sulit bagi kita untuk sekadar menalar
00:08:33sendiri tentang asumsi apa yang mungkin dibuat oleh agen pengodean. Jadi ini sangat, sangat kuat. Dan kemudian
00:08:38hal lain yang saya lakukan, seperti yang Anda lihat di sini, adalah kita punya berbagai sub-agen yang
00:08:42sedang berjalan untuk riset. Saya suka menggunakan sub-agen untuk perencanaan apa pun, membuat PRD,
00:08:48atau bahkan untuk proses perencanaan putaran PIV yang akan kita bahas sebentar lagi. Dan dengan
00:08:53Kode Claude, saya sebenarnya tidak perlu membuat sub-agen sendiri karena kita punya sub-agen eksplorasi dan
00:08:59riset yang sudah terpasang langsung di alat tersebut. Untuk agen pengodean lainnya, Anda mungkin harus membangun
00:09:04sendiri, itulah mengapa saya ingin menyebutkannya di sini. Tapi hampir setiap agen pengodean yang
00:09:08bagus akhir-akhir ini mendukung konsep sub-agen. Dan saya senang menggunakannya untuk riset. Dan alasannya
00:09:14adalah isolasi konteks. Sekali lagi, salah satu tema utama di sini adalah kita ingin benar-benar melindungi
00:09:20konteks agen pengodean utama kita. Dan alasan mengapa riset adalah kasus penggunaan yang sangat bagus untuk sub-agen
00:09:26secara khusus adalah karena saat mereka mengeksplorasi, mereka melihat segalanya. Mereka melakukan banyak
00:09:32eksplorasi basis kode atau riset web. Mereka memuat puluhan, bahkan ratusan ribu
00:09:36token untuk pekerjaan mereka. Tapi sebenarnya yang kita pedulikan hanyalah temuan mereka, ringkasan di bagian akhir
00:09:41yang mereka kembalikan ke konteks utama kita. Jadi kita bisa menjaga konteks utama kita tetap bersih. Saya tidak menyarankan
00:09:46penggunaan sub-agen untuk implementasi karena dengan implementasi, kita biasanya mempedulikan semua
00:09:51konteks berkas yang telah kita edit dan buat. Jika tidak, itu akan menyebabkan banyak halusinasi
00:09:57berdasarkan pengalaman saya. Dan itulah mengapa Kode Claude tidak punya agen bawaan untuk implementasi.
00:10:01Itu hanya untuk riset. Dan itulah tepatnya yang kita lihat di sini. Jadi saya akan membiarkan
00:10:06semuanya selesai dan saya akan kembali setelah ada pertanyaan untuk kita. Oke, jadi semua riset
00:10:12sub-agen sudah selesai dan sekarang kita punya rangkaian pertanyaan awal untuk dijawab. Dan seiring saya
00:10:17menelusuri ini, saya rasa Anda akan sangat menghargainya seperti saya karena kita sedang mengklarifikasi banyak
00:10:22hal. Setiap pertanyaan yang kita jawab di sini adalah menghilangkan asumsi dari agen
00:10:26pengodean. Dan karena ini pilihan ganda dan biasanya salah satu opsi yang disajikan di sini sudah bagus, kita bisa
00:10:31menyelesaikannya dengan sangat cepat. Jadi kita bisa cukup percaya diri saat masuk ke implementasi bahwa
00:10:36kita sudah mengunci semua detailnya. Dan contohnya, bagaimana seharusnya struktur URL halaman publik
00:10:41bekerja? Saya sebenarnya suka opsi nomor satu di sini dan kemudian bum, lanjut ke pertanyaan berikutnya. Berapa banyak halaman
00:10:46yang bisa dibuat oleh setiap pengguna? Mari kita buat satu halaman saja per pengguna. Maksud saya, beberapa di antaranya
00:10:50akan saya pilih sesuai default saja, tapi ada banyak contoh di mana agen ini benar-benar secara mendasar
00:10:54salah paham akan sesuatu dan di situlah saya bisa mengetik jawaban saya sendiri untuk mengklarifikasi. Jadi saya tidak
00:10:59tahu apakah saya akan menemukan contohnya di sini, tapi apa yang akan saya lakukan adalah saya akan menjawab
00:11:03semua pertanyaannya, lalu kembali lagi setelah selesai. Anda tidak perlu melihat saya menjawab setiap
00:11:07pertanyaan di sini karena mungkin bisa sampai 20 atau 25 pertanyaan. Agen ini akan menanyakannya secara mendalam.
00:11:14Jadi sekali lagi, Anda harus sedikit sabar dengan ini, tapi setiap pertanyaan yang Anda jawab bisa
00:11:19menyelamatkan Anda dari ratusan baris kode yang buruk. Nah, sebenarnya ini contoh bagus di mana saya ingin
00:11:24mengklarifikasi sesuatu yang sama sekali berbeda dari apa yang disarankannya di sini. Jadi dikatakan ini adalah kelompok
00:11:30pertanyaan kedua yang diajukan Claude kepada saya. Apakah editor tautan harus memiliki pratinjau bingkai ponsel
00:11:35langsung? Jadi seperti Lovable atau Bolt.new, di mana Anda punya tampilan apa yang sedang Anda buat dan
00:11:39lalu ada pembuatnya di sisi kiri, atau haruskah itu sebaris? Dan saya sebenarnya ingin memiliki
00:11:44kedua opsi tersebut. Jadi saya bisa masuk ke obrolan tentang hal ini. Dan kemudian ia akan menanyakan pertanyaan lain
00:11:49setelahnya, tapi sekarang kita bisa melakukan sedikit percakapan untuk hal ini secara spesifik. Dan jadi
00:11:53saya akan katakan di sini, saya ingin memiliki editor sebaris, tetapi saya ingin opsi untuk bisa melihat
00:11:58pratinjaunya juga. Jadi intinya saya ingin punya tiga tombol, satu untuk hanya melihat editor, satu
00:12:03untuk melihat keduanya, satu untuk hanya melihat pratinjau. Jadi saya kirim itu dan kemudian ia akan kembali
00:12:08dan menanyakan lebih banyak pertanyaan dan saya akan melanjutkan prosesnya. Jadi di sinilah kita. Claude selesai menanyakan
00:12:13banyak pertanyaan kepada saya, mungkin lebih banyak dari yang saya butuhkan, tapi Anda benar-benar bisa menyesuaikan ini dengan apa pun yang
00:12:18ingin Anda lakukan. Dan sekarang saatnya membuat PRD kita karena seperti yang bisa Anda lihat dari ringkasan spek akhir,
00:12:23ia benar-benar memiliki pemahaman yang jelas tentang apa sebenarnya yang akan kita bangun,
00:12:28bahkan di mana saya akan menyebarkannya. Saya akan menyebarkan ini ke Vercel setelah saya membangunnya.
00:12:31Ini fantastis. Saya merasa ia tidak berasumsi banyak lagi. Jadi sekarang apa yang akan saya lakukan
00:12:36adalah cukup jalankan perintah buat PRD saya. Saya akan letakkan ini di .claud/prd.md. Anda benar-benar bisa meletakkan ini
00:12:43di mana pun Anda mau. Anda bahkan bisa menamainya apa pun. Jadi saya menggunakan perintah yang saya
00:12:47sebutkan tadi karena kembali ke empat aturan emas kita, salah satu yang besar di sini
00:12:53adalah memerintahkan segalanya. Jika Anda melakukan sesuatu lebih dari dua kali, dan saya sudah pasti memulai
00:12:59lebih dari sekadar beberapa proyek, Anda harus menjadikannya sebuah perintah. Atau yang dikenal sebagai keahlian
00:13:03karena Kode Claude baru-baru ini menggabungkan perintah dengan keahlian, tetapi saya masih suka membedakan bahwa
00:13:10perintah adalah hal-hal yang Anda panggil sendiri seperti slash commit. Dan keahlian, itu terjadi saat agen
00:13:15memutuskan untuk membaca konteks, seperti memahami cara melakukan sesuatu yang baru. Jadi saya membuat perintah
00:13:20di sini karena saya memutuskan, oke, pada titik ini dalam percakapan, saya ingin menjalankan perintah ini untuk
00:13:27menghasilkan PRD yang terstruktur. Jadi sebagai bagian dari perintah ini, saya memberinya struktur yang tepat,
00:13:32semua bagian berbeda yang saya inginkan dalam PRD. Dengan begitu saya membuat seluruh proses saya dapat diulang,
00:13:38kan? Bagian besar dari sistem yang saya tunjukkan di sini adalah Anda bisa menciptakan sesuatu yang berhasil
00:13:42untuk Anda dan kemudian Anda bisa melakukannya berulang-ulang untuk fitur baru dan basis kode baru.
00:13:48Jadi saya akan melakukan /create PRD. Saya akan membiarkannya berjalan dan saya akan kembali setelah kita punya
00:13:53PRD final kita. Oke, jadi PRD kita sekarang sudah dibuat dan sangat komprehensif, tapi itu bagus
00:14:00karena kita tidak akan mengirimkan ini semua sekaligus ke agen pengodean kita untuk diimplementasikan. Sebaliknya,
00:14:04kita akan membangun segala sesuatunya dalam fase-fase yang dijelaskan oleh PRD kita. Jadi saya tidak akan melakukan
00:14:09banyak validasi di depan kamera sekarang. Pastinya tidak sebanding dengan waktu Anda, tapi saya ingin mengatakan bahwa
00:14:14penting untuk membaca ini dan memastikan bahwa Anda benar-benar selaras dalam segala hal. Jika tidak,
00:14:18itu akan menyebabkan banyak kode buruk di masa depan. Dan hal pertama yang ingin saya sampaikan
00:14:22dengan cepat di sini adalah kita punya cakupan MVP kita dan dalam hal ini kita bisa melihat semua pertanyaan kita membuahkan hasil
00:14:29dalam PRD kita. Dan itu penting karena percakapan yang baru saja kita lakukan sebenarnya hanya konteks
00:14:34tidak terstruktur untuk dimasukkan ke dalam PRD. PRD adalah satu-satunya hal yang akan bertahan. Jadi kita perlu memastikan
00:14:40bahwa seluruh percakapan yang kita lakukan dengan agen kita benar-benar dimasukkan ke sini. Kita punya
00:14:44hal-hal di luar cakupan, yang sama pentingnya, yaitu apa yang tidak ingin kita bangun sekarang. Kita punya seluruh
00:14:49struktur direktori. Jadi ia sudah mengerti secara umum apa yang akan masuk ke basis kode kita,
00:14:53yang mana bagus karena kita sudah menetapkan tumpukan teknologi dan arsitektur kita. Dan hal yang
00:14:58penting dalam hal ini adalah kita punya fase-fase kerja kita. Jadi dari sini, saat kita menggunakan perintah utama
00:15:04yang akan kita bahas sebentar lagi, kita bisa menetapkan seperti, oke, apa yang sudah kita bangun
00:15:09di basis kode kita? Apa yang harus kita bangun selanjutnya berdasarkan PRD? Jadi ini akan menjadi salah satu
00:15:13potongan konteks yang penting di awal setiap percakapan saat kita membangun MVP kita. Dan omong-omong,
00:15:19inilah bagian itu sendiri di mana saya menjabarkan fase-fasenya. Masing-masing dari ini akan menjadi implementasi
00:15:24granular, salah satu putaran PIV kita. Jadi kita membangun fondasi dan kita membangun manajemen tautan.
00:15:29Lalu kita mengerjakan tema dan kita akan merencanakan masing-masing secara individual. Jadi kita tidak mencoba
00:15:33meminta agen pengodean melakukan terlalu banyak hal sekaligus. Oke. Jadi kita baru saja membuat PRD kita dan itu benar-benar
00:15:38hal terbesarnya. Jadi kita hampir sampai pada implementasi pertama kita. Hal berikutnya yang
00:15:43harus kita siapkan adalah aturan kita. Dan ini akan sangat mendasar pada awalnya karena aturan kita pasti
00:15:48akan paling berkembang seiring kita mengembangkan basis kode kita yang sebenarnya. Jadi saya menggunakan
00:15:53Kode Claude. Saya hanya merujuk ke .agents dan agents.md karena ini lebih merupakan standar universal
00:15:58untuk penamaan aturan global. Jadi hal yang penting di sini adalah batasan
00:16:04dan konvensi yang selalu kita inginkan agar diikuti oleh agen pengodean kita, ini masuk ke berkas aturan global kita.
00:16:10Jadi ini adalah hal-hal seperti perintah untuk menjalankan aplikasi kita, strategi pengujian kita, strategi pencatatan
00:16:16log kita. Apa pun yang kita bangun, kita selalu ingin agen pengodean kita melihat ini. Jadi kita ingin
00:16:20membuat ini sekarang, setidaknya versi awal untuk memulai. Dan komponen
00:16:25lain yang saya miliki di sini adalah folder referensi. Anda juga bisa menggunakan keahlian Kode Claude untuk ini,
00:16:30tapi ini lebih universal karena sering kali kita punya konteks lain yang kita ingin agar diingat oleh agen,
00:16:35tapi hanya saat kita mengerjakan bagian tertentu dari aplikasi kita, seperti panduan
00:16:40untuk membangun komponen front-end jika kita sedang mengerjakan bagian front-end. Dan alasan kita tidak ingin
00:16:44begitu saja memasukkan semuanya ke dalam agents.md adalah berkas ini dimuat ke dalam konteks agen pengodean
00:16:49setiap kali ada percakapan. Dan ingat, konteks itu berharga. Jadi kita ingin menjaga ini tetap ringkas
00:16:55dan kemudian arahkan saja ia ke masing-masing berkas ini. Jadi kita bisa memberitahu agen pengodean, jika Anda sedang bekerja
00:17:00di front-end, maka Anda bisa membaca berkas ini. Atau jika Anda membangun titik akhir API baru, maka Anda bisa
00:17:04Jadi ini pada dasarnya adalah pengungkapan progresif. Kami memiliki berbagai lapisan konteks
00:17:09yang dapat ditemukan agen seiring waktu untuk memastikan ia hanya memuat apa yang benar-benar dibutuhkan
00:17:14berdasarkan tugas yang sedang dikerjakan. Dan untuk yang satu ini, saya punya perintah lain lagi. Sekali lagi, jadikan semuanya perintah,
00:17:20sama seperti saya punya templat yang saya suka untuk PRD. Saya punya templat yang saya suka untuk membuat
00:17:25aturan global saya. Jadi pertama-tama kita akan menelusuri apa yang sudah kita miliki di basis kode.
00:17:30Karena saya membuat ini agar bisa bekerja untuk basis kode yang sudah ada maupun yang baru. Dan untuk ini, yang akan dijelajahi
00:17:35hanyalah PRD. Ia akan mencari tahu apa tumpukan teknologi kita, apa arsitektur kita,
00:17:38melakukan riset web untuk strategi pengujian dan pencatatan log, lalu menyatukan semuanya
00:17:43dengan panduan saya untuk membuat aturan global. Dan saya memiliki struktur yang tepat di sini. Dan
00:17:50itu akan didasarkan pada templat yang saya miliki ini. Jadi saya akan tunjukkan ini dengan cepat juga,
00:17:55karena ini adalah templat yang suka saya gunakan untuk semua aturan global saya. Dan Anda bisa melihat bahwa
00:17:59semua yang ada di sini benar-benar kita pedulikan untuk agen kita, apa pun kondisinya. Seperti, oke, inilah tumpukan teknologi kami,
00:18:04perintah untuk menjalankan dan menguji berbagai hal, struktur proyek kami. Jadi ini pada dasarnya memiliki indeks dari
00:18:08basis kode kami, arsitektur kami, pola kode kami, seperti konvensi penamaan, strategi
00:18:13pengujian dan validasi. Secara keseluruhan cukup mendasar, tapi kita akan membuat ini terlebih dahulu,
00:18:17dan kemudian saya akan memberi Anda beberapa contoh dokumen referensi seperti konteks on-demand sekunder kami.
00:18:22Jadi saya akan masuk ke Claude di sini dan benar-benar hanya dalam percakapan yang sama saat saya membuat
00:18:27PRD saya, saya hanya akan mengetik “create rules” karena saya benar-benar bisa menggunakan semua percakapan ini sebagai konteks
00:18:33untuk membantu. Jadi seketika ia tahu, oke, inilah PRD kita. Inilah tumpukan teknologi kita dan hal-hal
00:18:38seperti itu. Baiklah. Perintah “create rules” kami selesai, dan sekarang kita memiliki aturan global. Dan
00:18:43saya sudah membukanya. Cukup standar di sini. Kita punya tumpukan teknologi, perintah-perintahnya,
00:18:47seperti kita menggunakan Drizzle ORM untuk basis data kita, misalnya, struktur proyek, arsitektur,
00:18:52pola kode. Demi singkatnya, saya tidak benar-benar menyesuaikan hal-hal di sini atau menerapkan pemikiran
00:18:57saya sendiri pada bagian ini, tetapi tergantung pada seberapa teknis Anda, ini adalah waktu Anda untuk memastikan
00:19:03bahwa batasan dan konvensi, pola kode, benar-benar selaras dengan cara Anda ingin
00:19:07membuat basis kode Anda. Jadi Anda bisa menghabiskan banyak waktu di sini jika mau. Saya tidak melakukannya
00:19:12karena saya sedang fokus pada ide-ide tingkat tinggi bersama Anda saat ini. Dan saya juga memintanya melakukan riset
00:19:16web tentang praktik terbaik untuk membuat hal-hal seperti komponen front-end dan endpoint API.
00:19:21Dan berdasarkan itu, saya juga harus membuat beberapa konteks on-demand. Dan sekali lagi,
00:19:24ini bisa berupa skill kode Claude jika Anda mau. Jadi jika kita kembali ke aturan global dan kita
00:19:29gulir ke bawah ke bagian konteks on-demand, ini dia. Saat mengerjakan komponen front-end,
00:19:34baca file ini. Saat mengerjakan rute API, baca file ini. Jadi claud.md adalah satu-satunya hal yang dimuat
00:19:40di awal, tapi kemudian ia akan memutuskan untuk memasukkan ini saat dibutuhkan. Dan dalam pengalaman saya, ia sangat
00:19:45pintar mereferensikan ini, terutama jika aturan global kita ringkas, sebagaimana mestinya. Seperti kita bahkan tidak
00:19:50sampai punya 240 baris di sini. Ada 233 baris untuk aturan global kami. Lalu kita punya api.md dan
00:19:58components.md. Ini jauh lebih besar karena saat kita sedang mengerjakan tugas dan itu sangat spesifik
00:20:03untuk bagian ini, maka tidak apa-apa untuk memasukkan lebih banyak informasi guna memastikan kita memiliki panduan yang baik
00:20:08untuk agen pengkodean kita. Jadi sekali lagi, kembali ke diagram kita di sini, aturan, ini adalah bagaimana kita ingin
00:20:14membangun sesuatu. PRD adalah apa sebenarnya yang akan kita bangun. Dan dengan kedua hal ini dalam pikiran,
00:20:19hal terakhir yang ingin saya bicarakan di sini adalah perintah, khususnya perintah prime.
00:20:23Kemudian kita akan mulai membangun rencana untuk fase pertama kita dan membuat kodenya. Jadi pada titik ini,
00:20:29kita sudah memiliki lapisan AI awal. Kita punya PRD, aturan, dan perintah generik yang saya masukkan
00:20:34yang bisa Anda gunakan sendiri secara bebas. Dan sekarang kita lanjut ke implementasi. Tapi
00:20:39inilah masalahnya. Di awal setiap percakapan baru dengan asisten pengkodean AI,
00:20:44kita membutuhkannya untuk memahami situasi basis kodenya. Apa yang sedang kita bangun? Apa langkah selanjutnya? Di
00:20:50situlah perintah prime berperan. Dan ini adalah sebuah perintah. Kita akan menjalankan /prime di awal setiap
00:20:56sesi baru. Ini adalah proses terpandu baginya untuk menjelajahi basis kode kita dan membawanya ke titik
00:21:02di mana ia memiliki model mental, di mana ia siap untuk implementasi fitur berikutnya. Dan jadi kita
00:21:06akan memintanya membaca dokumentasi, menjelajahi strukturnya. Ia juga bisa menggunakan sub-agen untuk melakukan semua ini.
00:21:11Memeriksa log git, karena itu hal lain yang akan saya bicarakan lebih lanjut sebentar lagi,
00:21:15yaitu menggunakan log git sebagai memori jangka panjang kita. Jadi ia bisa melihat seiring waktu bagaimana basis kode kita berkembang,
00:21:21karena itu akan membantunya membuat keputusan tentang apa yang akan ia bangun selanjutnya. Dan setelah perintah ini,
00:21:26ia akan memberikan output kepada kita berupa pemahamannya tentang basis kode. Jadi kita bisa memvalidasi bahwa ia tahu
00:21:31apa yang terjadi dengan basis kode kita, dan kita bisa lanjut membangun hal berikutnya. Dan untuk tidak
00:21:36membahas perintah prime terlalu mendalam di sini, tapi kita melakukan beberapa operasi dengan git untuk memanfaatkan
00:21:40riwayatnya. Lalu kita membaca file-file inti dan mengidentifikasi apa pun yang
00:21:45perlu kita beri perhatian khusus, seperti titik masuk utama ke aplikasi kita, misalnya. Dan
00:21:49kemudian laporan output ini adalah cara kita memvalidasi pemahamannya. Dan kita bisa mengembangkan ini seiring waktu untuk
00:21:55menjadikannya spesifik bagi proyek kita. Hanya untuk memberi satu contoh kecil di sini, untuk membaca dokumentasi
00:22:01inti, saya bisa mengatakan “baca migrasi drizzle agar kamu memahami skema basis data,”
00:22:08kan? Ia bahkan punya pelengkapan otomatis tadi. Ia tahu persis apa yang saya tuju. Dan seiring Anda
00:22:12membangun pemahaman Anda sendiri tentang hal-hal inti apa yang ingin Anda perhatikan oleh agen pengkodean
00:22:16dalam basis kode ini, seperti mungkin dokumentasi lain yang kita miliki di folder referensi,
00:22:20misalnya, kita bisa menambahkannya di sini. Dan sekarang yang akan saya lakukan adalah masuk ke Claude, tapi saya akan
00:22:25memulai percakapan baru yang benar-benar segar, karena sekarang kita akan masuk ke loop PIV pertama kita. Dan saya akan
00:22:30menjelaskan seluruh loop PIV sebentar lagi di sini, tapi lihat ini. Saya hanya akan menjalankan Prime. Dan
00:22:34itu akan menjadi awal percakapan saya sebelum saya melakukan apa pun yang ingin saya jelajahi. Dan dalam
00:22:39kasus ini, ia akan menyadari bahwa, oke, ini proyek baru. Biar saya periksa PRD-nya. Dan
00:22:44ia akan merekomendasikan seperti, ayo lakukan fase satu dulu. Mari kita buat fondasi untuk proyek kita.
00:22:49Jadi Prime kita selesai. Inilah gambaran umum proyek pembuat halaman link in bio. Keadaan saat ini,
00:22:54ini adalah repositori kosong yang hanya berisi dokumentasi. Saya memang sempat melakukan uji build sebelumnya, itulah sebabnya tertulis
00:22:59seperti ini, tapi saya sudah menghapus semuanya untuk saat ini. Dan kemudian ia mengambil fase pertama, fondasinya,
00:23:04dari PRD kita. Dan inilah yang ia rekomendasikan untuk kita bangun. Dan itulah tepatnya yang saya
00:23:10tuju di sini. Saya ingin ia mengambil fase satu per satu dari PRD. Jadi kita punya implementasi
00:23:14yang terperinci untuk loop PIV kita, yang berbicara tentang loop PIV, kita akan membahasnya sekarang.
00:23:20Jadi PIV adalah singkatan dari plan (rencana), implement (implementasi), validate (validasi). Kita mengambil pekerjaan yang terfokus, biasanya satu fase dari PRD,
00:23:29dan kita menjalankannya melalui seluruh proses ini. Jadi kita membuat rencana terstruktur. Itu adalah bagian
00:23:34di sini tentang apa yang akan kita kerjakan. Dan proses ini sebenarnya sangat mirip dengan
00:23:38membuat PRD. Kemudian kita masuk ke implementasi. Dan tujuan kita di sini adalah untuk mendelegasikan semua pengkodean kepada
00:23:44agen pengkodean. Dan kemudian kita melakukan validasi setelahnya. Jadi saya akan membahas dengan sangat cepat seperti apa
00:23:50proses ini. Lalu kita akan melihatnya langsung beraksi. Dan pertama-tama, saat kita berada dalam
00:23:55tahap perencanaan, kita punya dua lapisan perencanaan, kita punya perencanaan proyek tingkat atas. Itulah yang
00:24:00sudah kita lakukan saat membuat PRD dan aturan kita. Dan sekarang kita punya perencanaan spesifik tugas. Jadi seperti yang
00:24:07baru saja saya sebutkan, ini cukup mirip. Membuat rencana terstruktur itu sangat mirip dengan membuat
00:24:13PRD terstruktur kami. Perbedaan utamanya adalah rencana terstruktur hanya sangat terfokus pada
00:24:19fitur individual dan semua tugas yang menyertainya. Jadi sekarang kita beralih ke bagian
00:24:24kode. Kita tidak lagi di tingkat tinggi, tapi kita masih akan mulai dengan percakapan yang sangat
00:24:30tidak terstruktur. Saya suka menyebutnya vibe planning, di mana kita hanya akan menjelajahi ide-ide umum.
00:24:35Apa arsitektur untuk apa yang kita bangun secara spesifik, menjalankan sub-agen untuk analisis basis
00:24:40kode dan dokumentasi, lalu mencari tahu apa tugas-tugas spesifik yang perlu kita
00:24:44selesaikan untuk fitur ini. Jadi kita melakukan percakapan ini dan saya akan menunjukkan contohnya kepada Anda.
00:24:50Lalu kita mengubahnya menjadi dokumen terstruktur, persis seperti dengan PRD. Jadi tujuannya di sini adalah untuk
00:24:56membuat rencana penyerangan yang terperinci untuk asisten pengkodean AI berdasarkan percakapan kita. Jadi
00:25:02percakapan tersebut adalah bagian dari konteks kita, tetapi di sini kita memiliki bagian-bagian yang sangat spesifik yang ingin saya buat
00:25:09dalam rencana terstruktur. Tujuan dan kriteria keberhasilan fitur ini, dokumentasi apa pun
00:25:13yang ingin kita referensikan yang mungkin ditemukan oleh salah satu sub-agen, daftar tugas kita, yang bisa jadi
00:25:18sangat spesifik bahkan sampai ke file-file individual yang ingin kita buat dan perbarui. Dan kemudian mungkin bagian yang
00:25:23paling penting dari seluruh rencana ini adalah strategi validasi. Ini semacam pengujian berbasis
00:25:27pengembangan di mana kita ingin sangat spesifik dengan bagaimana kita bisa memvalidasi fitur tersebut
00:25:33bahkan sebelum kita menulis satu baris kode pun. Ini memaksa kita maupun agen pengkodean untuk menjadi sangat
00:25:38spesifik tentang kriteria keberhasilan. Jadi kita membuat rencana terstruktur kita dan kita sangat
00:25:45terlibat dalam hal ini, tetapi kemudian kita mendelegasikan semua pengkodean kepada agen itu sendiri. Ini bukan vibe
00:25:51coding. Satu-satunya alasan saya akan mempercayai agen tersebut tetapi tetap memverifikasinya adalah karena saya
00:25:56mengapit implementasi dengan perencanaan dan validasi di mana saya sangat terlibat di dalam
00:26:01prosesnya. Dan jadi kita akan meminta agen pengkodean memeriksa pekerjaannya sendiri dengan unit testing,
00:26:06integration testing, dan end-to-end testing. Kita akan melihatnya juga. Tapi kemudian saya akan menjalankan
00:26:11tinjauan kode saya sendiri dan menguji aplikasi secara manual. Saya akan mengirimkannya sendiri. Saya akan memeriksa
00:26:16aplikasi layaknya pengguna untuk memastikan semuanya berjalan baik sebelum saya melakukan
00:26:20commit dan mengirimkannya ke produksi atau staging atau apa pun. Hal yang penting di sini adalah bahwa di
00:26:26antara perencanaan dan implementasi, saya akan menyetel ulang konteksnya. Ini adalah salah satu
00:26:32aturan emas. Konteks itu sangat berharga. Jadi saya melakukan percakapan panjang dan terperinci untuk mencari tahu
00:26:38fitur yang akan kita implementasikan ini. Dan kemudian rencana terstruktur yang saya buat di sini, saya ingin itu
00:26:44menjadi semua konteks yang dibutuhkan agen pengkodean untuk menyelesaikan pekerjaan sehingga saya bisa memiliki
00:26:50percakapan baru di mana rencana tersebut adalah satu-satunya hal yang saya kirimkan karena ia sudah memiliki semua dokumentasi untuk
00:26:55direferensikan. Ia punya seluruh daftar tugas. Jadi kita tahu apa yang harus kita lakukan. Kita tahu cara memvalidasi. Dengan
00:27:00begitu kita bisa memutus segalanya dan langsung ke eksekusi agar hal-hal tetap sangat terfokus, kan? Kita
00:27:06ingin tidak memiliki banyak konteks yang membengkakkan percakapan saat kita masuk ke penulisan kode
00:27:12yang sebenarnya. Baiklah. Dengan itu, mari kita masuk ke loop PIV pertama kita. Dan ini akan jauh
00:27:16lebih sederhana dari yang Anda duga karena kita benar-benar akan memetik hasil dari semua perencanaan
00:27:22yang kita lakukan di awal. Kita sudah satu pemahaman dengan agen pengkodean kita. Kita yakin, ia mengerti apa
00:27:27yang ingin kita bangun. Jadi bahkan tidak terlalu banyak perencanaan yang harus kita lakukan untuk setiap
00:27:31fase ini, setidaknya pada awalnya. Jadi kembali ke sini, kita sudah menyelesaikan prime. Kita sudah satu
00:27:36pemahaman dengan agen pengkodean. Dan saya baru saja memberinya prompt yang sangat sederhana di sini. Seperti, ya, fase satu
00:27:40terlihat bagus. Konfirmasikan saja kepada saya persis semua yang akan kita bangun. Nah, biasanya untuk loop
00:27:44PIV setelah yang pertama, itu sedikit lebih detail. Seperti mari kita lihat basis kodenya untuk mencari tahu bagaimana
00:27:49persisnya kita akan membangun ini. Tapi di sini, ini sangat sederhana. Jadi ini terlihat bagus. Dan sekarang
00:27:53ingat, jadikan semuanya perintah. Saya ingin mengubah percakapan ini dan ide fase satu ini menjadi
00:27:59rencana terstruktur dengan daftar tugas dan validasi. Jadi saya punya perintah lain untuk itu. Namanya
00:28:04create atau plan feature /plan-feature. Nah itu dia. Jadi saya akan kirimkan ini dan sekarang plan
00:28:10feature, sama seperti create PRD, ia memiliki konsep rencana terstruktur bawaan. Jadi saya akan tunjukkan
00:28:17perintah ini juga. Jadi plan feature, buka ini. Jadi ia menerima argumen opsional di mana saya bisa
00:28:23menentukan apa yang ingin saya bangun. Dalam hal ini, saya hanya menggunakan riwayat percakapan. Jadi ia sudah tahu,
00:28:28tapi kita melalui proses bertahap di sini. Jadi pemahaman fitur mendalam ke basis kode, yang
00:28:33sekali lagi, lebih berlaku untuk loop PIV di masa mendatang, tapi ia melakukan banyak riset, menarik dokumentasi
00:28:38yang relevan, memastikan kita memiliki rangkaian konteks yang kaya saat masuk ke eksekusi. Dan kemudian
00:28:44apa yang Anda lihat di sini, ini adalah templatnya. Jadi kita ingin mendeskripsikan pernyataan masalah,
00:28:49konteks atau referensi apa pun. Kita punya rencana implementasi dengan daftar tugas di sini. Dan tentu
00:28:55saja kita punya strategi pengujian. Kita ingin mendefinisikan validasi di depan. Dan setelah kita membuat
00:29:00rencana ini, tentu saja, kita akan memvalidasinya. Kita akan memastikan bahwa kita sangat spesifik,
00:29:05langkah-demi-langkah inilah tepatnya cara kita ingin Anda memvalidasi aplikasi. Dan saya sebenarnya menggunakan
00:29:11skill Vercel agent browser CLI, yang sudah saya buatkan videonya dan akan saya tautkan di sini. Jadi kita
00:29:17akan membangun otomatisasi browser penuh. Agen akan menjalankan backend dan frontend
00:29:21serta menjalankan migrasi basis data, menelusuri seperti membangun link tree miliknya sendiri dan pada dasarnya hanya memastikan
00:29:26semuanya berjalan persis seperti cara pengguna menggunakan aplikasi. Jadi cukup menarik,
00:29:31tapi validasinya akan sangat detail di sini sehingga pada saat kontrol dikembalikan
00:29:36kepada kita, kita bisa sangat percaya diri pada implementasinya sambil tetap melakukan validasi sendiri, tapi itu akan
00:29:42menjadi jauh lebih sedikit pekerjaan. Oke. Dan rencana kita sudah dibuat sekarang. Jadi mari kita lihat. Jadi saya melakukan
00:29:47sedikit validasi di luar rekaman. Saya akan tunjukkan itu sebentar lagi. Biasanya Anda akan melakukan iterasi yang cukup banyak
00:29:52karena Anda ingin memastikan pemahamannya tentang fase satu selaras dengan apa yang Anda miliki di
00:29:56PRD, apa yang sebenarnya ingin Anda bangun, telusuri semua bagiannya. Saya mendorong Anda untuk melakukannya. Jadi
00:30:01inilah rencana implementasi kita dengan daftar tugas. Ini sangat detail, yang mana itu bagus. Kita ingin menjadi
00:30:05spesifik sekarang karena kita sangat terfokus pada fitur tunggal. Kita punya validasi kita dengan seluruh
00:30:10piramida validasi, sebutan saya untuk itu. Jadi pemeriksaan tipe dan linting serta unit testing. Dan kemudian
00:30:15kita sangat spesifik untuk pengujian end-to-end, semua perjalanan pengguna yang kita ingin agen lalui.
00:30:20Jadi kita bisa yakin pada implementasinya saat kembali kepada kita. Dan itu adalah sesuatu
00:30:24yang awalnya tidak ia lakukan dengan terlalu baik. Jadi saya memang memberikan prompt tindak lanjut di sini hanya untuk memberi Anda
00:30:29contoh cepat tentang bagaimana kita bisa mengiterasi dan menyempurnakan rencana sebelum kita mengirimnya ke implementasi.
00:30:34Dan satu lagi permata kecil, saya berjanji kita akan masuk ke implementasi dalam sedetik,
00:30:38tapi ini sangat penting. Umumnya agen pengkodean bukan yang terbaik dalam menangani variabel
00:30:43lingkungan. Mereka akan bingung. Jika Anda tidak menyetel variabel lingkungan sebelum implementasi,
00:30:48ia hanya akan melakukan banyak pengujian bohongan dan mengatakan semuanya tervalidasi padahal sebenarnya tidak,
00:30:53itu sangat menjengkelkan. Jadi biasanya apa yang suka saya lakukan secara paralel dengan perencanaan
00:30:57adalah kita akan membuat .env.example dan saya akan memintanya melihat ke sana. Jadi ia tahu semua variabel
00:31:03lingkungan yang saya setel, dan kemudian saya akan mengatur variabel lingkungan saya juga. Jadi jelas
00:31:09saya tidak akan menunjukkan file ini karena berisi rahasia saya untuk URL basis data dan hal-hal seperti itu. Tapi
00:31:13karena saya sudah mengaturnya, sekarang kita bisa melibas seluruh implementasi dan kemudian tidak
00:31:19hanya menulis kode, tapi ia bisa menjalankan migrasi basis data, menyalakan backend dan frontend,
00:31:23menggunakan Vercel agent browser CLI untuk menguji semuanya. Dan ia tidak perlu terinterupsi agar saya
00:31:29bisa menyetel variabel lingkungan saya. Jadi saya sudah mengatur panggungnya dengan sempurna sekarang dan masuk ke
00:31:34implementasi dan saya cukup senang dengan rencana ini. Jadi sekarang ingat reset konteks karena konteks itu
00:31:40berharga. Saya sekarang berada di jendela konteks yang baru di mana saya akan menggunakan perintah eksekusi saya dan satu
00:31:45parameternya adalah rencana yang saya tunjukkan kepadanya. Hanya ini yang ia butuhkan untuk konteksnya sekarang. Dan apa yang
00:31:51akan saya lakukan adalah saya akan menjeda dan kembali setelah ia menelusuri semuanya. Dan benar-benar kita
00:31:56mendelegasikan semua pengkodean kepada agen sekarang, memetik hasil dari semua upaya yang kita berikan ke perencanaan.
00:32:01Setiap loop PIV pada titik ini akan menjadi sangat cepat sekarang karena kerja keras yang kita curahkan untuk
00:32:06hal ini. Baiklah, implementasi kita sudah selesai. Kita bisa melihat dari tangkapan layar bahwa ia melakukan pengujian
00:32:11end-to-end penuh. Jadi Anda bisa cukup yakin pada implementasinya karena agen tersebut sudah
00:32:16mengurus semuanya tepat di sini, tapi tetap penting bagi kita untuk melakukan validasi manusia. Kita
00:32:21benar-benar bisa memastikan bahwa kita mempercayai tetapi tetap memverifikasi. Jadi tinjauan kode, itu menjadi
00:32:26sangat mendalam. Jadi saya tidak akan melakukannya sekarang, tetapi jika Anda lebih teknis, itu
00:32:30pasti penting untuk Anda lakukan. Tapi yang akan saya lakukan adalah menguji aplikasinya secara langsung bersama Anda.
00:32:35Jadi satu-satunya hal yang saya lakukan di luar rekaman adalah saya sudah membuat akun untuk memastikan bahwa
00:32:39autentikasi dasarnya berfungsi, tapi saya belum melakukan apa pun di sini. Dan lihatlah ini. Ini
00:32:43sangat keren. Sudah terlihat sangat, sangat bagus. Jadi saya bisa menyetel nama tampilan saya. Saya bisa membuat bio seperti
00:32:49pembangun AI yang keren. Baiklah, saya bisa menyetel URL avatar saya. Jadi saya baru saja mengunggah gambar ke Imgur. Jadi, oke,
00:32:55itu terlihat sangat bagus juga. Saya bisa menambahkan beberapa tautan seperti, oke, saya akan masukkan YouTube. Dan itu adalah
00:32:59https [youtube.com/@colemedine](https://www.google.com/search?q=https://youtube.com/%40colemedine). Baiklah, terlihat bagus. Tambah tautan lain. Saya akan masukkan LinkedIn. Saya tidak
00:33:08punya URL LinkedIn saya sekarang. Jadi saya akan masukkan seperti linkedin.com saja. Tidak terlalu peduli. Baiklah,
00:33:11keren. Dan izinkan saya menambah satu lagi. Saya akan masukkan X. Baiklah, jadi mari kita masukkan x.com. Sangat keren. Dan saya
00:33:18bisa menyeret tautan-tautan ini untuk mengurutkan ulangnya. Ini secara otomatis tercermin di sini. Saya bisa melihat editornya saja lalu
00:33:24menyesuaikan pratinjaunya. Temanya tidak terlihat yang terbaik saat ini. Seperti ini hanya putih, tapi saya pikir
00:33:28itu baru akan ada di fase berikutnya karena sekarang kita baru membangun fondasinya. Jadi banyak dari
00:33:32ini yang belum sempurna, tapi masih terlihat sangat bagus untuk titik awal. Dan kemudian saya
00:33:37bisa klik simpan. Dan, um, oke, ya, mari kita muat endpoint API-nya. Ini dijalankan di localhost ini.
00:33:42Nah itu dia. Perubahan berhasil disimpan. Jadi saya bisa menyegarkan halaman dan semuanya akan tetap
00:33:46ada di sana. Baiklah. Itu luar biasa. Jadi ini terlihat sangat, sangat bagus. Sekarang, apa yang ingin saya bicarakan
00:33:51karena kita sudah sampai pada fondasi proyek yang baik adalah pesan commit secara singkat di sini.
00:33:57Dan jadi saya punya perintah lain bernama slash commit, dan ini sangat, sangat dasar. Anda bisa
00:34:01membuat ini lebih detail jika mau, tetapi pada dasarnya Anda hanya ingin memberikan instruksi kepada agen tentang
00:34:06bagaimana cara membuat pesan git, karena kita akan menggunakannya sebagai memori jangka panjang kita. Jadi kembali
00:34:11aturan emasnya. Riwayat commit Anda adalah memori jangka panjang
00:34:17Anda. Jadi jika kita menstandarisasi pesan kita—dan itulah alasan kita menggunakan perintah /commit agar
00:34:22ini bisa digunakan kembali—maka agen kita, saat sedang memproses prime, dapat melihat log git untuk melihat
00:34:28riwayat apa yang kita bangun baru-baru ini, yang akan memandu apa yang akan dikerjakan selanjutnya dan mungkin pola yang
00:34:32kita ingin ia ikuti. Dan itulah kekuatan dari pesan commit ini di sini. Jadi saya akan melakukan /commit,
00:34:38yang mana saya bisa saja menjalankan git commit sendiri. Itu sangat mudah, tetapi ini hanya membuat
00:34:43pesannya selalu jenis yang sama demi konsistensi. Jadi dalam hal ini, tidak ada yang perlu di-commit karena
00:34:48saya sudah menjalankannya di luar rekaman juga, tetapi itu penting dilakukan setelah setiap
00:34:53implementasi tunggal. Sekarang, satu hal super penting lainnya yang harus dibahas setelah kita memiliki pondasi
00:34:58proyek kita adalah Anda ingin menyiapkan kerangka kerja untuk pengujian regresi. Kita ingin memastikan
00:35:04bahwa saat kita melewati loop PIV di masa mendatang, jadi kita melalui proses ini berulang-ulang untuk semua
00:35:09fitur yang ingin kita bangun, kita perlu memastikan hal-hal lama tidak rusak. Dan ini akan
00:35:14saya bahas lebih lanjut di video lain, semua strategi yang saya miliki untuk mengimplementasikan jenis
00:35:19harness pengujian ini sendiri, karena pada dasarnya Anda pergi ke agen, Anda katakan seperti, oke, apa yang
00:35:25kita miliki sekarang sudah bagus, tetapi saya juga bisa masuk ke Aqua voice di sini dan berkata, saya ingin Anda mencatat semua
00:35:31pengujian end-to-end yang Anda lakukan, masukkan ini ke dalam sebuah perintah untuk saya. Jadi saya bisa menjalankannya nanti setelah saya
00:35:36membangun fitur lain sehingga kita bisa memastikan bahwa semua yang kita bangun sebelumnya masih
00:35:41berjalan, kan? Sesuatu seperti itu. Sekali lagi, saya tidak akan terlalu mendalami ini
00:35:46sekarang. Butuh waktu lama untuk menyiapkannya dan membuat test harness, tetapi begitulah cara Anda memastikan
00:35:50bahwa aplikasi Anda stabil saat Anda terus membangun di atasnya. Dan memang butuh
00:35:55banyak kerja keras untuk membuat dan memelihara ini karena Anda terus-menerus harus memperbaruinya. Jadi ada juga
00:36:00solusi di luar sana yang menangani hal ini untuk Anda. Dan mereka sangat hebat. Salah satu
00:36:05aplikasi tersebut adalah QA tech. Mereka memiliki agen pengujian AI yang berevolusi, mereka beradaptasi dengan basis kode Anda.
00:36:11Jadi saat Anda menambahkan lebih banyak fitur, mereka menambahkan lebih banyak kasus uji untuk memastikan bahwa
00:36:16semuanya, aplikasi Anda bekerja dengan baik saat Anda terus membangunnya. Dan saya akan
00:36:22menunjukkan contohnya dengan cepat. Sangat mudah untuk memulainya. Jadi Anda masuk ke QA tech, mereka punya
00:36:26tingkat gratis bagi Anda untuk memulai dan mencobanya. Saya akan buat proyek di sini, lalu Anda hanya perlu
00:36:30menempelkan URL yang ingin Anda uji. Jadi saya mengambil aplikasi ini karena saya sudah membuat commit
00:36:35dan mendorongnya ke GitHub. Saya menerapkannya hanya dalam satu menit ke Vercel. Tempat termudah untuk
00:36:40menghos situs Anda secara gratis, terutama saat Anda membangun dengan Next.js. Jadi saya akan buka proyek saya di sini
00:36:45dan tempelkan saja URL ini. Ini akan memakan sedikit waktu untuk membuat proyek dan menganalisis
00:36:50basis kode Anda. Dan apa yang bisa kita lakukan adalah mengatakan, saya ingin pengaturan pengujian yang baik untuk situs saya. Bantu saya membuat
00:36:55tiga sampai lima kasus uji pertama. Dan ini semacam, Anda tahu, seperti bolt.new atau lovable,
00:36:59atau Anda bisa memberikan prompt untuk apa pun yang Anda ingin lakukan untuk menyiapkan rangkaian pengujian bagi
00:37:04proyek Anda. Tetapi ini adalah apa yang mereka rekomendasikan untuk memulai. Saya akan kirim ini.
00:37:08Dan ini sangat keren karena ia akan menelusuri situs web Anda, benar-benar merayapinya, tetapi Anda
00:37:12tidak perlu mengelola infrastrukturnya sama sekali. Ia menganalisis situs web Anda dan membuat
00:37:16kasus pengujiannya. Saya akan kembali setelah selesai. Jadi di tengah eksekusi, saya hanya ingin menunjukkan dengan cepat
00:37:21bahwa ia merayapi situs web saya hanya dalam beberapa menit. Dan kemudian salah satu hal yang sangat penting
00:37:25adalah kita butuh cara untuk masuk ke situs web kita. Kita ingin otomatisasi bisa melakukan itu. Dan
00:37:29mereka punya cara bagi kita untuk memasukkan nama pengguna dan kata sandi, lalu mereka akan menyimpannya
00:37:34dengan cara yang aman. Saya punya akun uji coba yang dibuat di sini. Saya akan simpan itu. Dan kemudian
00:37:38ia akan menggunakannya untuk masuk ke situs web, benar-benar mendalami dan memahami semua perjalanan pengguna yang
00:37:43ingin kita uji di sini. Dan lihatlah. Ia telah menghasilkan banyak kasus uji untuk kita, dan kita
00:37:48bahkan bisa mengklik masing-masing kasus tersebut. Dan kita bisa melihat alur tepat yang dilaluinya. Jadi sekarang kita
00:37:53memiliki semua pengujian yang sudah disiapkan. Dan agen pengujian AI di QA tech akan mengembangkan
00:37:59kasus-kasus uji ini seiring waktu untuk memastikan ia terus mencakup semuanya di basis kode kita. Saat kita membangun lebih
00:38:04banyak fitur, ini benar-benar sangat keren. Sekali lagi, kita bisa membangun sistem perintah kita sendiri
00:38:09untuk melakukan sesuatu seperti ini. Namun saya sangat menghargai memiliki platform yang menangani semua ini
00:38:14untuk saya. Dan ada agen di balik layar yang bisa saya ajak mengobrol untuk sekadar bekerja dengan
00:38:19pengujian di sini dan memastikan bahwa saya benar-benar melakukan pengujian regresi pada semuanya. Jadi kapan pun ada
00:38:24sesuatu yang rusak, saya bisa datang ke sini dan berkata, oke, ada bug pada aplikasi saat ini,
00:38:28buat pengujian yang seharusnya gagal. Biarkan saya mengatasi masalahnya. Dan kemudian pengujiannya
00:38:33seharusnya berhasil. Dan itu membawa kita ke aturan emas terakhir yang saya miliki di sini, pola pikir evolusi sistem.
00:38:40Jadi setiap kali kita menemukan bug di basis kode kita, penting untuk tidak hanya memperbaiki bug tersebut,
00:38:46tetapi pikirkan tentang apa yang bisa kita perbaiki di lapisan AI kita. Agar itu tidak terjadi lagi. Seperti mungkin kita perlu
00:38:51lebih spesifik tentang panduan gaya dan aturan kita, atau membuat konteks sesuai permintaan yang baru untuk itu.
00:38:57Mungkin kita perlu memiliki lebih banyak pengujian end-to-end yang dijabarkan dalam perintah kita, alur kerja kita,
00:39:02apa pun yang diperlukan untuk memastikan kita tidak menghadapi masalah ini lagi. Dan kemudian kita juga bisa
00:39:06melakukan apa yang baru saja saya tunjukkan di QA tech atau sistem perintah kita sendiri, di mana kita menambahkan pengujian untuk memastikan bahwa kita
00:39:12tidak menghadapi masalah itu lagi di basis kode. Jadi kekuatan dari ini, meskipun membutuhkan
00:39:16waktu untuk melakukannya, adalah kita membuat agen pengodean kita lebih andal dan dapat diulang dari waktu ke waktu, mengembangkannya
00:39:21bersamaan dengan basis kode kita. Jadi kita melakukan tiga hal secara paralel. Saat kita membangun
00:39:26basis kode kita, kita mengembangkan basis pengujian kita, basis kode kita, dan lapisan AI kita. Dan kawan, itu
00:39:32akan berlipat ganda seiring berjalannya waktu. Kembali ke cloud code di sini, saya akan memberi Anda contoh yang sangat sederhana mengenai
00:39:37hal ini. Satu hal yang saya lakukan untuk iterasi sekali di luar rekaman adalah saya mengerjakan gaya untuk situsnya.
00:39:43Karena jika Anda kembali ke awal video, Anda akan melihat bahwa saya agak lupa membicarakan tentang
00:39:47gaya, tepatnya bagaimana saya ingin situs itu terlihat. Jadi cloud code membuat asumsinya sendiri
00:39:51di sana. Dan itu tidak terlihat yang terbaik. Jadi saya harus melakukan iterasi pada hal tersebut. Dan satu hal yang bisa saya lakukan
00:39:56di sini adalah, Anda tahu, pada awalnya saya tidak suka gaya yang Anda terapkan untuk front end. Kita
00:40:01pasti tidak punya cukup di lapisan AI dengan aturan kita dan konteks sesuai permintaan untuk sebuah panduan
00:40:06gaya. Jadi saya ingin Anda melakukan meta reasoning di sini. Jangan mengubah apa pun, tetapi bantu saya berpikir
00:40:10saat ini, apa yang bisa kita ubah pada aturan kita atau konteks sesuai permintaan, sesuatu yang bisa kita
00:40:15tambahkan atau perbarui sehingga kita memiliki gaya yang lebih konsisten yang akan kita bangun saat kita
00:40:20terus membangun analitik dan hal-hal lain, halaman lain dalam aplikasi ini.
00:40:25Dan hal penting yang saya lakukan di sini adalah menyuruhnya untuk tidak mengubah apa pun dulu,
00:40:29karena biasanya saya ingin memiliki kontrol lebih besar atas pengubahan lapisan AI dibandingkan untuk basis
00:40:34kode, saya hanya ingin mendelegasikan sebanyak mungkin hal itu kepada agen. Jadi saya memintanya menalar bersama saya,
00:40:39tetapi saya biasanya suka membuat perubahan kecil dan sangat terfokus ini sendiri. Dan Anda bisa lihat di sini bahwa
00:40:44ia merekomendasikan pembuatan style.md di folder referensi. Potongan ketiga konteks sesuai permintaan untuk
00:40:50kita. Dan ini, saya kira akan sejalan dengan components.md. Itu lebih seperti, beginilah cara kita
00:40:54menyusun sesuatu. Dan kemudian styles.md ada di sini untuk menjelaskan cara kerjanya. Beginilah cara kita harus bekerja
00:40:58dengan Tailwind CSS dan mungkin Shad CN, misalnya. Jadi saya tidak akan menjalani seluruh
00:41:03implementasi ini dan mengoreksi segalanya, tetapi hanya mencoba memberi Anda contoh yang baik di sini tentang
00:41:06bagaimana, saat kita menghadapi apa pun di mana terdapat bug dalam kode atau hanya kurang selaras dengan kita,
00:41:11seperti yang kita miliki di sini, itu selalu merupakan kesempatan bagi kita untuk mengembangkan lapisan AI. Jadi kita menjadi
00:41:16semakin selaras dengan agen pengodean kita untuk proyek spesifik ini, seiring kita terus membangunnya.
00:41:20Dan itu, kawan, adalah bagian yang paling berpengaruh dari seluruh proses, benar-benar menyimpan yang terbaik untuk
00:41:26bagian akhir. Jadi itu saja semuanya. Ini benar-benar proses yang sangat sederhana untuk mendapatkan hasil yang andal dan dapat diulang
00:41:32dengan agen pengodean Anda saat Anda memulai proyek baru, karena sekarang setelah
00:41:35evolusi sistem, kita tinggal membawanya kembali ke atas dan kita melalui lebih banyak loop PIV melalui
00:41:40proses yang sama persis untuk membangun semua fase dalam PRD kita, menambahkan fitur lainnya, apa pun
00:41:45yang diperlukan untuk mencapai produk layak minimum (MVP) itu. Dan kemudian itu akan membawa kita ke pengembangan Brownfield
00:41:49pada salah satu video berikutnya yang akan saya unggah di saluran saya. Jadi jika semua ini terdengar bagus bagi Anda
00:41:54dan Anda ingin mendalami lebih jauh dengan pustaka sumber daya lengkap saya yang berisi perintah dan aturan, Anda ingin
00:41:59melihat seperti apa rupa evolusi sistem yang sebenarnya dan mendalaminya. Pastikan untuk memeriksa
00:42:04kursus pengodean agentic yang saya miliki di komunitas dynamics. Saya akan sertakan tautannya di
00:42:08deskripsi dan komentar yang disematkan. Jadi itulah semua yang saya miliki untuk Anda saat ini. Jika Anda
00:42:13menyukai video ini, dan menantikan lebih banyak hal tentang pengodean agentic di video pengembangan
00:42:17Brownfield, saya akan sangat menghargai like dan subscribe Anda. Dan dengan itu, saya akan sampai jumpa di
00:42:22video berikutnya.

Key Takeaway

Kerangka kerja ini menawarkan pendekatan sederhana namun disiplin dalam pengembangan perangkat lunak menggunakan agen AI melalui persiapan konteks yang matang dan siklus validasi yang ketat.

Highlights

Pentingnya membangun "AI Layer" yang terdiri dari PRD, aturan global, dan perintah khusus sebagai fondasi proyek.

Strategi pengurangan asumsi agen dengan meminta rangkaian pertanyaan detail sebelum penulisan kode dimulai.

Penerapan siklus PIV (Plan, Implement, Validate) untuk menjaga kualitas dan fokus pada setiap fase pengembangan.

Penggunaan sub-agen khusus riset untuk mengisolasi konteks dan mencegah degradasi performa model utama.

Manajemen konteks sebagai aturan emas untuk memastikan efisiensi token dan akurasi logika pemrograman AI.

Integrasi pengujian regresi otomatis menggunakan alat eksternal seperti QA Tech untuk menjaga stabilitas aplikasi.

Pola pikir evolusi sistem yang menekankan perbaikan instruksi AI setiap kali ditemukan kesalahan atau bug.

Timeline

Pendahuluan dan Filosofi Pengembangan Greenfield

Pembicara memperkenalkan kerangka kerja pengodean agentik yang sederhana untuk proyek baru atau disebut pengembangan Greenfield. Fokus utamanya adalah menghindari sistem multi-agen yang terlalu rumit di GitHub yang sering kali menyebabkan overengineering. Inti dari metode ini adalah penggunaan prinsip universal yang dapat diterapkan pada asisten AI apa pun seperti Claude atau ChatGPT. Penjelasan awal mencakup empat aturan emas termasuk manajemen konteks yang dianggap sebagai sumber daya paling berharga bagi pengembang. Bagian ini menekankan bahwa perencanaan yang matang di awal akan mempercepat seluruh proses implementasi di tahap berikutnya.

Membangun AI Layer: PRD dan Aturan Global

Bagian ini membahas pembentukan AI Layer yang terdiri dari aset-aset dasar seperti Product Requirements Document (PRD) dan aturan global. Pembicara menjelaskan bahwa AI Layer berfungsi sebagai peta jalan bagi agen untuk memahami apa yang harus dibangun dan bagaimana cara membangunnya secara konsisten. Penggunaan perintah atau keahlian (skills) yang dapat digunakan kembali sangat disarankan agar sistem dapat berevolusi seiring pertumbuhan basis kode. Melalui contoh proyek Linktree versi hos mandiri, audiens diajarkan cara mengumpulkan ide secara tidak terstruktur sebelum diformalkan. Perencanaan awal ini mungkin terasa lambat di awal, namun krusial untuk mencegah penulisan ribuan baris kode yang salah akibat ketidakselarasan visi.

Proses Curah Ide dan Pengurangan Asumsi Agen

Pembicara mendemonstrasikan teknik curah ide menggunakan alat pengubah ucapan ke teks untuk mentransfer konsep aplikasi ke Claude Code secara cepat. Strategi paling penting di sini adalah memaksa agen untuk memberikan banyak pertanyaan klarifikasi guna menghilangkan asumsi yang salah dari sisi AI. Pertanyaan pilihan ganda dari agen membantu mengunci detail teknis seperti struktur URL, batas pengguna, dan tumpukan teknologi seperti Next.js dan Neon. Penggunaan sub-agen riset juga diperkenalkan untuk menjaga kebersihan konteks utama dengan hanya menarik ringkasan temuan penting saja. Dengan menjawab puluhan pertanyaan detail, pengembang dapat menghemat waktu dari perbaikan bug logika yang mahal di masa mendatang.

Formalisasi PRD dan Pembuatan Aturan Instruksi

Setelah klarifikasi selesai, langkah selanjutnya adalah menjalankan perintah khusus untuk menghasilkan PRD terstruktur dalam format Markdown. PRD ini mencakup cakupan MVP, fase kerja, struktur direktori, dan hal-hal yang berada di luar cakupan proyek saat ini. Pembicara kemudian beralih ke pembuatan aturan global dalam berkas seperti agents.md yang berisi batasan dan konvensi pengodean universal. Teknik "pengungkapan progresif" diterapkan dengan memisahkan dokumen referensi khusus seperti panduan API atau komponen agar tidak membebani konteks agen secara sekaligus. Hal ini memastikan agen hanya memuat informasi yang benar-benar dibutuhkan sesuai dengan tugas yang sedang dikerjakan.

Perintah Prime dan Siklus PIV (Plan, Implement, Validate)

Sesi implementasi dimulai dengan perintah "/prime" di setiap sesi baru untuk menyelaraskan pemahaman agen terhadap kondisi terkini basis kode. Pembicara memperkenalkan metodologi PIV yang merupakan singkatan dari Plan (Rencana), Implement (Implementasi), dan Validate (Validasi). Tahap perencanaan tugas dilakukan dengan sangat detail, bahkan mencakup strategi validasi dan daftar tugas per berkas sebelum kode pertama ditulis. Salah satu aturan emas yang ditekankan kembali adalah mereset jendela konteks sebelum eksekusi untuk memastikan fokus total agen pada rencana yang telah disepakati. Metode ini mengubah gaya "vibe coding" yang tidak teratur menjadi proses delegasi pengodean yang terukur dan dapat diverifikasi.

Eksekusi Kode, Variabel Lingkungan, dan Demo Produk

Pada tahap implementasi, pembicara memberikan tip penting mengenai pengaturan variabel lingkungan sebelum agen mulai bekerja agar pengujian tidak gagal. Agen kemudian mengeksekusi rencana, melakukan migrasi basis data, dan menjalankan pengujian end-to-end secara otomatis menggunakan browser CLI. Hasilnya adalah aplikasi fungsional yang memungkinkan pengguna mengatur profil, menambahkan tautan sosial, dan mengurutkannya secara visual. Meskipun agen melakukan banyak pekerjaan, validasi manusia tetap diperlukan melalui tinjauan kode dan pengujian manual di browser. Demo menunjukkan bahwa meskipun desain visual belum sempurna, fondasi fungsional aplikasi telah berhasil dibangun dengan sangat cepat melalui metode ini.

Memori Jangka Panjang, Pengujian Regresi, dan Penutup

Di bagian akhir, pembicara menjelaskan pentingnya pesan commit git yang terstandarisasi sebagai memori jangka panjang bagi agen AI. Untuk menjaga stabilitas proyek dalam jangka panjang, disarankan menggunakan platform seperti QA Tech guna melakukan pengujian regresi otomatis yang terus berevolusi. Konsep terakhir adalah "Pola Pikir Evolusi Sistem" di mana setiap bug yang muncul harus memicu perbaikan pada AI Layer agar kesalahan serupa tidak terulang. Pembicara menyimpulkan bahwa proses ini menciptakan siklus pertumbuhan paralel antara kode aplikasi, rangkaian pengujian, dan instruksi AI. Video diakhiri dengan ajakan untuk bergabung dalam komunitas dan nantikan pembahasan mengenai pengembangan sistem yang sudah ada atau Brownfield.

Community Posts

View all posts