Batas repository mengubah cara kerja
Awalnya saya menganggap pilihan satu atau dua repository sebagai preferensi organisasi. Saat bekerja dengan AI coding assistant, boundary tersebut menjadi keputusan operasional.
Sebuah fitur jarang berhenti di frontend atau backend. Satu field baru dapat memengaruhi schema, migration, API contract, validation, query, form, dan E2E test.
Jika bagian tersebut berada di workspace terpisah, assistant hanya melihat setengah perubahan kecuali saya terus memberikan context. Bagian yang tidak terlihat akan berubah menjadi asumsi.
Mandor Plate menyimpan seluruh alur di satu Turborepo. Tujuannya bukan membuat repository besar, tetapi membuat satu fitur mudah ditelusuri.
Alur yang perlu dilihat assistant
Untuk fitur dashboard, dependency path yang berguna adalah:
Graph ini lebih penting daripada jumlah package. Assistant perlu menemukan lokasi sebuah istilah didefinisikan, diterapkan, dan dibuktikan melalui test.
Shared contract memberi satu vocabulary untuk fitur. Jika organizationId berubah, repository search dapat menemukan producer dan consumer tanpa melewati boundary repository.
Satu workspace belum cukup
Menempatkan kode di satu folder tidak otomatis menghasilkan context yang baik. Monorepo tetap sulit dipahami jika ownership dan arah dependency tidak jelas.
Saya menjaga beberapa aturan tetap eksplisit:
- API memiliki domain behavior dan persistence.
- Web app memiliki presentation dan user workflow.
- Shared contract berisi data agreement, bukan domain service.
- Package menyediakan public entry point dan menghindari deep import.
- Root command menjalankan pemeriksaan lintas package.
Aturan ini mengurangi jumlah lokasi yang masuk akal untuk sebuah perubahan. Manusia mendapat manfaat lebih dulu; AI memperoleh kejelasan yang sama.
Vertical slice menghasilkan feedback lebih baik
Saya meminta assistant menyelesaikan satu vertical slice, bukan membuat beberapa layer yang tidak terhubung.
Pekerjaan dimulai dari contract, melewati API dan database, lalu selesai pada UI dan test. Setiap tahap meninggalkan bukti untuk tahap berikutnya.
contract -> API rule -> migration -> web mutation -> UI state -> E2E
Urutan ini memperlihatkan pekerjaan yang belum lengkap lebih awal. UI yang berhasil compile tetapi mengirim bentuk salah akan gagal terhadap contract atau API sebelum dianggap selesai.
Command lint, typecheck, unit, dan E2E pada root memberi definition of done yang sama. Tanpa feedback yang dapat dijalankan, context lebih besar hanya membantu AI membuat perubahan besar yang belum diverifikasi.
Biayanya tetap ada
Monorepo menambah jumlah kode yang dapat dilihat setiap tool. Prompt yang tidak fokus dapat membuat assistant menyentuh package lain hanya karena lokasinya berdekatan.
Build configuration juga menjadi bagian dari produk. Task dependency, caching, environment variable, dan package boundary membutuhkan maintenance.
Solusinya bukan menyembunyikan repository lagi. Saya membatasi pekerjaan berdasarkan feature path, menyebut owning package, dan mewajibkan pemeriksaan yang relevan sebelum memperluas scope.
Repository terpisah tetap tepat ketika team, release cycle, access control, atau runtime ownership benar-benar independen. Kemudahan AI tidak boleh menghapus boundary tersebut.
Pelajaran yang saya dapat
Manfaat utamanya bukan karena AI dapat mengedit lebih banyak file. Assistant dapat memeriksa bukti yang menghubungkan file-file tersebut sebelum mengubahnya.
Context boundary yang berguna menggabungkan kode dalam satu tempat, ownership yang jelas, terminology bersama, dan pemeriksaan yang dapat dijalankan.
Tanpa batas tersebut, monorepo hanya memberi search space lebih besar. Dengan batas yang jelas, monorepo menjadi peta dari perubahan produk menuju implementasi yang sudah diverifikasi.