Bukan, Itu Bukan Pabrik Perangkat Lunak — Ryan Cooke, WorkOS

하이라이트

• WorkOS membangun pabrik perangkat lunak dengan mengukur metrik hasil untuk mempercepat pengiriman fitur, bukan sekadar melihat metrik output seperti jumlah pull request (PR).

• Sistem pabrik perangkat lunak WorkOS dibagi menjadi TARS untuk interaksi agen terintegrasi dan Horizon untuk orkestrasi infrastruktur di depan gateway MCP.

• Gateway MCP internal yang dinamakan context engine terhubung ke Snowflake dan sistem internal untuk memberi petunjuk navigasi serta konteks alat kepada agen AI.

• Pabrik perangkat lunak mengomatisasi pembuatan dokumen spesifikasi produk (Hilltop PRD), pengerjaan tiket Linear, hingga triase bug dan dukungan pelanggan di Slack.

• WorkOS mengalihkan infrastruktur dari sandbox-as-a-service ke infrastruktur sandbox sendiri untuk mengontrol data sesi dan membangun lapisan memori organisasi yang abadi.

타임라인

1. 00:00 - 03:11

   Pergeseran Fokus dari Metrik Output ke Metrik Hasil

   Banyak perusahaan berfokus pada persentase PR yang dihasilkan AI sebagai indikator keberhasilan. Metrik tersebut tidak membuktikan apakah hasil kerja AI benar-benar mendorong nilai bagi organisasi teknik. WorkOS memfokuskan investasi alur kerja otomatisasi untuk meningkatkan kecepatan rilis fitur dan mempercepat eksekusi proyek kompleks.

   • Metrik output seperti jumlah PR atau volume kode buatan AI dapat menyamarkan efektivitas sistem yang sebenarnya.
   • Tujuan utama pabrik perangkat lunak adalah memberikan setiap insinyur tim teknik kecil sendiri untuk mempercepat pengiriman fitur.
   • Mengukur keberhasilan berdasarkan kecepatan penyampaian nilai dan fitur kompleks ke produksi jauh lebih relevan daripada menghitung baris kode.
2. 03:11 - 05:07

   Arsitektur Otomatisasi Rekayasa: TARS dan Horizon

   Penggunaan agen AI sederhana di sandbox Cloudflare tidak menghasilkan lonjakan hasil kerja bagi para insinyur. Mengotomatiskan seluruh alur rekayasa membutuhkan pemisahan tugas antara TARS sebagai antarmuka pemrosesan peristiwa dan Horizon sebagai orkestrator infrastruktur. Pendekatan ini memungkinkan agen tidak hanya menulis kode, tetapi juga mengelola status proyek secara otonom.

   • Menjalankan agen AI dalam sandbox cloud standar tidak memberikan peningkatan produktivitas yang signifikan dibanding penggunaan lokal.
   • TARS mengintegrasikan alur kerja agen ke dalam Slack, Linear, dan GitHub melalui webhook untuk melacak kemajuan proyek.
   • Horizon berfungsi sebagai lapisan orkestrasi infrastruktur yang berada di depan gateway MCP.
3. 05:07 - 08:52

   Otonomi Eksekusi dan Dokumentasi Spesifikasi Hilltop

   Tanpa manajer produk khusus, insinyur produk di WorkOS mengandalkan agen khusus bernama PM untuk mengatasi hambatan halaman kosong (cold start). Agen merangkum konteks pelanggan dan merancang tiket kerja di Linear segera setelah dokumen Hilltop disetujui. Insinyur manusia tetap dapat meninjau, memberi komentar, dan menyesuaikan cakupan kerja yang dihasilkan AI.

   • Agen TARS mengeksekusi tiket dependensi secara beruntun dan mengevaluasi ulang celah dalam perencanaan proyek Linear.
   • Dokumen Hilltop PRD menstandarkan tujuan proyek, analisis kompetitif, dan tangkapan layar desain awal sebagai input bagi agen AI.
   • Agen PM membuat draf awal spesifikasi dan memecah proyek menjadi unit tiket kerja tanpa menunggu instruksi manual manusia di setiap tahap.
4. 08:52 - 11:59

   Demonstrasi Alur Kerja Proyek dan Fleksibilitas Alat

   Proses pengerjaan API baru dimulai dari perintah sederhana di Slack, di mana TARS langsung menyiapkan log keputusan, pertanyaan terbuka, dan alur pengerjaan. Meskipun agen terkadang melebih-lebihkan cakupan proyek, memangkas draf jauh lebih cepat daripada membuat seluruh struktur awal secara manual. Dokumentasi terpusat ini juga memberi konteks yang kaya bagi tim keamanan dan alat AI eksternal seperti Devon.

   • Insinyur dapat memicu alur pengerjaan fitur baru di Slack hanya dengan memberikan deskripsi beberapa kalimat.
   • TARS membuat seluruh struktur proyek di Linear dan Notion secara otomatis.
   • Alur dokumentasi yang dihasilkan dapat dimanfaatkan oleh berbagai penggerak eksekusi seperti Devon, Opus lokal via MCP, atau kolaborator manusia.
5. 11:59 - 14:06

   Peran Gateway MCP dan Context Engine

   Context engine bertindak sebagai pemandu bagi agen dengan menyediakan petunjuk navigasi serta aturan penggunaan sistem internal. Tabel semantik di Snowflake memungkinkan agen menulis kueri data yang tepat saat menjawab pertanyaan analisis. Pengoperasian server MCP internal ini akhirnya digunakan luas oleh berbagai tim internal di luar tim rekayasa perangkat lunak.

   • Gateway MCP internal atau context engine menghubungkan agen AI ke Snowflake dan database internal.
   • Deskripsi alat pada server MCP mengarahkan agen untuk membuat kueri pada tabel semantik penggunaan produk dan percakapan pelanggan.
   • Server MCP terbukti berguna bagi karyawan non-teknis untuk melakukan analisis data langsung melalui Slack.
6. 14:06 - 18:41

   Infrastruktur Sandbox Mandiri dan Lapisan Memori Organisasi

   Membangun lapisan infrastruktur sandbox sendiri memberikan fleksibilitas untuk memindahkan beban kerja dan melacak data sesi rekayasa. Lapisan memori organisasi memastikan konteks kerja tetap tersimpan dan dapat digunakan oleh berbagai alat AI. Data infrastruktur tersebut kemudian dimanfaatkan untuk verifikasi semi-online, mengevaluasi tingkat kesalahan agen, dan memperbarui keterampilan rekayasa tim secara berkelanjutan.

   • TARS digunakan untuk melakukan triase bug awal, perbaikan PR otomatis, serta penanganan tiket dukungan pelanggan di Slack.
   • WorkOS membangun infrastruktur sandbox sendiri untuk memperoleh kendali penuh atas data sesi.
   • Lapisan memori yang sedang dikembangkan menyediakan konteks abadi mengenai struktur tim, tanggung jawab produk, dan operasi organisasi.