Subjudul: Depresi Vibe Coding sebagai Lulusan Ilmu Komputer
Hari ini saya bertanya kepada Claude Code: Apakah cara yang saya lakukan ini benar?
Seperti biasa, ia memberikan alasan panjang lebar dan berkata, "Anda melakukannya dengan baik." Saya menatapnya dengan curiga lagi dan menjawab, "Saya tahu Anda dilatih untuk memuji, jadi itu tidak terlalu menghibur." Namun, itu lebih baik daripada tidak ada penghiburan sama sekali, dan saya terus menggali detailnya. Tidak seperti saat masih mahasiswa, tidak ada profesor atau senior yang bisa memberi tahu saya jawaban yang benar.
Akhir-akhir ini saya tidak menulis kode. Saya menyampaikan persyaratan dan mengawasi kemajuan.
Secara khusus, kekhawatiran saya saat ini adalah proses pengembangan dan kualitas. Semakin besar skala perangkat lunak, semakin mudah melampaui jumlah konteks yang dapat dibaca oleh AI. Bahkan di dalam konteks, AI menjadi bingung, dan mengendalikan kode besar yang melampaui batas tersebut secara terus-menerus dengan 'kewarasan' AI yang kecil bukanlah hal yang mudah. Setelah istilah rekayasa konteks, baru-baru ini muncul juga istilah rekayasa harness.
Oleh karena itu, jika ada referensi bagus di media sosial, saya memberikannya kepada AI terlebih dahulu, memintanya menganalisis apakah ada poin yang dapat diterapkan pada proyek Naia OS, dan kemudian menerapkannya. Dengan demikian, saya juga banyak belajar dengan menanyakan istilah-istilah yang tidak saya ketahui.
Namun, saya selalu ragu apakah saya melakukannya dengan baik atau apakah itu benar-benar yang terbaik. Keraguan ini memiliki dasar. Suatu hari, AI mengatakan telah melakukan review, tetapi tidak ada jejak file yang dibaca. Ia melewatkan kode, salah menentukan cakupan, dan mengatakan telah melihatnya padahal tidak. Ketika saya memintanya untuk mengulang review sampai bersih pada percobaan kedua, pada percobaan ketiga, ia menambahkan jawaban bahwa ia telah me-review seperti biasa dan tidak menemukan apa-apa, lalu melewatinya begitu saja. Jika dipikir-pikir, mengingat struktur LLM, itu adalah jawaban yang masuk akal, jadi ia menambahkannya. 'Pada titik ini, biasanya sudah selesai, kan?' Ia menjawab sendiri dan percaya itu adalah kebenaran.
Hari ini saya mendengarkan presentasi dari Goose Kim, yang mengembangkan moai sdk. Saya menerima proyek tersebut dan memintanya untuk menganalisisnya lagi, dan menemukan poin-poin perbaikan untuk proyek tersebut. #87isu Yang saya temukan kali ini adalah penggunaan EARS. Ini adalah standar persyaratan kedirgantaraan dari Rolls-Royce (IEEE RE'09), yang diadopsi oleh Amazon pada tahun 2025 untuk pengembangan AI-native. Dikatakan bahwa ini adalah cara untuk mencegah masalah di mana AI menafsirkan kriteria "selesai" secara berbeda untuk setiap isu, menggunakan tata bahasa terstruktur.
Dengan mengulang tindakan ini, saya terus mencoba meningkatkan proses pengembangan berbasis AI pada proyek. Saya menganalisis dan meningkatkan jikime-adk, makalah arXiv, Dueling LLMs dari Google Cloud, dan Spec-Driven Development dari Thoughtworks. Tentu saja, ini bukan karena saya tahu semuanya, melainkan ini juga merupakan hasil analisis Claude.
Saya menganalisis open-swe dari LangChain dan menerapkan pola ensure_no_empty_msg yang mencegah AI memberikan review dengan respons kosong. Di jikime-adk, saya menerapkan pola untuk mencatat keputusan AI dan jebakan yang ditemukan dengan menambahkan bagian ## AI Context pada pesan commit, sehingga git log dapat menjadi sumber pemulihan bahkan jika sesi terputus.
Secara umum, masing-masing secara independen memecahkan masalah serupa.
Namun, saya masih bertanya-tanya apakah metode ini benar. Saya khawatir jangan-jangan ini menjadi Frankenstein, dan sebagai seorang profesional, ini terasa aneh. Bagaimanapun, tidak ada buku teks dan kurangnya bukti bahwa ini adalah yang terbaik.
Semua metodologi rekayasa perangkat lunak yang kita gunakan berasal dari akumulasi kegagalan selama puluhan tahun. Agile muncul karena Waterfall terus gagal, dan TDD juga muncul karena pengembangan tanpa pengujian terus meledak, sehingga ada dasarnya.
Namun, apa yang saya gabungkan sekarang tidak dirancang untuk satu sama lain. Standar kedirgantaraan, pengembang indie Korea, dan agen LangChain berada dalam satu sistem.
Karena kegelisahan ini, saya juga meminta untuk mencari penelitian eksternal. Makalah V-Bounce (arXiv 2408.03416) mengklaim bahwa peran manusia di era AI berubah dari implementor menjadi verifikator. Itu benar, tetapi hanya ada teori dan saya tidak dapat menemukan implementasinya. Spec-Driven Development dari Thoughtworks bergantung pada alat tertentu. Di internal Anthropic, mereka mengatakan 90% kode Claude Code ditulis oleh Claude Code, tetapi tidak mengungkapkan metodologinya.
Pada akhirnya, semua orang yang serius mengembangkan dengan AI saat ini sedang menciptakan caranya sendiri. Tidak ada standar.
Jadi, yang saya lakukan akhir-akhir ini adalah mencari cara untuk mengukur apakah Frankenstein ini benar-benar berfungsi. CI gagal, tetapi merge tetap terjadi, dan ada teks yang mengatakan telah di-review, tetapi tidak ada jejak file yang dibaca. Metodologi telah dirancang, tetapi tidak dapat dipaksakan. Sepertinya ada sistem, tetapi saya tidak tahu apakah itu berfungsi. Satu-satunya cara untuk memverifikasinya adalah dengan membuat angka jujur yang dihasilkan oleh kode, bukan LLM, atau bahkan jika menggunakan LLM, kita harus menghasilkan "angka" yang menunjukkan peningkatan secara statistik. Saya sedang memikirkan bagaimana menganalisis kegagalan berulang dalam proyek secara berkala agar AI dapat mengusulkan perbaikan, dan mengukur kemajuan melalui evaluasi kinerja rekayasa konteks dan rekayasa harness.
Saat ini, saya hanya memegang kendali erat dan terus maju. Saya belum tahu ke mana arahnya, tetapi saya berharap saya tidak buta. Saya sedang membuat kendali, padahal sebenarnya saya baru pertama kali menunggang kuda. Itu seperti harness yang menahan vibe coding.
