AI dalam Alur Kerja Engineering Manager: Apa yang Benar-Benar Membantu, Apa yang Diam-Diam Merusak

Setiap IDE, pelacak proyek, dan bot standup kini hadir dengan "asisten AI." Sebagian besar menghasilkan estimasi yang terdengar meyakinkan namun salah, mengubah catatan 1:1 menjadi bubur beige, dan secara diam-diam melewatkan bagian terpenting dari pekerjaan: pertimbangan. Janji "AI untuk manajer" justru membuat saya semakin skeptis, bukan sebaliknya.

Saya bukan anti-AI. Saya menggunakan Claude dan Cursor setiap hari. Saya telah memangkas berjam-jam waktu persiapan. Tapi saya juga pernah terbakar, lebih dari sekali, karena mempercayai ringkasan yang terdengar benar namun secara halus keliru. Sebuah brief 1:1 yang meratakan konflik tegang menjadi "mendiskusikan prioritas." Laporan sprint yang dengan riang melewatkan fakta bahwa dua engineer telah berhenti memeriksa PR satu sama lain. AI tidak memberi tahu Anda apa yang tidak dilihatnya.

Ini adalah panduan yang ingin saya miliki dua tahun lalu. Di mana AI benar-benar berguna dalam seminggu seorang EM, di mana ia akan diam-diam merusak segala sesuatu jika Anda membiarkannya, dan rencana 30 hari untuk mengintegrasikannya tanpa kehilangan bagian pekerjaan yang harus tetap menjadi milik Anda.

Mengapa Hal Ini Penting Sekarang

Anda adalah garis pertahanan terakhir melawan AI slop yang mencapai tim Anda. Jika Anda tidak bisa membedakan antara ringkasan AI yang berguna dan yang halusinasi, Anda akan melakukan salah satu dari dua hal, dan keduanya buruk.

Anda akan menolak alat-alat ini sepenuhnya, sementara rekan-rekan Anda diam-diam menghemat empat jam seminggu. Atau Anda akan terlalu mempercayainya, masuk ke kalibrasi kinerja dengan dokumen "tema" hasil kluster AI, mengulang framing yang dihallusinasinya di depan ruangan, dan merekomendasikan promosi berdasarkan sesuatu yang diciptakan model dari satu thread Slack.

Keduanya tidak dapat diterima bagi manajer dengan 6-10 engineer. Tugasnya adalah mengetahui alur kerja mana yang cukup baik untuk AI, dan mana yang tetap Anda pegang tidak peduli seberapa besar godaannya untuk mendelegasikan.

Di Mana AI Benar-Benar Membantu

Lima alur kerja ini telah bertahan setahun saya mencoba memecahkannya. Tidak menarik, tapi nyata menghemat waktu.

Ringkasan persiapan 1:1

Sebelum setiap 1:1, saya memasukkan catatan minggu lalu dari engineer tersebut, daftar PR yang sudah di-merge, dan thread Slack tempat mereka aktif ke dalam Claude. Prompt:

Berikut catatan minggu lalu, PR yang di-merge, dan thread Slack untuk [nama]. Rangkum apa yang berubah sejak 1:1 terakhir kami dalam maksimal 5 poin. Tandai apa pun yang terdengar seperti gesekan, pekerjaan yang terhambat, atau pergeseran cakupan. Jangan berspekulasi tentang perasaan. Jika sebuah thread tidak jelas, katakan demikian.

Baris "jangan berspekulasi tentang perasaan" penting. Tanpanya, model akan dengan penuh semangat memberi tahu Anda bahwa seseorang tampak "frustrasi" berdasarkan tiga pesan singkat, Anda masuk dan menanyakannya, dan engineer tersebut akan memandang Anda seolah Anda sudah gila.

Yang saya dapatkan adalah bacaan 90 detik yang menangkap hal-hal yang saya lewatkan. Saya tetap menulis pertanyaan sendiri. AI hanya memastikan saya tidak membuka dengan "jadi, bagaimana semuanya" karena saya lupa mereka men-ship migrasi pada hari Kamis.

Input draf tinjauan kinerja

Enam bulan catatan 1:1 itu banyak sekali. Sekali per siklus, saya memasukkan catatan tersebut (dan hanya catatan itu, bukan Slack, bukan PR, itu pass yang berbeda) ke Claude dengan prompt kluster:

Kelompokkan catatan 1:1 ini menjadi 3-5 tema. Untuk setiap tema, berikan saya 2-3 momen konkret dari catatan yang mendukungnya. Gunakan kutipan langsung dari catatan jika memungkinkan. Jangan membuat tema yang tidak didukung oleh setidaknya dua catatan berbeda.

Ini membantu. Bukan merupakan drafnya. Ini memunculkan pola yang sudah saya setengah sadari dan mengingatkan saya pada momen spesifik yang telah saya lupakan. Dari situ, saya menulis tinjauan aktual dengan suara saya sendiri, dengan contoh saya sendiri. Output AI masuk ke scratchpad dan dihapus.

Tinjauan kinerja yang ditulis AI adalah jenis slop terburuk. Terdengar profesional tapi tidak bermakna apa-apa. Engineer yang membacanya akan mengetahuinya.

Ringkasan komentar PR dan pendelegasian tinjauan kode

Saya bukan pengulas kode untuk pekerjaan sehari-hari tim saya, tapi saya membaca diff untuk tetap memahami situasi. Jika sebuah PR kontroversial, saya akan membuka Claude dengan diff dan bertanya:

Rangkum ketidaksepakatan dalam thread PR ini. Apa pertanyaan arsitektur inti yang sedang diperdebatkan? Apa poin terkuat dari masing-masing sisi?

Berguna saat saya perlu mengambil keputusan desain tanpa harus membaca ulang 80 komentar inline. Lebih lanjut tentang pola Cursor + Claude di bawah.

Deteksi anomali analisis sprint

Sebagian besar dasbor sprint adalah noise. Yang saya inginkan adalah "sprint ini terlihat aneh, ini apa." Saya memasukkan data cycle-time, review-latency, dan status tiket ke Claude dengan satu prompt:

Bandingkan metrik sprint ini dengan 4 sprint sebelumnya. Tandai angka mana pun yang lebih dari 1,5 standar deviasi dari rata-rata trailing. Jangan menebak penyebabnya. Cukup beri tahu saya apa yang anomali.

Baris "jangan menebak penyebabnya" melakukan kerja nyata. Tanpanya, model akan dengan yakin memberi tahu Anda bahwa "tim mengalami kelelahan kerja" karena review latency meningkat, padahal sebenarnya satu senior engineer sedang PTO. AI bagus dalam mengatakan "angka ini terlihat aneh." Ia buruk dalam mengatakan "dan inilah alasannya."

Alasan itu adalah tugas Anda. Anda pergi dan berbicara dengan orang-orang.

Persiapan kalender

Kemenangan terkecil, dan yang paling terakhir saya lepaskan. Lima menit sebelum rapat apa pun yang belum saya persiapkan, saya menempelkan agenda (atau sekadar judul dan peserta) dan dokumen terbaru ke Claude:

Brief 90 detik: apa yang mungkin dibahas dalam rapat ini, apa ketegangan yang mungkin ada, apa yang harus saya siapkan untuk disampaikan. Spesifik. Jika Anda tidak tahu, katakan demikian.

Ini tidak ajaib. Ini adalah momen paksa "apa yang akan saya masuki" alih-alih tiba tanpa persiapan dan menghabiskan sepuluh menit pertama untuk menyesuaikan diri.

Di Mana AI Diam-Diam Merusak

Ini adalah alur kerja di mana AI terlihat membantu padahal tidak. Beberapa di antaranya saya saksikan membakar manajer lain. Beberapa sudah membakar saya sendiri.

Keputusan berdasarkan pertimbangan. Apakah engineer ini butuh proyek yang menantang atau dukungan lebih? Apakah tim ini siap untuk reorganisasi atau masih satu kuartal lagi? AI memberi Anda jawaban berimbang dari dua sisi yang terdengar bijak. Tugas Anda adalah memilih. Model tidak memiliki kepentingan dalam permainan ini dan tidak mengenal tim Anda.

Menyampaikan umpan balik sulit. Kata-katanya harus datang dari Anda, dengan suara Anda, secara langsung. Bukan melalui Slack. Bukan dalam sebuah dokumen. Bukan melalui "draf berbantuan AI" yang Anda modifikasi. Jika Anda tidak bisa mengatakannya tanpa skrip, berarti Anda tidak cukup meyakininya untuk menyampaikannya, dan orang di hadapan Anda akan merasakannya.

Keputusan perekrutan. Alat penyaringan AI cenderung condong ke bias dan pelaundering sinyal. Mereka memberi penghargaan pada kandidat yang terlihat seperti training set, lalu mencuci bias itu melalui skor yang terdengar meyakinkan. Saya pernah melihat satu alat meranking rendah seorang senior engineer karena résumé-nya memiliki jeda dua tahun (merawat keluarga). Gunakan AI untuk menjadwalkan, mencatat selama debriefing panel, membuat draf email penolakan. Jangan biarkan ia menyaring manusia.

Percakapan kinerja. PIP, penolakan promosi, perubahan cakupan, percakapan kompensasi. Ini bersifat quasi-hukum, berat secara emosional, dan memerlukan ketepatan kata-kata Anda sendiri. Saya belum pernah melihat dokumen PIP berbantuan AI yang tidak terkesan dingin atau salah, kadang keduanya.

Keputusan strategis. Taruhan mana, trade-off mana, pengurutan mana. AI memberi Anda opsi yang masuk akal. Ia tidak memberi Anda opsi yang benar-benar bisa dieksekusi tim Anda, yang sesuai dengan realitas politik Anda, yang akan disetujui direktur Anda. Sintesis itu adalah pekerjaannya. Itulah mengapa Anda dibayar.

Jebakan "Dokumen Promosi AI"

Seorang engineer menyerahkan berkas promosi kepada Anda. Verbanya generik ("menggerakkan," "memperjuangkan," "mempelopori"). Pernyataan dampaknya mencurigakan seimbang: tiga poin, masing-masing dua baris, masing-masing dengan sebuah angka. Tidak ada suara. Semuanya terasa seperti rekomendasi LinkedIn untuk orang lain.

Itu Claude. Anda bisa tahu. Skip-level Anda juga bisa tahu.

Begini masalahnya: biasanya tidak berarti pekerjaannya buruk. Artinya narasi diri engineer tersebut kosong, yang merupakan masalah tersendiri dan bisa dilatih. Pekerjaannya mungkin sangat baik. Ceritanya yang rusak.

Cara saya membimbing tanpa mempermalukan: saya tidak bertanya "apakah ini AI." Saya bertanya, "ceritakan dampak utamanya dengan kata-kata Anda sendiri." Jika mereka bisa, ceritanya nyata dan mereka hanya mendelegasikan penulisannya. Tidak apa-apa, tapi saya akan mendorong mereka menulis sendiri yang berikutnya karena penulisan adalah pemikirannya. Jika mereka tidak bisa, itulah masalah sebenarnya, dan kami mengerjakannya bersama. Bagaimanapun saya tidak bermain polisi AI-detector dalam 1:1.

Berkas itu tetap harus ditulis ulang. Prosa AI tidak bertahan di ruang kalibrasi. Manajer lain akan membacanya dengan cara yang sama seperti Anda, dan kandidat Anda akan diturunkan nilainya karena terdengar seperti semua orang.

Cursor + Claude untuk Pendelegasian Tinjauan Kode

Ini adalah pola konkretnya. Saya akan memberikan banyak catatan setelahnya.

Layer 1: Cursor dalam mode agen. Dikonfigurasi dengan aturan lint dan style tim. Menangkap hal-hal jelas: tes yang hilang, impor mati, error tipe, inkonsistensi penamaan. Engineer memperbaiki sendiri sebelum membuka PR.

Layer 2: Claude pada diff. Ketika PR dibuka, langkah CI (atau engineer secara manual) menjalankan diff melalui Claude:

Tinjau diff ini. Tandai: (1) fungsi lebih dari 50 baris, (2) cakupan pengujian yang hilang pada cabang baru, (3) perubahan apa pun pada jalur autentikasi, penagihan, atau penghapusan data, (4) tempat di mana penamaan tidak jelas. Jangan berkomentar tentang style; itu sudah ditangani. Jangan menyetujui atau memblokir. Cukup tandai.

Output menjadi satu komentar pada PR. Reviewer membacanya sebagai daftar periksa sebelum tinjauan manusia mereka.

Layer 3: Tinjauan manusia. Reviewer sekarang fokus pada arsitektur, niat penamaan, apakah ini sesuai dengan arah sistem, apakah abstraksinya tepat. Hal-hal yang memerlukan selera.

Di mana ini gagal. Apa pun yang menyentuh auth, penagihan, pembayaran, penghapusan data, atau PII mendapatkan reviewer manusia berpelatihan keamanan dari awal hingga akhir, tanpa AI dalam loop untuk keputusan tersebut. Domain baru yang belum pernah dibangun tim sebelumnya: sama. Migrasi kritis: sama. Pola ini baik untuk kode rutin; tidak baik untuk pekerjaan yang benar-benar berisiko.

Saya mempercayai pola ini karena saya telah melihat pass Claude melewatkan bug nyata dan saya tahu apa yang dilewatkannya. Jika Anda belum pernah duduk dengan diff dan menyaksikannya salah, Anda belum memiliki kalibrasi untuk menggunakannya. Jalankan selama sebulan dengan tinjauan manusia penuh di atasnya sebelum Anda membiarkan apa pun dari ini mempersingkat siklus tinjauan Anda.

Rencana Adopsi 30 Hari

Jika Anda mulai dari nol, jangan mengadopsi lima alur kerja AI sekaligus. Anda akan kehilangan jejak mana yang benar-benar menghemat waktu dan mana yang diam-diam menghasilkan slop yang Anda bersihkan. Satu per satu.

Minggu 1: Satu alur kerja saja. Pilih persiapan 1:1. Gunakan untuk setiap 1:1 minggu itu. Setelah setiap 1:1, tulis satu baris: "apa yang dilewatkan AI." Pada hari Jumat Anda akan memiliki 6-10 baris yang memberi tahu Anda titik buta model. Itulah fondasi untuk mempercayainya.

Minggu 2: Tambah satu lagi, antara deteksi anomali sprint atau persiapan kalender. Latihan yang sama. Bandingkan output AI dengan naluri Anda sendiri. Di mana ia setuju, Anda menghemat waktu. Di mana ia tidak setuju, salah satu dari Anda salah; cari tahu yang mana.

Minggu 3: Audit. Keluarkan catatan. Di mana AI secara bersih menghemat waktu, dan di mana Anda menghabiskan lebih banyak waktu memperbaiki slop daripada yang akan Anda habiskan untuk mengerjakannya sendiri? Hentikan alur kerja apa pun dalam kategori kedua. Jika persiapan 1:1 menghemat 20 menit seminggu dan analisis sprint menghabiskan 30 menit dalam keraguan, hentikan analisis sprint.

Minggu 4: Tulis dokumen "norma penggunaan AI" tim Anda. Satu atau dua halaman, ditulis oleh Anda. Bahas apa yang didorong, apa yang diizinkan dengan catatan, apa yang dilarang. Bagikan. Terima pertanyaan.

Starter untuk dokumen:

Norma Penggunaan AI: [Nama Tim]

Didorong: Ringkasan persiapan 1:1 (privat untuk manajer), brief kalender/rapat, pass pertama tinjauan kode (hanya tanda Cursor + Claude, tanpa auto-approve), deteksi anomali metrik sprint, ringkasan dokumen untuk konteks, membuat draf email tidak sensitif.

Diizinkan dengan catatan: Kluster tema tinjauan kinerja, hanya sebagai input, bukan draf. Outline berkas promosi, hanya outline, penulisan harus dilakukan engineer sendiri. Ringkasan catatan standup, boleh jika tim setuju.

Dilarang: AI sebagai draf final tinjauan kinerja, dokumen kalibrasi, atau PIP apa pun. AI sebagai kata-kata umpan balik sulit yang disampaikan kepada seseorang. Penyaringan kandidat oleh AI. Justifikasi kompensasi yang dihasilkan AI. Auto-approval PR yang menyentuh auth, penagihan, atau PII.

Mengapa: AI adalah asisten junior. Ia cukup baik untuk membuat draf, meringkas, dan menandai. Ia tidak cukup baik untuk mengambil keputusan tentang orang, dan keputusan tentang orang adalah sebagian besar pekerjaan kita.

Dokumen itulah artefak yang dibutuhkan tim Anda. Bukan daftar alat. Pemahaman bersama tentang apa yang tetap menjadi urusan manusia.

Opsional: Lensa ACE Framework

Jika Anda melacak adopsi AI di seluruh organisasi dan seseorang bertanya di mana manajemen teknik masuk ke dalam ACE Framework, berikut pemetaan singkatnya. Gunakan dengan hemat; kerangka ini lebih berguna untuk keputusan produk daripada untuk alur kerja pribadi.

• Ingest: menarik catatan 1:1, data PR, thread Slack, metrik sprint ke dalam satu konteks kerja
• Analyze: kluster anomali sprint, kluster tema tinjauan kinerja, ringkasan thread PR
• Predict: perkiraan cycle-time dan "apakah sprint ini berisiko." Gunakan dengan sangat hati-hati; ini adalah output yang paling rentan halusinasi yang akan Anda lihat.
• Generate: hanya input draf, bukan final. Brief 1:1, brief kalender, laporan anomali.
• Execute: jangan. Pertahankan manusia pada pemicu untuk tindakan apa pun yang berdampak pada orang. Tanpa pengecualian.

Langkah execute adalah di mana sebagian besar peluncuran tim-AI berjalan miring. "Kami menetapkan reviewer secara otomatis" tidak apa-apa. "Kami menyetujui PR secara otomatis di bawah N baris" adalah awal dari tinjauan insiden.

Kesalahan Umum

Mempercayai estimasi AI. Terdengar meyakinkan. Dibangun dari distribusi training yang tidak mencakup codebase Anda. Paling-paling sebagai pemeriksaan kewarasan.

Membiarkan AI menulis umpan balik yang akan Anda sampaikan. Jika Anda tidak bisa menulisnya sendiri, Anda tidak seharusnya menyampaikannya. Penulisan adalah bagian dari meyakininya.

Meringkas 1:1 menjadi bentuk yang kehilangan sinyal. Ringkasan lima poin meratakan percakapan tegang menjadi "mendiskusikan prioritas." Baca juga catatan mentah Anda.

Ketergantungan satu alat. Harga berubah, model dipensiunkan, vendor berputar haluan. Keterampilannya adalah alur kerja, bukan alatnya. Jika seluruh sistem persiapan Anda bergantung pada Claude yang tetap gratis di tier ini selamanya, Anda memiliki masalah kesinambungan.

Mengukur Keberhasilan

Anda akan tahu alur kerja berjalan dengan baik ketika:

1. Anda menghemat 2-4 jam seminggu untuk persiapan dan sintesis. Bukan 10. Jika seseorang menjual Anda 10, mereka menjual slop.
2. Tim Anda percaya bahwa percakapan sulit datang dari Anda, dengan kata-kata Anda, secara langsung.
3. Tidak ada konten yang dihasilkan AI mencapai tinjauan kinerja, keputusan perekrutan, atau ruang kalibrasi tanpa diedit.
4. Anda dapat mengartikulasikan, dalam satu kalimat masing-masing, alur kerja mana yang Anda percayakan kepada AI dan mana yang tidak.
5. Bawahan langsung Anda dapat mengartikulasikan hal yang sama tentang pekerjaan mereka sendiri, karena Anda telah menulis dokumen norma dan mereka telah membacanya.

Itulah tolok ukurnya. AI adalah asisten junior. Pekerjaannya (pertimbangan, percakapan sulit, keputusan yang tidak mau dibuat orang lain) tetap milik Anda. Jika sebuah alur kerja menggoda Anda untuk mendelegasikan pertimbangan, itulah alur kerja yang harus dilarang.

Pelajari Lebih Lanjut

• Menjalankan 1:1 dengan Engineer yang Menggerakkan Hal-Hal
• Percakapan Promosi dan Kinerja
• Metrik EM: Kecepatan Pengiriman, Kualitas, Retensi Karyawan, Perekrutan
• Alat dan Tech Stack Engineering Manager
• Companion JD: Staff Software Engineer