DEV Community

Cover image for Software Factory : Plan, Build, dan Evaluate dengan AI dalam ADLC
Rangga Aprilio Utama
Rangga Aprilio Utama

Posted on

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

#ai #productivity #programming

AI sekarang bisa membantu kita menulis kode jauh lebih cepat. Tapi ada satu pertanyaan yang sering terlupakan:

Apakah kita benar-benar menjadi lebih cepat, atau hanya menghasilkan lebih banyak kode?

Beberapa penelitian menunjukkan bahwa jawabannya tidak sesederhana “AI = lebih produktif”. Dalam satu studi METR, developer berpengalaman yang menggunakan AI justru membutuhkan waktu sekitar 19% lebih lama, meskipun mereka merasa pekerjaan mereka menjadi lebih cepat.

Di sisi lain, laporan lain menunjukkan bahwa penggunaan AI yang lebih tinggi bisa meningkatkan jumlah task yang selesai, tetapi juga diikuti peningkatan bug dan incident.

Jadi masalahnya bukan sekadar bagaimana membuat AI menulis kode lebih cepat.

Masalah sebenarnya adalah:

Bagaimana kita membuat sistem yang memastikan AI mengerjakan hal yang benar, dengan cara yang benar, dan hasilnya benar-benar bisa dipercaya?

Di sinilah konsep Software Factory menjadi menarik.

1. Apa Itu Software Factory?

Bayangkan kita memiliki sebuah pabrik.

Sebuah pabrik yang baik tidak hanya punya mesin yang cepat. Ia juga punya:

  • bahan baku yang jelas,
  • proses kerja yang teratur,
  • aturan keselamatan,
  • quality control,
  • dan pemeriksaan sebelum produk dikirim.

Konsep yang sama bisa diterapkan pada software development dengan AI.

Software Factory adalah sistem yang menggabungkan:

  • AI agents,
  • engineering tools,
  • knowledge dan context,
  • workflow otomatis,
  • automated verification,
  • dan human review.

Tujuannya adalah membawa sebuah pekerjaan dari:

Business Request
      ↓
     Plan
      ↓
     Build
      ↓
   Evaluate
      ↓
   Release
Enter fullscreen mode Exit fullscreen mode

Yang menarik, peran developer juga berubah.

Kita mungkin menulis lebih sedikit kode secara manual, tetapi justru harus lebih banyak memikirkan:

  • requirement,
  • acceptance criteria,
  • architecture,
  • context untuk AI,
  • permission,
  • testing,
  • evaluation,
  • dan edge cases.

Jadi bukan berarti manusia tidak dibutuhkan.

Manusia berpindah dari “penulis kode utama” menjadi orang yang mendesain dan mengontrol sistem produksinya.

2. Di Mana Posisi ADLC?

AWS memperkenalkan konsep AI-Driven Development Life Cycle (AI-DLC) yang menempatkan AI di tengah proses development, sementara manusia tetap memegang keputusan penting.

Secara sederhana, ada tiga fase:

┌──────────────┐
│   Inception  │
│     PLAN     │
└──────┬───────┘
       ↓
┌──────────────┐
│ Construction │
│     BUILD    │
└──────┬───────┘
       ↓
┌──────────────┐
│  Operations  │
│   EVALUATE   │
└──────────────┘
Enter fullscreen mode Exit fullscreen mode

Inception / Plan

AI membantu:

  • memahami kebutuhan,
  • mengajukan pertanyaan,
  • membuat requirement,
  • membuat unit kerja.

Manusia:

  • menjawab pertanyaan,
  • memvalidasi requirement,
  • menentukan keputusan bisnis.

Construction / Build

AI membantu:

  • membuat architecture proposal,
  • membuat domain model,
  • menulis kode,
  • membuat test.

Manusia:

  • memvalidasi keputusan teknis,
  • melakukan review,
  • menentukan apakah hasil boleh masuk ke branch utama.

Operations / Evaluate

AI membantu:

  • deployment,
  • infrastructure,
  • monitoring,
  • analisis hasil.

Manusia:

  • mengawasi production,
  • mengevaluasi hasil,
  • mengambil keputusan jika terjadi masalah.

Kalau disederhanakan:

ADLC adalah blueprint prosesnya. Software Factory adalah mesin dan quality control yang menjalankan blueprint tersebut.

3. Kenapa “Gerbang” Sangat Penting?

Bayangkan AI bisa menghasilkan 10 PR dalam sehari.

Kedengarannya luar biasa.

Tapi kalau tidak ada pemeriksaan yang baik, kita juga bisa mendapatkan:

10 PR
 ↓
10x kode
 ↓
10x sesuatu yang harus direview
 ↓
lebih banyak bug
 ↓
lebih banyak incident
Enter fullscreen mode Exit fullscreen mode

Jadi semakin cepat AI bekerja, semakin penting sistem quality control kita.

Ada tiga hal penting yang bisa kita pelajari dari berbagai penelitian.

3.1 AI sangat bagus untuk task yang jelas

AI cenderung bekerja lebih baik ketika task:

  • kecil,
  • spesifik,
  • punya requirement yang jelas,
  • dan punya acceptance criteria yang bisa diperiksa.

Artinya, jangan memberikan AI task seperti:

“Buatkan authentication system.”

Lebih baik:

“Tambahkan rate limiting pada endpoint /login. Batasi 10 percobaan gagal per IP dalam 15 menit. Setelah melewati batas, return HTTP 429 dengan Retry-After.”

Task kedua jauh lebih mudah untuk diverifikasi.

Jadi:

AI cepat ketika input-nya jelas.

Inilah alasan gerbang Plan penting.

3.2 Kita tidak selalu bisa merasakan apakah AI benar-benar membantu

Ini bagian yang cukup menarik.

Dalam studi METR, developer berpengalaman merasa mereka bekerja lebih cepat dengan AI. Tetapi ketika waktu sebenarnya diukur, mereka justru membutuhkan waktu lebih lama.

Artinya:

Perasaan kita tentang produktivitas tidak selalu akurat.

Karena itu kita membutuhkan tahap Evaluate.

Jangan hanya bertanya:

“Apakah developer merasa lebih produktif?”

Tapi ukur:

  • lead time,
  • deployment frequency,
  • change failure rate,
  • recovery time,
  • bug,
  • incident,
  • dan kualitas software.

3.3 AI memperkuat proses yang sudah kita punya

AI adalah amplifier.

Kalau proses kita bagus:

Good Process
     +
     AI
     ↓
Better / Faster Process
Enter fullscreen mode Exit fullscreen mode

Tapi kalau proses kita buruk:

Bad Process
     +
     AI
     ↓
Bad Process, but Faster
Enter fullscreen mode Exit fullscreen mode

Misalnya proses review kita sudah buruk.

Sebelum AI:

5 PR / hari
↓
review asal-asalan
Enter fullscreen mode Exit fullscreen mode

Setelah menggunakan AI:

30 PR / hari
↓
review tetap asal-asalan
Enter fullscreen mode Exit fullscreen mode

Kita bukan menyelesaikan masalah.

Kita hanya memperbesar masalah.

4. Gerbang Pertama: PLAN

Tujuan

Sebelum AI menulis kode, kita harus memastikan AI memahami apa yang sebenarnya harus dibuat.

Output dari tahap Plan sebaiknya bukan dokumen 50 halaman.

Justru sebaliknya:

Buat plan yang singkat, jelas, dan bisa divalidasi manusia.

4.1 Biarkan AI Bertanya

Daripada langsung berkata:

“Implementasikan fitur X.”

Berikan business intent terlebih dahulu.

Misalnya:

“Kami ingin membatasi brute-force attack pada login.”

Kemudian minta AI mencari hal-hal yang masih belum jelas.

Contohnya:

Berapa maksimal percobaan?

Dalam berapa menit?

Rate limit berdasarkan apa?

- IP?
- User?
- Device?

Apa response ketika diblokir?

Apakah admin tool ikut terkena?

Bagaimana behavior setelah login berhasil?
Enter fullscreen mode Exit fullscreen mode

Pertanyaan-pertanyaan tersebut kemudian dijawab oleh manusia.

Jawaban itu menjadi bagian dari context.

4.2 Pecah Pekerjaan Menjadi Unit Kecil

Jangan membuat satu task yang terlalu besar.

Lebih baik:

1 Unit of Work
      ↓
1 Branch
      ↓
1 PR
      ↓
1 Review
Enter fullscreen mode Exit fullscreen mode

Kenapa?

Karena semakin kecil unit kerja:

  • semakin mudah direview,
  • semakin mudah dites,
  • semakin murah rollback,
  • semakin mudah mencari sumber masalah.

Rule sederhana:

Kalau seseorang tidak bisa memahami dan mereview task dalam satu sesi, kemungkinan task tersebut terlalu besar.

4.3 Buat Acceptance Criteria Sebelum Coding

Jangan menggunakan:

“Fitur harus berjalan dengan baik.”

Itu terlalu subjektif.

Buat sesuatu yang bisa dicek.

Contoh:

Given:
IP tertentu melakukan login gagal

When:
Percobaan gagal mencapai percobaan ke-11
dalam waktu 15 menit

Then:
API harus mengembalikan HTTP 429
dan header Retry-After
Enter fullscreen mode Exit fullscreen mode

Dengan begitu AI tahu apa yang harus dibuat.

Dan reviewer tahu apa yang harus diperiksa.

4.4 Tentukan Permission dari Awal

AI agent seharusnya tidak memiliki akses ke semua hal.

Misalnya untuk task authentication:

ALLOW
├── auth middleware
└── authentication tests

DENY
├── production config
├── database migration
└── session store
Enter fullscreen mode Exit fullscreen mode

Prinsipnya sederhana:

Agent hanya mendapatkan permission yang benar-benar dibutuhkan untuk task tersebut.

4.5 Simpan Context di Repository

Jangan mengandalkan AI untuk “ingat” semua aturan.

Simpan informasi penting di repository:

repository/
├── docs/
│   ├── architecture.md
│   └── specifications/
│
├── AGENTS.md
├── CONTRIBUTING.md
└── ...
Enter fullscreen mode Exit fullscreen mode

Isi context bisa berupa:

  • coding conventions,
  • architecture rules,
  • business rules,
  • testing strategy,
  • API conventions,
  • security rules.

Dengan begitu AI tidak mulai dari nol setiap kali mengerjakan task.

5. Gerbang Kedua: BUILD

Setelah plan disetujui, baru AI masuk ke tahap implementasi.

Tujuannya bukan:

“Biarkan AI coding sebebas mungkin.”

Justru sebaliknya:

Berikan AI ruang kerja yang kecil dan terkontrol.

5.1 Gunakan Bolt yang Kecil

Istilah Bolt di definisikan sebagai unit pekerjaan kecil yang memiliki scope jelas dan bisa diselesaikan secara independen.

Idealnya:

1 Unit of Work
       ↓
1 Branch
       ↓
1 PR
Enter fullscreen mode Exit fullscreen mode

Jangan biarkan satu agent mengubah 50 bagian sistem sekaligus.

Semakin kecil perubahan:

  • semakin mudah direview,
  • semakin mudah di-debug,
  • semakin mudah di-rollback.

5.2 Test Harus Berasal dari Acceptance Criteria

Salah satu pendekatan yang menarik adalah:

Acceptance Criteria
       ↓
     Tests
       ↓
Implementation
Enter fullscreen mode Exit fullscreen mode

Bukan:

Prompt
  ↓
AI writes code
  ↓
AI writes tests
Enter fullscreen mode Exit fullscreen mode

Kenapa?

Kalau kode dan test dibuat oleh AI dari konteks yang sama tanpa pemeriksaan independen, ada risiko test hanya “membenarkan” implementasi yang salah.

Test seharusnya menjadi representasi dari requirement.

5.3 Automated Gate Harus Jalan Sebelum Human Review

Sebelum reviewer membaca kode, jalankan:

PR
 ↓
Lint
 ↓
Type Check
 ↓
Unit Test
 ↓
Integration Test
 ↓
Security Scan
 ↓
Human Review
Enter fullscreen mode Exit fullscreen mode

Kalau salah satu gagal:

❌ STOP
Enter fullscreen mode Exit fullscreen mode

Jangan buang waktu reviewer untuk PR yang bahkan belum lolos pemeriksaan dasar.

5.4 Review Diff, Bukan Perasaan

AI bisa menghasilkan kode yang terlihat sangat bagus.

Tetapi:

Kode yang terlihat bagus belum tentu melakukan hal yang benar.

Automated test membantu menjawab:

“Apakah kode ini bekerja?”

Human review menjawab:

“Apakah kode ini melakukan hal yang benar dan sesuai architecture kita?”

Keduanya berbeda.

6. Gerbang Ketiga: EVALUATE

Ini adalah bagian yang sering dilewati.

Setelah kode di-merge dan di-deploy, kita harus melihat hasil sebenarnya.

Bukan berdasarkan feeling.

Tapi berdasarkan data.

6.1 Ukur Delivery, Bukan Aktivitas AI

Jangan hanya mengukur:

Berapa banyak kode yang dibuat AI?
Berapa banyak suggestion AI yang diterima?
Berapa banyak PR yang dibuat?
Enter fullscreen mode Exit fullscreen mode

Angka tersebut hanya menunjukkan aktivitas.

Lebih berguna mengukur:

Lead Time
Deployment Frequency
Change Failure Rate
Recovery Time
Bug
Incident
Enter fullscreen mode Exit fullscreen mode

6.2 Kecepatan Harus Dilihat Bersama Kualitas

Misalnya:

Before AI

10 deployment
2 bugs
1 incident
Enter fullscreen mode Exit fullscreen mode

Setelah AI:

20 deployment
8 bugs
5 incidents
Enter fullscreen mode Exit fullscreen mode

Apakah kita menjadi lebih produktif?

Belum tentu.

Kita memang mengirim lebih banyak perubahan.

Tapi kualitasnya memburuk.

Karena itu:

Throughput tanpa quality bukan kemenangan.

6.3 Buat Baseline

Sebelum menerapkan AI secara besar-besaran, ukur kondisi sekarang.

Contoh:

Lead Time          : 3 hari
Deployment/Week    : 10
Change Failure     : 8%
Critical Bugs      : 3
Enter fullscreen mode Exit fullscreen mode

Setelah menggunakan AI, bandingkan:

Lead Time          : 1.5 hari
Deployment/Week    : 18
Change Failure     : 9%
Critical Bugs      : 4
Enter fullscreen mode Exit fullscreen mode

Sekarang kita punya data untuk menilai dampaknya.

Tanpa baseline, kita hanya menebak.

6.4 Evaluasi Agent-nya Juga

Agent adalah bagian dari sistem.

Jadi agent juga harus dievaluasi.

Buat kumpulan task yang representatif:

Evaluation Dataset
├── Authentication
├── CRUD
├── Database query
├── API integration
├── Refactoring
└── Bug fixing
Enter fullscreen mode Exit fullscreen mode

Kemudian jalankan kembali ketika kita mengubah:

  • model,
  • prompt,
  • agent rules,
  • tools,
  • context,
  • workflow.

Dengan begitu kita tahu apakah perubahan tersebut benar-benar membuat agent lebih baik.

7. Satu Contoh dari Awal Sampai Akhir

Misalnya product team meminta:

“Tambahkan rate limiting untuk login.”

PLAN

AI bertanya:

Berapa maksimal percobaan?

Berapa lama window-nya?

Rate limit berdasarkan IP atau account?

Apa response ketika diblokir?

Bagaimana dengan admin tools?
Enter fullscreen mode Exit fullscreen mode

Tim menjawab:

10 failed attempts
per IP
dalam 15 menit

Response:
HTTP 429
Retry-After header

Admin tools harus tetap bekerja.
Enter fullscreen mode Exit fullscreen mode

Acceptance criteria:

1. Percobaan gagal ke-11 → HTTP 429
2. Response memiliki Retry-After
3. Login berhasil → counter reset
4. Existing admin integration test tetap pass
Enter fullscreen mode Exit fullscreen mode

Permission:

Agent boleh:
- auth middleware
- authentication tests

Agent tidak boleh:
- production config
- database migration
- session store
Enter fullscreen mode Exit fullscreen mode

BUILD

Agent membuat:

Branch
 ↓
Tests
 ↓
Implementation
 ↓
Lint
 ↓
Type Check
 ↓
Integration Test
 ↓
Security Scan
 ↓
PR
Enter fullscreen mode Exit fullscreen mode

Reviewer menemukan:

Counter disimpan di memory aplikasi.

Masalahnya:

Instance A → counter = 5
Instance B → counter = 0
Enter fullscreen mode Exit fullscreen mode

Kalau aplikasi berjalan di beberapa instance, rate limit tidak konsisten.

Maka plan diperbaiki:

Memory
  ↓
Redis
Enter fullscreen mode Exit fullscreen mode

Agent melakukan perubahan.

PR kemudian di-merge.

EVALUATE

Dua hari kemudian ada laporan:

“User kantor terkena rate limit karena banyak orang menggunakan IP yang sama.”

Ternyata requirement:

rate limit berdasarkan IP
Enter fullscreen mode Exit fullscreen mode

tidak mempertimbangkan shared network.

Masalahnya bukan hanya di kode.

Masalahnya ada di Plan.

Maka kita memperbaiki sistem:

Auth Context

Rule baru:
"Pertimbangkan shared IP/network."

+

Clarification question baru:
"Apakah user dapat berbagi IP?"
Enter fullscreen mode Exit fullscreen mode

Sekarang failure tersebut menjadi pengetahuan untuk pekerjaan berikutnya.

Inilah inti Software Factory.

Kegagalan tidak hanya diperbaiki di kode.

Kegagalan digunakan untuk memperbaiki pabriknya.

8. Jadi Apa Sebenarnya Peran Manusia?

Dengan semua otomatisasi ini, apakah developer akan hilang?

Menurut saya, bukan itu yang terjadi.

Peran developer justru bergeser.

Dari:

Write Code
Enter fullscreen mode Exit fullscreen mode

menjadi:

Define Problem
       ↓
Define Constraints
       ↓
Define Acceptance Criteria
       ↓
Design System
       ↓
Control Agents
       ↓
Evaluate Result
       ↓
Improve Process
Enter fullscreen mode Exit fullscreen mode

Kita mungkin menulis lebih sedikit kode.

Tetapi kita harus lebih baik dalam:

  • system design,
  • requirement analysis,
  • architecture,
  • testing,
  • security,
  • observability,
  • dan decision making.

9. Checklist Sederhana

PLAN

Sebelum lanjut, pastikan ada:

  • [ ] Business intent yang jelas
  • [ ] Pertanyaan klarifikasi sudah dijawab
  • [ ] Unit kerja cukup kecil
  • [ ] Acceptance criteria bisa diverifikasi
  • [ ] Permission agent sudah ditentukan
  • [ ] Area yang tidak boleh disentuh sudah jelas
  • [ ] Context tersedia di repository

BUILD

Pastikan:

  • [ ] Satu unit kerja → satu branch
  • [ ] Test berasal dari acceptance criteria
  • [ ] Lint berhasil
  • [ ] Type check berhasil
  • [ ] Test berhasil
  • [ ] Security scan berhasil
  • [ ] Human review dilakukan
  • [ ] Diff tetap kecil dan mudah dipahami

EVALUATE

Pastikan:

  • [ ] Sudah memiliki baseline
  • [ ] Lead time diukur
  • [ ] Deployment frequency diukur
  • [ ] Change failure rate diukur
  • [ ] Incident dan bug diukur
  • [ ] Agent memiliki evaluation set
  • [ ] Feedback dari incident masuk kembali ke workflow
  • [ ] Ada audit trail

10. Kesimpulan

AI membuat kita bisa menghasilkan software lebih cepat.

Tetapi:

Menghasilkan kode lebih cepat tidak sama dengan menghasilkan software yang lebih baik.

Kalau kita memasukkan AI ke dalam proses development yang buruk, kita hanya mendapatkan proses buruk yang berjalan lebih cepat.

Karena itu, kita membutuhkan gerbang.

                 SOFTWARE FACTORY

Business Intent
      │
      ▼
┌──────────────┐
│     PLAN     │
│              │
│ Apa yang     │
│ sebenarnya   │
│ harus dibuat?│
└──────┬───────┘
       │
       ▼
┌──────────────┐
│    BUILD     │
│              │
│ Apakah kita  │
│ membuatnya    │
│ dengan benar?│
└──────┬───────┘
       │
       ▼
┌──────────────┐
│   EVALUATE   │
│              │
│ Apakah hasil │
│ akhirnya     │
│ benar-benar  │
│ lebih baik?  │
└──────┬───────┘
       │
       └──────────────┐
                      │
                      ▼
                Improve Factory
Enter fullscreen mode Exit fullscreen mode

Plan memastikan kita mengerjakan hal yang benar.

Build memastikan kita mengerjakannya dengan benar.

Evaluate memastikan hasilnya benar-benar memberikan nilai.

Dan yang paling penting:

Ketika terjadi kegagalan, jangan hanya memperbaiki kodenya. Perbaiki juga gerbang yang seharusnya menangkap kegagalan tersebut.

Itulah yang membuat Software Factory menjadi sistem yang terus belajar.

Referensi

  1. Peng, S., Kalliamvakou, E., Cihon, P., Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.
  2. METR (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.
  3. DORA (2025). State of AI-assisted Software Development.
  4. DORA (2025). AI Capabilities Model.
  5. AWS DevOps & Developer Productivity Blog (2025). AI-Driven Development Life Cycle.
  6. AWS Labs. aidlc-workflows.
  7. Faros AI. What is a Software Factory?

Top comments (0)