- Produk perangkat lunak beta internal ini menjadi eksperimen dengan batasan tetap berupa 0 baris kode yang ditulis manual, di mana Codex menulis logika aplikasi, pengujian, konfigurasi CI, dokumentasi, observabilitas, hingga alat internal
- Codebase yang dimulai dari repositori git kosong berkembang menjadi sekitar 1 juta baris dalam waktu sekitar 5 bulan, dengan tiga engineer menjalankan Codex untuk membuka dan menggabungkan sekitar 1.500 PR sebagai throughput PR
- Pekerjaan utama engineer bergeser dari menulis kode ke merancang lingkungan, menspesifikasikan niat, dan membangun feedback loop agar agen dapat bekerja dengan andal
- Pengetahuan repositori dikelola melalui
AGENTS.mdyang singkat,docs/yang terstruktur, rencana eksekusi, linter, dan CI, sementara UI, log, metrik, dan trace diubah menjadi keterbacaan aplikasi yang bisa langsung dibaca dan diverifikasi oleh Codex - Dengan peningkatan throughput, meminimalkan merge gate dan mengandalkan perbaikan berbasis eksekusi lanjutan menjadi pilihan yang praktis, tetapi konsistensi arsitektur jangka panjang dan pengodean penilaian manusia masih menjadi hal yang dipelajari
Beta internal yang dibuat dengan 0 baris kode yang ditulis manual
- Selama 5 bulan terakhir, dilakukan eksperimen untuk membangun dan merilis produk perangkat lunak beta internal dengan 0 baris kode yang ditulis manual
- Produk ini memiliki pengguna internal harian dan alpha tester eksternal, serta sudah benar-benar mengalami alur rilis, deployment, insiden, dan perbaikan
- Semua baris kode, mulai dari logika aplikasi, pengujian, konfigurasi CI, dokumentasi, observabilitas, hingga alat internal, ditulis oleh Codex, dan diperkirakan dibangun dalam sekitar 1/10 waktu dibanding menulis kode dengan tangan
- Manusia mengarahkan, agen mengeksekusi
- Hasil akhirnya, yang pada akhirnya mencapai skala 1 juta baris, harus dirilis dalam hitungan beberapa minggu, dan untuk itu pekerjaan utama tim engineering bergeser dari menulis kode ke merancang lingkungan, menspesifikasikan niat, dan membangun feedback loop
Dimulai dari repositori git kosong
- Commit pertama pada repositori kosong terjadi pada akhir Agustus 2025
- Scaffold awal seperti struktur repositori, konfigurasi CI, aturan formatting, konfigurasi package manager, dan framework aplikasi dibuat oleh Codex CLI yang menggunakan GPT-5 dengan panduan dari sebagian template yang sudah ada
- File
AGENTS.mdawal yang memandu cara agen bekerja di repositori juga ditulis oleh Codex - Tidak ada kode lama buatan manusia yang menopang sistem, dan repositori dibentuk oleh agen sejak awal
- Lima bulan kemudian, repositori berkembang menjadi sekitar 1 juta baris yang mencakup logika aplikasi, infrastruktur, alat, dokumentasi, dan utilitas developer internal
- Tiga engineer menjalankan Codex untuk membuka dan menggabungkan sekitar 1.500 PR, setara dengan throughput rata-rata 3,5 PR per engineer per hari
- Bahkan setelah tim berkembang menjadi tujuh engineer, throughput terus meningkat
- Hasil ini bukan sekadar output demi output; produknya digunakan oleh ratusan pengguna internal, termasuk power user internal
- Sepanjang proses pengembangan, manusia tidak berkontribusi langsung pada kode, dan tidak ada kode yang ditulis manual menjadi filosofi inti tim
Mendefinisikan ulang peran engineer
- Batasan bahwa manusia tidak melakukan coding langsung memperkenalkan jenis pekerjaan engineering yang berbeda, berfokus pada sistem, scaffolding, dan leverage
- Kemajuan awal lebih lambat dari perkiraan, tetapi bukan karena kurangnya kemampuan Codex, melainkan karena lingkungan belum dispesifikasikan dengan cukup baik
- Agen kekurangan alat, abstraksi, dan struktur internal yang dibutuhkan untuk membuat kemajuan menuju tujuan tingkat tinggi
- Pekerjaan utama tim engineering adalah membuat agen mampu melakukan hal-hal yang berguna
- Pekerjaan nyatanya dilakukan dengan pendekatan depth-first: memecah tujuan besar menjadi blok yang lebih kecil seperti desain, kode, review, dan pengujian; memberi prompt kepada agen untuk membuat blok-blok itu; lalu menjadikannya pijakan untuk tugas yang lebih kompleks
- Saat gagal, solusinya bukan “mencoba lebih keras”, melainkan mencari kemampuan apa yang hilang agar Codex bisa mengerjakan tugas itu, lalu membuatnya bisa dibaca dan diikuti oleh agen
- Manusia sebagian besar berinteraksi dengan sistem melalui prompt, dengan alur di mana engineer menjelaskan tugas, menjalankan agen, lalu memintanya membuka PR
- Dalam proses menyelesaikan PR, Codex meninjau perubahannya sendiri secara lokal, meminta review agen tambahan secara lokal dan di cloud, menanggapi feedback dari manusia atau agen, dan mengulangi proses ini sampai semua reviewer agen puas, dengan pendekatan yang mendekati Ralph Wiggum Loop
- Codex secara langsung menggunakan alat pengembangan standar seperti
gh, script lokal, dan skill bawaan repositori untuk mengumpulkan konteks tanpa perlu copy-paste oleh manusia - Manusia bisa mereview PR, tetapi itu tidak wajib, dan seiring waktu hampir semua pekerjaan review berpindah menjadi proses antaragen
Meningkatkan keterbacaan aplikasi
- Saat throughput kode meningkat, bottleneck berpindah ke kapasitas QA manusia
- Karena batasan tetapnya adalah waktu dan perhatian manusia, kemampuan agen diperluas dengan membuat UI aplikasi, log, dan metrik aplikasi itu sendiri dapat langsung dibaca oleh Codex
- Aplikasi disusun agar bisa di-boot per git worktree, sehingga Codex dapat menjalankan dan mengoperasikan satu instance untuk setiap perubahan
- Chrome DevTools Protocol dihubungkan ke runtime agen, lalu dibuat skill untuk snapshot DOM, screenshot, dan tugas navigasi
- Melalui ini, Codex dapat mereproduksi bug, memverifikasi perbaikan, dan menalar perilaku UI secara langsung
- Log, metrik, dan trace diekspos ke Codex melalui stack observabilitas lokal yang hanya ada sementara untuk worktree tertentu
- Codex bekerja pada versi aplikasi yang sepenuhnya terisolasi, termasuk log dan metriknya, dan ketika tugas itu selesai, log serta metrik terkait juga dihapus
- Agen melakukan query log dengan LogQL dan query metrik dengan PromQL
- Prompt seperti “pastikan startup service selesai dalam waktu di bawah 800ms” atau “pastikan tidak ada span pada empat user journey utama yang melebihi 2 detik” berubah menjadi tugas yang dapat dijalankan
- Satu eksekusi Codex sering kali mengerjakan satu tugas selama lebih dari 6 jam, dan waktu itu kerap terjadi saat manusia sedang tidur
Menjadikan pengetahuan repositori sebagai catatan sistem
- Salah satu tantangan utama untuk membuat agen efektif dalam pekerjaan besar dan kompleks adalah manajemen konteks
- Codex tidak membutuhkan buku petunjuk 1.000 halaman, melainkan peta
- Konteks adalah sumber daya yang langka, dan file instruksi raksasa akan menyingkirkan tugas, kode, serta dokumen yang relevan, sehingga agen melewatkan batasan inti atau mengoptimalkan batasan yang salah
- Terlalu banyak panduan justru berhenti menjadi panduan; ketika semuanya penting, tidak ada yang penting, sehingga agen cenderung berhenti menjelajah dengan sengaja dan hanya melakukan pencocokan pola lokal
- Satu manual raksasa cepat usang, berisiko menjadi kuburan aturan lama dan gangguan menarik yang tidak dipelihara manusia
- Satu file besar juga sulit diverifikasi secara mekanis untuk hal-hal seperti cakupan, kebaruan, kepemilikan, dan cross-link, sehingga drift menjadi tak terhindarkan
AGENTS.mddiperlakukan bukan sebagai ensiklopedia, melainkan daftar isi- Basis pengetahuan repositori ditempatkan di direktori
docs/yang terstruktur dan diperlakukan sebagai catatan sistem AGENTS.mdsingkat sekitar 100 baris dimasukkan ke konteks dan berperan sebagai peta yang menunjuk ke sumber kebenaran yang lebih dalam- Dokumen desain dikatalogkan dan diindeks bersama kumpulan keyakinan inti yang mendefinisikan status validasi dan prinsip operasi yang mengutamakan agen
- Dokumen arsitektur menyediakan peta tingkat atas untuk domain dan lapisan package
- Dokumen kualitas memberi peringkat pada tiap domain produk dan lapisan arsitektur serta melacak kesenjangan dari waktu ke waktu
- Rencana diperlakukan sebagai artefak kelas satu; perubahan kecil memakai rencana ringan yang bersifat sementara, sementara tugas kompleks disimpan ke repositori sebagai rencana eksekusi yang menyertakan progres dan log keputusan
- Rencana aktif, rencana selesai, dan utang teknis yang diketahui semuanya berada dalam version control dan ditempatkan bersama, sehingga agen dapat bekerja tanpa bergantung pada konteks eksternal
- Struktur ini memungkinkan pengungkapan bertahap: agen memulai dari titik masuk yang kecil dan stabil, lalu mempelajari ke mana harus melihat berikutnya, alih-alih langsung kewalahan
- Linter khusus dan job CI memverifikasi kebaruan, cross-link, dan ketepatan struktur basis pengetahuan
- Agen perawatan dokumentasi yang berjalan berulang mencari dokumen lama atau obsolete yang tidak lagi mencerminkan perilaku kode nyata, lalu membuat PR perbaikan
Keterbacaan bagi agen adalah tujuan
- Karena seluruh codebase merupakan hasil buatan agen, target optimasi tertinggi adalah keterbacaan bagi Codex
- Seperti halnya membuat kode mudah dijelajahi oleh engineer baru, tujuan engineer manusia adalah membuat agen bisa menalar seluruh domain bisnis langsung dari repositori itu sendiri
- Dari sudut pandang agen, sesuatu yang tidak dapat diakses dalam konteks saat runtime pada dasarnya tidak ada
- Pengetahuan di Google Docs, thread chat, atau di kepala seseorang bukanlah objek yang dapat diakses sistem; yang dapat dilihat agen hanyalah kode, Markdown, skema, dan rencana eksekusi yang berada di repositori lokal dan berada dalam version control
- Sekalipun tim menyepakati pola arsitektur lewat diskusi Slack, jika agen tidak dapat menemukannya, maka itu sama saja dengan pengetahuan yang tidak diketahui oleh anggota baru yang bergabung tiga bulan kemudian
- Memberi lebih banyak konteks ke Codex bukan berarti menuangkan instruksi acak, tetapi mengatur dan mengekspos informasi yang benar agar agen bisa menalar
- Jika agen diberi prinsip produk, norma engineering, budaya tim, bahkan preferensi emoji seperti saat onboarding anggota tim baru, hasilnya akan lebih selaras
- Dependensi dan abstraksi diutamakan dalam bentuk yang sepenuhnya terinternalisasi dan dapat ditalar di dalam repositori
- Teknologi yang sering dianggap “membosankan” cenderung lebih mudah dimodelkan oleh agen karena komposabilitas, stabilitas API, dan representasinya dalam data pelatihan
- Dalam beberapa kasus, lebih murah bagi agen untuk mengimplementasikan ulang sebagian fungsi daripada harus mengatasi perilaku tingkat tinggi yang opak dari library publik
- Alih-alih mengambil package gaya
p-limityang umum, tim mengimplementasikan helper map-with-concurrency sendiri yang terintegrasi erat dengan instrumentasi OpenTelemetry, memiliki cakupan pengujian 100%, dan berperilaku tepat sesuai ekspektasi runtime - Semakin banyak sistem yang ditarik ke bentuk yang bisa langsung diperiksa, diverifikasi, dan diperbaiki oleh agen, semakin besar pula leverage bukan hanya untuk Codex tetapi juga agen lain seperti Aardvark yang bekerja pada codebase yang sama
Memaksa arsitektur dan selera
- Dokumentasi saja tidak cukup untuk menjaga konsistensi dalam codebase yang sepenuhnya dihasilkan agen
- Dengan memaksakan invariant tanpa mengelola implementasi secara terlalu rinci, agen dapat merilis dengan cepat tanpa melemahkan fondasi
- Codex diwajibkan untuk mem-parse bentuk data di boundary, tetapi cara melakukannya tidak ditentukan sampai detailnya
- Agen bekerja paling efektif di lingkungan dengan boundary yang ketat dan struktur yang dapat diprediksi, sehingga aplikasi dibangun di sekitar model arsitektur yang kokoh
- Setiap domain bisnis dibagi ke dalam kumpulan lapisan yang tetap, dan arah dependensi serta koneksi yang diizinkan diverifikasi secara ketat
- Batasan ini ditegakkan secara mekanis melalui linter kustom dan structural test yang dibuat oleh Codex
- Dalam setiap domain bisnis, kode hanya boleh bergantung ke depan mengikuti lapisan tetap
Types → Config → Repo → Service → Runtime → UI - Concern lintas domain seperti autentikasi, connector, telemetry, dan feature flag hanya boleh masuk melalui satu antarmuka eksplisit bernama
Providers - Dependensi lain tidak diizinkan dan diblokir secara mekanis
- Arsitektur seperti ini biasanya ditunda sampai ada ratusan engineer, tetapi dalam lingkungan coding agent, ini menjadi prasyarat awal untuk menjaga kecepatan sambil mencegah pembusukan dan drift arsitektur
- Dalam praktik operasional, aturan ditegakkan lewat linter kustom, structural test, dan kumpulan kecil “invariant selera”
- Structured logging, aturan penamaan schema dan type, batas ukuran file, serta persyaratan keandalan spesifik platform ditegakkan secara statis lewat custom lint
- Pesan error pada custom lint ditulis agar menyuntikkan instruksi perbaikan ke konteks agen
- Dalam workflow yang mengutamakan manusia, aturan seperti ini bisa terasa terlalu teliti atau membatasi, tetapi dalam lingkungan agen, aturan yang sudah sekali dienkode menjadi pengali yang langsung berlaku ke seluruh sistem
- Secara terpusat, boundary, ketepatan, dan reproduksibilitas dikelola dengan ketat, sementara di dalamnya tim atau agen tetap memiliki kebebasan besar dalam cara mengekspresikan solusi
- Kode hasilnya mungkin tidak selalu sesuai preferensi gaya manusia, tetapi jika benar, dapat dipelihara, dan dapat dibaca oleh eksekusi agen berikutnya, maka itu memenuhi standar
- Selera manusia terus dikembalikan ke sistem melalui komentar review, PR refactoring, dan bug yang terlihat pengguna, lalu diterjemahkan menjadi pembaruan dokumentasi atau alat
- Jika dokumentasi tidak cukup, aturan dinaikkan menjadi kode
Filsafat merge yang diubah oleh throughput
- Seiring naiknya throughput Codex, banyak norma engineering lama justru menjadi kontraproduktif
- Repositori dioperasikan dengan merge gate pemblokir seminimal mungkin
- PR dijaga tetap pendek
- Test flake sering ditangani lewat eksekusi lanjutan alih-alih memblokir progres tanpa batas
- Dalam sistem di mana throughput agen jauh melampaui perhatian manusia, biaya perbaikan menjadi rendah dan biaya menunggu menjadi tinggi
- Pendekatan ini mungkin tidak bertanggung jawab di lingkungan throughput rendah, tetapi dalam lingkungan ini sering kali menjadi trade-off yang benar
Cakupan nyata dari “dihasilkan agen”
- Ketika dikatakan bahwa codebase dihasilkan oleh agen Codex, itu berarti segala sesuatu di dalam codebase tersebut
- Hal-hal yang dibuat agen
- kode produk dan pengujian
- konfigurasi CI dan alat rilis
- alat developer internal
- dokumentasi dan riwayat desain
- evaluation harness
- komentar review dan tanggapannya
- script yang mengelola repositori itu sendiri
- file definisi dashboard produksi
- Manusia tetap selalu berada di dalam loop, tetapi bekerja pada lapisan abstraksi yang lebih tinggi dibanding sebelumnya
- Manusia menentukan prioritas tugas, menerjemahkan feedback pengguna menjadi acceptance criteria, dan memvalidasi hasil
- Saat agen kesulitan, itu diperlakukan sebagai sinyal untuk mencari apakah yang kurang adalah alat, guardrail, atau dokumentasi, dan perbaikannya juga dikembalikan ke repositori agar ditulis oleh Codex
- Agen secara langsung menggunakan alat pengembangan standar, mengambil feedback review, menanggapinya inline, mendorong pembaruan, dan sering juga melakukan squash lalu merge PR-nya sendiri
Meningkatkan tingkat otonomi
- Karena semakin banyak pengujian, validasi, review, penanganan feedback, dan pemulihan yang dienkode ke dalam sistem, Codex baru-baru ini melewati ambang di mana ia dapat mendorong fitur baru dari awal sampai akhir
- Tugas yang bisa dilakukan agen hanya dengan satu prompt
- memvalidasi kondisi codebase saat ini
- mereproduksi bug yang dilaporkan
- merekam video yang menunjukkan kegagalan
- mengimplementasikan perbaikan
- memverifikasi perbaikan dengan mengoperasikan aplikasi secara langsung
- merekam video kedua yang menunjukkan solusi
- membuka PR
- menanggapi feedback dari agen dan manusia
- mendeteksi dan memperbaiki kegagalan build
- mengeskalasi ke manusia hanya saat dibutuhkan penilaian
- menggabungkan perubahan
- Perilaku ini sangat bergantung pada struktur dan alat spesifik repositori tersebut, dan tidak boleh diasumsikan bisa digeneralisasi tanpa investasi serupa
Entropi dan garbage collection
- Otonomi agen penuh juga memperkenalkan masalah baru
- Codex menyalin pola yang sudah ada di repositori, dan akan mengulanginya meskipun pola itu tidak merata atau tidak optimal
- Seiring waktu, pengulangan seperti ini mengarah pada drift
- Pada awalnya, manusia menanganinya secara manual, dan tim menghabiskan setiap hari Jumat, yaitu 20% waktu mingguan, untuk membersihkan “AI slop”
- Pendekatan ini tidak dapat diskalakan, sehingga “prinsip emas” dienkode langsung ke dalam repositori dan dibangun proses pembersihan berulang
- Prinsip emas adalah aturan mekanis yang kuat pendapatnya untuk menjaga codebase tetap mudah dibaca dan konsisten bagi eksekusi agen di masa depan
- Contoh prinsipnya adalah lebih memilih package utilitas bersama daripada helper buatan tangan untuk memusatkan invariant
- Contoh lainnya adalah memvalidasi boundary atau bergantung pada SDK bertipe agar data tidak dieksplorasi secara “YOLO” dan agar agen tidak kebetulan membangun di atas bentuk yang hanya ditebaknya
- Secara berkala, tugas Codex di background memindai penyimpangan, memperbarui peringkat kualitas, dan membuat PR refactoring yang terarah
- Sebagian besar PR refactoring dapat direview dalam waktu kurang dari 1 menit dan dapat di-merge otomatis
- Proses ini bekerja seperti garbage collection
- Utang teknis seperti pinjaman berbunga tinggi; hampir selalu lebih baik membayarnya terus-menerus dalam unit kecil daripada membiarkannya menumpuk lalu menanganinya sekaligus dengan menyakitkan
- Selera manusia, sekali tertangkap, kemudian dapat ditegakkan terus-menerus pada setiap baris kode
- Pola buruk bisa ditangkap dan diperbaiki setiap hari sebelum sempat menyebar ke seluruh codebase selama berhari-hari atau berminggu-minggu
Masih terus belajar
- Strategi ini sejauh ini bekerja dengan baik hingga tahap rilis dan adopsi internal OpenAI
- Membangun produk nyata untuk pengguna nyata berfungsi menambatkan investasi ke realitas dan mendorong ke arah maintainability jangka panjang
- Masih belum diketahui bagaimana konsistensi arsitektur dalam sistem yang sepenuhnya dihasilkan agen akan berubah dalam rentang bertahun-tahun
- Tim juga masih terus belajar di mana penilaian manusia memberi leverage terbesar, dan bagaimana mengodekan penilaian itu agar menghasilkan efek kumulatif
- Juga belum diketahui bagaimana sistem ini akan berevolusi ketika model menjadi lebih mampu seiring waktu
- Yang sudah menjadi jelas adalah bahwa membangun perangkat lunak tetap membutuhkan disiplin, tetapi disiplin itu kini lebih tampak pada scaffolding daripada pada kode
- Pentingnya alat, abstraksi, dan feedback loop untuk menjaga konsistensi codebase terus meningkat
- Tantangan terberat saat ini adalah merancang lingkungan, feedback loop, dan sistem kontrol yang membantu agen membuat dan memelihara perangkat lunak yang kompleks dan andal dalam skala besar
- Semakin besar bagian dari siklus hidup perangkat lunak yang diambil alih agen seperti Codex, semakin penting pula pertanyaan-pertanyaan ini
- Pembelajaran awal ini membantu menentukan di mana upaya perlu diinvestasikan agar dapat membuat sesuatu begitu saja
1 komentar
Komentar Hacker News
Throughput-nya benar-benar tidak masuk akal. Jadi penasaran baseline-nya seharusnya apa. Sebelum agent coding, biasanya berapa banyak PR yang diharapkan bisa diajukan seorang engineer? Mungkin sekitar 2~10 per hari?
Saya juga penasaran apakah dalam 6 bulan terakhir software benar-benar terasa makin baik. Kalau jumlah engineer kurang lebih sama, siklus iterasi aplikasi software utama seharusnya jadi sekitar 5 kali lebih cepat, tapi rasanya tidak terlihat begitu. Aplikasi AI memang berubah sangat cepat, tapi itu bisa dimaklumi karena bidangnya masih baru, sedangkan di luar itu nyaris tidak terlalu terasa
Di sini, 1.500 PR menghasilkan 1 juta baris, jadi kenaikan bersihnya sekitar 650 baris per PR. Bukan berarti total isi PR-nya 650 baris, melainkan kenaikan bersih setelah baris yang dihapus dikurangkan dari baris yang ditambahkan adalah +650
Ada beberapa pertanyaan untuk pembaca yang teliti. Seperti apa proyek yang tiap tahun bertambah sebanyak satu codebase Firefox setelah 10 tahun? Apa yang dikatakan jumlah baris tentang verbositas alat yang dipakai, dan apa yang dikatakan tujuan proyek yang tidak dijelaskan dengan jelas secara publik tentang hasilnya? Di dunia di mana manusia tidak lagi menulis kode secara langsung, masih perlukah kita peduli pada jumlah baris? Jika codebase menjadi jauh lebih besar, bagaimana dengan penggunaan token? Jika terkonfirmasi bahwa penggunaan LLM membuat jumlah baris meledak, apa artinya bagi codebase yang setelah beberapa bulan dipakai lalu ingin kembali ke coding manual karena biaya?
Anehya, sebagian besar penggunaan “agent” justru dipakai untuk membuat produk AI lain. Rasanya seperti struktur turtles all the way down. Mungkin ini lebih banyak mengatakan sesuatu tentang domain Harness daripada tentang kekuatan “agent” itu sendiri
Lihat saja MS Office, belakangan ada banyak perubahan kecil dan kebanyakan menjengkelkan. Misalnya saat menandai rekan kerja dengan @ di komentar Word fokusnya hilang, atau di kotak pencarian Outlook harus klik dua kali dulu sebelum bisa mengetik, atau date picker Outlook mobile sepertinya kehilangan fitur yang dulu bisa menampilkan waktu tersedia saya dan peserta lain
Jadi throughput-nya memang terlihat tinggi, tapi sayangnya yang terjadi justru merusak fitur yang tadinya berjalan baik. Atau menghabiskan waktu pada hal yang tidak penting seperti progress bar pencarian OneDrive yang berputar-putar di sekitar kotak input
Maksudnya, sebagian besar kode yang ditulis tetap saya kendalikan dari kursi pengemudi, sementara AI dipakai untuk memperkuat flow state dan menghilangkan hambatan. Saya ingin alat itu hanya melakukan pembuatan kode seminimal mungkin
Selama 5 bulan terakhir saya menjalankan eksperimen yang sama di tsz[1], dan sampai pada kesimpulan yang sangat mirip. Dibutuhkan banyak harness untuk memaksa pemisahan arsitektur yang baik, dan juga banyak test serta CI
Tujuan membuat tsz adalah mempelajari cara mengerjakan proyek yang sangat besar dengan AI. Pada akhirnya workflow dan sikap yang sama juga bisa dipakai untuk membangun aplikasi produk untuk pelanggan yang memiliki UI. OpenAI tampaknya juga memanfaatkan automated browser testing dan bahkan video sebagai bagian dari workflow mereka. Seiring model yang makin bagus, arah pembuatan software seperti ini pada akhirnya mungkin akan masuk akal, tetapi menurut saya kita belum sampai ke sana. Meski begitu, tidak seperti klaim samar OpenAI, di sini hasilnya dibagikan sehingga kita bisa melihatnya sendiri
Solusi seperti Lovable yang menawarkan tingkat otomatisasi sangat tinggi terasa agak terlalu optimistis, dan tidak terikat erat dengan banyak automated test
[1] https://github.com/tsz-org/tsz
Ini persis sama dengan cara yang saya lakukan. Claude/Codex memberi sarana agar mereka bisa memverifikasi pekerjaannya sendiri. Misalnya browser, smoke test, end-to-end test, dan lingkungan lokal dengan fidelitas tinggi
Semua konteks—issue tracking, dokumentasi, ide, rencana, log pekerjaan—saya simpan di dalam repositori(https://github.com/shepherdjerred/monorepo/tree/main/package...)
Saya juga memberi Claude/Codex akses ke alat observabilitas seperti Grafana, Prometheus, Tempo, dan PagerDuty, serta memintanya mengikuti pedoman engineering yang baik seperti fail fast, type safety, dan parsing di boundary
Hanya saja, di homelab saya belum berhasil mencapai otonomi penuh karena biaya dan beban CI
Belum lama ini saya menonton video pekerja pabrik vape. Mereka mengambil seikat vape dari conveyor belt, mengisapnya kuat-kuat selama sekitar 5 detik, lalu mengetes seikat berikutnya. Meninjau ratusan baris perubahan dalam PR yang ditulis AI rasanya tidak jauh berbeda
PR tidak seperti itu. Satu PR buruk bisa fatal bagi bisnis, sedangkan satu vape buruk biasanya tidak
Selain itu, jika software engineer melakukan sampling pada output AI, menurut saya kualitasnya saat ini masih belum secara konsisten memenuhi standar yang diinginkan untuk produk. Karena itu semua PR tetap harus direview dan cukup banyak yang harus diperbaiki
Pendekatan sampling mungkin bisa berjalan jika cakupan dampak perubahan dapat dibatasi, dan output-nya umumnya sudah cukup layak diterima tanpa pengawasan sehingga di pabrik orang tinggal mengecek ulang bahwa tidak ada regresi
Saya salah satu dari tiga engineer yang menulis artikel ini. Kalau ada pertanyaan, saya bisa jawab
Saya bukan skeptis AI, tapi saya meragukan niat artikel ini. Artikel ini membuat klaim besar tentang rekayasa yang mengutamakan agen dengan bersandar pada produk nyata, pengguna nyata, dan tim nyata yang sedang bertumbuh, lalu membuatnya tampak seperti studi kasus nyata, tetapi bahkan tidak mengatakan atau menunjukkan apa yang dibuat. Sama saja seperti semua tulisan AI yang dibesar-besarkan lainnya
Ini hanya bisa bekerja kalau ada sumber daya komputasi tak terbatas dan token tak terbatas
Dari pengalaman memakai paket $20, pendekatan yang murni berbasis agen seperti ini tidak mungkin dilakukan. Batasnya cepat tercapai dan hasilnya pun lebih sedikit
Pendekatan yang sangat berhasil adalah memberi kode yang ditulis manusia sebagai referensi lalu memintanya memperluas itu. Tentukan struktur keseluruhan, rancang arsitektur, dan tulis beberapa contoh kode seperti controller, service, model, component, skema database, metode autentikasi, agar LLM punya pijakan untuk mulai memusatkan perhatian
Biasanya saya menulis stub yang menjelaskan cara implementasi secara rinci. Bentuknya seperti pseudocode pada tingkat abstraksi yang lebih tinggi. Lalu saya minta LLM mengimplementasikannya
Jika gagal, sering kali lebih baik membatalkan seluruh perubahan, menyesuaikan stub agar bisa menangkap kegagalan sebelumnya, lalu mencoba lagi
Atau commit perubahannya lalu, dalam konteks baru, biarkan ia hanya menangani bagian yang salah
Kalau mencoba pendekatan berbasis agen sejak awal, saya selalu kecewa baik dari sisi hasil maupun batas penggunaan. Kadang belum sampai satu jam sudah kena batas
Kalau upgrade ke $200 per bulan, Anda bisa memakai lebih banyak, tetapi bahkan bagi pengguna berat seperti saya, pemakaiannya tetap selalu kurang
Saya masih iri pada orang-orang yang mendapat penggunaan 200 kali lipat hanya karena mereka RSVP ke pesta OpenAI
Ini lagi-lagi tulisan penjualan yang terengah-engah. Seperti menjual beliung kepada para penambang, tapi emasnya di mana? Di mana produk luar biasa yang benar-benar diciptakan oleh chatbot yang saling bercakap di atas Git sambil menghasilkan tumpukan baris kode? Sama sekali tidak terlihat
Saya berharap tulisan blog yang heboh seperti ini lebih edukatif
Misalnya, akan bagus kalau ditunjukkan langkah demi langkah bagaimana workflow yang diklaim begitu kuat itu benar-benar disiapkan dan didemonstrasikan secara konkret
Saya bukan skeptis AI. Justru kalau memang ada kekuatan super sungguhan, saya tidak mau melewatkannya
Untuk fitur baru saya menulis spesifikasi fitur Gherkin, untuk perbaikan saya memperbaruinya, dan untuk refactor saya tidak menyentuhnya. Di PR saya memberi label dengan kata benda ini
Saya menjalankan type check, linting, unit test, dan verifikasi lain yang cepat serta bisa discri pt-kan sebagai hook pra-push
Saya membuat sub-situs VitePress di dalam repositori dan membiarkan agen memeliharanya. Saya mendokumentasikan prinsip-prinsip penting, arsitektur, dan sebagainya
Saya membuat perintah CLI yang mencantumkan semua halaman dan deskripsi frontmatter YAML agar agen bisa memilih apa yang perlu dibaca tanpa meledakkan context window
Saya memakai domain-driven design dan monorepo. Logika ditulis di lapisan headless, lalu lapisan-lapisan itu dikomposisikan menjadi aplikasi. Agen sangat bagus dalam menjelajahi lapisan
Saya memakai zod atau alat setara dalam bahasa tersebut dan pengembangan API contract-first. Secara pribadi ini bagian yang paling saya sukai, dan saya memakai orpc
Saya hanya membuat satu skill tunggal bernama “code” dan menjelaskan siklus hidupnya. Buka worktree, atur .env agar tidak bentrok dengan agen lain, pilih port yang tidak dipakai, dan Docker bagus untuk ini. Tulis atau perbarui file fitur, selaraskan spesifikasi di sini, lalu implementasikan, verifikasi dengan sesuatu seperti playwright mcp, jalankan pemeriksaan pra-push, tunggu review setelah push, rapikan, lalu fast-forward merge ke main
testcontainers bagus untuk memastikan beberapa agen bisa menjalankan test tanpa konflik
Serius, skill-nya cuma satu. Sisanya semua ada di dokumentasi. Rasanya sangat produktif, bukan dalam arti jumlah baris kode, tetapi dalam arti “membuat perangkat lunak yang bagus”
Untuk itu, setiap kali agen menemui masalah, saya bertanya bagaimana ia akan menyelesaikannya dengan memakai alat atau skrip verifikasi. Dalam proses audit, saya juga menyuruhnya menulis alat-alat itu sendiri. Hasilnya, sekarang ada lebih dari 30 aturan untuk verifikasi commit[2], dan kerjanya cukup baik
[1] https://github.com/gildas-lormeau/rebuild-and-ruin (kalau ingin melihat mode “demo”, biarkan sampai timer selesai)
[2] https://github.com/gildas-lormeau/rebuild-and-ruin/blob/a4c3...
Saya pernah mencoba ini di awal. Sebelum menulis kode, saya memakai ChatGPT sebagai “manajer proyek” untuk menyiapkan seluruh harness. Seminggu kemudian, muncul lebih dari 140 dokumen aturan, arsitektur, dan framework, sementara baris kode yang ditulis tetap 0
Ketika kemudian saya minta alat lain untuk meninjaunya, putusannya adalah “brankas kosong yang sepenuhnya aman”. Harness-nya tanpa cela, tetapi di dalamnya tidak ada apa-apa
Harness itu penting, tetapi jika tidak berjalan beriringan dengan perilisan kode, itu hanya berarti menulis fiksi