Meskipun nama “DeveloperWeek” terdengar agak menyesatkan—karena ternyata acaranya kurang dari satu minggu—DeveloperWeek 2026 tetap persis seperti yang diharapkan: sebuah acara yang dipenuhi alat terbaru, alur kerja baru, dan gagasan untuk para pahlawan teknis yang menjaga produk, situs web, dan infrastruktur favorit kita tetap hidup. Tidak ada pengumuman teknologi besar—atau mobil—seperti di re:Invent, tetapi acara yang lebih kecil dan lebih akrab ini tetap berpusat pada pekerjaan harian para pengembang, yang harus menyelami detail kode dan alat mereka untuk suatu hari mewujudkan prediksi tentang developer 10x. Dan di inti percakapan di DeveloperWeek 2026 ada pertanyaan yang sudah lama kita ajukan: apakah alat AI benar-benar bagus?
AI yang benar-benar bisa dipakai berarti memberi manusia kendali
Satu hal yang tampaknya menjadi duri di sepatu semua orang—setidaknya di DeveloperWeek—adalah kegunaan alat AI. Saya menangkap hal ini dari salah satu sesi yang menurut saya sangat menarik: banyak alat AI sebenarnya tidak dirancang untuk sangat mudah digunakan. Sering kali, alat itu dibuat dengan fokus pada efisiensi dan kecepatan, bukan pada kemudahan pemakaian. Padahal, kalau Anda ingin membangun alat AI, sangat penting agar orang memang mau memakainya.
Dalam sesi Caren Cioffi dari Agenda Hero tentang menciptakan produk AI yang benar-benar ingin dipakai orang, ia menceritakan pengalaman yang sangat familiar: kesulitan membuat generator gambar AI menghasilkan gambar yang sempurna. AI itu membuat gambar yang hampir benar pada percobaan pertama, tetapi setiap upaya untuk memperbaiki detail kecil justru menghasilkan hasil yang makin buruk. Ini terjadi karena menghasilkan gambar dengan AI pada dasarnya seperti memasukkan prompt ke kotak hitam dan berharap hasilnya bagus, sebab piksel yang keluar setiap kali akan berbeda.
Ketidak-deterministikan AI—bahwa ia menghasilkan sesuatu yang sedikit berbeda setiap kali—adalah bagian dari keajaibannya. Tapi justru itu juga yang membuat alat AI menyebalkan untuk dipakai. Alat AI mengambil alih pekerjaan kita, menghasilkan pendekatan yang cepat dan efisien dari keinginan kita hanya lewat beberapa kata. Namun hasilnya sering kali hanya sebaik prompt yang kita berikan, dan bahkan begitu, alat itu tetap tidak memiliki rasa nuansa seperti yang dimiliki manusia. Mengubah pendekatan cepat dan efisien yang “hampir benar” itu menjadi sesuatu yang benar-benar tepat ternyata sangat sulit ketika alat yang dipakai hanyalah kotak hitam yang menerima prompt bahasa alami. Bagi pengembang—dan pengguna secara umum—rasanya bisa seperti kita bukan mengendalikan alat AI untuk tujuan kita sendiri, melainkan alat AI yang menyeret kita lewat proses kreatifnya sendiri. Ini tidak menyenangkan saat Anda hanya ingin membuat gambar hadiah ulang tahun untuk ibu, seperti kasus Cioffi, dan berkali-kali lebih tidak menyenangkan ketika AI seharusnya membantu Anda memperbaiki bug penting di codebase.
Solusi Cioffi adalah mengembalikan kendali manusia ke dalam alat AI. Salah satu caranya adalah mengizinkan pengguna membuat ulang bagian kecil dari output AI, atau—ide yang terbilang liar—membiarkan mereka mengeditnya. Mungkin Anda tidak ingin alat AI membuat jawaban baru sepenuhnya setiap kali, atau menghasilkan ulang seluruh gambar hanya karena ada satu bagian yang bermasalah. Sebaliknya, AI yang benar-benar bisa dipakai akan memberi Anda kemampuan untuk mengubah detail kecil sesuai kebutuhan, langsung di antarmuka.
Seiring penggunaan alat AI semakin umum dan kasus pemakaiannya makin spesifik, para pengembang AI perlu benar-benar memikirkan seberapa mudah alat itu dipakai dalam praktik, bukan cuma seberapa cepat atau seberapa cerdas modelnya. Karena tampaknya pengguna mulai bertanya pada diri sendiri: apakah alat ini benar-benar membuat saya lebih cepat, atau justru menambah pekerjaan? Kalau pengguna dipaksa membuat ulang output berkali-kali hanya untuk memperbaiki sesuatu yang sedikit meleset, mereka mungkin mulai berpikir bahwa akan lebih cepat jika dikerjakan manual saja. Dan di lingkungan enterprise, ketika AI diminta mengotomatiskan bagian besar pekerjaan, hal-hal kecil yang “agak meleset” itu menumpuk satu sama lain dan meninggalkan developer dengan gunungan technical debt. Betapa mudahnya jika kita bisa memperbaiki satu atau dua hal yang perlu diperbaiki sebelum semuanya lepas kendali. Ketika Anda memberi manusia kendali atas alat itu, Anda membuatnya berguna. Ketika Anda membuatnya berguna, Anda membuatnya bisa diadopsi.
Konteks, konteks, konteks
Sebagai semacam permainan kecil untuk diri sendiri, saya mencatat semua buzzword yang saya dengar dari berbagai sesi yang saya hadiri. Satu kata yang cukup sering muncul saat saya berkeliling di pusat konvensi San Jose adalah context. Ini tidak mengejutkan kalau Anda tahu hambatan utama yang mulai dihadapi organisasi dalam strategi AI mereka. Anda tahu sendiri, kemampuan AI hanya sebaik data latihnya, sementara sebagian besar data latih tidak memuat nuansa dan kebutuhan khusus sebuah perusahaan. Alat coding AI tanpa konteks perusahaan, misalnya, akan menghasilkan kode yang tidak mengikuti standardisasi atau arsitektur yang umum dipakai perusahaan itu, sehingga banyak developer akhirnya harus jadi petugas kebersihan yang merapikan dan mengatur ulang kode. Ini bisa sangat menjengkelkan karena pengetahuan penting yang membuat proyek selesai sebenarnya sudah ada di tempat yang sama seperti biasa—di kepala para developer.
Agar strategi AI benar-benar menciptakan developer 10x yang selama ini diramalkan, LLM butuh pengetahuan yang sudah dimiliki karyawan. Bentuknya berbeda-beda di setiap perusahaan: ada yang mengakses data lewat MCP server, memberi bot catatan rapat, menyusun persona secara manual lalu menambahkannya, atau memasang guardrail agar AI hanya bertindak berdasarkan spesifikasi yang diberikan. Bahkan alat desain kolaboratif Figma kini menambahkan konteks ke AI mereka lewat brand kit dan spesifikasi teks yang dimasukkan pengguna. Jadi, tampaknya akses ke pengetahuan dan konteks sangat penting agar alat AI benar-benar berguna dalam alur kerja harian kita.
Dalam sesi keynote Stack Overflow, Chief Product and Technology Officer kami, Jody Bailey, menjelaskan bahwa konteks adalah pengubah permainan bagi alat AI, semacam kunci master untuk membuka potensi penuh semua alat AI. Karena tiap organisasi punya alur kerja, cara komunikasi, dan guardrail yang sangat spesifik dan unik, AI siap pakai yang dilatih dari data publik tidak akan pernah sepenuhnya mewujudkan efisiensi dan produktivitas bagi developer, sekuat apa pun ia di pengaturan pabriknya. Dan bagaimana Anda bisa percaya AI membantu perusahaan Anda kalau ia tidak tahu apa pun tentang perusahaan itu selain apa yang tersedia di internet terbuka?
Inti dari kebutuhan AI akan konteks adalah bahwa para developer tidak tampak mempercayai alat AI. Developer sering mengkritik AI karena jawaban yang salah atau tindakan yang keliru, dan keduanya justru menghabiskan waktu developer. Seperti yang saya bilang tadi, banyak “kenaikan produktivitas” dari alat AI habis sia-sia ketika developer harus mengerjakan ulang jawaban atau kode yang sedikit salah. Dan walaupun membuat sesuatu lebih mudah diedit mungkin membantu kegunaan dan adopsi, pekerjaan ulang yang terus-menerus bukanlah strategi AI yang produktif atau berkelanjutan. Tidak cukup hanya mengobati gejalanya; kita perlu menemukan obatnya. Konteks bisa jadi obat itu.
Seperti yang disampaikan Lena Hall, Senior Director of Developer Relations dari Akamai, dalam sesinya: konteks adalah satu-satunya yang Anda butuhkan. Dalam banyak proses saat ini, manusia di tengah alur kerja harus memeriksa hasil AI untuk memastikan semuanya sesuai dengan detail codebase. Tetapi alih-alih memaksa titik berhenti di sepanjang proses agar manusia bisa memperbaiki kesalahan AI, Hall menyarankan agar keahlian domain dimasukkan sejak pembentukan logika. Menurutnya, ini bukan soal kecerdasan model, melainkan soal desain informasi. Perusahaan perlu memasukkan konteks industri dan konteks perusahaan yang diperlukan ke dalam agen sejak awal, atau setidaknya membuatnya tersedia bagi alat mereka selama proses logika berlangsung. Produk enterprise Stack Internal kami sendiri menggunakan MCP server untuk memasok data tervalidasi manusia ke agen, tetapi Hall juga menjelaskan bahwa A2A dan advanced RAG bisa menjadi solusi untuk masalah konteks.
Interoperabilitas dalam alur kerja agen
Dalam sesi tentang menciptakan kerangka kerja AI enterprise yang benar-benar berhasil, Chief Architect for AI IBM, Nazrul Islam, menegaskan pentingnya interoperabilitas dalam sistem agentic. Menurutnya, membangun jutaan agen saja tidak cukup. Seperti manusia, agen juga harus bisa bekerja sama untuk menghasilkan sesuatu yang nyata. Mengejutkan, ya!
Walaupun kondisi alat AI saat ini membuat kita manusia tetap harus berada di dalam loop, para developer dan tim teknis jelas ingin menyerahkan bagian pekerjaan yang lebih melelahkan daripada menyenangkan. Itulah sebabnya banyak perusahaan mencoba membangun alat AI yang bisa mengerjakan dokumentasi dan code review untuk kita. Dan bukan cuma developer yang frustrasi dengan tugas-tugas membosankan—semua orang di semua organisasi juga suka menunda-nunda. Ini sudah masalah tersendiri, tetapi jadi jauh lebih besar ketika menyangkut tugas lintas departemen, di mana banyak orang dari banyak tim sama-sama tidak ingin mengerjakan satu hal yang membosankan. Dan meski agen bisa meringankan beban itu bagi kita, tanggung jawab tetap jatuh kepada manusia lintas tim untuk berkolaborasi, berkomunikasi, dan menyelesaikan tugas. Kecuali kalau AI kita bisa saling bekerja sama untuk menyelesaikannya.
Di sinilah interoperabilitas berperan. Jika dirancang dengan benar, ia bisa mengubah tumpukan besar alat AI menjadi strategi AI yang berjalan. Tetapi interoperabilitas bukan kerangka yang mudah dibuat; kalau mudah, semua orang sudah melakukannya. Ini melibatkan koneksi sistem terdistribusi lintas SaaS, public cloud, dan on-prem yang sebelumnya tidak membutuhkan connector karena manusia bisa mengakses semuanya dengan mudah. Piping sistem terdistribusi semacam ini kini menjadi salah satu kesulitan utama bagi para pemimpin yang ingin mengotomatiskan seluruh alur kerja atau proses. Dalam dunia ideal, sistem agentic seperti ini akan seperti operan tongkat estafet yang mulus. Agen AI penjualan menutup transaksi lalu menyerahkan tongkat ke agen keuangan. Agen keuangan membuat forecast lalu menyerahkannya ke agen customer success. Agen customer success melacak retensi dan peluang upselling lalu mengirimkan info itu kembali ke agen keuangan, yang kemudian mengirim kuota kuartal berikutnya ke agen penjualan. Dan seterusnya.
Menurut Islam, membangun semacam “tim agen” di perusahaan yang benar-benar bekerja berarti menghindari jebakan yang sama seperti pada tim manusia—pekerjaan yang terkotak-kotak, lock-in yang membuat anggota tim sulit mencoba cara baru, serta alur kerja tidak terstruktur yang menyebabkan hilangnya konteks.
Bagi perusahaan yang ingin melakukannya, Islam menyarankan membuat roadmap untuk strategi AI yang mencakup inventarisasi kemampuan seperti API dan event, menormalkan akses untuk model melalui MCP dan A2A, membangun tata kelola interaksi yang bisa diamati dan diaudit, memetakan perjalanan lintas sistem yang harus dilalui agen, lalu membangun tim AI-nya. Dengan interoperabilitas yang benar-benar bagus, agen bahkan bisa “menemukan” agen lain, menciptakan jalur baru untuk mengotomatiskan pekerjaan dan berbagi informasi.
Untuk membuktikan kemampuan, dibutuhkan lebih dari sekadar kode
Sebagai penulis Gen Z di Stack Overflow, saya akan lalai kalau tidak membahas salah satu hal yang paling relevan untuk generasi saya—bagaimana developer junior bisa mendapatkan pekerjaan di pasar yang dipenuhi generator kode AI? Saat menghadiri sesi dari akademi IT Rumania, Coders Lab, saya makin sadar bahwa jalur lama bagi profesional muda untuk masuk ke industri teknologi sudah tidak lagi mudah dilalui. Masa magang dan belajar di pekerjaan level awal yang dulu lazim, sekarang nyaris hilang. Untuk mendapatkan pekerjaan pertama saja, developer junior harus membuktikan bahwa mereka lebih berharga daripada generator kode AI. Untuk itu, Coders Lab memberi developer junior kesempatan terlibat dalam pekerjaan klien nyata, dibimbing oleh mentor dari kalangan developer dan engineer senior yang memimpin proyek-proyek tersebut. Lewat pekerjaan ini, developer junior dapat menunjukkan kemampuan teknis, meningkatkan soft skill seperti komunikasi dan kolaborasi, serta mendapat bimbingan dari senior yang memimpin proyek.
Sebenarnya, ada banyak mahasiswa bermata berbinar di DeveloperWeek 2026, baik yang datang ke DevWeek Hackathon maupun yang berjejalan di lantai expo untuk networking. Walau hal-hal seperti ini memang sudah lama menjadi bagian dari perjalanan menuju pekerjaan pertama, sekarang tampaknya mereka menjadi jauh lebih penting bagi generasi termuda pekerja teknologi, yang seolah sadar bahwa kehadiran fisik mereka dalam komunitas dan percakapan memberi mereka pembeda yang nyata dari alat AI yang bisa melakukan pekerjaan serupa—dan kadang lebih baik—daripada mereka.
DeveloperWeek 2026 memberi validasi sekaligus ruang eksplorasi bagi banyak percakapan yang memang sudah terjadi di komunitas teknologi: bahwa alat AI memang cukup bagus, tetapi belum cukup bagus; bahwa mereka butuh lebih banyak konteks agar benar-benar membantu; dan bahwa arsitektur yang lebih kompleks masih dibutuhkan untuk otomatisasi yang sesungguhnya. Semua ini berarti masih banyak pekerjaan yang harus dilakukan industri teknologi untuk mewujudkan potensi penuh AI, dan itu berarti manusia developer masih sangat dibutuhkan untuk mengerjakannya. Sungguh hasil akhir yang melegakan untuk konferensi yang bernama DeveloperWeek.
