[🧑‍💻] Membuat Cepat dengan AI Berbeda dari Membuat Secara Profesional

✨ Ringkasan GPT-5.6 Sol 　

Aku mempercepat implementasi dengan AI dan harness, tetapi melewatkan konsistensi perencanaan, desain, dan dokumentasi, lalu meninjau kesombonganku setelah melihat rancangan di Figma dan manual milik tim eksternal.

Manusia memang harus rendah hati.

Beberapa hari lalu, ketika melihat sistem kerja yang diserahkan perusahaan kepada tim eksternal dan dibuat dalam waktu yang cukup lama, jujur aku sempat berpikir, “Kalau aku yang membuat ini, pasti selesai jauh lebih cepat…”

Kecepatan yang kudapat dari AI dan harness

Walaupun vibe coding dengan AI punya banyak celah, aku tetap melihatnya sebagai sesuatu yang bisa cukup diperbaiki. Kalau dijalankan secermat mungkin berbasis TDD, dan kalau harness untuk mencegah masalah berulang dibangun dengan baik, itu seharusnya mungkin. Melihat Big Tech yang serius dengan AI juga membuatku berpikir bahwa porsi developer yang menulis kode secara langsung mungkin akan terus berkurang.

Tentu saja, pendapatku itu sama sekali belum berubah. Jika AI dipakai dengan baik, test dan harness dipasang dengan benar, dan struktur pencegahan masalah berulang dibuat dengan teliti, kecepatan dan kualitas pengembangan bisa berubah besar.

Namun aku merasa perlu meninjau kesombongan di balik pikiran “pasti selesai jauh lebih cepat…”

Akhir-akhir ini aku sering mengembangkan dengan pola seperti ini. Aku bolak-balik dengan agent, terus memperbaiki struktur harness engineering, mencegah berbagai isu berulang, menambahkan fitur baru, menerima feedback, lalu memperbaikinya lagi. Untuk pekerjaan yang berulang, aku membuat agent worker/coordinator dan menjalankannya.

Pengembanganku melewatkan konsistensi

Rutinitas ini memberiku kecepatan pengembangan dan kemampuan berbelok arah dengan cepat, dan pencegahan isu serupa juga cukup berjalan. Tetapi ia lemah dalam mengikat seluruh produk dengan satu filosofi perencanaan dan desain. Karena itu implementasi bisa didorong cepat, tetapi konsistensi desain, fungsi, dan perencanaan sangat rendah.

Namun aku tidak melihat ini sebagai batas bawaan vibe coding. Ini lebih dekat pada kenyataan bahwa aku belum cukup memasukkan standar perencanaan, desain, dan dokumentasi ke dalam harness engineering-ku.

Profesionalisme yang kulihat di Figma dan manual

Tetapi ketika melihat tim eksternal itu memakai Figma secara aktif untuk mencatat berbagai struktur layar serta meninggalkan description dan flow, sesuatu menjadi jelas. Ada profesionalisme yang berbeda dari caraku yang sering langsung menyerbu tanpa struktur yang cukup. Konsistensi tinggi dalam rencana dan hasil kerja mereka memberi rasa percaya yang kuat.

Profesionalisme itu juga terlihat dalam manual GitBook. Aku hanya berpikir, kalau kubuat dengan baik, pengguna akan mengerti sendiri; kalau UI/UX intuitif, itu cukup. Aku bahkan tidak pernah membayangkan membuat buku panduan untuk staf internal.

Tentu saja, kalau UX bagus dan tombol bantuan ditempatkan tepat di tempat yang diharapkan pengguna, aku masih jujur bertanya-tanya apakah buku panduan memang benar-benar diperlukan.

Bagaimanapun… aku masih berpikir bahwa meminimalkan penggunaan LLM dan menulis kode secara langsung adalah budaya pengembangan yang cukup kuno dan sulit direkomendasikan. Tetapi aku jelas menyadari bahwa setidaknya aku belum berada pada level profesional yang pantas meremehkan dan habis-habisan mencela mereka.

Selalu rendah hati. Selalu belajar.