Mengapa AI berbasis agen bukan pair programmer yang baik

• Karena agen LLM menulis kode jauh lebih cepat daripada manusia, pengalaman pair programming justru bisa menurun
• Akibat otomatisasi yang terlalu cepat, pengguna sering tidak mampu mengikuti dan kehilangan konteks pekerjaan
• Fenomena ini mirip dengan rasa terasing yang dirasakan saat pairing dengan pengembang yang sangat berpengalaman, yang pada akhirnya melemahkan kontrol kualitas dan komunikasi
• Sebagai solusi, diajukan pendekatan kolaborasi yang berfokus pada code review asinkron, serta mengurangi kecepatan pairing dengan AI dan beralih ke workflow yang berpusat pada kontrol kualitas dan komunikasi
• Agen AI juga perlu dirancang agar lebih mirip manusia: “berhenti dan berdialog, serta fokus pada keraguan dan verifikasi alih-alih rasa percaya diri”

---

Masalah LLM agent dan pair programming

• Agen AI (misalnya Copilot Agent) menulis kode jauh lebih cepat daripada kecepatan berpikir manusia
• Akibatnya, kode mengalir deras bahkan sebelum pengguna sempat mengikutinya, sehingga konteks hilang dan tingkat keterlibatan dalam pekerjaan menurun
• Saat agen meminta bantuan dalam situasi bermasalah, pengguna sering belum memahami keadaannya dan akhirnya hanya berperan sebagai pihak yang “membereskan kekacauan”, sehingga beban untuk merapikan kode yang sudah berjalan ke arah yang salah menjadi lebih besar
• Pada akhirnya, kontrol kualitas, komunikasi, dan menjaga arah yang benar menjadi lebih sulit

• Pengalaman pairing dengan agen AI terbaik mengingatkan pada kenangan negatif dari masa lalu saat pairing dengan programmer manusia yang sangat hebat
  • Partner pair mengetik keyboard tanpa suara dengan kecepatan berlebihan, sehingga mustahil untuk mengikuti kodenya
  • Energi mental terkuras habis lalu perlahan menjauh dari pekerjaan
  • Ketika pair buntu dan meminta bantuan, muncul pengalaman canggung karena sulit memahami situasinya
  • Selama proses kerja, hasil implementasi yang melenceng dari tujuan pun terbentuk, dan beban untuk memperbaikinya sebelum tenggat berpindah kepada kita

The path forward: solusi praktis

• 1. Kolaborasi asinkron

  • Seperti ketika satu orang memimpin dalam pair programming dengan manusia, akan lebih efektif bila AI menulis kode secara mandiri lalu direview melalui Pull Request
  • Dengan memanfaatkan workflow asinkron seperti GitHub Coding Agent, pengguna dapat fokus pada review dan kontrol kualitas

• 2. Pairing “berbasis giliran” dengan kecepatan yang diperlambat

  • Alih-alih “Agent Mode” AI, gunakan pendekatan satu langkah tiap kali seperti Edit/Ask Mode
  • Seperti ping-pong pairing (satu pihak mengusulkan, satu pihak menyetujui), pengguna menerima/meninjau langsung perubahan yang diusulkan AI sambil mengatur kecepatannya
  • Sebaiknya AI tidak hanya dipakai untuk pemecahan masalah/debugging, tetapi dimanfaatkan dalam workflow yang konsisten

Ide untuk membuat pairing dengan agen lebih manusiawi

• Memungkinkan pengguna mengatur sendiri kecepatan keluaran kode (baris/menit, kata/menit)
• Fitur untuk menghentikan agen sementara, agar pengguna bisa bertanya atau menentang arah yang diambil
• Menyediakan primitive UI yang terhubung dengan progres pekerjaan, melampaui UI chatbot biasa (misalnya mengaitkan sesi saat ini ke issue GitHub tertentu, daftar To-do bawaan, dll.)
• Merancang agen agar lebih sering berhenti dan berdialog: memeriksa “mengapa ini dilakukan”, meminta saran, mengecek arah, dan membangun nuansa kolaborasi seperti dengan manusia
• Menghadirkan dukungan voice chat tingkat lanjut, agar pengguna bisa tetap memandang kode sambil berkomunikasi dengan AI lewat suara

• Jika fitur-fitur ini diterapkan, alih-alih pairing agen yang cepat dan sepihak seperti saat ini, akan dimungkinkan pengalaman kolaborasi manusia-agen yang sesungguhnya

Kesimpulan

• Saat ini kita sedang menyaksikan sekaligus batasan dan potensi pair programming berbasis agen AI
• Pair programming agen AI akan jauh lebih efektif bila dirancang berpusat pada komunikasi, kualitas, dan verifikasi—bukan sekadar kecepatan—seperti kolaborasi antarmanusia
• Pendekatan “pelan-pelan, sambil berdialog, memverifikasi, dan berbagi situasi” meningkatkan kualitas pairing dengan AI

[panarch]

> 1. Kolaborasi asinkron
> Seperti saat satu orang memimpin dalam pair programming dengan manusia, bentuk yang lebih efektif adalah AI menulis kode secara mandiri lalu meninjaunya melalui Pull Request

Saya sudah menggunakan Codex selama beberapa hari, dan saya lebih setuju dengan pendekatan ini daripada bentuk agent. Karena kini saya bisa menjalankan pekerjaan di beberapa proyek secara bersamaan, rasanya benar-benar seperti bekerja bersama beberapa developer junior.
Setelah bisa menggunakan AI secara asinkron, saya dapat menugaskan beberapa pekerjaan sekaligus di berbagai proyek, bahkan beberapa tugas dalam satu proyek, sehingga saya benar-benar merasakan produktivitas meningkat secara aritmetis lebih dari 3-10 kali lipat.

[GN⁺]

Opini Hacker News

• Rasanya ini tulisan yang menjelaskan dengan tepat kenapa saya cepat berhenti memakai AI dengan cara seperti ini. Saat saya ingin membuat sesuatu, biasanya saya sudah punya gambaran kasar tentang <i>caranya</i>, tetapi cara AI benar-benar mengerjakannya sering berbeda dari yang saya inginkan. Lalu ketika AI menghasilkan 2.000 baris kode sekaligus, anehnya pekerjaan malah bertambah. Saya harus memberi instruksi seperti, "hapus dulu semua komentar ini, penjelasannya dua kali lebih banyak daripada yang perlu untuk kode sederhana. Jangan abstraksikan X seperti ini, saya maunya begini..." lalu ketika saya memberi umpan balik, tiba-tiba 2.000 baris itu berubah drastis jadi 700 baris dan jadi sangat sulit diikuti. Saya juga tidak suka kalau codebase berubah jadi tumpukan skrip yang tidak saya pahami dengan baik dan masing-masing memakai gaya berbeda. Yang saya butuhkan adalah AI yang gaya dan cara berpikirnya mirip dengan saya, tetapi itulah bagian yang sangat sulit. Bekerja dengan AI terasa seperti bekerja dengan seseorang yang belum berpengalaman pada hari pertamanya. Secara pribadi, saya rasa ini bukan masalah kepercayaan diri alat, melainkan karena proses desain jadi lebih terekspos. Idealnya, saya ingin lebih dulu melihat dokumen rancangan seperti "saya sedang mempertimbangkan pendekatan ini, fungsi atau kelas seperti ini, status akan dikelola dengan cara ini", lalu kalau cocok baru lanjut ke implementasi.

  • Seperti halnya engineer manusia, saya ingin menekankan bahwa sesi perencanaan di awal memang sangat penting. Diskusikan dulu dan rapikan detailnya seperti sedang bernegosiasi sebelum menulis kode. Saya sengaja membuat pertanyaan pertama seumum mungkin untuk melihat apakah muncul rekomendasi tak terduga, lalu secara bertahap dibuat makin spesifik. Setelah cukup puas, saya meminta LLM membuat dua dokumen: initialprompt.txt dan TODO.md. Di initialprompt.txt ada ringkasan proyek dan instruksi untuk membaca TODO.md, serta perintah untuk mencentang setiap tahap setelah selesai. Dengan cara ini, LLM memahami tujuan besar sekaligus tugas rinci, dan nanti saat percakapan terputus lalu harus dimulai ulang karena batas konteks, ia bisa dengan cepat diingatkan lagi soal pekerjaannya.

  • Rasanya ini merangkum pengalaman saya persis. Saya hanya pernah berhasil menyelesaikan sesuatu dengan kode buatan AI ketika yang penting cuma hasil akhirnya dan saya hampir tidak punya pengetahuan latar di bidang tersebut. Kalau saya punya pendapat kuat tentang seperti apa hasil yang ‘bagus’, biasanya saya malah frustrasi dan akhirnya meninggalkan proyeknya. Saya sempat memakai fitur architect di roo code untuk merapikan pendekatannya dulu, lalu saat implementasi kode nyata di code mode rasanya setengah menyenangkan, setengah membuat frustrasi. Pelajaran pentingnya adalah selalu mulai tugas baru, jangan teruskan percakapan panjang. Saya biasanya tipe yang memecah masalah menjadi bagian kecil dan mengecek hasilnya, tetapi untuk LLM saya malah cenderung melempar seluruh ruang masalah sekaligus dan gagal. Saya sudah mencoba berkali-kali untuk menemukan cara saya sendiri, dan hari ini pun saya menambahkan fitur aplikasi hanya dalam 30 menit. Kalau saya kerjakan sendiri, itu benar-benar bisa makan beberapa hari. Dan saya memang mencatat hanya 30 menit kerja karena saya tahu persis apa yang saya inginkan dan tidak peduli pada prosesnya. Dari pengalaman seperti ini, saya sampai pada kesimpulan bahwa mustahil menyerahkan pada AI kode yang suatu hari harus dipakai orang lain, untuk semua alasan itu.

  • Pada akhirnya saya cuma merasa terlalu lelah, dan hasilnya pun selalu tidak memuaskan. Ini saya katakan untuk orang yang punya kekhawatiran serupa. Saya juga hanya pernah puas dengan agent coding untuk skrip jangka pendek yang kualitas kodenya tidak penting, atau fungsi daun yang benar-benar tidak berdampak ke mana-mana.

  • Alur kerja yang direkomendasikan dalam panduan penggunaan Claude Code dari Anthropic layak dicoba. Intinya adalah “suruh dia membaca kodenya dulu, lalu buat rencana perubahan, dan baru terakhir eksekusi.” Anda bisa meninjau dan mengoreksi rencana itu sebelum AI menulis satu baris kode pun. Saat memakai agent, kalau ia bergerak tidak sesuai cara yang Anda inginkan, misalnya langsung menulis kode tanpa rancangan, Anda cukup bilang "lakukan dengan cara lain".

  • Soal menghasilkan 2.000 baris kode sekaligus, jangan-jangan prompt-nya seperti menyuruh memasukkan seluruh Skyrim ke SNES. Bayangkan habis makan siang lalu dicoba jalan, terus marah karena yang dibuat malah Fallout bergaya PS1 dengan hanya serangan jarak dekat.

• Setiap kali tulisan saya naik ke halaman depan HN, saya selalu takut membaca komentar karena khawatir akan terlihat betapa bodohnya saya, atau orang-orang akan melempar komentar agresif yang menjatuhkan harga diri saya. Tapi kadang, kalau saya berhasil membuat judul yang sangat bagus, tidak ada yang benar-benar membaca tulisan saya dan semua orang cuma bicara soal diri mereka sendiri, jadi saya lolos dari kritik seperti itu.

  • Menurut saya ini lucu sekaligus realistis. Saya juga sering melihat pola serupa di tulisan lain. Bagaimanapun, saya menikmati diskusi seperti ini.

  • Tulisannya bagus. Rasanya seperti semacam “cara menikmati pair programming dengan AI”. Bermanfaat, jadi terima kasih.

• Saat pertama kali memakai agent LLM, saya mengharapkan komunikasi dua arah, pair programming yang benar-benar kolaboratif. Namun yang saya temui justru partner yang ingin menyelesaikan semuanya sepenuhnya dengan caranya sendiri. Begitu saya mencoba sedikit memperbaiki, konteks kode yang ditulis AI malah rusak dan pengalaman jadi lebih tidak nyaman. Yang saya inginkan adalah kerja sama sungguhan: saya mengerjakan sedikit, AI sedikit, bergantian.

  • Apakah Anda sudah mencoba lagi belakangan ini? Pengalaman saya berbeda. Saya mengedit kode yang dihasilkan AI lalu menyuruhnya membaca ulang file itu. Biasanya ia merespons semacam “ada perubahan pada file ini”. Jika AI mengubah kode, saya menjalankan tes lalu memberi umpan balik dan ia memperbaikinya secara iteratif. Cara ini bekerja cukup baik di Zed dan Claude Sonnet.

  • Cara yang umumnya saya pakai adalah menerima dulu usulan AI, lalu saya refactor atau kalau perlu saya arahkan lagi lewat prompt. Pendekatan ini punya efek menaikkan acceptance rate secara artifisial, dan statistik seperti itulah yang kemudian bisa dipakai perusahaan AI sebagai dasar klaim bahwa “AI menulis kode yang sangat bagus”. Padahal kenyataannya sering juga ada momen ketika saya cuma berpikir, “ah sudahlah, saya perbaiki sendiri saja”.

  • Saya biasanya cukup menambahkan “mari kita diskusikan dulu. Jangan ubah kode” agar percakapannya berjalan seperti yang saya mau. Setelah bolak-balik berdiskusi sampai cukup, baru di akhir saya bilang “terapkan”.

  • Kalau Anda menginginkan bentuk kolaborasi tertentu, saran saya minta secara spesifik kepada LLM. Akan bagus juga kalau menyiapkan beberapa dokumen prompt yang bisa dipakai berulang di setiap percakapan.

  • Belakangan ini menjaga konteks sudah tidak terlalu sulit, jadi tidak ada masalah besar saat mengubah kode. Saya hanya memakainya dalam mode Ask, bukan mode perintah, dengan Opus di Claude Code dan o3 max di Cursor. Saya sengaja menghindari mode agent karena, seperti di tulisan asli, makin lama manfaat yang saya dapat makin kecil. Saya jarang memakai tab completion, dan 80~90% dari kode yang disarankan saya edit lalu ketik sendiri. Karena itu saya tetap bisa mengetik di kecepatan 170wpm. Kecepatan keluaran Opus dan o3 max cukup terbatas, jadi membacanya juga tidak terlalu berat; awalnya terasa terlalu cepat, tapi segera terbiasa. Penilaian pribadi saya, kalau seluruh pengalaman LLM Anda cuma GitHub Copilot, itu baru setara pengalaman kelas motel.

• Pair programming juga tidak cocok untuk semua situasi. Bahkan sering kali memang tidak cocok. Seperti yang saya singgung di tempat lain, saran autocomplete dari LLM memutus alur fokus saat coding, karena saya harus berhenti di tengah-tengah untuk membaca, meninjau, lalu menerima atau menolak saran itu, sehingga flow pemrograman benar-benar rusak. Saya sangat kesulitan mencoba menyisipkan autocomplete AI ke dalam workflow saya.

  • Saya juga berpikir begitu. Solusinya adalah memakai dua-duanya: IDE khusus tanpa AI dan Cursor/VS Code, lalu bergantian di antara keduanya. Fokus mendalam yang sesungguhnya tidak mungkin terjadi sambil bercakap dengan chatbot.

  • Baru-baru ini saya membeli laptop baru dan memasang ulang IDE, lalu selama beberapa jam coding saya merasa ada sesuatu yang ‘aneh’. Ternyata saya lupa login GitHub Copilot, jadi saya bekerja tanpa AI. Rasanya saya malah menulis kode jauh lebih proaktif tanpa harus menunggu autocomplete. Cursor khususnya terus mengganggu alur kerja, jadi fitur seperti ‘memprediksi posisi kursor berikutnya’ pun benar-benar tidak perlu. Ke depannya saya akan mematikan Copilot, dan hanya memakai alat bergaya agent seperti aider untuk boilerplate atau pekerjaan berulang.

  • Fitur autocomplete AI atau saran kode justru paling buruk saat dipakai di bahasa yang strongly typed. Sebagian besar memang 80% benar, tetapi autocomplete IDE hampir 100% akurat. Pendekatan agent AI lebih baik karena 1) tidak terus-menerus mengganggu alur pikir, dan 2) ia bisa langsung compile dan menjalankan tes, memperbaiki yang salah, lalu memberi kode yang benar.

  • Saya justru sangat suka autocomplete. Saya harus memakai Go, dan boilerplate-nya sangat banyak, sementara itu bukan masalah yang bisa diselesaikan hanya dengan menambah library, jadi sering kali mengetik langsung malah lebih cepat. Untuk menulis kode yang membosankan, tangan saya sering lebih cepat daripada AI, jadi autocomplete benar-benar membantu. Saran satu baris bisa saya baca seketika, dan saran yang panjang pun kalau mirip dengan yang hendak saya tulis bisa langsung saya lanjutkan. Lama-lama kita jadi punya firasat soal apa yang akan diprediksi AI. Memang bukan peningkatan produktivitas yang luar biasa, tetapi untuk hal-hal membosankan seperti pesan log atau for loop jelas lebih cepat. Menurut saya ini hanya membantu ketika kecepatan membaca saya jauh lebih tinggi daripada kecepatan mengetik saya.

  • Pair programming memang tidak selalu tepat, tetapi dalam sebagian besar situasi tetap berguna. Biasanya gagal cocok ketika salah satu atau kedua pihak tidak benar-benar terlibat dalam proses ini, salah satu pihak menolak dengan sikap “hal seperti ini tidak bisa”, atau ketika prinsip-prinsip pair programming diterapkan terlalu kaku.

• Posisi saya agak rumit. Setidaknya selama sebulan saya aktif memakai berbagai alat LLM di kantor sambil belajar memanfaatkannya seefektif mungkin. Dilihat dari jumlah baris kode, produktivitas memang jelas naik. Tetapi secara keseluruhan saya tidak bisa bilang saya jadi lebih produktif. Hampir setiap tugas yang selesai menimbulkan perilaku aneh yang sulit dijelaskan, atau kadang malah menyentuh bagian yang tidak terkait sehingga saya harus membatalkannya. Tes yang dibuat otomatis oleh AI awalnya tampak meyakinkan, tetapi bila dilihat dari metrik lain seperti coverage, kekurangannya terlihat jelas. Untuk mencapai hasil yang saya inginkan, rasanya saya justru harus mundur beberapa langkah berulang kali. Bukan terasa seperti ada keuntungan atau pembelajaran, melainkan seperti benar-benar mengalami kemunduran. Pernah suatu kali 50 ribu baris import yang tidak perlu diam-diam ditambahkan ke modul yang bahkan bukan target perubahan. Di kesempatan lain, padahal aturannya sudah saya tetapkan dengan jelas, ia malah merusak seluruh struktur berorientasi objek dan mengimplementasikan semuanya dengan tumpukan if/else. Masalahnya, hasilnya terlalu bervariasi tergantung situasi; bahkan untuk tugas yang sama, kadang sempurna, kadang menghancurkan semuanya. Saya sudah mencoba banyak cara untuk meminta pekerjaan dan memberi arahan, tetapi untuk tugas yang mirip pun perilakunya terlalu berbeda, jadi saya selalu tersiksa harus meninjau semua perubahan. Bahkan ketika kodenya hampir benar, kalau saya hanya minta memperbaiki satu bagian tertentu, keseluruhan pekerjaan malah jadi berantakan. Menurut pengalaman saya, ini efektif untuk menulis alat kecil, tetapi sulit mengharapkan hasil yang konsisten di codebase menengah hingga besar.

• Agent LLM terasa terlalu banyak bicara dan selalu menganggap caranya sendiri yang benar. Tidak ringkas, dan hal yang seharusnya selesai dalam satu kalimat dijelaskan panjang lebar. Untuk perubahan kecil pun ia menulis komentar yang bertele-tele. Rasanya seperti mau mengajari saya, terlalu berlebihan.

  • Sebagian perilaku yang tidak disukai orang (“output terlalu panjang, komentar berlebihan, dan sebagainya”) mungkin merupakan efek samping karena LLM dirancang untuk meningkatkan efisiensi di sisi lain. Output panjang cenderung terkait dengan kode yang tidak malas-malasan dan skor benchmark performa yang tinggi. Komentar yang berlimpah juga terkait dengan penguatan konteks lokal, peningkatan kualitas kode berikutnya, dan berkurangnya error.

  • Kemarin saya mencoba sonnet 4, dan untuk tugas mengubah satu nilai konfigurasi saja ia menghabiskan 15 menit untuk terus mengetes dan refactor. Akhirnya malah mengubah 40 file tanpa perlu. Ia juga terus mencoba menjalankan debugger yang bahkan tidak ada, dan berulang kali mencoba membuka halaman web yang butuh autentikasi. Benar-benar terasa jauh dari sempurna.

• Menurut pengalaman saya, masalahnya bukan terlalu cepat, melainkan justru terlalu lambat. Dan kecepatannya berada di titik tanggung yang membuatnya lebih buruk. Kalau lebih cepat, saya bisa mengikuti kodenya secara real time sambil bekerja. Kalau lebih lambat, saya bisa mengerjakan hal lain lalu kembali lagi nanti. Tetapi kenyataannya pekerjaannya selesai dalam 50 detik sampai beberapa menit, jadi saya tidak bisa fokus ke hal lain. Menurut saya, justru lebih baik iterasi yang lebih cepat dalam unit kerja yang lebih kecil. Pada akhirnya, otonomi setingkat review manusia—misalnya pekerjaan mandiri seperti meninjau pull request (PR)—akan lebih baik. Loop saat ini (memberi tugas, menunggu 1~3 menit, melihat hasil, memberi umpan balik, lalu mengulang) bagi saya adalah skenario terburuk.

  • Ini mengingatkan saya pada komik The Oatmeal tentang “internet lambat vs tidak ada internet sama sekali”.

  • Kalau fokus buyar, taruh akuarium 30L di meja kerja, saran yang jenaka karena enak untuk melamun.

• Sebagai developer, saya hampir tidak memakai AI, paling kadang chatbot untuk pertanyaan yang tidak terkait proyek. Saya penasaran apakah orang memakai AI juga untuk proyek klien, atau hanya untuk proyek pribadi. Kalau untuk klien, apakah Anda memasukkan fakta bahwa kodenya dikirim ke AI ke dalam kontrak? Sebagian besar klien biasanya punya NDA atau perjanjian larangan pengungkapan ke pihak luar, dan beberapa klien bahkan pernah punya klausul larangan memakai AI. Saya penasaran apakah ada yang pernah menemui klien yang secara eksplisit mengizinkan pengecualian untuk alat coding AI.

  • Saya hampir selalu memakainya hanya di internal perusahaan, dan itu pun karena ada pedoman penggunaan AI yang jelas dari perusahaan. Secara nyata saya merasa alat ini tidak terlalu menghemat waktu, jadi untuk pekerjaan pribadi saya tidak akan mau membayar untuk memakainya. Dalam proyek pribadi, kesenangan membuatnya sendiri lebih penting daripada hasil akhirnya, jadi membuat dengan tangan sendiri lebih menyenangkan daripada mengurus prompt.

  • Kadang ada juga pihak klien yang justru secara aktif meminta penggunaan AI. Mereka berharap kualitas lebih baik dan pengembangan lebih cepat, yang pada akhirnya berarti penghematan biaya, meskipun kenyataannya sering tidak sesuai harapan itu. Tapi itu cerita lain.

  • Saya hanya membagikan ke OpenAI/Anthropic kode yang cukup publik hingga aman ditempel begitu saja ke kotak pencarian web.

  • Saya tidak membagikannya. Termasuk proyek internal; berbagi kode ke luar hanya mungkin kalau dibayar. Saya juga menangani data pribadi, jadi risiko hukumnya terlalu besar kalau kode terekspos ke perusahaan AS.

• Akhirnya ada seseorang yang tepat menyoroti ini. AI terlalu percaya diri soal desain, lalu menjalankan implementasi detail sesuka hati tanpa konsultasi. Bahkan API mocking pun sering dibuat tidak menjaga struktur, sehingga pengerjaan ulang jadi wajib. Saya berharap perilaku LLM lebih kolaboratif, dan kalau detailnya kurang, ia langsung bertanya. Tidak mungkin memberi semua informasi dalam prompt pertama, dan prompt tambahan justru merusak konteks dan alur berpikir desain awal. Mungkin saya yang memakainya salah, tetapi saya ingin tahu cara yang lebih baik. Saya berharap LLM menjadi lebih baik dalam menerima umpan balik secara bertahap lalu menerapkannya. Saya juga penasaran apakah menambah atau memperbarui konteks itu sendiri memang masalah yang sulit, tetapi saya tetap ingin terus belajar.

  • Sekarang kebanyakan tech stack sudah mendukung sesi “desain/perencanaan”, jadi mungkin akan membantu kalau Anda mulai dari situ dulu. Workflow yang sering saya pakai, baik untuk model besar maupun kecil, dimulai dengan percakapan seperti “berdasarkan @file, @docs, dan @examples, saya ingin mengerjakan _ di @path dengan mengacu pada @module_requirements.md — mari diskusikan semua yang diperlukan sebelum implementasi nyata”. Setelah bolak-balik berdiskusi sampai semua sepakat, itu bisa disimpan dalam file .md atau langsung dilanjutkan dengan “sekarang kerjakan”. Kalau workflow itu didaftarkan di .rules, file .md, atau snippet IDE, Anda bisa memakainya berulang pada tugas baru. Perlu diingat juga bahwa LLM terbaru membutuhkan konteks yang jauh lebih besar, jadi untuk tiap codebase atau proyek Anda harus mencoba alur yang berbeda, dan hasilnya pun bisa berbeda.

  • Saya juga merasa makin banyak informasi justru membuat AI makin bingung. Mungkin ada cara untuk mengatasinya. AI memang sangat pandai mengekstrak potongan informasi yang sangat kecil, tetapi saya agak menyesal seluruh industri seolah hanya fokus pada model chatbot. Saya jadi membayangkan bagaimana jadinya kalau kita dulu tidak terus mengembangkan keyboard, mouse, GUI, atau layar sentuh.

• Gaya kolaboratif yang memakai AI sebagai asisten justru menurut saya adalah cara pemakaian AI yang benar, dan tren yang terlalu berfokus pada “AI menulis kode langsung” malah contoh bagaimana industri perangkat lunak bergerak ke arah yang salah. Saya tidak pernah menyerahkan penulisan kode kepada AI. Saya memakainya hanya untuk mengkritik kode yang saya tulis, atau untuk membantu menyusun strategi desain struktur kode skala besar. Saya memakainya seperti konsultan strategi, dan kalau konteks untuk LLM disusun dengan baik, kita bisa mendapat panduan yang sangat bagus. Subjek utamanya harus selalu saya sendiri: saya yang memahami dan mengeksekusi, dan AI tidak saya beri tanggung jawab lebih dari sekadar penasihat. Saya menganggap AI sebagai “idiot savant” dan harus diperlakukan dengan hati-hati.