1 poin oleh GN⁺ 6 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Deskilling menggantikan kerja terampil dengan pengoperasian teknologi oleh pekerja berketerampilan rendah, sehingga menurunkan biaya dan hambatan masuk, tetapi juga melemahkan daya tawar pekerja
  • Selama 10 tahun terakhir, frontend kehilangan keahlian front of the frontend karena framework dan tool menutupi pengetahuan tentang browser, aksesibilitas, dan performa
  • AI berbasis agen mendorong coding ke tingkat abstraksi yang lebih tinggi, tetapi merupakan abstraksi bocor (leaky abstraction) yang non-deterministik dan hasilnya bisa sangat berubah hanya karena perbedaan kecil pada input atau model
  • LLM adalah kelanjutan dari copas Stack Overflow: membuat yang berpengalaman jadi lebih cepat, dan pemula pun bisa menghasilkan sesuatu yang berjalan, tetapi tetap harus ada orang yang memahami dan memperbaiki hasilnya
  • AI bisa menghasilkan lebih banyak AI slop dan penghematan biaya, tetapi tidak berarti kebutuhan akan orang yang memahami kualitas, pengguna, dan trade-off akan hilang

Frontend dan coding AI dilihat dari deskilling

  • Deskilling adalah proses mengganti kerja terampil dengan teknologi yang bisa dioperasikan pekerja semi-terampil atau tidak terampil; ini menurunkan biaya dan hambatan masuk, tetapi melemahkan daya tawar pekerja
  • Pengembangan frontend telah mengalami deskilling selama 10 tahun terakhir lewat framework dan tool JavaScript, dan kini AI berbasis agen sedang mendorong perubahan serupa di dunia pemrograman secara umum
  • Seperti ungkapan Frontend’s Lost Decade, keahlian frontend yang dulu memahami browser dan pengalaman pengguna secara mendalam tersisih oleh pengembangan yang berpusat pada framework

Keahlian yang hilang dari frontend

  • Dulu, pengembangan frontend membutuhkan pengetahuan khusus tentang HTML semantik, CSS, perbedaan antar-browser, aksesibilitas, progressive enhancement, performa jaringan, desain antarmuka, dan pengujian pengguna
  • Sebagian praktisi membedakan ranah ini dari “frontend” masa kini dan menyebutnya front of the frontend
  • Deskilling di frontend berlangsung lewat adopsi framework dan tool yang memperlakukan browser seperti target kompilasi sederhana, mirip JVM atau iOS sebagai runtime aplikasi
  • Dengan mengambil komponen seperti Shadcn radio button, orang bisa membangun fitur tanpa perlu memahami secara mendalam HTML dasarnya, nuansa tiap browser, performa pemuatan halaman, atau aksesibilitas
  • Perusahaan bisa lebih mudah menempatkan programmer umum ke pekerjaan frontend untuk menekan biaya
  • “Developer full-stack” kini sering berarti bukan orang yang benar-benar memahami frontend dan backend secara mendalam, melainkan developer serbaguna yang bisa menangani keduanya dengan framework JavaScript
  • Developer yang sama bisa dengan mudah dipindahkan antarproyek, dan bahkan diberi tanggung jawab aplikasi native lewat React Native dan Electron
  • Bersamaan dengan turunnya hambatan masuk, daya tawar pekerja juga melemah

Coding AI adalah abstraksi yang lebih tinggi sekaligus abstraksi bocor

  • Perubahan yang kini terjadi di pemrograman secara umum mirip dengan yang sudah dialami developer web
  • Arah perubahannya adalah mengganti kerja terampil berupa menulis kode secara langsung dengan teknologi yang ditangani pekerja semi-terampil atau tidak terampil
  • Kemampuan akhir apa yang akan dibutuhkan pekerja yang menggunakan AI berbasis agen, dan di mana harga tenaga kerja serta biaya LLM lokal maupun jarak jauh akan berakhir, masih belum jelas
  • Namun tampak jelas bahwa perusahaan kemungkinan akan memakai teknologi ini untuk menekan biaya dan melemahkan daya tawar pekerja
  • Menurunnya nilai pasar dari keahlian yang diasah bertahun-tahun ini mirip dengan perubahan ketika pengrajin dan pekerja manual digantikan oleh pekerja lini perakitan
  • Deskilling juga bisa dipandang sebagai peningkatan efisiensi lewat otomatisasi, yaitu perubahan menuju tingkat abstraksi yang lebih tinggi
  • Teknologi baru menyembunyikan detail dan membuat operator fokus pada gambaran besar, tetapi keputusan tentang detail mana yang dianggap “tidak penting” adalah keputusan besar
  • Pada akhirnya, detail dari abstraksi akan bocor juga suatu saat
  • Abstraksi bocor pada frontend “modern”

    • Abstraksi sering membawa biaya performa, dan pilihan untuk mengorbankan sebagian performa runtime demi produktivitas developer bisa masuk akal pada server yang kuat dan beban biasa
    • Di ponsel pada jaringan lambat, trade-off yang sama menjadi masalah yang sangat berbeda
    • Ketika banyak memakai framework JavaScript sisi-klien yang berat seperti React beserta paket-paket ekosistemnya, kita mengabstraksikan begitu saja aksesibilitas dan performa pada ponsel kelas bawah serta jaringan lambat
    • Akibatnya, pilihan diambil tanpa memikirkan masalah-masalah itu, dan tanpa benar-benar peduli padanya
  • Non-determinisme dalam coding berbasis agen

    • Saat membangun fitur atau memperbaiki bug dengan AI berbasis agen, alih-alih menulis semua kode sendiri, kita mendeskripsikan perubahan tingkat tinggi dengan lebih sedikit kata
    • AI melihat data pelatihan dan konteks di sekitarnya lalu mengisi detail yang dihilangkan; kadang tebakannya tepat, kadang gagal
    • Berguna atau tidaknya pendekatan ini sangat bergantung pada apa yang dianggap penting dalam coding
    • Coding berbasis agen tidak deterministik seperti compiler; perubahan kecil pada input atau model dapat menghasilkan hasil yang sangat berbeda, sehingga kebocorannya jauh lebih besar daripada abstraksi pemrograman lama
    • Alasan AI sering dibandingkan dengan “engineer junior” juga terkait non-determinisme ini, tetapi bedanya manusia bisa belajar tanpa perlu AGENTS.md atau SKILL.md disetel tanpa henti

LLM adalah kelanjutan dari copas Stack Overflow

  • Analogi terdekat untuk penggunaan LLM adalah cara orang dulu memakai pencarian Google
  • Kemampuan memilih kata kunci yang tepat agar tulisan forum atau jawaban Stack Overflow yang relevan muncul di halaman pertama hasil pencarian juga merupakan keterampilan yang harus dipelajari developer
  • Prompt LLM juga merupakan proses untuk memunculkan kombinasi data pelatihan yang sesuai, dan lebih mirip pengambilan pada ruang berdimensi tinggi seperti pencarian web yang kabur
  • Hasil pencarian sensitif terhadap perubahan kecil dalam frasa maupun perubahan pada indeks pencarian Google, dan LLM juga sensitif terhadap cara input diungkapkan serta perubahan model
  • Belakangan Google mengubah pencariannya agar istilah input dinormalisasi lebih kuat; pencarian jadi lebih mudah bagi orang yang tidak terbiasa dengan Google-fu, tetapi kurang kuat bagi yang sudah mahir
  • Google dan Stack Overflow telah mengubah pemrograman secara permanen, memungkinkan orang untuk menyalin-tempel jawaban alih-alih membaca manual, dan cukup sering mendapatkan hasil yang setidaknya lumayan berjalan
  • LLM berada di kelanjutan arus yang sama
    • Membuat orang yang tahu apa yang mereka lakukan menjadi sedikit lebih cepat
    • Memungkinkan orang yang belum terlalu tahu apa yang mereka lakukan untuk tetap membuat sesuatu yang lumayan berjalan
  • Abstraksi pada akhirnya akan bocor, dan ketika itu terjadi, harus ada seseorang yang benar-benar memahami apa yang sedang berlangsung dan memperbaikinya
  • Seperti dulu developer junior diajari untuk membaca dan memahami jawaban Stack Overflow sebelum memakainya, kini mereka juga perlu diajari untuk membaca dan memahami keluaran LLM serta menilai bagaimana hasil itu cocok dengan codebase yang ada

Jarak antara kualitas dan bisnis

  • Sebagian programmer tidak pernah benar-benar sampai pada tahap memahami jawaban Stack Overflow; selama hasilnya bekerja, itu dianggap cukup
  • Banyak perusahaan, meski tidak mengakuinya secara terbuka, juga puas dengan pendekatan seperti itu
  • Sekarang situasinya berkembang menjadi perusahaan yang secara terbuka membanggakan seberapa banyak mereka memakai AI, bahkan tanpa benar-benar berpura-pura menelaah hasilnya
  • Ada kasus penggunaan LLM yang valid, tetapi juga semakin banyak cara baru untuk merusak kode, komunikasi organisasi, dan proses kerja
  • Seperti halnya code review, ada perbedaan pandangan yang besar tentang bagaimana LLM seharusnya dipakai dan diintegrasikan ke workflow; jika ini tidak cocok dengan nilai yang dijunjung tim, alur kerja bisa bermasalah besar
  • Banyak perusahaan tetap berjalan baik meski terus membuat software yang buruk
  • Berlawanan dengan yang ingin dipercayai programmer, kesuksesan bisnis dan kualitas software sangat jarang benar-benar berkorelasi
  • Biasanya faktor lain seperti merek dan harga jauh lebih menentukan, dan proyek software diperlakukan seperti kotak hitam dengan peluang sukses dan gagal yang kurang lebih seimbang
  • Bahkan di frontend, situs yang lambat dan banyak banner cookie memang bisa menurunkan konversi, tetapi dampaknya lebih kecil dibanding faktor seperti loyalitas merek dan harga, dan situs kompetitor pun sering sama lambatnya
  • Dalam suasana seperti “tidak ada yang dipecat karena memilih React”, pilihan yang aman lebih disukai daripada kualitas
  • Ini bukan berarti kita harus berhenti peduli pada pengguna dan craftsmanship, tetapi semakin sulit mencari tempat kerja yang memungkinkan itu
  • Ketika hype mereda dan pemahaman tentang pekerjaan yang benar-benar cocok atau tidak cocok untuk LLM terbentuk, sebagian keseimbangan mungkin akan kembali, tetapi profesinya sendiri tidak akan sama lagi seperti dulu

Keterampilan yang tetap tersisa setelah industrialisasi

  • Ketika produk sehari-hari dan bangunan mulai bisa diproduksi massal lewat proses industri, salah satu reaksinya adalah membuat produk dan bangunan pabrikan yang meniru gaya masa lalu agar tampak seperti buatan tangan
  • Melawan historisisme semacam ini, Bauhaus pada awal abad ke-20 mengembangkan pendekatan yang tidak mempertentangkan pekerja pabrik dan pengrajin, melainkan membuat keduanya bekerja bersama dan mengembangkan kembali seni serta kerajinan dengan asumsi proses manufaktur industri
  • Bauhaus menuntut desainer kembali ke bengkel dan menangani material secara langsung, tetapi dengan tujuan akhir berupa desain yang bisa diproduksi massal
  • Software lebih mirip kerajinan karena program yang ditulis disampaikan kepada pengguna “apa adanya” tanpa melalui tahap manufaktur, tetapi juga mirip desain industri karena hal yang sama didistribusikan ke ribuan pengguna
  • Kemampuan menulis kode dengan tangan tetap dibutuhkan; seperti desainer industri harus memahami material produknya, desainer web juga harus sangat akrab dengan HTML dan CSS
  • Google, Stack Overflow, library siap pakai, dan LLM memang memudahkan pemula untuk mulai, tetapi juga terus menurunkan hambatan alami untuk membuat sesuatu sekadar bekerja
  • Industrialisasi memang menghasilkan banyak produk plastik murah yang dibuat tanpa cukup memikirkan cara pakai dan penggunanya, tetapi desain industri yang baik tetap ada
  • Word processor menghasilkan banyak dokumen dengan format buruk, tetapi tipografi dan desain grafis tetap ada
  • Wix dan Next.js memungkinkan terciptanya banyak situs yang lambat dan kurang aksesibel, tetapi praktisi front of the frontend juga tetap ada
  • AI memungkinkan munculnya banyak AI slop, tetapi bukan berarti orang yang tahu apa yang mereka lakukan dan peduli pada pekerjaannya tidak lagi dibutuhkan

Perubahan dan trade-off ke depan

  • Seperti di industri lain, porsi pekerjaan yang benar-benar dikerjakan dengan baik mungkin akan menjadi bagian yang lebih kecil dari keseluruhan
  • Pada saat yang sama, total pasar akan terus membesar karena membuat sesuatu menjadi lebih mudah dan murah
  • Sulit menilai sekarang apakah jumlah absolut orang yang dibayar untuk bekerja dengan baik akan bertambah atau berkurang
  • Ada kalanya membuat prototipe cepat atau MVP memang merupakan pilihan yang benar
  • Jika product-market fit belum ditemukan, iterasi dan pembelajaran cepat lebih penting daripada membuat semuanya tahan masa depan sejak awal
  • Namun kita tetap harus tahu apa yang ingin dipelajari dan bagaimana memvalidasi pembelajaran itu
  • Ketika waktunya tepat, biasanya lebih baik mundur sejenak dan mengerjakannya dengan benar dari awal
  • Misalnya, mencapai performa yang baik belakangan pada frontend dengan arsitektur buruk itu sangat sulit
  • Memulai dengan stack yang sederhana lalu menambah fitur belakangan lebih mudah daripada kebalikannya
  • Mastro secara eksplisit mendorong titik awal dengan performa baik dan stack sederhana
  • Entah memilih membeli layanan, memakai library open source, menghasilkan dengan LLM, atau menulis sendiri, kita harus tahu trade-off apa yang diambil di tiap bagian sistem
  • Saat hype mereda, industri akan menyadari bahwa AI hanyalah salah satu alat lain di kotak peralatan
  • Sampai saat itu, dengan nama AI, kita mungkin masih akan terus melihat kode buruk, komunikasi yang rusak, dan PHK yang mengerikan

1 komentar

 
GN⁺ 6 jam lalu
Komentar Hacker News
  • Menurut saya, keahlian mendalam yang disesalkan OP sebenarnya cukup tidak nyaman bagi banyak orang
    Keanehan tiap browser, membangun sendiri komponen yang aksesibel, dan mencari nafkah dari kemahiran dalam kekhususan CSS memang bisa dipahami, tetapi bagi kebanyakan orang itu lebih dekat ke kompleksitas insidental. Jelas merupakan hal baik bila lebih banyak orang bisa membuat sesuatu, dan jika sebagian hasilnya lebih lambat atau kurang aksesibel, itu adalah kompromi yang bisa dipilih
    Bisa juga dikatakan bahwa abstraksi memaksakan konsekuensi yang tidak dipilih pengguna, tetapi saya juga melihat kemungkinan bahwa LLM lebih memahami konvensi aksesibilitas daripada saya

    • Selalu sulit menangani dengan baik elemen UX/pengembangan perangkat lunak yang kurang terlihat seperti aksesibilitas, intuisi, kompatibilitas, responsivitas, skalabilitas, arsitektur, dan performa
      Namun framework tingkat sangat tinggi dan sekarang LLM membuat bagian-bagian ini rusak sambil mempermudah peluncuran MVP setengah matang dengan cepat, sehingga jarak antara “bisa diterima” dan “bagus” makin melebar. Dari sudut pandang yang mengejar “bagus”, makin sulit bersaing dengan pihak yang mendorong “bisa diterima”
      Akibatnya, ini berujung pada lebih banyak lembur dan penurunan kualitas perangkat lunak, mungkin juga turunnya kepuasan kerja secara keseluruhan. Belakangan ini mulai terjadi situasi di mana orang memperbaiki situs web yang rusak atau menghapus gangguan dengan alat pengembang dan uBlock demi menghidupkan kembali fungsi dasar, dan saya juga melihat orang-orang di sini melakukan hal yang sama(https://news.ycombinator.com/item?id=47042747). Dulu, bahkan pada era Flash atau browser awal, tidak perlu sampai mengutak-atik langsung seperti ini
      Ada juga contoh yang kurang anekdotal: https://news.ycombinator.com/item?id=47390945
      Yang lebih buruk, sebagian besar uang yang dihemat dari pemangkasan seperti ini hanya kembali ke lapisan paling atas organisasi
    • AI berulang kali membuat kesalahan dengan menempatkan objek animasi di belakang objek blur, sehingga browser terus-menerus melakukan redraw
      AI mode milik Google juga memuat hal seperti itu, dan situs web lain tampaknya jelas memasukkan hal serupa lewat vibe coding
      Awalnya saya bingung kenapa penggunaan GPU melonjak dan kipas berputar kencang, tetapi sekarang saya melihat ini sebagai kesalahan yang sering dibuat AI dan tidak diuji dengan benar oleh siapa pun. Manusia juga bisa membuat kesalahan seperti ini, tetapi sampai sekarang saya nyaris tidak pernah mengalaminya sepanjang hidup
      Karena saya memakai monitor 240Hz, browser mencoba melakukan redraw 240 kali per detik, dan satu-satunya cara adalah memblokirnya dengan uBlock Origin. Tidak masuk akal
    • Tulisan jenis “kita sedang kehilangan keahlian craftsmanship kita” selalu punya pola muram yang sama
      Yang lebih buruk, di pertengahan tulisan biasanya mereka justru membantah argumennya sendiri
      Misalnya ada kalimat, “keputusan tentang detail mana yang dianggap tidak penting adalah keputusan yang sangat penting, kadang subjektif, dan pada akhirnya detail selalu bocor keluar”; kalau begitu, artinya teknologi baru ini pada akhirnya tetap memberi imbalan pada pemahaman teknis yang mendalam. Karena itu tak terhindarkan. Saya setuju soal itu. Tapi lalu kenapa nada keseluruhannya menjadi “AI sedang menjadikan keahlian saya komoditas murahan”?
      Situs web secara teknis umumnya lebih baik daripada 10 tahun lalu. Fiturnya lebih banyak, lebih cepat, dan SSL/aksesibilitas/responsif telah menjadi default yang lebih kuat. Masalah content farm, SEO, dan situs berita adalah pola kegagalan mengerikan yang terpisah, dibentuk oleh iklan dan insentif korporat, bukan salah React
    • Pernyataan “LLM akan lebih memahami konvensi aksesibilitas daripada saya” itu tepatnya terjadi karena orang lain memahaminya dan menuliskannya
      LLM kadang bisa memanfaatkannya. Tetapi kalau orang berhenti menulisnya, lalu apa yang terjadi berikutnya?
      Saya setuju bahwa lebih banyak orang membuat sesuatu itu baik. Jika faktor lainnya sama, lebih banyak memang lebih baik. Kalau “AI” meresap ke mana-mana karena perbaikan yang tak terbantahkan, situasi dan suasananya pasti akan sangat berbeda
      Meski begitu, orang tidak otomatis memiliki hak yang sewajarnya atas pengetahuan yang “dihasilkan” melalui kerja mereka. Jika atribusi dan kompensasi ditangani dengan serius, dan pelatihan hanya boleh memakai materi berbayar kepada para pembuatnya, mungkin jauh lebih cepat dan murah untuk belajar CSS saja
    • Kemudahan yang dibangun dengan mengabaikan “keahlian mendalam”, lalu menumpuk hack dan abstraksi malas di atasnya, menurut saya adalah bentuk kemunduran yang berlanjut sampai framework modern berukuran beberapa MB dan Electron
      Tentu saja tidak ada yang peduli pada penggunaan komputer/memori pengguna, pengalaman yang menurun, bandwidth yang terbuang, atau biaya energi tambahan dan dampak lingkungan yang dibebankan kepada 8 miliar orang
      Apakah lebih banyak orang membangun infrastruktur publik juga “jelas hal yang baik”? Jika hasilnya jalan yang lebih buruk, jembatan yang lebih buruk, dan sistem yang gagal? Perangkat lunak juga sama, dan sebenarnya kebanyakan hal juga demikian
  • Sebagian besar dari “teknologi frontend” yang katanya dalam tulisan ini mulai kehilangan relevansinya sebenarnya adalah pekerjaan menembus ladang ranjau penuh pengecualian yang tidak intuitif, ketidakcocokan antar-browser, beban sejarah, serta pengecualian dari pengecualian dari pengecualian
    Frontend modern, yaitu “menara abstraksi yang bocor”, pada akhirnya memang lebih mendekati model mental yang masuk akal untuk pengembangan web. Ini dipaksakan di atas bahan peledak berupa keanehan standar dan konvensi web, tetapi fakta bahwa ini tetap bekerja dan hanya sedikit bocor saja sudah merupakan pencapaian

    • Ungkapan “model mental yang masuk akal untuk pengembangan web” itu kontradiktif. Entah ini dunia pengecualian seperti ladang ranjau, atau model yang masuk akal; tidak bisa keduanya sekaligus
      Kita masih berada di ladang ranjau pengecualian, dan sulit mengatakan bahwa teknologi pembuat frontend sudah menjadi bersih, dapat diprediksi, dan bebas dari beban sejarah
      Yang kita lakukan hanyalah menambal plester di atas kesalahan dan inkompatibilitas fondasi, bukan menyelesaikannya. React tidak menyelesaikan fakta bahwa HTML tidak dirancang sebagai kotak alat UI. Next.js tidak menyelesaikan fakta bahwa JavaScript penuh dengan kesalahan desain yang membuatnya gagal menjadi bahasa yang aman, waras, dan rasional. Tailwind tidak menyelesaikan masalah bahwa CSS diperkenalkan secara tambal sulam untuk mempercantik markup yang memang tidak dirancang untuk styling
      Yang dilakukan LLM sekarang hanyalah “mengetahui” kengerian di bawah plester itu di dalam model statistik. Model itu dilatih dengan contoh-contoh dari era ketika 99% kasus hanyalah menambal retakan di lapisan plester sebelumnya
    • Saya bukan ahli, tetapi setelah pernah merilis frontend yang dilihat publik, frontend itu seperti jalan bata kuning di The Wizard of Oz
      Selama tidak keluar dari sekumpulan kecil praktik baik yang cukup masuk akal, beberapa library yang membosankan namun teruji sudah cukup untuk memberi pengalaman yang lumayan bagus
      Tetapi begitu Anda terlibat dengan framework frontend yang sedang tren hari ini, atau lebih buruk lagi framework yang tren kemarin, atau harus menyesuaikan diri dengan preferensi ganjil pengembang lain yang ngotot pada satu cara tertentu, atau mulai menangani hack “jenius” yang direkatkan dengan harapan dan duct tape, kompleksitas dan cara interaksinya akan meningkat secara eksponensial
    • Tulisan aslinya seperti sedang meratapi hilangnya sebuah zaman keemasan yang sebenarnya tidak pernah ada
      Saya mengalami masa itu. JavaScript murni khusus IE6 digantikan oleh jQuery yang penuh bug, lalu oleh aplikasi satu halaman Angular yang tak mungkin dirawat, lalu oleh codebase React yang seperti monster
    • Ini terdengar seperti pernyataan yang menunjukkan ketidaktahuan
      Kenyataannya jauh lebih dari itu
      Saya terlalu sering melihat orang datang wawancara mengaku ahli Next.js, tetapi di luar itu tidak bisa apa-apa. Itu bukan keterampilan, hanya pengetahuan, dan sekarang pengetahuan itu tersedia gratis di mana-mana
    • Kemampuan memahami abstraksi bocor itu ada di menara mana, di lantai mana, dan di ruangan mana tetap sangat berharga dan mungkin tidak terlihat oleh LLM
      Hanya karena sesuatu tidak dirancang sempurna sejak awal oleh sebuah komite, bukan berarti kita boleh melupakan semuanya, menutup bukunya, lalu membiarkan mesin yang menghitung
      Saya juga melakukan yang kedua, jadi saya tahu di mana letak salahnya, tetapi bukan berarti saya tertipu sampai membuat kekacauan yang tak bisa dirawat. Setiap kali agen-agen itu keluar jalur, keterampilan frontend saya benar-benar berguna
  • Pernyataan bahwa “frontend adalah keterampilan yang sangat terspesialisasi yang menuntut pemahaman tentang HTML yang semantis, CSS, perbedaan browser, aksesibilitas, progressive enhancement, performa jaringan, desain antarmuka, pengujian pengguna, dan sebagainya” mungkin terdengar cukup lucu bagi generasi frontend sebelumnya, yaitu para pengembang C/C++
    Web dulu dianggap menurunkan hambatan masuk secara besar-besaran dan mengurangi tingkat keterampilan yang dibutuhkan. Para programmer assembly mungkin juga berpikir serupa tentang pengembang C/C++

    • Setiap lapisan menganggap dirinya yang paling penting, paling terspesialisasi, dan paling terampil
      Tetapi semua lapisan salah. Setiap lapisan dibangun di atas abstraksi dari lapisan di bawahnya. Jika ditelusuri sampai fisika dan matematika, bahkan para penganut teori himpunan pun mengasumsikan aksioma tertentu. Tidak ada yang tahu apa yang sebenarnya dilakukan para ahli logika
    • Kutipan itu tidak berasal dari tulisan tersebut dan juga tidak berhubungan dengannya, jadi saya tidak mengerti sebenarnya sedang terjadi apa
  • Logika seperti “sedih rasanya karena proses baru ini menghasilkan keluaran berkualitas lebih rendah dan tampaknya banyak orang tidak peduli” tampaknya bergantung pada asumsi bahwa sebelum AI, sebagian besar pekerjaan ini dikerjakan oleh para perajin terampil yang berdedikasi pada kualitas
    Siapa pun yang benar-benar pernah bekerja di industri ini dan jujur pasti tahu, kenyataannya tidak begitu. Ada banyak yang di bawah rata-rata
    Selain itu, tergantung bagaimana Anda mendefinisikan “kualitas”, sulit juga memastikan bahwa hasil AI memang berkualitas lebih rendah. AI bisa menghasilkan keseragaman yang canggung, tetapi sekaligus banyak hasilnya cukup berguna karena konvensi yang dipelajari model, suka atau tidak, memang “berfungsi” bagi mayoritas pengguna akhir

    • Ini lebih mirip “menambahkan satu bata lagi ke dinding”
      Sebelumnya pun sudah ada banyak tekanan untuk melakukan minimum yang memenuhi kebutuhan lalu menyatakannya sukses. Sekarang rasanya tekanan itu menjadi tak tertahankan
    • Soal asumsi bahwa sebelum AI ada para perajin terampil yang berdedikasi pada kualitas, ada juga orang-orang yang beruntung sempat mengalami masa seperti itu beberapa kali dalam karier mereka
      Hanya saja saya setuju bahwa itu sudah menghilang bahkan sebelum AI
    • Standar kualitasnya tampak sangat rendah
    • Benar. Web sebelum jQuery dan Bootstrap memang berantakan dan juga tidak menyenangkan untuk dikoding
      Kalau bicara kualitas rendah, justru itulah yang lebih umum saat itu
  • Baru-baru ini saya juga memikirkan hal yang mirip.
    Saya memang hampir tidak mengerjakan pengembangan frontend setidaknya selama 10 tahun, tetapi saya cukup tua untuk mengingat masa ketika pada akhir 2000-an tiba-tiba semua orang mulai memakai framework alih-alih membuat web GUI dengan tangan, dan orang yang masih menulis HTML/CSS/JS serta kueri database secara manual tetap diejek. Iklan lowongan juga tiba-tiba mulai meminta Ruby on Rails, Django, Spring, GWT, lalu belakangan Angular, alih-alih PHP/HTML/CSS/SQL/JS.
    Rasanya anehnya familier dengan keadaan sekarang. Bahkan tanpa pengetahuan mendalam, kita bisa membuat aplikasi web yang berjalan hanya dalam beberapa menit, dan itu terasa seperti sihir. Setelah itu, kita menyesuaikan sesuatu di dalam framework sambil sekilas melihat dokumentasi dan mencari-cari, lalu pada suatu titik tidak bisa lanjut lagi. Karena kita sama sekali tidak tahu bagaimana bagian dalamnya bekerja. Seperti webapp vibe coding, webapp framework standar yang ditempel-tempel dalam satu sore bisa dikenali dari jauh, tetapi bagi para manajer itu sangat mengesankan.
    Yang menarik, para pengembang membicarakan model terdepan yang paling sering mereka pakai dengan cara yang mirip dengan bagaimana para pengembang GUI 15~20 tahun lalu membicarakan framework web favorit mereka. Mereka mempersonifikasikan alat, bahkan mengidentifikasikan diri dengannya, frustrasi karena sesuatu yang berjalan di versi X memburuk di X.1, dan terus mengulang kalimat seperti “sekarang saya mengembangkan 10 kali lebih cepat” atau “saya akan menulis XYZ dengan tangan lagi”.

    • Sebaliknya, penggunaan framework setelah itu juga merupakan upaya yang baik untuk standardisasi.
      GUI buatan sendiri yang tidak seorang pun tahu cara menanganinya juga bukan kelebihan.
      Secara pribadi saya menolak hal-hal yang terasa terlalu “besar” seperti Nuxt/Next, tetapi saya suka Vue. Hanya saja sekarang saya ingin menghapus sebagian besar JavaScript, jadi saya cenderung ke solusi keluarga HTMX atau Alpine bersama template sisi server.
      Secara pribadi, makin sedikit teknologi yang dipakai makin baik. Dulu juga ada masa ketika webapp sudah dipenuhi segala macam hal yang tidak perlu bahkan sebelum menambahkan satu baris kode kustom.
    • Bahkan pada awal 2000-an, para pengembang web sudah lelah harus mengodekan semuanya dengan tangan, dan mencari otomatisasi seperti framework atau CMS.
      Bahkan pada 2004 saya pernah membuat situs dengan pendekatan dasar seperti menaruh txt dalam pohon direktori lalu PHP menyisipkannya ke HTML sambil menambahkan tag alih-alih pemisah baris. Alternatif saat itu adalah sistem manajemen konten yang berat.
      Saya datang ke Django setelah melewati dua framework PHP mengerikan buatan para lead developer di tempat kerja, jadi framework seperti Django terasa sebagai transisi yang lebih bertahap dan jauh lebih menyenangkan.
      Tentu saja, kalau didorong lebih jauh, misalnya dengan menambahkan version control ke objek, semuanya jadi sangat rumit, tidak ada jaminan akan berfungsi, dan juga tidak ada cara memperbaikinya.
      Meski begitu, sikap dasarnya sendiri tampak mirip dengan sekarang.
  • Kita berada di industri perangkat lunak. Inti industri ini adalah mengotomatisasi pekerjaan yang sangat berulang.
    Proyek frontend sangat berulang, dan sekarang AI mengerjakannya. Itu hal yang bagus, dan membebaskan banyak waktu untuk membuat hal-hal yang lebih menarik.
    Deskilling pada keterampilan yang tidak lagi terlalu relevan adalah sesuatu yang terus terjadi di industri ini sejak komputer ditemukan. Karena masalahnya telah diselesaikan, entah oleh AI atau cara lain.
    Tinggal lanjut dan pelajari teknologi baru. Sebenarnya, menggunakan AI secara efektif juga merupakan keterampilan yang sulit bagi sebagian orang. Benda-benda tetap tidak dibuat dengan sendirinya. Jika Anda memberi prompt yang benar, Anda bisa menyelesaikannya, tetapi apakah Anda memang memberi prompt dengan benar? Apakah alat itu benar-benar melakukan yang diminta? Bagaimana Anda tahu? Sudah memeriksanya? Saya sendiri menghabiskan sangat banyak waktu untuk memberi prompt ke AI, dan jelas membaik, tetapi itu masih nyaris seperti pekerjaan penuh waktu.
    Sekitar 10 tahun lagi kita akan melihat ke belakang dan menganggap cara ini sebagai cara yang sangat tidak efisien untuk membuat perangkat lunak. Alat akan menjadi lebih baik dan AI akan menjadi lebih otonom. Jika Anda menghabiskan waktu seharian mengulang prompt yang sama, seseorang atau sesuatu juga harus mengotomatisasi itu.

    • Tujuan perangkat lunak adalah mengodekan kehendak manusia ke dalam bentuk yang bisa dikomunikasikan oleh mesin.
      Keluhan di sini adalah bahwa otomatisasi itu berisiko mengodekan hal yang tidak diinginkan.
    • Alih-alih menyerah pada frontend, efisiensi baru yang dibuat AI seharusnya membebaskan sumber daya untuk mendorong frontend dan backend lebih jauh.
      Dunia membutuhkan jauh lebih banyak perangkat lunak daripada yang bisa kita buat sekarang.
    • Saya sama sekali tidak paham apa maksud pernyataan “proyek frontend sangat berulang”.
      Ini pandangan yang begitu buruk sampai saya bahkan tidak tahu harus membantah dari mana. Apakah yang dimaksud berulang itu karena semua UI punya tombol?
      Jika orang benar-benar percaya ini, saya jadi paham kenapa UX rusak sejak tahun 90-an dan kemudian makin memburuk.
    • Anda mungkin akan terkejut kalau sadar bahwa tidak ada banyak “hal menarik” yang bisa dibuat.
  • AI coding sangat membantu untuk membuat prototipe produk, tetapi pada saat yang sama juga melahirkan produk yang dari jauh pun terlihat jelas dibuat oleh AI.
    Barusan juga ada startup yang mendemokan aplikasinya, dan aplikasinya punya nuansa UI vibe coding yang sangat jelas.
    Umpan balik yang mereka terima dingin, tetapi tepat. Isinya kira-kira, “cukup lumayan, tetapi terlalu kelihatan dibuat dengan AI, dan kalau begitu orang lain yang menginginkan ini juga bisa membuatnya dengan sangat cepat memakai AI, jadi tidak ada banyak nilai pada apa yang ingin Anda jual.”

    • Saya berharap hal seperti ini lebih sering terjadi. UI buatan LLM, dan orang-orang yang menganggap itu sudah cukup, sama-sama sulit ditoleransi.
    • Yang lucu, cukup dengan menyiapkan design system dasar dan CSS, kode frontend yang dihasilkan AI bisa terasa cukup menyatu secara alami.
      Tetapi kebanyakan orang bahkan tidak memberi perhatian dasar sebanyak itu.
      Sudut membulat masih menjadi tren tanpa akhir, dan segala hal yang belum terdefinisi dengan baik tampaknya ikut terinfeksi bentuk itu.
    • Ini terdengar lebih seperti fantasi di kepala daripada sesuatu yang benar-benar terjadi.
      Venture capitalist yang kompeten tidak akan memberi umpan balik tak bermakna seperti ini. Kalau bagus ya bagus, memangnya apa masalahnya jika itu dibuat oleh AI? Jika produknya berkualitas sama tetapi tidak terlihat seperti hasil vibe coding, apakah itu berarti tidak apa-apa? Ini hanya hal yang akan dipedulikan oleh orang yang secara ideologis menentang AI.
  • Kadang terasa seperti teknik membuat antarmuka pengguna yang kompleks dengan HTML tanpa AJAX atau manipulasi DOM pada awal 2000-an praktis telah hilang, seperti teknik pembangunan piramida
    Ada sisi “deskilling” pada developer full-stack muda, sehingga banyak juga yang mengira, misalnya, validasi formulir memerlukan JavaScript
    Begitu mulai memakai AJAX dan memanipulasi DOM, kompleksitas komunikasi asinkron pada akhirnya hampir pasti berkembang menjadi sesuatu yang skalanya mirip React. Meski kita bisa menulis seperti document.title="A new title" dan tidak perlu menarik sesuatu, bahkan jika frontend dipandang hanya sebagai “memperbarui UI saat data datang dari server”, aplikasi yang kompleks tetap harus memperbarui banyak bagian UI, dan pada titik tertentu Anda akan membuat sesuatu seperti komunikasi atau bus manajemen state. Apakah bisa dibuat secara berbeda? Tentu saja bisa
    Jika ada masalah pada ekosistem React, itu bukan karena ia membuat abstraksi di atas abstraksi lain, melainkan karena abstraksi itu bocor. Jika Anda membuat sesuatu yang sangat sederhana dan tidak terlalu peduli pada tampilannya, Anda bisa memakai Bootstrap atau MUI tanpa memahami CSS. Tetapi untuk menghasilkan pekerjaan tingkat profesional yang ditampilkan ke pelanggan, Anda harus memahami HTML, CSS, JS, dan semua framework yang dipakai dalam proyek

    • Khususnya di HN, sering terasa bahwa React dipakai seperti kata makian empat huruf yang mewakili keluhan yang lebih luas terhadap web interaktif secara umum
      Kebanyakan orang yang mengkritik React sebenarnya tidak benar-benar memahami masalah apa yang diselesaikan React. Jika Anda diperlihatkan source code webapp yang cukup kompleks tetapi tidak bergantung pada React, Anda biasanya bisa menemukan tiruan mirip React buatan sendiri di dalamnya
  • Saya tidak setuju bahwa mengoperasikan aplikasi frontend dengan server-side rendering, lazy loading, dan semacamnya di NextJS itu “lebih mudah” dibanding masa ketika hanya memakai HTML, JS, dan CSS
    Tingkat kompleksitas dan ekspektasi pengguna berada di tempat yang sepenuhnya berbeda
    Selain itu, jumlah engineer terampil juga telah bertambah sekitar 1000 kali lipat, dan kita harus bersaing dengan pasar global. Pada awal 2000-an hampir tidak ada persaingan. Keterampilan pekerja umumnya hanya berkorelasi longgar dengan tingkat yang diminta pasar, tetapi sekarang pasar sangat kompetitif