Coding dengan AI sudah tidak lagi jadi perdebatan di sebagian besar tim engineering yang saya ajak bicara, itu sudah jadi cara kerja sehari-hari. Pertanyaan yang menarik bukan lagi "apakah perlu pakai AI". Pertanyaan yang benar-benar penting adalah apa yang berubah secara struktural pada sebuah tim begitu menulis kode menjadi murah dan cepat, sementara mereview kode tidak ikut jadi murah dan cepat.

Saya menjalankan delivery untuk proyek enterprise di mana kodenya harus benar-benar tahan di production untuk perusahaan finance, bukan sekadar lolos demo. Pakai tools AI untuk coding setiap hari sudah mengubah cara saya staffing proyek, cara saya melatih junior, dan ke mana saya mengarahkan perhatian saya sendiri. Semuanya tidak sesuai dengan janji hype, dan sebagian besar justru lebih berguna dari yang dijanjikan hype tersebut.

Bottleneck-nya Berpindah, Bukan Menghilang

Dulu, menulis kode adalah bagian yang mahal. Seorang engineer senior perlu menghabiskan jam kerja sungguhan untuk membuat modul CRUD, lapisan validasi, atau report generator. AI menekan biaya itu mendekati nol untuk task yang spesifikasinya jelas. Yang tidak bisa dilakukan AI adalah memahami domain bisnis Anda, edge case Anda, atau apa arti "benar" untuk logika pencairan pinjaman di perusahaan multifinance.

Jadi bottleneck-nya tidak hilang, ia berpindah ke hulu yaitu spesifikasi, dan ke hilir yaitu review. Kalau Anda tidak bisa mendeskripsikan dengan presisi apa yang seharusnya dilakukan sistem, AI akan dengan percaya diri menghasilkan sesuatu yang bisa di-compile tapi salah. Dan kalau tidak ada yang mereview output itu dengan teliti, kode yang salah akan tayang lebih cepat dari sebelumnya.

Apa yang Benar-Benar Berubah pada Sebuah Tim

Tim yang lebih kecil bisa menghasilkan lebih banyak, tapi hanya dengan jangkar senior. Tim beranggotakan tiga engineer berpengalaman yang menggunakan AI dengan baik kini bisa menutupi pekerjaan yang dulu butuh lima atau enam orang. Tapi ini hanya berlaku kalau setidaknya satu atau dua orang di tim itu punya penilaian domain dan arsitektur yang cukup untuk menangkap saran yang buruk sebelum di-merge. Tim yang isinya semua junior plus AI akan melaju cepat menuju tembok.

Disiplin code review menjadi gerbang kualitas yang sesungguhnya. Di dunia lama, menulis kode secara lambat berfungsi sebagai filter alami, ide buruk memakan cukup banyak waktu sehingga orang berpikir dua kali. Friksi itu sudah hilang. Review sekarang menjadi titik penentu kualitas, yang artinya review harus jadi lebih ketat, bukan lebih longgar. Saya sampai harus secara eksplisit bilang ke reviewer: anggap saja logikanya kelihatan masuk akal tapi sebenarnya salah secara halus, baca seolah-olah Anda tidak percaya padanya.

Junior butuh jalur pelatihan baru. Jalur tradisional, menulis banyak boilerplate, membangun muscle memory, lalu naik ke masalah yang lebih sulit, jadi terganggu karena sekarang AI yang menulis boilerplate itu. Ini tidak otomatis buruk, tapi artinya junior berisiko melewatkan fase di mana mereka biasanya membangun intuisi tentang kenapa kode disusun dengan cara tertentu. Kami harus sengaja mengatur ini: junior di tim saya sekarang menghabiskan lebih banyak waktu membaca dan menjelaskan diff hasil AI baris demi baris ketimbang menulis dari nol, khusus untuk membangun kembali intuisi itu lewat jalur yang berbeda.

Menulis spesifikasi kini menjadi skill engineering kelas satu. Engineer yang mendapat leverage paling besar dari tools AI coding bukanlah yang paling cepat mengetik, melainkan yang bisa menulis spesifikasi yang tidak ambigu dan sadar edge case sebelum menyentuh keyboard. Ini lebih dekat ke skill manajemen dan komunikasi ketimbang skill mengetik. Saya sudah membahas ini lebih dalam di prompting adalah skill manajemen, bukan skill teknis, dan polanya berlaku juga untuk coding secara spesifik: presisi masuk, presisi keluar.

Di Mana Risiko yang Sesungguhnya Berada

Risiko yang kelihatan dan dikhawatirkan banyak orang, AI menulis kode yang tidak aman atau rusak, itu nyata tapi bisa dikelola dengan proses review yang baik. Risiko yang kurang terlihat adalah architectural drift. Tools AI sangat andal menyelesaikan masalah lokal yang ada di depannya, tapi biasa-biasa saja dalam menghormati desain sistem yang lebih luas. Kalau dibiarkan tanpa kontrol di puluhan PR kecil, Anda akan berakhir dengan codebase yang secara teknis berjalan di mana-mana tapi tidak koheren di mana pun: lima pola berbeda untuk jenis validasi yang sama, logika terduplikasi yang seharusnya dibagi bersama, penanganan error yang tidak konsisten.

Inilah kenapa penilaian teknis senior justru makin penting di era coding berbantuan AI, bukan makin tidak penting. Harus ada orang yang memegang bentuk keseluruhan sistem di kepalanya dan berani bilang tidak pada perubahan yang secara lokal masuk akal tapi secara global salah. Itu bukan tugas yang bisa didelegasikan ke tool yang justru menghasilkan perubahan tersebut.

Checklist Praktis untuk Tim yang Mengadopsi Ini

  • Wajibkan spesifikasi tertulis atau deskripsi ticket yang cukup detail sehingga dua engineer akan membangun hal yang kurang lebih sama darinya
  • Perlakukan PR hasil AI sama seperti PR hasil junior: anggap plausible-tapi-salah sampai terbukti sebaliknya
  • Tugaskan setidaknya satu reviewer senior per PR yang bertanggung jawab atas konsistensi arsitektur, bukan sekadar kebenaran
  • Rotasi junior lewat latihan "jelaskan diff ini", bukan hanya "tulis fitur ini"
  • Lacak waktu review sebagai metrik; kalau waktu itu turun sementara volume merge naik, itu red flag, bukan kemenangan

Kesimpulan

Coding dengan AI mengubah kurva biaya menulis software, bukan kurva biaya memahaminya. Tim yang memperlakukan ini sebagai "sekarang kita bisa merekrut lebih sedikit engineer dan bergerak lebih cepat" tanpa berinvestasi pada disiplin spesifikasi dan review akan mengirim lebih cepat lalu menghabiskan waktu yang dihemat itu untuk memadamkan kebakaran. Tim yang memperlakukan ini sebagai "penilaian senior kami sekarang adalah sumber daya langka, lindungi itu" adalah tim yang benar-benar melipatgandakan keuntungannya. Kalau Anda sedang menata ulang cara tim engineering Anda bekerja di sekitar tools AI dan butuh sudut pandang kedua soal di mana risiko sesungguhnya berada, itulah percakapan yang saya lakukan di /partner.