Pemimpin pemikiran

AI Menulis Kode, Tapi Apakah Infrastruktur Anda Bisa Mengikuti?

mm
Tambahkan Unite.AI ke sumber pilihan Anda di Google

Kami sedang melalui salah satu inversi paling aneh dalam sejarah rekayasa perangkat lunak. Selama dekade, tujuan adalah determinisme; membangun sistem yang berperilaku sama setiap saat. Sekarang kami melapisinya dengan agen AI probabilistik, menghasilkan kode dengan skala dan kecepatan yang mengkhawatirkan. Dan jujur? Sebagian besar infrastruktur kami tidak dibangun untuk ini.

Saya telah menghabiskan tahun-tahun bekerja pada alat DevOps, menjadi co-penulis penelitian, dan membantu tim insinyur mencapai kinerja tertinggi mereka. Apa yang saya lihat sekarang dengan pengembangan yang didorong AI adalah lebih dari sekadar evolusi. Ini memperlihatkan setiap celah dalam alur kerja kami yang ada.

Masalahnya Sudah Ada Di Sini

Sebuah penelitian GitClear 2025 menemukan bahwa hampir 7% komit sekarang berisi kode yang dihasilkan AI. Analisis sebelumnya mereka tentang 153 juta baris kode yang diubah menunjukkan biaya: “perubahan kode” – kode yang ditulis ulang atau dihapus dalam waktu dua minggu – meningkat dua kali lipat pada 2024 dibandingkan dengan baseline sebelum AI.

Implikasi keamanan sama-sama mengkhawatirkan. Analisis terbaru tentang 80 tugas pemrograman yang dikurasi di lebih dari 100 model bahasa besar menemukan bahwa kode yang dihasilkan AI memperkenalkan kerentanan keamanan dalam 45% kasus. Dampak dunia nyata? Satu dari lima CISO sekarang melaporkan insiden besar yang disebabkan langsung oleh kode yang dihasilkan AI.

Keuntungan kecepatan nyata, tetapi biaya stabilitas juga nyata.

Efek Amplifikasi

Satu hal yang saya pelajari adalah bahwa AI memperkuat semua. Jika Anda memiliki praktik yang baik, AI membuatnya lebih baik dan lebih cepat. Jika proses Anda berantakan, AI memperburuk kekacauan itu juga. Ini mencerminkan pola yang muncul tahun demi tahun dalam laporan DevOps tahunan DORA: lebih sedikit variabel menghasilkan hasil yang lebih baik. Tim yang sukses memstandarkan pada lebih sedikit sistem operasi, lebih sedikit bahasa pemrograman, lebih sedikit cara melakukan hal-hal.

Agen AI mengikuti pola yang sama. Berikan mereka lingkungan yang konsisten di mana Python berarti versi yang sama di setiap mesin pengembang, di mana dependensi dikunci dan dilacak, dan mereka akan unggul. Paksa mereka untuk menavigasi 17 konfigurasi yang berbeda, masing-masing dengan perbedaan yang halus, dan Anda akan membakar token untuk memahami keanehan lingkungan daripada menyelesaikan masalah yang sebenarnya.

Paradoks Determinisme

Ini menciptakan ketegangan yang menarik. Selama bertahun-tahun, ilmu komputer mengejar determinisme sebagai tujuan utama. Sekarang kami menjalankan beban kerja probabilistik, model AI yang secara harfiah tidak dapat menjamin output yang sama dua kali, di atas sistem yang dirancang untuk dapat diprediksi.

Jawaban saya? Pertahankan sebanyak mungkin tumpukan yang deterministik. Jika Anda dapat mempertahankan 80% infrastruktur Anda pada tingkat deterministik, agen AI Anda memiliki lebih sedikit variabel untuk dikelola. Mereka tidak menghabiskan konteks jendela pada “Mengapa dependensi ini tidak terinstal?” atau “Ayo coba perintah build ini lagi.” Mereka fokus pada pekerjaan yang sebenarnya Anda minta mereka lakukan.

Pikirkan tentang ini: ketika agen mencoba mengompilasi sesuatu dan ikatan asli gagal karena ImageMagick tidak terinstal, itu adalah detour yang mahal token. Jika lingkungan Anda sudah mencakup semua yang dibutuhkan (kompiler, library, pohon dependensi lengkap hingga libc), agen hanya bekerja. Tidak ada debugging, tidak ada trial dan error, hanya kemajuan.

Spesifikasi dan Validasi adalah Kunci

Apa yang menjadi jelas adalah bahwa pengembangan yang didorong AI memaksa kami untuk berpikir lebih keras tentang dua keterampilan yang historis kurang dihargai: spesifikasi dan validasi. Anda perlu mengartikulasikan apa yang sebenarnya Anda bangun, dan Anda perlu cara yang kuat untuk memverifikasi bahwa Anda mendapatkannya.

Saya telah memperhatikan sesuatu yang menarik: orang dengan latar belakang manajemen produk atau rekayasa produk sering lebih sukses dengan agen AI sekarang. Mereka sudah terlatih untuk berpikir dalam hal persyaratan, kriteria keberhasilan, dan trade-off. Mereka nyaman bertanya “Mengapa Anda membuat pilihan itu?” dan menyesuaikan berdasarkan alasan.

Validasi, mengetahui apakah sesuatu benar-benar benar, telah menjadi masalah terberat dalam rekayasa perangkat lunak. QA telah dihargai rendah selama dekade, namun ini adalah bagian terberat: menentukan apakah perangkat lunak memecahkan kebutuhan pengguna yang sebenarnya. AI tidak menyelesaikan ini. Jika ada, ini membuatnya lebih kritis, karena sekarang Anda memvalidasi output probabilistik terhadap persyaratan deterministik.

Percayalah, Tetapi Verifikasi (Dan Kontrol)

Ada sentimen yang saya mulai terima: kita harus menganggap kode yang dihasilkan AI sebagai musuh sampai dibuktikan sebaliknya. Bukan karena AI jahat, tetapi karena kita tidak tahu. Kita tidak bisa mengaudit setiap baris ketika agen menghasilkan ribuan baris per hari.

Ini berarti memindahkan titik kontrol. Jika kita tidak bisa mengontrol semua pada waktu pengembangan, kita perlu kontrol yang lebih kuat pada waktu runtime. Operator, SRE, tim platform, siapa pun yang bertanggung jawab atas produksi, perlu visibilitas yang lebih baik ke dalam apa yang berjalan, pelacakan dependensi yang lengkap, dan provenance yang jelas untuk setiap artifact.

Ini adalah tempat di mana reproducibility menjadi penting. Ketika Anda dapat membuktikan secara matematis bahwa artifact yang Anda uji secara lokal identik dengan apa yang berjalan di produksi – input yang sama, output yang sama, penutupan dependensi yang sama – Anda dapat memulai membuat keputusan yang cerdas. Mungkin Anda tidak perlu menjalankan ulang unit test di CI jika Anda sudah menjalankannya secara lokal dan tidak ada yang berubah. Mungkin Anda dapat memetakan cakupan test ke perubahan kode dan melewati test suite yang tidak relevan.

Apa yang Terjadi Selanjutnya

Kami berada pada titik infleksi. Tim yang sudah memiliki praktik yang baik sekarang melihat keuntungan produktivitas yang besar dengan AI. Tim yang berjuang sekarang berjuang lebih cepat.

Infrastruktur yang memungkinkan pengembangan yang didorong AI perlu dibangun untuk reproducibility dari awal. Bukan dengan alat pemindaian dan audit yang dipasang setelahnya, tetapi dipanggang ke dalam cara pengembang bekerja dari hari pertama. Ketika lingkungan pengembangan Anda identik di Mac dan Linux, ketika setiap dependensi dilacak dan dikunci, ketika Anda memiliki provenance lengkap untuk setiap artifact, agen AI menjadi pengganda kekuatan bukan pembuat kekacauan.

Berikut adalah saran terbesar saya untuk tim yang mencoba sukses di era AI:

  • Standarisasi dengan kejam. Lebih sedikit variabel berkorelasi dengan kinerja yang lebih tinggi. Kunci teknologi stack Anda, lakukan lingkungan yang konsisten di semua platform, dan hapus drift konfigurasi sebelum AI memperkuatnya. Jika perbedaan versi Python menyebabkan masalah sekarang, mereka akan menyebabkan 10 kali lebih banyak masalah ketika AI menghasilkan kode dengan skala.

  • Bangun validasi ke dalam alur kerja Anda, bukan di akhir. Dengan AI menghasilkan kode lebih cepat daripada manusia dapat meninjau, Anda tidak bisa hanya mengandalkan tinjauan kode manual. Implementasikan pengujian otomatis yang memvalidasi tidak hanya kode berjalan, tetapi juga kode memecahkan kebutuhan yang sebenarnya. Buat pipa CI/CD Anda sebagai jaring pengaman, dengan gerbang yang kuat pada waktu runtime untuk penyebaran produksi.

  • Investasikan reproduktivitas sebagai infrastruktur. Perlakukan konsistensi lingkungan sebagai kekhawatiran infrastruktur kelas satu. Ketika Anda dapat membuktikan secara matematis bahwa lingkungan lokal, lingkungan CI, dan lingkungan produksi Anda identik, Anda menghilangkan satu kelas masalah “bekerja di mesin saya”. Ini adalah fondasi deterministik yang memungkinkan Anda untuk dengan aman melapisinya dengan beban kerja AI probabilistik.

Pertanyaannya bukan apakah AI akan menulis sebagian besar kode kita. Ini sudah dilakukan untuk banyak tim. Pertanyaannya adalah apakah infrastruktur kita bisa mengikuti.

Michael Stahnke adalah eksekutif teknik yang berpengalaman, telah menghabiskan 15+ tahun terakhir bekerja di ruang pengembangan dan alat operasional di mana ia juga melakukan penelitian dan menjadi penulis di Laporan State of DevOps Puppet.

Michael saat ini menjabat sebagai VP of Engineering di Flox. Sebelumnya, ia menjabat sebagai pemimpin teknik senior di CircleCI dan Puppet di mana ia tumbuh tim teknik sebesar 5x atau lebih. Ia telah menghabiskan waktu membangun tim yang berkinerja tinggi, organisasi, dan melakukan penelitian tentang efektivitas teknik serta mengembangkan sistem pengemasan dan rilis. Ia telah berbicara di acara DevOps dan Automation sejak 2007. Ia mendirikan repositori paket Extra Packages for Enterprise Linux (EPEL) dan menulis buku tentang OpenSSH pada 2005.