Mengapa LLM Sebenarnya Tidak Bisa Membangun Perangkat Lunak

• Insinyur perangkat lunak yang efektif membangun dan mempertahankan model mental yang jelas tentang requirement dan kode, lalu menjalankan loop untuk terus membandingkan dan memperbaruinya
• LLM dapat menulis dan memodifikasi kode, menulis test, serta melakukan debugging, tetapi kekurangan kemampuan untuk mempertahankan model mental yang akurat, sehingga mudah bingung dalam tugas yang kompleks
• Saat ini LLM memiliki keterbatasan dalam mendeteksi konteks yang hilang, bias resensi, dan halusinasi, sehingga sulit memahami perbedaan antara kode dan requirement secara tepat lalu memperbaikinya dengan sesuai
• Manusia dapat beralih cara berpikir secara fleksibel sesuai situasi, misalnya menyimpan konteks keseluruhan secara sementara, atau menyembunyikan detail sejenak untuk melihat gambaran besar, tetapi LLM belum mampu melakukan ini
• LLM berguna untuk tugas dengan requirement sederhana, tetapi dalam pengembangan perangkat lunak yang kompleks, insinyur perangkat lunak tetap harus bertanggung jawab langsung atas kejelasan requirement dan perilaku kode, sementara LLM berperan sebagai alat bantu

---

Loop rekayasa perangkat lunak

• Insinyur berpengalaman bekerja dengan mengulangi langkah-langkah berikut
  1. Membangun model mental dari requirement
  2. Menulis kode sesuai model tersebut
  3. Memahami apa yang benar-benar dilakukan oleh kode yang ditulis
  4. Mengidentifikasi perbedaan lalu memperbaiki kode atau requirement
• Inti dari loop ini adalah kemampuan untuk memiliki model mental yang akurat dan dapat dipertahankan

Keterbatasan LLM

• LLM mampu melakukan berbagai fungsi seperti menulis kode, mengidentifikasi masalah lalu memperbaikinya, menulis dan menjalankan test, menambahkan logging, serta menggunakan debugger
• Namun, karena tidak mampu mempertahankan model mental, masalah berikut pun muncul
  • Mengasumsikan kode yang ditulisnya sendiri bekerja dengan baik
  • Saat test gagal, bergantung pada tebakan untuk menentukan apakah kode atau test yang harus diperbaiki
  • Saat bingung, menghapus seluruh kode dan menulis ulang dari awal
• Tidak seperti manusia, saat test gagal LLM kurang fleksibel dalam memeriksa modelnya untuk menentukan arah perbaikan, atau mengurai masalah melalui percakapan saat mengalami kebuntuan
• Insinyur perangkat lunak menjalankan test di tengah proses kerja, dan saat muncul masalah mereka dapat menilai dengan jelas bagian mana yang harus diperbaiki
• Terkadang, bahkan ketika memulai ulang seluruh pekerjaan, hasilnya justru berupa pemahaman yang lebih dalam tentang masalah

Kemungkinan ke depan

• Model mungkin akan berubah seiring perkembangan di masa depan, tetapi rekayasa perangkat lunak menuntut lebih dari sekadar pembuatan kode
• Saat menyelesaikan masalah penting, manusia dapat mengeluarkan seluruh konteks dari ingatan secara sementara untuk diproses, lalu fokus pada isu tertentu atau melihat gambaran besar
• Yang penting bukan terus menambah informasi konteks, melainkan cara berpikir yang menangani informasi yang diperlukan secara selektif
• LLM tidak memiliki kemampuan untuk menyimpan dan memulihkan konteks secara sementara seperti manusia, atau berpindah antara gambaran besar dan detail saat berpikir
• Batasan utama LLM saat ini
  • Context omission: kurang mampu menemukan bagian yang kehilangan informasi penting
  • Recency bias: terlalu berat menekankan informasi terbaru di dalam context window
  • Hallucination: menciptakan detail yang sebenarnya tidak ada
• Jika fitur memori ditambahkan, sebagian hal mungkin membaik, tetapi ketika kompleksitas terlampaui, LLM tetap gagal dalam memahami konteks dan mempertahankan model
• LLM juga kurang memiliki kemampuan untuk mempertahankan dua model mental yang mirip sekaligus, menganalisis perbedaannya, lalu memutuskan bagian mana dari requirement atau kode yang harus diperbaiki

Peran dan pemanfaatan saat ini

• LLM unggul dalam pembuatan kode cepat serta integrasi requirement dan dokumentasi, sehingga cukup berguna untuk tugas yang sederhana dan jelas
• Namun, pada masalah yang tidak sederhana, menjaga konteks yang memadai dan melakukan perbaikan berulang tetap sulit
• Karena itu, klarifikasi requirement dan verifikasi kode tetap menjadi tanggung jawab insinyur perangkat lunak
• Kita memang mengarah pada lingkungan di mana manusia dan agen (LLM) membangun perangkat lunak bersama, tetapi untuk saat ini insinyur harus memimpin, dan LLM digunakan sebagai alat

[kandk]

Mengapa LLM 'saat ini' sebenarnya tidak bisa membuat perangkat lunak..

[GN⁺]

Opini Hacker News

• Kita tidak menyelesaikan masalah hanya dengan menambahkan lebih banyak kata ke context window; kalau begitu kita pasti sudah gila.
  Saat masalah muncul, kita juga tidak melihatnya semata-mata sebagai teks.
  Kalau muncul error autentikasi di debugger, kita tidak berpikir, "apa token validation-nya kita hapus saja dari kode?" sebagai solusi.
  Kita mundur selangkah untuk melihat keseluruhan situasi agar bisa memahami akar masalah yang sebenarnya.
  Misalnya, kalau muncul error autentikasi, kita akan meninjau ulang proses validasi token dan izin pengguna yang memanggilnya, lalu bisa jadi sadar bahwa justru test-nya sendiri yang salah.
  Dalam proses ini, alih-alih sekadar menghilangkan error, kita juga bisa menemukan bahwa perlu ada pembedaan yang lebih rinci, misalnya apakah 401 itu murni karena belum terautentikasi, atau karena kurang izin.
  Lihat Grugbrain.dev

  • Saya melihat programmer sebagai pihak yang menerjemahkan aturan bisnis ke dalam bentuk ketat yang bisa dipahami komputer.
    Proses terjemahan ini tidak selalu sederhana karena kita harus sekaligus paham apa arti aturan itu dan bagaimana komputer (atau framework serta lapisan abstraksi yang digunakan) bekerja.
    Terutama ketika requirement baru merusak semua asumsi sebelumnya atau malah saling bertentangan, kita tak punya pilihan selain merevisi berkali-kali.
    Bahkan penerjemahan bahasa antarmanusia saja rumit karena ambigu, sementara komputer mengeksekusi persis seperti diperintahkan, jadi kesalahan kecil pun bisa jadi masalah besar.

  • Saya pikir pendekatan yang realistis adalah manusia tetap terlibat secara iteratif.
    Saya terus memakai cara ini karena memungkinkan pekerjaan lebih cepat dan kualitasnya lebih tinggi.

  • Secara pribadi saya bisa menampung konteks dalam jumlah besar di kepala saya.
    Teks kode itu sendiri langsung dibuang, dan otak saya mem-parse kode menjadi struktur seperti AST (abstract syntax tree), bahkan lebih jauh lagi menjadi graf spasial.
    Saya memodelkan program itu sendiri secara logis, dan memahaminya sebagai struktur yang sepenuhnya terpisah dari teks.
    Dari sudut pandang ini, LLM tidak memahami struktur software karena hanya berfokus pada teks dan gagal membangun model logis dari program.
    Merancang arsitektur sistem berskala besar yang membutuhkan kemampuan berpikir abstrak benar-benar memerlukan banyak upaya otak, tetapi LLM kurang punya kemampuan abstraksi semacam ini.

  • Metode saya seperti ini.
    Ketika ada laporan test gagal, saya lebih dulu mengidentifikasi komponennya, lalu menganalisis secara mendalam tujuan komponen itu, alur kontrol internalnya, perubahan state-nya, hingga asumsi terhadap konteks sekitarnya, lalu merangkumnya dalam Markdown (<nama-komponen>-mental-model.md).
    Setelah itu, setiap kali menangani masalah test, saya selalu merujuk ke mental model ini.
    Jika analisis ini ditempel ke prompt Claude, LLM bisa menghasilkan hasil yang lebih baik.
    Bahkan kita bisa langsung membaca dan mengoreksi mental model yang dibangun LLM.

  • AI juga bisa menyarankan agar saat izin tidak cukup, gunakan 403 alih-alih 401.

• Penulis artikel tampaknya belum benar-benar memahami kemampuan LLM dan tool coding saat ini.
  Klaim bahwa ketika test gagal LLM hanya menebak-nebak apakah kodenya benar atau test-nya yang salah, lalu saat frustrasi malah menghapus seluruh kode, tidak sesuai dengan pengalaman saya.
  Software engineer selalu mencari penyebab spesifik kegagalan test berdasarkan model mental yang mereka punya.
  Saya memakai Cline dan Anthropic Sonnet 3.7 untuk mengembangkan aplikasi Rails dengan pendekatan TDD, dan saya selalu menyuruh LLM menulis test dulu baru kemudian menulis kodenya.
  Saya memecah pekerjaan menjadi unit-unit kecil agar bisa saya review per bagian, dan saat test gagal, model cukup baik dalam menalar bagian mana yang perlu diperbaiki lalu membetulkannya dengan benar.
  LLM memang tidak sempurna, tetapi hasilnya sering setara dengan engineer junior manusia, atau bahkan lebih baik.
  Kadang memang gagal memperbaiki bug, tetapi developer pemula manusia juga sebenarnya begitu.

  • LLM bekerja sangat baik terutama untuk pekerjaan CRUD di dalam framework yang sudah matang seperti Rails.
    Sebaliknya, saat saya mencoba membuat aplikasi native Windows dengan Direct2D dan Rust, hasilnya sangat buruk.
    Saya berharap ada evaluasi yang lebih terbuka terhadap berbagai kasus.

  • Sudah sangat dikenal bahwa model sering memakai jalan pintas dan trik (seperti hardcoding) demi meloloskan test yang gagal.

  • Dalam pengalaman saya, hasilnya sangat bervariasi tergantung bahasa, platform, dan domain yang dipakai.
    Belakangan ini saya sendiri sudah lama tidak menyentuh Ruby, jadi saya belum bereksperimen dengan Rails, tetapi area Rails punya kultur pemrograman yang sangat konsisten, jadi rasanya wajar kalau LLM bisa bekerja cukup baik di sana.
    Sebaliknya, di Python banyak gaya coding berbeda bercampur, sehingga LLM sering mencampur berbagai pola dan membuat test jadi tidak stabil.
    Saya harus berulang kali mengubah kode, dan pernah juga error sebenarnya hanyalah "hasil query tidak diurutkan", tetapi LLM malah menyarankan hal aneh seperti membuang SqlAlchemy dan pindah ke Django.
    Untuk bahasa R, bahkan mendapatkan kode yang berjalan benar sesuai spesifikasi saja sudah cukup sulit.

  • Jika LLM dibatasi sebagai engineer level junior, ia memang sangat cepat menemukan dan menerapkan solusi, terutama untuk masalah yang pernah dilihat sebelumnya.
    Sebaliknya, untuk masalah yang belum pernah dilihat, LLM membutuhkan lebih banyak penjelasan atau instruksi; dalam kasus seperti ini peran saya praktis menjadi mentor.
    Tim kami aktif memakai pendekatan claude-code untuk pekerjaan repetitif yang sudah dikenal, seperti refactor sederhana yang lama tertunda di backlog atau sistem analisis sekunder.
    Secara pribadi saya suka menyorot blok kode lalu bertanya hal seperti "jelaskan ini seperti untuk anak 5 tahun" atau "cari apakah ada risiko race condition".
    Kode yang dihasilkan juga sering harus saya perbaiki sendiri agar sesuai dengan style code yang sudah ada.
    Belakangan bahkan ada yang bilang "tulis kode agar mudah dibaca AI", tetapi saya masih merasa manfaatnya belum besar dibanding beban tambahannya.

  • Soal klaim bahwa "LLM kadang setara atau lebih baik dari junior", saya justru berpikir mungkin ini lebih mencerminkan standar hiring developer belakangan ini.
    Kalau saya merekrut junior yang performanya lebih buruk dari Sonnet 3.7, saya akan sangat kecewa.

• Mungkin kebanyakan kritik terhadap LLM memang benar, tetapi dari pengalaman investasi bertahun-tahun saya belajar bahwa kita perlu memperhatikan teknologi atau perusahaan yang "kurang bagus tapi terus tumbuh".
  Pada awal hingga pertengahan 90-an banyak keluhan tentang internet, tetapi orang terus memakainya, dan Twitter juga sering down namun tetap menjadi platform berita.
  Mobil listrik, smartphone, dan sebagainya juga punya banyak ketidaknyamanan, tetapi tetap terus membaik karena ada nilainya.
  LLM memang belum sempurna untuk banyak tugas, tetapi dibanding 2022 sekarang sudah 10 kali lebih maju, dan saya kira dalam 5 tahun ke depan sebagian besar masalah yang dibahas sekarang akan terselesaikan.

  • Tetapi dalam semua contoh tadi, ekspektasinya juga sering tidak sesuai dengan kenyataan.
    Internet memang jadi lebih cepat, tetapi metaverse tidak pernah benar-benar menjadi arus utama, dan batasan fisik seperti motion sickness pada VR juga belum terpecahkan.
    Dulu orang juga tidak terlalu banyak mengeluh telepon itu lambat; use case yang diharapkan memang berbeda.
    Hanya karena teknologi berkembang lewat jalur tertentu bukan berarti LLM pasti akan berevolusi dengan pola yang sama.
    Kita juga perlu mengingat bahwa bisa saja teknologi baru lain menghadirkan solusi yang lebih baik.
    Memang benar tahun lalu area penerapannya meluas, tetapi belum ada terobosan yang pantas disebut revolusioner.

  • Walaupun ponsel lama lambat dan kualitas kameranya rendah, fungsi utamanya saat itu—bisa dihubungi kapan saja dan di mana saja—sudah cukup membuatnya menjadi sesuatu yang esensial.
    Perkembangan besar berikutnya hanyalah "bonus"; orang tidak hidup sambil menunggu, "kapan ya ponsel ini jadi bagus?"

  • Saya juga merasa ada distorsi ingatan di sini.
    Berbeda dengan narasi tentang keluhan publik terhadap internet di tahun 90-an, pada saat itu penggunanya masih minoritas, dan baru lama sesudahnya internet jadi arus utama.
    Nyaris tidak ada bukti bahwa massa umum benar-benar mengeluhkan internet yang lambat.

  • Kita hanya mengingat segelintir produk yang berkembang sukses, sementara sebagian besar lainnya cepat dilupakan atau hilang tanpa pernah membaik.
    Daripada berharap teknologi pasti akan berkembang, saya lebih memilih menilai berdasarkan kondisi saat ini.

  • Saya sulit setuju dengan logika sederhana bahwa lompatan besar LLM dalam beberapa tahun terakhir pasti akan terus berlanjut ke depan.
    Bisa saja ia mendekati batas pertumbuhan, dan terutama kurangnya kemampuan menemukan pengetahuan baru atau menalar hal yang belum diketahui terasa sebagai batas krusial LLM.
    Saya tidak bilang ini tool yang tidak berguna, tetapi saya juga tidak ikut dalam ekspektasi yang berlebihan.

• Mengharapkan LLM langsung membuat prototype hanya dari beberapa kalimat memang tidak realistis.
  Kalau tim developer manusia disuruh bekerja seperti itu, hasilnya juga tidak akan benar; jadi saya heran kenapa ekspektasi seperti ini justru diarahkan ke LLM.
  Untuk benar-benar meningkatkan kualitas output pengembangan software berbasis LLM, kita harus aktif memanfaatkan proses dan tool yang sudah dipakai tim pengembang saat ini.
  artikel autonomous-software

  • Saya memulai proyek bernama steadytext yang ditulis sepenuhnya secara otonom, murni dengan pendekatan vibe coding, dan LLM berhasil menulis proyek kompleks 7.000 baris (library Python, CLI, ekstensi Postgres) sambil menangani issue dan feature request sendiri.
    Saya bahkan belum pernah melihat langsung 90% dari kodenya, dan tidak ada masalah pada test coverage keseluruhan, CI yang lolos, maupun penggunaan nyata di production.
    Memang perlu rencana yang sangat detail di CLAUDE.md, serta issue dan request yang jelas serta spesifik, tetapi kalau persiapan itu ada, hasilnya berjalan baik.
    Mengelola atau menulis kode secara efisien lewat coding agent memang tidak mudah, tetapi pengalaman saya positif.
    GitHub steadytext

  • Saya menerima pandangan yang kritis, tetapi untuk memecahkan masalah yang ambigu, pada akhirnya kuncinya adalah seluruh tim berbagi banyak konteks.
    Solusi yang paling kreatif pun lahir dari batasan yang eksplisit maupun implisit.
    LLM tidak mampu menangkap batasan-batasan seperti ini, atau merancang solusi baru di dalam batasan yang belum didefinisikan dengan jelas.
    Baru setelah manusia mendefinisikan masalah, menentukan cakupan, dan memahami constraint, LLM bisa menjadi alat bantu implementasi.
    Untuk saat ini, ia baru bertambah sebagai salah satu pilihan di tingkat "tool apa yang akan dipakai untuk menyelesaikan kode ini?"
    Menarik diskusi ini ke arah solusi tunggal yang mutlak all-or-nothing justru terasa tidak realistis.

  • Sebenarnya banyak engineer manusia yang juga bekerja lumayan baik dalam situasi seperti ini.
    Kalau memberi instruksi ke LLM saja tidak semudah itu, saya jadi bertanya apa sebenarnya nilai keberadaannya.

  • Kiro sedang menerapkan pendekatan ini, dan walaupun masih tahap awal dan belum sempurna, kalau dipakai sesuai maksudnya hasilnya lumayan bagus.

• Saya makin frustrasi saat memakai claude code karena merasa benar bahwa "LLM tidak bisa membangun mental model yang jelas".
  Saya juga tidak yakin apakah LLM berbasis teks bisa benar-benar menyelesaikan masalah ini.

  • Ini mengingatkan saya pada contoh Google Genie 3 yang kehilangan state internalnya dalam sekitar satu menit.
    Saya punya firasat masalah ini baru bisa diatasi jika ada arsitektur baru di level transformer, sehingga short-term dan long-term context, serta penyesuaian bobot sendiri (semacam imitasi pembelajaran), bisa dimungkinkan.
    Referensi: diskusi terkait

  • Belakangan saya berpikir mungkin struktur agent hierarkis adalah alternatif yang realistis.
    Akan bagus jika agent tingkat atas hanya menjaga mental model keseluruhan, lalu agent-agent di bawahnya membagi pekerjaan satu sama lain.
    Rasanya sekarang pun ini sudah bisa diimplementasikan dengan fitur agent di tool Code; kalau ada yang punya strategi terkait, saya ingin mendengarnya.

  • Saya sudah mencoba claude-code-requirements-builder, dan memang sedikit lebih baik, tetapi tetap belum memuaskan.

  • Secara realistis, di lapangan kerja pun developer junior yang "rata-rata" sering tidak jauh berbeda dari ini.
    Mereka menganggap kode yang mereka buat pasti benar, panik saat test gagal, dan kalau tidak tahu arah, dalam kasus terburuk menghapus semua kode lalu menulis ulang dari nol.
    Mulai dari copy-paste dari StackOverflow, menyalahkan compiler, sampai bilang "ini gara-gara radiasi kosmik dari alam semesta" pun ada.

  • Semakin sering memakai LLM, semakin saya sadar bahwa pada akhirnya saya sendiri yang harus memimpin planning dan design.
    Pekerjaan berulang di level rendah dan test bisa saya serahkan ke LLM, dan saya senang karena jadi punya lebih banyak waktu untuk memikirkan gambaran besar.
    Hanya saja, saya berharap review hasil LLM dan usulan perubahan darinya bisa ditingkatkan menjadi jauh lebih interaktif.

• Saya pikir arah startup AI adalah inti masalah saat ini.
  Yang dibutuhkan bukan chat interface sederhana, melainkan workflow AI yang menyatu secara natural di dalam IDE.
  Seperti di Visual Studio, InteliJ, dan Android Studio, itulah arah trennya.
  Saya ingin tool yang makin mendekati programmer sungguhan: bisa diberi perintah suara dalam bahasa ibu saya, memahami konteks seluruh proyek, mencakup refactor, static analysis, feedback AI, membuat UI dari sketsa, coding dari tulisan tangan, sampai membuat commit message dari perubahan kode.

• Saya setuju bahwa LLM cukup berguna untuk pekerjaan level junior.
  Belakangan saya jadi memikirkan ulang klaim lama bahwa "kecepatan mengetik tidak terlalu penting".
  Dulu, karena desain keseluruhan dan penyusunan struktur jauh lebih penting daripada kecepatan mengetik kode, waktu input itu sendiri tidak terlalu dominan.
  Tetapi setelah memakai Claude, saya merasa perubahan kode yang dulu merepotkan dan sering saya tunda kini bisa dilakukan dengan mudah tanpa banyak fokus.
  Dulu setiap kali menambah satu nilai enum, saya harus hati-hati memperbarui semua bagian yang cocok dengannya, tetapi LLM bisa memperbaiki bagian itu secara otomatis.
  Pekerjaan yang dulu merepotkan karena harus memperbaiki compile error satu per satu sekarang cukup saya minta Claude membetulkannya berulang kali.
  Karena banyak agent bisa sekaligus menyentuh berbagai bagian kode, saya bisa memakai waktu itu untuk memikirkan struktur besar, atau bahkan menulis komentar di HN.
  Jadi, karena saya tidak perlu lagi memperbaiki compile error sendiri, saya bisa menerapkan lebih banyak perubahan dengan cepat, dan pekerjaan yang dulu bisa memakan satu hari penuh untuk junior kini bisa selesai sekaligus.
  Karena itu saya bisa lebih fokus pada desain arsitektur keseluruhan, dan juga menuntaskan berbagai pekerjaan coding kecil yang sudah lama tertunda, yang sangat membantu motivasi saya.

  • Saya setuju dengan pernyataan bahwa "meski mengetik jadi lebih cepat, itu tidak otomatis mempercepat sampai ke tujuan, karena bottleneck-nya ada di desain".
    LLM bisa sangat buruk dalam menyusun desain yang bagus, dan bahkan fungsi-fungsi kecil pun hampir selalu tetap perlu direfactor.
    Ada peningkatan produktivitas di tahap implementasi nyata, tetapi sebatas mewujudkan ide yang sebelumnya sudah ada di kepala saya atau di dokumen.
    Untuk brainstorming, ini lumayan berguna.
    Kalau saya melempar seluruh kode dan test lalu bertanya, "ada edge case yang saya lewatkan?", mungkin satu atau dua dari sepuluh sarannya akan benar-benar berguna.
    Fix jangka pendek agar sesuatu berjalan dan keunggulan struktural jangka panjang adalah dua masalah yang sangat berbeda, jadi apakah LLM bisa mengejar yang kedua masih belum jelas.

  • Soal "ada banyak hal yang ingin saya lakukan di codebase", saya justru merasa bottleneck-nya sebenarnya ada di review, bukan pada perubahan kode itu sendiri.

  • Kalau "pekerjaan yang butuh seharian untuk junior bisa cepat diselesaikan LLM", dan itu pada akhirnya menghilangkan kesempatan belajar para pemula lalu berujung pada berkurangnya perekrutan, saya khawatir siapa yang nanti akan membesarkan mereka.

• Soal fenomena "tidak bisa memutuskan apakah yang perlu diperbaiki itu kode atau test saat test gagal",
  memakai bahasa "Red-Green-Refactor" ternyata membantu.
  Sekarang saya menjelaskan dengan jelas ke LLM alurnya: tahap RED (test gagal itu normal), tahap GREEN (buat kondisi sukses dengan kode seminimal mungkin), dan tahap REFACTOR (perbaiki kode tanpa merusak test).
  Dengan begitu, LLM bisa memahami mental model TDD, bukan sekadar "memperbaiki kode yang rusak".

• Menurut saya jelas bahwa LLM masih belum cukup untuk proyek baru utuh di level "buatkan Facebook versi saya sendiri".
  Sebaliknya, untuk tugas yang lebih rinci seperti "tambahkan modal seperti ini, sesuaikan stylenya dengan kode yang sudah ada", saya sering mendapatkan hasil yang saya inginkan.
  Jika masalahnya dipecah menjadi unit kecil lalu diberikan satu per satu, hasilnya jauh lebih baik.

  • Menyalin kode yang sudah ada lalu memodifikasinya sesuai kebutuhan sebenarnya sudah bisa saya lakukan sendiri.
    System clipboard saya, tidak seperti LLM, selalu bekerja secara deterministik dan tidak tanpa akhir menciptakan masalah baru tak terduga seperti LLM.

  • Saya penasaran bagaimana tool baru seperti v0 akan merespons permintaan seperti ini.

• Saya merasa proses empat langkah di awal tulisan sangat mirip dengan "The Beginning of Infinity" karya Deutsch.
  Teori kita berawal dari "dugaan", dan pengetahuan terbentuk lewat "siklus dugaan dan kritik".
  Menulis kode adalah semacam "dugaan", dan membuat test adalah "kritik" terhadap dugaan itu.
  Keduanya adalah proses yang berusaha mendekat ke penjelasan yang ada di dalam kepala kita (ideal Platonis).