Stack Overflow Developer Survey 2026: Trust ke AI Agent

Hasil survei rilis pada 6 Oktober 2026 dan angka utamanya adalah adopsi: 83% responden memakai minimal satu AI tool di kerja. Saya justru membaca angka kedua lebih dulu, karena itu yang menentukan apa yang harus dilakukan tim hari Senin. Hampir separuh responden percaya output AI kalau bisa mereka verifikasi, dan hanya 6,6% yang percaya untuk keputusan penting.

Tulisan ini membaca press release dan halaman data AI dari survei itu baris demi baris, hanya mengutip angka yang memang tertulis di sana, dan menyebut sampel tiap pertanyaan bila halamannya mencantumkan. Lalu saya menjawab pertanyaan praktis yang tidak dijawab survei: kebijakan review seperti apa yang masuk akal dari trust yang bersyarat. Bagian kebijakan adalah interpretasi saya, diberi label jelas, lengkap dengan config CODEOWNERS dan branch protection yang bisa Anda salin.

Apa yang diukur survei, dan apa yang tidak bisa dijawabnya

Halaman metodologi Stack Overflow mencatat periode fielding 23 Juni sampai 5 Agustus 2026, dengan 39.266 baris dalam extract dan 30.903 di antaranya respons valid dari 169 negara. Survei dipromosikan lewat stackoverflow.com, stackoverflow.blog, dan milis anggota komunitas yang bersedia ikut riset. Halaman itu tidak menyebut pembobotan.

Cara rekrutmen ini penting untuk setiap angka di bawah. Orang yang mengisi survei Stack Overflow adalah orang yang sudah membaca Stack Overflow, jadi ini sampel besar dari komunitas developer yang aktif, bukan sampel acak seluruh developer. Halaman utama survei juga menyebut ukuran sampel berbeda per pertanyaan, sekitar 11.500 sampai 21.100 responden, dan sebagian hasil hanya mencakup subgrup seperti pengguna AI harian atau yang berpengalaman 16 tahun ke atas.

Seluruh bagian AI bersifat self-reported: apa yang orang katakan mereka pakai, percayai, dan lakukan. Saya menganggapnya bukti tentang perilaku dan sentimen yang dinyatakan, bukan pengukuran seberapa andal agent atau seberapa teliti code benar-benar di-review. Satu catatan lagi dari membaca kedua halaman bersamaan: press release dan halaman data AI membulatkan atau mendefinisikan beberapa angka secara berbeda, jadi bila berbeda saya memakai halaman data yang menyebut pertanyaan dan n-nya.

Agent 26,2%: AI sudah umum, workflow agent masih minoritas

Pertanyaan penggunaan di kerja menanyakan apakah responden saat ini memakai AI tool atau agent dalam perannya (n = 17.464, boleh memilih lebih dari satu). Coding assistant dan coding agent memimpin, sedangkan automated agent workflow sekitar seperempat. Kolom harian berasal dari pertanyaan frekuensi terpisah (n = 14.478) dan menunjukkan seberapa sering pengguna tiap jenis memakainya.

Ada dua pembacaan yang menggoda dan keduanya berlebihan. Pertama, bahwa agent itu marginal; padahal 63,1% penggunanya memakainya setiap hari, jadi seperempat yang memakai agent sangat bergantung padanya. Kedua, bahwa 26,2% adalah populasi agent yang sebenarnya; labelnya menggabungkan agent dengan automated workflow, dan pertanyaannya tidak menyebut seberapa otonom agent tersebut.

Survei juga mencatat 55% pengguna AI harian memakai AI tool minimal dua jam sehari (n = 10.926), dan 30,9% empat jam atau lebih. Kalau seperempat developer menjalankan workflow agent dan banyak yang berjam-jam sehari memakai AI, code yang tiba di review bukan lagi kejadian langka. Itulah konteks untuk angka trust.

Trust itu bersyarat: 48,0% percaya yang bisa diverifikasi

Pertanyaan trust menanyakan seberapa jauh developer percaya output AI dalam workflow mereka (n = 14.304). 48,0% memilih percaya bila mudah diverifikasi. 16,3% percaya untuk banyak tugas tetapi bukan keputusan penting, 16,3% lainnya hanya untuk tugas berisiko rendah, 12,3% tidak percaya untuk sebagian besar tugas, dan 6,6% percaya untuk banyak tugas termasuk keputusan penting.

Struktur jawabannya itulah temuannya. Kelompok terbesar tidak didefinisikan oleh seberapa bagus modelnya, tetapi oleh seberapa murah pengecekannya. Halaman survei menambahkan bahwa hanya 4% responden early-career dengan pengalaman satu sampai lima tahun yang percaya AI untuk keputusan penting. Press release Stack Overflow menambahkan bahwa 78,7% menyatakan source attribution penting saat menilai code atau jawaban teknis buatan AI, dan mengutip CEO-nya bahwa trust diperoleh lewat transparansi, source attribution, dan konteks teknis yang kaya.

Pertanyaan kedua menanyakan apa yang biasanya dilakukan developer pada jawaban AI sebelum memakainya (n = 13.162, boleh memilih lebih dari satu). Jawaban teratas menggambarkan verifikasi, bukan penerimaan begitu saja:

• Menjalankannya secara lokal: 76,5%
• Membandingkan dengan konteks codebase: 63,9%
• Memeriksa implikasi test atau security: 53,0%
• Memakainya apa adanya: 9,6%

Dibaca bersama, 48,0% percaya output yang bisa diverifikasi dan 76,5% mengaku menjalankan code-nya. Keduanya konsisten satu sama lain, dan sesuai dengan profesi yang mengadopsi AI dengan membangun kebiasaan verifikasi di sekelilingnya. Keduanya juga self-report, jadi isinya adalah apa yang developer yakini tentang disiplin mereka sendiri.

Di mana developer menyerahkan kerja ke AI, dan di mana tidak

Pertanyaan workflow menanyakan bagian pekerjaan mana yang saat ini memakai AI (n = 12.547). Dua kolom di bawah adalah ujung distribusinya: porsi yang sudah memakai dan porsi yang tidak memakai maupun tidak berencana. Halamannya punya kolom lain, untuk penggunaan yang diharapkan ke depan dan tugas yang tidak ada di workflow responden, yang tumpang tindih dengan ini dan tidak saya tampilkan.

Urutannya mengikuti blast radius. Pekerjaan yang hasilnya bisa dijalankan dalam hitungan detik, seperti code di area yang dikenal, debugging, dan test, punya penggunaan tertinggi. Pekerjaan yang mengubah sistem bersama atau yang live punya yang terendah, dan deploy atau operasi production adalah satu-satunya baris di mana porsi tidak berencana, 36,0%, lebih besar dari yang sudah memakai, 19,9%. Developer tampaknya menerapkan aturan verifiability dari pertanyaan trust pada daftar tugas mereka sendiri.

Rating kegunaan searah (n = 12.734, useful ditambah very useful): implementation 74,6%, debugging atau refactoring 72,6%, review 64,5%, communication 35,0%. Pertanyaan kepuasan (n = 12.125) punya satu angka yang layak dicermati: implementation meningkatkan kepuasan bagi 60,1% tetapi menurunkannya bagi 19,9%, penurunan tertinggi di antara aktivitas yang terdaftar. Press release menyebut 66% untuk debugging atau refactoring, yang berbeda dari angka kegunaan 72,6% di halaman data dan lebih dekat ke angka kepuasan 66,1%, jadi periksa pertanyaan mana yang jadi asal angka yang Anda kutip.

Kesenjangan kebijakan: 24,0% melaporkan ada tool resmi dan panduan

Pada penggunaan organisasi (n = 13.167), 29,7% mengatakan AI bersifat opsional dan terserah individu, 24,0% mengatakan tool resmi dan panduan disediakan, 15,9% mengatakan didorong tetapi bervariasi, 11,5% mengatakan diharapkan untuk pekerjaan tertentu, dan 10,2% mengatakan diukur dalam evaluasi kinerja. 6,1% mengatakan tidak dipakai di kerja.

Soal cara organisasi menyeleksi tool (n = 12.637), 32,8% melaporkan beberapa tool atau model resmi, 18,6% kebanyakan satu, dan 17,3% mengatakan tiap tim memilih sendiri. Lalu 12,5% mengatakan organisasinya mencoba beberapa tool sebelum memutuskan. Soal siapa yang mengendalikan memori AI (n = 12.825), 53,6% menjawab saya sendiri dan 14,7% organisasi secara terpusat.

Jadi developer lebih mungkin disuruh memakai AI daripada diberi tahu cara memverifikasinya. Survei ini tidak punya pertanyaan tentang kebijakan review, dan saya tidak akan menyimpulkannya. Yang ditunjukkan adalah trust ditentukan oleh individu, satu kebiasaan verifikasi demi satu, pada populasi di mana hanya minoritas yang melaporkan panduan organisasi. Tim yang menginginkan konsistensi harus menuliskan kebijakannya sendiri.

Failure mode: menjadikan trust self-reported sebagai kontrol keamanan

Jebakannya adalah membaca 76,5% menjalankannya secara lokal sebagai sebuah kontrol. Itu pernyataan kebiasaan dari orang yang memilih mengisi survei, dan kebiasaan gagal tepat saat volume naik. Reviewer yang menghadapi pull request agent ke-10 hari itu tidak akan menjalankan kesepuluhnya secara lokal. Kalau keamanan Anda bergantung pada setiap reviewer ingat untuk memverifikasi, kebijakan Anda yang sebenarnya adalah 9,6% yang memakai output apa adanya, di bawah tekanan waktu.

Jebakan kedua adalah kata mudah dalam percaya bila mudah diverifikasi. Survei tidak mendefinisikannya, dan sifatnya relatif terhadap pemverifikasi. Migration yang lolos type check tidak mudah diverifikasi bila risikonya kehilangan data. Mudahnya pengecekan adalah properti test suite, type, dan environment Anda, yang bisa Anda perbaiki, bukan properti modelnya.

Ada biayanya, dan saya lebih suka menyebutnya daripada menyembunyikannya. Required check dengan aturan branch up to date menambah latensi dan memaksa rebase saat beberapa pull request agent terbuka bersamaan, dan aturan CODEOWNERS di jalur yang sibuk menjadikan tim kecil sebagai bottleneck. Itulah trade-off-nya: merge lebih lambat di jalur yang merge salahnya mahal, ditukar dengan kebijakan yang tidak bergantung pada perhatian siapa pun hari itu.

Mengubah verifiable menjadi kebijakan merge

Tabel ini memetakan tier trust dari survei ke kebijakan merge. Tier dan persentasenya dari survei (n = 14.304); kolom kebijakan adalah pemetaan saya sendiri, bukan milik Stack Overflow, dan sebaiknya Anda sesuaikan dengan risiko Anda. Prinsipnya: garis pemisah dari survei itu sendiri, apakah output bisa diverifikasi, menjadi aturan merge.

Kepemilikan dulu. File CODEOWNERS mengubah jalur mana yang penting menjadi sesuatu yang ditegakkan platform. Dokumentasi GitHub menyebut pola yang cocok terakhir yang berlaku, owner untuk satu pola harus berada di satu baris, dan approval dari salah satu owner yang terdaftar sudah memenuhi syarat.

# .github/CODEOWNERS
# Last matching pattern wins, so the broad rule goes first and the narrow
# rules after it. Owners for one pattern must share one line: split across
# lines, only the last owner is kept.
*                      @acme/maintainers
/infra/                @acme/platform
/.github/              @acme/platform
/migrations/           @acme/data-owners @acme/platform
/src/billing/          @acme/payments

# Protect the ownership file itself, or an agent can edit its own reviewers.
/.github/CODEOWNERS    @acme/platform

Lalu buat GitHub menegakkannya. Panggilan ini mengatur branch protection pada main lewat endpoint REST, yang body-nya mewajibkan required_status_checks, enforce_admins, required_pull_request_reviews, dan restrictions:

# Branch protection for main. gh sends the JSON body from stdin.
# strict=true forces the branch to be up to date before merge: safer, but
# every merged agent PR makes the other open ones stale, so expect rebases.
gh api -X PUT repos/acme/shop/branches/main/protection --input - <<'JSON'
{
  "required_status_checks": { "strict": true, "contexts": ["verify"] },
  "enforce_admins": true,
  "required_pull_request_reviews": {
    "dismiss_stale_reviews": true,
    "require_code_owner_reviews": true,
    "required_approving_review_count": 1
  },
  "restrictions": null,
  "required_conversation_resolution": true
}
JSON

Status check harus benar-benar ada, kalau tidak aturannya tidak menjaga apa pun. Workflow ini versi paling sederhana yang jujur: job bernama verify, sesuai dengan context di atas, menjalankan typecheck dan test pada setiap pull request ke main. Ganti perintahnya dengan milik Anda; intinya verifikasi adalah check yang gagal, bukan kebiasaan.

# .github/workflows/verify.yml
# The job name "verify" is the status-check context the protection rule
# requires. Rename one and the other silently stops matching.
name: verify
on:
  pull_request:
    branches: [main]
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npx tsc --noEmit
      - run: npm test

Yang dikerjakan hari Senin

Lima langkah berurutan, masing-masing cukup kecil untuk tim yang belum pernah menulis kebijakan AI.

1. Tulis jalur mana yang penting: infrastruktur, migration, billing, authentication, config CI. Masukkan ke CODEOWNERS dan lindungi file CODEOWNERS itu sendiri.
2. Aktifkan Require review from Code Owners dan Require status checks to pass before merging untuk main, dengan check yang benar-benar menjalankan test dan typecheck Anda.
3. Tentukan kelas jalur mana yang boleh merge hanya dengan check hijau. Kriteria jujurnya mengikuti survei: hanya bila kegagalan akan tertangkap oleh check otomatis yang Anda percaya.
4. Minta agent menandai commit-nya, misalnya dengan trailer Co-Authored-By, agar Anda bisa melihat berapa bagian main yang ditulis agent dan mana yang melewati review.
5. Jalankan ulang audit tiap bulan dan bandingkan dengan klaim tim tentang cara mereka me-review, karena survei menunjukkan betapa jauhnya kebiasaan yang dinyatakan dan kebijakan yang ditegakkan bisa berbeda.

# 1. How much of the last 30 days of main is agent-authored? This only works
#    if your agents add a Co-Authored-By trailer, so it measures the
#    convention, not the truth. Treat a low number as a floor.
git log origin/main --since="30 days ago" --oneline | wc -l
git log origin/main --since="30 days ago" \
  --grep="Co-Authored-By: Claude" --oneline | wc -l

# 2. Which of the last 50 merged PRs touched infra/ with zero reviews?
#    "reviews" and "files" are real gh pr list JSON fields.
gh pr list --state merged --limit 50 --json number,title,reviews,files \
  --jq '.[] | select((.reviews | length) == 0)
        | select(any(.files[]; .path | startswith("infra/")))
        | "#\(.number) \(.title)"'

# 3. Does the required check actually exist on main? An absent context
#    means the rule gates nothing.
gh api repos/acme/shop/branches/main/protection/required_status_checks \
  --jq '.contexts'

Tiga perintah di bawah mencakup langkah 3 sampai 5 setelah aturan aktif. Yang pertama hanya mengukur konvensi Anda, yang kedua mencari pull request ter-merge yang menyentuh infra tanpa review, dan yang ketiga memastikan required check benar-benar terpasang di main.

Hasil survei yang paling berguna bukan 26,2% memakai agent, melainkan bahwa developer menentukan trust mereka dari seberapa murah mengecek outputnya. Buat itu eksplisit: sebuah jalur aman diotomatisasi bila ada check yang Anda kendalikan yang bisa menggagalkan merge, dan sisanya butuh owner. Kutip angka survei bersama pertanyaan, sampel, dan batasannya, lalu biarkan audit Anda sendiri melengkapi sisanya.