Mengapa AI yang Ditulis Keluar dari Kotak Mengganggu Tim — dan Apa yang Dapat Dilakukan Tentang Hal Ini

Dengan sebagian besar teknologi, semakin lama Anda menggunakannya, semakin tenang Anda mengandalkannya. Dengan alat AI, sebaliknya telah terbukti: dalam survei tahunan lebih dari 49.000 pengembang, Stack Overflow mencatat penggunaan meningkat menjadi 84% bahkan ketika kepercayaan terhadap akurasi alat tersebut menurun dari 40% menjadi 29% dalam waktu satu tahun.

Efek itu akrab bagi saya. Pengalaman pertama kami dengan alat AI dalam pengembangan memiliki sedikit kesamaan dengan efek wow dari pekerjaan yang lebih cepat dan kurang membosankan yang teknologi tulis terus tentang. Pengembang kami kecewa: AI menghasilkan kode yang biasa-biasa saja yang membutuhkan waktu lama untuk ditinjau dan, pada akhirnya, harus ditulis ulang. Tim itu mengharapkan AI untuk menghemat waktu dan sebaliknya mendapatkan pekerjaan tambahan. Jadi tidak lama setelah upaya pertama untuk melipat alat AI ke dalam aliran kerja sehari-hari, tim kembali bekerja dengan cara yang sama seperti sebelumnya.

Hari ini, alat-alat tersebut mempercepat baik menulis kode maupun meninjau kode untuk pengembang kami — bukan karena kami menemukan model yang lebih baik, tetapi karena kami mengubah cara kami bekerja dengannya. Berikut yang membantu kami mencapai tujuan itu.

Mengapa Kode yang Ditulis AI Mengganggu Pengembang

AI bergantung pada massa kode publik yang besar dari seluruh internet, dan kode itu jarang sempurna: kualitasnya rata-rata, dan model tersebut mereproduksi rata-rata tersebut.

“Rata-rata” bukanlah batas dari apa yang mungkin — itu hanya apa yang model keluarkan sampai itu mengenal proyek Anda: konvensi, struktur kode, keputusan arsitektur. Dalam survei 600 pengembang, Qodo menemukan bahwa di antara mereka yang tidak puas dengan kualitas kode AI, 44% mengatributkannya tepat pada kurangnya konteks. Itulah yang membuat output tetap pada tingkat yang biasa-biasa saja.

Berita baiknya adalah konteks yang diterima AI hampir sepenuhnya dikendalikan oleh tim. Seberapa baik alat tersebut memahami proyek tidak bergantung pada model, tetapi pada apa yang Anda berikan kepadanya.

Alasan kedua adalah mental — sifat pekerjaan itu sendiri berubah. Ketika AI menulis sebagian besar kode, tindakan utama pengembang tidak lagi menulis tetapi memeriksa apa yang dihasilkan: membaca solusi orang lain, menimbang alternatif, memutuskan apa yang siap untuk dikirim. Itu adalah keterampilan yang berbeda dari menulis kode sendiri, dan bagi siapa pun yang menyukai bagian penulisan, itu tidak datang dengan mudah.

Dalam laporan Octoverse 2025, GitHub menggambarkan perubahan ini: pengembang yang telah melangkah jauh dengan AI tidak lagi menyebut diri mereka “penulis kode” dan menjadi sesuatu yang lebih dekat dengan “direktur kreatif”, di mana keterampilan utama adalah mengarahkan dan memverifikasi. Tapi jalan menuju peran itu melalui kesalahan dan frustrasi, sampai seseorang melihat hasilnya dalam pekerjaannya sendiri.

Apa yang Mengubah AI dari Sumber Frustrasi Menjadi Alat Kerja

Ketika tim kami pertama kali menggunakan AI, beberapa pengembang bekerja dengan Claude Code, yang lain mencoba OpenAI Codex, GitHub Copilot, atau Gemini CLI, dan setiap alat memberikan hasil yang berbeda. Jadi ketika kami memutuskan untuk membawa ketertiban dalam cara tim bekerja dengan AI, hal pertama yang kami lakukan adalah menetapkan satu alat.

Ini bukan hanya praktik kami. Ambil cerita tim di Linear: sampai awal 2026 mereka berjalan pada prinsip “biarkan semua orang bekerja dengan cara yang sesuai bagi mereka”, dan pada Januari, kepemimpinan membuang pendekatan itu dan memindahkan semua orang ke satu cara bekerja — mempersempit pilihan ke dua alat AI dan meminta pengembang untuk menulis kode hanya dengan mereka, bukan dengan tangan. Menurut perusahaan, produktivitas rata-rata meningkat sebulan kemudian sebesar 30% dalam PR yang digabungkan dan sebesar 33% dalam tugas yang diselesaikan per insinyur.

Yang dikatakan, alat bersama sendiri tidak memperbaiki kode — itu harus dikonfigurasi: atur aturan, sesuatu seperti rules.md, yang menjelaskan cara menulis kode — pendekatan apa yang harus diikuti, apa yang harus dihindari. Lalu datang keterampilan khusus untuk tugas yang khas dari proyek Anda, sehingga Anda tidak menjelaskan hal yang sama berulang-ulang. Dan akhirnya, itu sepadan untuk menunjukkan agen ke basis kode yang ada: itu menganalisis bagaimana proyek itu ditulis dan menghasilkan kode baru dengan gaya yang sama, bukan dengan gaya generik. Semakin banyak konteks yang diterima alat, semakin sedikit yang harus Anda tulis ulang dengan tangan nanti.

Tapi bagian yang paling sulit bukanlah teknis. Perubahan dari penulis kode ke evaluator tidak terjadi dengan sendirinya — transisi itu membutuhkan bantuan. Jalur yang paling langsung adalah pelatihan dan sertifikasi. Dalam kasus kami, misalnya, sepuluh pengembang mengikuti program mitra dengan penyedia alat, sementara di samping mereka bekerja orang yang bertanggung jawab untuk adopsi, yang menjelaskan mengapa alat menghasilkan hasil tertentu dan bagaimana memperbaikinya.

Sekali tim bekerja dalam cara yang terkoordinasi, satu bottleneck tetap — tinjauan — dan itu sepadan untuk diperkuat dengan AI. Agen itu melalui setiap permintaan tarik pertama dan mengambil yang jelas: kesalahan rutin, gaya, pengulangan, celah keamanan. Peninjau manusia kemudian tidak lagi melihat semuanya secara tidak diskriminatif, hanya pada arsitektur dan keputusan kritis. Efeknya terlihat bahkan di dalam perusahaan yang membangun alat-alat ini: di Anthropic, setelah memperkenalkan agen seperti itu, bagian permintaan tarik yang menerima tinjauan substansial naik dari 16% menjadi 54%, dan insinyur tidak setuju dengan kurang dari 1% dari komentarnya.

Untuk kami, ini mempersingkat siklus tinjauan yang sebelumnya meluas selama dua atau tiga hari selama beberapa putaran, dan itu mengangkat rutinitas dari insinyur senior kami, meninggalkan mereka dengan tempat yang benar-benar sulit. Sekali alat itu akhirnya mulai menghasilkan hasil yang tidak perlu dikerjakan ulang, kepercayaan terhadap alat itu muncul juga.

Di Mana Kepercayaan terhadap Alat AI Membayar

Pertama dan terutama — dalam menulis kode: ketika alat tersebut mengenal proyek dan agen menangani tinjauan pertama, tim menulis lebih banyak dan lebih baik dalam waktu yang sama. Dalam kasus kami, alat AI mempercepat pekerjaan sekitar 30-40%.

Di luar itu, AI telah membuat onboarding lebih mudah. Ketika seseorang baru bergabung dengan proyek, seseorang yang berpengalaman biasanya harus menjawab puluhan pertanyaan tentang bagaimana kode proyek disusun. Sekarang agen itu mengambil peran itu: jika proyek itu didokumentasikan dengan baik, pendatang baru mengarahkan hingga 95% dari pertanyaan tersebut kepadanya, bukan kepada rekan.

Cerita yang sama berlaku untuk dokumentasi: draf arsitektur kasar yang sebelumnya memakan waktu berjam-jam sekarang, sebagian besar, ditulis oleh agen itu sendiri — menurut perkiraan kami, sekitar 80% dari draf, jika Anda memberinya konteks yang cukup. Apa yang tersisa bagi manusia adalah apa yang tidak ada di repositori — keputusan, kompromi, keahlian.

Sama pentingnya adalah bersikap jujur tentang batasan apa yang dapat dilakukan AI, karena itu adalah harapan yang dilebih-lebihkan yang memicu kekecewaan pada awalnya. AI tidak mengambil alih kepatuhan — manusia menandatangani data medis atau keuangan, dan perusahaan, bukan model, bertanggung jawab atas kebocoran. AI tidak mempercepat integrasi dengan mitra, di mana puluhan jam masuk ke dalam panggilan dan koordinasi.

AI yang keluar dari kotak memang mengganggu — tetapi hanya ketika digunakan sebagai solusi selesai. Perbedaan antara frustrasi dan hasil terletak pada apa yang Anda bangun di sekitarnya: standar bersama, konteks proyek, dan peran pengembang yang baru.