Istilah AI engineer semakin sering dipakai, tapi maknanya sering terlalu luas. Kadang yang dimaksud adalah orang yang membangun aplikasi dengan LLM. Kadang yang dimaksud adalah orang yang melatih model. Dua-duanya valid, tapi pekerjaannya sangat berbeda.
Menurut kami, ada dua jalur besar yang perlu dibedakan:
- Mengimplementasikan LLM ke dalam harness
- Membangun model dan melakukan training
Keduanya sama-sama penting. Namun skill, tools, cara berpikir, dan output pekerjaannya tidak sama.
Path 1: Mengimplementasikan LLM ke dalam harness
Ini adalah jalur yang paling dekat dengan software engineering dan product engineering.
Di jalur ini, tugas utama AI engineer bukan membuat model dari nol. Tugasnya adalah mengambil model yang sudah tersedia, lalu membungkusnya ke dalam sistem yang benar-benar bisa dipakai user.
Kata kuncinya adalah harness.
Harness adalah seluruh lapisan product dan engineering yang membuat LLM bisa bekerja dengan aman, konsisten, dan berguna di aplikasi nyata. Model hanya satu bagian. Di sekelilingnya ada banyak pekerjaan:
- prompt dan instruction design
- retrieval-augmented generation atau RAG
- tool calling
- structured output
- UI untuk streaming response
- memory dan state management
- permission dan approval flow
- logging dan observability
- evaluation
- fallback dan error handling
- cost control
- deployment
OpenAI sendiri menempatkan evaluasi sebagai bagian penting untuk menguji performa aplikasi LLM di production. Google Cloud juga menjelaskan bahwa pengembangan generative AI application sering melibatkan prompt design, RAG, tuning, deployment, dan operasi aplikasi, bukan hanya pemanggilan model.
Di dunia nyata, banyak problem AI product justru tidak selesai dengan model yang lebih pintar. Problemnya sering berada di harness:
- context yang diberikan ke model kurang tepat
- retrieval mengambil dokumen yang salah
- tool call terlalu bebas
- output tidak bisa divalidasi
- latency terlalu tinggi
- biaya inference tidak terkendali
- user interface tidak menjelaskan apa yang sedang terjadi
- tidak ada eval untuk mencegah regression
Jadi AI engineer di path ini perlu kuat di software engineering. Ia perlu paham API, database, frontend state, backend workflow, product requirement, testing, dan deployment. LLM adalah komponen penting, tapi bukan satu-satunya komponen.
Jalur ini cocok untuk orang yang ingin membangun:
- AI assistant untuk internal tools
- chatbot dengan akses ke knowledge base
- document analysis workflow
- customer support automation
- coding assistant untuk domain tertentu
- agent yang bisa memakai tools
- product feature yang memakai model sebagai salah satu engine
Output akhirnya adalah aplikasi, workflow, atau sistem yang bisa dipakai.
Path 2: Membangun model dan melakukan training
Jalur kedua lebih dekat dengan machine learning engineering dan research engineering.
Di sini fokusnya bukan membungkus model yang sudah ada ke dalam product. Fokusnya adalah membuat model menjadi lebih mampu, lebih efisien, atau lebih cocok untuk domain tertentu.
Pekerjaannya bisa mencakup:
- mengumpulkan dan membersihkan dataset
- merancang data pipeline
- memilih model architecture atau pretrained checkpoint
- melakukan supervised fine-tuning
- preference tuning atau reinforcement learning
- model evaluation dan benchmark
- distributed training
- GPU infrastructure
- inference optimization
- quantization
- model serving
- monitoring model drift
OpenAI menjelaskan supervised fine-tuning sebagai proses melatih model dengan contoh untuk use case tertentu. Hugging Face juga menjelaskan fine-tuning sebagai kelanjutan training dari pretrained model pada dataset yang lebih kecil dan spesifik untuk task atau domain tertentu.
Ini pekerjaan yang lebih dalam ke sisi model. Bahasa yang sering dipakai bukan hanya TypeScript atau application framework, tapi juga Python, PyTorch, Transformers, CUDA, distributed systems, experiment tracking, dan statistik.
Jalur ini cocok untuk orang yang ingin membangun:
- model domain-specific
- classifier atau embedding model khusus
- fine-tuned LLM untuk gaya atau format tertentu
- model yang lebih kecil dan murah untuk inference
- model yang berjalan di edge device
- research prototype untuk architecture atau training method baru
Output akhirnya adalah model, checkpoint, training pipeline, atau serving system.
Perbedaannya bukan mana yang lebih tinggi
Kesalahan yang sering terjadi adalah menganggap path kedua lebih “asli” karena berhubungan langsung dengan model training, sementara path pertama dianggap hanya memakai API.
Menurut kami itu framing yang kurang tepat.
Membangun product harness di atas LLM bukan pekerjaan sederhana. Semakin kuat modelnya, semakin besar juga ekspektasi user terhadap reliability, latency, UX, privacy, cost, dan safety. Semua itu adalah problem engineering yang nyata.
Sebaliknya, model training juga bukan sekadar menjalankan script fine-tuning. Training yang baik membutuhkan pemahaman data, evaluasi, failure mode, infrastructure, dan trade-off antara kualitas, biaya, dan maintainability.
Keduanya adalah engineering. Hanya titik beratnya berbeda.
”Berarti cuma LLM wrapper?”
Komentar yang sering muncul untuk path pertama adalah: “Berarti cuma bikin wrapper di atas LLM? Itu gampang.”
Ada bagian yang benar dari komentar itu. Kalau yang dibuat hanya form input, tombol submit, lalu response dari model ditampilkan ke layar, itu memang wrapper tipis. Dan untuk demo sederhana, pekerjaan seperti itu bisa selesai sangat cepat.
Tapi product harness yang serius bukan berhenti di sana.
Perbedaannya biasanya baru terasa ketika aplikasi dipakai oleh user sungguhan:
- Bagaimana memastikan model hanya menjawab dari data yang boleh diakses user?
- Bagaimana mendeteksi retrieval yang salah sebelum jawaban dikirim?
- Bagaimana membuat tool calling tidak menjalankan aksi berbahaya?
- Bagaimana menjaga output tetap sesuai schema ketika model sedang tidak konsisten?
- Bagaimana mengevaluasi kualitas jawaban setiap kali prompt, model, atau data berubah?
- Bagaimana mengatur latency, retry, fallback, dan cost ketika traffic naik?
- Bagaimana membuat UI menjelaskan state: sedang mencari data, menjalankan tool, gagal, atau butuh approval?
- Bagaimana melakukan logging tanpa membocorkan data sensitif?
Di titik itu, “wrapper” berubah menjadi sistem.
Thin wrapper hanya membungkus API call. Product harness mengatur konteks, data, tool, state, permission, eval, observability, dan deployment agar model bisa menjadi bagian dari produk yang reliable.
Jadi kritik “cuma LLM wrapper” berguna sebagai pengingat. Jangan berhenti di demo. Jangan menganggap satu API call sudah cukup untuk disebut AI product. Tapi kritik itu juga tidak cukup untuk meremehkan path pertama, karena pekerjaan sebenarnya justru dimulai setelah wrapper paling sederhana berhasil dibuat.
Cara memilih jalur
Kalau kamu lebih suka membangun produk, berinteraksi dengan user problem, merancang UI, menyusun workflow, dan membuat sistem yang dipakai langsung, kamu kemungkinan lebih cocok mulai dari path pertama: LLM application harness.
Kalau kamu lebih suka data, eksperimen, model behavior, training loop, paper, benchmark, dan infrastruktur komputasi, kamu kemungkinan lebih cocok mengejar path kedua: model building and training.
Tidak harus memilih selamanya. Banyak engineer yang memulai dari application harness, lalu pelan-pelan masuk ke fine-tuning dan model evaluation. Ada juga yang datang dari machine learning, lalu belajar product engineering agar model yang mereka bangun benar-benar terpakai.
Namun untuk belajar, membedakan dua jalur ini penting. Tanpa pemisahan ini, orang sering merasa harus menguasai semuanya sekaligus: frontend, backend, prompt engineering, RAG, PyTorch, CUDA, RLHF, deployment, dan research paper. Itu terlalu luas untuk langkah awal.
Posisi Devscale
Untuk program publik Devscale, fokus kami ada di path pertama: mengimplementasikan LLM ke dalam full-stack product harness.
Artinya, kami ingin siswa belajar bagaimana membangun aplikasi yang memakai AI secara nyata:
- frontend yang bisa menampilkan AI interaction dengan baik
- backend yang typed dan maintainable
- database dan schema yang jelas
- integration dengan AI SDK
- tool calling dan workflow automation
- RAG dan document ingestion
- evaluation untuk menjaga kualitas
- deployment dan production workflow
Kami tidak sedang membangun program model training dari nol. Bukan karena jalur itu tidak penting, tapi karena ia membutuhkan fokus kurikulum yang berbeda.
Untuk mayoritas builder yang ingin membuat AI product, path pertama adalah titik mulai yang lebih langsung. Kamu bisa memakai model terbaik yang tersedia hari ini, lalu belajar membangun sistem yang membuat model itu benar-benar berguna.
Penutup
AI engineer bukan satu pekerjaan tunggal. Ada engineer yang membuat model, dan ada engineer yang membuat model menjadi produk.
Keduanya dibutuhkan.
Namun kalau tujuanmu adalah membangun aplikasi, internal tools, SaaS, agent workflow, atau AI feature yang benar-benar dipakai user, jangan merasa harus mulai dari training model. Mulailah dari harness: product surface, data flow, tools, evals, dan deployment.
Karena di sanalah banyak pekerjaan AI engineering hari ini benar-benar terjadi.