- Banyak produk AI berhenti sebatas wrapper yang memanggil model eksternal seperti ChatGPT melalui API, sehingga membawa risiko diferensiasi, biaya, kecepatan, dan kustomisasi ke dalam produk
- Pendekatan panggilan LLM sederhana bisa dibuat cepat, tetapi dapat ditiru siapa saja; jika OpenAI memasukkan fungsi yang sama ke ChatGPT, sulit mempertahankan nilai unik
- LLM serbaguna mahal untuk dijalankan, sehingga dapat muncul struktur seperti GitHub Copilot: menarik biaya $10 per bulan, tetapi rata-rata biayanya $20, dan untuk sebagian pengguna hingga $80 per bulan
- Visual Copilot dari Builder mencoba menggunakan LLM saja dalam proses mengubah desain Figma menjadi kode, tetapi karena latensi respons dan batas kualitas, mereka beralih ke toolchain internal
- Secara praktis, lebih cepat, murah, dan mudah dikendalikan jika masalah diselesaikan lebih dulu dengan kode biasa, lalu model AI khusus ditambahkan hanya pada area sempit yang sulit ditangani dengan kode standar
Batasan pendekatan wrapper LLM sederhana
- Banyak produk AI yang dibuat saat ini lebih menyerupai wrapper di atas model lain, bekerja dengan mengirim input bahasa alami ke ChatGPT API dan menerima output bahasa alami
- Implementasinya mudah dan dapat menghasilkan fitur menarik dengan cepat, tetapi jika nilai unik produk berada pada teknologi AI canggih, risiko peniruannya menjadi besar
- Alur seperti aplikasi chat PDF—ketika satu orang membuatnya, lalu banyak orang membuat aplikasi serupa, dan kemudian OpenAI memasukkannya langsung ke ChatGPT—terjadi saat teknologi yang terdiferensiasi kurang kuat
- Jika produk hanya sebatas satu tombol yang mengirim permintaan ke ChatGPT lalu menampilkan respons kepada pengguna, daya tahannya paling lemah
- Jika teknologi internalnya substansial dan LLM hanya membantu sebagian kecil namun penting, posisinya lebih baik, tetapi masalah biaya dan kecepatan tetap ada
Biaya dan kecepatan adalah batasan nyata dalam produkisasi
- LLM menjadi besar dan kompleks demi mendapatkan keserbagunaan yang luas, dan karena itu biaya menjalankannya juga tinggi
- Menurut Wall Street Journal, GitHub Copilot menagih pengguna $10 per bulan, tetapi biaya rata-ratanya $20, dan sebagian pengguna menimbulkan biaya hingga $80 per bulan bagi GitHub
- Banyak produk tidak membutuhkan model raksasa yang dilatih dengan seluruh internet; 99,9% cakupan pelatihannya mungkin tidak relevan dengan kasus penggunaan tertentu
- Bisa terjadi situasi ketika biaya operasional layanan berbasis LLM lebih besar daripada jumlah yang bersedia dibayar pengguna
- Kecepatan juga sangat menentukan pengalaman produk
- Dalam pengalaman seperti ChatGPT, ketika pengguna membaca kata demi kata, output yang lambat masih dapat ditoleransi sampai batas tertentu
- Dalam aplikasi yang membutuhkan respons lengkap sebelum dapat berpindah ke langkah workflow berikutnya, latensi langsung menurunkan usability
- Visual Copilot dari Builder mencoba transformasi LLM untuk mengubah desain menjadi kode berkualitas tinggi, tetapi proses memasukkan seluruh spesifikasi desain dan menerima representasi baru per token memakan waktu beberapa menit, sehingga tidak praktis
- Representasi yang dikembalikan LLM bukan bentuk yang dibaca manusia, sehingga status loading pun mendekati spinner sederhana, dan pengalaman pengguna menjadi kurang baik
Fine-tuning saja tidak cukup untuk kustomisasi yang memadai
- LLM mendukung fine-tuning, sehingga dapat sedikit disesuaikan agar lebih mendekati arah yang diinginkan
- Builder menerapkan fine-tuning pada pendekatan yang memasukkan desain Figma sebagai input dan mengeluarkan kode sebagai output, tetapi kualitasnya tidak membaik meski banyak contoh diberikan
- Akibatnya, pendekatan tersebut menjadi lambat, mahal, dan kualitasnya rendah, sehingga diperlukan cara lain
- Alternatif yang dipilih adalah membuat toolchain internal
- LLM yang di-fine-tune
- Compiler kustom yang ditulis sendiri
- Model yang dilatih sendiri
- Kini melatih model sendiri bukan lagi sesuatu yang hanya bisa dilakukan data scientist atau Ph.D. machine learning; developer dengan pengalaman yang memadai juga bisa melakukannya
- Pendekatan ini membantu membuat produk yang lebih cepat, andal, lebih murah, dan terdiferensiasi
Produk AI kompleks tersusun dari toolchain, bukan satu model raksasa
- Kesalahpahaman umum tentang produk AI adalah mengira teknologi intinya ditangani seluruhnya oleh satu model pintar
- Mobil otonom juga bukan struktur tempat satu AI raksasa menerima input kamera, sensor, dan GPS lalu langsung mengeluarkan tindakan seperti belok kanan
- Pada praktiknya, beberapa model khusus dan kode biasa saling terhubung
- Model computer vision menemukan dan mengidentifikasi objek
- Model pengambilan keputusan prediktif memperkirakan perilaku orang lain
- Model natural language processing memahami perintah suara
- Banyak kode dan logika biasa menghasilkan hasil akhir
- Mobil otonom adalah contoh yang jauh lebih kompleks, dan saat memulai produk AI umum, tingkat kompleksitas seperti itu tidak diperlukan
- Fitur mobil pun tidak selesai sekaligus; dimulai dari fitur seperti parkir otomatis dan pengereman otomatis saat dekat objek, lalu lapisan ditambahkan hingga koreksi keluar jalur dan pengambilan keputusan berkendara penuh
- Sama seperti software, fitur AI juga dibuat dengan menumpuk lapisan berikutnya di atas lapisan sebelumnya
Selesaikan dulu dengan kode biasa, lalu tambahkan AI khusus hanya di tempat yang perlu
- Titik awal penting dalam pendekatan Visual Copilot adalah tidak menggunakan AI sejak awal
- Ruang masalah perlu dieksplorasi dengan cara pemrograman biasa, dan lebih dulu menemukan area mana yang benar-benar membutuhkan model khusus
- Pendekatan “supermodel” yang memasukkan data Figma dalam jumlah besar ke model lalu langsung menerima kode final terlalu kompleks
- Framework yang harus didukung beragam
- Ada banyak opsi styling dan kustomisasi
- Sulit terus melatih ulang untuk mencerminkan data baru
- Bisa menjadi rumit, lambat, dan mahal sehingga peluncuran produk itu sendiri sulit dilakukan
- Builder lebih dulu mengeksplorasi sejauh mana mereka bisa berjalan tanpa AI
- Setiap node desain harus diubah menjadi objek yang dapat direpresentasikan sebagai kode
- Elemen seperti gambar, latar belakang, dan foreground harus dipahami secara detail
- Cara membuat input apa pun menjadi responsif harus ditangani secara cermat
- Mereka membuat berbagai algoritme canggih dengan logika yang ditulis tangan, misalnya menangani item yang tersusun vertikal sebagai flex column dan item yang berdampingan sebagai flex row
- AI ditambahkan pada titik ketika batas kode standar tercapai
- Masalah mendeteksi otomatis layer mana yang harus digabung menjadi satu gambar mudah bagi persepsi manusia, tetapi tidak mudah dengan kode JavaScript imperatif
- Jenis model yang sudah mapan seperti object detection dapat dilatih di produk seperti Google Vertex AI dengan memilihnya lewat GUI, menyiapkan data, lalu mengunggahnya
- Internet dapat dimanfaatkan untuk membuat data
- Membuka situs web di browser dengan puppeteer dan mengambil screenshot
- Menelusuri HTML untuk menemukan tag
img - Menggunakan posisi gambar sebagai data output dan screenshot halaman web sebagai data input
- Dengan cara ini, koordinat sub-gambar dan gambar asal diperoleh dan digunakan sebagai data pelatihan model object detection
- Dengan menggabungkan kode dan model AI khusus, pengguna dapat memilih desain, mengklik Generate code, lalu menunggu sekitar 1 detik sebelum berpindah ke Builder.io
- Di Builder, pengguna bisa mendapatkan situs web yang sepenuhnya responsif dan kode berkualitas tinggi yang dapat dikustomisasi, dengan dukungan untuk berbagai framework dan opsi
Keuntungan produk saat mengendalikan model sendiri
- Dengan memiliki model sendiri, perusahaan tidak berhenti sekadar membungkus model eksternal, tetapi dapat terus meningkatkan modelnya
- Jika hanya bergantung pada model eksternal seperti OpenAI, tidak ada jaminan kapan model tersebut akan menjadi lebih pintar, lebih cepat, atau lebih murah untuk kasus penggunaan tertentu
- Rentang yang dapat dikendalikan hanya dengan prompt engineering dan fine-tuning juga terbatas
- Visual Copilot masih dalam status beta, sehingga masih ada desain yang belum dapat diimpor dengan baik, dan peningkatan diterapkan setiap hari berdasarkan masukan pengguna
- Mengendalikan teknologi sendiri juga membantu memenuhi kebutuhan privasi dengan lebih baik
- Perusahaan besar yang berfokus pada privasi sering memberi masukan bahwa mereka tidak dapat menggunakan OpenAI atau produk yang menggunakan OpenAI
- Ada kebutuhan agar data tidak masuk ke sistem yang tidak diizinkan
- Karena Builder mengendalikan seluruh teknologinya, mereka dapat menerapkan standar privasi yang tinggi
- Tahap LLM bukan sesuatu yang wajib, melainkan lebih seperti opsi, sehingga dapat dimatikan
- Perusahaan juga dapat menghubungkan LLM mereka sendiri
- Model internal sepenuhnya
- Fork
llama2 - Instance enterprise OpenAI sendiri
- Model lain apa pun
- AI sebaiknya digunakan sesedikit mungkin, sementara kode biasa tetap menjadi fondasi yang cepat, andal, deterministik, serta mudah di-debug, diperbaiki, dikelola, dan diuji
- Keajaiban produk bukan muncul dari mengganti semuanya dengan AI, melainkan dari penggunaan model AI pada area kecil tetapi menentukan
1 komentar
Pendapat Hacker News
Saya setuju dengan arah umum tulisan ini, tetapi sepertinya saya tidak akan memilih cara implementasi yang disarankan penulis
Kesimpulan yang saya ambil adalah jangan terlalu bergantung pada LLM. Itu berlaku baik untuk cakupan tugas yang diserahkan kepadanya, maupun untuk menghindari terikat pada satu LLM tertentu
Misalnya, meskipun memakai OpenAI secara internal, produk yang bersaing langsung dengan ChatGPT bisa jadi tidak menguntungkan dalam jangka panjang. Jika membuat aplikasi untuk memesan hotel dan tiket pesawat lewat chatbot, suatu hari ChatGPT, Microsoft, atau Google kemungkinan akan menyediakan fitur serupa dengan lebih baik dan melumpuhkan bisnis kecil
Terlalu bergantung pada sesuatu seperti OpenAI SDK juga menurut saya membuang waktu; memanggil REST API secara langsung lebih fleksibel
Namun menambahkan compiler ke toolchain adalah persoalan berbeda. Setiap kali memasukkan compiler, kompleksitas yang tidak perlu dan ketergantungan pada alat tertentu makin besar. Jika React atau Svelte sudah cukup, memakai cross-compiler komponen terasa seperti menambah satu hal lagi yang harus dipelajari hanya untuk membuat aplikasi web
Menurut saya pesan akhirnya seharusnya adalah “buat toolchain yang paling efisien untuk mencapai tujuan”. Nilai tidak muncul hanya karena menempelkan banyak alat, dan juga tidak muncul karena mengikuti cara yang dilakukan orang lain; ini berlaku bukan hanya untuk integrasi aplikasi LLM, tetapi juga untuk rekayasa perangkat lunak secara umum
Saya tidak begitu paham bagaimana AI akan membuatnya berbeda, atau apakah pada akhirnya tidak akan terbentur batasan yang sama
Itu memang unik dan tidak mudah ditiru, tetapi jika mempertimbangkan bahasa yang didukung, biaya pemeliharaannya akan sangat besar
Lapisan abstraksi tambahan ini agak terasa seperti factory-factory-factory
Justru AI punya ruang yang lebih besar untuk spesialisasi dibanding pencarian tiket pesawat
Untuk chatbot tugas khusus, sekarang setelah pemahaman bahasa dasar sudah cukup baik, kualitas model bahasa serbaguna bukanlah faktor terpenting. Chatbot pemesanan perjalanan yang disesuaikan dengan preferensi saya dan terintegrasi dengan API-API niche yang relevan tidak akan mudah dikalahkan oleh alat serbaguna yang sedikit lebih baik dalam mem-parsing pertanyaan tetapi mencoba memesan semuanya lewat Expedia
Di pasar seperti ini, satu rekomendasi yang bagus atau buruk saja bisa memunculkan loyalitas merek atau penolakan, sehingga sulit juga menyebutnya mendekati winner-takes-all
Inti tulisan blog itu sebenarnya bukan di sana
Produk mereka adalah alat yang otomatis mengubah file desain Figma menjadi kode React. Cara menyelesaikan masalah ini dengan kode biasa memang adalah compiler
Mereka tidak mengatakan semua orang harus memakai compiler
Dalam konteks ini, kritik terhadap compiler secara umum kurang tepat. Alternatifnya adalah memakai ChatGPT seperti compiler, dan tulisan itu cukup meyakinkan bahwa cara tersebut lebih buruk. Atau apakah maksudnya produk yang menghasilkan kode React itu sendiri buruk, saya jadi penasaran
Tulisan ini memberi bahan untuk dipikirkan, dan saya setuju dengan intinya: “jangan memakai AI selama masih bisa dihindari”
AI paling baik digunakan untuk hal-hal yang hanya mungkin dilakukan dengan AI. Jika ada cara membuat fitur atau menyelesaikan masalah tanpa AI, lebih baik lakukan cara itu
Kini semua orang punya akses yang hampir sama ke model-model terbaik, jadi produk yang bagus pada akhirnya harus ditentukan oleh hal-hal non-AI, yaitu unsur klasik seperti workflow, UI, pengalaman pengguna, dan performa
Namun saya tidak yakin dengan saran “latih model sendiri”. Itu bisa menjadi jalan yang membuat produk cepat usang. Mungkin bisa menjadi pembeda sesaat, tetapi jika dalam 6–12 bulan OpenAI atau pesaing dengan pendanaan besar merilis model yang jauh lebih baik, model yang terdiferensiasi itu langsung menjadi utang teknis
Startup kecil yang mencoba bersaing lewat model tampak seperti distraksi besar. Mirip dengan membuat database sendiri alih-alih memakai Postgres atau MySQL. Tentu saja perlu moat dan produk yang sulit ditiru, tetapi itu harus berada di area yang secara realistis bisa menjadi yang terbaik dengan sumber daya yang dimiliki
Lalu ChatGPT muncul, dan pekerjaan para pesaing itu seketika menjadi usang, sementara dia bisa mengejar fitur AI dalam hitungan minggu
Ia benar soal apa yang harus dibangun, tetapi salah soal alasannya, dan hasilnya menjadi keuntungan besar bagi bisnisnya
Diferensiasi sebenarnya faktor yang cukup penting
Ini tulisan yang bagus, dan sepertinya akan relevan bagi sebagian besar startup AI baru. Saran saya adalah jangan membuat produk AI sama sekali
Kerangka “produk X” jarang mengarah pada penambahan nilai bagi pelanggan. Misalnya produk web3, produk observability, produk machine vision, produk AI, dan seterusnya
Seperti semua ide startup yang baik, intinya adalah berangkat dari kebutuhan pengguna nyata, bukan memaksakan masalah agar cocok dengan teknologi baru yang ingin dipakai. Menempelkan UI pada teknologi yang sedang dibesar-besarkan tidak otomatis memenuhi kebutuhan pengguna
Saya mengatakan ini bukan karena membenci LLM, tetapi kebanyakan orang yang saya kenal secara offline tidak suka berinteraksi dengan chatbot sebagai produk. Baru-baru ini saat pindah rumah, saya harus berurusan dengan bot dukungan pelanggan dari penyedia energi, air, dan internet, dan semuanya mengerikan
Menurut saya, berangkat dari “GPT itu keren” lalu membuat chatbot kustom sulit untuk benar-benar menyelesaikan kebutuhan pengguna atau menjadi bisnis yang berkelanjutan
Bahkan menemukan masalah yang cukup nyata untuk membenarkan biaya teknologi saja berada di luar zona nyaman banyak teknisi. Kita berasumsi masalahnya nyata, atau lebih buruk lagi, berharap masalahnya nyata, lalu langsung terjun ke solusi. Karena membangun adalah wilayah yang kita kenal
Sikap atau proses seperti ini sendiri tidak selalu salah. Dalam banyak kasus ketika teknisi memecahkan masalah nyata, masalah nyata itu muncul secara kebetulan dalam proses membangun, mengiterasi, dan menghentikan
Jadi bagi teknisi, cara terbaik menemukan masalah nyata mungkin bukan berlama-lama di fase penemuan masalah, melainkan memiliki siklus rilis-iterasi-penghentian yang lebih baik. Siklus untuk melihat penggunaan saat ini, memperkirakan masa depan, dan cepat memutuskan apa yang tidak perlu dibangun
Setelah membaca biografi beberapa pemimpin teknologi, saya mulai melihat bahwa kemampuan inti yang membedakan mereka adalah memulai dari MVP yang sangat mendasar lalu, dalam waktu singkat, mengasah intuisi tentang permintaan masa depan secara eksponensial
Beberapa tahun lalu pun chatbot sudah ada, dan hampir semua perusahaan besar menyusun strategi untuknya. Idenya adalah mengurangi staf call center secara besar-besaran dan meningkatkan pengalaman pelanggan
Masalahnya bukan hanya kualitas percakapan. Bagi banyak pengguna, yang penting bukan sekadar mendapatkan jawaban atas masalah, tetapi juga rasa koneksi manusiawi bahwa ada seseorang yang mendengarkan
Yang saya inginkan adalah urusan ditangani secepat mungkin; apakah saya berbicara dengan manusia sungguhan tidak terlalu penting
Alasan chatbot sejauh ini tidak membantu adalah karena justru menambah waktu dan rasa kesal dalam proses. Langkah pertamanya adalah membuat chatbot memuntahkan nomor telepon atau susah payah menghubungkan ke agen
Tentu saja chatbot sebelum OpenAI memang buruk. Tetapi jika chatbot setelah OpenAI benar-benar hebat, saya tidak melihat alasan orang tidak akan memakainya
Beberapa tahun lalu itu blockchain. Saya tidak tahu berikutnya apa, tetapi sudah terlihat jaringan “teknisi” di LinkedIn berpindah dari startup kripto ke startup AI
Ini terlihat seperti pilihan yang sangat mengorbankan kecepatan peluncuran
Saat Anda meluncur setelah 6–12 bulan, tim lain mungkin sudah memakai model hosted secara langsung, melakukan iterasi dua kali, dan membangun basis pelanggan nyata. Saat itu Anda menunjukkan v0.1 kepada pelanggan pertama, dan pelanggan bisa mengatakan bahwa sebenarnya mereka menginginkan hal lain
Lalu yang harus diubah bukan sekadar sedikit mengutak-atik prompt, melainkan mengode ulang compiler dan toolchain, dari atas sampai bawah stack
Jika Anda benar-benar memahami pelanggan dan kebutuhannya, ini bisa masuk akal. Tetapi dalam situasi yang semudah ini, saya lebih skeptis mengapa tidak memvalidasi konsep lebih awal dengan model hosted, meskipun generik dan mahal. Ini seperti persoalan optimasi prematur sebagai akar dari segala kejahatan
Ada banyak pembahasan tentang teknologi dan pipeline, tetapi tanpa produk yang akan dibuat dan masalah yang akan dipecahkan, semuanya tidak berarti
Ini mirip berdebat kepada pengguna apakah SOAP atau REST lebih baik. Pengguna tidak peduli bagaimana Anda membuatnya
Dari sudut pandang persaingan, ini terlalu dipikirkan berlebihan. Buat saja sesuatu yang tidak mudah ditiru
Ada banyak cara, tetapi dari sudut pandang persaingan, aturan yang diperlukan hanya itu
Di hampir semua pasar vertikal, hampir 100% dari total pasar masih terbuka
Diferensiasi teknis hanyalah bagian kecil; menurut saya yang lebih penting terlebih dahulu adalah jangkauan
Ini perlombaan menuju 1 miliar pengguna, dan untuk B2B seperti kami mungkin perlombaan menuju 1 juta pengguna. Pada saat yang sama, ini adalah perlombaan untuk nilai terbaik, yaitu masalah yang diselesaikan dan pengalaman pengguna, bukan perlombaan spesifikasi teknis terbaik
Jika pembeda Anda adalah sesuatu yang tidak bisa ditiru orang lain dengan memakai OAI, maka aman memakai OAI
Jika satu-satunya pembeda Anda hanyalah memakai OAI, Anda memang sudah gagal sejak awal
Secara umum saya setuju dengan keadaan yang disimpulkan. Produk kami juga memakai LLM di dalam alur kontrol seperti state machine, dan itu bekerja dengan baik
Namun saya tidak setuju dengan sentimen penulis. Jika Anda developer yang hanya pernah memakai UI web ChatGPT, Anda 100% perlu mencoba dan membuat teknologi “AI wrapper” sendiri
Sebab sebelum menemukan sendiri batasan model kelas atas, sulit melihat di mana dan bagaimana LLM sebaiknya dipakai di dalam stack perangkat lunak tradisional
Perusahaan penulis pun tampaknya pada akhirnya menempuh jalan ini. Awalnya mereka membuat prototipe berbasis LLM yang mengubah Figma menjadi kode, dan setelah itu bekerja “sampai tingkat tertentu”, mereka menemukan celah dalam prosesnya
Jadi menurut saya lebih baik buat saja apa pun yang Anda inginkan dengan sesuatu seperti GPT-4-Vision, entah “sistem penilaian kartu trading berbasis AI” atau lainnya, lalu setelah itu cari cara membuatnya berfungsi sebagai produk nyata seperti builder.io
Sepertinya AI akan segera tertanam di berbagai perangkat lunak. Saat itu, semuanya akan menjadi benar-benar keren sekaligus menakutkan
Contoh sederhananya adalah klien email. Jika seseorang meminta keputusan atau konfirmasi, AI bisa mengekstrak pertanyaannya dan menampilkan tombol radio
Contoh: Terima jadwal janji yang diusulkan: [Jumat 10:00] [Senin 11:30] [Usulkan waktu lain]
George menanyakan apakah ia bisa mempresentasikan draf: [Ya] [Tidak]
Perangkat lunak tiket dukungan pelanggan seperti Zendesk tampaknya sudah memiliki AI. Besar kemungkinan banyak permintaan dukungan sudah dijawab hampir secara otomatis
Departemen HR juga bisa menggunakan AI untuk menyaring lamaran kerja, menelusuri informasi tambahan tentang kandidat di internet, lalu membuat entri database yang terstandardisasi. Tentu saja, ini bisa sangat banyak cacatnya
Yang menarik adalah aplikasi semacam ini, bukan ekstensi atau plugin ChatGPT lainnya
Untuk setiap email baru, saya ingin menjalankan pipeline agar menyarankan beberapa tindakan
Saya masih memutar beberapa pendekatan di kepala, tetapi ini sudah tampak cukup memungkinkan
Pembuka tulisannya terasa agak terlalu berbunga-bunga dan berlebihan. Misalnya, LLM tidak semahal itu, klaim WSJ bahwa Copilot merugi per pengguna tidak terlalu meyakinkan, dan sulit juga mengatakan LLM selalu “menyakitkan lambat”
Meski begitu, rekomendasi inti artikelnya cukup masuk akal
Yaitu menangani sebanyak mungkin bagian dengan kode, dan memakai AI terspesialisasi untuk bagian yang tidak bisa dilakukan dengan kode
Masuk akal, tetapi bukan hal yang khususnya baru
Saya berharap tulisannya membahas lebih dalam bagaimana membuat produk AI yang benar-benar berguna dan bagus. Ada banyak upaya seperti peluncuran Humane baru-baru ini, tetapi tampaknya belum banyak yang sukses
Artikel ini cukup berfokus pada bagaimana membangun produk AI, tetapi secara pribadi saya melihat keberhasilan dan kegagalan “produk AI” lebih bergantung pada apakah produk itu benar-benar berguna, ketimbang diferensiasi, biaya, kecepatan, atau penyesuaian model
Sayangnya, sebagian besar produk yang saya lihat sejauh ini terasa seperti solusi yang sedang mencari masalah
Menurut saya, jalan yang seharusnya ditempuh perusahaan saat ini adalah menemukan bagian paling membosankan dan repetitif saat menggunakan produk, lalu mencari cara untuk menyederhanakannya secara andal dengan AI
Seperti semua siklus hype, jika yang Anda punya hanya palu, semua hal tampak seperti paku
Beberapa waktu lalu palunya adalah blockchain, sekarang AI
Jika Anda cukup naif untuk tertipu janji blockchain, wajar saja jika Anda kecewa bahwa AI bukan skema piramida cepat kaya yang membuat Anda memperoleh jutaan dolar tanpa waktu, energi, atau pemikiran orisinal
Kalau hanya itu yang Anda cari, Anda akan terus kecewa, dan memang pantas begitu
AI punya jauh lebih banyak hal dibanding blockchain. Membandingkan keduanya sebagai setara berarti Anda tidak benar-benar memahami salah satunya