Jeremy Freeman, Co-Founder dan CTO Allstacks – Seri Wawancara

Jeremy Freeman, Co-Founder dan CTO Allstacks, adalah insinyur perangkat lunak, arsitek teknologi, dan wirausaha dengan karir yang meliputi pengembangan perangkat lunak, rekayasa perangkat keras, pembelajaran mesin, dan inovasi produk. Sejak menjadi co-founder Allstacks pada 2017, ia telah memimpin arsitektur dan pengembangan platform inti perusahaan, membantu mengubah manajemen pengiriman perangkat lunak melalui analitik prediktif dan peramalan yang didorong AI. Sebelum Allstacks, Freeman memegang peran kepemimpinan di Ravioli Labs dan CertiRx, di mana ia bekerja pada rekayasa perangkat lunak, penelitian, teknologi anti-pemalsuan, dan pengembangan produk. Pada awal karirnya, ia memperoleh pengalaman di seluruh startup, perusahaan teknologi, dan akademisi, termasuk mengajar pengembangan web di Wake Technical Community College. Latar belakang teknisnya mencakup sistem tertanam, desain perangkat keras, platform perangkat lunak skala besar, pembelajaran mesin, dan kepemimpinan rekayasa, memberinya perspektif unik tentang membangun produk yang didorong data untuk membantu organisasi meningkatkan hasil pengiriman perangkat lunak.

Allstacks adalah platform kecerdasan rekayasa perangkat lunak dan manajemen aliran nilai yang membantu organisasi meningkatkan prediktabilitas dan efisiensi pengembangan perangkat lunak. Platform ini mengintegrasikan data dari alat yang digunakan di seluruh siklus hidup pengembangan perangkat lunak, termasuk sistem manajemen proyek, kontrol sumber, dan sistem pengiriman, kemudian menerapkan AI dan pembelajaran mesin untuk mengidentifikasi risiko, meramalkan hasil pengiriman, dan menyajikan wawasan yang dapat ditindaklanjuti. Dengan memberikan visibilitas kepada pemimpin rekayasa dan produk tentang kesehatan proyek, kinerja tim, dan tren pengembangan, Allstacks memungkinkan organisasi membuat keputusan yang lebih tepat, mengurangi ketidakpastian pengiriman, dan mempertahankan upaya rekayasa dengan tujuan bisnis. Teknologinya dirancang untuk membantu perusahaan melampaui perencanaan yang didorong oleh intuisi dengan memanfaatkan data operasional waktu nyata untuk meningkatkan kinerja pengiriman perangkat lunak dan eksekusi strategis.

Anda telah memiliki perjalanan unik dari memimpin tim penelitian dan rekayasa yang menerapkan pembelajaran mesin pada data pengembangan perangkat lunak hingga menjadi co-founder Allstacks pada 2017. Apa celah atau masalah berulang yang Anda amati yang akhirnya mendorong Anda untuk membangun perusahaan?

Ketika kami memulai Allstacks, kami menghabiskan banyak waktu di awal melakukan penemuan pelanggan, dan pola yang muncul konsisten: perusahaan demi perusahaan memiliki sejumlah besar data dan tetap tidak tahu apa yang sebenarnya terjadi. Pengiriman perangkat lunak tidak dapat diprediksi meskipun memiliki beberapa orang paling pintar di ruangan. Masalah itu belum terpecahkan.

Apa yang menjadi jelas cukup cepat adalah bahwa ini bukanlah masalah pelaporan atau integrasi. Ini adalah masalah hubungan. Untuk mengetahui apakah sesuatu berisiko, Anda perlu tahu bagaimana item pekerjaan terhubung ke cabang, cabang terhubung ke PR, PR terhubung ke tujuan sprint, dan tujuan sprint terhubung ke inisiatif bisnis. Grafik itu tidak ada secara default di mana pun di rantai alat standar. Anda harus membangunnya. Dan membangunnya dengan baik secara fundamental adalah masalah inferensi, yang mana latar belakang ML menjadi langsung berguna.

Tujuan kami dari awal bukanlah membuat pengembang individu lebih cepat pada fitur X. Ini adalah membuat seluruh organisasi lebih baik. Bagaimana Anda menyelaraskan upaya rekayasa dengan hasil bisnis? Bagaimana Anda membuat rekayasa benar-benar melayani bisnis daripada hanya ada di sampingnya? Anda perlu pemahaman yang lebih baik tentang hubungan data untuk menjawab itu. Ini adalah pertanyaan yang telah mengarahkan hampir setiap keputusan produk yang kami buat.

Allstacks fokus menganalisis data di seluruh siklus hidup pengembangan perangkat lunak. Apa jenis sinyal atau pola yang paling prediktif ketika datang ke mengidentifikasi risiko pengiriman dini?

Saya tidak berpikir ada satu set metrik yang memprediksi baik dan buruk, tetapi pola untuk fase dan jenis organisasi yang berbeda. Apa yang saya temukan lebih berguna adalah mengakui bahwa organisasi rekayasa melalui musim perbaikan. Bulan ini, itu kinerja database. Bulan depan, itu komunikasi antar tim. Kemudian itu “mengapa kita tidak bisa menutup PR?” Kemudian observabilitas. Sebagai pemimpin rekayasa, Anda berenang dalam sinyal: beberapa diagnostik, beberapa pemantauan, dan banyak yang hanya noise.

Apa yang membantu adalah memulai dengan masalah yang Anda lihat sebenarnya, bukan metrik yang ingin Anda perbaiki. Jika Anda bertanya “mengapa terasa seperti kita mengirimkan lebih sedikit daripada tahun lalu,” itu adalah titik awal yang tepat. Dari sana, saya pikir Anda perlu tiga jenis metrik: pertama, bagaimana Anda tahu masalah itu nyata (mungkin hitungan PR per pengembang dari waktu ke waktu); kedua, apa perubahan yang Anda buat dan bagaimana Anda melacaknya sepanjang jalan (katakanlah, adopsi PR reviewer AI jika itu adalah intervensi Anda); dan ketiga, seberapa signifikan masalah ini bagi bisnis. Intuisi Anda mungkin benar bahwa Anda mengirimkan 20 persen lebih sedikit kode, tetapi cerita sebenarnya mungkin bahwa QA sekarang memakan waktu tiga kali lebih lama. Anda perlu ketiga lensa untuk mengetahui apakah Anda memecahkan hal yang tepat.

Anda telah bekerja di seluruh industri seperti kesehatan, energi, dan teknologi. Bagaimana tantangan dalam pengiriman perangkat lunak berbeda di seluruh sektor ini, dan bagaimana itu membentuk platform Allstacks?

Saya sangat menghargai pengalaman saya di sektor non-teknologi murni. Di perusahaan SaaS, mudah untuk tersesat dalam ide bahwa perangkat lunak itu sendiri adalah tujuan. Ketika Anda berada di bisnis di mana Anda tidak secara langsung menjual perangkat lunak, peran Anda menjadi jauh lebih jelas: teknologi ada untuk mendukung bisnis. Saya sering bercanda bahwa jika bisnis bisa mencapai semua tanpa harus berurusan dengan saya, mereka akan memilih opsi itu tanpa berpikir dua kali.

Perspektif itu sebenarnya berguna. Ini mengkontekstualkan apa yang kita lakukan di industri ini, dan itu meletakkan banyak debat teknologi kembali ke tempatnya. Bisnis tidak peduli apakah Anda menggunakan Python atau Go. Menghabiskan siklus pada rewrite itu mungkin tidak di mana return yang sebenarnya.

Apa yang konsisten di seluruh industri, bagaimanapun, adalah masalah fragmentasi. Tidak peduli sektor, setiap organisasi rekayasa memiliki data yang tersebar di seluruh belasan alat dengan jaringan terbatas di antaranya. Spesifiknya bervariasi: industri yang diatur memiliki siklus perencanaan yang lebih lama dan toleransi yang lebih rendah untuk ketidakjelasan dalam persyaratan karena biaya membangun hal yang salah lebih tinggi. Toko teknologi berkecepatan tinggi mengumpulkan utang tersembunyi lebih cepat. Tapi mode kegagalan inti sama. Tim dapat memberitahu Anda apa yang dikirim. Mereka tidak bisa melacak mengapa sesuatu tergelincir, apa yang menjadi biaya, atau di mana risiko terlihat sebelum menjadi masalah. Itulah yang membentuk bagaimana kami membangun platform.

Ada narasi yang berkembang bahwa AI mempercepat pengkodean itu sendiri sambil mengekspos kelemahan di tempat lain. Mengapa persyaratan, perencanaan, dan kesiapan spesifikasi menjadi bottleneck sebenarnya?

Kami melihat ini setiap hari. Dengan agen yang baik dan harness yang solid di sekitarnya, Anda dapat berpindah dari ide, terkadang langsung dari mulut pelanggan, ke produksi dalam beberapa jam.

Bagian dari apa yang membuat perubahan ini sangat signifikan adalah perubahan dalam loop umpan balik. Dengan alat copilot-style, manusia ada di dalam loop untuk setiap saran. AI menawarkan penyelesaian; Anda menerima atau menolaknya segera. Ketika itu salah, Anda menangkapnya dengan cepat. Radius ledakan dari saran yang buruk adalah satu baris kode. Agentic coding bekerja secara berbeda: Anda memberi agen sebuah tujuan, itu memecah pekerjaan, melaksanakan rencana multi-langkah, dan mengirimkan modul yang berfungsi. Manusia meninjau output, bukan setiap langkah. Ketika spesifikasi salah, agen membangun implementasi seluruhnya ke spesifikasi yang salah dan Anda menemukannya saat tinjau.

Itu terdengar seperti keuntungan murni sampai Anda mengakui apa yang sebenarnya dilakukan oleh waktu lag sebelumnya. Waktu lag itu berfungsi sebagai tujuan yang nyata. Beberapa putaran orang pintar yang meninjau, merencanakan, menguji, dan bekerja melalui ide untuk menghasilkan sistem yang lebih baik.

Godaan sekarang adalah untuk melewati semua itu. Tapi agen dan harness tidak siap untuk seluruh SDLC yet. Kecepatan nyata. Pengawasan kualitas yang terjadi di semua langkah yang lebih lambat sebelumnya belum digantikan. Itu adalah celah.

Banyak organisasi masih mengukur produktivitas menggunakan metrik yang sudah ketinggalan zaman. Apa yang pemimpin dapatkan secara fundamental salah tentang produktivitas dalam lingkungan pengembangan yang didorong AI?

Orang telah matang pada topik ini secara signifikan sejak kami memulai Allstacks. Pengukuran telah bergeser ke hal-hal yang benar-benar penting, dan kerangka telah menjadi lebih canggih. AI mengguncang semua itu.

Pengembangan perangkat lunak tradisional secara fundamental dibatasi oleh seberapa cepat pengembang dapat menulis kode yang memenuhi persyaratan bisnis dan teknologi yang mendasarinya. Biaya itu mendekati nol. Apa yang kita hadapi sekarang adalah sesuatu yang lebih dekat dengan pengembang individu sebagai manajer agen. Model itu memerlukan pendekatan yang sama sekali berbeda untuk mengukur produktivitas, yang didasarkan pada sesuatu yang lain daripada token yang dihasilkan atau jam pengembang yang dihabiskan.

Bagian dari bahaya dengan metrik saat ini adalah bahwa mereka menyembunyikan apa yang sebenarnya terjadi di tingkat tim. Insinyur senior dengan alat AI mengompensasi keuntungan mereka: mereka memiliki konteks codebase dan penilaian untuk mengarahkan output agen dan menangkap kegagalan mereka. Insinyur awal karir sering menghasilkan volume kode yang sama tetapi menghabiskan lebih banyak waktu untuk memeriksa output yang tidak dapat mereka evaluasi sepenuhnya. Kecepatan agregat terlihat baik, mungkin bahkan ditingkatkan. Jarak antara kedua kelompok itu tidak muncul di mana pun di dashboard standar. Pertanyaan yang tepat untuk dimulai adalah bukan “seberapa cepat kita pergi” tetapi “seberapa banyak dari apa yang kita kirimkan benar dari awal.”

Kami belum memiliki konsensus industri tentang model pengukuran yang tepat, tetapi tim yang mulai melacak kualitas output dan tingkat perkerjaan ulang, bukan hanya throughput dan adopsi, akan lebih baik diposisikan daripada tim yang menunggu orang lain untuk memecahkannya.

Platform Anda menghubungkan data dari alat seperti sistem manajemen proyek dan repositori kode. Seberapa penting untuk mempersatukan sumber data yang terfragmentasi ini, dan apa yang terjadi ketika organisasi gagal melakukannya?

Allstacks telah berhasil di ruang ini karena kami telah membangun grafik konteks sejak sebelum itu menjadi istilah. Kami mengakui dari awal bahwa menghubungkan semua data bersama-sama diperlukan untuk menjawab pertanyaan yang sebenarnya ditanyakan oleh pelanggan.

Ketika koneksi itu tidak ada, AI yang beroperasi pada data rekayasa Anda hanya dapat melihat sebagian dari gambaran. Ini dapat menganalisis apa yang ada di sistem manajemen proyek Anda. Ini dapat menganalisis apa yang ada di repositori kode Anda. Apa yang tidak bisa dilakukan adalah melacak penundaan pengiriman kembali ke ketergantungan yang diblokir di seluruh tiga alat, karena hubungan antara sinyal itu tidak ada di lapisan data. Anda mendapatkan analisis yang dangkal pada saat terbaik, dan rekomendasi yang salah dengan percaya diri pada saat terburuk. Kualitas model tidak menyelesaikan ini. Anda dapat meletakkan model paling mampuan yang tersedia di atas integrasi API mentah dan masih melewatkan penyebab sebenarnya dari masalah karena data tidak mengkodekan hubungan antara sinyal. Sampah masuk, sampah keluar, terlepas dari seberapa pintar modelnya.

Koneksi itu adalah fondasi. Itu yang memungkinkan kami untuk menjadi yang pertama di pasar dengan kemampuan yang masih belum direplikasi.

Bagaimana organisasi yang siap dengan baik terlihat dibandingkan dengan yang tidak siap ketika agen AI menjadi lebih tertanam dalam alur kerja pengembangan?

Ironisnya, itu tidak jauh berbeda dari menjadi siap untuk membawa kelas magang musim panas. Anda perlu memiliki suite pengujian otomatis yang kuat, dokumentasi yang solid, pipa CI/CD yang matang, dan guardrails yang Anda letakkan ketika Anda menambahkan pengembang yang dipercaya tetapi tidak terlatih ke tim.

Apa yang juga penting, dan orang cenderung meremehkannya, adalah kembali secara teratur untuk meninjau dasar-dasar: aturan agen Anda, file AGENTS.MD Anda. Anda dapat melakukan langkah pertama yang solid, tetapi mudah untuk masuk ke irama mengirim dalam cara baru dan melupakan bahwa Anda sebenarnya dapat melatih banyak default yang buruk. Hal-hal seperti mengajarkan agen untuk menjalankan tes sebelum setiap komit tidak memerlukan pengingat manusia setiap kali.

Satu pertanyaan diagnostik yang saya berikan kepada setiap pemimpin rekayasa: dapatkah Anda memberitahu saya apa yang dihasilkan agen Anda pada sprint terakhir, mana dari output itu yang diterima apa adanya versus direvisi, dan di mana upaya revisi terkonsentrasi? Jika Anda dapat menjawab itu, Anda memiliki instrumen untuk memperbaiki. Jika Anda tidak bisa, Anda terbang dengan perasaan.

Anda telah menekankan pentingnya menyelaraskan pekerjaan rekayasa dengan hasil bisnis. Bagaimana organisasi dapat menjembatani kesenjangan itu dengan cara yang praktis dan dapat diukur?

Saya telah melihat dua mode kegagalan utama. Yang pertama adalah perusahaan yang tidak menghubungkan tim rekayasa dengan produk. Banyak struktur tim adalah warisan dan telah ada selama waktu yang lama. Satu tim mungkin memiliki bagian dari tiga produk yang berbeda sementara tim lain memiliki empat sepenuhnya. Investasi rekayasa sebagian besar turun ke headcount, dan ketika tim tidak selaras dengan produk, menjadi sangat sulit untuk melihat di mana harapan bisnis menyimpang dari kenyataan.

Mode kegagalan kedua adalah tidak memperhitungkan semua pekerjaan yang masuk ke dalam membangun dan memelihara perangkat lunak. Ada kategori besar pekerjaan rekayasa yang tidak terlihat bisnis. Contoh favorit saya adalah menjaga paket tetap mutakhir. Pemimpin bisnis non-teknis sering berjuang untuk memahami nilai atau mengapa itu berkelanjutan dan tidak terduga. Tapi mereka dapat memahami kategori investasi. Jika Anda membingkaiinya sebagai “peningkatan keamanan kritis” dan menunjukkan rata-rata seberapa banyak kapasitas yang dikonsumsi, Anda berbicara dengan bahasa yang mereka dapat bekerja dengannya.

Jika Anda bertanya kepada pemimpin penjualan untuk memilih antara beberapa pembaruan paket npm dan fitur yang mereka butuhkan untuk menutup kesepakatan, fitur itu menang setiap saat. Tapi jika Anda membingkaiinya sebagai “kami keluar dari kepatuhan SOC atau kami mengirimkan fitur ini,” sekarang Anda menunjukkan kepada mereka dua pertukaran yang sebenarnya dapat mereka evaluasi. Pembingkaian kembali itu adalah seluruh permainan. Kami telah melihat pelanggan memotong waktu pelaporan modal R&D mereka lebih dari dua pertiga hanya dengan membuat klasifikasi pekerjaan itu otomatis daripada manual. Mekanisme itu sama apakah tujuannya adalah pelaporan modal, justifikasi headcount, atau membuktikan ROI AI: data yang terhubung menggantikan spreadsheet yang terkorelasi.

Bagaimana peran pengembang berkembang ketika AI mengambil lebih banyak beban pengkodean?

Jujur, saya sedikit khawatir, meskipun saya percaya bahwa orang pintar akan menemukan jalan keluarnya.

Kekhawatiran saya nyata. Lulusan baru akan segera memasuki angkatan kerja tanpa pernah mengkode dalam dunia tanpa agen pengkodean. Apakah pendidikan telah mengejar ketinggalan dengan itu? Alat-alat itu bergerak dengan cepat; pendidikan tinggi tidak selalu bergerak seiring dengan mereka. Perubahan lain yang saya amati adalah pengaburan antara insinyur senior dan pemimpin produk senior. Praktisi yang paling sukses dalam model baru adalah insinyur yang sangat berinvestasi dalam pemikiran produk.

Apa yang menjadi lebih berharga adalah penilaian: kemampuan untuk mendefinisikan masalah dengan cukup presisi sehingga agen dapat menyelesaikannya, menilai apakah solusi itu benar, dan menangkap kegagalan halus yang melewati CI tetapi menciptakan masalah arsitektur nanti. Insinyur senior mengompensasi keuntungan mereka karena mereka dapat mengarahkan output agen dan tahu output mana yang dapat dipercaya. Kekhawatiran adalah untuk jalur karir awal. Cara tradisional membangun penilaian itu adalah dengan menulis banyak kode dan belajar dari kesalahan. Loop umpan balik itu berubah dengan cara yang belum sepenuhnya dikerjakan oleh industri.

Namun, sejarah menawarkan beberapa jaminan. Ada kontingen signifikan orang yang percaya bahwa compiler akan membuat pengembang assembly kehilangan pekerjaan. Perubahan teknologi terjadi seperti yang mereka prediksi. Apa yang terjadi pada pengembang yang tidak mengikuti skrip yang sama? Selama dekade berikutnya, jumlah total pengembang tumbuh. Banyak dari pengembang assembly tersebut belajar bahasa baru dan unggul karena pengetahuan dasar mereka. Saya pikir pola versi itu akan terulang lagi.

Menghadap ke depan, bagaimana Anda melihat AI mengubah siklus hidup pengembangan perangkat lunak dalam tiga hingga lima tahun ke depan, dan di mana perusahaan akan memperoleh keuntungan kompetitif terbesar?

Kita akan melihat perlombaan fitur yang tidak seperti apa pun yang pernah kita lihat sebelumnya. Ketika biaya untuk membangun mendekati nol, perusahaan, bahkan yang besar, menghadapi keterbatasan baru: mengumpulkan dan memvalidasi umpan balik pelanggan yang cukup untuk terus membangun hal-hal yang berkualitas dengan skala.

Perubahan yang harus terjadi adalah bahwa batang untuk apa yang dibangun perlu naik. Keterbatasan saat ini di sebagian besar organisasi rekayasa adalah sederhana: lima prioritas teratas, mungkin dua yang dikirim. Dengan agen, rasio itu terbalik. Anda mungkin memiliki lima teratas, sepuluh berikutnya, dan dua puluh mungkin di daftar, dan mengirim seratus. Pertanyaan yang tidak ada jawabannya adalah bagaimana Anda menjaga enam puluh lima terakhir dari menjadi konsep yang buruk dan dieksekusi dengan buruk.

Dua hal yang saya cukup yakin tentang jendela tiga hingga lima tahun. Pertama, keunggulan kompetitif dalam rekayasa AI akan datang dari kedalaman dan keluasan konteks, bukan kualitas model. Model-model itu menjadi barang yang umum; setiap alat akan memiliki model yang mampuan. Apa yang akan membedakan platform terkemuka adalah seberapa dalam mereka memahami organisasi Anda yang spesifik: repositori Anda, struktur tim Anda, riwayat pengiriman Anda, pola penerapan Anda. Alat yang mengetahui sistem Anda akan menghasilkan jawaban yang secara fundamental berbeda dari yang tidak. Kedua, pergeseran dari reaktif ke proaktif. Alat hari ini menjawab pertanyaan ketika ditanya. Dalam beberapa tahun, alat terkemuka akan mengamati terus menerus dan menampilkan risiko sebelum Anda bertanya. Organisasi yang membangun lapisan konteks sekarang sedang mengompensasi keuntungan. Generasi alat berikutnya harus memecahkan masalah kualitas dengan skala, dan organisasi yang memecahkannya pertama akan memiliki keunggulan nyata.

Terima kasih atas wawancara yang luar biasa, pembaca yang ingin mempelajari lebih lanjut dapat mengunjungi Allstacks.