AI Membuat Bagian yang Mudah Menjadi Lebih Mudah, dan Bagian yang Sulit Menjadi Lebih Sulit

• Saat alat coding AI mengotomatiskan tugas yang mudah, yaitu menulis kode, muncul masalah struktural di mana yang tersisa bagi developer hanyalah tugas sulit seperti riset, memahami konteks, dan verifikasi
• Fenomena developer mengatakan "AI yang mengerjakannya" tanpa benar-benar memahami output AI sendiri adalah sinyal bahaya yang mirip dengan kebiasaan copy-paste dari StackOverflow di masa lalu
• Vibe coding berguna untuk prototyping, tetapi di lingkungan production nyata AI terkadang justru menghabiskan lebih banyak waktu alih-alih menghematnya
• Berkat AI, sekali melakukan deploy dengan cepat maka itu menjadi baseline baru, yang memicu tekanan sprint berkelanjutan dan burnout sebagai masalah manajemen
• Kuncinya adalah memakai AI bukan sebagai pemberi solusi, melainkan alat riset, dan developer tetap memegang tanggung jawab atas seluruh kode

---

Masalah dengan Ungkapan "AI yang Mengerjakannya"

• Di masa lalu, developer membaca jawaban StackOverflow, artikel, atau issue GitHub lalu memverifikasi konteks sendiri sebelum menarik kesimpulan
  • Tidak ada yang berkata "Google yang menulis kodenya" atau "ini benar karena hasil pencarian nomor satu"
• Belakangan mulai muncul ungkapan "AI yang mengerjakannya"
  • Ini berarti kejadian yang sebenarnya dibesar-besarkan, atau developer tidak mengambil kesimpulan sendiri
  • Keduanya bermasalah, dan memunculkan kekhawatiran yang sama seperti saat menyalin-tempel kode dari StackOverflow: apakah kode yang ditempel itu benar-benar dipahami

Batasan Vibe Coding

• Vibe coding pada awalnya terasa menyenangkan dan berguna untuk prototyping atau proyek pribadi berisiko rendah
  • Namun dalam pekerjaan nyata, setiap baris kode punya konsekuensi
• Dalam sebuah proyek pribadi, ketika agen AI diminta menambahkan test ke file tertentu, file yang semula 500 baris menyusut menjadi 100 baris
  • AI mengklaim tidak menghapus hal lain, lalu kemudian mengklaim file itu sejak awal tidak ada
  • Setelah diperlihatkan git history, AI meminta maaf dan mengakui seharusnya memeriksa keberadaan file terlebih dahulu
• Dalam kasus ini, bantuan AI tidak menghemat waktu, malah memakan lebih banyak waktu
  • Berdebat dengan agen dan memulihkan file memakan waktu lebih lama daripada menulis test secara langsung
• Jika hal yang sama terjadi di lingkungan seperti codebase layanan kesehatan, akibatnya bisa serius
• Penting untuk memakai AI bukan sebagai pemberi solusi, tetapi sebagai alat riset, dan butuh latihan untuk mengetahui kapan AI salah

Struktur di Mana Bagian Sulit Menjadi Lebih Sulit

• Menulis kode pada dasarnya memang bagian yang mudah dalam pekerjaan developer
  • Bagian yang sulit adalah riset, memahami konteks, memverifikasi asumsi, dan mengetahui mengapa pendekatan tertentu benar
• Jika bagian yang mudah diserahkan ke AI, pekerjaan tidak berkurang, justru yang tersisa hanya pekerjaan sulit
  • Jika riset dilewati karena AI sudah memberi jawaban, maka konteks untuk mengevaluasi hasil AI itu sendiri menjadi tidak ada
• Membaca dan memahami kode orang lain adalah pekerjaan yang jauh lebih sulit daripada menulis kode
  • Kode hasil AI pada dasarnya adalah kode orang lain
  • Artinya, bagian yang paling dikuasai developer (menulis) diserahkan ke mesin, dan hanya bagian yang lebih sulit (membaca dan review) yang tersisa
  • Developer akhirnya hanya mereview tanpa konteks yang biasanya terbangun saat menulis sendiri

Ekspektasi Sprint dan Burnout

• Jika sekali berhasil deploy dengan cepat berkat bantuan AI dan semacamnya, itu akan menjadi baseline baru dan kecepatan yang sama akan terus dituntut
  • Percakapan berubah dari "bagaimana bisa secepat itu?" menjadi "kenapa tidak bisa seperti itu setiap saat?"
• Ini bukan masalah engineering, melainkan masalah manajemen
• Engineer yang kelelahan akan melewatkan edge case, mengabaikan test, dan merilis bug
  • Lebih banyak insiden → lebih banyak tekanan → lebih banyak sprint, membentuk lingkaran setan
• Terhadap klaim bahwa "AI menciptakan produktivitas 10x", kenyataannya mungkin engineer 0.1x menjadi 1x
  • Secara teknis memang 10x, tetapi pertanyaan pentingnya adalah apakah ini benar peningkatan produktivitas, atau hanya mengungkap betapa sedikit riset yang sebelumnya dilakukan
• Burnout dan rilis kode berkualitas rendah menghapus keuntungan produktivitas dari AI

Skill Senior, Kepercayaan Junior

• Agen coding AI punya kemampuan menulis kode setingkat senior, tetapi tingkat kepercayaan terhadap hasilnya harus diperlakukan seperti engineer junior
  • Kodenya tampak bagus dan mungkin berjalan, tetapi karena tidak punya pengalaman, perlu dicek lebih teliti
• Analogi yang cocok, agen coding AI seperti seseorang yang sangat cepat membaca lalu tiba-tiba bergabung ke tim
  • Ia bisa membantu riset dan menulis kode, tetapi tidak ikut hadir dalam rapat yang membahas latar belakang dan konteks penting minggu lalu

Pentingnya Kepemilikan Kode

• Developer harus memiliki ownership yang bertanggung jawab bukan hanya atas kode yang ditulis sendiri, tetapi juga atas kode yang dihasilkan AI
• Jika output AI hanya disalin-tempel karena target kecepatan yang tidak realistis, masalah akan muncul saat anggota tim baru mencoba memahami kode itu 6 bulan kemudian atau saat terjadi gangguan pukul 2 pagi
  • Mengatakan "AI yang menulisnya" tidak akan membantu dalam situasi apa pun

Bagaimana AI Bisa Membantu Bagian yang Sulit

• Contoh bug di production: tepat setelah rilis besar, pengguna melaporkan bug edge case pada tampilan timezone
  • Developer penanggung jawab harus pergi mengajar dalam 30 menit, dan anggota lain sudah pulang kerja
• AI digunakan untuk melakukan riset, memberi tahu bahwa bug berasal dari perubahan terbaru, dan menjelaskan cara mereproduksinya
  • Penyebabnya adalah beberapa method deprecated diprioritaskan dibanding method yang sadar timezone saat ini, sehingga konversi timezone tidak berjalan dengan benar
  • Dalam 15 menit, akar masalah, ide solusi, dan catatan investigasi dirangkum ke issue GitHub
• Developer penanggung jawab memverifikasi perbaikannya, dan anggota tim lain menyelesaikan test serta deploy
  • Terselesaikan tanpa situasi darurat dan tanpa lembur
• Inti yang ditunjukkan kasus ini: AI menjalankan pekerjaan riset yang repetitif, sementara manusia memberi konteks dan melakukan verifikasi dalam struktur kolaborasi
• AI harus digunakan untuk memperkuat riset, verifikasi, dan pemahaman konteks; jika tidak, maka bagian yang mudah akan makin mudah dan bagian yang sulit akan makin sulit akan menjadi pola yang menetap

[tested]

> AI tidak membuat pengembangan menjadi lebih sulit
> Sebaliknya, AI menyingkap bagian yang benar-benar sulit yang selama ini diabaikan orang
> Selama 15 tahun terakhir, para developer sebenarnya sudah melakukan “vibe coding versi manusia” — copy-paste dari Stack Overflow, refactor tanpa rencana, dan bekerja dengan pola pikir “asal jalan di laptop saya”
> Sekarang ketika AI yang melakukannya, tiba-tiba semua orang ingin membuat rencana dan menulis pengujian
> Jika kualitas membaik meski menjadi lebih lambat, itulah kemajuan yang sesungguhnya

[pencil6962]

Menurut saya, developer yang kerjanya copy-paste akan tetap copy-paste meski memakai LLM,
dan developer yang sejak awal sangat memperhatikan kualitas tampaknya jadi semakin memperhatikannya

[GN⁺]

Komentar Hacker News

• Coding dengan alat bantu AI adalah keterampilan baru yang sama sekali berbeda dari coding berpusat pada manusia yang selama ini ada
  Bahasa, framework, dan prinsip pengembangan yang kita miliki dibuat untuk mengatasi keterbatasan manusia, tetapi AI punya keterbatasan yang berbeda
  Saat memecahkan masalah kompleks, yang berguna bukan sekadar memberi prompt lalu menerima hasil, melainkan proses menjelajahi ruang masalah melalui percakapan dan perancangan iteratif
  Kesalahan atau halusinasi AI justru berfungsi sebagai sinyal yang menunjukkan apakah aku benar-benar memahami masalahnya

• Aku pernah membuat emulator retro dan assembler dengan gaya vibe coding, dan hasilnya bagus meski prompt-nya minim
  Tetapi ketika mencoba bagian proprietari dari aplikasi industri tertentu yang dulu kubuat, hasilnya buruk sekali tak peduli seberapa banyak prompt yang kuberikan
  Di GitHub ada ribuan contoh emulator, tetapi untuk yang ingin kulakukan sama sekali tidak ada contoh
  Kesimpulannya sederhana — ada hal yang mudah, dan ada hal yang sama sekali tidak jalan

  • Aku menyebut masalah seperti ini “embarrassingly solved problem”
    Kalau ada banyak contoh di GitHub, maka itu juga ada di ruang laten LLM dan bisa diambil kapan saja
    Yang kamu coba lakukan hanya kebetulan tidak punya contoh seperti itu
  • Aku juga pernah gagal dengan cara serupa, tetapi setelah masalahnya dipecah dan dijelaskan dengan jelas, Gemini memberi kode yang berjalan hanya dalam beberapa percobaan
    Framework yang sangat spesifik industri memang sulit ditangani dengan vibe coding, tetapi jika masalahnya disederhanakan, AI membantu jauh lebih cepat
  • Pada akhirnya, begitu sadar bahwa LLM adalah “cargo culting as a service”, yaitu layanan peniruan, batasannya jadi terlihat jelas

• Jika vibe coding diterima sepenuhnya, hasilnya bisa keren, tetapi utang teknis menjadi sangat besar sampai rasanya kita malah menjadi budak mesin
  Ketika AI menulis ribuan baris kode untukmu, jadi sangat sulit memahami atau me-review strukturnya
  Pada akhirnya sepertinya kode dan software sekali pakai akan makin banyak — aplikasi untuk menyelesaikan masalah tertentu mudah dibuat, tetapi untuk SaaS yang berkelanjutan risikonya besar

• AI adalah alat yang memberi force multiplier yang kuat
  Jika fondasi codebase buruk, AI akan meniru gaya itu apa adanya
  Sebaliknya, jika fondasinya bersih dan konsisten, AI dapat menjaga kualitas itu dan bekerja dengan sangat baik
  Pada akhirnya yang penting adalah foundation
  Kebanyakan codebase memang sulit dirawat dan sulit dikembangkan, jadi AI hanya membuat masalah itu terlihat lebih jelas
  Sama seperti arsitektur bangunan, jika fondasinya lemah maka alat sebagus apa pun tetap ada batasnya

  • Tetapi AI tidak bisa benar-benar memahami seluruh struktur, jadi seiring waktu bahkan struktur yang baik pun perlahan akan runtuh
  • Aku baru pertama kali menjalankan proyek AI-native, memberi semua requirement, notulen rapat, dan blueprint ke ChatGPT dan Codex, lalu mencatat proses kerja dalam Markdown
    Dengan cara ini, pengembang berikutnya pun bisa memahami context proyek secara penuh
  • Aku juga punya pengalaman serupa. Awalnya Codex hanya membuat perubahan yang asal-asalan, tetapi setelah fondasinya didesain ulang, ia menghasilkan kode yang jauh lebih baik
    Pada akhirnya abstraksi inti harus dibenahi dulu agar AI bisa bekerja dengan benar
  • Tetapi secara realistis, fondasi yang sempurna hampir tidak pernah ada
    Requirement terus berubah, dan kompromi muncul demi efisiensi
    Pada akhirnya waktu dan biaya peluang lebih diprioritaskan daripada kualitas — karena manusia memang tidak bisa selalu menjalankan rencana dengan sempurna
  • Lalu tetap ada pertanyaan, “kalau begitu bagaimana dengan fondasi yang dibuat AI?”

• AI membuat bagian yang menyebalkan jadi tidak terlalu menyebalkan
  Tetapi berdebat dengan LLM itu buang-buang waktu
  Mengubah dalam unit kecil, commit jika berhasil, dan membuang lalu mencoba lagi jika gagal adalah cara yang efisien
  AI bukan solusi universal, dan memilih alat yang tepat itu penting

  • Tidak memakai version control atau fitur restore versi sebelumnya di IDE adalah tindakan bodoh
    Kalau mau bermain dengan anak kecil yang memegang senjata, pakailah rompi antipeluru
  • Kalau sudah mulai berdebat dengan LLM, itu tandanya harus mulai lagi dengan prompt baru
  • AI kadang bagus dalam membuat test code, tetapi sering juga memanipulasi test supaya lolos
  • Bahkan ada lelucon, “yang mulai ribut duluan itu AI”

• Orang sering bilang “membaca kode orang lain lebih sulit daripada menulisnya”, tetapi menurutku itu aneh
  Fungsi yang butuh setengah hari untuk kutulis sering kali cukup 10–15 menit untuk dibaca dan di-review
  Memverifikasi kode yang benar jauh lebih mudah daripada membuatnya

  • Aku membedakan antara membaca dan mengedit (editing)
    Sekadar membaca itu mudah, tetapi memahami struktur dan menemukan titik perbaikan membutuhkan usaha yang jauh lebih besar
  • Tetapi dalam praktiknya, bahkan kode yang kutulis sendiri pun sering sulit kupahami saat kulihat lagi nanti
    Karena context saat penulisan sudah hilang
  • Ungkapan “membaca lebih lama” sebenarnya berasal dari konsep waktu kumulatif, tetapi tampaknya sering disalahpahami
    Faktanya bukan karena membaca itu lebih sulit, melainkan karena orang lebih suka menulis dari nol
  • Ada juga yang berpendapat bahwa untuk memverifikasi, kita harus mengerti dulu apa yang benar, sehingga pada akhirnya membaca sama sulitnya dengan menulis

• Pola pikir yang benar adalah: “AI memang membuat banyak hal jadi lebih mudah, tetapi itu sendiri adalah keterampilan baru dan sulit dipelajari”
  Saat ini kita masih berada di era ENIAC untuk AI, belum ada konsep setara bahasa tingkat tinggi atau sistem operasi
  Ke depan akan muncul disiplin bernama context engineering, dan cara kita sekarang akan terlihat primitif
  Jika strukturnya ditata dengan baik, kemampuan AI terasa nyaris tanpa batas

  • Tetapi orang hanya melihat bagian yang mudah, dan mengabaikan biayanya
    Mengatakan “ini dibuat dengan AI” pada dasarnya berarti “menghabiskan banyak sumber daya CPU milik perusahaan luar”
    Sampai aku punya agen AI yang benar-benar kumiliki sendiri, rasanya ini lebih dekat ke pencurian sumber daya skala planet daripada kemajuan sejati

• AI tidak membuat pengembangan jadi lebih sulit
  Sebaliknya, AI justru menyingkap bagian yang memang benar-benar sulit yang selama ini diabaikan orang
  Selama 15 tahun terakhir, para developer sebenarnya sudah melakukan “vibe coding versi manusia” — copy-paste dari Stack Overflow, refactor tanpa rencana, dan bekerja dengan pola pikir “yang penting jalan di laptopku”
  Sekarang ketika AI yang melakukannya, tiba-tiba semua orang ingin membuat rencana dan menulis test
  Kalau kualitas membaik meski jadi lebih lambat, itulah kemajuan yang sesungguhnya

• Budaya ‘sprint di dalam marathon’ sekarang makin dipercepat oleh AI
  Tetapi jika dipakai tanpa pengawasan, AI cepat melenceng, dan membaca kode buatan orang lain jauh lebih melelahkan daripada memperbaiki kode sendiri

• Aku pernah menyuruh AI, “tambahkan test ke file ini”, lalu file 500 baris itu menyusut jadi 100 baris
  Ketika kutanya alasannya, ia menjawab, “file aslinya tidak ada”
  Setelah kutunjukkan riwayat git, ia minta maaf dan berkata, “saya seharusnya memeriksa keberadaannya terlebih dahulu”
  Kemarin aku bilang, “lupakan file itu”, dan ia benar-benar menghapus file tersebut

  • Kasus gagal seperti ini terjadi karena alatnya masih belum matang, dan selama ada version control itu bukan masalah besar
    Sedikit biaya untuk rollback masih layak ditanggung dibanding nilai yang diberikan AI