- Mengoperasikan workflow "AI factory" pribadi yang mengotomatiskan dari pembuatan kode hingga verifikasi dengan memanfaatkan berbagai agen AI (claude/o3/sonnet, dll.)
- Saat masalah muncul, inti pendekatannya adalah meningkatkan tingkat otomasi dengan memperbaiki input seperti rencana, prompt, dan komposisi agen, alih-alih langsung mengubah kode (output)
- Dengan terus menyempurnakan input secara berulang, para agen terus berkembang sehingga produktivitas untuk pekerjaan berulang dapat dimaksimalkan
- Pembagian peran tiap agen: dibedakan menjadi perencanaan (o3/sonnet4), eksekusi (sonnet3.7/4), verifikasi (o3/sonnet4), dll., untuk mewujudkan pemrosesan paralel dan loop umpan balik otomatis
- Kesalahan kode atau masalah gaya juga dicerminkan ke template rencana agar diperbaiki mulai generasi berikutnya, sehingga factory itu sendiri bertumbuh melalui penyempurnaan input yang berulang
Gambaran umum AI factory dan prinsip intinya
- Menjalankan beberapa jendela claude code pada git-worktree yang berbeda untuk mempertahankan lingkungan kerja yang terpisah
- o3 dan sonnet 4 digunakan untuk menyusun rencana, sonnet 3.7 atau sonnet 4 untuk eksekusi, dan o3 untuk mengevaluasi hasil
- Penyusunan rencana, eksekusi, dan verifikasi dibagi secara paralel antaragen untuk meningkatkan efisiensi
Prinsip inti – "Memperbaiki input itu sendiri, bukan hasil (output)"**
- Jika muncul masalah, alih-alih menambal langsung kode yang dihasilkan, ia mengejar perbaikan otomatis dengan menyesuaikan rencana, prompt, dan campuran agen
- Konsepnya adalah membangun jaringan agen AI bergaya pabrik yang tumbuh secara otomatis, seperti game Factorio
- Dalam struktur ini, loop perencanaan-pengodean-verifikasi-perbaikan terus berputar, menciptakan lingkungan tempat agen AI sendiri memproduksi/memverifikasi/memperbaiki kode
Workflow harian – struktur factory
- Antarmuka utama adalah claude code, dan secara lokal memanfaatkan mcp, Goose (untuk menghubungkan model Azure OpenAI), o3, dan lainnya
Langkah 1: Perencanaan (Planning)
- Memasukkan task tingkat tinggi ke claude code → setelah o3 mengajukan pertanyaan tambahan, ia membuat draf rencana (
<task>-plan.md)
- Draf rencana mencakup permintaan asli dan rencana implementasi
Langkah 2: Eksekusi (Execution)
- sonnet 4 meninjau rencana lalu mengubahnya menjadi daftar task
- claude code mengeksekusi pekerjaan, dan menggunakan sonnet 3.7 atau 4 tergantung kompleksitas tugas
- Karena claude meninggalkan riwayat commit di setiap tahap kerja, rollback menjadi mudah saat masalah terjadi
Langkah 3: Verifikasi dan umpan balik (Verification → Feedback)
- sonnet 4 melakukan verifikasi awal terhadap kode yang dihasilkan berdasarkan rencana
- Setelah itu, o3 melakukan verifikasi yang lebih ketat dengan membandingkannya terhadap rencana dan persyaratan awal
- o3 dengan tegas menunjuk kode yang tidak perlu (misalnya flag lint ignore) atau struktur yang sudah usang
- Masalah yang terungkap saat verifikasi dicerminkan bukan dengan mengubah kode secara langsung, melainkan melalui penyempurnaan template rencana
- Dengan memanfaatkan git worktree, beberapa instance claude code dijalankan secara paralel, sehingga banyak pekerjaan simultan dimungkinkan
Mengapa "input" lebih penting daripada "output"
- Hasil (output) bisa dibuang, tetapi rencana/prompt (input) terus diakumulasikan dan diperbaiki sebagai aset kumulatif
- Jika debugging dilakukan pada bagian input (rencana, prompt), hasilnya dapat diperluas ke semua pekerjaan di masa depan
- Ini mengubah agen dari generator sederhana menjadi entitas yang belajar sendiri dan berkolaborasi
- Contoh: membuat kode yang memuat seluruh CSV ke memori diubah menjadi pemrosesan stream, lalu pola itu diterapkan ke rencana untuk semua CSV sehingga verifikasi otomatis di masa depan menjadi mungkin
Ekspansi factory dan kolaborasi agen
- Dengan MCP, agen yang terspesialisasi ditugaskan ke pekerjaan yang berbeda dan diparalelkan
- Contoh: mengoperasikan agen khusus untuk menerapkan aturan style lokal dengan mengumpulkan seluruh kode Clojure, sehingga claude dapat mengoreksi masalah style yang muncul dalam siklus lint/test/debug
- Bahkan pada kode library internal, penggunaan retry lama dan
Thread/sleep dalam kode lama diganti dengan library retry internal untuk memperkuat produktivitas dan konsistensi
- Dengan membangun banyak agen berunit kecil, workflow yang kompleks pun dapat diotomatisasi dengan menggabungkannya untuk subtask tertentu
- Contoh: dari spesifikasi API dan business case, kombinasi agen dapat menangani integrasi, pengujian, hingga dokumentasi secara otomatis
- Intinya: terus mengubah input sambil menjalankan ulang berulang kali, lalu mencerminkan umpan balik pada percobaan berikutnya saat terjadi kegagalan/stagnasi/kekurangan konteks
- Kode itu sendiri adalah barang habis pakai, aset yang sebenarnya adalah instruksi (input) dan konfigurasi agen
- Semua pelajaran dari kegagalan, stagnasi, dan kurangnya konteks diterapkan ke input berikutnya untuk melengkapi loop factory
Langkah berikutnya dan arah masa depan
- Berupaya memperkuat koordinasi menyeluruh antaragen untuk melacak seluruh workflow dan mendorong penerapan otomasi
- Memperbaiki pemanfaatan dengan menghubungkan dokumen bisnis dan informasi agen secara lebih baik, serta menangkap terutama informasi abstraksi tingkat tinggi agar bisa digunakan lebih efektif
- Ingin mewujudkan workflow yang makin kompleks, sambil memperluas kolaborasi dan interaksi kompleks antaragen
- Juga sedang mencari cara untuk memaksimalkan kuota token dari berbagai penyedia dan memudahkan perpindahan (terutama untuk menghadapi batas token bedrock sonnet 4)
Kesimpulan
- Saat ini AI factory telah membuat pembuatan dan verifikasi kode otomatis menjadi hal sehari-hari, sehingga kode bisa dideploy bahkan selama secangkir kopi
- Walau belum sepenuhnya otomatis, prinsip "memperbaiki input alih-alih memperbaiki output" kini telah menjadi esensi factory
1 komentar
Komentar Hacker News
Saya rasa tulisan ini hampir mustahil dipahami oleh orang yang belum pernah mengalami momen 'aha' dengan Claude Code
Jika pembatasan izin dilepas dengan
"claude --dangerously-skip-permissions"lalu diberi masalah yang rumit, kita bisa melihat Claude memakai berbagai alat secara bebas untuk menyelesaikannyaHari ini pun saya menyuruhnya mengompilasi, menjalankan, dan men-debug generator fraktal Mandelbrot berbasis 486 assembly lewat Docker
Hasilnya benar-benar sangat bagus
tautan gist
Menurut saya ini contoh yang sangat mudah untuk IDE atau LLM seperti itu
Assembly sudah cukup banyak ada di dataset pelatihan, begitu juga Docker
Saya juga pernah membiarkan Cursor bebas menjelajah codebase saya
Saya berharap tool-tool terbaru pada akhirnya benar-benar bisa sampai ke titik itu, tetapi rasanya belum sampai sana
Saya juga ingin merekomendasikan video ini, presentasi dari Dagger (dan pendiri Docker) di konferensi AI Engineer
Video ini juga mungkin terasa agak sulit dipahami
Saya tulis ini kalau-kalau bisa membantu
Saya menurunkan langganan Claude dari max ke pro, dan batas pemakaian dengan 20 dolar per bulan sudah lebih dari cukup
Kelihatannya mereka sedang bersaing dengan Gemini CLI, jadi saya senang sekarang membayar lebih sedikit
Saya rasa hampir semua LLM bisa menangani contoh dan konteks seperti ini tanpa banyak kesulitan
Saya sendiri pernah mengulang upgrade dependensi Rust yang jauh lebih kompleks lebih dari 30 kali, dan menanganinya dengan kode wasm kustom
Claude mengumpulkan detail sambil menghubungkan berbagai tool seperti context7 atau mcp-lsp
Tetapi kalau terus dipakai, pada akhirnya akan mentok pada batasnya, jadi kalau didorong ke tugas yang lebih rumit dan lebih berat, kelemahannya akan terlihat
Soal kalimat bahwa dengan
"claude --dangerously-skip-permissions"kita bisa memberi masalah rumit lalu ia akan memakai banyak tool untuk menyelesaikannyaSaya pernah melihat Claude menghabiskan lebih dari satu jam mencoba memperbaiki kode dengan cara yang salah
Pada akhirnya saya harus turun tangan dan menyuruhnya, "tulis dulu unit test, lalu setelah test lolos tulis ulang kodenya dan beri tahu saya"
Claude Code memang tool yang sangat keren, tetapi kenyataannya kita tetap harus terus-menerus mengulang peta arsitektur dasar untuknya
Sulit menilai setup seperti ini tanpa tahu hasil kodenya benar-benar dipakai bagaimana
Kalau ini hanya aplikasi vibe coding untuk pemakaian pribadi, cerita seperti ini sangat mudah dipercaya,
tetapi cerita bahwa ia menulis kode berkualitas tinggi untuk lingkungan production yang kompleks rasanya tidak mudah diterima
Sangat setuju
Saya memang sangat mempercepat kecepatan coding dengan Claude Code, tetapi untuk setiap perubahan kode saya selalu cek sendiri apakah sistem terbaik benar-benar sedang dibangun
Dalam beberapa percobaan yang hanya saya biarkan berjalan sendiri, hasilnya justru memberi bug ke pengguna
Sebenarnya saya kurang paham workflow atau konsep yang dijelaskan tulisan ini
Mungkin karena penjelasannya agak samar
Saya sehari-hari menangani sistem production yang kompleks dengan memanfaatkan struktur banyak agen yang saling berbicara, agen asinkron, git work tree, dan semacamnya
Bukan berarti saya tidak pernah mengubah hasil output, tetapi kalau hasil yang diinginkan tidak keluar, saya cenderung menganggap itu sebagai sinyal untuk memperbaiki workflow saya
Saya juga sedang mencoba workflow yang mirip, jadi ingin berbagi pengalaman saya
Codebase Go yang saya tangani berukuran ratusan ribu baris, dan benar-benar dipakai oleh puluhan ribu hingga ratusan ribu pengguna B2C
Performanya longgar, tetapi akurasi dan reliabilitas sangat penting karena ini domain finansial
Saya berada di lingkungan yang hanya memakai key OpenAI, jadi saya cuma memakai codex-cli dan skrip sederhana untuk setup dasar seperti clone repo, menyiapkan agen, menjalankan prompt, dan sebagainya
Instance codex memberi tahu giliran saya lewat notifikasi sistem, dan saya memakai fzf untuk attach ke sesi tmux saat diperlukan
Saya belum mencoba MCP, tetapi sudah ada di daftar yang ingin saya lihat
Cara seperti ini sangat membantu untuk menangani task-task kecil yang tersebar, dan sekarang saya bisa membuat jauh lebih banyak PR kecil
Metafora
"cattle not pets"masih berlaku; saya cukup melempar prompt cepat untuk pekerjaan kecil agar distraksi berkurangUntuk pekerjaan yang lebih besar, sepertinya masih belum terlalu cocok, mungkin juga karena saya belum berhasil membangun context flywheel yang memadai
Sebagian besar waktu saya tetap selalu membaca dan membenahi sendiri kode hasilnya sebelum masuk code review
Pengelolaan perubahan juga hampir semuanya masih manual; branch, commit, dan push pun saya lakukan sendiri
Saya juga sudah mencoba beberapa tool otomatisasi, tetapi belum benar-benar pindah penuh
Saya 100% setuju dengan pola pikir "perbaiki inputnya, bukan outputnya"
Itu prinsip yang sangat kuat bahkan tanpa AI, dan industri juga makin banyak menerimanya
Pada proses nondeterministik seperti LLM, penerapannya tidak mudah dan rasanya lebih dekat ke latihan daripada sains
Terima kasih atas tulisan yang bagus
Di tulisan saya tentang "Vibe Specs", saya memperkenalkan workflow yang mirip tetapi sedikit lebih sederhana
makalah blog terkait
Saya memakai aturan ini di seluruh codebase, dan membuat AI bertindak berbeda dalam dua hal
(1) apa pun yang terjadi, ia harus bertanya lebih dulu
(2) sebelum coding, ia harus membuat dokumen
spec.mdTema besarnya mirip, tetapi saya membatasinya pada satu LLM saja
Sepertinya kebanyakan dari kita mencoba hal yang kurang lebih serupa
Sebagai developer individu, saya bereksperimen dengan berbagai otomatisasi produktivitas dengan pola pikir yang berpusat pada engineering
Bagi saya, tujuan akhirnya adalah mendapatkan kepercayaan terhadap kode dari e2e test yang dibuat otomatis oleh agen, terlepas dari implementasinya
Saya belum sepenuhnya berhasil sampai ke sana
Sekarang Claude Code juga mendukung alur seperti ini secara native lewat “plan mode”
Membuat file .md secara manual sebenarnya terasa lambat dan merepotkan
Gagasan dasarnya adalah bahwa kita bisa terus mendokumentasikan apa yang harus dilakukan sistem (baik level tinggi maupun fitur rinci), bagaimana membuktikan bahwa ia bekerja, sampai cara implementasinya seperti arsitektur dan gaya kode
Alasan memakai banyak model adalah untuk mengurangi bias dan menambah pilihan fine-tuning yang sesuai untuk tugas tertentu
Suatu hari nanti, bahkan sistem besar yang kompleks pun mungkin bisa dibangun ulang berdasarkan sekumpulan requirement, dan pada saat itu software akhirnya akan benar-benar selaras dengan spesifikasi kebutuhannya
Pada titik itu, satu-satunya ‘legacy code’ yang tersisa hanyalah dokumen spesifikasi legacy
Sudut pandangnya adalah: jangan perbaiki kode hasil generasi, perbaikilah spesifikasi kebutuhannya
gambar meme terkait
Saya penasaran sebenarnya mereka membuat apa dalam praktiknya
Setiap kali orang bicara tentang workflow AI, sulit menilai apakah yang dibicarakan itu alur kerja nyata yang produktif atau hanya setengah seperti mimpi
Kalau LLM yang menulis semua kodenya, saya malah kehilangan minat
Dari sekitar 50 proyek, hanya 2 yang dibuat dengan LLM, dan itu pun tetap saya sentuh sendiri
Sisanya cuma berangkat dari pikiran “akan bagus kalau ada”, tetapi saya sebenarnya tidak terlalu peduli pada hasil akhirnya
Akhirnya saya terjebak dalam loop bergulat dengan berbagai model dan detail implementasi, lalu ketika perilaku yang diinginkan tidak muncul, saya melempar dokumen desain, prompt, dan data contoh sambil terus berdebat dengan komputer
Jauh lebih cepat dan lebih tidak membuat stres jika komputer hanya membantu melengkapi sedikit demi sedikit saat saya menulis kode
Kalau dipikir-pikir lagi, rasanya saya hanya menghabiskan waktu dan biaya, lalu hasilnya cuma software yang sekadar jalan seadanya
Kalau ada requirement yang jelas atau codebase yang sudah ada, dan saya memimpin dengan arahan yang kuat, agen bisa cukup membantu, tetapi alur seperti vibe coding sama sekali tidak menyenangkan dan kualitas yang saya inginkan jarang keluar, kecuali mungkin untuk skrip kecil atau aplikasi niche
Biayanya juga terlalu mahal dan kodenya tetap berantakan
Akhirnya terasa seperti menghabiskan waktu dalam perdebatan tanpa akhir dengan komputer
Kalau begitu, jauh lebih baik saya kerjakan sendiri saja
Masalah saat banyak agen bekerja di work tree masing-masing adalah tiap agen mengusulkan ide yang sama sekali berbeda di setiap detail, sehingga pengalaman pengguna sama sekali tidak konsisten
Misalnya agen yang membuat dashboard Documents dan dashboard Design bisa merancang dari sudut pandang yang benar-benar berbeda
Konsistensi desain, struktur, skema DB, maupun desain API semuanya jadi tidak seragam
Meskipun inputnya sama, outputnya berbeda
Akhirnya, demi menjaga konsistensi, file instruksi terus bertambah, dan untuk proyek besar ukurannya bisa mencapai ribuan baris sehingga context window pun tidak cukup
Karena itu saya rasa lebih tepat memakai LLM kecil yang hanya dilatih pada rule dan skema tertentu
Daripada LLM besar yang menangani ide seluas alam semesta lewat prompt, LLM kecil tampaknya justru jawaban yang benar
Hasil tiap agen benar-benar berbeda, dan desainnya tidak konsisten
Akhirnya tetap butuh senior
Baik AI maupun manusia, kita tetap harus menyediakan sendiri struktur minimal dan fleksibilitas agar semuanya bergerak ke arah yang diinginkan
Kalau tidak ada struktur, jauh lebih baik menulis kodenya sendiri saja
Saya membuat versi pertama sendiri, lalu setelah itu lebih mudah menjaga konsistensi dengan menyuruh Claude Code, "buat seperti contoh ini"
Coding ala ADHD, mencoba menghasilkan produk secara serampangan lalu mengulang sampai cocok?
Bukankah lebih baik langsung menulis sendiri kode yang bisa dikembangkan ke depan
Saya cenderung berpikir tidak perlu menambah jejak karbon untuk hal seperti ini
Tujuan akhirnya adalah menyingkirkan developer dari proses ini
Pemilik bisnis meminta aplikasi CRUD baru lalu langsung tayang ke production
Tentu saja hasilnya penuh bug, lambat, dan menyimpan data di DB yang tidak diautentikasi, tetapi dengan mentalitas bahwa itu bukan urusan saya
Lalu ditutup dengan ungkapan emosional tentang menenggak teh panas sekaligus
Pemrograman sudah berubah selamanya, dan perubahan itu harus cepat diterima
Kalimat “tinggal tulis saja kodenya” itu seperti bersikeras agar semua orang tetap merawat kereta kuda sendiri
Mobil juga bisa rusak, tetapi itu bukan alasan untuk memaksakan cara lama
Saya heran kenapa selalu muncul argumen ‘lebih baik langsung tulis sendiri dengan kode yang bisa dikembangkan ke depan’
Coding assistant zaman sekarang juga bisa menulis kode yang scalable dan maintainable secara zero-shot; saya jadi ingin bertanya apakah itu benar-benar pernah dicoba dengan permintaan seperti itu
Pada akhirnya manusia juga mencari jawaban lewat trial and error terus-menerus
Perbedaannya hanya orang yang lebih berpengalaman bisa melakukan lebih banyak simulasi di kepala
Kalau jejak karbon dijadikan masalah, sudut pandang lainnya adalah: kalau data center AI berjalan dengan energi terbarukan, apakah itu lalu dianggap baik-baik saja?
Saya rasa kita perlu mencari cara mengintegrasikan AI ke workflow dengan lebih efektif
Orang-orang yang sudah aktif mengadopsi AI tampaknya mengalami kegelisahan yang mirip, tetapi belum ada solusi yang benar-benar pasti
Pada tahap ini, kuncinya menurut saya adalah memberi AI peran seminimal mungkin tetapi dengan tugas yang sangat jelas
Misalnya, untuk workflow agen riset saham, saya membuat dua AI bernama ‘Bullish Guy’ dan ‘Bearish Guy’ agar mereka berdebat tentang kelebihan dan kekurangan satu saham
Dengan menyuruh mereka meneliti dari posisi yang saling berlawanan, hasil analisisnya menjadi lebih komprehensif sekaligus lebih mendalam
Ide seperti ini sebenarnya terinspirasi dari cara orang berdebat di media sosial
Dalam vibe-coding, rasanya hasil akhirnya jarang lebih dari sekadar pembicaraan yang saling merujuk ke dirinya sendiri, dan pada akhirnya tampak seperti hobi mahal yang penuh aktivitas membuat mainan tanpa akhir, penerus 3D printing
Saya jadi bertanya-tanya apakah contoh yang setara dengan “benchy” di vibe coding zaman sekarang tidak lebih dari aplikasi todo
Orang yang mendesain produk atau mengerjakan engineering memakainya semua
Satu-satunya alasan konsumen umum tidak memanfaatkannya adalah karena hampir semua barang plastik yang mereka butuhkan sudah bisa langsung dipesan dari Amazon
Kalau ini terjadi sebelum era belanja online, teknologi itu akan jauh lebih berguna bagi orang kebanyakan
Ke depannya, ini mungkin benar-benar hanya akan menjadi teknologi yang dibutuhkan oleh orang-orang yang mampu merancang file kustom sendiri