AI Bukan Mau Ganti SRE, Tapi Bikin Mereka Lupa Skill Dasar?

Kamu pasti pernah dengar narasi standar: AI bakal ganti pekerjaan manusia, termasuk Site Reliability Engineer (SRE). Tapi kalo kamu ngobrol sama SRE senior di kantor atau komunitas teknis, keluhannya bukan soal diganti — tapi soal lupa cara kerja sistem sendiri. Fenomena ini disebut "deskilling", dan itu jauh lebih berbahaya dari sekadar otomatisasi tugas rutinitas.

Bayangin kamu tiap hari pakai Copilot atau tool observability AI yang langsung nunjukin root cause, suggest fix, bahkan auto-remediate incident. Awalnya keliatan cuan banget: MTTR turun, on-call jadi santai, kamu bisa tidur nyenyak. Tapi coba deh hapus tool itu seminggu — kamu masih ingat cara trace latency pake `bpftrace` nggak? Masih tau kenapa database kamu pilih isolation level `READ COMMITTED` bukan `SERIALIZABLE`?

Kenapa deskilling ini berbahaya banget buat reliability

SRE bukan cuma soal "sistem jalan". SRE soal paham *kenapa* sistem jalan, dan *bagaimana* dia bisa mati. Kalo AI handle 90% investigasi, otak kamu berhenti bangun mental model arsitektur. Saat edge case muncul — misalnya race condition di distributed lock yang cuma kejadian 1 kali sebulan — AI mungkin nggak nemu pola karena data training nggak cukup. Kamu? Kamu udah lupa cara baca flame graph manual. Itu resep bencana.

Data dari survei internal beberapa tim platform di perusahaan besar (yg nggak bisa disebut nama) nunjukin: engineer yang bergantung penuh AI observability butuh 3x lebih lama resolve incident novel dibanding yang rutin latihan manual debugging. Skill itu kayak otot — nggak dipakai, ikut menyusut. Dan di dunia reliability, "menyusut" berarti outage lebih lama dan blast radius lebih gede.

Yang berubah buat workflow harian SRE

Dulu on-call artinya: dapet alert → buka dashboard → query logs → korelasikan metrics → hypothesis testing → fix. Sekarang? Alert → AI summary → klik "apply fix" → done. Efisien? Ya. Tapi kamu nggak belajar apa-apa dari incident itu. Knowledge nggak masuk ke kepala tim, cuma tersimpan di model AI yg bisa berubah kapan aja. Dokumentasi? Sering di-skip soalnya "AI kan tau".

Lalu ada tekanan bisnis: "Kenapa butuh 2 SRE kalo AI bisa handle?" Management mulai lihat headcount. Hasilnya: tim jadi kurus, bus factor jadi 1, dan kalo AI hallucinate (sering banget di kasus kompleks), nggak ada yang cukup paham buat tangkap kesalahannya sebelum production roboh.

• AI observability tool jadi crutch, bukan safety net
• Mental model arsitektur erosi perlahan tapi pasti
• Incident novel jadi nightmare soalnya nggak ada prior art di training data
• Bus factor turun drastis kalo tim dikurangi berkat "AI efisien"

Gimana cara hindar jebak deskilling ini

Praktik nyata: wajibin "manual debugging day" seminggu sekali. Matikan AI assistant, ambil incident lama, coba solve dari nol pake tool dasar: `grep`, `jq`, `kubectl`, `bpftrace`, SQL manual. Bikin catatan: "Kenapa saya pilih query ini? Kenapa hypothesis ini salah?" Itu yang bangun intuition — hal yg AI nggak bisa transfer ke kamu.

Lainnya: rotasi on-call harus include "shadow shift" buat junior. Senior nggak boleh selalu handle incident kritis. Biarkan junior struggle (dengan safety net), tapi jangan biarkan AI solve kan. Struggle itu tempat belajar. Dan dokumentasi post-mortem harus ditulis manusia, bukan generate AI — proses nulis itu yang memaksa kamu reflektif.

Bottom line: AI tool bagus buat *accelerate* yang sudah kompeten, tapi berbahaya kalo jadi *substitute* kompetensi. Kamu mau jadi SRE yang cuma tahu klik tombol "AI fix", atau yang paham sistem sampai ke level kernel? Pilihannya di tangan kamu — dan pilihan itu menentukan seberapa cepat pulih kalo production jatuh besok pagi.