Studi Produktivitas Developer AI METR 2026: Apa Isinya

Saya mengunduh data.csv dan regression.py yang dipublikasikan METR untuk studi lanjutan akhir 2025, lalu menjalankan script itu tanpa modifikasi pada 17 Oktober 2026. Hasilnya minus 18,1 persen untuk panel developer asli, dengan interval 95 persen dari minus 38,4 persen sampai plus 8,8 persen. Satu baris itu merangkum seluruh studinya: angka yang terdengar seperti vonis, tetapi duduk di dalam interval yang sekaligus muat untuk lebih lambat, tidak berubah, dan jauh lebih cepat.

Post ini membaca post perubahan desain METR tanggal 24 Februari 2026, paper 2025 sebelumnya, repository data publik, dan post survei METR Mei 2026, dan setiap angka saya atribusikan ke sumbernya. Ini adalah pengukuran METR sendiri, bukan replikasi independen, dan subset sepuluh developer bukan tim Anda. Saya membedakan apa yang ditulis METR, apa yang saya reproduksi dari file publiknya, dan mana yang pembacaan saya. Ini bukan klaim bahwa AI membuat developer lebih cepat atau tidak.

Tiga angka dan satu konvensi tanda

Post yang ditulis Joel Becker, Nate Rush, Tom Cunningham, David Rein, dan Khalid Mahamud ini berjudul We are Changing our Developer Productivity Experiment Design. Isinya tiga estimasi, dan hanya yang pertama yang merupakan temuan konvensional, dalam arti intervalnya tidak memuat nol.

Untuk kedua kelompok akhir 2025, post melaporkan 57 developer, 143 repository, dan lebih dari 800 tugas, dengan median pengalaman 10 tahun. Post tidak pernah menyatakan konvensi tandanya, tetapi pemakaiannya konsisten: angka-angka itu menggambarkan perubahan waktu tugas, jadi minus 18 berarti 18 persen lebih sedikit waktu dengan AI. Script yang dipublikasikan menghitung exp dari koefisien AI dikurangi 1 pada log waktu, yang artinya sama. Perhatikan asimetrinya: 18 persen lebih sedikit waktu setara sekitar 22 persen lebih banyak pekerjaan per jam, karena 1 dibagi 0,82 kira-kira 1,22, sehingga angka waktu dan angka throughput tidak bisa saling menggantikan.

Mengapa kedua interval akhir 2025 bukan temuan

Interval yang memuat nol cocok dengan AI yang membuat pekerjaan lebih lambat, sama saja, atau lebih cepat. Minus 38 sampai plus 9 membentang 47 poin persentase waktu tugas untuk developer asli, dan minus 15 sampai plus 9 membentang 24 untuk developer baru. METR sendiri mengatakan demikian: kedua interval akhir 2025 memuat nol, dan hanya interval awal 2025, plus 2 sampai plus 39 persen, yang tidak.

Untuk melihat seberapa rapuhnya, saya menjalankan script METR pada CSV-nya di environment Python bersih dengan pandas, statsmodels, dan scipy. File itu berisi 1.134 issue dari 57 developer; script membuang 57 issue yang ditinggalkan, lalu menjalankan regresi yang sama dua kali, sekali pada issue yang selesai dan sekali pada issue yang punya waktu implementasi awal. Kolom pertama mereproduksi post tersebut.

Baris panel adalah pelajarannya. Dengan filter kedua, interval untuk developer itu menjadi minus 40,8 sampai minus 2,4 dan tidak lagi melintasi nol. Saya tidak mengklaim filter kedua lebih baik. Saya menyatakan bahwa headline yang dibangun di atas sekitar sepuluh developer bisa berpindah dari cocok dengan nol menjadi tidak, hanya karena pilihan baris mana yang dihitung, yang tidak pernah muncul di headline. Kedua run adalah reproduksi saya atas script publik METR, dibulatkan seperti yang dicetak script.

Selection effect adalah inti sebenarnya dari post ini

METR menyebut dua masalah seleksi. Pertama rekrutmen dan retensi: banyak developer kini mengaku tidak mau mengerjakan setengah pekerjaannya tanpa AI, sehingga studi kehilangan orang yang paling antusias. Kedua seleksi tugas: saat disurvei, 30 sampai 50 persen developer mengatakan kepada METR bahwa mereka memilih tidak mengirim sebagian tugas karena tidak mau mengerjakannya tanpa AI.

METR menyimpulkan estimasi yang dilaporkan kemungkinan merupakan batas bawah dan speedup sebenarnya bisa jauh lebih tinggi pada developer dan tugas yang tersingkir. Di post yang sama METR menulis bahwa seleksi tampaknya memengaruhi sebagian kecil developer dan tugas, dan bahwa estimasi pusatnya kemungkinan proxy yang buruk bagi dampak produktivitas AI yang sebenarnya pada developer ini. Dibaca bersama, arah biasnya dinyatakan, ukurannya tidak.

Yang tersisa sempit. Angka akhir 2025 menggambarkan tugas yang developer setuju kerjakan dengan dan tanpa AI, dan tugas yang paling terbantu AI justru yang paling mungkin ditahan. METR mengatakan efek ini akan makin dramatis seiring kemampuan dan ekspektasi tumbuh, itulah alasan METR mendesain ulang eksperimennya, bukan sekadar menerbitkan sampel lebih besar dari desain yang sama.

Empat masalah kecil yang dinilai METR kurang parah

Selain seleksi, post mencantumkan empat isu yang dinilai kurang parah. Masing-masing adalah jebakan pengukuran yang bisa Anda alami di eksperimen tim, dan kolom kanan adalah pembacaan saya tentang artinya di sana, bukan pendapat METR.

Selisih penyelesaian terlihat di CSV publik. Dari 611 issue AI-allowed, 460 selesai (75,3 persen) dan 120 belum selesai; dari 523 issue AI-disallowed, 368 selesai (70,4 persen) dan 124 belum selesai. Issue yang ditinggalkan hampir sama, 28 berbanding 29. Script hanya menganalisis issue selesai, jadi tiap arm menyumbang porsi yang berbeda dari penugasannya. Saya tidak mengklaim ini membiaskan estimasi ke arah tertentu; saya hanya bilang angka ini harus Anda cetak.

Mengapa bertanya ke developer tidak menyelesaikan soal

Studi 2025 sudah menunjukkan masalahnya. Sebelum mulai, developer memperkirakan AI memangkas waktu tugas 24 persen. Sesudahnya mereka percaya AI memangkas waktu sekitar 20 persen. Hasil terukurnya, tugas justru 19 persen lebih lama. Jarak antara keyakinan dan pengukuran mendekati 40 poin persentase.

Post survei METR Mei 2026 melihat pertanyaan ini dari sisi lain. Survei menganalisis 349 responden, 87 di antaranya software engineer, dan menemukan median perubahan nilai pekerjaan yang dilaporkan sendiri antara 1,4x dan 2x pada tiga ukuran, serta median perubahan kecepatan 3x yang diperkirakan penulis melebih-lebihkan nilai. Penulis menulis bahwa hasil survei belum tentu berpijak pada kenyataan dan bahwa hasilnya patut diduga mengalami selection bias yang signifikan, dengan alasan convenience sample dan response rate sekitar 2 persen untuk responden yang dihubungi lewat email.

Jadi ada dua jenis bukti yang berbeda karena alasan yang masuk akal. Survei mengukur nilai yang dipersepsikan pada banyak jenis pekerja; eksperimen mengukur menit pada tugas yang orang setuju kerjakan dengan dan tanpa AI. Keduanya bukan audit independen karena sama-sama dari METR. Yang membuat eksperimen bisa diperiksa adalah CSV dan script yang publik, sehingga saya bisa memverifikasi aritmetikanya, walau tidak rekrutmennya.

Mengukur tim sendiri tanpa jebakan yang sama

Bagian desain METR yang bertahan dari kritiknya sendiri murah untuk ditiru: tulis tugas dan estimasi waktu tanpa AI sebelum lempar koin, acak per tugas, dan analisis log waktu dengan estimasi sebagai covariate. Reproduksi dulu angka METR sekali supaya Anda tahu seperti apa interval selebar ini.

# Reproduce METR's late-2025 numbers from its published files.
# regression.py needs: pip install pandas numpy statsmodels scipy
git clone https://github.com/METR/Measuring-Late-2025-AI-on-OSS-Devs
cd Measuring-Late-2025-AI-on-OSS-Devs
python regression.py --input-data data.csv

# It drops ditched issues, then runs the regression on all, panel and new
# developers, twice: "Total Time Merged" (status == complete) and
# "Initial Impl Started" (any issue with an initial implementation time).
# The model is OLS with HC3 errors:
#   log(totalImplementationTime) ~ ai_treatment + log(estimatedTimeWithoutAI)
# speedup = exp(beta) - 1, so a NEGATIVE number means LESS time with AI.
#
# Expect (rounded, as the script prints them):
#   Panel Developers (Total Time Merged)  -0.181  (-0.384, 0.088)
#   New Developers   (Total Time Merged)  -0.036  (-0.147, 0.09)
#   Panel Developers (Initial Impl Started) -0.24 (-0.408, -0.024)

Lalu jalankan versi kecil pada ticket Anda sendiri. Script di bawah menetapkan assignment dengan hash dari id ticket plus seed yang di-commit lebih dulu, sehingga tidak ada yang bisa menggeser undian yang tidak disukai, dan memakai spesifikasi METR dengan satu perubahan dari saya: error di-cluster per developer, karena segelintir orang yang masing-masing mengerjakan banyak tugas bukan banyak observasi independen.

# team_experiment.py: fixed-rule randomisation and analysis for a team trial.
# Specification adapted from METR's regression.py:
#   log(time) ~ ai_treatment + log(estimate without AI)
import hashlib

import numpy as np
import pandas as pd
import statsmodels.formula.api as smf
from scipy.stats import norm

SEED = "2026-q4-team-trial"  # commit this to the repo BEFORE the first task


def assign(task_id: str) -> str:
    # Decided from the ticket id alone, before the developer sees the task.
    # A hash cannot be nudged by someone who dislikes the draw.
    digest = hashlib.sha256(f"{SEED}:{task_id}".encode()).digest()
    return "AI-allowed" if digest[0] % 2 == 0 else "AI-disallowed"


# tasks.csv: task_id, developer_id, status, minutes, estimate_no_ai
# estimate_no_ai is logged BEFORE assignment; status is complete / incomplete / ditched
df = pd.read_csv("tasks.csv")
df["arm"] = df["task_id"].map(assign)

# Print this next to every effect you report: differential completion.
print(df.groupby("arm")["status"].value_counts(normalize=True).round(3))

done = df[
    (df["status"] == "complete") & (df["minutes"] > 0) & (df["estimate_no_ai"] > 0)
].copy()
done["ai"] = (done["arm"] == "AI-allowed").astype(int)

model = smf.ols("np.log(minutes) ~ ai + np.log(estimate_no_ai)", data=done)
# METR uses cov_type="HC3". Clustering by developer is my change: a few people
# doing many tasks each are not many independent observations.
res = model.fit(cov_type="cluster", cov_kwds={"groups": done["developer_id"]})

beta, se = res.params["ai"], res.bse["ai"]
z = norm.ppf(0.975)
change = np.exp(beta) - 1  # negative = less time with AI, same as METR's convention
low, high = np.exp(beta - z * se) - 1, np.exp(beta + z * se) - 1
print(f"Change in task time: {change:+.1%}  (95% CI {low:+.1%} to {high:+.1%})")

Script METR memakai error robust HC3 dan memperlakukan setiap issue sebagai independen. Clustering per developer adalah tambahan saya, bukan METR, dan dengan kurang dari sekitar sepuluh developer ia tidak menyelamatkan sampel; ia hanya membuat interval jujur melebar. Perlakukan hasilnya sebagai bahan diskusi, bukan papan skor.

Apa yang diubah METR, dan harga tiap perbaikan

METR mengatakan adopsi agentic tool yang lebih luas seperti Claude Code dan Codex membuat rekrutmen lebih sulit dan mengubah tugas yang dikirim developer. Rencana tanggapannya ada di bawah. Kolom biaya mengutip METR bila METR menyebutnya dan ditandai sebagai inferensi saya bila tidak.

METR juga mengatakan akan terus mendesain ulang sebagian pengukurannya seiring kemampuan model meningkat. Itu sinyal berguna bagi engineering manager: sumber utama untuk pertanyaan ini sudah mengatakan instrumennya sendiri mulai aus, jadi satu angka darinya, atau dari Anda, pantas diberi tanggal kedaluwarsa.

Yang dikerjakan hari Senin

Anda tidak butuh program riset. Anda butuh aturan yang di-commit sebelum data datang, dan kebiasaan mencetak interval serta completion rate di samping setiap efek yang Anda laporkan.

1. Jalankan regresi METR pada CSV publiknya sekali, supaya lebar interval 10 developer dan 44 developer adalah sesuatu yang pernah Anda lihat, bukan sekadar baca.
2. Pilih satu kelas pekerjaan, misalnya ticket yang sudah punya estimasi, dan tulis aturan inklusinya, termasuk nasib tugas yang ditinggalkan.
3. Catat estimasi waktu tanpa AI sebelum assignment, dan tetapkan assignment dengan hash id ticket plus seed yang di-commit ke repository.
4. Catat waktu implementasi awal dan waktu review serta rework secara terpisah, seperti pemisahan di dataset METR, dan tandai saat orangnya multitasking.
5. Laporkan interval dan completion rate per arm, jangan pernah estimasi titik saja, dan pasang tanggal ukur ulang pada hasilnya.

Saat ada yang meneruskan headline AI membuat developer 18 persen lebih cepat, balasan yang akurat singkat: estimasinya 18 persen lebih sedikit waktu pada subset sepuluh developer, intervalnya dari 38 persen lebih sedikit sampai 9 persen lebih banyak, dan penulisnya menyebut estimasi pusat itu proxy yang buruk.

Aturan yang saya bawa dari sini: angka produktivitas AI hanya sebaik interval dan cerita seleksinya. Update METR berharga karena mencetak keduanya, dan pembacaan jujurnya adalah data akhir 2025 tidak menguatkan maupun menyingkirkan speedup, sementara perlambatan awal 2025 diukur pada generasi tool yang berbeda. Ukur pekerjaan Anda dengan aturan yang ditetapkan lebih dulu.