Setelah 25 tahun membangun platform terlebih dahulu, para praktisi senior kini menyadari bahwa pendekatan lama tidak lagi efektif. Dulu, menulis boilerplate dianggap mahal, dan setiap fitur membawa "pajak" sendiri—migrasi database, konfigurasi routing, hingga autentikasi. Membangun fondasi bersama terlebih dahulu, membayar pajak tersebut sekali, terlihat masuk akal dan menjadi landasan roadmap selama seperempat abad.
Namun, sebuah statistik yang tak terelakkan muncul: sekitar 60% fitur pada roadmap enam bulan sudah usang sebelum dirilis. Bukan hanya sedikit meleset, tetapi benar-benar tidak relevan karena masalah pengguna sudah berubah dan pasar bergerak lebih cepat. Membangun jawaban yang sempurna untuk pertanyaan yang sudah tidak ada lagi membuat kesalahan menjadi sangat mahal. Semakin lama waktu pengembangan sebelum sesuatu yang nyata muncul, semakin sulit mengakui bahwa kita salah. Akibatnya, tim sering kali tetap melanjutkan pengembangan fitur yang sudah tidak relevan dan menyebutnya "sesuai jadwal". Saya sendiri pernah mengalami hal ini berulang kali.
AI tidak menciptakan masalah ini, tetapi agen cerdas membuat kita tidak bisa lagi mengabaikannya. Survei McKinsey tahun 2025 menunjukkan kesenjangan 82 poin: 88% organisasi menggunakan AI, tetapi hanya 6% merasakan dampak nyata pada laba bottom‑line. Kesenjangan ini bukan tentang alat, karena semua orang memiliki akses ke teknologi yang sama. Perubahan nyata muncul dalam laporan McKinsey tahun 2026, yang menggambarkan agen bekerja semalaman: memperkaya persyaratan, menghasilkan kode, dan mengemas output untuk tinjauan di pagi hari. Fenomena ini disebut “24‑jam sprint”. Organisasi terkemuka melaporkan peningkatan produktivitas 3–5 kali lipat dengan tim yang 60% lebih kecil.
Seorang product owner masuk ke sistem pukul 09.00 dan menemukan bahwa sebuah fitur telah berubah dari konsep hingga kode yang teruji semalaman, tanpa campur tangan manusia. Ini bukan sekadar fitur otomatisasi, tetapi sebuah model pengiriman yang berbeda. Kunci kesuksesan model ini, yang sering terlewatkan oleh banyak tim, adalah keterbatasan yang jelas: tugas harus kecil, terbatasi, dan lengkap. Agen membutuhkan batas yang konkret; arsitektur platform horizontal justru memberikan kebalikannya. “Struktur basis kode Anda sekarang, secara efektif, menjadi bagian dari prompt,” tulis Jeremy D. Miller untuk .NET pada Juni 2026. Bayangkan meminta seseorang memperbaiki saklar lampu, tetapi mereka harus membaca diagram kabel seluruh rumah terlebih dahulu. Ketika diperbesar ke pengembangan platform horizontal, agen diminta membangun infrastruktur yang akan mendukung lima fitur masa depan—konteks yang sangat luas, tanpa batas yang jelas, dan tidak ada sesuatu yang nyata untuk diuji.
Jimmy Bogard menawarkan solusi: potongan vertikal (vertical slice). Alih-alih mengorganisir kode berdasarkan lapisan teknis, kelompokkan semuanya berdasarkan fitur. Satu folder untuk “membuat pengiriman”: di dalamnya terdapat request, validasi, logika bisnis, akses database, dan response—semuanya bersama-sama. Agen hanya perlu membuka satu folder, mendapatkan semua yang diperlukan, tanpa gangguan dari kode yang tidak relevan. Lingkup yang kecil dan batas yang jelas memungkinkan pengujian end‑to‑end dalam hitungan hari.
Medtronic, perusahaan perangkat lunak medis yang diawasi FDA, menganjurkan pendekatan ini. Insinyur sistem utama mereka menyatakan bahwa potongan vertikal “secara struktural, persis seperti apa yang dibutuhkan model agentik untuk beroperasi secara andal”. Tanpa hal ini, agen menghasilkan output yang terlihat masuk akal tetapi sebenarnya salah dalam cara yang sulit dideteksi. Agen membutuhkan batasan; potongan vertikal menyediakan batasan tersebut, sedangkan platform horizontal justru menghilangkan batasan.
SDLC (Software Development Life Cycle) tidak hilang karena AI. Perencanaan, pengiriman, dan tinjauan tetap menjadi tulang punggung pengembangan perangkat lunak. Yang berubah adalah bentuknya. Perencanaan menjadi lebih ketat; kita masih menulis spesifikasi, tetapi bukan lagi diagram arsitektur 18 bulan, melainkan satu potongan vertikal saja: nomor seksi, ID stabil, dan daftar non‑tujuan yang eksplisit. Spesifikasi ini menjadi kontrak yang dijalankan oleh agen. “Ini tidak sesuai dengan §2.2” bisa diselesaikan dalam 10 detik, bukan 10 menit untuk menebak bahwa sesuatu terasa salah.
Pengiriman menjadi vertikal: satu potongan lengkap, dari request hingga response, database hingga UI, dibangun oleh agen dalam semalam. Potongan tersebut dapat diuji secara end‑to‑end pada hari yang sama; pengujian integrasi bukan lagi fase akhir, tetapi potongan tersebut sendiri merupakan pengujian integrasi.
Tinjauan dibagi menjadi dua: verifikasi spesifikasi (apakah output cocok dengan kontrak?) dan verifikasi nilai (apakah ini benar‑benar menyelesaikan masalah pengguna?). Proses yang dulu memakan waktu berbulan‑bulan kini berlangsung dalam hitungan hari. Laporan Anthropic tahun 2026 mencatat bahwa pengembang menggunakan AI dalam 60% pekerjaan mereka, tetapi hanya dapat mendelegasikan sepenuhnya 0‑20% tugas. Agen mempercepat waktu eksekusi, tetapi tidak mengurangi ambiguitas atau akuntabilitas. Tinjauan manusia tetap menjadi tempat manusia untuk menilai nilai.
Berikut gambaran sehari-hari yang mungkin terjadi:
Pagi hari: Anda masuk ke sistem, melihat bahwa agen telah menyelesaikan Potongan A semalaman—kode lengkap dengan tes yang lulus, siap untuk pull request. Anda meninjau output terhadap spesifikasi, memeriksa nomor seksi, dan menyetujui atau meminta perubahan dalam hitungan detik.
Sementara itu, Anda memberi tugas kepada agen untuk membangun Potongan B, berdasarkan spesifikasi yang mencakup non‑tujuan. Anda tidak mengawasi; spesifikasi adalah instruksi yang jelas.
Siang hari: Anda menempatkan Potongan A di depan pengguna nyata, mengamati bagaimana mereka berinteraksi, dan mempelajari apakah fitur tersebut benar‑benar menyelesaikan masalah yang Anda pikirkan. Sementara itu, agen terus membangun Potongan B. Pekerjaan ini tidak terhambat oleh hasil uji coba pengguna, karena Potongan B bergantung pada antarmuka yang didefinisikan dalam spesifikasi, bukan pada apakah pengguna menyukai Potongan A.
Malam hari: Anda mencatat pelajaran yang dipetik dan menulis spesifikasi untuk Potongan C, mengantrekannya untuk dikerjakan agen semalaman. Siklus ini berulang, dengan pekerjaan yang berjalan paralel karena serah terima berupa artefak, bukan percakapan.
Di Indonesia, banyak startup teknologi seperti Gojek, Tokopedia, dan Bukalapak mulai mengadopsi pola potongan vertikal, terutama ketika mereka bermigrasi ke arsitektur berbasis mikro layanan. Komunitas pengembang di Jakarta dan Surabaya sering mengadakan lokakarya tentang “pengembangan berbasis agen” yang menekankan pentingnya batasan yang jelas. Tantangan terbesar bagi perusahaan lokal adalah warisan sistem monolitik yang sudah ada selama bertahun‑tahun. Peralihan ke potongan vertikal sering kali memerlukan refactor besar, yang dapat mengganggu operasi saat ini. Namun, banyak yang melaporkan bahwa investasi ini terbayar dengan waktu pengiriman fitur yang lebih cepat dan kemampuan untuk menyesuaikan dengan perubahan pasar yang cepat.
Dampak lebih luas dari pergeseran ini adalah perubahan komposisi tim. Perusahaan yang berhasil mengadopsi model agen kini dapat mempertahankan tim yang 60% lebih kecil sambil mempertahankan produktivitas yang lebih tinggi. Hal ini membuka peluang bagi talenta junior untuk mengambil peran yang sebelumnya hanya untuk senior, karena alat-alat baru mengotomatisasi banyak tugas repetitif. Namun, hal ini juga menciptakan permintaan baru akan keterampilan dalam penulisan spesifikasi, pemahaman tentang batasan agen, dan penilaian nilai yang hanya dapat dilakukan oleh manusia.
Ke depan, potongan vertikal kemungkinan akan menjadi standar, terutama ketika model agen terus meningkat dalam pemahaman konteks dan kemampuan pemecahan masalah. Platform akan tetap ada, tetapi dibangun secara on‑demand ketika kebutuhan spesifik muncul, bukan lagi sebagai fondasi universal yang dibangun di awal. Manusia akan terus menjadi pengawas di tahap verifikasi nilai, memastikan bahwa kode yang dihasilkan tidak hanya sesuai spesifikasi tetapi juga benar‑benar bermanfaat bagi pengguna.
Perubahan ini bukan sekadar tren teknologi; ini merupakan pergeseran paradigmatik dalam cara kita berpikir tentang pengembangan perangkat lunak. Mereka yang beradaptasi lebih awal akan menikmati siklus pengiriman yang lebih cepat, biaya operasional yang lebih rendah, dan kemampuan untuk berinovasi dengan kecepatan yang belum pernah terjadi sebelumnya.