Software Factory : Plan, Build, dan Evaluate dengan AI dalam ADLC

Dalam satu uji coba acak, developer berpengalaman yang memakai alat AI butuh waktu 19% lebih lama untuk menyelesaikan tugas mereka. Sebelum studi dimulai, mereka memperkirakan AI akan membuat mereka 24% lebih cepat. Setelah studi selesai, mereka masih percaya AI telah mempercepat kerja mereka (METR, 2025).

Di tahun yang sama, ada angka lain: Faros AI melaporkan bahwa adopsi AI yang lebih tinggi berjalan bersama 33,7% lebih banyak task yang diselesaikan, tetapi juga 54% lebih banyak bug per developer dan sekitar 240% lebih banyak insiden per PR (Faros AI).

Jadi AI menghasilkan kode lebih cepat, tetapi kita buruk dalam menilai apakah kita benar-benar selesai lebih cepat, atau apakah hasilnya lebih baik. Jurang itulah inti dari artikel ini. Kalau Anda ingin AI menjalankan bagian nyata dari proses delivery Anda, Anda harus memperlakukannya seperti pabrik: input yang terdefinisi, stasiun kerja yang terdefinisi, dan pemeriksaan kualitas di setiap stasiun. Artikel ini membahas apa itu software factory, bagaimana ia masuk ke dalam AI-driven development life cycle (ADLC), dan seperti apa loop Plan, Build, dan Evaluate yang baik. Artikel ini ditulis untuk tech lead dan engineering manager yang punya wewenang mengubah cara kerja pipeline, review, dan permission di tim mereka.

Catatan singkat soal istilah. "ADLC" dipakai untuk beberapa hal. Di sini saya memakainya untuk AI-Driven Development Life Cycle, model yang dipublikasikan AWS sebagai AI-DLC. Sebagian orang juga memakai ADLC untuk siklus pengembangan "agentic". Idenya banyak tumpang tindih, tetapi sumber-sumber di bawah ini merujuk ke versi AWS.

Apa sebenarnya software factory itu?

Istilah ini lebih tua dari hype AI. Departemen Pertahanan AS memakainya untuk rangkaian pipeline yang mengubah source code menjadi artefak siap deploy dengan campur tangan manusia seminimal mungkin. Dalam versi itu, manusia yang mengoperasikan pipeline.

Makna baru yang bersifat agentic menggeser pembagian kerjanya. Faros mendefinisikan software factory sebagai sistem yang memakai "agen AI, engineering tools, konteks organisasi" ditambah workflow otomatis, verifikasi, dan penilaian manusia untuk menggerakkan pekerjaan sampai menjadi software yang dirilis (Faros AI). Ada tiga bagian:

1. Intake dan orkestrasi. Sebuah harness memutuskan agen dan model mana yang mengambil sebuah task, tools dan konteks apa yang mereka dapat, dan di titik mana manusia harus menyetujui.
2. Pengetahuan dan eksekusi. Context engineering, memori agen, dan skill memberi bekal ke agen, yang bekerja di lingkungan terkendali.
3. Verifikasi dan umpan balik. Tes, eval, agen reviewer, dan review manusia memutuskan apakah pekerjaan boleh lanjut. Kegagalan yang berulang dimasukkan kembali ke sistem.

Peran manusia juga berubah. Anda menulis lebih sedikit kode dan menghabiskan lebih banyak waktu untuk spesifikasi, acceptance criteria, konteks agen, eval, permission, dan kasus-kasus tepi yang butuh penilaian.

Peringatan: Faros menjual platform untuk persis hal ini, dan halaman itu sendiri mengakui belum ada definisi standar dan belum ada benchmark industri. Anggap kerangka ini sebagai satu sudut pandang yang berguna, bukan kebenaran yang sudah mapan.

Di mana posisi ADLC

AWS menjelaskan ADLC dalam sebuah tulisan pada Juli 2025 (AWS DevOps Blog). Ide intinya: AI berada di pusat proses, dan manusia tetap memegang keputusan. Ada tiga fase:

Ada dua pergantian istilah yang perlu diketahui. Bolt, yang oleh AWS digambarkan sebagai siklus kerja "yang diukur dalam jam atau hari, bukan minggu," menggantikan sprint. Unit of Work menggantikan epic.

Perhatikan bahwa tulisan AWS tidak memberikan hasil pengukuran apa pun. Kalimat "dari minggu menjadi hari" adalah klaim, bukan benchmark. AWS juga membuka workflow ini sebagai rules yang bisa dimuat ke tools seperti Amazon Q Developer (awslabs/aidlc-workflows).

Metafora pabrik cocok di sini. ADLC adalah tata letak lantai pabrik. Software factory adalah mesin dan kontrol kualitas di lantai itu.

Mengapa gerbang itu penting: apa kata riset

Tiga temuan riset membentuk cara saya berpikir soal ini. Masing-masing menunjuk ke gerbang yang berbeda.

1. AI paling cepat pada tugas kecil yang terdefinisi jelas. Itulah gerbang Plan. Dalam eksperimen tahun 2023, developer yang memakai GitHub Copilot menyelesaikan tugas membuat HTTP server dalam JavaScript 55,8% lebih cepat daripada kelompok kontrol, dengan interval kepercayaan 95% yang lebar, yaitu 21% sampai 89% (Peng et al., arXiv:2302.06590). Tugasnya greenfield, berdiri sendiri, dan dispesifikasikan dengan jelas. Itulah kondisi di mana percepatan muncul. Pelajarannya bukan "AI membuat semuanya lebih cepat." Pelajarannya adalah "AI cepat ketika inputnya kecil dan jelas." Gerbang yang menolak pekerjaan yang kabur atau terlalu besar sebelum ada kode yang dibuat adalah cara menciptakan kondisi itu dengan sengaja.

2. Developer tidak bisa merasakan apakah AI membantu. Itulah gerbang Evaluate. Uji coba METR memakai 16 developer open-source berpengalaman pada 246 tugas di repo yang mereka kenal baik. Menggunakan AI menambah waktu penyelesaian sebesar 19%, sementara para developer percaya AI telah membuat mereka lebih cepat (METR, arXiv:2507.09089). METR sendiri menyebutnya satu studi pada satu titik waktu, jadi jangan dibaca sebagai "AI itu lambat." Bacalah sebagai "perasaan Anda soal kecepatan tidak bisa diandalkan." Kalau orang yang mengerjakan saja tidak bisa tahu, satu-satunya cara untuk tahu adalah gerbang di akhir yang membandingkan hasil terukur dengan baseline.

3. AI memperkuat proses yang sudah Anda punya. Itulah gerbang Build. Laporan DORA 2025 menyatakan bahwa "peran utama AI adalah sebagai amplifier, memperbesar kekuatan dan kelemahan yang sudah ada di organisasi," dan bahwa hasil terbesar datang dari sistem organisasi, bukan dari tools (DORA 2025; lihat juga DORA AI Capabilities Model). Proses delivery yang rapuh ditambah AI menghasilkan proses delivery rapuh yang lebih cepat. Pemeriksaan yang berada di antara kode hasil generate dan branch utama, seperti tes, scan, permission, dan review manusia, adalah bagian proses yang ikut diperkuat. Kalau pemeriksaan itu lemah, AI menghasilkan lebih banyak kode yang tidak diperiksa. Kalau kuat, AI menghasilkan lebih banyak kode yang sudah diperiksa.

Kalau digabungkan: percepatan itu nyata dalam kondisi tertentu, tidak terlihat dalam kondisi lain, dan biaya kualitasnya muncul belakangan. Gerbang di setiap tahap adalah cara untuk menciptakan kondisi yang baik, menangkap biaya itu lebih awal, dan mengetahui apakah semuanya berhasil. Sisa artikel ini membahas ketiga gerbang itu tahap demi tahap: Plan, Build, Evaluate.

Tahap 1: Plan (Inception)

Seperti apa yang baik: rencana singkat, tertulis, dan disetujui manusia sebelum ada kode yang dibuat.

Dalam ADLC, di tahap inilah AI mengajukan pertanyaan dan tim menjawabnya. Tulisan AWS menggambarkan AI yang "membuat rencana kerja, mengajukan pertanyaan klarifikasi" dan baru mengimplementasikan setelah rencana divalidasi. Manusia yang memutuskan karena merekalah yang memegang konteks bisnis.

Beberapa kebiasaan praktis yang mengikuti dari situ (ini rekomendasi saya, dibangun dari sumber-sumber di atas):

• Biarkan AI mewawancarai Anda. Berikan niat bisnisnya dan minta AI mendaftar apa yang belum jelas. Jawab secara tertulis. Jawaban itu menjadi bagian dari konteks untuk setiap langkah berikutnya.
• Pecah menjadi unit kerja kecil. Satu unit harus bisa direview seseorang dalam sekali duduk. Kalau tidak bisa direview dengan cepat, unitnya terlalu besar.
• Tulis acceptance criteria sebelum kode. Buat yang bisa dicek: sebuah tes, sebuah query, perbandingan screenshot. "Berjalan dengan baik" bukan kriteria.
• Tentukan gerbangnya sekarang. Untuk setiap unit, tetapkan siapa menyetujui apa, dan apa yang tidak boleh disentuh agen (auth, billing, migration, config production).
• Simpan konteks dalam file. Spesifikasi, catatan arsitektur, dan konvensi coding harus ada di repo supaya agen bisa membacanya. Inilah bagian "context engineering" dari pabrik.

Kesalahan umum: melewati rencana karena agennya cepat. Menghasilkan hal yang salah dengan cepat tetap saja salah, dan sekarang ada lebih banyak yang harus direview.

Tahap 2: Build (Construction)

Seperti apa yang baik: bolt yang kecil, agen yang dibatasi, dan pemeriksaan otomatis yang berjalan sebelum manusia membaca satu baris pun.

Selama Construction, AI mengusulkan arsitektur, domain model, kode, dan tes, sementara tim memberi masukan pada keputusan teknis yang penting. Beberapa kebiasaan yang menjaga tahap ini tetap terkendali:

• Jaga setiap bolt tetap pendek dan terbatas. Satu unit kerja, satu branch, satu PR. Batch kecil membuat review mungkin dilakukan dan rollback jadi murah.
• Biarkan tes yang berargumen. Minta agen menulis tes dari acceptance criteria dulu, baru implementasinya. Kalau tes dan kode datang dari prompt yang sama tanpa pemeriksaan independen, tesnya mungkin hanya mengonfirmasi bug.
• Jalankan gerbang otomatis sebelum review. Lint, type check, tes, dan security scan harus menggagalkan PR sebelum ada orang yang menghabiskan waktu untuknya.
• Batasi permission. Agen mendapat akses minimum yang mereka butuhkan. Harness yang memutuskan "task ini mendapat tools ini" adalah persis yang digambarkan model pabrik.
• Review diff-nya, bukan perasaannya. Pemeriksaan otomatis memberi tahu bahwa kodenya berjalan. Hanya pembaca yang bisa memberi tahu bahwa kodenya melakukan hal yang benar. Manusia tetap bertanggung jawab atas setiap merge.

Kesalahan umum: membiarkan review menjadi stempel belaka. Ketika AI menghasilkan sepuluh PR sehari, review menjadi bottleneck, dan tekanan untuk membaca sekilas makin besar. Perbaiki pipeline-nya (PR yang lebih kecil, pemeriksaan otomatis yang lebih baik), bukan kesabaran reviewer.

Tahap 3: Evaluate (dan Operate)

Seperti apa yang baik: Anda mengukur hasil di tingkat sistem, dan kegagalan mengubah pabriknya, bukan hanya kodenya.

Inilah tahap yang paling sering dilewati tim, dan hasil METR adalah alasan mengapa tahap ini tidak boleh dilewati. Developer merasa lebih cepat padahal lebih lambat. Perasaan tidak bisa dipercaya di sini.

Apa yang diukur:

• Metrik delivery, bukan metrik aktivitas. Lead time, frekuensi deployment, change failure rate, waktu pemulihan. Jumlah baris kode dan "jumlah saran AI yang diterima" hanya memberi tahu soal pemakaian, bukan nilai.
• Kualitas berdampingan dengan kecepatan. Selalu tampilkan bug dan insiden di samping throughput. Pola Faros dari pembukaan artikel ini adalah hal yang ingin Anda tangkap lebih awal.
• Baseline. Catat angka Anda sebelum AI diterapkan ke sebuah tim. Tanpa baseline, Anda menebak-nebak persis seperti peserta METR.
• Eval untuk agennya sendiri. Simpan sekumpulan kecil tugas yang representatif dan jalankan setiap kali Anda mengubah prompt, model, atau file rules.
• Jangan anggap satu model cocok untuk semua tugas. Faros melaporkan bahwa rute model terbaik secara keseluruhan hanya menjadi yang terbaik pada 84 dari 211 tugas, jadi satu model default kemungkinan tidak optimal untuk segalanya.
• Umpan balik pasca-insiden ke dalam pabrik. Ketika perubahan yang ditulis agen merusak sesuatu, tanyakan gerbang mana yang seharusnya menangkapnya. Lalu perbaiki gerbangnya: tambah tes, perketat rule, perbarui file konteks. Faros menggambarkan ini sebagai kegagalan berulang yang dimasukkan kembali untuk memperbaiki sistem.
• Jejak audit. ADLC mencatat input, keputusan, dan respons di setiap fase. Ketika ada yang salah di production, Anda ingin tahu apa yang diberitahukan ke agen dan siapa yang menyetujuinya.

Kesalahan umum: hanya mengukur produktivitas individu. Poin amplifier dari DORA adalah soal organisasi. Kecepatan individu yang tidak muncul dalam stabilitas delivery bukanlah kemenangan.

Satu unit kerja melewati tiga gerbang

Supaya konkret, begini loop-nya untuk satu perubahan kecil. Contoh ini ilustrasi, bukan studi kasus.

Permintaannya. Tim produk meminta rate limit pada endpoint login. Terlalu banyak percobaan gagal dari satu tempat harus diblokir untuk sementara.

Plan. Tim memberikan niat bisnisnya ke agen dan meminta agen mendaftar apa yang belum jelas. Agen kembali dengan pertanyaan: berapa kali percobaan, dalam jendela waktu berapa lama, per IP atau per akun, apa yang dilihat klien saat diblokir, dan apakah admin tools yang juga memakai endpoint login ikut terdampak. Tim menjawab secara tertulis: 10 percobaan gagal per IP dalam 15 menit, balas dengan HTTP 429 dan header Retry-After, admin tools harus tetap berjalan. Jawaban itu menjadi acceptance criteria:

• Percobaan gagal ke-11 dari satu IP dalam 15 menit mengembalikan 429 dengan Retry-After.
• Login yang berhasil mereset penghitung untuk IP itu.
• Tes integrasi admin tool yang sudah ada tetap lulus.

Gerbangnya ditetapkan sekarang. Agen boleh mengubah auth middleware dan tesnya. Agen tidak boleh menyentuh session store, migration database, atau config production. Seorang backend lead menyetujui rencananya. Jawaban dan kriterianya disimpan di repo, di samping unit kerjanya.

Build. Satu bolt, satu branch, satu PR. Agen menulis tes dari tiga kriteria itu lebih dulu, dan seorang reviewer membacanya sebelum ada kode. Satu tes salah: tesnya mereset penghitung pada setiap percobaan login, bukan hanya yang berhasil. Reviewer memperbaikinya. Lalu agen menulis middleware-nya, dan lint, type check, tes, serta dependency scan lulus di PR. Reviewer membaca diff-nya, sekitar 80 baris, dan melihat bahwa penghitungnya disimpan di memori proses, yang akan gagal begitu service berjalan di dua instance. Itu celah di rencana, bukan bug di kode, jadi rencananya diperbarui untuk memakai Redis cache yang sudah ada, agen melakukan putaran kedua, dan PR di-merge.

Evaluate. Perubahannya dirilis. Dua hari kemudian, tim support melaporkan bahwa pengguna di balik jaringan kantor bersama ikut terblokir setelah beberapa rekan mereka salah mengetik password. Pertanyaan pasca-insidennya: gerbang mana yang seharusnya menangkap ini? Jawabannya Plan. "Per IP" adalah satuan yang salah untuk jaringan bersama, dan tidak ada yang bertanya soal kasus itu. Perbaikan untuk pabriknya adalah satu baris di bagian auth pada file konteks: "rate limit harus menangani IP bersama", ditambah satu pertanyaan klarifikasi permanen untuk setiap pekerjaan auth di masa depan. Catatan insidennya menautkan rencana awal, tanya jawabnya, dan persetujuannya, sehingga jejak auditnya lengkap. Di dashboard tim, unit ini menunjukkan lead time satu hari dan satu change failure, berdampingan dengan baseline yang dicatat sebelum tim mulai memakai agen.

Itulah seluruh loop-nya. Perhatikan apa yang dilakukan tiap gerbang. Plan mengubah permintaan yang kabur menjadi tiga kriteria yang bisa dicek dan satu daftar larangan. Build menangkap satu tes yang salah dan satu celah desain sebelum merge. Evaluate mengubah satu hal yang lolos menjadi perbaikan permanen pada gerbang Plan, sehingga perubahan auth berikutnya mulai dari posisi yang lebih baik.

Checklist sederhana

Kalau Anda hanya punya waktu untuk memulai satu hal: buat baseline dan ukur kualitas berdampingan dengan kecepatan. Semua yang lain jadi lebih mudah begitu Anda bisa melihat apa yang sebenarnya dihasilkan pabrik Anda.

Yang tidak akan saya klaim

• Bahwa AI membuat setiap tim lebih cepat. Buktinya campur aduk, dan studi-studi paling terkenal menunjuk ke arah berbeda tergantung tugas dan developernya.
• Bahwa ADLC sudah terbukti dalam skala besar. Tulisan AWS menawarkan metode dan klaim "dari minggu menjadi hari", bukan hasil independen.
• Bahwa satu pun metrik di atas bersifat kausal. Sebagian besar data industri bersifat korelasional, dan beberapa sumbernya adalah vendor.

Kesimpulan yang berguna lebih sempit dan, menurut saya, lebih tahan lama: AI memperkuat proses Anda. Buat prosesnya layak diperkuat.

Referensi

1. Peng, S., Kalliamvakou, E., Cihon, P., Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590. https://arxiv.org/abs/2302.06590
2. METR (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. https://arxiv.org/abs/2507.09089
3. DORA (2025). State of AI-assisted Software Development. https://dora.dev/research/2025/dora-report/
4. DORA (2025). AI Capabilities Model. https://dora.dev/ai/capabilities-model/report/
5. AWS DevOps & Developer Productivity Blog (Juli 2025). AI-Driven Development Life Cycle. https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/
6. AWS Labs. aidlc-workflows (rules workflow AI-DLC open-source). https://github.com/awslabs/aidlc-workflows
7. Faros AI. What is a software factory? (sumber vendor; baca dengan mengingat hal itu). https://www.faros.ai/blog/software-factory