Perjalanan Saya Mengadopsi AI

• Mitchell Hashimoto, yang telah exit dari HashiCorp dan kini membuat Ghostty, merangkum prosesnya hingga benar-benar mengintegrasikan alat AI ke dalam pekerjaan nyata
• Ia membaginya ke dalam tiga tahap: inefisiensi → adaptasi → peningkatan produktivitas, sambil mencatat secara rinci proses trial-and-error dan pembelajaran di tiap tahap
• Setelah menyadari keterbatasan coding berbasis chatbot, ia mulai menemukan nilai sesungguhnya saat beralih ke alat berbasis agen
• Dengan melatih agen untuk mereproduksi commit yang sebelumnya ia selesaikan secara manual, ia memahami bahwa pemecahan tugas, pemisahan perencanaan/eksekusi, dan verifikasi otomatis adalah kunci
• Dengan memanfaatkan 30 menit terakhir hari kerja untuk otomatisasi malam hari dan mendelegasikan tugas sederhana yang berulang kepada agen, ia memperoleh peningkatan produktivitas yang nyata
• Kini ia berada pada tahap selalu menjalankan satu agen, sambil menerapkan "harness engineering" untuk mencegah kesalahan dan memaksimalkan efisiensi kolaborasi manusia-AI

---

Latar belakang adopsi dan pendekatan

• Setiap kali mengadopsi alat baru, kita perlu melewati tiga tahap: inefisiensi → kecocokan → inovasi
  • Karena sudah terbiasa dengan workflow yang ada, adopsi awal terasa tidak nyaman, tetapi dalam jangka panjang mengarah pada peningkatan produktivitas
• Alih-alih ekspektasi berlebihan atau kritik ekstrem terhadap alat AI, ia menawarkan sudut pandang yang seimbang berdasarkan pengalaman penggunaan nyata

Step 1: Keluar dari chatbot

• Coding melalui antarmuka chatbot seperti ChatGPT dan Gemini bergantung pada pengetahuan hasil pretraining, dan perbaikan error pun bergantung pada umpan balik berulang dari manusia, sehingga tidak efisien
• Momen "wow" pertamanya adalah saat menempelkan screenshot command palette Zed ke Gemini lalu mereproduksinya dengan SwiftUI, yang kemudian menjadi dasar command palette Ghostty di macOS
• Namun, dalam konteks proyek brownfield (codebase yang sudah ada), chatbot sering menghasilkan hasil buruk, dan proses copy-paste kode maupun output justru lebih tidak efisien daripada mengerjakannya sendiri
• Untuk benar-benar mendapatkan nilai, kita harus menggunakan agen; agen di sini adalah alat yang memungkinkan LLM berulang kali memanggil aksi eksternal, minimal dengan kemampuan membaca file, menjalankan program, dan melakukan HTTP request

Step 2: Mereproduksi pekerjaan sendiri dengan agen

• Saat pertama kali menggunakan Claude Code, ia tidak puas dengan hasilnya, dan pekerjaan koreksi justru memakan waktu lebih lama daripada melakukannya sendiri
• Alih-alih menyerah, ia berulang kali melatih agen untuk mereproduksi commit manual secara identik
  • Ini adalah proses yang menyakitkan karena mengerjakan tugas yang sama dua kali (manual + agen), tetapi friksi seperti ini memang wajar saat mengadopsi alat baru
• Dari proses ini, ia menemukan sendiri tiga prinsip utama:
  • Pecah sesi menjadi tugas yang jelas dan dapat dieksekusi
  • Untuk permintaan yang ambigu, pisahkan sesi perencanaan dan sesi eksekusi
  • Jika agen diberi cara untuk memverifikasi pekerjaannya, ia bisa memperbaiki kesalahannya sendiri dan mencegah regresi
• Memahami area yang tidak dikuasai agen, lalu mengetahui kapan tidak menggunakannya, juga menjadi faktor besar dalam peningkatan efisiensi
• Pada tahap ini ia belum merasakan peningkatan efisiensi bersih, tetapi sudah bisa menerima agen sebagai alat yang memuaskan

Step 3: Memanfaatkan agen di penutup hari

• Ia memperkenalkan pola mengalokasikan 30 menit terakhir setiap hari untuk memulai pekerjaan agen
  • Hipotesisnya: efisiensi bisa didapat jika agen membuat kemajuan saat manusia sedang tidak bekerja
• Tiga jenis tugas yang terbukti efektif:
  • Sesi riset mendalam: meneliti library dengan lisensi tertentu untuk bahasa tertentu, lalu membuat ringkasan multi-halaman tentang kelebihan, kekurangan, aktivitas pengembangan, dan reaksi komunitas
  • Menjelajahi ide ambigu dengan agen paralel: bukan untuk dirilis, tetapi untuk menemukan variabel yang belum diketahui sebelum bekerja keesokan harinya
  • Klasifikasi/review issue dan PR: menggunakan gh (GitHub CLI) untuk triage issue dengan agen paralel; agen tidak merespons secara langsung, hanya membuat laporan untuk ditinjau keesokan harinya
• Ia tidak menjalankan agen berulang sepanjang malam, dan kebanyakan tugas selesai dalam waktu 30 menit
• Dengan mengalihkan waktu lelah di akhir hari ke pekerjaan agen, ia mendapatkan efek "warm start" keesokan paginya

Step 4: Delegasi tugas yang benar-benar pasti

• Setelah mengetahui jenis tugas yang hampir pasti bisa dikerjakan agen dengan baik, ia mendelegasikan tugas itu ke agen background dan dirinya fokus ke pekerjaan lain
• Setiap pagi, ia memfilter hasil triage malam sebelumnya secara manual untuk memilih issue yang cocok bagi agen, lalu menjalankannya satu per satu
• Di waktu ini, alih-alih membuka SNS atau video, ia melakukan pekerjaan berpikir mendalam dengan cara lama sebelum era AI
• Mematikan notifikasi desktop agen adalah kunci: biaya context switching sangat tinggi, jadi yang efisien adalah bukan agen menginterupsi manusia, melainkan manusia mengeceknya saat jeda alami
• Terkait makalah riset pembentukan skill dari Anthropic: ia menerima bahwa skill formation pada tugas yang didelegasikan ke agen memang dilepas, tetapi pada tugas yang tetap dikerjakan manual, pembentukan skill tetap berlanjut secara alami
• Pada tahap ini, ia mencapai tingkat "tidak bisa kembali ke cara sebelumnya", dan keuntungan terbesar adalah bisa fokus pada pekerjaan yang ia sukai

Step 5: Harness engineering

• Agen paling efisien ketika bisa memberikan hasil yang benar pada percobaan pertama, atau setidaknya hanya memerlukan koreksi minimal
• Setiap kali agen melakukan kesalahan, merekayasa solusi agar kesalahan yang sama tidak terulang lagi adalah konsep "harness engineering"
• Ada dua bentuk:
  • Perbaikan prompting implisit (AGENTS.md): jika agen menjalankan perintah yang salah atau menemukan API yang keliru, itu dicatat dalam file AGENTS.md untuk menyelesaikannya — ada contoh nyata di repo Ghostty
  • Alat yang diprogram: menulis script untuk menangkap screenshot, menjalankan test yang sudah difilter, dan sebagainya, lalu memberi tahu agen tentang keberadaan alat itu di AGENTS.md
• Saat ini ia berada di tahap ini, dan aktif berinvestasi untuk mencegah perilaku buruk agen serta memverifikasi perilaku baiknya

Step 6: Selalu menjaga agen tetap berjalan

• Sejalan dengan Step 5, ia menetapkan target agar selalu ada satu agen yang berjalan di background
• Ia menyukai model lambat tetapi berkualitas tinggi, seperti deep mode dari Amp (berbasis GPT-5.2-Codex), yang membutuhkan lebih dari 30 menit tetapi menghasilkan output berkualitas
• Saat ini ia tidak menjalankan banyak agen secara paralel, karena menilai keseimbangan antara satu agen dan pekerjaan manual adalah yang paling tepat
• Dalam praktiknya, hanya sekitar 10~20% dari jam kerja yang diisi oleh agen background yang sedang berjalan, dan ia masih berupaya meningkatkan rasio ini
• Menjalankan agen bukanlah tujuan itu sendiri; agen hanya perlu dijalankan saat benar-benar ada tugas yang membantu, dan membangun workflow delegasi berkualitas tinggi itu penting terlepas dari ada atau tidaknya AI

Kondisi saat ini dan sudut pandang

• Ia sudah menghasilkan dampak dengan alat AI, dan mendekatinya dengan perspektif seimbang yang berpijak pada realitas
• Ia tidak bekerja di perusahaan AI, tidak berinvestasi, dan tidak menjadi penasihat; terlepas dari apakah AI akan terus bertahan atau tidak, motivasi utamanya adalah menikmati proses membuat sesuatu sebagai software craftsman
• Ia sangat mengkhawatirkan masalah pembentukan skill pada developer junior yang fondasinya masih lemah
• Karena laju inovasi model sangat cepat, penilaian terhadap area yang tidak bisa ditangani agen harus terus ditinjau ulang
• Menggunakan atau tidak menggunakan AI adalah pilihan pribadi, dan tulisan ini bertujuan membagikan contoh personal tentang cara mengeksplorasi dan memanfaatkan alat

[GN⁺]

Komentar Hacker News

• Kuncinya adalah membagi sesi menjadi unit kerja yang jelas dan bisa dieksekusi
  Kalau instruksinya terlalu rinci, tidak ada alasan memakai LLM, sementara kalau terlalu luas seperti “tolong buatkan aplikasi Facebook untuk anjing”, hasilnya hanya prototipe yang tidak berguna
  Pada akhirnya, keberhasilan memakai LLM untuk coding adalah soal menemukan cakupan yang pas ini

  • Bagian yang paling saya nikmati saat memakai alat AI justru pembentukan intuisi ini
    Menangkap pekerjaan seperti apa yang akan memberi hasil bagus, lalu menyesuaikan cakupannya, memberi kesenangan yang mirip dengan modularisasi dalam pemrograman
  • Saya pernah gagal karena memberi permintaan yang terlalu besar seperti contoh “Facebook for dogs”
    Di Lovable, rasanya sejak onboarding sudah mengarahkan ke kegagalan, sedangkan dengan Claude Code, saat dipecah menjadi bagian-bagian kecil, hasilnya jauh lebih sukses
  • Kalau LLM dipakai hanya untuk mencari contoh sintaks for, itu nyaman karena bisa mengurangi perpindahan konteks
    Di awal, saya banyak memakainya sebagai bantuan penulisan kode sederhana seperti ini
  • Seiring model berkembang, terasa bahwa batas atas cakupan yang pas itu naik setiap 6–8 minggu
  • Kadang saya bilang “tolong cetak outputnya”, lalu model benar-benar merespons dengan hanya menambahkan print(output)
    Bekerja sambil bolak-balik antara bahasa alami dan kode justru terasa lebih nyaman secara psikologis

• Tahun 2025 adalah tahun ketika alat coding AI benar-benar masuk ke tahap praktis
  Dulu model awal seperti GPT-3 hanya menunjukkan potensi, dan itu memicu hype dan skeptisisme yang berlebihan
  Namun sekarang, banyak pengembang benar-benar mengintegrasikan AI ke workflow mereka
  Kalau masih skeptis, saya sarankan membaca tulisan Mitchell lalu mencoba Claude Code sendiri

  • Saya juga berpikir begitu. Saya penasaran titik mana yang nanti akan diingat sebagai titik balik dalam 10 tahun ke depan
    Dulu orang banyak bicara soal “batas data”, tetapi setelah Claude Code, Sonnet 4.5, dan Opus 4.5 muncul, suasananya benar-benar berubah
  • Saya penasaran apakah ada alasan untuk memakai Claude Code alih-alih Codex atau Gemini
    Kedua model itu terasa mirip, tetapi saya belum mencoba Claude karena kabarnya batas pemakaian paket cepat habis
  • Tetapi saya tetap khawatir dengan struktur industri yang berpusat pada hype
    Saya takut para eksekutif hanya mementingkan kecepatan dan kuantitas lalu memproduksi tumpukan kode yang tidak berkelanjutan

• Pendekatan “Don’t draw the owl” juga sesuai dengan pengalaman saya
  Masalahnya adalah LLM makin lama makin melenceng dari batasan dunia nyata
  Karena itu, chat saya pisahkan untuk diskusi desain, sementara agen hanya menangani pekerjaan diff yang sempit dan bisa diverifikasi
  Setelah loop ini stabil, AI bukan lagi mainan melainkan alat pengungkit yang nyata, dan saya sudah beberapa kali merilis fitur proyek sungguhan dengannya

  • Ada yang menunjukkan bahwa gaya tulisan artikel ini mirip LLM
    Menariknya, belakangan struktur kalimat yang berpola seperti ini juga makin sering terlihat di antara manusia
  • Ada juga pemikiran bahwa pendekatan seperti ini sebenarnya tidak berbeda dari cara kita seharusnya menulis software sejak awal

• Karena diskusi tentang Opus 4.5 makin ramai, saya mencobanya sendiri dan merasa paradigma agen memang jelas menjadi lebih berguna
  Untuk saat ini masih terutama untuk tugas-tugas sederhana, tetapi saya puas

• LLM tidak cocok untuk saya
  Daya pikir dan kreativitas manusialah yang membedakan kita, dan saya merasa menyerahkannya ke mesin justru melemahkan diri sendiri
  Sebagai pengembang Rails, saya sudah mencoba Zed dan Claude Sonnet 4.x serta Opus, tetapi saya benar-benar merasakan kemampuan menulis RSpec saya makin menurun
  Pada akhirnya saya kembali ke neovim dan bekerja tanpa agen
  Kenyamanan pada akhirnya bisa membawa kemunduran kemampuan berpikir
  LLM adalah alat kemudahan terbaik yang pernah dibuat manusia, tetapi saya memilih menjaga keterampilan dan cara berpikir saya

• Tulisan ini terasa jauh lebih praktis dan tidak terlalu dibesar-besarkan dibanding tulisan lain di halaman depan

  • Akhirnya muncul panduan langkah demi langkah yang bahkan bisa diikuti orang skeptis
    Ini pendekatan yang realistis, bukan klaim berlebihan seperti “saya membuat OS dengan vibe coding”

• Menarik melihat semua orang mengalami perjalanan pemanfaatan AI yang mirip
  Saya memakai beberapa model sekaligus untuk bagian berbeda dari codebase, lalu membuat model-model itu saling memverifikasi
  Saya masih sering melakukan git reset, tetapi perlahan belajar cara menghindarinya dengan lebih efisien
  Rasanya seperti hidup di era pelengkapan otomatis untuk otak

• Ada yang bilang “agen harus bisa membaca file, menjalankan program, dan melakukan permintaan HTTP”,
  dan itu hampir setara dengan ‘trinitas mematikan’ yang disebut Simon Willison

  • Karena itu saya sama sekali tidak berniat menjalankannya di mesin lokal saya

• Menjengkelkan karena kita harus terus memberi tahu agen hal-hal yang perlu diperbaiki
  Setiap kali saya harus mengubah agent.md untuk memberi umpan balik, padahal akan lebih bagus kalau ia bisa belajar sendiri dan membaik

  • Tetapi perbaikan menurut seseorang bisa jadi code smell bagi orang lain
    Menambahkan beberapa baris ke AGENTS.md juga bukan pekerjaan besar
    Kalau membuat perintah /fix agar bisa otomatis memperbaiki dan mendokumentasikannya, itu cukup menghemat waktu
  • Justru saya menikmati memberi umpan balik
    Itu memberi saya rasa bahwa kendali rekayasa tetap ada di tangan saya
    Terutama karena saya bisa mengulang riset dan implementasi fitur baru dengan cepat

• Kalau penasaran seperti apa pendekatan ini dalam praktik,
  ada baiknya melihat tulisan blog lama OP, “Non-trivial Vibing”, dan diskusi HN tentangnya