CEO GitHub: Di Tengah Booming AI, "coding manual" tetap menjadi inti
(techinasia.com)- CEO GitHub Thomas Dohmke menekankan pentingnya kemampuan coding manual meskipun alat AI makin meluas
- Ia berpendapat bahwa meskipun AI dapat menghasilkan kode, pengembang tetap harus memperbaiki dan meninjaunya langsung agar efisien
- Jika hanya mengandalkan otomatisasi, ada risiko inefisiensi nyata dan penurunan produktivitas, serta penyalahgunaan kode AI seperti "Vibe coding" dapat meningkatkan risiko kualitas dan keamanan
- Ia menjelaskan dengan dukungan tren industri dan berbagai contoh bahwa pendekatan hibrida antara AI dan pengembang manusia adalah yang paling efektif
- Peran developer tidak akan hilang, melainkan berevolusi ke arah yang menuntut kolaborasi dengan AI serta kemampuan pemecahan masalah strategis dan perancangan
CEO GitHub menegaskan pentingnya coding manual di era AI
CEO GitHub Thomas Dohmke menegaskan pentingnya mempertahankan kemampuan coding manual meskipun penggunaan alat AI semakin meluas di lapangan pengembangan perangkat lunak
- Dalam penampilannya di “The MAD Podcast with Matt Turck”, ia menjelaskan bahwa developer harus memiliki kemampuan untuk langsung memperbaiki kode yang dihasilkan AI agar dapat mencegah penurunan produktivitas
- Sebagai workflow yang efektif, alat AI menghasilkan kode dan mengajukan Pull Request, lalu developer segera memperbaikinya dengan memanfaatkan keterampilannya
- Disebutkan bahwa jika hanya bergantung pada agen otomatisasi, bisa timbul inefisiensi karena waktu terbuang tidak perlu untuk menjelaskan perubahan sederhana dalam bahasa alami
- Dohmke menunjukkan bahwa “mencoba menjelaskan dalam bahasa alami sesuatu yang sebenarnya sudah bisa dilakukan langsung dalam bahasa pemrograman adalah pilihan yang paling tidak efisien”
- Istilah “vibe coding” yang disebut oleh salah satu pendiri OpenAI Andrej Karpathy merujuk pada ketergantungan berlebihan pada kode buatan AI, dan Dohmke juga mengingatkan agar berhati-hati terhadap hal tersebut
Insight dan tren industri
1. Solusi optimal untuk AI coding adalah strategi hibrida
- Pandangan Dohmke sejalan dengan konsensus industri yang menyatakan bahwa gabungan otomatisasi AI dan keterampilan pemrograman manusia adalah pendekatan terbaik
- Menurut riset Deloitte, developer terutama menggunakan alat AI untuk menulis boilerplate code, namun tetap mempertahankan peninjauan akhir oleh manusia, sehingga memperoleh peningkatan produktivitas sekitar 10~20 menit
- Karena sekitar setengah dari kode yang dihasilkan AI masih mengandung kesalahan parsial, strategi “percaya, tetapi verifikasi” kini menjadi standar industri
- Google menghasilkan lebih dari 25% total kodenya dengan AI, namun tetap mendapati bahwa proses review dan perbaikan aktif oleh developer manusia masih esensial
- Pendekatan yang seimbang ini mencerminkan kematangan industri yang makin menyadari keterbatasan AI, serta arah di mana keahlian developer ditingkatkan, bukan digantikan
2. Peran developer sedang berubah, bukan menghilang
- Alih-alih membuat profesi pemrograman hilang, AI justru mendorong peran developer berubah dari coder murni menjadi pengelola proses pengembangan berbasis AI
- Para ahli memperkirakan bahwa profesi pengembangan akan terbelah antara product engineer yang memanfaatkan AI dan arsitek tingkat lanjut untuk menjamin kualitas/keamanan sistem
- Perubahan ini berarti perlunya kemampuan baru seperti cara memanfaatkan AI secara efektif, kemampuan pemecahan masalah strategis, dan kemampuan perancangan tingkat tinggi
- Bersamaan dengan kekurangan software engineer dan terbuktinya efek dukungan alat AI bagi developer junior, hal ini juga membuka peluang pertumbuhan baru bagi developer berpengalaman
- Ini menunjukkan bahwa seperti saat kemunculan alat pengembangan dan teknologi abstraksi di masa lalu, kreativitas manusia tetap dibutuhkan
3. Dilema produktivitas-kualitas dari “Vibe coding”
- Fenomena “Vibe coding” adalah tren yang memperlihatkan keuntungan produktivitas dari kode buatan AI sekaligus keterbatasan kualitas dan keamanan
- Alat AI mendukung prototyping cepat dan pengembangan iteratif, tetapi juga meningkatkan kekhawatiran terhadap penurunan kualitas kode dan risiko keamanan
- Dalam kasus nyata, kerentanan keamanan pernah muncul akibat penggunaan kode AI tanpa verifikasi
- Di lingkungan seperti startup yang dipimpin pendiri non-teknis, penyalahgunaan kode AI dapat menumpuk utang teknis dan berujung pada hambatan pertumbuhan jangka panjang
- Berdasarkan pengalaman perusahaan IT besar, keseimbangan antara otomatisasi dan kontrol kualitas yang ketat adalah kunci adopsi AI, dan pelajaran ini juga penting bagi startup
1 komentar
Opini Hacker News
Sangat penasaran kenapa orang-orang tidak lagi membicarakan kompleksitas esensial dari sistem
Dalam No Silver Bullet karya Fred Brooks, dijelaskan bahwa kesulitan nyata dalam rekayasa perangkat lunak berasal dari memahami, memperjelas, dan memodelkan ruang masalah inti. Kompleksitas insidental seperti keterbatasan alat hanyalah sekunder
Belakangan ini sering ada pembicaraan bahwa agen AI akan membuat seluruh codebase dari prompt bahasa alami sebagai pengganti engineer. Namun asumsi ini keliru karena menganggap masalah spesifikasi sudah terselesaikan. Padahal, mengubah ide yang samar menjadi sistem yang rinci dan kokoh tetap merupakan peran inti engineer
Jika seseorang memberikan spesifikasi rinci dan bekerja secara iteratif dengan AI untuk membuat perangkat lunak, pada dasarnya itu berarti menghilangkan kompleksitas insidental dengan AI. Ini mirip dengan perpindahan developer dari assembly ke bahasa tingkat tinggi. Itu bukan menggantikan engineer, melainkan hanya meningkatkan produktivitas. Biaya kerja berulang berkurang dan muncul peluang untuk memperluas dampak
Jika agen bisa membuat produk hanya dari prompt, itu karena seseorang sudah mendefinisikan sistemnya dengan jelas. Dan jika AI hanya menyalin produk yang sudah ada, itu bukan pemecahan masalah teknis melainkan persaingan distribusi atau biaya, jadi itu bukan inovasi engineering melainkan inovasi bisnis.
Jadi saya penasaran apakah ada sesuatu yang saya lewatkan
Intinya adalah mengapa pekerjaan spesifikasi sudah diremehkan jauh sebelum kemunculan AI
Para pemangku kepentingan (pelanggan, manajer) sejak dulu sering hanya menyuruh orang ngoding berdasarkan feeling kasar. Mereka memberi penjelasan samar, lalu berharap seseorang secara ajaib menghasilkan solusi yang cocok. Tidak ada yang benar-benar tahu apakah solusinya bekerja sepenuhnya. Sering kali kalau terlihat lumayan jalan, ya dianggap cukup
Dalam banyak kasus, programmerlah yang membuatnya konkret berdasarkan pengetahuan domain (misalnya, karena mereka secara intuitif tahu seperti apa halaman pengiriman formulir yang benar)
Sekarang hanya lawan bicaranya yang berubah menjadi AI, dan masih harus dilihat apakah cara kerja seperti ini benar-benar bisa terus diulang begitu saja
Pembedaan kompleksitas esensial/insidental adalah wawasan yang sangat penting untuk memikirkan sampai sejauh mana AI bisa mengambil alih pengembangan perangkat lunak
Banyak developer tidak bisa menjelaskan dengan kata-kata mengapa mereka tidak akan digantikan AI, tetapi secara naluriah mereka merasa bahwa titik inilah alasannya
Saya sendiri juga pernah mencoba membuat agen seperti Claude menyelesaikan masalah pada codebase besar yang sangat kompleks dengan logika bisnis eksternal yang saling terkait. Tetapi AI tidak punya intuisi yang tepat soal kebutuhan bisnis atau konteks, jadi tidak bisa melakukan perubahan kode yang bersifat bisnis. Paling hanya membantu perubahan kode dengan konteks sempit. Artinya, AI hanya bisa menangani kompleksitas insidental, dan punya batasan ketika harus menerjemahkan kebutuhan nyata ke dalam sistem, yang justru merupakan peran developer sesungguhnya
Sebagai tambahan, banyak masalah yang sebenarnya diselesaikan developer mungkin bukan masalah teknis, melainkan masalah distribusi/pasar. Menggantikan junior dengan AI masih terasa tidak aman. Isu terbesarnya adalah AI tidak bisa melakukan self-correction sendiri. Meski begitu, upaya membangun bisnis berbasis AI untuk menurunkan biaya bisnis yang sudah ada akan terus berlanjut. Apakah perubahan itu baik atau buruk tidak banyak berarti bagi orang yang kehilangan pekerjaan
Ada jawaban untuk “apa saya melewatkan sesuatu?”
Faktanya ada sangat banyak developer yang tidak bisa menggunakan software. Mereka akan sangat mudah digantikan oleh AI
Dalam karier saya dulu, saya bekerja dengan JavaScript, dan orang-orang yang benar-benar melakukan hal luar biasa hanyalah mereka yang memang hobi ngoding sejak lama. Di kantor, kebanyakan orang bahkan kesulitan menampilkan teks di layar. Ini bukan bercanda
Banyak orang mencoba framework raksasa, tetapi akhirnya hanya sampai di level copy-paste sampai nyaris bisa jalan. Mereka seolah menyelesaikan kompleksitas tingkat tinggi, padahal hampir semuanya adalah pekerjaan yang tidak perlu atau sekadar pamer kode
Hampir tidak ada kemampuan untuk membuat aplikasi orisinal, menulis dokumentasi, atau mengukur kegunaan secara nyata
Bagaimana mengatasinya? Seperti profesi hukum, perlu ada standar tinggi seperti ujian profesi, sehingga orang yang tidak lolos standar disaring dengan tegas, dan hanya direkrut sebagai junior atau apprentice saja agar generasi developer bisa berkembang dengan benar
Jawaban sederhana untuk “bagian yang terlewat” adalah bahwa tidak ada orang di industri ini yang membaca "No Silver Bullet"
Orang yang menulis soal technical debt dan arsitektur sistem biasanya bukan pengambil keputusan yang benar-benar menentukan arah tim/bisnis, dan buku-buku seperti itu juga opsional bagi engineer
Orang-orang yang memimpin narasi soal penggantian coding oleh AI sering kali tidak bisa membedakan antara membuat MVP dan mengembangkan codebase selama 10 tahun sambil memperbaiki legacy
Misalnya, pernah ada seorang manajer yang mengusulkan pembagian waktu 33% untuk tiga proyek per hari, usulan yang sangat khas tapi salah. Alokasi orang dan penataan waktu seharusnya menjadi kemampuan manajer, tetapi yang akhirnya membereskannya justru engineer
Sekarang para manajer seperti itu mengusulkan “suruh AI saja membereskan semua technical debt/testing”, dan ketika tidak berhasil, engineer pula yang harus menjelaskannya
Pembicaraan tentang kompleksitas pada kenyataannya hanya pengulangan dari masalah manajemen yang buruk. Sebagian besar engineer berpengalaman sudah tidak percaya bahwa pekerjaannya akan tergantikan oleh prompt sederhana
Topik yang benar-benar perlu kita bicarakan adalah bahwa “software engineering punya masalah manajemen yang serius, dan AI justru menyorotinya lebih terang”
Banyak non-developer atau mahasiswa merasa bahwa pengembangan perangkat lunak menuntut penguasaan tool yang rumit, sehingga mereka tertarik pada janji bahwa “siapa pun bisa membuat software asal spesifikasinya bagus” (sambil mengabaikan bahwa kemampuan membuat spesifikasi itu sendiri sangat sulit dan butuh teknologi pendukung)
Dulu no-code juga dijual dengan cara seperti ini, dan pada praktiknya tool no-code itu terbatas; makin kuat fiturnya, makin kompleks dan makin menuntut pembelajaran yang spesialis
Gagasan bahwa LLM akan menggantikan SWE pada akhirnya hanyalah versi lain dari “daripada mempelajari sistem, cukup pakai prompt bahasa alami dan model akan memakai tool sendiri”
Jika dilihat begini, vibe coding yang ramai dibicarakan sekarang pada dasarnya adalah bentuk paling ekstrem dari tujuan tersebut (meski ada kelemahan nyata seperti maintainability)
Menurut saya, salah satu alasan manajer ingin menyingkirkan SWE adalah karena mereka tidak bisa berkomunikasi dengan baik dengan SWE
Dengan memakai LLM, mereka merasa bisa berkomunikasi dengan mesin tanpa “nerd (developer)”, dan menganggap itulah solusi masalahnya
Bahasa pemrograman adalah medium yang cocok untuk spesifikasi presisi dari program yang diinginkan. Bahasa alami tidak akan pernah memiliki tingkat kejelasan setinggi itu
Jadi wajar saja hasil yang dihasilkan AI harus direview dan diedit. Dalam beberapa kasus, memperbaiki langsung justru lebih mudah daripada menjelaskan perubahan yang diinginkan
Saya penasaran apakah hasil penelitian independen yang menunjukkan Copilot meningkatkan tingkat error turut secara alami menyebarkan sikap yang lebih hati-hati
Orang-orang yang menjual AI sering kali mengklaim bahwa penulis manusia akan segera tidak lagi dibutuhkan
Transformer bisa diterapkan pada banyak hal seperti automated testing, ekspansi spesifikasi, percepatan proyek baru, eksplorasi API yang belum dikenal, pembangunan fitur awal, code review, dan lain-lain
Sekalipun kode dianggap medium spesifikasi yang benar, Transformer berfungsi sebagai antarmuka otomatis antara bahasa alami dan medium itu (kode)
Belakangan ini Transformer tidak punya masalah dalam menghasilkan kode berkat pengetahuannya yang sangat luas
Sebagaimana manusia mengejar otomatisasi dalam pemrograman, Transformer adalah lompatan besar
Di satu titik di masa depan, penggantian programmer oleh AI bisa menjadi kenyataan (seperti mesin tenun otomatis, percetakan, dan kalkulator elektronik yang menggantikan pekerjaan manusia di masa lalu)
Hanya saja, itu mungkin tidak terjadi sekarang juga, atau bahkan dalam 10 tahun ke depan, dan masih ada tantangan seperti halusinasi, akurasi, toolchain, pembangunan infrastruktur, dan sebagainya
Ada tidaknya pekerjaan pemrograman bisa berbeda tergantung domain, kemampuan, dan ekspektasi kompensasi
Penting untuk menerima alat AI dengan serius dan beradaptasi. Jika tidak, ada risiko tertinggal seperti saat adopsi personal computing atau internet
Saya melihat pseudo-kreativitas AI punya batas
Jika semua hasil pelatihan LLM hanya terus diputar kembali menjadi input LLM, cakupan ide baru tidak akan pernah benar-benar meluas
Manusia terus menunjukkan kreativitas yang melampaui batas tersebut
Mungkin di masa depan LLM bisa menembus dinding itu, tetapi untuk saat ini rasanya tidak jauh berbeda dari ‘monyet dengan mesin tik’
Dalam pengalaman saya, LLM paling efektif bila digunakan sebagai scaffolding (alat pijakan awal)
Saya cukup menuangkan fitur yang ingin dibuat seperti dump isi kepala, lalu meminta model membuatkan model dan controller dasar yang dibutuhkan
Sisanya saya tinggal fokus pada view dan logika bisnis yang sebenarnya, sehingga pembagian kerja jadi jelas
Saat bahasa tingkat tinggi pertama kali muncul, setahu saya pada masa sangat awal dulu juga ada kritik yang mirip dengan kritik sekarang terhadap LLM atau kode berbasis bahasa alami, seperti “kurang presisi karena sulit mengendalikan memori secara langsung”
Masalahnya bukan karena bahasa alami mustahil presisi, melainkan karena kebanyakan orang menjelaskan kebutuhannya secara tidak presisi, atau hanya jelas tentang apa yang mereka inginkan tanpa mampu menjelaskan dengan benar apa yang harus dilakukan komputer
Akibatnya, engineer harus banyak menebak saat menerjemahkan kebutuhan bisnis, atau LLM mengambil peran itu sambil memahami konteks yang lebih sedikit lagi
Cara terbaik memanfaatkan AI adalah untuk menjaga flow state, supaya saya tidak tersendat karena API yang belum pernah saya lihat atau fitur yang malas saya kerjakan
AI bisa menerapkan pola umum ke seluruh kode dengan cepat dan efisien, tetapi pada dasarnya 'tidak tahu apa yang sedang dilakukannya'
Berbagi pengalaman terbaru, saya sempat meminta LLM me-refactor kode yang terkait dengan perhitungan ukuran popup dan penentuan posisi
Satu ditulis dengan "if", satu lagi dengan "switch", tetapi LLM sama sekali tidak fleksibel terhadap fakta bahwa keduanya memang berbeda, dan bahkan setelah dijelaskan dengan jelas, ia tetap menyamakan keduanya menjadi if semua atau switch semua
LLM cenderung mempertahankan pola dari token sebelumnya
Di sini mungkin bukan masalah besar, tetapi dalam situasi yang sedikit lebih kompleks, ia mengabaikan detail dan menghasilkan kode yang tampak meyakinkan di permukaan
Sebaliknya, jika dipecah menjadi unit kecil dan diberi instruksi jelas, LLM cukup efisien. Misalnya, instruksi seperti “simpan ukuran di m_StateStorage lalu terapkan pada tahap render” dapat dilakukan dengan mudah
Terutama bila dipakai bersama model seperti Cerebras yang bisa memproses kode beberapa kilobyte dengan cepat, itu jauh lebih cepat daripada saya harus mengetik sendiri pikiran saya menjadi kode nyata
Pada akhirnya, yang sedang dievaluasi hari ini hanyalah kritik terhadap performa model transformer saat ini
Industri ini berubah begitu cepat sehingga keterbatasan hari ini bisa jadi sudah tidak relevan sebulan lagi
Bahkan “LLM” sendiri, jika mau ketat, adalah istilah yang kabur. Model transformer terbaru bersifat multimodal, menangani berbagai bentuk data, bukan hanya teks
Jadi kalau mau mengkritik, perlu menyebut model/tool/paradigma yang spesifik agar diskusinya punya daya guna
Tentang penelitian yang mengatakan “kekurangan software engineer” dan “AI sangat membantu developer junior”
Di realitas tempat saya hidup, pasar kerja tech sedang berada pada titik terburuk, dan AI justru merugikan junior karena mengambil pengalaman yang seharusnya menjadi tempat mereka bertumbuh
Baru-baru ini saya punya pengalaman lucu dengan Claude. Di Zed saya memberi perintah “tolong perbaiki error di baris 71”, tetapi yang diubah justru formatting tak perlu di baris 91
Rasanya seperti main telepon rusak dengan LLM
Untuk perbaikan sesederhana ini saja lebih cepat saya kerjakan sendiri. Dari pengalaman lain seperti ini, saya kembali merasa bahwa “LLM benar-benar tidak berpikir”
LLM sangat buruk dalam mengenali nomor baris
Pengalaman seperti ini memberi pelajaran bahwa “LLM tidak bisa menghitung nomor baris”
Lain kali, akan lebih baik kalau memberi instruksi seperti “perbaiki error di fungsi XYZ” atau menempelkan langsung baris terkait
Dan, tentu saja, LLM memang tidak berpikir. Ia hanyalah persamaan raksasa
Di thread ini sepertinya banyak orang yang baru pertama kali mencoba coding dengan AI
Mungkin saja itu kesalahan operator
Kita harus memberi konteks yang tepat kepada LLM. Nomor baris adalah konteks yang tidak cocok
Bagi saya, peran software engineer adalah mengubah requirements menjadi software
Software bukan sekadar kode semata, dan requirements juga tidak diberikan hanya dalam bentuk bahasa alami yang sederhana
Pada titik saat ini, bahkan saat bekerja bersama AI pun saya tidak lebih cepat daripada AI itu sendiri (kecuali untuk tugas sederhana dan software kecil)
Saat ini, menurut standar saya, AI setara developer junior/mid-level
Selama dua tahun terakhir, AI tidak terasa meningkat secara dramatis dalam pengalaman saya
Sebagian besar requirements tidak pernah datang dalam bentuk dokumentasi yang jelas
Hampir tidak ada yang benar-benar tahu apa logika bisnisnya
Akibatnya, software engineer sering harus datang langsung dan bertanya sendiri
Dibutuhkan pula pengalaman dan intuisi untuk memikirkan arah pertumbuhan software dan bagaimana merancangnya agar skalabilitas itu terjaga
Saya sulit membayangkan LLM bisa mengambil alih peran seperti ini meski hanya sebagian
Saya belum pernah melihat satu pun proyek software dengan requirements yang benar-benar jelas
Setengah dari proyek adalah ‘mencari tahu sebenarnya apa yang diinginkan’
LLM bahkan masih belum mencapai level junior
Kalau AI yang ada sekarang setara developer mid-level di perusahaan Anda, itu berarti masalahnya ada pada rekrutmen perusahaan Anda
Salah satu keunggulan terbesar komputer adalah otomatisasi yang andal dan dapat direproduksi
Bahasa formal seperti bahasa pemrograman bisa menyampaikan kebutuhan otomatisasi yang diinginkan dengan jelas tanpa ambiguitas
Bahasa alami tidak sepresisi itu
Landasan kebenaran (ground truth) dari sebuah program pada akhirnya adalah kode
Jika manusia ingin mengendalikan perilaku program secara akurat, maka kemampuan untuk memahami dan mengubah kode adalah yang paling penting
Kata “manual (manual)” punya nuansa negatif
Yang dimaksud artikel tersebut adalah “human coding tetap inti”
Saya tidak yakin apakah CEO GitHub benar-benar memakai kata "manual". Akan bagus kalau ada sumber artikel dengan pilihan kata yang lebih netral atau lebih akurat
Merendahkan human coding sebagai “manual” tidak ideal. Developer manusia juga memakai berbagai toolkit otomatisasi, bukan hanya AI
Bisa jadi sama negatifnya seperti “pemikiran manual”
Saya baru tahu kalau “manual” punya konotasi negatif
Saya jadi penasaran apakah sekarang orang memang sebegitu alerginya pada pekerjaan manual
Saya penasaran apa bedanya “manual coding” dan “human coding”
“Kalau hanya bergantung pada agen AI, itu bisa tidak efisien”
Misalnya, sering kali jauh lebih cepat mengedit kode langsung daripada menjelaskan perubahan sederhana dengan panjang lebar dalam bahasa alami
Karena itu, interaksi aktif dengan agen AI kemungkinan akan menjadi workflow yang optimal
Saat saya memikirkan perubahan dalam bahasa alami, sering kali sebelum selesai mengetik saya sudah membayangkan perubahan langsung yang saya butuhkan di kepala
Makin banyak konteks yang terlibat dalam suatu perubahan, makin terasa bahwa saya sendiri bisa memperbaikinya lebih cepat daripada agent
Saya penasaran seberapa banyak interaksi aktif yang masih terasa masuk akal
Saya baru bergabung dengan startup tooling agent belakangan ini, dan kami banyak mendiskusikan hal ini secara internal
Menurut saya, terus-menerus memberi feedback seperti “jujur, kamu kurang bagus di bagian ini!” kepada agent masih oke, tetapi ada titik di mana itu juga bisa melelahkan
Saya penasaran bagaimana pendapat Anda, dan apakah ada bayangan atau feedback tambahan soal workflow
AI masih belum sampai ke level yang diharapkan
Misalnya, saya sering kesulitan karena referensi atau spesifikasi yang salah. Sepertinya ini karena AI dilatih dengan data usang dan tidak punya kemampuan update real-time yang memadai
LLM dan solusi GI yang ada sekarang mencoba menyelesaikan semua langkah (n-step) sekaligus, dan justru jadi kurang berguna
Kalau saja ia bisa menangani tahap 1 sampai tahap i dengan benar, itu akan jauh lebih membantu dari sudut pandang manusia
Saya masih belum melihat solusi AI sepenuhnya modular yang saya inginkan (misalnya: menyelesaikan masalah x hanya dengan merujuk ke resource a, b, c sambil mengikuti gaya github saya)
Dan saya berharap akan muncul AI coding yang menjelajahi masalah secara berurutan, sambil sesekali mengajukan pertanyaan tambahan dan berdialog
Menarik melihat seorang CEO menyampaikan pandangan yang agak berbeda soal AI dan coding
Biasanya CEO atau investor meramalkan penyusutan peran developer dengan mengatakan “lebih dari 30% seluruh kode ditulis oleh AI”, tetapi diagnosis di sini adalah bahwa pada praktiknya developer yang sama hanya menggunakan alat untuk menulis kode lebih cepat
Ia juga menekankan bahwa menulis kode sendiri hanyalah sebagian dari pekerjaan pengembangan perangkat lunak