Mengapa Alat Coding AI Generatif dan Agen Tidak Efektif bagi Saya

• Penulis tidak menggunakan alat coding AI karena alasan terbesar adalah alat tersebut tidak membuat dirinya bekerja lebih cepat
• Penulis menilai bahwa waktu yang dibutuhkan untuk meninjau dan memahami kode yang dihasilkan AI bisa lebih lama daripada menulisnya sendiri
• Karena kualitas kode dan tanggung jawab tetap berada pada pengembang itu sendiri, menggunakan kode AI tanpa peninjauan adalah hal yang berisiko
• Menanggapi anggapan bahwa AI sebaiknya dipandang seperti intern, penulis mengkritik bahwa AI tidak dapat belajar sehingga mirip intern yang mengalami amnesia
• Penulis menjelaskan perbedaan antara kontribusi open source dan kode AI, serta menilai bahwa interaksi dengan manusia memberi ide-ide baru sehingga tetap bernilai

---

Pendahuluan

• Banyak orang sering bertanya kepada saya apakah saya menggunakan alat coding AI generatif, dan bagaimana pendapat saya tentangnya
• Dalam tulisan ini, saya hanya merangkum pengalaman teknis pribadi di luar posisi pro maupun kontra
• Saya menjelaskan alasan dari sudut pandang teknis mengapa AI tidak membantu pekerjaan coding saya

AI tidak lebih cepat

• Meski menggunakan alat coding AI generatif, kecepatan kerja saya tidak menjadi lebih cepat
• Walaupun AI menuliskan kode, tanggung jawab atas kode tetap ada pada saya; saya hanya bisa memasukkannya ke proyek setelah meninjau seluruh kode dengan teliti dan benar-benar memahaminya
• Code review membutuhkan waktu dan konsentrasi yang sama lamanya dengan menulis kode, dan ada juga pepatah di industri bahwa “membaca kode lebih sulit daripada menulisnya”
• Memercayai kode yang ditulis AI seperti sebuah “black box” adalah pilihan yang sangat tidak bertanggung jawab. Jika terjadi cacat pada kode, tanggung jawab hukum dan finansial juga tetap berada pada programmer
• Tanpa penurunan kualitas dan peningkatan risiko, tidak mungkin ada peningkatan produktivitas atau keuntungan lewat AI

AI bukan alat leverage

• Sebagian orang berpendapat bahwa alat coding AI melipatgandakan efisiensi, tetapi menurut saya itu hanya kesan subjektif
• Beberapa pengguna menghemat waktu dengan memakai kode hasil AI tanpa review atau hanya meninjaunya sebagian, tetapi saya tidak bisa melewati proses itu, jadi ini tidak membantu saya
• Saya juga tidak setuju dengan anggapan bahwa menggunakan AI untuk mempelajari bahasa atau teknologi baru itu efisien. Proses belajar hal baru itu sendiri adalah kesenangan dalam pemrograman
• Saya benar-benar mempelajari berbagai bahasa seperti Rust, Go, dan TypeScript secara langsung, dan tidak mendelegasikan pengalaman itu kepada AI
• Karena pada akhirnya, rasa tanggung jawab atas semua kode tetap ada pada saya

Kode AI berbeda dari kode manusia

• Saya sering menghadapi pertanyaan, “Kontribusi open source juga merupakan kode yang tidak saya tulis sendiri, jadi mengapa diperlakukan berbeda dari kode AI?”
• Faktanya, saya juga menginvestasikan waktu untuk meninjau PR open source secara menyeluruh. Tetapi kolaborasi dengan pengguna menghasilkan ide-ide baru dan motivasi
• Ada juga yang mengatakan bahwa menjalankan beberapa agen AI untuk menerima PR penyelesaian bug issue adalah game changer, tetapi pada akhirnya bottleneck code review tetap manusia, sehingga justru menjadi lebih lambat
• Seiring alat AI makin tersebar, PR berkualitas rendah semakin sering dibuat. Ada kesan ganjil yang halus pada kode AI, dan saat mengajukan pertanyaan kepada pengirim PR, sering kali tidak ada jawaban
• Kontribusi kode yang bertanggung jawab dan komunikasi dalam komunitas open source adalah pembeda penting dari kode buatan manusia

Perbedaan AI dan intern

• Ada pula pendapat yang membandingkan AI dengan intern, tetapi keduanya berbeda secara mendasar
• Kode awal dari intern memang membutuhkan banyak review dan waktu, tetapi mereka tumbuh cepat melalui umpan balik
• Investasi pada pertumbuhan intern pada akhirnya membuat mereka menjadi rekan penting yang bisa dipercaya untuk menangani pekerjaan secara mandiri
• Alat AI melupakan pengetahuan setiap kali memulai tugas baru dan harus memulai lagi dari awal, sehingga tidak bisa tumbuh atau mengakumulasi keahlian
• Itu seperti intern yang tidak pernah berkembang, dan tidak bisa berkontribusi pada peningkatan produktivitas

Kesimpulan

• Melalui tulisan ini, saya ingin menyampaikan dengan jelas masalah teknis saat menerapkan alat coding AI generatif
• Dalam AI coding, tidak ada yang namanya 'makan siang gratis'
• Klaim bahwa AI membuat pekerjaan lebih cepat atau produktivitas meningkat berasal dari penurunan standar kualitas sambil menanggung risiko tambahan, atau dari kepentingan penjual AI
• Programmer harus selalu ingat bahwa mereka adalah pihak yang memikul tanggung jawab akhir

[ceruns]

Saya sudah sepenuhnya menetap menggunakan mode agent dari copilot (claud) + codex (3 model simultan mcp: o3/4o/codex-mini), tetapi menurut saya efektivitasnya bisa sangat berbeda tergantung orang yang menggunakannya dan karakter proyeknya.

Saya biasanya menjalankan pekerjaan secara bersamaan di 5-6 workspace lalu memeriksanya sesuai urutan selesai; karena model bisa menangani seluruh pekerjaan hingga menelusuri bagian dalam kode open source dan memverifikasinya, menurut saya ini cukup bagus. Kalau saya memulai pekerjaan saat jam makan siang, biasanya satu atau dua sudah selesai. Kadang juga berjalan semalaman, tetapi copilot rate limit itu seperti black box jadi...

Tugas seperti kernel berperforma tinggi, penyederhanaan seluruh call stack, atau memastikan readability, yang bagi manusia memakan waktu karena sering perlu berpindah konteks, tetap bisa diselesaikan jika prompt dan tujuannya diberikan dengan baik (karena ia bisa memuat lebih banyak kode di memori dibanding manusia), jadi meninjau patch pada kode seperti ini relatif mudah... Dan bagi yang pernah mengalami gangguan akibat kesalahan penggunaan API atau bug pada proyek open source itu sendiri, memaksa verifikasi yang tegas dengan Agent juga cukup baik untuk kesehatan mental...

Namun, pada akhirnya pengembang yang memakainya tetap harus bisa memahami patch tersebut. Dan tentu harus tahu cara melempar prompt. Karena hanya jika kita bisa membentuk masalah dengan cepat berdasarkan pengalaman lalu melemparkannya, proses itu bisa benar-benar dimulai. Seperti pengembangan kernel berperforma tinggi yang mustahil tanpa rumus. Untuk menangkap apakah masalahnya ada di level chip/OS, level aplikasi, atau masalah remote resource, sepertinya itu masih peran seorang senior.

[ndrgrd]

Dari sudut pandang seseorang yang sudah cukup mencoba Copilot, ChatGPT dan sejenisnya, serta Cursor, alat pengembangan semacam ini memang cocok untuk peran setingkat templat atau snippet, tetapi belum sampai pada level agen atau rekan kerja.

[allinux]

Saya sedang menggunakan cursor.
Saya lebih memilih mode chat ask daripada agent, karena saya tetap ingin meninjaunya lalu menerapkannya ke kode saya, dan secara umum saya setuju dengan kekurangan seperti yang disebutkan di artikel.
Meski begitu, saya akan tetap menggunakan AI generatif, karena cukup sering AI menghasilkan ide atau kode yang tidak terpikirkan oleh saya, sehingga saya menilai itu cukup bernilai setidaknya sebagai bahan referensi.

[cronex]

Berdasarkan pengalaman pribadi, kesan saya tentang penggunaan alat coding generatif kurang lebih mirip.

• Dari sudut pandang developer, untuk pekerjaan antarmuka sederhana yang terasa merepotkan tetapi ternyata memakan waktu lebih lama dari perkiraan, alat ini bisa memberikan hasil yang tertata lebih baik dari yang dibayangkan.
• Terutama, jika kita mengimplementasikan satu atau dua antarmuka yang bisa dijadikan contoh dengan baik, lengkap dengan penanganan pengecualian dan komentar, alat ini bisa "mempelajari" itu dan saat menulis kode juga menangani hal serupa dengan memasukkan pola yang mirip.
• Selain itu, saat menggunakan platform atau SDK baru yang sebelumnya belum pernah dipakai, alat ini bisa menjadi panduan yang membantu menyelesaikan masalah dengan lebih sedikit trial and error.
• Tentu saja, pada akhirnya detail tetap harus dicek di semua kasus, tetapi dibandingkan saat kita bekerja dengan copy-paste manual lalu melakukan kesalahan, kualitas kodenya jauh lebih baik, dan jauh lebih mudah menemukan bagian yang bermasalah dibandingkan meninjau hasil kerja yang kita tulis sendiri. (Biasanya memang lebih mudah mencari masalah pada kode yang ditulis orang lain daripada pada kode yang kita tulis sendiri.)
• Kelebihan di atas berlaku ketika alat ini digunakan oleh developer menengah/mahir yang mampu meninjau langsung kode hasil generasi dan menilai masalah maupun validitasnya. Bagi developer pemula atau level rendah yang tidak mampu melakukan itu, justru kualitas kode dan hasil akhirnya bisa jatuh bebas, arah pengembangannya pun bisa tidak jelas, sampai pada tingkat tidak mampu menyelesaikannya.
• Secara khusus, untuk metodologi, algoritma, atau struktur data baru yang belum dikenal luas, AI coding tidak bisa mengimplementasikannya dengan baik, dan hasil saat dicoba pun berada di level yang menyedihkan.
• Artinya, ini hanyalah alat yang baik dipakai developer yang sudah matang untuk meningkatkan kecepatan kerja atau memperbaiki kualitas hasil, bukan sesuatu yang bisa sepenuhnya menggantikan satu orang developer atau dipakai untuk membuat developer pemula yang belum berpengalaman bertumbuh.
• Sebaliknya, jika dipakai developer pemula tanpa panduan yang tepat, kemungkinan besar justru hanya akan menimbulkan efek negatif.

[GN⁺]

Komentar Hacker News

• Ada yang setiap kali mempelajari bahasa atau teknologi baru selalu punya pertanyaan; dulu mereka mencari di Google atau bertanya di Stack Overflow lalu menunggu jawaban. Sekarang mereka bisa langsung bertanya ke ChatGPT atau Gemini dan mendapat jawaban jauh lebih cepat, sehingga produktivitas meningkat besar. Saya ingin menekankan bahwa sekadar mendapatkan jawaban cepat atas pertanyaan saja sudah mempercepat proses belajar.

  • Alasan ChatGPT dan Gemini bisa memberi jawaban yang benar adalah karena keduanya dilatih dari pengetahuan yang sudah ada di web, termasuk Stack Overflow. Jika semua orang hanya memakai AI untuk bertanya, pada akhirnya sumber pengetahuan publik yang tepercaya bisa habis. Ini mirip kebangkitan era ensiklopedia, ketika informasi dikumpulkan dan dijual dengan biaya tinggi. Selain itu, yang dikritik penulis adalah alat coding AI yang menulis kode secara langsung, jadi itu harus dibedakan dari alat yang hanya menjawab pertanyaan.

  • Dulu saya pernah memakai API yang tidak familier lalu program saya crash. Saya masukkan stack trace ke Gemini, dan langsung dapat petunjuk penyebabnya lalu menyelesaikan masalah cukup dengan mengubah dua baris. Dari pengalaman seperti ini saja nilai AI sudah sangat terasa. Kelebihan besarnya adalah kita tidak perlu lama tersesat karena kesalahan bodoh di bidang yang belum kita kuasai.

  • Pencarian makin sering memprioritaskan spam blog, padahal lebih mendidik jika belajar dari dasar lewat dokumentasi resmi atau panduan pengguna yang bagus. Saat membaca dokumentasi API yang baik, kita bisa sekalian memahami desain keseluruhan dan fitur tambahannya. Contoh blog atau tutorial mungkin menyelesaikan masalah saat itu juga, tetapi tidak banyak membantu peningkatan kemampuan yang sesungguhnya. Itu hanya seperti mengerjakan PR untuk kita, jadi saya rasa ChatGPT tidak benar-benar mendorong pembelajaran mandiri.

  • Untuk masalah sulit, proses memverifikasi hasil AI itu wajib. Salah satu alasan saya mematikan fitur autocomplete AI adalah karena efisiensinya ternyata tidak besar, malah sering menimbulkan revisi yang tidak perlu. Menariknya, bahkan model lokal yang sepenuhnya offline pun bisa memberi referensi yang cukup berguna. Hasil Gemini bawaan Google juga kualitasnya kurang bagus. Kekhawatiran utama saya adalah jika orang hanya mengandalkan AI untuk memperoleh informasi, gudang pengetahuan nyata seperti Stack Overflow bisa menghilang.

  • Untuk alat boilerplate kecil, AI sempurna. Hal-hal sederhana seperti ekstensi browser atau skrip Tampermonkey hampir bisa langsung dikerjakan tanpa membaca dokumentasi. Untuk autocomplete kode yang tidak rumit atau perbaikan kecil, AI juga cukup berguna. Proyek kecil yang biasanya bahkan tidak saya mulai bisa dituntaskan dengan cepat.

• Salah satu manfaat potensial dari menulis kode sendiri adalah meninggalkan model mental yang kuat tentang masalah tersebut di otak kita. Nantinya, saat memecahkan masalah atau mengintegrasikan fitur baru, efek belajar "bawah sadar" ini sangat besar. Kemampuan sejati meningkat ketika ingatan karena pernah mengerjakannya sendiri menumpuk. Di organisasi yang pernah saya lihat, bahkan setelah adopsi LLM, mereka tetap tidak mengalami pelipatan produktivitas yang nyata. Saya curiga ini hanya kekeliruan karena orang merasa memakai jalan mudah sambil mengurangi kerja otak.

  • Saya rasa ini merangkum dengan sangat baik fenomena ketika orang terbiasa menyelesaikan masalah dengan energi mental lebih sedikit, lalu salah mengira perasaan itu sebagai produktivitas. Hasil eksperimen Google Research pada 2024 tentang efek produktivitas LLM menunjukkan bahwa dibanding kelompok yang belajar dari buku, kelompok pengguna LLM justru butuh waktu lebih lama, dan hanya pemula yang skornya sedikit naik, bukan mereka yang sudah mahir. Namun banyak peserta tetap merasa diri mereka lebih cepat dan lebih akurat, dan peneliti menafsirkan alasannya sebagai "berkurangnya beban kognitif". Tautan makalah terkait https://storage.googleapis.com/gweb-research2023-media/pubtools/7713.pdf

  • Jika kita memakai lebih sedikit energi otak dan bisa bekerja lebih lama, bukankah secara nyata kita bisa menangani volume kerja yang lebih besar? Bahkan sekarang pun pekerjaan yang sangat sulit biasanya mentok di 3~4 jam. Sudut pandangnya: kalau kita bisa lari maraton dengan kecepatan jalan kaki, total output akhirnya bisa meningkat.

• Saya setuju bahwa coding tradisional dan coding dengan AI adalah dua skill yang terpisah. Saya juga sangat skeptis terhadap klaim bahwa AI akan menggantikan coding. Namun, saya melihat bahwa "coding AI" itu sendiri juga punya kurva belajar yang cukup besar, seperti manajemen prompt atau menjaga konteks, dan menurut saya banyak orang meremehkan nilainya di titik ini. Seperti menggambar manual dan memotret, tujuan yang dikejar bisa memang berbeda. Pendekatan yang saya sukai adalah "AI menangani pekerjaan berat, sementara saya bertanggung jawab atas desain keseluruhan dan orkestrasinya".

  • Coding berbasis LLM mirip pengalaman melakukan outsourcing yang berulang pada siklus definisi tugas-umpan balik-iterasi, lebih dari sekadar autocomplete biasa. Bedanya ada pada kecepatan pemrosesan (LLM unggul) dan keandalan (manusia unggul), tetapi dalam jangka panjang batas itu pun tampaknya akan makin kabur. Yang penting, saya pada dasarnya tipe orang yang ingin menangani detail pekerjaan itu sendiri. Saya memilih profesi ini karena suka belajar dan mendalami infrastruktur serta pemrograman. Karena itu saya menghindari peran manajerial dan tetap bersikeras ingin membuat langsung meski penghasilannya lebih kecil. Mungkin saya akan tertarik lagi ketika AGI sudah mencapai tingkat rekan kerja. Bahkan istilah AI sendiri mungkin nantinya tidak akan terasa begitu istimewa.

  • Walaupun kurva belajar coding AI ternyata cukup besar, tetap tidak sama dengan piano yang harus ditekunin bertahun-tahun. Para AI coder paling terampil yang ada sekarang pun baru punya sekitar 3 tahun pengalaman, dan modelnya juga terus berubah, jadi banyak pengalaman lama yang tidak cocok dengan generasi model saat ini. Ketiadaan struktur belajar dari seorang master juga merupakan batasan.

  • Apakah skill coding AI benar-benar bernilai dalam jangka panjang? Saya ragu seberapa jauh skillset alat AI saat ini bisa ditransfer ke generasi berikutnya. Walaupun sekarang efisiensinya naik, kita perlu mempertimbangkan kemungkinan bahwa saat model dan alat berubah, skill itu bisa menjadi tak berguna.

  • Saya rasa mahir coding AI cukup butuh beberapa menit atau paling satu jam. Secara analogi, ini bukan bidang yang perlu digali per buku seperti GDB atau UNIX. Seperti halnya gambar dan foto tidak dicampuradukkan karena prinsip dasar dan tujuannya sangat berbeda, coding AI juga aktivitas yang sepenuhnya berbeda dari coding biasa.

  • Saya tidak setuju dengan kepercayaan diri yang menganggap preferensi untuk coding langsung itu semata karena kemampuan coding AI-nya kurang. Dari ROI penggunaan pembayaran kecil dan free trial yang sudah saya coba sampai sekarang saja, saya rasa itu sudah cukup untuk menilai.

• Dalam praktiknya, alih-alih melakukan code review AI atau memeriksa hasilnya, muncul budaya mengunggah kode hasil AI langsung ke PR dan melempar review ke orang lain. Dalam situasi seperti ini, GenAI bukan terasa sangat berguna, melainkan lebih sering menjadi efek samping untuk menunda pekerjaan.

  • Saya juga pernah mengalami hal seperti ini. Jika manajernya kurang kompeten, mereka tidak bisa membedakan siapa yang benar-benar menciptakan nilai. Saya sendiri mendapatkan banyak nilai dari coding agent, tetapi saya rasa struktur organisasi yang tidak kompeten dan memberi imbalan pada output asal-asalan adalah masalah yang serius.

  • Jika PR yang diajukan terus-menerus berupa hasil AI mentah, menurut saya team lead memang harus mengumpulkan umpan balik dan mengangkat masalah itu.

• Sebagai orang yang sering memakai Claude Code, saya 100% setuju dengan klaim bahwa saat meninjau kode yang ditulis orang lain, perbedaan waktunya hampir tidak ada dibanding menulis sendiri. LLM cukup berguna, tetapi makin banyak kontrol yang kita serahkan, justru waktu sampai rilis nyata jadi lebih lama. Ini membantu meredakan gejala RSI, tetapi efek penghematan waktunya sering kali dilebih-lebihkan.

  • Ketika ditanya apakah kode memang harus direview, biasanya saya terutama hanya melakukan spot review pada hasil AI, lalu menyuruh AI menulis dokumen spesifikasi, setelah itu saya lakukan peninjauan akhir dan pengujian dengan teliti. Faktanya, sebagian besar kode pustaka open source juga sejak awal tidak saya review sepenuhnya.

  • Di sini ada asumsi bahwa "kode yang saya tulis sendiri tidak perlu ditinjau dari sudut pandang terpisah". Padahal, diri saya di masa depan juga merupakan calon pembaca kode itu. Coding AI memaksa pola pikir seperti ini, yaitu menetapkan acceptance criteria yang jelas lalu memverifikasinya lewat pengujian dan aturan yang konsisten. Hasilnya, ini mendorong budaya pengembangan yang lebih kokoh dan terdokumentasi.

  • Dengan Claude Code, untuk debugging bug, jika kita menulis tes terlebih dulu, AI bisa memperbaikinya dalam hitungan menit dan itu sudah jadi hal biasa. Setelah fitur pencarian baru ditambahkan, bahkan pekerjaan rumit pun bisa ditangani dalam 5 menit; di bagian ini penghematan waktunya terasa sangat jelas.

  • Sebagai cara mengatasi gejala RSI, saya juga merekomendasikan selalu menjaga lengan tetap hangat.

  • Muncul pertanyaan: "Saya tidak ingin memproses semuanya lewat antarmuka percakapan; adakah contoh penerapan UI dengan pendekatan hybrid?"

• Alat coding Generative AI hanya mempercepat bagian pekerjaan yang mudah, dan justru membuat bagian yang sulit menjadi lebih sulit. Waktu yang benar-benar habis untuk aktivitas coding itu sendiri sebenarnya tidak terlalu besar, jadi meskipun bagian itu dipercepat 100 kali, produktivitas total tidak banyak berubah. Karena itu saya tidak merasa perlu menghabiskan waktu di sana.

  • Jika seorang engineer memang sudah menembus dan memahami betul stack serta domain masalah tertentu, ia memang tidak butuh alat apa pun, juga tidak perlu belajar lagi. Tetapi logika ini secara realistis tidak terlalu bermakna. Pada akhirnya pemilihan alat adalah optimasi personal.

  • Saya menyuruh AI menulis algoritma, menjelaskan penyebab kode, melakukan pemanggilan API, atau mengimplementasikan fungsi tertentu. Mungkin bukan keseluruhan kode lengkap, tetapi saya makin sering memakainya bersama debugger.

  • Apakah Anda tukang ledeng? pertanyaan bercanda yang dilontarkan.

• Bagian ketika penulis mengatakan "me-review kode yang ditulis orang lain bisa memakan waktu sama banyaknya atau bahkan lebih banyak dibanding menulis kode sendiri" sangat saya rasakan juga, sebagai orang yang pernah melakukan code review teliti seperti audit keamanan. Namun jika AI benar-benar unggul dalam pekerjaan rutin yang sangat sederhana, mungkin pemeriksaan menyeluruh ala verifier eBPF saja sudah cukup tanpa perlu melihat kode secara detail. Kalau ada isu yang terlalu rumit, PR-nya tinggal ditolak. Untuk kode yang sederhana dan berulang, manusia juga tidak perlu memeriksanya terlalu teliti.

  • Tetapi saya ragu apakah ini benar-benar cara yang efisien. Jika harus membuka puluhan PR lalu hanya meloloskan satu, saya justru lebih percaya pada kode dari rekan kerja. Struktur yang hanya membuang waktu, uang, dan sumber daya lingkungan seperti itu menurut saya tidak diinginkan.

  • Kalau itu memang benar-benar "fungsi Go yang repetitif", saya malah bertanya apakah kode itu memang layak ditulis. Untuk kode yang tidak efisien, sulit dipakai ulang, dan sebenarnya bisa selesai dengan satu dua baris pustaka umum, saya tidak melihat alasan membuatnya dengan AI.

  • Bagi orang yang membaca kode lebih cepat daripada menulisnya, GenAI berguna; sebaliknya, bagi yang menulis lebih cepat, tidak banyak alasan untuk memakainya.

  • Muncul pertanyaan mengapa kode yang ditulis AI harus diperiksa dengan cara berbeda dari kode yang ditulis manusia.

  • Untuk pekerjaan repetitif dan sederhana, template binding IDE dan fitur autocomplete variabel saja sudah cukup menutup kebutuhan, dan pendekatan ini gratis.

• Dalam pembahasan yang membandingkan intern dengan alat bantu coding AI, intern belajar kode nyata, bisnis nyata, dan histori sistem, sedangkan AI harus terus-menerus diberi penjelasan konteks. Keterbatasan ini masih ada.

  • Ada pandangan bahwa jika konteks penting disimpan dalam file mdc, penanggung jawab berikutnya juga bisa merujuk informasi itu, sehingga dokumentasi dan keberlanjutan pengetahuan justru menjadi lebih baik.

  • Pada beberapa LLM, ini jadi penyebab system prompt membengkak sampai 14k.

  • Intern sering kali benar-benar CARE.

  • Konteks bisnis yang penting juga bisa langsung dimasukkan ke dalam system prompt.

• Model AI saat ini pada dasarnya hanya mempelajari pola dari data yang sudah ada. Mereka menggabungkan template kasus sukses, bukan struktur yang mendorong solusi baru dari akar persoalan. Ketika melihat masalah, AI cenderung mencari jawaban dari pengalaman yang paling mirip, bukan mendekatinya secara prinsipil dari awal. Pakar manusia mahir dalam first-principles, yaitu pendekatan logis dari prinsip dasar yang sulit bagi AI. AI mengutamakan kemiripan sehingga menghasilkan solusi yang terpola, dan batasannya makin menonjol terutama di area yang butuh inovasi atau pada masalah yang tidak cocok dengan kebiasaan umum. Dalam menghadapi context poisoning pun manusia jauh lebih efisien.

  • Sebenarnya manusia juga berkembang dengan memperluas pola yang dipelajari dari data yang sudah ada; "metodologi baru" pun lahir dari pengalaman sukses yang terkumpul. Dalam hal ini, saya rasa AI juga tidak jauh berbeda dari cara manusia belajar.

• Saya pribadi tidak terlalu berharap pada AI di ranah kode hasil generasi, tetapi untuk pekerjaan boilerplate yang repetitif dan membosankan, AI bisa N kali lebih cepat, dan secara subjektif angkanya terasa sangat besar. Dari pengalaman nyata, saya pernah melempar contoh struktur modal berbasis React Context ke ChatGPT, lalu ia langsung menghasilkan rangkaian hooks, provider, dan seterusnya. Itu langsung menghemat sekitar 30 menit, dan untuk pekerjaan repetitif seperti ini, biaya 20 dolar per bulan sama sekali tidak terasa sayang.

  • Dalam kasus seperti ini, sering kali kita juga bisa mengambil dari contoh di dokumentasi pustaka, dan dalam 5 menit pun implementasi dasar paling penting bisa selesai kalau dikerjakan sendiri. Namun kode hasil generasi biasanya menawarkan solusi lengkap yang disesuaikan dengan situasi saat ini, sehingga setelah itu justru kurang nyaman untuk perbaikan struktur bertahap atau refactoring.

  • Saya juga terutama memakai AI untuk boilerplate atau skrip ad-hoc. Untuk masalah nyata yang kompleks, saya rasa masih sulit menyerahkannya sepenuhnya ke AI. Terutama untuk masalah yang menyelam jauh ke dalam sistem, manusia tetap harus turun tangan sendiri, dan insight yang didapat selama proses itu penting. Semakin besar proyek dan semakin banyak elemen yang saling terintegrasi, saya merasa batasan AI makin besar.