Amazon Kiro: Saat IDE Berhenti Menebak dan Mulai Bertanya tentang Spesifikasi

Selama dua tahun terakhir, hampir semua IDE yang mengintegrasikan agen AI bekerja dengan premis yang sama: pengguna mengetik prompt, agen langsung menulis kode, dan manusia diminta menilai hasilnya. Premis itu murah untuk dimulaikan, menyenangkan untuk dipamerkan di demo, tapi mahal dalam jangka panjang. Setiap developer yang sudah cukup lama menggunakan Claude Code, Cursor Composer, atau OpenCode akan menceritakan cerita yang sama: ada momen tertentu di mana agen dengan percaya diri menulis fungsi yang tidak sesuai dengan arsitektur aplikasi, memperkenalkan dependensi baru yang tidak perlu, dan meninggalkan jejak kode yang harus dibersihkan di sesi berikutnya. Inilah konteks mengapa Amazon merilis Kiro di paruh kedua 2026 dengan pendekatan yang secara eksplisit berbeda: tidak menulis satu baris kode pun sebelum spesifikasi tertulis dengan jelas. Bukan penambah fitur untuk editor, melainkan reorientasi fundamental tentang bagaimana agen AI seharusnya bekerja.

Kiro, singkatan dari agentic engineering yang digaungkan Amazon sejak preview di AWS re:Invent 2025, adalah IDE berbasis Visual Studio Code fork yang menyatukan editor tradisional dengan workflow spec-driven. Alih-alih menerima prompt sebagai perintah langsung, Kiro meminta pengguna dan agen untuk berunding dulu di sebuah file Markdown yang ia sebut spec. Setelah spec dianggap cukup matang, baru agen menulis kode dalam batch yang terstruktur, dengan validasi yang bisa dijalankan. Untuk developer Indonesia yang selama ini komplain tentang agen yang 'asal tebak' atau 'hallo-everything-the-prompt-says', pendekatan ini adalah kategori baru yang patut diuji.

Apa yang sebenarnya berubah dari alur kerja berbasis prompt

Pada IDE modern berbasis prompt, alurnya relatif pendek: pengguna menulis prompt di sidebar chat, agen menebak maksudnya, menampilkan diff, dan pengguna menerima atau menolak per blok. Kiro menambah satu tahap yang tidak terlihat di workflow Cursor atau Claude Code: negosiasi spesifikasi. Saat pengguna menulis permintaan seperti 'buat endpoint /api/orders yang mengembalikan daftar pesanan user yang sedang login', Kiro tidak langsung menulis kode. Ia membuat file requirements.md, design.md, dan tasks.md yang masing-masing punya struktur tetap. requirements.md berisi user story dalam format The system shall..., kriteria penerimaan dalam bentuk Given-When-Then, dan daftar kebutuhan non-fungsional seperti performance, security, dan observability. design.md berisi diagram alur data, struktur response, dan keputusan teknis seperti library yang akan dipakai. tasks.md adalah daftar pekerjaan terstruktur yang akan dieksekusi oleh agen.

Yang menarik adalah Kiro tidak meminta pengguna menulis semua itu dari nol. Agen yang terpasang di balik spec akan menebak-nebak draf awal berdasarkan prompt, lalu pengguna tinggal mengedit, menghapus, atau menambah. Setelah ketiga file itu dianggap cukup matang melalui tombol Approve, agen baru mulai menulis kode sesuai tasks.md yang sudah disetujui. Hasilnya, pengguna tidak pernah membaca diff secara membabi buta, karena apa yang di-approve di tingkat spesifikasi adalah kontrak yang harus dipatuhi oleh agen. Kalau hasil kode menyimpang dari spec, itu menjadi bug yang bisa dilacak dengan mudah.

Untuk developer yang sudah terbiasa memprogram dengan Vim atau Neovim murni, alur seperti ini mungkin terasa birokratis. Tapi untuk tim yang terdiri dari beberapa orang dengan pemahaman domain yang berbeda, atau untuk tim yang sering harus menjelaskan keputusan teknis ke stakeholder non-teknis, memiliki spec yang bisa di-review dan di-approve sebelum kode ditulis adalah pengubah permainan. Ini mirip dengan apa yang sudah dilakukan di dunia waterfall tiga puluh tahun lalu, tapi dalam skala yang jauh lebih kecil dan jauh lebih cepat. Review spec lima menit, bukan review sprint tiga hari.

Bagaimana Kiro memanfaatkan agen tanpa mengorbankan kendali manusia

Kiro tidak mengasumsikan satu agen akan menangani semuanya. Di balik spec yang sudah di-approve, ada konsep sub-agen yang masing-masing punya tanggung jawab spesifik. Ada agen yang khusus untuk menulis kode, ada agen untuk menulis test, ada agen untuk dokumentasi, dan ada agen untuk code review. Setiap sub-agen hanya boleh bekerja dalam ruang lingkup yang sudah didefinisikan di tasks.md, dan setiap output harus bisa dijelaskan dengan merujuk ke baris tertentu di spec. Pola ini meminjam banyak dari praktik microservices yang memecah sistem besar menjadi layanan kecil yang independen, dan menerapkannya ke dalam workflow pengembangan sehari-hari.

Yang paling konkrit adalah kemampuan hooks, yaitu titik-titik dalam workflow Kiro di mana manusia bisa menyisipkan perintah otomatis. Misalnya, setiap kali agen selesai menulis satu blok kode, hook bisa memicu test runner lokal atau linter untuk memastikan standar tim terpenuhi. Setiap kali spec di-approve, hook bisa memicu snapshot ke repositori Git sehingga tim punya jejak audit lengkap tentang siapa yang menyetujui apa. Bagi tim engineering Indonesia yang sering harus bekerja dengan klien korporat dan harus menunjukkan bukti compliance, kemampuan hooks ini sangat relevan karena bisa diterjemahkan menjadi log audit otomatis tanpa intervensi manual.

Kiro juga men-support multi-modal input: pengguna bisa menempelkan screenshot mockup, menulis catatan suara, atau bahkan menunjuk ke file di repositori dan berkata 'buat sesuatu yang mirip ini'. Semua input itu dikonversi menjadi entri di spec yang kemudian diolah oleh agen. Untuk praktisi yang sering bekerja dengan desainer UI/UX atau product manager yang lebih nyaman dengan gambar daripada teks, kemampuan ini menutup gap komunikasi yang selama ini sering jadi friksi di tim produk.

Mengapa Kiro layak diperhatikan oleh tim engineering Indonesia

Untuk startup teknologi dan tim produk di Indonesia yang sudah mengadopsi agen AI sebagai bagian dari workflow harian, kehadiran Kiro membawa tiga implikasi praktis. Pertama, on-boarding engineer baru menjadi lebih terstruktur. Engineer baru yang bergabung ke tim tidak langsung diminta menulis kode, melainkan diminta membaca spec terlebih dahulu, memahami keputusan teknis yang sudah didokumentasikan di design.md, dan baru kemudian diberi tasks.md yang sudah jelas ruang lingkupnya. Pola ini mirip dengan yang sudah diterapkan di perusahaan-perusahaan software besar di Silicon Valley, tapi kini tersedia untuk tim kecil dengan harga langganan yang relatif terjangkau di tier individu.

Kedua, komunikasi dengan stakeholder non-teknis menjadi jauh lebih mulus. Product manager, designer, atau bahkan klien korporat tidak perlu membaca kode untuk memahami apa yang sedang dibangun. Mereka cukup membaca requirements.md yang sudah ditulis dalam bahasa natural, lalu memberikan feedback. Bagi tim Indonesia yang sering bekerja dengan klien dari sektor perbankan, telekomunikasi, atau pemerintah, kemampuan menunjukkan spec yang readable oleh non-teknis adalah pembeda yang signifikan dibanding IDE yang hanya menghasilkan diff kode.

Ketiga, audit dan compliance menjadi lebih ringan. Setiap keputusan teknis punya jejak di spec yang bisa dilacak, setiap perubahan kode punya referensi ke tasks.md, dan setiap approval punya identitas dan timestamp. Untuk industri yang teregulasi seperti fintech, kesehatan, atau pemerintahan, kemampuan traceability otomatis seperti ini bisa menghemat waktu audit yang biasanya dihabiskan untuk rekonstruksi keputusan dari diff Git yang sulit dibaca.

Batasan yang perlu dipahami sebelum Kiro diadopsi secara luas

Meskipun menarik, Kiro juga punya batasan yang perlu dipahami supaya ekspektasi realistis. Pertama, workflow spec-driven punya biaya awal yang tidak kecil di awal project. Untuk prototipe satu halaman yang harus selesai dalam sehari, menulis requirements.md dan design.md terlebih dahulu terasa overkill. Kiro memang menyediakan mode fast-path di mana spec bisa di-skip untuk tugas-tugas kecil seperti melengkapi fungsi atau menulis test untuk satu file, tapi untuk project baru yang benar-benar dari nol, biaya setup spec tidak bisa dihindari.

Kedua, kualitas spec sangat bergantung pada kemampuan pengguna untuk menulis spesifikasi yang baik. Agen Kiro bisa menebak draf awal dari prompt, tapi kalau prompt-nya sendiri ambigu, draf spec-nya juga akan ambigu. Ini bukan kelemahan Kiro secara spesifik, melainkan karakteristik umum dari semua workflow yang berbasis spesifikasi: garbage in, garbage out. Untuk engineer Indonesia yang belum terbiasa dengan formalitas menulis spesifikasi, ada kurva belajar yang tidak bisa diabaikan.

Ketiga, ekosistem plugin dan integrasi Kiro masih terus berkembang. Karena berbasis fork dari VS Code, banyak ekstensi yang sudah tersedia di marketplace VS Code bisa dipakai, tapi beberapa ekstensi yang khusus bekerja dengan sidebar chat di Cursor mungkin tidak langsung kompatibel. Begitu juga integrasi dengan tool DevOps atau platform CI/CD tertentu masih perlu konfigurasi manual di hooks, dan dokumentasi tentang best practice-nya masih terus diperbarui oleh komunitas.

Yang patut diperhatikan ke depan untuk ekosistem AI Indonesia

Ada empat hal yang akan menentukan apakah pendekatan spec-driven ala Kiro akan menjadi standar atau hanya menjadi mode opsional di IDE modern. Pertama, apakah agen akan semakin pintar dalam menerjemahkan prompt bahasa natural menjadi spec yang akurat, atau apakah spec akan tetap bergantung pada kualitas input manusia. Kedua, apakah IDE-IDE besar lain seperti JetBrains, Cursor, atau VS Code sendiri akan mengadopsi pola workflow yang sama, atau tetap fokus pada iterasi prompt-diff yang lebih cepat. Ketiga, apakah standar format spec akan muncul atau setiap IDE akhirnya akan menggunakan formatnya sendiri yang tidak interoperable. Keempat, apakah komunitas engineering Indonesia akan mulai menulis dokumentasi best practice dalam bahasa Indonesia untuk tools semacam ini, atau hanya mengandalkan terjemahan otomatis yang sering kehilangan nuansa teknis.

Dalam pengujian editorial Wawasan AI, kemunculan Kiro bukan sekadar rilis IDE baru yang harus dibandingkan dengan Cursor atau Claude Code. Ini adalah eksperimen serius tentang bagaimana hubungan antara manusia dan agen AI seharusnya bekerja. Bukan prompt-sebanyak-mungkin, tapi spesification-yang-jelas-dulu. Bukan diff-sebanyak-mungkin, tapi approval-sebelum-eksekusi. Bukan iterasi-tanpa-akhir, tapi negosiasi-yang-terstruktur. Untuk ekosistem AI yang sedang tumbuh di Indonesia, ini adalah pengingat bahwa kecepatan menulis kode tidak selalu setara dengan kecepatan membangun produk yang benar. Kadang satu keputusan untuk berhenti sejenak dan bertanya 'apa sebenarnya yang kita mau' adalah langkah paling berharga yang bisa diambil oleh sebuah tim.