- Tim AI StrongDM mengusulkan konsep Software Factory yang menghasilkan perangkat lunak berkualitas tinggi tanpa perlu melihat kode
- Berdasarkan spesifikasi/skenario, agen menulis kode, menjalankan harness pengujian, dan melakukan konvergensi tanpa peninjauan manusia dalam metode pengembangan non-interaktif
- Kode tidak boleh ditulis atau ditinjau oleh manusia, dan Software Factory hanya akan berfungsi dengan baik jika menghabiskan biaya token minimal lebih dari 1.000 dolar per engineer per hari
- Sejak Claude 3.5 revisi kedua (Oktober 2024), workflow coding agen jangka panjang mulai mengakumulasi akurasi secara majemuk alih-alih menumpuk kesalahan, sehingga kemungkinan pengembangan non-interaktif mulai terbukti
- Dengan memperluas konsep pengujian yang ada, mereka memperkenalkan scenario dan satisfaction, membangun sistem di mana LLM menilai kepuasan pengguna secara probabilistik
- Melalui Digital Twin Universe (DTU), layanan SaaS utama seperti Okta, Jira, dan Slack direplikasi untuk melakukan verifikasi skala besar, sehingga validasi skenario dapat dilakukan pada volume dan kecepatan yang melampaui batas produksi
- Era agen secara fundamental mengubah ekonomi perangkat lunak, sehingga membangun replika SaaS berketelitian tinggi yang dulu tidak masuk akal secara ekonomi kini menjadi pekerjaan rutin
Konsep Software Factory
- Specs dan scenarios menggerakkan agen untuk menulis dan memverifikasi kode dalam sistem pengembangan non-interaktif
- Penulisan dan review kode oleh manusia dilarang, dan seluruh proses pengembangan dijalankan oleh agen
- Efisiensi diukur dengan patokan penggunaan token lebih dari 1.000 dolar per engineer per hari
- Pendekatan ini bertujuan membangun lingkungan produksi perangkat lunak otonom di mana kode dihasilkan, diverifikasi, dan dikonvergensikan secara otomatis tanpa campur tangan manusia
Peluncuran tim AI StrongDM
- Pada 14 Juli 2025, tim AI StrongDM dibentuk untuk memulai eksperimen pengembangan non-interaktif
- Peserta: Jay Taylor, Navan Chauhan, Justin McCarthy(co-founder sekaligus CTO)
- Sejak akhir 2024, setelah Claude 3.5 (revisi Oktober), akurasi penulisan kode jangka panjang meningkat, sehingga compounding correctness menjadi mungkin alih-alih akumulasi kesalahan berulang
- Melalui mode YOLO di Cursor, kemampuan model dalam penulisan kode jangka panjang terlihat jelas
- Pada model sebelumnya, ketika LLM diterapkan berulang kali pada tugas coding, berbagai kesalahan seperti salah paham, halusinasi, error sintaks, pelanggaran version DRY, dan inkompatibilitas library terus menumpuk hingga aplikasi "runtuh"
- Kombinasi model Anthropic yang diperbarui dan mode YOLO memperlihatkan kemungkinan awal dari pengembangan non-interaktif atau perangkat lunak yang ditumbuhkan
Prinsip inti: lepas tangan
- Pada jam pertama hari pertama tim AI, sebuah piagam dibuat, dan prinsip terpentingnya adalah: "kode tidak boleh ditulis langsung oleh manusia"
- Pada awalnya ini hanyalah intuisi dan eksperimen sederhana: seberapa jauh mereka bisa melangkah tanpa menulis kode sama sekali dengan tangan
- Awalnya mereka menemui batas, lalu mulai membuat kemajuan setelah menambahkan pengujian
- Agen terobsesi pada tugas langsung dan memilih jalan pintas: pengujian yang ditulis terlalu sempit bisa lolos hanya dengan return true, tetapi tidak tergeneralisasi menjadi perangkat lunak yang benar-benar diinginkan
- Pengujian sederhana saja tidak cukup; perlu diperluas ke integration test, regression test, end-to-end test, dan behavioral test
Beralih dari test ke scenario dan satisfaction
- Tema berulang di era agen: dibutuhkan bahasa baru, karena kata "test" tidak memadai dan ambigu
- Test yang disimpan di codebase bisa ditulis ulang secara malas agar sesuai dengan kode, atau kode bisa ditulis ulang agar sekadar lolos test secara sepele
- Istilah scenario didefinisikan ulang: mewakili user story end-to-end, disimpan di luar codebase (mirip set "holdout" dalam pelatihan model), dapat dipahami secara intuitif oleh LLM, dan diverifikasi secara fleksibel
- Karena perangkat lunak yang ditumbuhkan itu sendiri mencakup komponen agen, evaluasi keberhasilan bergeser dari sekadar nilai boolean ke satisfaction yang bersifat probabilistik dan empiris
- Satisfaction: mengukur proporsi lintasan teramati yang lolos semua scenario dan kemungkinan besar benar-benar memuaskan pengguna
Validasi scenario melalui Digital Twin Universe
- Dalam rezim sebelumnya, integration test, regression test, dan otomasi UI dipakai untuk menentukan "apakah ini bekerja?"
- Mereka menemukan dua keterbatasan dari teknik yang sebelumnya dianggap andal:
- Test terlalu kaku: karena coding dilakukan dengan agen dan loop LLM + agen dibangun sebagai primitif desain, evaluasi keberhasilan sering kali memerlukan LLM-as-judge
- Test rentan terhadap reward hacking: dibutuhkan validasi yang lebih tahan terhadap kecurangan model
- Digital Twin Universe (DTU) menjadi jawabannya: klon perilaku dari layanan pihak ketiga yang menjadi dependensi perangkat lunak
- Mereka membangun twin untuk Okta, Jira, Slack, Google Docs, Google Drive, dan Google Sheets, mereplikasi API, edge case, dan perilaku yang dapat diamati
- Dengan DTU, validasi dapat dilakukan pada volume dan kecepatan yang jauh melampaui batas produksi
- Mode kegagalan yang berisiko atau mustahil diuji di layanan live juga bisa diuji
- Ribuan scenario per jam dapat dijalankan tanpa menyentuh rate limit, memicu deteksi penyalahgunaan, atau menumpuk biaya API
Ekonomi yang tidak konvensional
- Keberhasilan melalui DTU menunjukkan salah satu dari banyak cara Agentic Moment mengubah ekonomi perangkat lunak secara mendasar
- Membuat klon berketelitian tinggi dari aplikasi SaaS utama selalu mungkin secara teknis, tetapi tidak layak secara ekonomi
- Beberapa generasi engineer menginginkan replika penuh in-memory dari CRM untuk pengujian, tetapi bahkan tidak pernah mengusulkannya ke manajer karena sudah menduga akan ditolak
- Pembangun Software Factory perlu mempraktikkan deliberate naivete: mencari lalu menghapus kebiasaan, konvensi, dan batasan dari Software 1.0
- Melalui DTU, hal yang enam bulan lalu tak terbayangkan kini dirutinkan sebagai pekerjaan sehari-hari
Bacaan selanjutnya
- Principles : keyakinan mereka tentang pengembangan perangkat lunak dengan agen
- Perangkat lunak ditumbuhkan dengan struktur seed → validation harness → feedback loop, dan token berperan sebagai bahan bakar
- Semua perangkat lunak membutuhkan seed awal: dulu berupa PRD atau spesifikasi, kini bisa berupa beberapa kalimat, screenshot, atau codebase yang sudah ada
- Validation harness harus end-to-end dan sedekat mungkin dengan lingkungan nyata (pelanggan, integrasi, ekonomi)
- Feedback yang memasukkan sampel output kembali sebagai input membentuk closed loop yang memungkinkan sistem memperbaiki dirinya sendiri dan mengakumulasi akurasi secara majemuk
- Teori validasi dan feedback mudah dipahami, tetapi praktiknya membutuhkan engineering kreatif dan mutakhir: mencari cara untuk mengubah setiap hambatan menjadi representasi yang dapat dipahami model
- Techniques : pola-pola berulang untuk menerapkan prinsip-prinsip ini
- Digital Twin Universe (DTU)
- Mereplikasi perilaku yang dapat diamati dari dependensi pihak ketiga yang penting
- Validasi pada volume dan kecepatan yang jauh melampaui batas produksi
- Menyediakan kondisi pengujian yang deterministik dan dapat direproduksi
- Gene Transfusion
- Menetapkan agen pada contoh yang konkret untuk memindahkan pola kerja antar-codebase
- Solusi yang dipasangkan dengan referensi yang baik dapat direproduksi dalam konteks baru
- Filesystem
- Model dapat menjelajahi repositori dengan cepat dan menyesuaikan konteksnya sendiri melalui baca/tulis file
- Direktori, indeks, dan status on-disk berfungsi sebagai fondasi memori yang praktis
- Shift Work
- Memisahkan pekerjaan interaktif dan pekerjaan yang sepenuhnya terspesifikasi
- Saat intensi sudah lengkap (spesifikasi, test, aplikasi yang ada), agen dapat mengeksekusi end-to-end tanpa bolak-balik
- Semport
- Porting otomatis yang sadar semantik, dilakukan sekali atau berkelanjutan
- Memindahkan kode antarbahasa atau framework sambil mempertahankan intensi
- Pyramid Summaries
- Ringkasan reversibel pada berbagai level zoom
- Mengompresi konteks tanpa kehilangan kemampuan untuk mengekspansinya kembali ke detail penuh
- Products : alat-alat yang mereka gunakan setiap hari dan mereka yakini juga berguna bagi orang lain
- CXDB adalah penyimpanan konteks self-hosted untuk agen AI, menyediakan Turn DAG, deduplikasi blob, tipe dinamis, dan visual debugging
- StrongDM ID adalah sistem identitas untuk manusia, workload, dan agen AI, mendukung federated auth dan path-scoped sharing
- Attractor adalah agen coding non-interaktif yang disusun dengan phase graph, untuk eksekusi end-to-end saat tugas sudah sepenuhnya terspesifikasi
3 komentar
Saya mencoba pengembangan berbasis spesifikasi dengan memakai multi-agent. Memang benar beban kerja banyak berkurang, tetapi karena keterbatasan performa LLM, produk yang benar-benar memuaskan pelanggan belum bisa dibuat. Penggantian 100% tidak mungkin, dan pekerjaan manusia masih diperlukan sampai tingkat tertentu.
Memang agak provokatif, tapi sampai batas tertentu saya juga bisa memahaminya.. entah kenapa ini tulisan yang bikin perasaan jadi aneh.
Kalau membaca tulisan ini lalu melihat tulisan di bawah, rasanya jadi lebih relate.
Berduka atas jiwa craftsmanship kita
Komentar Hacker News
Saya setuju dengan konsep Digital Twin Universe
Codebase saya juga punya banyak integrasi layanan eksternal, jadi saat panggilan eksternal diblokir ketika testing, hampir tidak ada yang bisa diverifikasi
Karena itu saya membuat implementasi palsu untuk tiap API seperti Okta, Jira, Slack, Google Docs, dan lainnya untuk pengujian
Namun saya tidak menyalin UI-nya, hanya meniru perilaku API-nya
Pernyataan bahwa “kalau tidak menghabiskan token $1.000 per hari per engineer, masih ada ruang untuk peningkatan” terdengar terlalu tidak realistis
Sulit percaya itu benar-benar klaim serius
Kalau dihitung, itu sekitar $250k per tahun
Kalau AI benar-benar menghasilkan produktivitas sebesar itu, mungkin bisa masuk akal
Secara realistis, efisiensinya mungkin setara dua engineer junior
Pada akhirnya manusia tampaknya hanya akan berperan sebagai lead untuk perencanaan dan verifikasi
Memang optimisme yang berlebihan, tapi bukan ide yang sepenuhnya gila
Saya cuma memakai langganan Claude dan OpenAI seharga $20 per bulan
Kalau token habis, saya jalan-jalan atau baca buku
Saya bukan akselerasionis, tapi pekerjaan tetap beres
Saya salah satu anggota tim StrongDM
Intinya, menghabiskan token $1.000 per hari itu mudah, tetapi menggunakannya secara produktif itu sulit
Ini terlihat seperti sekadar pamer
Rasanya seperti mengirim sinyal, “kami lebih maju dalam AI daripada kalian”
Saya merasa malu saat membaca tulisannya
Kesan saya, mocks dan pengujian simulasi yang sudah ada hanya dibungkus seolah-olah sebagai “inovasi”
Meski begitu, saya menghargai mereka karena jujur membuka struktur biayanya
Saya mencari kode atau produk nyata di situs mereka
Satu-satunya yang saya temukan adalah strongdm/attractor
“Coding dengan pacar asal Kanada” kini tampaknya sudah jadi model bisnis
Saya juga menemukan strongdm/cxdb, tetapi riwayat commit-nya sudah dirapikan
Ada kode nyata di repositori cxdb
Saya tidak tahu ini kegilaan atau sekilas masa depan
Di halaman Products juga ada database dan sistem ID
Jika banyak agen harus berkolaborasi, konteks bersama dan sistem izin adalah hal yang wajib
Saya pernah mengikuti webinar tentang BAML dari BoundaryML
Spec-driven development adalah pendekatan untuk membuat workflow terstruktur dengan manusia tetap berada di dalam loop
Loop
/research → /plan → /implementdidefinisikan dengan jelas, dan di tiap tahap ada verifikasi manusiaIni adalah filosofi yang sepenuhnya berlawanan dengan klaim StrongDM bahwa “manusia tidak menulis atau membaca kode”
Rasanya seperti posting blog kosong lainnya
Tidak ada hasil nyata, dan cerita token $1.000/hari terasa seperti untuk memikat investor
Jika masalah verifikasi tidak diselesaikan, semua ini hanya pamer belaka
Meski ada review otomatis atau guardrail, pada akhirnya tetap manusia yang harus memastikan kecocokan antara spesifikasi dan hasil
Di Speedscale kami mengotomatiskan verifikasi lewat capture dan replay traffic
Sebenarnya developer manusia juga tidak sempurna
Sudah ada banyak prosedur verifikasi sistematis seperti code review, testing, QA, dan sebagainya
Yang penting bukan apakah AI sempurna, melainkan apakah kualitas keseluruhan sistem akan konvergen
Dari pengalaman saya, dengan Opus 4.5 ada sedikit efek keuntungan bersih
Saya hampir sepenuhnya setuju
Intinya adalah verifikasi, bukan generasi
Saya sedang membangun struktur di mana beberapa agen independen mengungkapkan perbedaan pendapat lalu mencapai konsensus
Singkatnya, verifikasi dan pengujian keamanan dilempar ke pengguna akhir
Kita perlu lebih aktif memakai bahasa berbasis spesifikasi dan verifikasi formal
Pada akhirnya, pemrograman akan didefinisikan ulang sebagai “tindakan mengonkretkan spesifikasi”
Token $1.000 per hari berarti menghabiskan lebih banyak uang untuk AI daripada untuk manusia
Ini tampak seperti titik runtuh visi AI
Katanya Simon Willison sudah memperbarui tulisannya
$240k per tahun setara engineer FANG level pemula
Sejujurnya, banyak junior yang lebih buruk daripada Claude
Pada akhirnya kemungkinan akan tersusun ulang menjadi struktur piramida dengan sedikit manusia di puncak
Jika pekerjaan yang sama bisa selesai dalam 5 hari, maka biaya dibanding kecepatan mungkin masih masuk akal
Jika output-nya bertambah secara proporsional, maka efisiensi biaya mungkin cocok
Selain itu, harga token juga bisa turun
Industri hukum dan asuransi akan paling kesulitan menghadapi perubahan ini
Kesalahan manusia masih bisa dimodelkan, tetapi rantai error dari loop otonom adalah masalah yang sama sekali berbeda
Keputusan AI pada akhirnya akan bermuara pada tanggung jawab manusia
Ini tampaknya akan menjadi rem bagi pergeseran agentic secara keseluruhan
Token $1.000 per hari adalah metrik yang tidak masuk akal
Kalau kualitas kode buruk, konsumsi token akan meledak
Pada akhirnya, codebase yang berantakan lah yang memperbesar biaya
Jika ada tim yang membakar seribu dolar per hari, efisiensinya kemungkinan nyaris nol
(Referensi: meme ini)
Ini soal optimasi jangka pendek vs jangka panjang
Pilihannya adalah meningkatkan efisiensi sekarang, atau memperbaiki keseluruhan sistem
Mungkin baru sekarang para eksekutif akan sadar akan pentingnya refactoring
Tim yang pernah saya sebut sebagai pola Dark Factory rupanya memang mereka
Saya menulis artikel terkait, dan tim ini adalah eksperimentator paling ambisius
Namun kenyataannya hampir tidak ada hasil nyata
Jika memberi beberapa mahasiswa $10k, saya rasa mereka bisa membuat sesuatu yang lebih baik
Token $1.000 per hari adalah sesuatu yang bahkan tak bisa saya impikan dengan anggaran tim saya
Secara pribadi pun mustahil karena biaya hidup
Pada akhirnya rasanya seperti “kalau dilakukan hancur, kalau tidak dilakukan juga hancur”
Jika tidak ada hasil yang bisa diverifikasi, maka ini hanya omongan
Sekarang bahkan omongan pun jadi jauh lebih murah berkat LLM
Perlu ada keterbukaan yang etis
Istilah di situs itu hanya konsep lama yang dikemas ulang
“Digital Twin Universe” adalah mocks, “Gene Transfusion” adalah membaca kode referensi, “Semport” adalah transpiling
Tidak ada data atau benchmark nyata sama sekali
Ini contoh pemasaran AI yang dibungkus sebagai wawasan engineering
Sebenarnya sebagian besar kode intinya sudah ada di GitHub
Pembeda sebenarnya adalah desain mekanisme dan sistem nilai
Masa depan kemungkinan akan bergerak ke gabungan formal methods dan AI
“Menguji dengan menyisakan skenario sebagai holdout set” terdengar menarik
Ini meniru konsep pengujian agresif oleh tim QA
Memisahkan tim build dan tim pendeteksi bug menjadi struktur kompetitif satu sama lain terasa menarik
Namun token $1.000 per hari terasa membuat putus asa bagi developer open source
Biaya bisa ditekan dengan memakai model lokal
Seperti di thread ini, otomatisasi agen lokal juga sangat mungkin dilakukan
Mungkin suatu hari para agen akan saling menyuap
Saya tetap lebih suka manusia tetap berada di dalam loop
Membakar token tanpa arah hanyalah pemborosan
Saya mengeksplorasi kerangka mental pemanfaatan LLM di artikel “LLMs aren’t tools”
“Pabrik perangkat lunak” adalah titik akhir saat ini, tetapi tahap berikutnya adalah melihat LLM sebagai sebuah aplikasi
Artinya, bukan sekadar otomatisasi workflow, melainkan tahap membuat harness kustom