Vibe coding dan agentic engineering semakin mendekat lebih dari yang saya inginkan
(simonwillison.net)- vibe coding dan agentic engineering awalnya dibedakan berdasarkan peninjauan kode dan standar akuntabilitas, tetapi seiring meningkatnya keandalan agen coding, batas di antara keduanya mulai kabur dalam pekerjaan produksi nyata
- vibe coding adalah pendekatan menerima hasil selama keluaran yang diinginkan muncul tanpa banyak melihat kodenya, sehingga mungkin berguna untuk alat pribadi, tetapi terlihat tidak bertanggung jawab untuk perangkat lunak yang melibatkan data dan pengalaman pengguna orang lain
- Agen seperti Claude Code berulang kali menangani endpoint JSON API, kueri SQL, pengujian, dan dokumentasi dengan baik, sehingga muncul situasi di mana tidak semua baris kode hasil generasi ditinjau, dan ini menciptakan risiko berupa kepercayaan pada entitas yang tidak punya reputasi atau tanggung jawab seperti tim manusia
- Kini repositori dengan 100 commit, README yang bagus, dan rangkaian tes lengkap pun bisa dibuat dalam 30 menit, sehingga kualitas makin sulit dinilai dari tampilan luar, dan tolok ukur sebenarnya menjadi apakah ada seseorang yang terus menggunakan perangkat lunak tersebut
- Alat AI tidak menggantikan pengalaman software engineer, melainkan memperkuatnya, dan ketika kecepatan produksi kode naik dari 200 baris per hari menjadi 2.000 baris, bottleneck berpindah ke desain, verifikasi, operasional, dan penggunaan nyata
Batas antara vibe coding dan agentic engineering
- Dalam podcast Heavybit High Leverage Ep. #9 yang membahas alat coding AI, muncul pandangan bahwa vibe coding dan agentic engineering semakin mendekat satu sama lain dalam pekerjaan nyata
- Sebelumnya, di Not all AI-assisted programming is vibe coding (but vibe coding rocks), vibe coding dan pemrograman berbantuan AI yang bertanggung jawab dibedakan dengan jelas, dan yang terakhir kemudian mulai disebut agentic engineering
- vibe coding dibedakan sebagai cara di mana pengguna hampir tidak melihat kode, bahkan bisa saja tidak memahami pemrograman, lalu meminta hasil yang diinginkan dan menerimanya jika berjalan, atau meminta lagi jika tidak
- Untuk alat pribadi, ketika bug hanya merugikan diri sendiri, vibe coding bisa berguna, tetapi saat membuat perangkat lunak yang melibatkan informasi dan pengalaman pengguna orang lain, pendekatan ini terlihat tidak bertanggung jawab
- agentic engineering adalah cara seorang software engineer profesional memanfaatkan alat AI hingga batas maksimal kemampuannya sambil memahami batasan seperti keamanan, maintainability, operasional, dan performa
- Tujuannya bukan membuat hasil berkualitas lebih rendah dengan lebih cepat, melainkan membuat sistem produksi berkualitas lebih tinggi dengan lebih cepat
- Masalahnya, ketika agen coding menjadi makin dapat dipercaya, bahkan pada pekerjaan tingkat produksi pun semua baris kode yang dihasilkan tidak lagi selalu ditinjau
Kepercayaan yang membuat peninjauan kode dilewati
- Ada keyakinan bahwa jika meminta Claude Code membuat endpoint JSON API, menjalankan kueri SQL, lalu menampilkan hasilnya sebagai JSON, ia akan menanganinya dengan benar
- Bahkan saat diminta menambahkan pengujian otomatis dan dokumentasi, orang mulai berharap hasilnya akan baik-baik saja, dan dalam proses itu ada situasi di mana kode sebenarnya tidak ditinjau
- Jika kode tidak ditinjau, tetap ada rasa bersalah tentang apakah menggunakannya di produksi adalah tindakan yang bertanggung jawab
- Ini bisa dilihat mirip dengan cara menggunakan perangkat lunak dari tim lain saat bekerja sebagai engineering manager di organisasi besar
- Jika tim lain menyediakan layanan pengubahan ukuran gambar, biasanya kita tidak membaca setiap baris kode yang mereka tulis
- Kita melihat dokumentasinya, mencoba mengubah ukuran gambar, lalu merilis fitur kita
- Hanya ketika muncul bug atau masalah performa barulah repositori Git mungkin diperiksa
- Dalam sebagian besar kasus, layanan itu diperlakukan seperti kotak hitam setengah terbuka
- Agen juga semakin diperlakukan dengan cara yang sama, tetapi tidak seperti tim manusia, Claude Code tidak memiliki reputasi profesional maupun akuntabilitas
- Tim manusia bisa membangun reputasi lewat rekam jejak membuat perangkat lunak yang baik, dan mereka menghadapi tekanan bahwa hasil buruk akan memengaruhi reputasi profesional mereka
- Claude Code tidak bisa memiliki reputasi seperti itu, tetapi ia sedang membangun kepercayaan dengan berulang kali menangani tugas sederhana secara benar sesuai gaya yang menyukai pekerjaan berulang
- Di sini ada unsur normalization of deviance
- Setiap kali model menulis kode yang benar tanpa diawasi ketat, kepercayaan bertambah
- Belakangan, risiko ikut bertambah bahwa pada momen yang salah kita menjadi terlalu percaya diri lalu menanggung kerugian
Menilai perangkat lunak menjadi lebih sulit
- Dulu, jika sebuah repositori GitHub memiliki 100 commit, README yang bagus, dan tes otomatis, mudah untuk menilai bahwa proyek itu telah mendapat cukup banyak ketekunan dan perhatian
- Kini repositori Git dengan 100 commit, README yang indah, dan tes yang mencakup setiap baris kode bisa dibuat hanya dalam 30 menit
- Repositori seperti itu bisa tampak sama dari luar dengan proyek yang benar-benar dibangun lewat ketekunan dan perhatian selama waktu yang lama
- Bisa saja memang sama bagusnya, tetapi sulit mengetahuinya dari tampilan luar, dan masalah yang sama juga muncul pada proyek sendiri
- Tolok ukur yang dinilai lebih penting daripada kualitas tes dan dokumentasi adalah apakah ada seseorang yang benar-benar menggunakan perangkat lunak itu
- Bahkan jika hasilnya adalah vibe coded, bila pembuatnya telah menggunakannya setiap hari selama dua minggu terakhir, itu dipandang jauh lebih bernilai daripada hasil yang hampir tidak pernah dijalankan dan sekadar dimuntahkan begitu saja
Bottleneck berpindah dari penulisan kode ke tahap lain
- Saat kemampuan beralih dari menghasilkan 200 baris kode per hari menjadi 2.000 baris, bagian lain dari software development lifecycle mulai rusak
- Software development lifecycle yang ada dirancang dengan asumsi kecepatan produksi hanya beberapa ratus baris kode per hari
- Perubahan bottleneck memengaruhi bukan hanya tahap hilir, tetapi juga tahap hulu
- Dalam presentasi Jenny Wen, proses desain yang ada dipandang dibangun di atas asumsi bahwa “desain harus benar sejak awal”
- Karena jika sesuatu yang salah diberikan ke engineer lalu dibangun selama 3 bulan, hasilnya akan menjadi bencana
- Karena desain mengarah pada pekerjaan yang mahal, maka dibuatlah proses desain yang luas
- Tetapi jika proses build tidak memakan 3 bulan, biaya ketika terjadi kesalahan menjadi jauh lebih rendah, sehingga proses desain dapat mengambil risiko jauh lebih besar
Mengapa ini tetap tidak berarti akhir karier software engineer
- Percakapan dengan agen tampak seperti “moon language” yang sulit dipahami bagi kebanyakan orang
- Salah satu alasan mengapa kemampuan komputer menulis kode sendiri tidak dianggap sebagai akhir karier software engineer adalah karena alat seperti ini memperkuat pengalaman yang sudah ada
- Orang yang tahu apa yang sedang mereka lakukan bisa bergerak jauh lebih cepat bersama alat AI
- Semakin banyak menggunakan alat AI, semakin berulang kali terkonfirmasi bahwa membuat perangkat lunak itu sendiri sangat sulit
- Bahkan dengan semua alat AI yang tersedia, apa yang ingin dicapai tetap dipandang sulit
- Matthew Yglesias menulis dalam tweet, “setelah lima bulan saya sadar saya tidak ingin melakukan vibecode. Saya ingin perusahaan software yang dikelola secara profesional menggunakan bantuan coding AI untuk membuat produk perangkat lunak yang lebih banyak, lebih baik, dan lebih murah, lalu menjualnya kepada saya,” dan pandangan ini disetujui
- Ini diringkas lewat analogi bahwa meskipun setelah cukup banyak menonton video YouTube tentang perpipaan seseorang mungkin bisa memperbaiki pipa rumahnya sendiri, tetap saja lebih memilih menyewa tukang ledeng
Risiko SaaS dan pengembangan internal
- Terhadap ancaman bahwa perusahaan kini bisa membuat solusi sendiri tanpa memakai SaaS, standar yang sama tetap berlaku, yaitu lebih memilih perangkat lunak yang sudah terbukti lewat penggunaan nyata
- Untuk proyek pribadi, preferensinya adalah alat yang setidaknya telah digunakan langsung oleh pembuatnya sendiri selama beberapa minggu
- Dalam versi enterprise, standarnya menjadi tidak ingin mengadopsi CRM kecuali sudah berhasil digunakan setidaknya oleh dua perusahaan besar lain selama 6 bulan
- Sebelum mengambil risiko, yang diinginkan adalah solusi yang sudah terbukti benar-benar bekerja
5 komentar
Kalau kode yang ditulis agen langsung dijalankan ke produksi, sering kali mereka menuntut performa sistem yang tidak masuk akal.
Bahkan untuk kode yang sepele pun CPU/memori bisa jebol, dan saat diminta menganalisis, mereka cepat sekali menyimpulkan bahwa instance-nya harus di-upgrade.
Kalau kita terus mengkritik dan memaksa karena anggaran terbatas, ternyata cukup banyak hal yang sebenarnya bisa dihindari,
dan pada akhirnya kita bisa melihat bahwa dengan sistem yang sekarang pun semuanya tetap berjalan baik.
Akan bagus kalau sejak awal sudah seperti ini, tetapi meskipun modelnya makin bagus, sepertinya mereka belum otomatis piawai melakukan optimisasi.
Mereka menekankan HITL (human-in-the-loop), dan sepertinya yang penting adalah apakah di dalam loop itu saya benar-benar bisa memberi kritik yang bernilai.
Sepertinya saya harus selalu meninggalkan prompt bahwa saya tidak punya uang di AGENTS.md
Opini di Lobste.rs
Kesimpulan bahwa pada akhirnya tidak ada perbedaan besar memang tidak terlalu mengejutkan, tetapi tetap menarik bahwa @simonw juga sampai pada kesimpulan itu
Sejak awal saya merasa insentifnya memang selalu mengalir ke arah itu. Jika ada mesin yang menghasilkan output dalam jumlah besar, dan tujuannya adalah agar engineer terampil meninjau hasilnya, itu pada akhirnya berarti pekerjaan yang melelahkan dibebankan ke engineer senior sekaligus menjadikan mereka bottleneck
Namun, karena orang yang pertama kali mengajukan pembedaan ini adalah Simon, patut dicatat bahwa sekarang Simon sendiri tampaknya tidak lagi melihatnya seperti itu
Tambahan lagi, karena @simonw hampir pasti akan membaca ini, rasanya agak canggung menulis sesuatu yang mungkin terdengar kritis di sini. Sebenarnya saya menganggap @simonw sebagai penulis pro-AI terbaik, jadi saya membaca semua tulisannya dengan penuh minat. Kalau harus mengkritik, mungkin karena @simonw sangat penuh pertimbangan, tulisannya justru memberi pembenaran yang cukup besar bagi para pedagang yang jauh kurang penuh pertimbangan daripada dia
Saya paham maksud penulisnya, tetapi kalau dilihat sedikit berbeda, menurut saya begini: vibe coding dan agentic engineering adalah dua titik pada satu spektrum, dan dalam konteks deployment nyata pun makin banyak orang bergerak ke arah yang lebih dekat ke vibe coding daripada agentic engineering
Jika eufemisme yang baru dibuat bergantung pada neologisme dan istilah yang tidak terdefinisi dengan baik, pada akhirnya ia akan dipakai dengan cara yang ambigu. Apa itu memang tidak terduga? Justru saya pikir itulah tujuan ungkapan tersebut
Jika ingin membuat neologisme dipakai secara presisi, mungkin harus dibangun di atas istilah yang sudah dipahami dengan baik. Tentu saja, itu pun tidak menjamin keberhasilan
Dari apa yang dipromosikan sebagai "agentic engineering", saya pribadi akan menyebutnya pengembangan yang dipimpin bot. "Bot" adalah istilah yang relatif cukup dipahami, dan ada preseden seperti "test-driven development". Ini bukan usulan sungguhan, hanya contoh bagaimana saya akan membentuk istilah semacam itu
Namun, dalam media sosial atau wacana politik, ada pengecualian bahwa "bot" telah berubah menjadi cercaan umum untuk "orang di internet yang tidak sependapat dengan saya"
Dalam kasus ini, hal yang saya suka dari istilah "agentic engineering" adalah bahwa seseorang yang memasukkan prompt, mendapatkan aplikasi, tetapi sama sekali tidak memahami cara kerjanya akan sangat sulit mengklaim bahwa dirinya melakukan "agentic engineering". Terutama ketika tepat di sebelahnya sudah ada istilah "vibe coding" yang cukup mapan
Jika pernyataan "saya hanya ingin memakai side project yang sudah dipakai beberapa minggu" diubah ke versi perusahaan, jadinya kira-kira: "saya hanya ingin memakai CRM setelah setidaknya dua perusahaan raksasa berhasil memakainya selama 6 bulan"
Saya rasa arah umumnya benar, tetapi yang terjadi di lapangan sedikit berbeda. Sistem besar seperti ini biasanya sangat dikustomisasi. Salesforce, SAP, Workday umumnya sangat disesuaikan, dan biaya pemeliharaannya besar. Selain itu, platformnya sendiri juga bisa kaku dengan cara yang cukup menyulitkan. Tidak ada yang menyukai Workday, tetapi di dunia enterprise ia ada di mana-mana
Jelas ada ruang untuk pendekatan lain. Hanya saja saya tidak yakin bahwa jawabannya adalah "sesuatu yang dibuat dengan vibe coding dari awal". Mungkin bentuknya akan berupa sesuatu yang diletakkan di atas platform-platform ini, tetapi saya rasa lama-lama akan lebih mirip merakit "produk/layanan kelas enterprise" dengan vibe coding
Efek lain adalah bahwa pendekatan agentic ini mengarah pada mengosongkan isi sistem-sistem semacam itu. Selama ini mereka bertahan lama agar tidak menjadi sekadar "database", tetapi pendekatan agentic pada akhirnya mendorong mereka ke arah itu
Jadi saya tidak membayangkan akan ada hal seperti "kami melakukan vibe coding untuk Salesforce", tetapi mereka memang sedang bertarung di banyak front
Menurut saya itu cukup masuk akal untuk SaaS besar yang sejak awal memang sangat bisa dikustomisasi
Saya belum sepenuhnya yakin bagaimana harus menafsirkan tulisan ini. Dari beberapa kalimat, saya ingin memparafrasakan intinya sebagai "perbedaan antara vibe coding dan agentic engineering bukan soal apakah kode dibaca atau tidak". Maksudnya, mungkin yang lebih penting daripada apakah kodenya dibaca adalah praktik kerja seperti apa yang digunakan
Tentu saja, banyak orang benar-benar memimpikan dunia tanpa perbedaan itu. Sebagai pengguna nonprogrammer, cukup mengatakan apa yang diinginkan, lalu agen membuat sesuatu dengan tingkat ketangguhan yang memadai, dan pengguna tidak perlu secara terpisah menentukan praktik yang diperlukan untuk menjamin ketangguhan itu
Tetapi saya tidak merasa kita sudah sampai di sana, dan saya juga tidak menganggap tulisan ini sedang mengatakan bahwa kita sudah sampai di sana
Hanya saja saya tidak yakin apakah penafsiran ini adil. @simonw, bagaimana menurut Anda?
Sebagai catatan, secara pribadi saya sama sekali belum dekat ke tahap memasukkan sesuatu ke production tanpa membaca kodenya. Dalam konteks dan pengalaman saya, proses itu masih belum cukup bisa dipercaya. Tetapi saya sedang mencoba memahami sudut pandang tulisan ini
Saya masih percaya ada perbedaan yang sangat besar antara software engineer profesional yang memakai AI untuk memperkuat dan mempercepat pekerjaannya, dan nonprogrammer yang menyelesaikan masalahnya sendiri lewat vibe coding sambil tidak benar-benar memahami cara kerja sistem yang dibuatnya
Yang berubah adalah saya kini sadar bahwa saya mulai men-deploy kode yang saya percaya dan berani saya beri nama saya sendiri, meskipun saya tidak meninjau setiap barisnya. Itu tampak lebih dekat ke definisi asli vibe coding daripada yang saya inginkan
Saya masih sedang merapikan apa arti semua ini, dan bagaimana cara membicarakannya
Pendapat Hacker News
Vibe coding dan LLM bukan menciptakan organisasi atau insinyur yang tidak disiplin, melainkan hanya menyingkap dan mempercepat masalah yang sudah ada
Banyak insinyur memang longgar atau bahkan tidak punya standar dan praktik penulisan kode, dan banyak tim juga lemah dalam standar untuk menerapkan kode ke lingkungan produksi
Ini bukan fenomena baru, melainkan berarti bahwa individu dan tim yang belum pernah menjaga standar dalam siklus hidup pengembangan perangkat lunak kini jauh lebih mudah menghasilkan lebih banyak kode dan mewujudkan ide
Saya belum pernah melihat rekan kerja menjadi insinyur yang baik hanya karena bisa menulis kode lebih cepat
Insinyur terbaik yang saya kenal adalah orang-orang yang, berdasarkan pengalaman dan penilaian yang hati-hati, membagikan wawasan penting kepada tim dan mengarahkan sistem ke arah yang lebih baik
“Claude, tolong buatkan satu sistem. Tapi yang bagus ya. Terima kasih!”
Dulu, ketika codebase mulai menolak pengembangan fitur, yang dilakukan adalah memperbaiki bottleneck saat itu lalu menundanya lagi sampai titik resistensi berikutnya
Caranya adalah membuat fitur sambil melakukan refactor secukupnya, tetapi model frontier mendorong mundur momen “saat jadi masalah” itu
Karena mereka masih bisa menangani tumpukan kode yang diberikan sampai titik tertentu, LLM muncul dalam bentuk membuat lebih banyak regresi atau makin sering melewatkan requirement, tetapi rasanya pekerjaan bagi manusia tidak serta-merta jadi lebih sulit
Lalu pada satu titik, terlalu banyak yang rusak dan harus diperbaiki, tetapi seluruh codebase sudah menjadi lapisan fraktal dari keputusan-keputusan yang bukan saya buat, sehingga sulit diurai
Karena kita tidak mengedit kode secara langsung, reaksi tubuh yang biasanya terasa seperti “kalau saya menambahkannya dengan cara ini, tegangannya besar” pun hilang, sehingga lebih sulit menemukan terobosan refactor
Kode selalu bisa direfactor, dan kita bisa memaksa agen menulis potongan dan file yang kecil serta modular
Entah ditulis agen atau manusia, engineering yang baik tetaplah engineering yang baik
Untuk saat ini, manusia setidaknya masih harus memahami dan memimpin arsitektur, sementara agen bisa sangat membantu dalam penelusuran dan pemberian saran
Kecuali saya ketinggalan perkembangan dalam beberapa minggu terakhir, AI tampaknya bukan jadi lebih dapat diandalkan, melainkan kesalahannya menjadi lebih halus
Kalau kode tidak bisa dikompilasi, itu mudah ditemukan, dan kalau bisa dikompilasi tetapi tidak berjalan, itu juga masih agak mudah ditemukan
Tetapi kalau bisa dikompilasi dan berjalan, namun salah pada sebagian edge case, punya kerentanan keamanan, atau membawa technical debt dan keputusan arsitektur yang meragukan, itu jauh lebih sulit ditemukan, dan beban review sama sekali tidak berkurang
Bahkan, kode yang tampak meyakinkan justru lebih membebani secara mental saat direview daripada kode yang jelas-jelas buruk
Minta ia menulis berbagai test lebih dulu, memastikan kode sesuai dengan itu, dan menyuruh agen menata kode dengan benar
Tetapi sekarang dorongan dari atas terlalu besar untuk menerapkannya secara luas di mana-mana, dan kalau menentangnya, rasanya sangat menguras semangat dan membatasi karier
Saat kita menunjukkan masalah yang jelas, akan muncul begitu banyak solusi sementara, lalu pada solusi itu segera terlihat masalah lain, dan itu terus melahirkan solusi baru tanpa akhir
Pada titik tertentu, semua ini terasa seperti pekerjaan demi mesin itu sendiri
Di banyak perusahaan, rasanya tujuan yang sebenarnya menjadi kabur dan yang tersisa hanya LLM itu sendiri
Saya tidak tahu apakah orang-orang yang mempertaruhkan masa depan perusahaan untuk mewujudkan visi itu dijamin punya jalan keluar yang mulus untuk menghindari akibatnya, atau memang rasionalitas sedang dibuang sepenuhnya
Mungkin masalahnya bisa dikurangi dengan prinsip engineering yang sehat, tetapi dari sudut pandang beban kognitif, waktu developer, uang, dan sumber daya yang terbatas, saya meragukan efisiensi nyata yang dihasilkan
Dalam kalimat “apa yang rusak ketika Anda bisa membuat 2.000 baris per hari alih-alih 200”, memakai jumlah baris kode sebagai ukuran output engineering itu memalukan
Me-review 200 baris dan me-review 2.000 baris adalah beban kerja yang sepenuhnya berbeda
Saat saya membuat ulang program yang sama dari kepala saya sendiri dan hanya memakai ChatGPT seperti pencarian dan autocomplete, hasil yang sama keluar dalam 1.500 baris
Perbedaan upayanya jujur saja tidak terlalu besar, tetapi pendekatan menulis manual mungkin diuntungkan karena saya sudah lebih dulu memikirkan apa yang ingin saya buat berkat versi yang sebelumnya dibuat dengan vibe coding
Memakai jumlah baris kode sebagai nilai masukan untuk review perangkat lunak masuk akal
Karena secara harfiah setiap baris harus dibaca
Hanya saja sebagai satu-satunya ukuran produktivitas developer, metrik ini buruk sekali, dan masalah muncul ketika dipakai seperti itu
Meski begitu, ini tetap berguna karena hampir satu-satunya metrik yang langsung intuitif, dapat dipahami, dan bisa dibandingkan lintas perusahaan, tim, bahasa, dan konteks aplikasi
Bahkan bila tim yang sama mengerjakan produk yang sama, perubahan 1.000 baris bisa selesai cepat, sedangkan perbaikan bug 1 baris bisa butuh debugging berhari-hari
Karena itu sulit membandingkan PR, fitur, atau story point di luar konteks, dan kalau ada metrik standar industri untuk produktivitas developer yang benar-benar mungkin, semua orang pasti sudah memakainya, tetapi saya rasa ini pada dasarnya memang sulit
Untuk perbandingan seperti ini, asumsi bahwa konteksnya sama memang membantu
Misalnya jika tim yang membuat produk tertentu di perusahaan tertentu dengan tech stack dan proses kualitas tertentu kemarin menghasilkan N1 baris, lalu hari ini dengan AI menghasilkan N2 baris, maka selisih N1 dan N2 seiring waktu mendekati dampak nyatanya
Bahkan penelitian produktivitas pengembangan berbantuan AI yang ketat pun umumnya mengukur dengan gaya A/B test yang membandingkan PR sebelum dan sesudah penggunaan AI pada kelompok yang sama
Bagi saya, perbedaannya terletak pada kualitas dan ketegasan pipeline
Vibe coding adalah pendekatan mencoba sekali atau beberapa kali, memeriksa hasilnya secara singkat, lalu memakainya sampai rusak
Ini cocok untuk proof of concept yang ringan atau aplikasi pribadi, keluarga, atau tim kecil yang risikonya rendah
Engineering bergaya agen memperhatikan kepentingan yang lebih luas seperti ketepatan fungsional, performa, infrastruktur, resiliensi/ketersediaan, skalabilitas, dan maintainability
Ada pipeline multi-tahap yang mengelola alur kerja, dan tahapannya bisa mencakup penerimaan proyek, seleksi, spesifikasi, penguraian epic, penguraian story, coding, dokumentasi, dan deployment
Di setiap tahap, ada campuran gerbang kualitas yang menentukan seperti kelulusan test atau ambang performa, serta review yang adversarial terkait nilai bisnis, kelengkapan spesifikasi, keanggunan kode, dan ketegasan serta kesederhanaan ubiquitous language
Ini juga sebuah slider
Kadang saya tidak ingin melakukan wawancara, membakar token, menjalani tiga kali review adversarial, estimasi nilai, dan spesifikasi rinci hanya untuk merilis satu fitur, jadi saya cukup melempar tiket ke sistem
Saya memakai Opus, GPT-5.5, dan model yang lebih kecil setiap hari, tetapi tidak menyerahkan seluruh pekerjaan kepada mereka
Walaupun saya sudah cukup serius mendefinisikan dan merapikan spesifikasi, mereka masih sering melakukan hal bodoh yang tidak akan lolos dalam review PR manusia
Jika saya mempercayai outputnya atau membangun pipeline agen besar yang memberi rasa aman palsu, akan mudah membiarkannya mengalir begitu saja ke codebase
Mungkin 10 tahun lagi akan lebih baik, tetapi pipeline vibe coding dan engineering bergaya agen saat ini sama-sama tampak seperti variasi dari tema yang sama: menyerahkan seluruhnya kepada LLM
Bahkan pagi ini, saya sempat merasa bisa menyerahkan perubahan pada satu file tunggal kepada Opus on Max, tetapi hampir di setiap giliran ada kesalahan atau hal yang terlewat sehingga harus saya perbaiki
Kode yang diusulkan mungkin sebagian besar akan berjalan, tetapi terlalu rumit dan malah mengembalikan kemunduran pada bagian yang sebelumnya sudah saya sederhanakan secara manual
Jika hal seperti ini dikalikan ke ribuan commit agen, codebase akan cepat memburuk
Tim pengembang akan kesulitan kalau mencoba membangun tanpa proses yang benar untuk desain, test, dan review
Ini sudah benar bahkan sebelum ada agent coding, tetapi sekarang makin terasa, dan tim yang paling sukses adalah yang memahami cara memanfaatkan agen dalam proses ini
Apakah Anda tidak merasakan bahwa coding agent sering datang sangat dekat ke solusi pada percobaan pertama, tetapi butuh pekerjaan besar untuk menyelesaikan 10% atau 5% terakhir
Jika cara mendekati masalah diubah, agen bisa menutup celah itu
Sepuluh tahun lalu saya berhenti menulis kode setiap 10–15 menit untuk refactor, test, dan analisis demi memastikan semuanya sempurna
Sebab bug akan mencemari seluruh kode yang datang setelahnya
Coding agent tidak bisa melakukan itu, dan terus berjalan sambil membawa bug atau arsitektur yang salah
Secara naluriah saya ingin menghentikan agen di tengah jalan, tetapi itu tidak mungkin karena berbagai alasan
Sebagai gantinya, karena biayanya sangat murah, kita mencari titik saat agen pertama kali salah, memperbaiki prompt, lalu bukannya mengubah kode, kita hapus semuanya dan menjalankannya lagi dari awal
Ulangi ini sampai prompt menghasilkan kode yang sempurna
Orang mungkin akan membantah bahwa ini tetap butuh banyak kerja manusia, tetapi justru itulah intinya
Manusia masih tetap dibutuhkan, dan dengan memakai alat seperti ini, kecepatan penulisan kode menjadi 10 kali lebih cepat
“Sesuatu yang berjalan” bisa dibuat cukup cepat, tetapi butuh waktu lama untuk mengevaluasi pilihan lain, merapikannya, mengujinya, dan membangun keyakinan
Intinya benar, tetapi tak seorang pun tahu batasnya ada di mana
Satu tahun ke depan mungkin akan menjadi masa ketika semua orang mencari batas itu, dan karena itulah kita sering mendengar ucapan seperti “kita harus menemukan ulang GitHub”
Dalam banyak kasus, berinvestasi untuk memekanisasi bagian terakhir itu tidak masuk akal secara ekonomi
Saya rasa para penyedia LLM mengambil pendekatan yang salah sejak awal
Mereka seharusnya fokus pada melengkapi tenaga kerja, bukan menggantikannya, dan tampaknya mereka belajar pelajaran yang mahal
Mungkin akan lebih baik memulai dari nol, tetapi saat mulai saya belum tahu seperti apa arsitektur yang saya inginkan
Hanya karena LLM kesulitan menyesuaikan fitur ke arsitektur yang ada, bukan berarti kita bisa menghapus seluruh codebase yang sedang berjalan dan memulai lagi
Ini tulisan yang bagus, ditulis oleh orang yang cerdas, rendah hati, dan terus belajar
Kalimat yang saya suka adalah, “Ada banyak alasan saya tidak takut karier software engineer berakhir hanya karena komputer sekarang bisa menulis kodenya sendiri. Sebagiannya karena hal-hal ini adalah penguat bagi pengalaman yang sudah ada. Jika Anda tahu apa yang Anda lakukan, Anda bisa berlari jauh lebih cepat”
Saya juga suka bagian, “Memakai alat-alat ini terus mengingatkan kita betapa sulitnya pekerjaan kita. Membuat perangkat lunak itu sangat, sangat sulit. Bahkan jika Anda memberi kita semua alat AI di dunia, apa yang sedang kita coba capai di sini tetap benar-benar sulit”
Pengamatan bahwa pekerjaan upstream juga ikut berubah itu tepat
Alat di sisi desain berkembang sangat cepat, sehingga rasanya tidak lagi layak menanggung biaya translasi yang tetap tinggal di sisi Figma
Bagian yang menakutkan adalah ketika lapisan kompleksitas AI menumpuk di codebase, lalu manusia tidak lagi bisa memahami kodenya, sehingga model terbaru pun membutuhkan biaya besar untuk menguraikan dan mengubahnya
Tak lama lagi, reuse kode bisa menghilang, dan kita mungkin membakar uang hanya untuk terus-menerus menemukan ulang roda
Saat membuat aplikasi Android awal dulu, IDE itu wajib dipakai, dan rasanya menguras jiwa karena kita harus menulis jumlah boilerplate yang konyol hanya untuk menampilkan notifikasi “Hello World” setelah klik tombol
Ulangi bersama saya: sebagian besar perangkat lunak menghabiskan mayoritas masa hidupnya dalam fase maintenance
Karena itu, sebagian besar uang yang dihasilkan perangkat lunak juga datang pada fase maintenance
Industri ini, meski sudah hampir 100 tahun, masih belum memahaminya
Alan Kay 100% benar ketika berkata revolusi komputer belum terjadi
Di balik semua kemajuan saat ini, alat-alat kita sebagian besar masih setara zaman batu
Harapan besar saya adalah AI akan mempercepat kita sampai ke titik di mana paradigma yang ada sekarang hancur total dan tak bisa dipulihkan, sehingga akhirnya kita bisa melakukan sesuatu yang baru, berbeda, dan lebih baik
Jadi untuk saat ini, mari pasangi jetpack AI pada siklus hidup pengembangan perangkat lunak dan gas saja
Bergerak cepat, dan benar-benar hancurkan sesuatu
Ini pengamatan yang tepat waktu dan terasa cocok juga bagi saya
Saya perlu membuat alur yang relatif sederhana: unduh batch → konversi → pasang API endpoint, dan meski saya menulis prompt yang cukup detail, banyak detail implementasi seperti sumber data saya biarkan kosong
Opus 4.7 membuatnya sekitar 90% sama dengan cara yang akan saya lakukan, dan menambahkan jauh lebih banyak convenience method serta validasi per tahap
Itu sangat bagus, dan memberi saya ruang untuk memikirkan masalah yang lebih sulit
Saya terutama developer Python, tetapi terus memakai bahasa backend lain seperti Rust atau Go yang sudah familiar walau belum setara tingkat kemahirannya
Dengan sekitar 13 tahun pengalaman yang sangat condong ke satu bahasa dan pembelajaran formal pada bahasa lain, mengarahkan LLM jadi jauh lebih mudah
Beban mempelajari sintaks, building block dasar, package manager, test, dan sebagainya kecil dibanding cara pemrograman lama
Belum lama ini saya membantu rekan non-developer yang sedang mengotomatiskan reporting dengan Claude cowork/code
Rekan itu paham baik sisi business intelligence, tetapi kesulitan dengan ekspresi dasar untuk melakukan vibe coding pada wrapper pyautogui yang menjalankan RDP dan mengisi nilai ke abstraksi MS Access di atas database vendor
Sepertinya developer sebagai profesi masih akan aman untuk 5–10 tahun ke depan
Saat menggunakan Codex 5.5, saya setiap hari dibuat takjub karena rasanya era coding manual oleh manusia benar-benar sudah mendekati akhir. Belakangan ini, hari-hari ketika saya tidak menulis satu baris kode pun makin sering. Peran dan kebutuhan untuk profesi developer akan berubah secara besar-besaran dan cepat.