Designing Software for Software Factories: Era AI-Native Engineering

Sejak publikasi tentang AI-powered Software Engineering pada 2024, jendela overton telah bergeser dari apakah AI bisa membantu software development menjadi bagian mana yang masih memerlukan intervensi manusia. Di banyak perusahaan tech, tim engineering mulai membangun apa yang disebut sebagai software factory. Sistem ini adalah kombinasi dari AI-driven automation dan organisasi yang mengelilinginya untuk mengubah stream customer request menjadi software yang sudah di-deploy. Artikel ini membahas prinsip desain, tantangan, dan metrik yang relevan untuk membangun software factory yang efektif.

Menurut tulisan dari blog sshh.io yang berjudul Designing Software for Software Factories, definisi software factory bervariasi tergantung siapa yang ditanya. Penulis mendefinisikannya sebagai sistem yang didorong AI beserta organisasi yang mengelilinginya, yang mampu mensolution, mendesign, membangun, mengetest, dan mendeploy produk software. Ini adalah salah satu dari banyak loop yang harus dikembangkan oleh perusahaan AI-native modern sebagai bagian dari operasi EPD (Engineering, Product, Design).

Prinsip Wajib Software Factory

Software factory yang lengkap harus memenuhi beberapa prinsip ketat. Pertama, sistem harus mampu beroperasi pada raw distribution of customer generated RFEs dan bug reports sebagai input. Ini berarti tidak boleh ada Product Manager yang perlu menscope setiap tiket atau engineer yang harus memecah solution menjadi bagian lebih kecil. AI harus bisa menangani input yang tidak terstruktur dan mengubahnya menjadi plan of action yang konkret. Kemampuan ini memisahkan software factory yang benar-benar autonom dari sekadar workflow automation yang memerlukan banyak preprocessing manual.

Kedua, sistem hanya boleh memerlukan manusia untuk off-ramping (menekan tombol stop merah) dan review pada stage tertentu. Tidak boleh ada explicit pairing step di mana manusia dan AI bekerja berdampingan untuk setiap task. Pairing sesekali boleh terjadi, tetapi sebagai exception, bukan norma. Ketiga, setiap review yang dilakukan harus di-feed back ke sistem sehingga review gate secara bertahap bisa mengdeprecate dirinya sendiri. Jika review hanya berlaku untuk instance software generation tertentu, sistem tidak akan belajar dan tidak akan menjadi lebih baik dari waktu ke waktu. Keempat, sistem harus mampu menjalankan banyak request secara konkuren, bukan satu per satu. Jika request harus diserialisasi karena stage-stage berbagi mutable state, throughput akan terbatas oleh resource manusia, bukan oleh compute budget.

Metrik Efektivitas Software Factory

Untuk mengukur first-order efficacy dari software factory, penulis menyarankan beberapa metrik utama. Cycle time adalah wall time dari customer request sampai deploy, atau per stage. Metrik ini mengukur seberapa cepat sistem merespons perubahan kebutuhan. Review volume adalah seberapa banyak feedback yang diberikan pada output yang di-draft oleh AI per stage. Semakin tinggi review volume, semakin banyak intervensi manusia yang masih diperlukan, yang berarti sistem belum cukup matang. Goal jangka panjang adalah menurunkan review volume ke level minimum sambil tetap menjaga kualitas output.

Kedua metrik ini harus diukur per stage, bukan hanya secara end-to-end. Dengan memecah metrik per stage, tim bisa mengidentifikasi bottleneck spesifik. Misalnya, stage testing mungkin memerlukan review volume yang tinggi karena AI belum cukup baik dalam menulis test cases yang komprehensif. Identifikasi bottleneck ini memungkinkan tim untuk fokus improvement pada area yang paling berdampak.

Tantangan Implementasi Nyata

Membangun software factory di dunia nyata menghadirkan tantangan yang tidak terduga. Salah satu yang terbesar adalah mengelola mutable state yang terbagi. Jika ada satu test environment, satu staging branch, atau satu deploy slot, request harus diserialisasi. Ini merusak salah satu prinsip utama: konkuren execution. Solusi untuk ini sering kali melibatkan ephemeral environments yang di-spin up untuk setiap request, atau branch-based isolation yang memungkinkan banyak request diproses secara paralel tanpa saling mengganggu.

Tantangan lain adalah memastikan feedback loop yang efektif. Ketika reviewer manusia memberikan feedback, feedback itu harus disimpan dalam format yang bisa dikonsumsi oleh AI untuk improvement berikutnya. Ini memerlukan standardisasi format review dan integrasi yang rapat antara review system dengan training atau fine-tuning pipeline. Tanpa feedback loop yang efektif, software factory akan stagnasi dan tidak akan mencapai tingkat autonomi yang diharapkan.

Tantangan ketiga adalah trust. Tim engineering dan stakeholder product harus percaya bahwa output dari software factory memenuhi standar kualitas. Membangun trust ini memerlukan transparansi: sistem harus bisa menjelaskan apa yang dibangun, mengapa membuat keputusan tertentu, dan bagaimana menangani edge cases. Auditability menjadi fitur kritis, bukan afterthought. Tanpa trust, organisasi akan terjebak dalam cycle dimana setiap output harus di-review secara manual, yang mengalahkan tujuan dari software factory itu sendiri.

Implikasi untuk Tim Engineering

Software factory mengubah role dari engineer secara fundamental. Engineer tidak lagi menghabiskan sebagian besar waktu untuk menulis kode, melainkan untuk mendesign sistem, mengawasi operasi, mengaudit output, dan mengelola feedback loop. Ini adalah transisi dari craftsman individual contributor ke systems operator dan quality assurance specialist. Perubahan ini bisa memicu resistensi, terutama dari engineer yang mendefinisikan identitas profesional mereka melalui kemampuan coding manual. Organisasi yang sukses dalam transisi ini akan memberikan training dan support yang memadai untuk membantu tim beradaptasi.

Role Product Manager juga berubah. PM tidak lagi menscope tiket individual, melainkan mengelola backlog of unscoped requests dan memastikan bahwa software factory memiliki akses ke context yang cukup untuk membuat keputusan yang tepat. Ini memerlukan kemampuan baru dalam data analysis dan strategic thinking. PM yang hanya fokus pada tactical execution akan kesulitan beradaptasi dengan model baru ini.

Software factory adalah evolusi alami dari software engineering di era AI. Organisasi yang berhasil membangunnya akan menikmati keunggulan kompetitif yang signifikan dalam kecepatan inovasi dan responsiveness terhadap kebutuhan customer. Namun, perjalanan menuju sana tidak mudah. Memerlukan investasi besar dalam infrastruktur, perubahan budaya, dan kemauan untuk mengulang iterasi demi iterasi sampai sistem mencapai level autonomi yang memadai.

Sumber utama artikel ini berdasarkan tulisan dari blog.sshh.io: Designing Software for Software Factories. Untuk pemahaman lebih lanjut tentang transisi organisasi di era AI, kunjungi juga tulisan dari penulis yang sama tentang The Transposed Organization.