1. Pendahuluan

Selama sebagian besar sejarah perangkat lunak, sumber daya yang langka adalah penulisannya. Keahlian seorang pengembang diukur dari kemampuan mengubah sebuah niat menjadi kode yang benar, dan jam-jamnya tercurah untuk mengetik, mencari rujukan, menyatukan pustaka, memperbaiki kesalahan-kesalahan kecil yang diungkap oleh galat kompilasi dan pengujian yang gagal. Sebuah agen pengkodean yang cakap menyingkirkan sebagian besar dari itu. Beri ia sebuah instruksi yang jelas dan akses ke sebuah basis kode, dan ia akan menghasilkan sebuah perubahan yang berfungsi dalam hitungan menit, dalam idiom yang telah dilihatnya sejuta kali, dengan boilerplate yang sudah benar. Sebutan sehari-hari untuk cara kerja seperti ini, yang dipopulerkan pada awal 2025, adalah vibe coding: menggambarkan apa yang Anda inginkan dan membiarkan model menghasilkannya, mengarahkan berdasarkan hasil alih-alih dengan menulis setiap baris. Ini benar-benar sebuah lompatan, dan mudah untuk salah mengiranya sebagai keseluruhan cerita.

Itu bukan keseluruhan cerita, karena membuat kode muncul tidak pernah menjadi bagian tersulit dari perangkat lunak, hanya bagian yang melelahkan. Bagian yang sulit adalah memutuskan apa yang harus dibangun, dan mengetahui bahwa apa yang telah dibangun memang benar, aman, dan layak dijalankan. Hal-hal ini tidak menjadi lebih murah ketika generasi menjadi murah; kalaupun ada, ia menjadi lebih sulit, karena kini ada jauh lebih banyak kode untuk dipahami, dihasilkan lebih cepat daripada yang ditulis seseorang, oleh seorang penulis yang percaya diri bahkan ketika keliru. Hambatan utama pengembangan perangkat lunak berpindah. Dulu ia berada pada generasi, seberapa cepat sebuah tim dapat menulis kode yang benar. Dengan sebuah agen, ia berada pada verifikasi: seberapa cepat sebuah tim dapat memastikan kode itu benar dan meloloskannya.

Makalah ini membahas konsekuensi dari pergeseran itu bagi perkakas, dan ia sengaja dibuat konkret. Jika verifikasi adalah kendalanya, maka hal paling bernilai yang dapat dilakukan sebuah penyiapan berbantuan AI bukanlah menghasilkan lebih cepat, melainkan membantu sebuah tim memverifikasi lebih cepat dan lebih aman, menangkap kesalahan agen secara murah dan dini. Kami menguraikan rangkaian spesifik yang kami gunakan di Nashua untuk membangun dan mengoperasikan produk kami sendiri, Nashua 360 Enterprise Platform, Claude Code sebagai agen, GitHub sebagai tulang punggung berkontrol-versi dan gerbang tinjauan, Vercel untuk sebuah preview berjalan dari setiap perubahan, Next.js sebagai framework aplikasi, dan Postgres sebagai basis datanya, dan kami masuk ke bagaimana setiap bagian sebenarnya bekerja, karena pada detailnyalah nilai itu berada. Setiap mata rantai memperoleh tempatnya dengan mengetatkan sebuah putaran atau menambahkan sebuah gerbang, bukan dengan menjadi pintar secara tersendiri.

Kontribusinya adalah sebuah argumen dan sebuah rekomendasi yang telah dikerjakan, bukan sebuah tolok ukur. Bagian 2 memaparkan apa yang diubah AI dan apa yang tidak, serta menemukan letak hambatan utamanya. Bagian 3 menyajikan rangkaian itu sebagai sebuah putaran (Gambar 1), membangun argumen bahwa untuk pekerjaan berbantuan-agen best-of-breed berarti konvensional, dan menjelaskan mengapa gerbang-gerbang independen berlipat ganda. Bagian 4 hingga 9 membahas kelima bagian itu satu per satu dan masuk ke seluk-beluknya, termasuk arsitektur runtime yang sebenarnya dimiliki sebuah deployment (Gambar 2) dan bagian yang mengejutkan banyak orang, bahwa sebuah perubahan kini dapat dimulai dan ditinjau dari sebuah ponsel. Bagian 10 hingga 12 membahas gerbang manusia dan moda-moda kegagalannya, biaya yang sesungguhnya, dan bagaimana rangkaian itu berjalan dalam praktik. Pertanyaan yang mengalir di sepanjang makalah adalah: begitu sebuah agen dapat menulis kode, apa yang harus ditempatkan sebuah tim di sekelilingnya agar menulis dengan cepat tidak berarti mengirimkan yang keliru?

2. Apa yang diubah AI, dan apa yang tidak

2.1 Pergeseran

Perubahan yang dibawa sebuah agen paling tepat dinyatakan dengan saksama. Bukan bahwa mesin kini memahami masalahnya; melainkan bahwa biaya menghasilkan sebuah implementasi yang masuk akal, dan sering kali benar, dari sebuah perubahan yang terspesifikasi dengan baik telah anjlok. Seorang pengembang yang semestinya menghabiskan satu sore untuk sebuah fitur dapat memiliki versi pertamanya dalam waktu yang diperlukan untuk menggambarkannya, dan dapat membuang beberapa versi dengan murah. Moda kerja bergeser dari mengarang menjadi mengarahkan: menyatakan niat, membaca hasil, mengoreksi arah. Ini adalah daya ungkit yang nyata, dan sebuah tim yang menolaknya akan tersalip.

2.2 Tidak ada peluru perak

Perubahan itu juga memiliki batas, dan batas itu sudah lama. Brooks (1987) menarik pembedaan yang masih berlaku di sini: kompleksitas aksidental perangkat lunak, kerja yang dibebankan oleh perkakas dan bahasa kita alih-alih oleh masalahnya, dapat diserang dan dikurangi, tetapi kompleksitas esensial, memahami masalah dan menspesifikasikan sebuah solusi yang benar, tidak dapat diotomasikan hingga lenyap, karena ia adalah masalahnya itu sendiri. Sebuah agen pengkodean adalah serangan paling ampuh terhadap kompleksitas aksidental yang pernah dibangun: ia menyerap sintaksis, boilerplate, pencarian API, idiom. Ia tidak berbuat apa-apa terhadap esensinya. Mengetahui apa yang dibutuhkan bisnis, memutuskan desain yang tepat, dan memastikan bahwa sebuah perubahan tertentu benar-benar memenuhi kebutuhan tanpa merusak hal lain, tetap menjadi pekerjaan manusia, dan itulah pekerjaan yang selalu sulit.

2.3 Verifikasi menjadi kendala

Satukan keduanya dan kesimpulannya menyusul. Generasi, bagian yang aksidental, kini cepat dan murah. Verifikasi, tempat esensi itu bersemayam, bahwa perubahan ini benar, bahwa ia melakukan apa yang diinginkan, bahwa ia tidak merusak apa pun, bahwa ia aman untuk dipaparkan, tidaklah demikian. Dalam setiap pipeline, throughput ditentukan oleh tahap yang paling lambat, dan ketika generasi melaju melampaui verifikasi, verifikasi menjadi kendala yang mengikat. Sebuah tim yang dapat menghasilkan sepuluh perubahan sehari tetapi memverifikasi dua akan mengirimkan dua, dan akan menumpuk tunggakan kode tak-terverifikasi yang merupakan liabilitas, bukan aset. Lebih buruk lagi, sebuah agen menghasilkan pekerjaan yang percaya diri dan tampak benar di permukaan, sehingga biaya dari kurang-memverifikasi, dari menggabungkan apa yang tampak benar padahal tidak, naik persis seiring naiknya godaan untuk melakukannya. Sisa makalah ini membahas pembangunan sebuah rangkaian yang tugasnya adalah menaikkan langit-langit verifikasi dan menyulitkan kurang-verifikasi.

3. Rangkaian itu, dan mengapa yang konvensional menang

3.1 Putaran itu

Sebuah penyiapan berbantuan AI yang baik adalah sebuah putaran, bukan sebuah perkakas. Gambar 1 menggambarkan yang kami gunakan. Seorang pengembang menyatakan sebuah niat. Claude Code, sang agen, mengubahnya menjadi sebuah perubahan pada sebuah branch, bukan pada kode yang hidup. Perubahan itu menjadi sebuah pull request GitHub, tempat dua gerbang otomatis berjalan tanpa perhatian siapa pun: pemeriksa tipe dan rangkaian continuous-integration. Vercel membangun branch itu menjadi sebuah preview deployment yang nyata dan berjalan, sebuah salinan lengkap aplikasi dengan perubahan yang hidup, dapat dijangkau di URL-nya sendiri. Seorang manusia meninjau perubahan itu, membaca diff dan mengeklik preview, di sebuah desktop atau, semakin lama, di sebuah ponsel. Barulah kemudian ia di-merge ke branch utama, yang oleh Vercel di-deploy ke produksi, didukung oleh Postgres. Hasilnya memberi makan niat berikutnya. Inti dari diagram itu adalah bahwa agen menempati satu kotak; setiap kotak lainnya adalah sebuah putaran yang menutup atau sebuah gerbang yang menangkap, dan dari sanalah keamanan dan kecepatan itu berasal.

3.2 Best-of-breed berarti konvensional

Cara biasa untuk memilih perkakas adalah memeringkatnya berdasarkan daya dan memilih yang paling cakap. Untuk sebuah rangkaian berbantuan-agen, kriterianya berbeda, dan itulah gagasan paling berguna dalam makalah ini. Sebuah agen menulis dengan paling baik perkakas yang paling banyak dilihatnya. Kompetensinya pada sebuah framework atau sebuah basis data adalah fungsi dari seberapa banyak kode benar yang menggunakan perkakas itu ada dalam pelatihannya, dan kuantitas itu mengikuti popularitas perkakas itu, dokumentasinya, dan kestabilan konvensinya. Oleh karena itu, sebuah perkakas yang arus-utama, berdokumentasi baik, dan sarat-konvensi bukan sekadar pilihan manusia yang aman; ia adalah pilihan yang padanya agen paling cakap dan paling kecil kemungkinannya mengarang sebuah API yang tidak ada. Efeknya berlipat ganda: perkakas populer memperoleh lebih banyak kode yang dihasilkan agen, yang berfungsi, yang memperkuat popularitasnya. Untuk pengembangan berbantuan AI, best-of-breed dan paling-konvensional telah menyatu, dan setiap perkakas dalam Tabel 1 dipilih dengan mengingat hal itu. Ini juga sebuah peringatan: framework eksotis yang dapat dimainkan seorang pakar manusia dengan cemerlang sering kali justru merupakan tempat agen paling lemah, karena ia paling sedikit melihatnya.

3.3 Mengapa gerbang-gerbang independen berlipat ganda

Rangkaian ini tidak mempercayai satu pun pemeriksaan tunggal. Ia memverifikasi sebuah perubahan melalui beberapa gerbang yang menyoroti hal-hal yang benar-benar berbeda: pemeriksa tipe memeriksa bentuk, pengujian continuous-integration memeriksa perilaku, preview deployment memperlihatkan hasil yang berjalan, dan peninjau manusia menilai niat. Karena gerbang-gerbang itu sebagian besar independen, kegagalan tangkap mereka berlipat alih-alih bertambah: sebuah cacat mencapai produksi hanya jika setiap gerbang gagal menangkapnya, sehingga empat gerbang sederhana yang masing-masing menangkap sebagian besar dari apa yang dilihatnya hanya meloloskan sebagian kecil dari hasil kali apa yang mereka lewatkan. Inilah prinsip pertahanan berlapis (defence-in-depth) yang telah lama dikenal dalam rekayasa keselamatan sebagai pelapisan penghalang-penghalang yang tak sempurna (Reason, 2000), dan ia memiliki korolari praktis yang tajam. Menghapus atau melemahkan satu gerbang, melewati preview, mematikan sebuah tipe yang strict, menyetujui tanpa membaca, tidak menambahkan sedikit risiko; ia mengalikan laju lolos dengan kebalikan dari apa yang dahulu ditangkap gerbang itu. Cara termurah untuk tetap aman adalah menjaga beberapa gerbang yang berbeda dan tak sempurna tetap jujur, yang persis itulah yang dirancang untuk dilakukan rangkaian ini.

4. Agen itu: bagaimana Claude Code cocok

Claude Code adalah agennya: sebuah perkakas yang membaca basis kode, menulis dan menyunting berkas, menjalankan perintah, mengeksekusi pengujian, dan membuka pull request, bekerja dari sebuah instruksi dan mengoreksi dirinya sendiri terhadap hasil yang dilihatnya. Bagaimana ia dijalankan lebih penting daripada kemampuan mentah model, dan tiga hal tentangnya layak mendapat perhatian seorang praktisi.

Yang pertama adalah konteks. Sebuah agen hanya sebaik apa yang diketahuinya tentang basis kode Anda, dan artefak tunggal berdaya-ungkit tertinggi adalah sebuah berkas konvensi yang ter-commit, dalam kasus kami sebuah CLAUDE.md proyek, yang memberi tahu agen aturan rumah: bagaimana proyek ditata, bagaimana menjalankan pemeriksa tipe dan pengujian, apa yang harus di-deploy dan bagaimana, apa yang tak boleh disentuh. Agen membacanya pada setiap kali jalan, sehingga sebuah koreksi yang dituliskan sekali berhenti berulang. Di sekelilingnya terdapat sebuah permukaan yang lebih luas, skills yang dapat digunakan ulang untuk tugas-tugas berulang, hooks yang berjalan pada pemanggilan perkakas untuk menegakkan sebuah aturan secara mekanis, dan server MCP yang memberi agen akses bertipe ke sistem-sistem luar, GitHub di antaranya, sehingga ia dapat membuka dan memperbarui pull request sebagai tindakan kelas-satu alih-alih dengan screen-scraping. Rekayasa konteks (context engineering), memutuskan apa yang seharusnya diketahui dan dapat dilakukan agen, adalah pekerjaan sesungguhnya dalam mengadopsi sebuah agen, dan ia adalah higiene perangkat lunak biasa: tuliskan konvensinya, buat pemeriksaannya dapat dijalankan, jaga permukaannya tetap kecil.

Yang kedua adalah bahwa agen berjalan di dalam putaran alih-alih secara terisolasi. Ia diharapkan menjalankan sendiri pemeriksa tipe dan pengujian, membaca apa yang mereka laporkan, dan memperbaikinya, sebelum ada manusia yang melihat, sehingga gerbang-gerbang otomatis dari rangkaian itu sudah hijau pada saat sebuah pull request dibuka. Untuk tugas-tugas yang lebih besar, ia dapat menyebarkan pekerjaan ke subagent yang masing-masing membawa konteksnya sendiri dan melapor kembali, yang menjaga utas utama tetap fokus dan konteks tetap bersih. Disiplinnya adalah membiarkan umpan balik yang cepat dan murah, tipe dan pengujian, terjadi di dalam putaran agen itu sendiri, dan menyimpan umpan balik yang lambat dan mahal, yakni manusia, untuk bagian akhir.

Yang ketiga adalah di mana ia berjalan. Melampaui terminal, Claude Code berjalan sebagai sebuah sesi cloud yang dapat dijangkau dari sebuah aplikasi seluler, yang mengubah bentuk hari kerja. Sebuah perubahan dapat dimulai dari sebuah ponsel dalam perjalanan ke suatu tempat, dibiarkan berjalan di cloud, dan pull request serta preview-nya ditinjau dan disetujui dari ponsel yang sama kemudian. Kami bersikap sengaja tentang hal ini bukan karena kerja seluler adalah sebuah kebaruan melainkan karena ia mempersingkat putaran: jarak antara menyadari sesuatu dan memulai perubahan, serta antara sebuah perubahan siap dan seseorang menyetujuinya, menyusut dari hitungan jam menjadi menit, yang dalam dunia yang terikat-verifikasi justru merupakan jarak yang layak ditutup.

5. Tulang punggung: GitHub

GitHub adalah bagian dari rangkaian yang membuat segala sesuatu yang lain menjadi aman, dan ia yang paling tidak gemerlap. Ia menyimpan satu-satunya sumber kebenaran, yakni repositori, dan ia menegakkan aturan yang menjadi sandaran seluruh argumen: branch utama, yang mengirimkan ke produksi, bersifat terproteksi, dan hanya dapat dijangkau melalui sebuah pull request yang telah disetujui seorang manusia dan yang pemeriksaan status wajibnya telah lolos. Agen tidak pernah menyunting kode produksi secara langsung; ia mengusulkan, pada sebuah branch, dan usulan itu adalah sebuah diff yang dapat dibaca manusia dan dapat diuji mesin.

Pemeriksaan wajib itu adalah tempat gerbang-gerbang otomatis bersemayam. Pada setiap pull request, GitHub Actions menjalankan rangkaian yang kami haruskan sebelum apa pun di-merge: pemeriksa tipe, linter, rangkaian pengujian, dan sebuah build produksi, masing-masing merupakan status wajib yang memblokir tombol merge sampai ia hijau. Karena semua ini ditegakkan oleh platform alih-alih oleh disiplin siapa pun, mereka tidak dapat dilewati dengan terburu-buru, dan karena agen tahu mereka akan berjalan, ia memenuhinya lebih dahulu. Pull request adalah unit perubahan: kecil, mandiri, dapat ditinjau secara individual dan dapat dibatalkan secara individual, yang itulah yang menjaga tinjauan tetap murah dan riwayat tetap terbaca. Dan karena setiap perubahan adalah sebuah commit dengan seorang penulis dan sebuah pesan, riwayat itu adalah sebuah jejak audit dan pembatalannya total, apa pun yang dilakukan agen dapat dilihat, diatribusikan, dan dibatalkan. Sebuah agen pengkodean adalah aktor yang cepat, ampuh, dan dapat keliru, dan GitHub adalah struktur yang membuatnya aman untuk melepas satu agen, dengan memastikan tidak ada yang dilakukannya yang tak-ditinjau, tak-teruji, atau tak-dapat-dibalik.

6. Mata: Vercel

Membaca sebuah diff memberi tahu Anda apa yang berubah; ia tidak memberi tahu Anda apa yang dilakukan perubahan itu. Vercel menutup kesenjangan itu dengan membangun setiap pull request menjadi sebuah preview deployment: sebuah instans aplikasi yang lengkap, terisolasi, dan berjalan dengan perubahan yang telah diterapkan, di URL-nya sendiri, dibuat secara otomatis dan diperbarui pada setiap push. Inilah gerbang yang menangkap apa yang tidak ditangkap tipe dan pengujian, tata letak yang rusak, alur yang menjadi satu langkah lebih panjang, hal yang secara teknis benar namun keliru dalam penggunaan, dan itulah sebagian besar alasan mengapa rangkaian itu dapat bergerak cepat tanpa bergerak buta. Seorang peninjau, dan agen, mengeklik hasil yang sebenarnya alih-alih membayangkannya dari kode.

Yang membuat preview itu tepercaya adalah bahwa ia merupakan sebuah build nyata dari keseluruhan stack, bukan sebuah mock (Gambar 2): framework yang sama, runtime yang sama, variabel lingkungannya sendiri, dan, jika dilakukan dengan baik, basis datanya sendiri yang terisolasi atau ter-branch sehingga melatihnya tidak dapat menyentuh data produksi. Deployment bersifat immutable: masing-masing adalah sebuah build yang berbeda dan dapat dialamati, sehingga mempromosikan sebuah preview yang telah ditinjau ke produksi adalah sebuah pemindahan penunjuk alih-alih sebuah pembangunan ulang, dan sebuah rilis yang buruk adalah sebuah rollback seketika ke deployment immutable sebelumnya alih-alih sebuah hotfix yang panik. Pada saat merge ke branch utama, mesin yang sama yang membangun preview membangun produksi, sehingga hal yang ditinjau adalah hal yang dikirimkan. Dalam model rangkaian ini, preview deployment adalah sebuah gerbang verifikasi yang murah dan otomatis dengan laju tangkap yang tinggi untuk sebuah kelas cacat yang tidak dilihat gerbang lain mana pun.

7. Mulus berkat git: mengapa ketiganya cocok satu sama lain

Alasan mengapa Claude Code, GitHub, dan Vercel terasa tidak seperti tiga perkakas melainkan lebih seperti satu sistem adalah bahwa mereka berbagi satu antarmuka tunggal, dan antarmuka itu adalah git. Keluaran alami Claude Code bukanlah sebuah deployment; ia adalah sebuah branch dan sebuah pull request. Tugas GitHub adalah menyimpan commit-commit itu, menjalankan pemeriksaan, dan menampung tinjauan. Vercel mengamati repositori dan mengubah setiap branch menjadi sebuah preview dan branch utama menjadi produksi. Tak satu pun dari mereka harus diajari tentang yang lain: agen tidak pernah mempelajari sebuah API deployment, ia membuka sebuah pull request; Vercel tidak pernah mempelajari tentang agen, ia mengamati repo. Jahitan di antara mereka adalah protokol git yang sudah dibicarakan ketiganya, dan itulah mengapa menambahkan sebuah agen ke dalam rangkaian tidak mengubah apa pun tentang cara deployment bekerja, dan mengapa keseluruhan jalur dari sebuah prompt menuju produksi tidak memiliki serah-terima di dalamnya.

Konsekuensinya adalah bahwa deployment berhenti menjadi sebuah langkah yang dilakukan siapa pun dan menjadi sebuah konsekuensi dari tindakan git yang memang akan mereka lakukan. Sebuah push adalah sebuah build. Sebuah pull request adalah sebuah lingkungan preview, dibuat dan dibongkar dengan sendirinya. Sebuah merge ke branch utama adalah sebuah deploy produksi. Sebuah revert adalah sebuah rollback. Tak seorang pun menjalankan sebuah rilis; mereka melakukan merge, dan rilis itu terjadi. Tidak ada server build untuk diasuh, tidak ada skrip deploy yang bisa dikelirukan agen, tidak ada perkakas promosi terpisah, tidak ada jendela di mana seseorang telah menulis kode tetapi belum mengirimkannya. Untuk sebuah tim yang terikat-verifikasi, inilah tempat yang persis tepat untuk menghilangkan gesekan: satu-satunya tindakan manusia yang disengaja yang tersisa di jalur itu adalah tinjauan, yang merupakan satu-satunya tindakan yang seharusnya disengaja, dan segala sesuatu yang mekanis di sekelilingnya ditangani oleh perkakas yang mengamati git.

Inilah juga mengapa kemulusan itu aman alih-alih sembrono, dan kedua sifat itu berasal dari fakta yang sama. Karena deployment menumpang pada git, ia mewarisi jaminan-jaminan git: setiap deploy produksi terikat pada sebuah commit tertentu yang telah ditinjau, dengan seorang penulis dan sebuah pesan; setiap preview terikat pada sebuah branch; dan karena deployment bersifat immutable, melakukan rollback hanyalah mengarahkan produksi ke build dari sebuah commit yang lebih awal. Perkabelan yang sama yang memungkinkan sebuah perubahan mengalir dari sebuah prompt yang diketik di ponsel menuju sebuah situs langsung tanpa seorang pun menyentuh sebuah konsol deploy juga memastikan bahwa tidak ada yang mencapai situs langsung itu kecuali melalui sebuah commit yang ditinjau, dapat diatribusikan, dan dapat dibatalkan. Integrasi itu cocok bukan karena para vendor mengoordinasikannya melainkan karena ketiganya dibangun untuk memperlakukan git sebagai sumber kebenaran, dan ketika agen bergabung dengan konvensi itu, pipeline yang dibutuhkannya sudah ada di sana.

8. Medannya: Next.js

Agen harus menavigasi sebuah basis kode, dan framework basis kode itu adalah medannya. Next.js adalah sebuah pilihan yang kuat karena dua alasan yang keduanya kembali ke verifikasi. Yang pertama adalah bahwa ia TypeScript, dan tipe adalah gerbang pertama dan termurah. Dijalankan dalam mode strict, pemeriksa tipe menolak sebuah kelas kesalahan yang besar, bentuk yang keliru, field yang hilang, nilai yang mungkin null, pada saat agen menuliskannya, yang persis saat sebuah koreksi paling murah, sebelum kode berjalan dan jauh sebelum seorang manusia melihat. Kami mendorong gagasan yang sama ke tepi-tepi program, memvalidasi masukan eksternal, body permintaan, variabel lingkungan, baris basis data, terhadap sebuah skema sehingga data tak-bertipe dari luar menjadi bertipe dan teruji di batas alih-alih dipercaya begitu saja. Tipe bukanlah birokrasi di sini; ia adalah gerbang yang mengubah kesalahan paling umum agen, sebuah bentuk yang masuk akal namun keliru secara halus, menjadi sebuah coretan merah yang diperbaikinya sendiri.

Alasan kedua adalah bahwa Next.js bersifat konvensional, dan modelnya, meskipun kaya, cukup sering-ditempuh sehingga agen menuliskannya dengan fasih. Ada baiknya bersikap konkret tentang model itu, karena di situlah banyak rekayasa bersemayam. App Router merender di server secara baku: Server Components berjalan di server dan tidak pernah mengirimkan kodenya ke peramban, menjaga akses data dan secret tetap di sisi-server, sementara Client Components, yang ditandai secara eksplisit, membawa interaktivitas. Mutasi berjalan melalui Server Actions, yakni fungsi server yang dapat dipanggil langsung oleh sebuah form atau sebuah tombol, dan Route Handlers menyediakan permukaan API. Setiap rute memilih bagaimana ia merender, statis pada waktu build, diregenerasi secara inkremental menurut sebuah jadwal, atau secara dinamis per permintaan, dan di mana ia berjalan, runtime Edge yang ringan dekat dengan pengguna atau runtime Node.js yang lebih lengkap, dengan middleware yang berjalan sebelum permintaan untuk menangani hal-hal seperti autentikasi dan lokal (locale). Ini adalah banyak tuas, tetapi semuanya adalah tuas yang publik, berdokumentasi, dan stabil yang telah dilihat agen digunakan dengan benar dalam skala besar, sehingga ia meraih yang tepat, dan framework itu cukup ampuh untuk membangun sebuah produk nyata sambil tetap menjadi medan yang padanya agen paling cakap, yang, menurut argumen Bagian 3, merupakan kombinasi yang penting.

9. State: Postgres

Segala sesuatu di atas menyangkut kode, yang aman untuk diubah karena ia berversi dan dapat dibalik. Data tidak demikian: sebuah kolom yang terhapus atau sebuah migrasi yang buruk dapat menghancurkan sesuatu yang tak dapat dipulihkan commit mana pun. Postgres adalah state yang tahan lama dan transaksional di dasar rangkaian, dan disiplin di sekelilingnya sengaja dibuat lebih ketat daripada di sekeliling kode. PostgreSQL memperoleh tempatnya dengan cara yang sama seperti bagian lain dari rangkaian itu, ia adalah pilihan yang konvensional, teruji-pertempuran, dan berdokumentasi sangat baik, sehingga agen menulis SQL yang benar dan migrasi yang benar terhadapnya, dan sebuah instans terkelola menyingkirkan jerih payah operasional tanpa mengubah modelnya.

Kehati-hatian itu tercurah pada perubahan. Perubahan skema adalah migrasi: berkas-berkas yang terurut dan berversi yang ter-commit ke repositori dan ditinjau seperti perubahan lainnya, dijalankan terhadap preview sebelum produksi, dan ditulis agar dapat dibalik. Sebuah basis data langsung tidak dapat diubah seperti sebuah basis data yang baru, sehingga sebuah perubahan berisiko dibuat sebagai sebuah urutan perubahan yang aman, yakni pola expand and contract (Ambler & Sadalage, 2006): tambahkan kolom atau tabel baru dan mulai menulis ke dalamnya, lakukan backfill, pindahkan pembacaan ke sana, dan baru kemudian, dalam sebuah deployment berikutnya, singkirkan bentuk yang lama, sehingga pada setiap langkah antara, kode yang berjalan dan skema itu kompatibel dan langkahnya dapat dibalik. Postgres membantu dengan membuat sebagian besar perubahan skema bersifat transaksional, sehingga sebuah migrasi yang gagal di-rollback dengan bersih alih-alih meninggalkan basis data setengah-berubah. Dua poin operasional penting dalam sebuah latar serverless, di mana banyak instans fungsi berumur-pendek masing-masing menginginkan sebuah koneksi: sebuah connection pooler bukanlah opsional, karena sebuah basis data memiliki batas koneksi yang keras yang akan dihabiskan oleh sekawanan worker serverless; dan row-level security memungkinkan basis data itu sendiri menegakkan siapa yang boleh melihat baris yang mana, sebuah jaring pengaman yang tidak bergantung pada aplikasi menjalankan setiap kueri dengan benar. Aturan yang kami pegang sederhana dan layak dinyatakan: agen boleh mengusulkan sebuah migrasi, tetapi sebuah migrasi adalah satu-satunya jenis perubahan yang selalu dibaca manusia dengan perhatian penuh, karena ia adalah satu-satunya jenis yang tak dapat dibatalkan rangkaian ini sepenuhnya.

10. Gerbang manusia dan bagaimana ia gagal

Setiap gerbang otomatis dalam rangkaian ini ada untuk membuat gerbang manusia menjadi murah, bukan untuk menghapusnya. Peninjau pada pull request melakukan satu hal yang tak diotomasikan gerbang mana pun: menilai apakah perubahan itu adalah apa yang sebenarnya diinginkan bisnis dan apakah ia aman untuk dipaparkan, pertanyaan-pertanyaan yang diberi informasi oleh tipe, pengujian, dan preview tetapi tidak dijawabnya. Tujuan keseluruhan dari rangkaian itu adalah menyampaikan kepada peninjau itu sebuah perubahan yang kecil, berjalan, dan telah-diperiksa-sebelumnya sehingga penilaiannya cepat dan berdasar kuat. Tetapi gerbang itu memiliki moda-moda kegagalan yang khas, dan menamainya adalah bagian dari menggunakan rangkaian itu dengan baik.

Yang pertama adalah asal stempel (rubber-stamping). Ketika agen biasanya benar, peninjau belajar untuk menyetujui dengan cepat, dan tinjauan itu merosot menjadi sebuah formalitas yang tidak menangkap apa pun. Pertahanannya adalah menjaga perubahan tetap kecil, sehingga membacanya dengan benar tetap murah, dan memperlakukan preview sebagai wajib, bukan opsional: sebuah tinjauan yang tidak mengeklik perubahan yang berjalan bukanlah sebuah tinjauan. Yang kedua adalah terlalu percaya (over-trust), keyakinan bahwa karena kode itu lolos pemeriksa tipe dan pengujian maka ia pastilah benar; gerbang-gerbang itu menangkap bentuk dan perilaku tetapi bukan niat, dan manusia adalah satu-satunya gerbang atas niat. Yang ketiga adalah kelelahan skala (scale fatigue): sebuah agen dapat membuka lebih banyak pull request daripada yang dapat ditinjau sebuah tim secara serius, dan sebuah tunggakan perubahan yang setengah-ditinjau adalah rezim terikat-verifikasi yang menegaskan dirinya kembali. Jawabannya bukanlah meninjau lebih cepat melainkan menghasilkan dengan lebih sengaja, membiarkan agen menghasilkan hanya apa yang benar-benar dapat diverifikasi tim, karena perubahan yang tak-terverifikasi adalah sebuah liabilitas berapa pun volumenya.

11. Biaya dan trade-off

Rangkaian itu adalah seperangkat pilihan, dan kejujuran menuntut pernyataan tentang biayanya. Yang paling nyata adalah keterikatan (coupling): Next.js dan Vercel berasal dari perusahaan yang sama, dan membangun di atasnya membeli sebuah jalur yang mulus dan terintegrasi dengan harga berupa suatu derajat lock-in, baik ke sebuah framework yang bergerak cepat dan kadang merusak kompatibilitas antar-versi mayor, maupun ke sebuah platform hosting yang harga dan primitifnya Anda adopsi. Kami menilai pertukaran itu sepadan demi kecepatan dan kualitas putaran preview, tetapi ia adalah sebuah ketergantungan yang nyata, dan sebuah tim seharusnya menjaga logika domain dan datanya tetap portabel sehingga framework dan host tetap menjadi infrastruktur yang dapat diganti alih-alih menjadi produk itu sendiri. Biaya kedua adalah disiplin yang dituntut gerbang itu: rangkaian itu hanya seaman tinjauan yang menjadi puncaknya, dan sebuah tim yang membiarkan gerbang manusia melapuk menjadi asal stempel memiliki sebuah cara cepat untuk mengirimkan kesalahan yang percaya diri, yang lebih buruk daripada sebuah cara lambat untuk mengirimkan kesalahan yang dipertimbangkan. Yang ketiga adalah akses agen itu: sebuah perkakas yang dapat menyunting repositori dan memicu deployment adalah aktor yang kuat, dan ia harus dibatasi cakupannya sebagai aktor demikian, dengan proteksi branch, dengan kredensial berhak-akses-terkecil, dengan secret yang dijauhkan dari repositori dan dari jangkauan agen, dan dengan perubahan izin dan infrastruktur yang ditinjau dengan kehati-hatian khusus. Yang keempat adalah ketakterbalikan data, yang dibahas di atas: satu-satunya tempat jaring pengaman rangkaian itu memiliki lubang, dan tempat untuk mencurahkan perhatian manusia paling banyak. Tak satu pun dari ini merupakan alasan untuk tidak mengadopsi rangkaian itu; masing-masing adalah alasan untuk mengadopsinya dengan sengaja.

12. Bagaimana kami menjalankan platform Nashua 360 di atasnya

Rangkaian dalam makalah ini bukanlah sebuah usulan yang telah kami teorikan; ia adalah rangkaian yang menjadi landasan kami membangun dan mengoperasikan produk kami sendiri. Nashua 360 Enterprise Platform adalah sebuah aplikasi Next.js, di-deploy di Vercel, didukung oleh Postgres, dengan sumbernya di GitHub, dan ia dikembangkan dengan Claude Code sebagai agen, termasuk dari aplikasi seluler ketika sebuah perubahan lebih baik dimulai atau disetujui jauh dari meja kerja. Sebuah berkas konvensi yang ter-commit memberi tahu agen aturan rumah; setiap perubahan pada platform adalah sebuah branch dan sebuah pull request; setiap pull request memperoleh pemeriksaan tipenya, jalannya continuous-integration-nya, dan preview deployment-nya di sebuah salinan stack yang terisolasi; tidak ada yang mencapai branch produksi tanpa seorang manusia membaca diff dan mengeklik preview; dan migrasi adalah perubahan yang kami baca paling keras. Kami tidak menyusun rangkaian ini untuk menjadi modis. Kami menyusunnya karena, begitu kami menerima bahwa sebuah agen telah membuat generasi menjadi murah dan verifikasi menjadi kendala, setiap mata rantai menyusul dari pertanyaan tentang bagaimana memverifikasi dengan cepat dan aman, dan karena penalaran yang sama yang menjadikannya tepat bagi kami, perkakas konvensional yang ditangani agen dengan baik, dibungkus dalam putaran dan gerbang yang menangkap kesalahannya, menjadikannya tepat bagi sebagian besar tim yang membangun perangkat lunak web hari ini. Bahwa ia juga memungkinkan sebuah produk yang serius dikembangkan dari sebuah ponsel di dalam kereta bukanlah alasan kami memilihnya, tetapi ia adalah sebuah tanda yang adil tentang betapa jauh bentuk pekerjaan ini telah berubah.

13. Keberatan dan tanggapan

Ini hanyalah continuous delivery dengan sebuah agen yang dibautkan. Sebagian besar, memang sengaja. Praktik-praktik yang menjadi sandaran rangkaian itu, kontrol versi, perubahan kecil yang ditinjau, continuous integration, deployment terotomasi dengan preview dan rollback, adalah disiplin yang telah mapan dari penyampaian perangkat lunak modern (Humble & Farley, 2010; Forsgren et al., 2018), dan itulah intinya: agen tidak menggantikan disiplin itu, ia menaikkan premi atasnya, karena disiplin itulah yang memasok verifikasi yang kini dituntut oleh kecepatan agen. Kontribusinya bukanlah sebuah praktik baru melainkan argumen tentang mengapa praktik-praktik lama justru lebih penting, bukan kurang penting, begitu generasi menjadi murah.

Sebuah model yang lebih baik akan membuat perkakas ini tak diperlukan. Tidak akan, karena perkakas ini menangani bagian yang tidak disentuh oleh sebuah model yang lebih baik. Sebuah agen yang lebih cakap menghasilkan lebih cepat dan, dalam sebuah dunia yang terikat-verifikasi, menghasilkan lebih cepat tidak menaikkan apa yang sebenarnya dikirimkan; hanya memverifikasi lebih cepatlah yang melakukannya. Model yang lebih baik itu juga menghasilkan lebih banyak kode, lebih cepat, untuk diperiksa seorang manusia, yang membuat gerbang-gerbang itu lebih diperlukan, bukan kurang. Rangkaian itu adalah sebuah taruhan pada verifikasi, dan taruhan itu menjadi lebih baik, bukan lebih buruk, seiring membaiknya generasi.

Anda terkunci ke dalam stack satu vendor. Sebagian, dan kami telah mengatakannya. Keterikatan Next.js dan Vercel adalah sebuah biaya nyata yang diterima demi sebuah manfaat nyata, yakni putaran preview terintegrasi yang menjadi pusat seluruh argumen. Mitigasinya adalah menjaga logika yang esensial, kode domain dan basis data, tetap portabel, dan memperlakukan framework dan host sebagai infrastruktur yang dapat diganti. Sebuah tim dengan selera risiko yang berbeda dapat mempertahankan bentuk rangkaian itu, agen, kontrol versi, preview terisolasi, framework bertipe, basis data yang ditinjau, pada komponen-komponen lain.

14. Keterbatasan

Ini adalah nasihat yang ditujukan bagi praktisi, dan batas-batasnya perlu dinyatakan. Ia adalah sebuah rekomendasi yang beralasan dan berpijak pada penggunaan kami sendiri, bukan sebuah perbandingan terkendali; kami belum mengukur rangkaian itu terhadap alternatif-alternatifnya. Perkakas-perkakas spesifik itu mutakhir per akhir 2026, dan ini adalah bidang yang bergerak cepat: argumennya, bahwa verifikasi adalah kendalanya dan bahwa rangkaian itu harus dibaca sebagai putaran dan gerbang, dimaksudkan untuk bertahan lebih lama daripada perkakas tertentu mana pun, tetapi perkakas tertentu itu akan berubah, dan seorang pembaca seharusnya mempertahankan argumennya dan memeriksa ulang bagian-bagiannya. Rekomendasi itu dibatasi cakupannya pada jenis perangkat lunak yang kami bangun, aplikasi web dengan sebuah basis data, dan kurang langsung berlaku pada domain-domain dengan kendala yang berbeda, seperti sistem di mana biaya sebuah gerbang verifikasi itu sendiri bersifat menghalangi, atau di mana tidak ada agen yang telah cukup melihat stack-nya untuk dapat dipercaya mengerjakannya. Dan keamanan rangkaian itu bersandar pada sebuah gerbang manusia yang dibuat murah oleh rangkaian itu tetapi tak dapat dibuatnya otomatis; sebuah tim yang tak bersedia menjaga gerbang itu tetap jujur seharusnya mengharapkan kecepatannya tanpa keamanannya.

15. Kesimpulan

Sebuah agen pengkodean membuat menulis perangkat lunak menjadi cepat, dan dengan melakukannya ia memindahkan bagian yang sulit ke tempat terang. Generasi, bagian yang dahulu mendominasi hari, menjadi murah; verifikasi, memutuskan apa yang harus dibangun dan memastikan hasilnya benar, tidak, dan menjadi kendalanya. Pelajaran bagi perkakas adalah bahwa nilai dari sebuah penyiapan berbantuan AI tidak terletak pada agen melainkan pada rangkaian di sekelilingnya yang memungkinkan sebuah tim memverifikasi pada kecepatan agen menghasilkan dan menangkap kesalahannya sebelum pengguna melakukannya. Kami membangun dan menjalankan platform Nashua 360 di atas sebuah rangkaian semacam itu: Claude Code untuk menulis, dalam sebuah putaran bersama pemeriksaan dan dapat dijangkau dari sebuah ponsel; GitHub untuk menjadikan setiap perubahan sebuah diff yang ditinjau dan dapat dibalik di balik sebuah branch yang terproteksi; Vercel untuk memberi setiap perubahan preview berjalannya sendiri dan setiap rilis sebuah rollback seketika; Next.js sebagai sebuah medan bertipe dan konvensional yang tipenya adalah gerbang pertama; dan Postgres sebagai state yang tahan lama yang diubah melalui migrasi yang ditinjau dan dapat dibalik. Setiap mata rantai menutup sebuah putaran atau menambahkan sebuah gerbang, gerbang-gerbang itu independen sehingga tidak ada satu pun di antaranya yang harus sempurna, dan keseluruhannya dipilih berdasarkan sebuah kriteria yang khas untuk momen ini: bahwa untuk sebuah agen, perkakas yang konvensional adalah yang cakap. Tulis dengan cepat, verifikasi lebih cepat, dan jangan biarkan apa pun mencapai produksi yang belum dilihat seseorang berjalan. Itulah keseluruhannya, dan itu sudah cukup.

Lampiran A. Daftar periksa adopsi

Praktik-praktik di bawah ini adalah yang membuat rangkaian itu aman alih-alih sekadar cepat. Tak satu pun yang baru; disiplinnya itulah nilainya.

Referensi

Ambler, S. W., & Sadalage, P. J. (2006). Refactoring databases: Evolutionary database design. Addison-Wesley. ISBN 978-0-321-29353-5.

Bacchelli, A., & Bird, C. (2013). Expectations, outcomes, and challenges of modern code review. In Proceedings of the 35th International Conference on Software Engineering (ICSE) (pp. 712–721). IEEE. https://doi.org/10.1109/ICSE.2013.6606617

Beck, K. (2000). Extreme programming explained: Embrace change. Addison-Wesley. ISBN 978-0-201-61641-5.

Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. Computer, 20(4), 10–19. https://doi.org/10.1109/MC.1987.1663532

Chen, M., Tworek, J., Jun, H., et al. (2021). Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374. https://arxiv.org/abs/2107.03374

Anthropic (2026). Claude Code documentation. https://code.claude.com/docs

Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organizations. IT Revolution Press. ISBN 978-1-942788-33-1.

Fowler, M. (2006). Continuous integration. martinfowler.com. https://martinfowler.com/articles/continuousIntegration.html

GitHub (2026). GitHub documentation. https://docs.github.com

Humble, J., & Farley, D. (2010). Continuous delivery: Reliable software releases through build, test, and deployment automation. Addison-Wesley. ISBN 978-0-321-60191-9.

Vercel (2026). Next.js documentation. https://nextjs.org/docs

Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot. arXiv preprint arXiv:2302.06590. https://arxiv.org/abs/2302.06590

PostgreSQL Global Development Group (2026). PostgreSQL documentation. https://www.postgresql.org/docs/

Reason, J. (2000). Human error: Models and management. BMJ, 320(7237), 768–770. https://doi.org/10.1136/bmj.320.7237.768

Sadowski, C., Söderberg, E., Church, L., Sipko, M., & Bacchelli, A. (2018). Modern code review: A case study at Google. In Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP) (pp. 181–190). ACM. https://doi.org/10.1145/3183519.3183525

Vercel (2026). Vercel documentation. https://vercel.com/docs