Setiap penyebaran Asana memiliki konsol admin. Di sinilah admin TI mengonfigurasi cara perusahaan mereka menggunakan Asana, seperti menyesuaikan persyaratan kata sandi, peran dan izin, apakah file dapat dilampirkan dari Dropbox, dan siapa yang dapat melihat proyek baru secara default.
Seiring pertumbuhan Asana, konsol admin menumpuk logika kustom dan tambal-sulam sekali pakai selama bertahun-tahun, sehingga membuat biaya pembuatan dan pemeliharaan kontrol administratif menjadi semakin mahal. Contohnya, satu pengaturan administratif: privasi default untuk proyek baru. Admin memilih apakah proyek baru awalnya terlihat oleh seluruh organisasi, terlihat oleh timnya, atau bersifat privat untuk anggota yang diundang. Mudah dijelaskan, tetapi ada banyak kompleksitas yang tersembunyi di dalamnya:
Apakah fitur ini ada di paket pelanggan?
Apakah mereka dulu membayarnya, lalu berhenti, dan terjebak pada pengaturan yang tidak dapat mereka ubah lagi?
Apakah mereka pelanggan HIPAA atau FedRAMP, yang hanya peran dengan hak akses lebih tinggi yang dapat mengeditnya?
Apakah salah satu pilihan menjadi tidak tersedia karena pengaturan lain?
Perlukah banner info ditampilkan untuk menjelaskan batasan saat ini?
Setiap tim yang ingin menambahkan kontrol admin harus memastikan semua itu benar. Sebagian besar memutuskan bahwa hal itu tidak sepadan, dan seiring waktu, kesenjangan antara apa yang bisa dilakukan Asana dan apa yang bisa dikendalikan admin semakin melebar. Hal ini diilustrasikan dengan fakta bahwa beberapa kontrol hanya dapat dikonfigurasi di tingkat seluruh perusahaan, sehingga admin TI kesulitan menerapkan kontrol hanya pada sebagian kecil pengguna mereka.
Berikut adalah cuplikan untuk dialog pengaturan privasi proyek, yang digunakan untuk menentukan apakah pengaturan tersebut harus dinonaktifkan dan apakah banner harus ditampilkan:
Ada banyak logika yang harus diurai di sana - lisensi fitur, tata kelola, penggantian karena struktur penyebaran, dan peran pengguna, terutama untuk peninjau. Agar teliti, Anda harus membangun kembali matriks pengujian dalam pikiran Anda untuk menentukan apakah matriks tersebut benar.
Dan itu baru dialognya. Apakah baris tersebut muncul di halaman pengaturan atau tidak diputuskan di tempat lain, dan juga secara tidak konsisten:
Tiga baris, tiga mekanisme, dan kontrol tidak selalu berada di file yang sama. Jadi, untuk menjawab "pengaturan mana yang sebenarnya dilihat oleh pelanggan ini?" Anda tidak hanya harus membaca setiap baris, tetapi juga harus menelusuri setiap komponen. Pertanyaan itu muncul cukup sering: dukungan pelanggan yang mencoba menjelaskan mengapa suatu pengaturan menghilang bagi pelanggan, PM yang menginginkan jawaban langsung tentang apakah kontrol baru merupakan perubahan cepat atau perubahan dua minggu, pegawai baru yang mencoba menemukan satu tempat yang menentukan apa yang dapat dilihat oleh pengguna tertentu.
Secara umum, ada empat hal yang membuat bekerja di konsol admin menjadi mahal:
Mahal untuk ditinjau. Logika berada di mana pun pembuatnya menempatkannya, jadi PR dapat memperkenalkan perilaku khusus tanpa terlihat jelas bagi peninjau, dan kebenaran bukanlah sesuatu yang dapat Anda verifikasi dengan mudah hanya dengan membacanya.
Kurangnya standardisasi menutupi bug. Kami memiliki bug lama yang sulit dideteksi. Banyak bug disebabkan oleh perbedaan antara spesifikasi produk dan implementasi, yang diakibatkan oleh banyaknya implementasi khusus. Tim mengambil keputusan sewenang-wenang, sehingga setiap kontrol memiliki keanehan tersendiri.
Biaya perubahan yang mahal. Untuk membuat satu perubahan bagi pengguna akhir, Anda harus menemukan setiap tempat aturan dikodekan, dan jarang ada satu titik definisi.
Biaya pengujian mahal. Menyiapkan pengujian memerlukan pengetahuan mendalam tentang status backend, dan pengujian manual komprehensif terhadap penyebaran akhir tidak memungkinkan karena banyaknya dimensi yang berinteraksi.
Memperkenalkan kerangka kerja
Kami membuat kerangka kerja deklaratif untuk kontrol administratif yang berfungsi sebagai sumber kebenaran dalam basis kode. Kontrol kini menyatakan apa adanya:
Setiap bidang di sini dipetakan ke cabang dari dialog di atas: requiredAdminRole adalah pemeriksaan HIPAA/super-admin, upsellBehavior adalah dua cabang upsell, dan churnBehavior adalah kasus pelanggan yang berhenti berlangganan, yang memungkinkan mereka memulihkan pengaturan default dan tidak ada yang lain.
Sebagai bagian dari proses ini, kerangka kerja menampilkan hook yang digunakan oleh para teknisi untuk mendapatkan status kontrol yang dihitung. Lihatlah tampilan dialog privasi proyek yang sama sekarang:
Rantai if banner digabungkan menjadi satu komponen bersama yang digerakkan oleh hook terpusat. Kerangka kerja menangani logika kombinatorial dari semua skenario yang berbeda, dan SME yang bertanggung jawab untuk memeliharanya, yang memahami produk administrasi secara mendalam, dapat dengan yakin membuat perubahan besar-besaran. Sekarang kami menggunakan pengetikan yang ketat untuk memandu para implementor agar mengisi informasi wajib yang diperlukan untuk menampilkan pengaturan mereka dengan benar dalam semua skenario yang mungkin terjadi. Yang terpenting, mereka tidak perlu memahami seluk-beluk skenario tersebut, atau bagaimana skenario tersebut berinteraksi.
Pengaturan ini dapat diakses melalui baris di UI Konsol Admin. Visibilitas baris-baris tersebut mendapatkan perlakuan yang sama, dan di sinilah peran kerangka kerja kedua. Baris dalam registri pengaturan tidak menjelaskan aturan visibilitasnya sendiri, melainkan mengaitkannya dengan kontrol yang merepresentasikannya:
Larik kontrol adalah nilai tambah. Array ini berisi objek ProjectDefaultPrivacy yang sama dengan yang diberikan dialog ke useAdminConsoleControl, dan registri menjalankannya melalui sumber kebenaran yang sama, sehingga halaman dan dialog tidak dapat bertentangan. Dulu, perhitungan dilakukan secara terpisah, sehingga adanya perbedaan dapat menyebabkan dua mode kegagalan: baris yang terlihat tetapi membuka dialog yang tidak dapat Anda gunakan, dan pengaturan yang dibayar pelanggan tanpa baris untuk mengaksesnya. Memusatkannya menghilangkan kategori bug ini.
Pengujian yang mengadopsi kerangka kerja terpusat sangat meningkatkan pengalaman peninjau PR. Contohnya, lihat pengujian visibilitas baris, yang menjawab pertanyaan "pengaturan mana yang sebenarnya dilihat oleh pelanggan ini?" pertanyaan dari sebelumnya. Alih-alih kode pengujian, skenario hanyalah data: persona, status domain, dan halaman tempat skenario ditampilkan.
Dan baris hanya mencantumkan skenario bernama mana yang harus ditampilkan di dalamnya:
Tidak ada panggilan render atau pernyataan yang harus ditulis. Rangkaian pengujian dinamis membaca katalog dan memeriksa setiap baris terhadap setiap skenario yang disebutkan di dalamnya. Katalog sekarang menjadi satu-satunya tempat yang menunjukkan apa yang dilihat pelanggan, yang diperiksa oleh mesin . Tidak perlu lagi mengandalkan peninjau kode yang teliti atau penulis untuk mengidentifikasi dan menulis kasus pengujian mereka sendiri dengan benar.
Di dunia AI
Kami memulai pekerjaan ini pada akhir tahun 2025 karena kami mengantisipasi perlunya memberdayakan para teknisi non-SME untuk membangun dengan percaya diri di konsol admin. Pada saat itu, golnya bukan untuk mengoptimalkan kinerja LLM, tetapi ternyata, menstandarkan dan menyederhanakan pengalaman bagi para teknisi juga berdampak sama bagi agen AI.
Sebelum membangun kerangka kerja ini, kami memang menggunakan AI untuk mengatasi masalah migrasi ini, yang secara teknis berhasil. Masalahnya adalah, baik agen maupun peninjau tidak dapat memastikan apakah pengujian tersebut benar-benar akurat, yang berarti ada rasa percaya diri yang keliru dan kesenjangan yang tidak terdeteksi. AI tidak memperbaiki kurangnya struktur, AI hanya menghasilkan lebih banyak kode, lebih cepat, di atas struktur apa pun yang sudah ada. Google membuat argumen serupa untuk sistem tipe Go dalam pengembangan yang dibantu AI: tipe statis bertindak sebagai jaring pengaman otomatis, karena LLM rentan terhadap properti halusinasi dan ketidaksesuaian tipe di seluruh file. TypeScript tidak seketat Go secara statis, tetapi kerangka kerja dapat membangun jaminan yang sama di atasnya: tentukan tipe kontrol satu kali di tingkat kerangka kerja, dan setiap implementasi harus sesuai dengannya pada titik penggunaan.
Setelah kerangka kerja siap, kami mulai mempersiapkan delegasi dan paralelisasi. Saya menggunakan alat pengembangan berbasis spesifikasi baru kami [placeholder tautan: postingan blog teknis tentang pengembangan berbasis spesifikasi: Blog Teknis Asana - Pengembangan berbasis spesifikasi: Bagian-bagian yang Baik untuk membangun keterampilan yang menyelesaikan pekerjaan dari awal hingga akhir. Ini mengodekan seluruh konversi: menentukan kontrol, memanggil hook, mengganti banner, memperbarui fragmen, menambahkan pengujian deklaratif baru, serta daftar periksa yang diperbarui secara otomatis dan log kasus khusus dari konversi sebelumnya. Dari total ~150 migrasi, 91% tidak memerlukan revisi setelah ditinjau.
Meminta agen untuk menulis PR tidak memerlukan banyak upaya, dan meninjau PR tersebut juga tidak memerlukan banyak upaya. Karena semuanya dinyatakan dengan cara yang dapat diprediksi, peninjau tidak perlu menjadi SME di bidang administrasi untuk memeriksa apakah implementasi sesuai dengan spesifikasi produk. Yang terpenting, ini membuka kumpulan peninjau yang memenuhi syarat untuk kelompok teknisi yang jauh lebih luas, yang meningkatkan kecepatan lebih dari sekadar corong yang lebih lebar di bagian atas yang membuat PR. Kami tidak sendirian dalam memikirkan kembali peninjauan untuk era ini: GitHub membangun kembali agen peninjauan Copilot sendiri berdasarkan bukti PR terstruktur untuk membantu peninjau manusia menemukan pertanyaan yang tepat dengan lebih cepat, sehingga mengurangi biaya peninjauan mereka sekitar 20%.
Migrasi awal ~150 item yang mencakup beberapa kerangka kerja dianggap sebagai pekerjaan teknis manual satu kali dari awal hingga akhir. Dengan membangun kerangka kerja terlebih dahulu, lalu mendelegasikan migrasi kepada para teknisi yang memantau agen setelahnya, kami dapat menyelesaikan seluruh upaya ini lebih dari sebulan lebih cepat dari rencana semula.
Apa selanjutnya?
Membuat kerangka kerja ini tidak pernah menjadi proyek tersendiri. Ini muncul karena kebutuhan, dari peta jalan yang perlu diparalelkan dan diskalakan, dengan staf yang terbatas dan berubah-ubah selama proses berlangsung, dan tanpa mengharuskan setiap kontributor menjadi pakar domain terlebih dahulu. Kami telah melihatnya berfungsi di luar tim yang membangunnya: 18 dari 66 kontrol dalam kerangka kerja saat ini dibuat oleh para insinyur dari 8 tim yang berbeda.
Sekarang, kami mencari tempat berikutnya untuk melakukan investasi semacam ini. Bahkan, argumennya kini lebih kuat daripada sebelum kami memulai: Kerangka kerja deklaratif yang dirancang dengan baik tidak hanya membuat peninjauan lebih mudah, tetapi juga menentukan apakah agen menghasilkan sesuatu yang andal, atau hanya sesuatu yang cepat. Ini juga yang mungkin membuat tinjauan otonom masuk akal: Cloudflare telah membangun sistem di mana peninjau AI menyetujui kode yang bersih dan memblokir masalah nyata secara mandiri, dan itu hanya berfungsi karena input mereka cukup terstruktur sehingga dapat dipercaya oleh peninjau. Apakah input kami cukup terstruktur untuk mencoba hal yang sama adalah pertanyaan berikutnya yang bagus.
Tentang penulis
Leo Zhang adalah insinyur perangkat lunak di tim Admin Foundations, yang memberdayakan admin TI dalam mengelola organisasi mereka. Saat ini, ia meningkatkan pengalaman pengembangan teknisi produk lainnya di Konsol Admin dengan berinvestasi pada kerangka kerja teknis yang mendukung produk kami.
Ucapan Terima Kasih untuk Tim
Merancang, menerapkan, menguji, dan mensosialisasikan perubahan ini merupakan upaya besar dari tim. Hal ini dapat terwujud berkat kontribusi para teknisi lain di tim Admin Foundations: Yunus Rahbar, Maryam Booshehrian, Saverio Castelli, Bronwyn Damm, Cindy Yu, Calvin Norton, dan Jaxsun McCarthy Huggan. Walter Li dari tim tiger kesuksesan agen sangat membantu dalam menyiapkan alat AI yang tepat untuk migrasi ini.
Referensi
Lan Cheng, Emerson Murphy-Hill, Mark Canning, Ciera Jaspan, Collin Green, Andrea Knight, Nan Zhang, dan Elizabeth Kammer, "Apa yang Meningkatkan Produktivitas Developer di Google? Code Quality," ESEC/FSE '22, November 2022. https://doi.org/10.1145/3540250.3558940
"Orchestrating AI Code Review at Scale," Blog Cloudflare, April 2026. https://blog.cloudflare.com/ai-code-review/
Napalys Klicius, "Alat yang lebih baik membuat tinjauan kode Copilot menjadi lebih buruk. Berikut cara kami benar-benar memperbaikinya," Blog GitHub, Juli 2026. https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/
"Why Go is an Ideal Language for AI-Assisted Software Engineering," Blog Google Developers, Agustus 2026. https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/
