Pemimpin pemikiran

Sistem Anda Sudah Memiliki Titik Buta. AI Hanya Membuatnya Lebih Buruk.

mm
Tambahkan Unite.AI ke sumber pilihan Anda di Google

Pada tahun 2022, sebelum alat pengkodean generatif menjadi bagian dari pekerjaan teknik harian kami, saya menulis about my philosophy on tool selection. Itu bertahan lebih baik daripada yang saya harapkan. Saat itu, saya berargumen untuk memulai dengan masalah yang sebenarnya Anda selesaikan, mengetahui kelemahan Anda, dan memprioritaskan cara Anda menggunakan alat dibandingkan hanya melompat pada alat apa pun yang terdengar paling baik dan berharap itu berhasil. Kenali dirimu, dan tujuanmu, sehingga Anda dapat menetapkan harapan yang tepat untuk alat Anda.

Pada saat itu, saya memikirkan penyebaran SaaS, bukan kode yang dihasilkan AI. Namun hari ini filosofi saya bahkan lebih mendesak, dan lebih penting untuk dipertahankan.

Banyak di antara kami telah membaca 2025 DORA report, yang menemukan bahwa, tidak seperti tahun sebelumnya, adopsi AI kini berhubungan positif dengan throughput pengiriman. Temuan di bawahnya adalah bahwa ketidakstabilan pengiriman terus meningkat, dan mereka menguji apakah peningkatan kecepatan menutupi hal itu. Mereka tidak. Itu sesuai dengan pengalaman kami. Tim kami mengadopsi pengembangan perangkat lunak agenik dan melihat peningkatan throughput sebesar 48% selama dua kuartal, diikuti oleh peningkatan masalah stabilitas sebesar 16%. Sepuluh orang adalah sampel kecil, tetapi itu juga sampel dari mana saya dapat melihat gambaran lengkap, dan pola tersebut tetap berlaku. 

Adopsi AI tidak lagi menjadi pertanyaan. Anda enten baru memulai atau sudah berada di tengahnya. Apa yang berbeda sekarang adalah para pemimpin teknik diharapkan mengadopsi AI dan juga membuktikan bahwa itu memberikan hasil. CEO, dewan, dan keuangan semua ingin tahu cara mengoptimalkan investasi AI mereka. Mereka menanyakan apakah alat yang Anda pilih menyelesaikan masalah nyata secara efisien. 

Kesenjangan Selalu Ada. AI Hanya Membuatnya Lebih Lebar.

Sebagai CTO, saya menghabiskan sebagian besar waktu saya berbicara dengan pemimpin teknik lainnya, termasuk pelanggan, prospek, dan rekan-rekan saya untuk membandingkan pencapaian dan keluhan tentang apa yang kami alami dengan AI. Setelah cukup banyak percakapan ini, saya mulai melihat pola dalam adopsi AI dan hasilnya.

Pengamatan utama bukan milik saya. DORA telah menyorotnya selama dua tahun sekarang: AI memperkuat apa pun yang sudah terjadi di organisasi, baik kekuatan maupun kelemahan. Tim dengan arsitektur bersih dan kebiasaan review yang sehat menjadi lebih cepat. Tim yang telah mengatasi tumpukan hutang teknis yang rumit cukup untuk mengirim kode kini menemukan bahwa hutang teknis itu berkembang menjadi penghalang utama. Namun, kerangka tersebut tidak menjelaskan mengapa hal ini mengejutkan begitu banyak tim. AI tidak menyembunyikan kelemahan ini; sistem yang kami andalkan tidak pernah mengungkapkannya.

Tumpukan tiket-dan-pelaporan yang digunakan kebanyakan organisasi teknik dibangun untuk menjawab pertanyaan yang dimiliki manusia, dengan kecepatan manusia, oleh orang yang secara kasar memahami apa arti “selesai” untuk suatu pekerjaan tertentu. Itu tidak pernah menjadi catatan yang sempurna. Itu selalu perkiraan, diisi oleh seseorang yang merangkum sesuatu yang lebih berantakan di bawahnya. Sekarang, AI menambah volume, dan menambah masukan baru yang menghasilkan aktivitas baru. Tidak ada sistem (atau alat) yang digunakan untuk metode pengembangan tradisional non-AI yang pernah dibuat untuk itu. 

Terlepas dari itu, kami masih bertanggung jawab atas tujuan yang sama. Anda masih mengendalikan kecepatan, kualitas, pengeluaran, dan bagaimana tim Anda sebenarnya berjalan. Anda tidak lagi dapat mempercayai dasbor tahun lalu begitu saja. 

Ada keberatan yang wajar di sini. DORA’s 2026 ROI report menggambarkan kurva J: penurunan produktivitas tepat setelah adopsi, dipicu oleh kurva belajar, biaya verifikasi kode yang dihasilkan AI, dan proses hilir yang belum mengejar. Mereka menyebutnya “biaya kuliah” transformasi, dan memperingatkan para pemimpin agar tidak mengira itu kegagalan. Itu masuk akal. Namun biaya kuliah dan masalah nyata terlihat identik pada dasbor yang dibangun dari tiket. Jika Anda tidak dapat membedakan mana yang Anda alami, Anda tidak bersabar. Anda hanya menebak.

Kita perlu kembali ke dasar. Kenali dirimu. Kenali timmu. Ketahui masalah apa yang Anda selesaikan. 

Bagaimana Anda “Mengenal Diri” dengan AI?

Dari percakapan saya, saya mengidentifikasi lima area utama di mana sistem konvensional, yang dibangun untuk pekerjaan yang dihasilkan manusia dan dilaporkan manusia, memiliki titik buta. Mengabaikannya berisiko memperkuat kelemahan Anda saat terus mengadopsi AI.

Titik Buta 1: Teater Kecepatan

Lebih banyak commit dan lebih banyak PR dapat terasa seperti kemajuan, dan sering memang begitu. AI meningkatkan kedua hitungan secara otomatis. Sebuah Stanford case study menunjukkan bahwa mengadopsi AI meningkatkan jumlah PR sebesar 14%. Namun yang Anda lewatkan adalah seberapa banyak aktivitas tersebut merupakan pekerjaan fitur yang dikirim versus pemeliharaan, pengerjaan ulang, atau churn dari refaktor yang tidak bertahan.

Untuk mengatasinya, perhatikan pemisahan antara pekerjaan fitur dan pemeliharaan, serta pantau frekuensi deployment dan lead time dibandingkan baseline historis Anda sendiri, bukan rata-rata industri. Tanpa pemisahan itu, Anda melaporkan kemajuan yang tidak dapat dibuktikan secara nyata.

Titik Buta 2: Hutang Review

Kapasitas review tidak secara otomatis meningkat seiring dengan output. Pajak verifikasi bukanlah fase yang dapat dilewati; itu merupakan bagian dari biaya tetap untuk pengembangan agen. Sebuah survei terbaru para pemimpin teknik menemukan bahwa 80% tim menghabiskan setidaknya 10% waktunya untuk review, dan kira-kira satu dari sepuluh menghabiskan lebih dari 40%. Di bawah beban itu, tim berayun antara backlog yang terus bertambah dan persetujuan otomatis, dan keduanya bukan jawaban yang sebenarnya.

Kendala pengiriman bukan lagi seberapa cepat kode ditulis. Itu seberapa cepat seorang manusia dapat benar-benar yakin bahwa perubahan tersebut benar, seberapa cepat dan akurat cacat dapat terdeteksi dan ditangani. Amati bagaimana beban review sebenarnya didistribusikan di seluruh tim Anda; jika tidak, Anda berisiko membebani insinyur senior Anda, menunda rilis Anda, atau menyebabkan masalah produksi yang besar.

Blind Spot 3: Pekerjaan Tersembunyi

Refaktor dan pergeseran arsitektur cenderung bersembunyi di dalam tiket lain, jika mereka muncul di sistem tiket sama sekali. AI menghasilkan lebih banyak jenis pekerjaan ini, bukan lebih sedikit. Seorang agen tidak ragu untuk menyentuh dua belas file untuk memperbaiki satu bug, sementara manusia mungkin berhenti sejenak dan mempertimbangkan kembali. Pekerjaan yang melewati sistem pencatatan juga melewati perencanaan, yang berarti model kapasitas Anda salah, dan setiap perkiraan yang dibangun di atasnya juga salah.

Untuk memahami berapa banyak pekerjaan yang sebenarnya dilakukan, Anda perlu mengamati berapa banyak yang sebenarnya berubah dalam basis kode dan riwayat pull request. Tanpa itu, rencana kapasitas Anda dibangun atas apa yang orang ingat untuk dicatat, bukan atas apa yang sebenarnya mereka lakukan.

Blind Spot 4: Penurunan Kualitas

Survei yang sama menemukan hampir setengah pemimpin teknik kesulitan mendeteksi masalah keamanan minggu demi minggu. Kompleksitas, duplikasi, dan ketergantungan yang tidak sepenuhnya cocok menumpuk di banyak perubahan kecil yang masing-masing tampak wajar. Tidak ada satupun yang tampak mengkhawatirkan secara terpisah. Dalam studi kasus Stanford yang sama, kualitas kode turun 9% dan variansinya lebih dari tiga kali lipat. Sementara rata-rata berubah sedikit, penyebaran (bagian yang Anda perhatikan) berubah sangat signifikan. Pada volume AI, mereka berakumulasi lebih cepat daripada proses review kebanyakan dapat menangkapnya. Penurunan kualitas cenderung muncul sebagai peringatan on-call yang ditelusuri kembali ke sebuah ketergantungan yang tidak diingat siapa pun telah direview. Pada saat ini terjadi, ada kemungkinan cukup besar bahwa pelanggan sudah memperhatikannya terlebih dahulu.

Amati tren pada temuan keamanan, ketergantungan, serta kegagalan dan pemulihan—bukan commit individu. Kompleksitas dan duplikasi yang merayap selama beberapa minggu lebih penting daripada satu perubahan yang ditandai dalam review. Tanpa itu, Anda menangkap penurunan kualitas dengan cara yang masih dilakukan kebanyakan tim: setelahnya sudah menyebabkan insiden.

Blind Spot 5: Pengeluaran yang Belum Terbukti

Setelah adopsi AI tidak lagi menjadi perdebatan, pengeluaran AI dan ROI menjadi pertanyaan yang menjadi fokus semua orang. Keuangan ingin mengetahui apa yang dapat dikapitalisasi versus operasional. Kepemimpinan ingin mengetahui apa hasil investasi tersebut. Sebagian besar tim masih membuat keputusan tentang alat, lisensi, dan jumlah karyawan berdasarkan intuisi, bukan bukti hubungan antara uang dan pekerjaan yang disampaikan.

Amati ke mana upaya teknik sebenarnya mengalir dalam basis kode itu sendiri, kuartal demi kuartal — bukan ke mana roadmap mengatakan seharusnya mengalir. Tanpa tautan itu, Anda membela anggaran tahun depan dengan anekdot, dan anekdot tidak bertahan dalam percakapan keras dengan CFO.

Mulailah Dengan Apa yang Tidak Bisa Anda Lihat

Pertanyaan keuangan tentang pengeluaran yang dikapitalisasi dan halaman on-call pada pukul 2 pagi tampak tidak terkait, padahal tidak. Keduanya dapat “diperkirakan” dari aktivitas. Namun keduanya sebenarnya dapat dijawab, dengan bukti, dari kode itu sendiri.

Jawaban DORA untuk semua ini adalah sistem teknik itu sendiri: kualitas platform, kejelasan alur kerja, keselarasan tim. Benar, dan itu juga bukan langkah pertama. Anda tidak dapat memperbaiki sistem yang tidak dapat Anda lihat. Setiap dari lima area tersebut adalah hal yang harus Anda amati sebelum dapat berargumen untuk berinvestasi di dalamnya.

Langkah berguna pertama bukanlah alat baru atau proses baru. Itu adalah mengenal diri sendiri dengan jujur, dan menentukan mana dari lima area ini yang merupakan blind spot dimana Anda kekurangan bukti nyata. Kebanyakan pemimpin dapat segera mengidentifikasi (dan memperhatikan) masalah di salah satu area ini. Namun, area di mana Anda memiliki informasi paling sedikit adalah yang paling mungkin muncul dan menggigit Anda saat Anda terus mengadopsi AI.

Aaron Beals adalah CTO di Flux, di mana ia membangun tim rekayasa berkinerja tinggi, berorientasi produk, dan platform skala era AI untuk pemimpin perangkat lunak. Dengan pengalaman lebih dari dua puluh tahun, ia telah memimpin inisiatif rekayasa dan produk di Endeca, Netezza, Proyek Pengiriman Kesehatan Global Harvard Medical School, dan Appsembler (diakuisisi oleh Xenon Partners).