https://medium.com/data-science-collective/how-i-b...

Artikel ini bahas workflow end-to-end membangun project AI dari nol sampai jadi project yang benar-benar bisa dipakai, bukan cuma tutorial “panggil API LLM lalu selesai”.

Penulisnya, Marina Wyss, memakai contoh project bernama ShelfScanner: user foto rak buku, sistem AI membaca judul-judul buku di foto, lalu merekomendasikan buku berdasarkan selera user. Dari project itu dia menjelaskan bagaimana dia membuat AI product secara sistematis. (Marina Wyss)

Garis besarnya begini:

1. Tentukan dulu kenapa project itu dibuat. Bisa untuk belajar, portfolio cari kerja, atau benar-benar mencari user. Standar project-nya akan berbeda tergantung tujuan. (Marina Wyss)
2. Mulai dari problem, jangan dari teknologi. Jangan mulai dengan “gue mau bikin RAG/agent”. Cari masalah yang memang kamu pahami, baru tentukan apakah butuh LLM, vision model, RAG, agent, dll. (Marina Wyss)
3. Scope project sebelum coding. Tentukan siapa user-nya, input/output, constraint, data, latency, biaya, success metric, bahkan pertanyaan penting: “apakah masalah ini memang perlu AI?” (Marina Wyss)
4. Pakai AI coding assistant dengan spec-driven development. Claude/AI tidak langsung disuruh “build semuanya”. Setiap fitur dibuatkan proposal/spec dulu: apa yang berubah, asumsi apa yang dipakai, bagaimana implementasinya. Manusia tetap membuat keputusan engineering. (Marina Wyss)
5. Siapkan fondasi engineering. Database/storage, API keys, .env, environment Python, repo structure, dan sebagainya. Dalam contoh dia menggunakan Supabase. (Marina Wyss)
6. MVP = eksperimen untuk menjawab risiko terbesar. Bukan “versi jelek dari seluruh aplikasi”. ShelfScanner awalnya cuma script CLI untuk mengecek dua pertanyaan: vision model bisa baca buku dari foto atau tidak, dan model bisa memberi rekomendasi yang bagus atau tidak. (Marina Wyss)
7. Log setiap eksperimen AI. Model apa, prompt apa, output-nya apa, latency, cost, failure, dll. Jadi pemilihan model tidak berdasarkan feeling. (Marina Wyss)
8. Bangun bertahap dan kerjakan bagian paling berisiko dulu. Jangan habiskan waktu bikin UI cantik kalau belum tahu core AI-nya bekerja. (Marina Wyss)
9. Testing AI berbeda dengan testing software biasa. Selain unit/integration test, dia membuat AI evaluation set berisi data yang sudah dilabeli untuk mengukur apakah perubahan prompt/model menyebabkan improvement atau regression. (Marina Wyss)
10. Deploy, monitor, lalu cari real users. Setelah stabil, deploy aplikasinya, monitor model calls, kemudian dokumentasikan architecture, trade-off, keputusan engineering, dan hasil eksperimen supaya portfolio menunjukkan cara berpikirnya—bukan hanya UI aplikasi. (Marina Wyss)

Menurutku ide paling penting dari artikel ini adalah:

Jangan biarkan AI menjadi engineer yang mengambil semua keputusan. AI dipakai untuk mempercepat implementasi, sementara kamu tetap menentukan problem, architecture, assumptions, experiments, dan evaluation.

Dan ada satu prinsip lain yang cukup kuat: jangan memaksakan RAG, agent, fine-tuning, atau teknologi AI lain hanya agar project terlihat canggih. ShelfScanner misalnya akhirnya tidak menggunakan RAG, agent, maupun fine-tuning karena problem-nya memang tidak membutuhkan itu. (Marina Wyss)

Kalau diterjemahkan menjadi flow sederhana:

Problem → Scope → Spec → MVP experiment → Evaluate → Update design → Build in phases → Test → Monitor → Deploy → Real users → Portfolio

Jadi ini sebenarnya artikel yang bagus kalau targetmu adalah belajar cara berpikir seperti AI Engineer/Product Engineer, bukan sekadar belajar prompt atau coding dengan Claude.