Rutinitas 15 menit Claude Code untuk pemula: alur kerja pagi yang aman

Jumat malam, saya melempar satu perintah ke Claude Code: “Tolong perbaiki semua yang mengganjal di proyek ini,” lalu saya tidur.

Paginya, file yang berubah ada 23. Beberapa kodenya memang jalan. Tapi mana yang benar-benar diperbaiki, dan apa yang harus saya cek, saya sendiri sama sekali tidak bisa menjelaskannya. Membaca diff dari atas ke bawah saja makan waktu satu jam, dan ujungnya saya terlalu takut untuk meng-commit satu baris pun.

Saya sudah menyerahkan tugas besar ke AI yang pintar, tapi bukannya maju, saya malah mundur. Inilah jebakan pertama yang paling sering menjerat pemula.

Penyebabnya bukan kemampuan Claude Code. Saya cuma belum menentukan cara “menutup” sebuah pekerjaan. Hari ini saya akan memberikan persis rutinitas 15 menit yang saya jalankan setiap pagi, selagi menyeduh kopi.

Poin penting

• “Perbaiki semua” adalah sumber kecelakaan. Yang dikerjakan tiap hari cukup “satu tugas kecil yang ditentukan dalam satu kalimat”.
• Sebelum mulai mengedit, tentukan dulu perintah verifikasi yang menjadi penanda selesai atau belum.
• Setelah bekerja, cukup sisakan tiga hal: “file yang berubah”, “hasil perintah verifikasi”, dan “satu langkah berikutnya”.
• Yang diserahkan ke AI adalah bagian eksekusinya. Menentukan cakupan dan menekan tombol publikasi tetap dikerjakan manusia.
• Salin-tempel skrip di bawah, dan pemeriksaan pagi bisa berjalan otomatis dalam urutan yang sama.

Kenapa “menutup pekerjaan secara kecil” cocok untuk pemula

Waktu pertama mencoba Claude Code, tujuan saya selalu mengambang. “Bikin bagus ya”, “Rapikan biar enak dibaca”. Dengan cara begini, setelah selesai pun saya tidak tahu AI sudah mengerjakan apa dan sampai mana.

Hal yang sama berlaku untuk karyawan baru. Orang yang diminta “tolong urus dokumen ini seadanya” biasanya bingung. Tapi orang yang diminta “ganti angka di halaman 3 dengan versi terbaru, lalu cek apakah tabelnya tidak berantakan” bisa langsung bergerak, dan bisa menilai sendiri apakah pekerjaannya sudah selesai.

Dalam rutinitas harian, yang penting bukan menulis instruksi pintar dalam sekali coba. Yang penting adalah memotong pekerjaan menjadi kecil, dalam bentuk yang bisa dinilai kapan selesainya. Begitu ini bisa dilakukan, bahkan pemula pun bisa berkata setiap hari, “Hari ini saya maju sampai sini.”

Omong-omong, dasar dari pola pikir ini terhubung ke artikel Cara memulai Claude Code dan Dasar pengelolaan izin. Beresin dulu lingkungan di sana, baru tumpangkan kebiasaan ini, hasilnya lebih terasa.

Yang dikerjakan dalam 15 menit cuma 4 langkah

Yang saya kerjakan setiap pagi cuma empat hal berikut. Urutannya pun selalu sama. Dengan urutan tetap, tubuh bergerak tanpa perlu banyak berpikir.

1. Tulis tugas terkecil hari ini dalam satu kalimat. Misalnya “tulis ulang 3 baris paragraf pembuka README”, dengan tingkat detail yang ujungnya kelihatan. Pekerjaan besar sengaja tidak dikerjakan hari ini.
2. Tentukan dulu perintah verifikasinya. Seperti “kalau npm run build lolos berarti OK” atau “kalau satu test jadi hijau berarti OK”. Bentuk tujuan ditetapkan sebelum mulai mengedit.
3. Kerjakan, lalu periksa dengan urutan diff, build, baru URL publik. Jangan langsung publikasi; mulai dari yang bisa dinilai mesin dulu.
4. Sisakan satu baris untuk besok. Catat “risiko yang tersisa” dan “tugas terkecil berikutnya”. Ini jadi titik mulai besok pagi.

Kuncinya ada di nomor 2. Kalau mulai mengedit tanpa menentukan perintah verifikasi dulu, kamu balik lagi ke situasi Jumat malam tadi: “rasanya sudah benar, tapi tidak ada buktinya”. Pasang dulu garis finish, baru lari. Cuma dengan ini, pekerjaan harian terasa jauh lebih ringan.

Cakupan untuk AI, dan cakupan untuk keputusan manusia

Saya rasa di sinilah pemula paling sering bingung. Tidak semuanya boleh dilempar ke AI, tapi kalau semua dikerjakan sendiri, lalu apa gunanya pakai AI. Saya rangkum patokan pembagiannya dalam tabel.

Situasi	Diserahkan ke AI	Ditentukan/ditekan manusia
Menentukan cakupan	Mengeluarkan kandidat	Memutuskan satu kalimat tugas hari ini
Mengedit	Menulis kode atau teks	Arahan apa yang diperbaiki
Verifikasi	Menjalankan build atau test	Verifikasi mana yang jadi tujuan
Publikasi	Membuat ringkasan diff	Menekan tombol publikasi
Operasi berbahaya	Bertanya “boleh dilakukan?”	Keputusan akhir hapus/deploy produksi

Patokan saat ragu itu sederhana. Pekerjaan yang bisa diulang serahkan ke AI, pekerjaan yang tak bisa dibatalkan tangani sendiri. Mengedit file bisa diulang berkali-kali, jadi serahkan saja. Publikasi ke produksi atau menghapus file, di awal wajib kamu tekan sendiri. Hanya operasi yang sudah terbiasa yang perlahan dinaikkan menjadi otomatis. Pengaturan izin yang lebih rinci sudah dirangkum di dokumentasi resmi Claude Code, jadi kalau ragu soal pembagian ini, sempatkan membacanya sekali biar lebih tenang.

Template permintaan siap salin-tempel

Kalau menulis permintaan dari nol setiap kali, tingkat detailnya jadi tidak konsisten. Saya menempelkan template ini di aplikasi catatan, lalu mengisi titik-titiknya setiap pagi.

Tugas terkecil hari ini: (satu kalimat di sini. Contoh: tulis ulang 3 baris pembuka README)
Cakupan yang boleh disentuh: (Contoh: hanya README.md. File lain dilarang diubah)
Cara verifikasi selesai: (Contoh: npm run build berhasil)

Cara mengerjakan:
1. Sebelum mengubah apa pun, baca kondisi sekarang lalu ringkas.
2. Edit hanya pada cakupan di atas. Jangan menyentuh di luar cakupan.
3. Setelah mengedit, laporkan nama file yang diubah dan hasil cara verifikasinya.
4. Jika perlu hapus, deploy produksi, atau kirim ke luar, jangan dieksekusi; tanyakan dulu.

Cukup dengan menyisipkan dua baris “jangan sentuh di luar cakupan” dan “operasi berbahaya tanyakan dulu”, kecelakaan 23 file di awal tadi hampir tidak akan terjadi lagi. Bayangkan kamu tidak memberi kebebasan ke AI, melainkan memberi kotak yang aman.

Skrip verifikasi yang langsung jalan

Kalau pemeriksaan pagi diketik manual, pasti ada yang terlupa. Saya menaruh skrip ini sebagai morning-check.mjs, lalu menjalankannya sebelum menyeduh kopi. Selama Node.js terpasang, skrip ini jalan.

// morning-check.mjs : menjalankan pemeriksaan pagi secara berurutan
import { execSync } from "node:child_process";

// Susun perintah yang ingin dicek dari atas ke bawah. Sesuaikan dengan proyekmu.
const checks = [
  { label: "File yang berubah", cmd: "git status --short" },
  { label: "Apakah build lolos", cmd: "npm run build" },
];

let allOk = true;

for (const { label, cmd } of checks) {
  console.log(`\n=== ${label} : ${cmd} ===`);
  try {
    // Tampilkan hasilnya apa adanya. Jika error, lompat ke catch di bawah.
    const out = execSync(cmd, { encoding: "utf8" });
    console.log(out.trim() || "(tidak ada output)");
  } catch (e) {
    allOk = false;
    console.log("Gagal:", e.message.split("\n")[0]);
  }
}

console.log("\n--- Penutup hari ini ---");
console.log(allOk ? "Verifikasi OK. Sisakan satu baris tugas terkecil berikutnya." : "Verifikasi berhenti. Perbaiki dulu sebelum lanjut.");

Cara menjalankannya cuma ini.

node morning-check.mjs

Triknya adalah menyesuaikan isi checks dengan proyekmu sendiri. Kalau ada test, tambahkan npm test; kalau situs statis, tambahkan pengecekan URL publik. Selama perintah yang sama mengalir dalam urutan yang sama setiap pagi, verifikasi yang terlewat hampir hilang. Saya juga menambahkan pengecekan “apakah berhenti tanpa sempat commit” di sini.

Situasi di mana ini terasa manjur (3 contoh)

Contoh 1: hari pertama cukup buat peta repo Tidak perlu langsung memperbaiki kode. Minta AI meringkas “direktori mana yang berbahaya” dan “di mana file konfigurasi berada”, lalu cukup baca itu, hari pertama sudah sukses. Pekerjaan hari-hari berikutnya jadi jauh lebih cepat.

Contoh 2: hari kedua cukup satu paragraf README Bangun pengalaman sukses yang kecil. Tulis ulang 3 baris paragraf pembuka, lalu cek dengan npm run build apakah ada yang rusak. Cukup itu. Dengan menutup pekerjaan secara kecil dan menuntaskan sampai verifikasi, kamu mendapat rasa “ternyata saya bisa menjalankannya sendiri”.

Contoh 3: hari ketiga satu perbaikan kecil yang terkait angka Perbaiki judul artikel, tambah satu test, atau perbaiki satu tautan rusak. Pilih perbaikan kecil yang hasilnya kelihatan. Yang penting adalah menumpuk satu “perubahan yang lolos sampai verifikasi” setiap hari.

Contoh kegagalan dan cara memperbaikinya

Jujur saja, saya berkali-kali jatuh karena tiga hal ini.

Jebakan 1: mau menyelesaikan semuanya sekaligus. “Semua yang mengganjal” menghasilkan diff raksasa yang tak bisa diverifikasi. Cara memperbaikinya sederhana: persempit satu kalimat tugas hari ini jadi “satu saja”. Sisanya dialihkan ke catatan besok.

Jebakan 2: menganggap selesai hanya dengan build lokal. Walau npm run build lolos, belum tentu URL publik tampil dengan benar. Saya pernah sekali, build hijau tapi halaman publik masih versi lama dan saya tidak sadar. Cara memperbaikinya: setelah publikasi, buka URL aslinya dan lihat dengan mata apakah judul dan awal isi sudah berubah sesuai perubahan kali ini.

Jebakan 3: menekan persetujuan berbahaya karena terbawa arus. Saat dialog konfirmasi muncul, pemula cenderung menekan “Yes saja dulu”. Kalau konfirmasi hapus atau deploy produksi datang, hentikan tangan sejenak. Kalau ragu menilai, jawaban yang benar adalah tidak melakukan operasi itu hari ini. Soal cara pandang izin, penjelasan untuk non-engineer juga bisa jadi rujukan.

Bentuk catatan yang disisakan untuk besok

Catatan terakhir yang disisakan boleh pendek. Tapi tetapkan bentuknya, supaya diri kamu besok pagi tidak mengulang keputusan yang sama.

- Yang dikerjakan hari ini: tulis ulang 3 baris pembuka README
- Cara verifikasi: npm run build berhasil / cek judul lewat URL publik
- Risiko tersisa: ada 2 tautan gambar yang rusak
- Tugas terkecil besok: perbaiki satu tautan gambar saja

Dengan catatan ini, waktu yang terbuang besok pagi untuk bingung “mulai dari mana” jadi nol. Sejak saya mulai melakukannya, terasa pemanasan pagi jadi lebih cepat sekitar 5 menit.

Pertanyaan umum

T. Saya tidak punya 15 menit tiap hari. Bisa lebih singkat? Bisa. Awalnya cukup “tulis satu kalimat tugas terkecil hari ini” saja. Asal kebiasaan menentukan perintah verifikasi terbentuk, waktu kerja akan menyusut dengan sendirinya.

T. Saya tidak tahu apa perintah verifikasinya. Kalau proyekmu punya npm run build atau npm test, mulai dengan itu sudah cukup. Kalau tidak ada apa-apa, “buka URL publik dan lihat dengan mata” pun verifikasi yang sah. Awalnya cukup tetapkan satu hal yang bisa dinilai mesin.

T. Bukankah lebih cepat menyerahkan semuanya ke AI? Sekilas memang terlihat begitu untuk jangka pendek. Tapi “perubahan yang tak bisa kamu jelaskan apa yang diperbaiki” ujungnya tetap harus dibaca ulang semuanya nanti. Menutup pekerjaan secara kecil, totalnya justru lebih cepat, itu pengalaman saya.

T. Apa hal pertama yang harus dilakukan pemula? Membuat peta repo. Sebelum memperbaiki kode, minta AI meringkas di mana letak apa, lalu baca. Ini jadi fondasi untuk maju dengan aman.

T. Apakah rutinitas ini bisa dipakai saat diadopsi tim? Bisa. Hanya saja, di tim sebaiknya didokumentasikan dulu “siapa yang menyetujui publikasi” dan “verifikasi mana yang jadi tujuan”, supaya kebiasaan individu langsung menjadi aturan tim.

Hasil setelah saya coba sendiri

Sejak Jumat malam itu, saya berhenti pusing soal “sampai mana harus menyerahkan ke AI”. Sebagai gantinya, yang saya tentukan setiap pagi cuma dua: satu kalimat hari ini dan perintah verifikasinya.

Setelah menjalankan morning-check.mjs selama dua minggu, yang paling berubah adalah verifikasi yang terlewat. Dulu saya beberapa kali commit dengan merasa build sudah lolos, lalu belakangan ketahuan rusak. Sejak verifikasi mengalir lewat mesin dalam urutan yang sama, hal itu jadi nol.

Lalu, catatan 4 baris yang disisakan tiap malam. Sejak memulainya, kebingungan “tadi mau ngapain ya” di pagi hari lenyap. Daripada mencari cara pakai yang pintar, tutup pekerjaan secara kecil dan sisakan verifikasi. Sederhana, tapi menurut saya di sinilah kecepatan pemula untuk maju ditentukan.

Untuk awal, besok pagi tentukan satu kalimat saja, lalu jalankan satu perintah verifikasi. Saat kamu sudah punya pola sendiri setelah terus melakukannya, perbanyak template permintaan lewat daftar materi supaya langkah harianmu makin sedikit.