Realita Software Engineer setelah Agentic AI: Kerja Makin Mudah, Beban Makin Banyak

Agentic AI membuat pekerjaan software engineer lebih mudah. Masalahnya, sesuatu yang menjadi lebih mudah biasanya tidak membuat pekerjaan berkurang. Justru ekspektasinya yang bertambah.

Sejak menggunakan AI agent untuk membantu pekerjaan sehari-hari, saya merasakan perubahan yang cukup besar. Membaca codebase, membuat implementasi awal, mencari penyebab bug, menulis test, sampai melakukan refactoring sekarang bisa dikerjakan lebih cepat.

Pekerjaan yang sebelumnya membutuhkan beberapa jam kadang bisa selesai dalam hitungan menit. Kita tidak lagi harus menulis setiap baris code dari awal. Cukup memberikan konteks, meminta agent membuat rencana, membiarkannya mengeksekusi, lalu kita melakukan review dan validasi.

Di satu sisi, ini jelas membantu.

Namun ada realita lain yang mulai terasa, terutama ketika bekerja di software house: karena satu engineer dianggap bisa bekerja lebih cepat, satu engineer juga dianggap bisa menangani lebih banyak pekerjaan.

Dari Satu Project ke Beberapa Project

Sebelum era Agentic AI, kapasitas engineer relatif mudah terlihat. Satu orang punya satu project utama, beberapa task, lalu fokus menyelesaikannya berdasarkan prioritas.

Sekarang batas itu mulai bergeser.

Dengan bantuan AI, satu engineer secara teknis memang bisa berkontribusi di beberapa project. Pagi memperbaiki bug di Project A, siang membuat fitur di Project B, sore melakukan review atau membantu investigasi di Project C.

Selama kondisinya normal, pola ini bahkan terlihat sangat efisien. AI membantu memahami struktur codebase yang berbeda, mencari file yang relevan, dan mempercepat proses implementasi. Waktu yang biasanya habis untuk pekerjaan mekanis bisa dialihkan ke pengambilan keputusan.

Masalahnya, kapasitas manusia bukan hanya soal seberapa cepat kita menghasilkan code.

Setiap project membawa konteksnya sendiri:

• kebutuhan bisnis yang berbeda,
• arsitektur dan konvensi codebase yang berbeda,
• orang-orang yang perlu diajak berkomunikasi,
• jadwal meeting dan tenggat waktu,
• proses QA dan deployment,
• serta risiko yang harus ditanggung ketika terjadi masalah.

AI bisa membantu membaca konteks. Tetapi engineer tetap membutuhkan energi untuk memahami, memutuskan, dan bertanggung jawab atas hasil akhirnya.

Coding Lebih Cepat, Context Switching Tetap Mahal

Salah satu hal yang belum diselesaikan oleh Agentic AI adalah context switching.

Bayangkan sedang fokus memperbaiki masalah autentikasi di satu project. Belum selesai melakukan pengujian, masuk pesan dari project lain karena ada perubahan mendadak dari klien. Ketika mulai memahami perubahan tersebut, ada lagi laporan bahwa aplikasi di project ketiga mengalami masalah di production.

AI agent mungkin bisa membuka ketiga codebase dan mulai bekerja secara paralel. Tetapi perhatian kita tidak benar-benar berjalan paralel.

Kita tetap harus berpindah dari satu model bisnis ke model bisnis lain, mengingat keputusan sebelumnya, membaca hasil kerja agent, lalu memastikan solusi yang dibuat tidak merusak bagian lain. Setiap perpindahan terlihat kecil, tetapi meninggalkan sisa beban di kepala.

Pada akhirnya, bottleneck-nya tidak selalu berada pada kemampuan menulis code. Bottleneck bisa berpindah ke:

• kemampuan memberikan konteks yang tepat,
• kecepatan melakukan review,
• kapasitas mengambil keputusan,
• koordinasi dengan banyak pihak,
• dan fokus untuk melakukan validasi secara menyeluruh.

Agent bisa menghasilkan perubahan lebih cepat daripada kemampuan kita untuk memeriksanya. Kalau tidak hati-hati, antrean pekerjaan hanya berpindah dari “belum ditulis” menjadi “belum direview”.

Ketika Semua Project Baik-Baik Saja

Menangani beberapa project terasa memungkinkan ketika semuanya berjalan sesuai rencana.

Requirement jelas. Tidak ada masalah di production. QA berjalan lancar. Klien tidak mengubah prioritas. Agent menghasilkan implementasi yang cukup akurat. Dalam kondisi seperti ini, satu engineer memang bisa memiliki leverage yang jauh lebih besar dibandingkan sebelumnya.

Inilah sisi Agentic AI yang paling mudah terlihat: jumlah pekerjaan yang selesai bertambah, sementara waktu implementasi berkurang.

Namun kapasitas tidak seharusnya dihitung hanya dari kondisi ideal.

Software engineering selalu memiliki ketidakpastian. Ada edge case yang baru ditemukan, integrasi pihak ketiga yang tiba-tiba bermasalah, deployment yang gagal, atau requirement yang terlihat kecil tetapi ternyata menyentuh banyak bagian sistem.

Kalau satu engineer memegang beberapa project, satu kejadian darurat mungkin masih bisa ditangani. Tetapi ketika dua atau tiga masalah datang bersamaan, seluruh perencanaan bisa runtuh dengan cepat.

Saat Hectic, Semuanya Bisa Jadi “Kebakaran”

Di sinilah konsekuensi dari kapasitas yang terlalu padat mulai muncul.

Project A harus segera rilis. Project B mendapat revisi besar dari klien. Project C menemukan bug kritis menjelang demo. Semua dianggap prioritas, semua punya alasan untuk segera dikerjakan, dan semua mengarah ke orang yang sama karena orang tersebut selama ini terlihat mampu menanganinya.

Agentic AI tetap membantu. Ia bisa membuat analisis awal, menyiapkan patch, atau menjalankan test. Tetapi agent tidak bisa menghilangkan tekanan dari tiga tenggat yang bertabrakan. Ia juga tidak mengambil alih tanggung jawab ketika keputusan yang dibuat ternyata salah.

Dalam kondisi seperti ini, kecepatan AI bahkan bisa menciptakan ilusi bahwa semuanya masih terkendali. Banyak perubahan bisa dibuat dalam waktu singkat, tetapi:

• apakah seluruh perubahan sudah direview dengan benar?
• apakah setiap skenario penting sudah diuji?
• apakah kita masih memahami konsekuensi dari keputusan yang diambil?
• atau kita hanya terus menerima hasil agent agar semua terlihat bergerak?

Ketika sedang “kebakaran”, kualitas review adalah salah satu hal yang paling mudah dikorbankan. Padahal justru pada saat itulah risiko kesalahan menjadi lebih tinggi.

AI yang sangat cepat, engineer yang kelelahan, dan beberapa project yang sama-sama mendesak adalah kombinasi yang berbahaya.

Produktivitas Bukan Berarti Utilisasi Maksimal

Menurut saya, ada perbedaan penting antara menjadi lebih produktif dan mengisi seluruh kapasitas yang berhasil dibebaskan.

Jika AI menghemat 30 persen waktu engineer, waktu tersebut tidak harus langsung diisi dengan 30 persen pekerjaan tambahan. Sebagian kapasitas bisa digunakan untuk hal-hal yang selama ini sering tertunda:

• memperbaiki kualitas dan struktur code,
• menambah cakupan test,
• menulis dokumentasi,
• memahami kebutuhan bisnis lebih dalam,
• mengurangi technical debt,
• atau sekadar menyediakan ruang untuk menghadapi hal yang tidak terduga.

Ruang kosong bukan berarti engineer sedang tidak produktif. Dalam pekerjaan yang penuh ketidakpastian, ruang kosong adalah cadangan kapasitas.

Masalahnya, di software house kapasitas sering berkaitan langsung dengan jumlah project yang dapat berjalan. Secara bisnis, wajar jika perusahaan ingin memanfaatkan efisiensi dari AI. Tetapi jika setiap peningkatan kecepatan selalu dibalas dengan penambahan beban, engineer tidak pernah benar-benar merasakan manfaat efisiensi tersebut.

Yang berubah hanya jumlah pekerjaan yang harus dijaga dalam waktu bersamaan.

Peran Engineer Justru Menjadi Lebih Berat

Agentic AI memang mengurangi sebagian pekerjaan eksekusi, tetapi tanggung jawab engineer tidak ikut berkurang.

Peran kita bergeser dari sekadar menulis code menjadi:

• mendefinisikan masalah dengan jelas,
• memberikan konteks kepada agent,
• memilih pendekatan yang tepat,
• menilai kualitas hasil,
• menguji asumsi,
• dan menjaga agar perubahan tetap aman untuk sistem.

Satu engineer mungkin bisa menghasilkan pekerjaan setara beberapa orang dalam konteks tertentu. Namun itu tidak otomatis berarti satu engineer dapat menggantikan beberapa orang dalam semua aspek.

AI bisa membantu mengerjakan beberapa hal secara paralel. Manusia tetap harus menanggung komunikasi, keputusan, fokus, dan akuntabilitasnya.

Karena itu, menghitung kapasitas engineer setelah Agentic AI hanya dari kecepatan implementasi adalah ukuran yang terlalu sederhana.

Kita Membutuhkan Cara Baru Mengukur Kapasitas

Setelah Agentic AI, pertanyaan manajemen seharusnya bukan hanya:

“Dengan AI, berapa banyak project yang sekarang bisa ditangani satu engineer?”

Pertanyaannya juga perlu mencakup:

• Berapa banyak konteks yang bisa dijaga engineer tanpa menurunkan kualitas?
• Siapa yang menentukan prioritas ketika beberapa project mendesak bersamaan?
• Berapa banyak waktu yang disediakan untuk review dan pengujian?
• Apa yang terjadi ketika agent menghasilkan solusi yang salah?
• Apakah masih ada cadangan kapasitas untuk insiden dan perubahan mendadak?

AI meningkatkan kemampuan eksekusi, tetapi kapasitas tim tetap perlu dirancang berdasarkan kondisi terburuk yang masuk akal, bukan hanya berdasarkan hari-hari ketika semuanya berjalan lancar.

Penutup

Saya tetap melihat Agentic AI sebagai perkembangan yang sangat membantu software engineer. Banyak pekerjaan menjadi lebih cepat, proses memahami codebase menjadi lebih ringan, dan kita punya lebih banyak leverage untuk menyelesaikan masalah.

Tetapi leverage tidak selalu berarti beban menjadi lebih ringan.

Di software house, leverage itu bisa berubah menjadi lebih banyak project, lebih banyak konteks, dan lebih banyak tanggung jawab untuk satu orang. Ketika situasi normal, semuanya terlihat efisien. Ketika beberapa masalah datang bersamaan, semuanya bisa berubah menjadi “kebakaran”.

Karena itu, tantangan software engineer setelah Agentic AI bukan lagi sekadar bagaimana menulis code lebih cepat.

Tantangannya adalah bagaimana menjaga fokus, kualitas, dan kesehatan kerja ketika ekspektasi meningkat secepat kemampuan kita.

Agentic AI seharusnya memberi engineer ruang untuk bekerja lebih baik, bukan sekadar ruang untuk menampung lebih banyak pekerjaan.