# Pengembangan berbasis spesifikasi > Bagaimana para teknisi Asana mengubah pengajuan perintah berulang ke agen pengodean menjadi alur kerja berbasis spesifikasi yang tahan lama, dan apa yang kami pelajari setelah kurang lebih tiga bulan penggunaan internal. Source: https://asana.com/id/inside-asana/spec-driven-development ## Pengembangan berbasis spesifikasi: Hal-hal Positif - dan apa yang kami pelajari setelah tiga bulan _Setelah tiga bulan, kami memiliki gambaran yang lebih jelas tentang kapan struktur tambahan itu membantu dan kapan struktur itu menjadi penghalang._ Salah satu teknisi kami sedang menyiapkan migrasi data dan memutuskan untuk menggunakan pengembangan berbasis spesifikasi (SDD) untuk merencanakan pekerjaan. SDD dimaksudkan untuk membantu mereka menemukan celah lebih awal, membuat pendekatan lebih mudah ditinjau, dan memberikan arahan yang jelas kepada agen. Rencana yang dihasilkan cukup terperinci dan, di atas kertas, terlihat cukup masuk akal. Rencana tersebut menata pekerjaan seperti ini: **Masalah → Penelitian → Spesifikasi → Tinjauan → Implementasi → Verifikasi** Seiring berjalannya implementasi, teknisi menyadari bahwa dua pekerjaan dapat berjalan bersamaan dan membuat bidang kustom duplikat. Pendekatan ini juga membuat kode menjadi semakin kompleks dan sulit diikuti. Untungnya, mereka menemukan masalahnya, menghentikan implementasi, menulis dokumen desain satu halaman, dan menandai beberapa rekan kerja untuk memberikan masukan. Bersama-sama, mereka membahas desain dan menemukan pendekatan yang lebih aman. Spesifikasi asli melakukan apa yang kami minta: spesifikasi itu membuat proyek tetap bergerak ke arah semula. Masalahnya adalah arahnya salah. Spesifikasi terperinci membuat proyek mudah dilanjutkan, sekalipun ide awalnya kurang mantap. Agen dapat mengembangkan ide itu lebih cepat daripada orang-orang bisa berhenti dan mempertanyakannya. Proyek itu menunjukkan satu risiko dari penambahan struktur: satu agen dapat membawa asumsi keliru yang sama dari spesifikasi ke kode dan pengujian. Spesifikasi, kode, dan pengujian saling sesuai, tetapi itu tidak berarti asumsi yang mendasarinya benar. Untuk keputusan yang lebih berisiko, orang lain masih perlu kembali ke gol awal dan mencari cara bagaimana implementasi dapat melanggar gol tersebut. Meskipun demikian, agen-agen menangani pekerjaan yang berlangsung lebih dari satu sesi, dan petunjuk sering kali tidak cukup untuk mempertahankan apa yang hendak dicapai proyek atau alasannya. Hal itu mendorong kami untuk membangun /spec-driven, kerangka alur kerja dengan spesifikasi sebagai intinya. Spesifikasi membuat arah proyek tetap tersedia untuk sesi berikutnya. Skrip memberikan konteks dan menjalankan pemeriksaan. Saat suatu eksekusi mengungkap adanya aturan, pemeriksaan, atau bagian konteks yang terlewat, kami dapat menambahkannya ke alur kerja sehingga agen berikutnya tidak perlu menemukan celah yang sama lagi. Masih ada cukup banyak perbedaan pendapat tentang apakah struktur tambahan SDD sepadan. [Microsoft](https://developer.microsoft.com/blog/spec-driven-development-ai-native-engineering) dan [AWS](https://aws.amazon.com/blogs/machine-learning/how-frontier-teams-are-reinventing-ai-native-development/) mempromosikan SDD, sementara [Thoughtworks menggambarkannya sebagai pendekatan yang sedang berkembang dan diperdebatkan](https://www.thoughtworks.com/en-sg/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices), dan [para praktisi melaporkan pengalaman yang beragam](https://news.ycombinator.com/item?id=45610996). Para kritikus memperingatkan bahwa SDD dapat menghasilkan lebih banyak Markdown daripada yang dapat dikelola oleh para teknisi, mengubah spesifikasi terperinci menjadi kode yang ditulis dalam bentuk prosa, atau meninggalkan deskripsi lain tentang sistem yang menyimpang dari kode.[1][2][3] Setelah tiga bulan penggunaan nyata, kami mengetahui bahwa pertanyaan pentingnya bukanlah apakah harus menggunakan SDD. Itu adalah hal yang kurang dimiliki agen dalam proyek itu. Terkadang jawabannya adalah spesifikasi. Terkadang, jawabannya adalah contoh yang lebih baik, pemeriksaan otomatis, atau teknisi yang mengenal area tersebut. ## Alasan kami membangun /spec-driven Beberapa teknisi di Asana sudah mencoba [GitHub Spec Kit](https://github.com/github/spec-kit/blob/main/docs/reference/workflows.md) dan [OpenSpec](https://github.com/Fission-AI/OpenSpec/blob/main/docs/customization.md), tetapi keduanya tidak menjadi bagian dari alur kerja reguler mereka. Kami menginginkan versi yang dapat kami sesuaikan seiring kami belajar dan menghubungkannya ke proses pengembangan Asana. Mode rencana bawaan sudah dapat meneliti basis kode dan menghasilkan rencana implementasi yang berguna sebelum membuat perubahan. SDD menambahkan lebih banyak struktur seputar rencana tersebut: SDD membuat masalah, keputusan utama, dan kriteria penerimaan tetap terlihat selama implementasi dan verifikasi. Sebelum implementasi, /spec-driven menyampaikan kembali pemahamannya tentang masalah dan mengajukan pertanyaan yang dapat mengubah rencana. Ini memberi teknisi kesempatan untuk mengoreksi arah sebelum ada kode yang harus ditulis ulang. Kami menyimpan status itu di repositori sehingga sesi berikutnya tidak perlu menebak apa yang telah terjadi. Kami ingin aturan alur kerja bersifat deterministik, jadi skrip menangani pencatatan dan pemeriksaan. Model ini menangani bagian-bagian yang mendapat manfaat dari penilaian: mengajukan pertanyaan, menimbang perbandingan, dan menjelaskan keputusan. Alur kerja mencakup beberapa perintah. Para teknisi menggunakan /spec-driven spec untuk menelusuri pertanyaan terbuka dan menghasilkan spesifikasi serta rencana implementasi. Setelah meninjau rencana, mereka menggunakan /spec-driven ship untuk menerapkannya, memverifikasi hasilnya, dan menyiapkan pekerjaan untuk ditinjau. Mesin status melacak proyek saat melewati perintah-perintah ini, sehingga sesi berikutnya mengetahui apa yang telah terjadi dan apa yang akan terjadi selanjutnya. Sejak awal, kami ingin /spec-driven menjadi lebih dari sekadar cara untuk menulis dan menjalankan spesifikasi. Kami juga ingin /spec-driven menata alur kerja agen. Ini mengurutkan tugas menurut dependensi dan menjaga perubahan file yang tumpang tindih dalam putaran eksekusi terpisah. Ini mengirimkan pekerjaan independen ke beberapa agen secara paralel, lalu menggunakan hasilnya untuk memutuskan apa yang dapat dijalankan selanjutnya. Seperti GPS untuk pekerjaan: kapan pun, langkah berikutnya dan keputusan yang benar-benar penting selalu jelas, jadi sulit untuk mengalami kebuntuan.Teknisi Asana menggunakan /spec-driven dengan cara spec-first dan spec-anchored. Dengan spec-first, mereka menggunakan spec untuk memilih arah, lalu berhenti memperbaruinya. Dengan pendekatan berbasis spesifikasi, mereka menjaganya agar selalu terkini saat pekerjaan berubah. Para teknisi juga menulis spesifikasi independen untuk bagian dari upaya yang lebih besar, sehingga satu orang dapat menggunakan alur kerja tanpa meminta seluruh tim untuk menggunakannya. ## Kapan /spec-driven sepadan dengan pekerjaan tambahan Struktur tambahan paling bermanfaat saat konteks penting diperlukan untuk tetap ada di berbagai sesi, serah terima, atau banyak tugas terkait. Teknisi dapat meninjau bagaimana rencana berubah, dan arah proyek tetap tersedia saat pekerjaan dipindahkan ke sesi agen atau orang lain. Dua upaya produk mempertahankan spesifikasi yang terus diperbarui selama kurang lebih dua hingga tiga bulan: satu membangun fitur baru yang signifikan, yang lain menggulirkan tanggal subtugas ke tugas induk. Saya baru saja menyelesaikan inisiatif yang cukup besar dengan pendekatan berbasis spesifikasi dan menurut saya, pendekatan ini sangat membantu saya! Saya mengerjakan rencana selama sekitar dua hari, lalu menyelesaikan semua pekerjaan teknik dan menggabungkannya dalam tiga hari.Spesifikasi membuat serah terima menjadi lebih mudah. Seseorang yang melanjutkan proyek yang dijeda dapat melihat apa yang sedang dicoba dilakukan tim, mengapa proyek itu berbentuk seperti itu, dan apa yang tersisa. Mereka tidak perlu merekonstruksi proyek dari komit dan percakapan. Teknisi juga menggunakan /spec-driven untuk mengoordinasikan batch besar pekerjaan yang dijalankan agen. Di Konsol Admin Asana, tempat tim TI di perusahaan pelanggan mengelola keamanan, akses, integrasi, dan pengaturan berbagi di seluruh organisasi, para teknisi menggunakannya untuk memindahkan 66 pengaturan ke kerangka kerja bersama. Memindahkan pengaturan tersebut membutuhkan sekitar 150 migrasi di beberapa kerangka kerja Konsol Admin. Setiap migrasi menjadi tiket Asana untuk agen cloud, dan para teknisi menjalankannya dalam batch paralel, memperbarui tiket yang tersisa berdasarkan hasil sebelumnya. Tim yang menjalankan upaya tersebut melaporkan bahwa 91% migrasi tidak memerlukan revisi setelah peninjauan dan bahwa upaya secara keseluruhan selesai lebih dari sebulan lebih awal dari rencana semula. Migrasi besar lainnya hanya memerlukan prompt singkat. Perbedaannya adalah seberapa jelas basis kode sudah dijelaskan. Basecode tersebut memiliki contoh yang dapat diikuti oleh agen dan pemeriksaan yang dapat memverifikasi hasilnya. Agen Konsol Admin tidak dapat memahami setiap persyaratan dari kode, jadi pekerjaan membutuhkan struktur yang lebih baik. /spec-driven juga membantu pembuatan prototipe yang cepat. Teknisi dapat dengan cepat menjawab cukup banyak pertanyaan produk terbuka untuk membangun pengalaman end-to-end yang berfungsi. Manajer Produk dan desainer dapat mencoba prototipe sebelum para teknisi berinvestasi dalam penguatan produksi. Jika para teknisi memutuskan untuk mempertahankan kode, biasanya kode tersebut perlu dibersihkan secara menyeluruh sebelum dapat digabungkan. Pada saat itu, prototipe sudah menunjukkan apakah ide tersebut layak dijalankan. ## Apa yang ditunjukkan oleh angka-angka awal Kami mendorong semua orang untuk mencoba /spec-driven sekali, tetapi tidak mewajibkan penggunaan berkelanjutan. Sekitar separuh dari para teknisi mencobanya. Pada bulan terakhir, penggunaan mingguan berkisar antara 30 hingga 50 teknisi. Di antara keterampilan agen bawaan dan yang dikembangkan Asana yang dipanggil langsung oleh para teknisi, /spec-driven menempati peringkat ketiga. Penggunaan berkelanjutan cukup menggembirakan, tetapi tidak memberi tahu kami bagaimana /spec-driven memengaruhi penyelesaian. Kecepatan teknik terkenal sulit diukur. Permintaan pull dan penambahan kode implementasi merupakan indikator produktivitas yang tidak sempurna, tetapi kami yakin keduanya sering kali merupakan ukuran yang berguna secara arah. Untuk perbandingan kecepatan, kami melihat tujuh teknisi dan 524 permintaan perubahan yang digabungkan selama empat bulan. Kami membandingkan pekerjaan sebelum dan sesudah setiap insinyur pertama kali menggunakan /spec-driven dengan jelas dan mengecualikan spesifikasi, rencana, dan artefak alur kerja lainnya. Untuk perbandingan pemulihan, kami mengklasifikasikan permintaan perubahan sebagai /spec-driven ketika permintaan tersebut mengubah file proyek alur kerja. Permintaan pull per minggu naik 38%, dan penambahan kode implementasi naik 2,66×. Satu periode singkat dengan volume yang sangat tinggi memengaruhi hasil penambahan. Bahkan tanpa itu, penambahan masih 66% lebih tinggi. Tingkat pengembalian eksplisit juga sedikit lebih rendah: 1,2% untuk pekerjaan berbasis /spesifikasi, dibandingkan dengan 1,66% untuk permintaan perubahan lainnya. Lebih banyak kode tidak selalu berarti hasil yang baik. Agen dapat menghasilkan implementasi yang besar ketika implementasi yang lebih kecil sudah cukup, sehingga peningkatan penambahan kode mungkin mencerminkan solusi yang terlalu besar, alih-alih lebih banyak pekerjaan yang selesai. Tinjauan normal memberi kami satu pemeriksaan terhadap mode kegagalan tersebut. Kami mengandalkan peninjau untuk menandai implementasi yang lebih besar atau lebih kompleks daripada yang dibutuhkan oleh masalah, dan perubahan ini masih disetujui. Hal itu memberi kami keyakinan bahwa implementasi yang terlalu besar tidak mendorong seluruh peningkatan. Perbandingan ini tidak dikontrol, dan kami tidak dapat memisahkan pengaruh /spec-driven dari kombinasi proyek atau peningkatan yang lebih luas dalam alat agen. Bahkan dengan keterbatasan tersebut, kami merasa termotivasi oleh hasilnya. ## Hal yang masih perlu diperbaiki ### Meninjau dokumen dapat menjadi kemacetan Membuat spesifikasi membutuhkan waktu mulai dari 30 menit hingga beberapa hari, tergantung pada seberapa familiar teknisi dengan area tersebut serta kompleksitas dan risiko proyek. Teknisi dapat menggunakan /spec-driven agar agen membuat draf spesifikasi dengan cepat, tetapi meninjaunya tetap membutuhkan waktu. Dalam satu upaya, seorang teknisi menghabiskan berjam-jam meninjau permintaan penarikan dengan research.md, file kerja tempat agen mencatat apa yang dipelajarinya dari basis kode, dokumentasi, dan keputusan sebelumnya sebelum menyusun draf spesifikasi. Beberapa temuan tersebut tidak jelas, tidak akurat, atau sedikit keliru. Peninjauan itu menunjukkan bahwa kami belum sepakat apakah file-file ini merupakan catatan kerja sementara atau dokumentasi yang harus dipercaya oleh para teknisi di masa mendatang. Beberapa teknisi menghargai bukti proses tentang bagaimana suatu keputusan dibuat. Yang lain khawatir bahwa menyimpan riset yang tidak sempurna akan membuatnya tampak otoritatif. Di salah satu tim infrastruktur, peninjauan spesifikasi menjadi penghambat baru sebelum implementasi. Menurut saya, perintah dan alur kerja terasa jauh lebih rumit dan memakan waktu daripada sekadar membuat rencana lalu menerapkannya.Sebagian besar peninjau tidak ingin membaca spesifikasi yang panjang dan kemudian meninjau kode juga. Ketika pekerjaan mencapai tahap permintaan perubahan, serah terima perlu meringkas keputusan, alasan kami mengambilnya, hal yang tampak berisiko, dan cara kami memeriksa hasilnya. Jika arahnya sendiri perlu ditinjau, kami perlu memintanya lebih awal, saat masih mudah diubah. ### Spesifikasi yang berguna berubah seiring proyek berjalan Para teknisi terus belajar saat mereka menerapkan rencana. Memperbarui spesifikasi dengan apa yang mereka pelajari membutuhkan upaya. Detailnya membantu selama implementasi dengan menunjukkan apa yang menurut agen sedang dibuatnya. Setelah itu, sebagian besar detail tersebut mengulangi kode. Sekarang kami berpendapat bahwa spesifikasi kerja harus berkembang saat proyek masih belum pasti dan menyusut setelah kode dapat menjelaskan implementasi. Bagian yang tersisa seharusnya membantu pembaca berikutnya memahami desain, keputusan penting, kendala, dan risiko yang belum terselesaikan. Spesifikasi yang sudah selesai menimbulkan pertanyaan terkait: apa yang seharusnya terjadi pada spesifikasi tersebut? Kami terlalu lama menunggu untuk menjawabnya. Meninggalkannya di monorepo membuat spesifikasi tersebut mudah ditemukan, tetapi juga meninggalkan dokumen yang tidak ada pemiliknya. Kami memindahkannya ke arsip terpisah. Kita masih membutuhkan serah terima yang lebih singkat yang menyimpan hal-hal penting untuk nanti. Jika dokumen menciptakan lebih banyak pekerjaan daripada yang dihemat, dokumen tersebut tidak membantu. ## Membangun siklus umpan balik ke dalam kerangka kerja Terkadang jawabannya bukan dokumen lain, melainkan perubahan pada sistem di sekitar agen. Salah satu contohnya adalah bug dalam cara /spec-driven membaca Markdown: judul dan kotak centang di dalam contoh dapat disalahartikan sebagai milestone aktual atau tugas yang belum selesai. Setelah mencatat bug, kami menelusuri bagian lain dari /spec-driven dan menemukan beberapa perintah dengan parser Markdown kecilnya sendiri dan titik buta yang sama. Kami menggantinya dengan satu parser bersama, menambahkan pengujian regresi dan pemeriksaan arsitektur, serta menerapkan perbaikan ke lingkungan. [OpenAI menjelaskan pendekatan terkait sebagai rekayasa harness](https://openai.com/index/harness-engineering/): menempatkan pengetahuan penting di tempat yang dapat ditemukan agen, membuat aturan dapat ditegakkan, dan menggunakan kegagalan untuk meningkatkan lingkungan di sekitar agen. Pelajaran lain tidak dapat menjadi uji coba atau aturan arsitektur. Kami menyaring kesalahan berulang menjadi panduan. Karena /spec-driven memandu pengguna melalui alur kerja yang dapat diprediksi, kami dapat menampilkan setiap pelajaran saat agen mencapai langkah yang relevan. Para teknisi masih memutuskan pelajaran mana yang berlaku di luar proyek awal. Kami menguji panduan pada delapan permintaan perubahan terdahulu, bersama dengan kasus sintetis yang dirancang untuk menangkap saran yang tidak relevan. Dalam tindak lanjut, kami menguji tiga tugas historis tersebut dengan petunjuk singkat, sedang, dan terperinci, sehingga menghasilkan total sembilan perbandingan. Panduan menampilkan pertanyaan tambahan yang berguna atau batasan perencanaan dalam delapan dari sembilan perbandingan. Pengujian terpisah mencakup tiga tugas historis lainnya. Uji coba ini jelas meningkatkan dua rencana; pada rencana ketiga, agen tanpa panduan telah menemukan isu tersebut. Panduan yang paling bermanfaat menanyakan tentang perubahan perilaku, konsumen dan varian yang terdampak, serta kontrak antara API, skema, atau parser. Evaluasi hanya mencakup pertanyaan dan rencana. Kami tidak mengukur apakah panduan mempercepat implementasi. Panduan yang sempit juga menjadi usang lebih cepat dan terkadang muncul dalam pekerjaan yang tidak terkait. Mempertahankan panduan dan evaluasi membutuhkan lebih banyak pekerjaan daripada membangun versi pertama. Kami dapat memetakan ranjau darat dengan panduan, menyingkirkannya dengan memperbaiki sistem yang mendasarinya, atau menerima risiko bahwa agen atau peninjau harus menemukannya lagi. Kami biasanya memetakannya terlebih dahulu karena biayanya lebih murah. Memperbaiki API, pengujian, dokumentasi, atau contoh yang mendasarinya membutuhkan lebih banyak upaya, tetapi bermanfaat bagi semua orang dan menghilangkan kebutuhan akan panduan. ## Bagaimana pendekatan kami terhadap /spec-driven sekarang Kami ingin mencegah para teknisi mengulangi prompt yang sama dan menjelaskan kembali proyek tanpa menghilangkan friksi yang bermanfaat. Agen tetap perlu berhenti ketika memiliki pertanyaan penting, bukti tidak ada, atau langkah berikutnya memerlukan penilaian manusia. Kami mendapatkan beberapa panduan praktis: - Untuk sebagian besar perubahan kecil dan lokal, percakapan atau rencana singkat sudah cukup. - Gunakan pendekatan berbasis spesifikasi terlebih dahulu untuk menyepakati arah. Pertahankan spesifikasi tetap menjadi acuan ketika keputusan harus tetap berlaku di sesi atau serah terima berikutnya. - Jangan memasukkan setiap bagian yang hilang ke dalam spesifikasi. Harness harus memberikan konteks dan menjalankan pemeriksaan; penilaian arsitektur masih perlu ditinjau oleh manusia. Jika suatu spesifikasi layak dikelola, tuliskan untuk pembaca berikutnya. Buat keputusan dan risiko mudah ditemukan, tautkan ke bukti alih-alih menyalinnya, dan putuskan apa yang harus dilakukan terhadap spesifikasi saat proyek berakhir. ## Langkah selanjutnya Setelah tiga bulan, para teknisi masih menggunakan /spec-driven ketika pekerjaan berlangsung lintas sesi, berpindah dari satu orang ke orang lain, atau terbagi menjadi banyak tugas terkait. Mereka telah menggunakannya untuk menjaga proyek multibulan tetap berjalan dan menata sejumlah besar pekerjaan yang dijalankan agen. Itu adalah hasil yang baik untuk eksperimen internal. Seiring kami memperluas /spec-driven untuk mendukung lebih banyak jenis pekerjaan, beberapa fitur baru menyelesaikan masalah nyata bagi tim tertentu, tetapi membuat alur kerja menjadi lebih kompleks bagi semua orang. Di versi berikutnya, kami ingin beralih ke inti yang lebih kecil dan lebih terfokus. Orang-orang memiliki pendapat yang kuat tentang SDD dan rekayasa harness. Kami belajar lebih banyak dengan mencobanya pada pekerjaan nyata daripada dengan memperdebatkan salah satunya. Sebelum menambahkan lebih banyak proses, sekarang kami menanyakan apa yang kurang dari agen di proyek itu. Mulailah dari hal kecil, lihat di mana alur kerja membantu atau menghalangi, lalu sesuaikan berdasarkan apa yang Anda pelajari. [1] Birgitta Böckeler, “[Memahami Pengembangan Berbasis Spesifikasi: Kiro, spec-kit, dan Tessl](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html),” Oktober 2025. [2] François Zaninotto, “[Spec-Driven Development: The Waterfall Strikes Back](https://marmelab.com/blog/2025/11/12/spec-driven-development-waterfall-strikes-back.html),” November 2025. [3] Gabriella Gonzalez, “[Spesifikasi yang cukup terperinci adalah kode](https://haskellforall.com/2026/03/a-sufficiently-detailed-spec-is-code),” Maret 2026. #### **Tentang Penulis** Walter Li adalah Insinyur Perangkat Lunak di tim Infrastruktur Penyimpanan Inti Asana, dan Rohan Batra adalah Insinyur Perangkat Lunak di tim Kerangka Kerja Backend. Keduanya menghabiskan beberapa bulan bergabung dengan Tim Tiger Agent Success, tempat mereka memimpin pengembangan dan evaluasi alur kerja /spec-driven yang dijelaskan dalam postingan ini. #### **Ucapan Terima Kasih untuk Tim** Ucapan terima kasih khusus kepada Leo Zhang, Karol Krupa, Gordie Levitsky, dan Mitch Conquer karena telah membantu kami membentuk dan mengembangkan /spec-driven serta menjadi pengguna awal. - [Menskalakan LunaDb, sistem pemuatan data deklaratif internal kami](/id/resources/scaling-lunadb) Teknik #### Insinyur Platform Di Asana, kami telah membangun sistem pemuatan data bernama LunaDb yang berfungsi sebagai tulang punggung aplikasi web kami. Terlepas dari namanya, ini bukan database. Sebaliknya, ... - [Cara Asana menjadikan saya manajer teknik yang lebih efektif](/id/inside-asana/asana-makes-me-effective-engineering-manager) Teknik #### Manajer Teknik Infrastruktur Data As an engineering manager, I need to keep track of so many things. I have my own personal to-dos that I need to prioritize, making time for focused work while also handling incomi ... - [Menskalakan pipeline invalidasi kami: Bagian 1](/id/inside-asana/scaling-invalidation-pipeline-part-1) Teknik #### Insinyur Platform At Asana, our invalidation pipeline is a key part of implementing near-realtime reactivity in the webapp. Reactivity is how each-and-every Asana tab keeps up-to-date with the lat ... - [Pengembangan berbasis spesifikasi: Hal-hal Positif -- dan apa yang kami pelajari setelah tiga bulan](/id/inside-asana/spec-driven-development) Teknik Setelah tiga bulan, kami memiliki gambaran yang lebih jelas tentang kapan struktur tambahan itu membantu dan kapan struktur itu menjadi penghalang.Salah satu teknisi kami sedang m ... - [Teknik](/inside-asana/engineering-spotlight)