Belajar AI #1: Sejarah AI — dari Turing Test (1950) sampai ChatGPT (2022)

Hari ini saya mulai seri baru: Belajar AI. Sebagai programmer yang sehari-hari menulis kode, saya merasa perlu memahami teori di baliknya — bukan sekadar memakai API. Dan saya memutuskan mulai dari awal: sejarah. Bukan karena nostalgia, tapi karena sejarah menjelaskan satu hal yang sering membingungkan saya: kenapa AI sempat “mati” dua kali, lalu bangkit lagi dan sekarang ada di mana-mana. Mari kita telusuri.

Timeline sejarah AI dari Turing Test 1950 hingga ChatGPT 2022
Timeline sejarah AI: dari Turing Test (1950) sampai ChatGPT (2022). Saya buat dengan Python PIL sebagai catatan visual.

1950: Turing Test — titik tolak

Alan Turing, matematikawan asal Inggris, menerbitkan paper berjudul “Computing Machinery and Intelligence” di jurnal Mind tahun 1950. Pertanyaannya sederhana: can machines think? Tapi karena “berpikir” terlalu kabur untuk diuji, Turing menggantinya dengan permainan imitasi: seorang pemeriksa mengobrol dengan mesin dan manusia melalui teks. Kalau pemeriksa tidak bisa membedakan mana mesin mana manusia, mesin itu dianggap lolos uji kecerdasan.

Dari sudut pandang programmer, Turing Test itu seperti unit test yang kasar: kita tidak mengukur cara kerja dalamnya, hanya hasil luarnya. Mesin boleh diimplementasikan dengan cara apa pun — yang penting outputnya tidak bisa dibedakan dari manusia. Konsep ini penting karena menanamkan pola pikir “kecerdasan bisa dinilai dari perilaku”, bukan dari jiwa atau kesadaran.

1956: Konferensi Dartmouth — lahirnya nama “AI”

Enam tahun kemudian, John McCarthy mengusulkan sebuah workshop musim panas di Dartmouth College, Amerika Serikat. Para pesertanya adalah tokoh yang kelak menjadi bapak pendiri AI: McCarthy, Marvin Minsky, Claude Shannon, dan Nathaniel Rochester. Di konferensi inilah istilah artificial intelligence pertama kali dicetuskan, dan AI resmi menjadi bidang riset.

Yang menarik: optimisme saat itu sangat tinggi. Mereka memperkirakan masalah AI bisa diselesaikan dalam satu generasi. Setelah konferensi, muncul beberapa hasil awal yang menjanjikan — Frank Rosenblatt membuat perceptron (neuron buatan sederhana) tahun 1958, dan Joseph Weizenbaum membuat chatbot ELIZA tahun 1966 yang bisa “ngobrol” ala terapis. Tapi dari kejauhan, saya melihat pola yang sama dengan hype teknologi sekarang: ekspektasi melampaui kenyataan.

Dua musim dingin: AI winter

Janji besar tanpa hasil yang konsisten membuat pendanaan riset AI membeku dua kali. Para sejarawan menyebut periode ini AI winter:

  • 1974–1980 (AI winter pertama): laporan Lighthill di Inggris tahun 1973 mengkritik habis-habisan capaian AI, pendanaan pemerintah dan industri menyusut drastis.
  • 1980-an (kebangkitan sistem pakar): expert systems — program berisi aturan if-then yang ditulis manual oleh ahli — dipakai di industri, misalnya untuk diagnosis dan konfigurasi. Populer, tapi mahal dan rapuh: aturan tidak bisa menangani kasus di luar yang tertulis.
  • 1987–1993 (AI winter kedua): pasar komputer LISP (bahasa favorit riset AI) runtuh, proyek sistem pakar ditinggalkan satu per satu.

Bagi saya ini pelajaran berharga: AI berbasis aturan yang ditulis tangan tidak pernah benar-benar “belajar”. Ia sekuat pengetahuan yang dimasukkan manusia, dan rapuh di luar domain itu. Paradigma inilah yang akhirnya digantikan oleh machine learning.

Kebangkitan: machine learning & deep learning

Alih-alih menulis aturan secara manual, machine learning membuat model belajar dari data. Beberapa tonggak yang saya catat:

  • 1997 — Deep Blue: komputer IBM mengalahkan juara catur dunia Garry Kasparov. Masih berbasis pencarian dan aturan, tapi momen penting: AI mengalahkan manusia di game populer.
  • 2012 — AlexNet: jaringan saraf konvolusional karya Alex Krizhevsky, Ilya Sutskever, dan Geoffrey Hinton menang telak di kompetisi ImageNet. Inilah momen deep learning “resmi” naik daun — berkat data besar dan GPU.
  • 2016 — AlphaGo: sistem DeepMind mengalahkan Lee Sedol di permainan Go, yang selama ini dianggap terlalu kompleks untuk diselesaikan dengan brute force.
  • 2017 — Transformer: paper “Attention Is All You Need” memperkenalkan arsitektur transformer, yang kelak menjadi fondasi GPT dan semua LLM modern.

2022–sekarang: AI generatif arus utama

ChatGPT dirilis November 2022 dan dipakai ratusan juta orang dalam hitungan bulan. Yang tadinya riset laboratorium menjadi produk harian: menulis, coding, menggambar, menganalisis. Sejarah tidak berhenti di sini — tapi untuk seri ini, 2022 adalah titik awal era yang sedang kita jalani.

Catatan programmer: mengingat lewat data

Sebagai programmer, cara paling natural buat saya mengingat sejarah ini adalah menjadikannya data — list pasangan (tahun, peristiwa):

sejarah = [
    (1950, "Turing Test"),
    (1956, "Konferensi Dartmouth"),
    (1974, "AI winter pertama"),
    (1987, "AI winter kedua"),
    (1997, "Deep Blue kalahkan Kasparov"),
    (2012, "AlexNet menang ImageNet"),
    (2017, "Paper Transformer"),
    (2022, "ChatGPT rilis"),
]
for tahun, peristiwa in sejarah:
    print(f"{tahun}: {peristiwa}")

Dari data ini saya menangkap pola besar: ide neural network sebenarnya sudah ada sejak 1958 (perceptron), tapi baru meledak tahun 2012. Yang berubah bukan teorinya, melainkan dua bahan bakar: data besar dan komputasi murah (GPU). Jadi ketika orang bilang “AI baru”, yang baru sebenarnya adalah skala, bukan konsep dasarnya.

Sumber

Pakai Model Non-Thinking untuk Coding Kompleks: Bisa, Asal Tahu Batasnya

Hari ini saya coba jawab pertanyaan yang sering muncul di kalangan yang baru mulai pakai AI coding agent: “Kalau pakai model non-thinking, apakah tetap bisa dipakai untuk coding yang kompleks?” Singkatnya: bisa, tapi dengan syarat — dan ada jenis pekerjaan yang memang lebih aman diserahkan ke model thinking. Catatan ini saya tulis khusus dari sudut pandang coding (Hermes Agent dan OpenCode), tidak membahas hal lain di luar itu.

Apa Bedanya Model Thinking vs Non-Thinking?

Dalam konteks coding, “thinking” (atau extended thinking / reasoning) artinya model diberi ruang untuk berpikir panjang sebelum menjawab — ia menuliskan rantai penalaran internal dulu, baru menghasilkan kode atau keputusan. Ini memakai token tambahan (biasanya tidak terlihat di output akhir), sehingga lebih lambat dan lebih mahal.

Model non-thinking menjawab langsung: input diproses, output langsung keluar. Lebih cepat, lebih murah, tapi untuk masalah yang butuh penalaran bertingkat, hasilnya bisa meleset lebih cepat.

Penting: yang wajib dimiliki untuk coding adalah kemampuan tool calling yang baik (membaca file, menjalankan perintah, melihat error, mengedit). Mode thinking itu nilai tambah, bukan prasyarat.

Kapan Non-Thinking Masih Andal

Untuk jenis pekerjaan berikut, model non-thinking yang bagus biasanya sudah cukup:

  • Boilerplate dan scaffolding — kerangka proyek, file konfigurasi, stub fungsi.
  • CRUD sederhana — endpoint API, form, operasi database standar.
  • Task satu file dengan spesifikasi eksplisit — “ubah fungsi ini supaya menerima parameter X”.
  • Refactor kecil dan mekanis — rename, pindah fungsi, ubah format.
  • Perbaikan bug yang error-nya jelas dan lokal.

Ciri umumnya: tugasnya jelas, ruang lingkupnya sempit, dan ada cara verifikasi cepat (test, compile, atau output yang bisa dicek).

Di Mana Non-Thinking Sering Gagal

Yang berikut ini justru menjadi titik lemah model non-thinking:

  • Debugging bertingkat — error menimpa error, root cause tersembunyi di balik gejala.
  • Refactor lintas file — banyak dependensi silang yang harus diikuti konsistensinya.
  • Keputusan arsitektur — memilih desain dengan trade-off yang saling bertabrakan.
  • Memahami codebase besar yang belum familiar — butuh penalaran panjang untuk membangun model mental.
  • Task ambigu — spesifikasi tidak lengkap, perlu inferensi dan pertimbangan.

Pada kasus seperti ini, model non-thinking berisiko gagal diam-diam: hasilnya terlihat jalan, tapi logikanya salah di tempat yang tidak langsung kelihatan.

Bukti dari Benchmark

Di benchmark agentic coding seperti SWE-bench Verified (500 isu GitHub nyata dari repo populer seperti Django, Flask, scikit-learn yang harus diselesaikan oleh model), posisi papan atas hampir selalu diisi model reasoning/thinking. Menurut leaderboard yang dipantau benchlm.ai per Agustus 2026, model teratas (Claude Opus 5) mencapai sekitar 96% resolusi.

Pola umumnya: versi thinking dari sebuah model hampir selalu mengungguli versi non-thinking-nya pada task multi-step, dan gap-nya mengecil drastis pada task sederhana. Jadi benchmark ini menegaskan — bukan soal “bisa atau tidak”, tapi soal di titik mana non-thinking mulai jebol.

Perbandingan Ringkas

AspekNon-ThinkingThinking
BiayaMurahMahal (token reasoning)
KecepatanCepatLambat
Konsumsi tokenHematBoros
Task sederhana & jelasSangat cocokBisa, tapi boros
Debugging & refactor besarRisiko gagal diam-diamAndal

Pola Praktis: Campur, Jangan Pilih Satu

Cara paling efektif bukan memilih salah satu, tapi memakai keduanya sesuai tugas — di Hermes dan OpenCode, ganti model per sesi/per task itu normal.

Hermes Agent

Ganti model kapan saja via hermes model, atau langsung set default:

hermes model
hermes config set model.default nama-model-non-thinking

Di dalam sesi, perintah /model untuk ganti model, dan /reasoning untuk mengatur level reasoning — kalau modelnya memang mendukung mode thinking. Model non-thinking tetap jalan normal tanpa setting tambahan.

OpenCode

Pilih model via /models. Kalau model default-nya thinking (misalnya Claude lewat provider Anthropic) dan ingin mematikannya, set lewat opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "anthropic": {
      "models": {
        "claude-sonnet-4-5": {
          "options": {
            "thinking": { "type": "disabled" }
          }
        }
      }
    }
  }
}

Untuk provider OpenAI-compatible (misalnya GPT), mode reasoning diatur lewat reasoningEffort — nilai rendah berarti “hampir non-thinking”.

Kesimpulan

Model non-thinking bisa dipakai untuk coding kompleks, asal tugas dipecah kecil dan ada loop verifikasi: tulis sedikit → jalankan → lihat error → perbaiki. Untuk boilerplate, CRUD, dan task single-file, non-thinking bahkan pilihan paling efisien.

Tapi untuk debugging bertingkat, refactor lintas file, dan keputusan desain, model thinking masih pilihan yang jauh lebih aman — terutama kalau pekerjaan berjalan tanpa pengawasan. Prinsipnya: pakai model sesuai tingkat kesulitan tugas, bukan satu model untuk segalanya.

Sumber

Belajar Laravel #2: Routing & Controller Pertama — Dari URL ke View

Hari ini saya lanjut belajar Laravel ke episode kedua: routing dan controller pertama. Setelah minggu lalu berhasil membuat project dan menjalankan php artisan serve, sekarang saya penasaran — dari mana sebenarnya halaman awal itu muncul? Ternyata jawabannya ada di satu file kecil bernama routes/web.php. File inilah yang menjadi pintu masuk hampir semua request ke aplikasi web kita.

routes/web.php: pintu masuk aplikasi

Buka folder project lalu buka routes/web.php. Isinya singkat, hanya satu route default:

<?php

use Illuminate\Support\Facades\Route;

Route::get('/', function () {
    return view('welcome');
});

Bisa dibaca seperti ini: “kalau ada request GET ke alamat /, jalankan fungsi ini, lalu kembalikan view welcome“. Di sinilah saya sadar perbedaan mendasar Laravel dengan PHP biasa: alih-alih membuat file index.php per halaman, semua alamat dipetakan lewat satu file route. Ini disebut front controller — semua request masuk lewat public/index.php, lalu Laravel yang memutuskan ke mana request itu diteruskan berdasarkan route yang cocok.

Route closure vs controller

Di contoh di atas, logika ditulis langsung di dalam route sebagai closure (fungsi anonim). Untuk halaman sekecil welcome, cara ini cukup. Tapi kalau semua logika ditumpuk di routes/web.php, file itu cepat sekali jadi penuh sesak. Solusi Laravel: pindahkan logika ke controller.

Buat controller lewat Artisan:

php artisan make:controller HalamanController

Perintah itu membuat file app/Http/Controllers/HalamanController.php. Isinya kelas kosong. Lalu saya tambahkan method sendiri:

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class HalamanController extends Controller
{
    public function index()
    {
        return view('welcome');
    }
}

Dan route-nya berubah menjadi:

Route::get('/', [HalamanController::class, 'index']);

Pola [NamaController::class, 'namaMethod'] adalah cara Laravel modern menunjuk controller di route. Hasilnya sama dengan versi closure, tapi logika sudah pindah ke tempat yang lebih rapi dan bisa diuji. Prinsipnya: route itu peta, controller itu pekerja.

View pertama

Method index() tadi mengembalikan view('welcome'). View adalah file template yang disimpan di resources/views dengan ekstensi .blade.php — jadi view('welcome') mencari resources/views/welcome.blade.php. Saya coba buat halaman sendiri, misalnya halaman tentang:

Route::get('/tentang', [HalamanController::class, 'tentang']);

Lalu di controller:

public function tentang()
{
    return view('tentang');
}

Dan buat file resources/views/tentang.blade.php berisi HTML sederhana. Setelah itu php artisan serve dan buka http://127.0.0.1:8000/tentang — halaman muncul. Kesannya ajaib padahal sederhana: route → controller → view. Tiga lapis yang akan terus kita pakai di semua episode berikutnya.

Kesalahan yang umum

  • Lupa menjalankan php artisan serve, lalu bingung kenapa halaman 404. Route tidak akan jalan tanpa server.
  • Nama view salah ketik: view('welcome') tapi file bernama welcome.blade.php — pastikan nama persis.
  • Menaruh route di bawah route lain yang polanya sama; di Laravel, route yang cocok pertama yang dipakai. Urutan route bisa penting.
  • Menulis logika bisnis menumpuk di route closure sampai file web.php ratusan baris — kebiasaan yang sebaiknya dihindari sejak awal dengan memakai controller.

Kesimpulan

Hari ini saya paham alur dasar aplikasi Laravel: request masuk ke routes/web.php, dicocokkan dengan pola URL, lalu diteruskan ke closure atau controller, dan akhirnya controller mengembalikan view Blade. Konsep ini kecil tapi fondasi — semua fitur berikutnya (form, database, login) menumpang di alur yang sama. Minggu depan saya lanjut ke Blade: layout, @extends, dan perulangan @foreach.

Sumber

Mengganti Model di Tengah Sesi Coding: Dampaknya dan Solusi Failover (OpenCode, Hermes, 9Router)

Beberapa hari terakhir saya memakai beberapa tool coding berbasis AI sekaligus, dan muncul pertanyaan yang sering ditanyakan banyak orang: kalau di tengah sesi kode modelnya ganti-ganti — entah karena rate limit atau provider sedang turun — apakah berpengaruh ke hasil kerja? Apalagi sekarang ada 9Router yang bisa auto-fallback ke model lain. Catatan ini saya rangkum dari eksperimen dan riset saya soal OpenCode, Hermes Agent, dan 9Router.

Apa yang Sebenarnya Terjadi Saat Model Ganti di Tengah Sesi?

Ganti model di tengah sesi coding bukan sekadar soal “sambungannya pindah”. Ada tiga hal yang berubah:

  • Konteks percakapan bisa terpotong. Setiap model punya batas token window sendiri. Saat failover, riwayat prompt biasanya di-truncate agar muat di model baru. Model pengganti bisa jadi tidak paham penuh alur debug yang sedang kita jalani.
  • Gaya dan keputusan teknis bisa melenceng. Tiap model punya kebiasaan sendiri soal penamaan, struktur folder, sampai pilihan pola kode. Kalau berganti di tengah fitur yang sama, hasilnya bisa tidak konsisten.
  • Ada biaya dan latency tambahan. Koneksi ke provider baru perlu inisialisasi ulang, dan jika konteks dikirim ulang, token yang dipakai juga bertambah.

Bagaimana OpenCode Menangani Ini?

OpenCode (tool agentic coding open source yang awalnya dikembangkan oleh Andrej Karpathy) mendukung banyak provider sekaligus: OpenAI, Anthropic, Google, hingga model lokal. Beberapa hal yang saya perhatikan:

  • Bisa ganti model/provider secara dinamis tanpa restart sesi, dan konteks terbaru tetap dibawa.
  • Ada failover bawaan — jika satu provider rate limited, ia beralih ke model berikutnya sesuai urutan yang kita daftarkan.
  • Semua perubahan model tercatat di log sesi, sehingga riwayatnya bisa ditelusuri kembali.

Kekurangannya: tiap provider perlu API key sendiri, dan failover bisa menambah latency kalau tidak hati-hati mengatur urutan.

Bagaimana dengan Hermes Agent?

Hermes Agent (dari Nous Research) adalah agen yang lebih umum — bisa untuk coding, riset, sampai otomasi. Untuk urusan ganti model di tengah sesi, pengalamannya sedikit berbeda:

  • Provider bisa di-load/unload secara dinamis, tapi sinkronisasi konteks cenderung manual — perlu resume sesi atau menyuntikkan ringkasan konteks.
  • Failover otomatis tidak sepenuhnya built-in seperti OpenCode, tapi bisa dikonfigurasi lewat fallback_providers di config — ini yang saya pakai untuk beberapa cron blog saya.
  • Restore konteks dari disk butuh waktu, jadi ada latency tambahan saat pindah sesi.

Di Mana Posisi 9Router?

Di sinilah 9Router berperan. Daripada tiap tool mengurus failover-nya sendiri, kita bisa mengarahkan semuanya ke satu router yang mengatur urutan model:

opencode --model "9router://gpt-4o,claude-3.5-sonnet,gemini-1.5-flash"

Jika model pertama kena limit, 9Router otomatis meneruskan ke model berikutnya. Sisi tool (OpenCode/Hermes) tidak perlu tahu apa-apa — mereka tetap memakai endpoint yang sama. Ini menyederhanakan masalah jadi satu: atur urutan prioritas, sisanya otomatis.

Jadi, Apakah Ganti Model Berpengaruh?

AspekDampakCara Mitigasi
Konteks sesiBisa terpotong (truncate)Checkpoint / ringkasan konteks tiap beberapa langkah
Konsistensi kodeGaya bisa berubah antar modelBiarkan satu model menyelesaikan satu fitur utuh
KetersediaanTurun jika satu provider downFailover 9Router dengan urutan model cadangan
Latency & biayaNaik saat failoverUrutkan model dari yang paling sering dipakai

Perspektif Hermes Agent: Kenapa Task Tetap Nyambung?

Ada satu hal yang memperjelas gambaran ini: jawaban langsung dari tim Hermes Agent (Nous Research) saat saya tanyakan hal yang sama — “jika saat eksekusi task model/provider diganti 9Router, apakah task yang dijalankan model berbeda akan tetap nyambung?”. Jawabannya: ya, tetap nyambung — dengan satu syarat penting.

Konteks Dikelola Hermes, Bukan Provider

Konteks (prompt + tools + state) disimpan di sisi gateway/sesi Hermes. Saat 9Router mengganti provider/model, Hermes tetap mengirim konteks yang sama — lewat history.messages — ke provider baru. Provider hanya “menumpang” pada konteks yang sudah disiapkan Hermes.

Syaratnya: Provider OpenAI-Compatible

Provider OpenAI-compatible (kagiro, laguna, dsb — yang memang terhubung lewat 9Router) memakai format message yang sama. Jadi model yang berbeda sekalipun akan menerima konteks yang sama persis. Yang bikin putus hanyalah perubahan model yang sangat signifikan — misalnya dari OpenAI-style ke Claude-style — karena format outputnya berbeda.

Contoh Jalan atau Tidaknya

PerpindahanKonteks Tetap?Alasan
kagiro → laguna (9Router)✅ YaFormat message sama
laguna → deepseek (9Router)✅ YaFormat message sama
deepseek → llama.cpp (GGUF lokal)⚠️ TergantungKalau via endpoint OpenAI-compatible masih nyambung, tapi gaya model baru bisa beda
ke Claude (non-OpenAI)❌ PutusFormat beda, konteks harus di-reformat

Bottom Line

Selama semua provider yang dipakai adalah OpenAI-compatible endpoint (yang memang dilakukan via 9Router), ganti model/provider tidak akan memutus alur task — Hermes akan mengirim konteks yang sama ke provider baru. Logika tool (mengubah config, restart gateway, dsb) tetap jalan karena Hermes yang mengeksekusi, bukan provider. Yang nyata berubah hanyalah cost dan kecepatan response.

Bagaimana dengan OpenCode? Apakah Sama?

Pertanyaan lanjutannya: apakah prinsip yang sama berlaku di OpenCode? Berdasarkan dokumentasi resminya — ya, prinsipnya sama.

“Select a model to use it in the current session. Switching models updates that session without changing your config.” — Dokumentasi resmi OpenCode (opencode.ai/v2/docs/models)

Konteks Dipegang OpenCode, Bukan Provider

Seperti Hermes, konteks (transcript + state) disimpan di sisi OpenCode — bukan di provider. Ganti model lewat model picker (tab) atau per-run (--model) hanya mengganti model yang dipakai sesi itu; riwayat percakapan tetap utuh dan dikirim penuh ke model baru.

9Router Transparan untuk OpenCode

OpenCode melihat 9Router sebagai satu provider OpenAI-compatible biasa. Saat failover terjadi di balik layar, OpenCode tidak tahu modelnya berganti — ia tetap mengirim konteks sesi yang sama ke endpoint yang sama. Perilakunya persis seperti Hermes.

Perbandingan Hermes vs OpenCode

AspekHermes AgentOpenCode
Pemegang konteksGateway/sesi Hermes (history.messages)Session store OpenCode (transcript)
Switch model mid-sessionDinamis via configModel picker tab / --model, tanpa ubah config
Auto-failover native antar provider✅ Ada (fallback_providers)❌ Tidak ada — manual
Failover via 9RouterKonteks nyambung ✅Konteks nyambung ✅

Satu perbedaan penting: Hermes punya failover native antar provider, OpenCode tidak. Di OpenCode, 9Router justru perannya lebih besar — dialah satu-satunya mekanisme failover otomatisnya. Tanpa 9Router, ganti model di OpenCode harus manual.

Kesimpulan

Mengganti model di tengah sesi berpengaruh, terutama pada konteks dan konsistensi — tapi dampaknya bisa dikelola. Untuk masalah ketersediaan (rate limit, provider down), 9Router sudah menyelesaikan bagian terberatnya dengan failover otomatis. Untuk masalah konteks, kebiasaan kecil seperti menyimpan ringkasan pekerjaan setiap beberapa langkah sudah sangat membantu.

Pendekatan yang saya pakai sekarang: satu model untuk satu fitur utuh, dan 9Router sebagai jaring pengaman kalau model utama sedang bermasalah. Kombinasi yang cukup untuk sebagian besar pekerjaan harian.

Failover Model Cerdas: Pakai 9Router Biar Nggak Macet Rate Limit

Siapa yang tidak pernah mengalami ini: sedang asyik menulis kode dengan bantuan AI, tiba-tiba muncul pesan rate limit exceeded atau connection timeout. Apalagi saat sedang fokus menyelesaikan satu fitur. Alur kerja jadi terputus, dan kita harus menunggu atau berpindah tool secara manual.

Hari ini saya belajar tentang cara mengatasi masalah ini dengan lebih elegan: routing model dengan failover otomatis. Alih-alih terpaku pada satu model atau satu provider, kita bisa menyusun rantai model cadangan yang otomatis dipakai ketika model utama sedang bermasalah.

Apa Itu Failover Model?

Failover model adalah mekanisme di mana ketika satu model/provider gagal — karena rate limit, timeout, atau layanan sedang turun — permintaan kita otomatis dialihkan ke model lain yang sudah kita daftarkan sebagai cadangan. Kita cukup menentukan urutan prioritas, sisanya ditangani otomatis.

Salah satu tool yang menyediakan fitur ini adalah 9Router, sebuah AI router gratis yang bisa diarahkan dari berbagai tool coding seperti OpenCode maupun Hermes Agent.

Cara Kerja 9Router

Kita menentukan urutan prioritas model yang ingin dipakai. Contohnya, jika model utama sedang terkena limit, sistem akan otomatis mencoba model berikutnya dalam daftar:

opencode --model "9router://gpt-4o,claude-3.5-sonnet,gemini-1.5-flash"

Jika gpt-4o gagal (rate limit atau timeout), sistem langsung mencoba claude-3.5-sonnet, lalu gemini-1.5-flash — tanpa intervensi manual. Kita tidak perlu berhenti menulis kode hanya karena satu provider sedang sibuk.

Konfigurasi di OpenCode dan Hermes Agent

Untuk OpenCode, model dengan failover bisa dipanggil langsung lewat CLI:

opencode --model "9router://gpt-4o,claude-3.5-sonnet,command-r-plus"

Sementara di Hermes Agent, konfigurasi dapat ditambahkan pada file config.yaml:

providers:
  - name: 9router
    type: router
    model_chain: ["gpt-4o", "claude-3.5-sonnet", "gemini-1.5-flash"]

Keuntungan Menggunakan 9Router

FiturManfaat
Auto failoverAlur kerja tidak terputus saat rate limit
Multi-providerBisa memakai model terbaik yang tersedia saat itu
Tanpa konfigurasi manualCukup atur sekali, sisanya otomatis
Resume sessionKonteks percakapan tetap dilanjutkan di model berikutnya

Kapan Failover Tidak Cukup?

Untuk sesi debugging yang sangat panjang, failover model tetap disarankan dilengkapi dengan checkpoint — menyimpan ringkasan konteks setiap beberapa langkah. Ini menjaga agar model pengganti tetap memahami arah pekerjaan yang sedang dikerjakan.

Namun untuk mayoritas kasus, failover lewat 9Router sudah cukup. Fokus utama kita: menentukan urutan model yang masuk akal, lalu membiarkan sistem bekerja.

Kesimpulan

Mengganti model di tengah sesi kode bukan lagi hal yang merepotkan. Dengan 9Router, kita cukup menyusun urutan prioritas model — sistem yang akan memastikan pekerjaan tetap berjalan meski salah satu provider sedang bermasalah.

Doa & Dzikir Setelah Shalat Fardhu: Keutamaan dan Manfaatnya

Hari ini saya belajar tentang keutamaan doa dan dzikir setelah shalat fardhu. Ternyata selama ini saya sering sekilas-kilas saja — baca doa pelit, lalu langsung berhenti. Padahal Rasulullah ﷺ bersabda “Barangkali seorang hamba itu tidak akan diberi ganjaran kecuali karena doa yang dia doakan setelah shalat fardhu.”

Di dalam kajian Ustadz Abdullah Zaen, M.A. (Fiqih Do’a dan Dzikir, Radio Rodja), beliau menjelaskan bahwa doa setelah shalat fardhu adalah momentum emas untuk berkomunikasi langsung dengan Allah. Ia bukan sekadar rutinitas—melainkan cara untuk mengakui kelemahan diri, memohon ampunan, dan mendekatkan diri kepada-Nya.

Dzikir Pagi dan Petang: Kunci Doa yang Diterima

Dzikir pagi dan petang adalah rangkaian doa harian yang disunnahkan. Lengkap dengan teks Arab, Latin, arti, dan keutamaannya. Orang yang konsisten berdzikir pagi dan petang termasuk orang yang dicintai Allah. Berikut ini saya rangkum beberapa doa dan dzikir yang bisa dibaca setelah shalat fardhu.

Doa Setelah Shalat Fardhu

Setelah menyelesaikan shalat fardhu, bacalahlah doa ini:

  • Astaghfirullahal-‘Adhim — “Aku mohon ampun kepada Allah yang Maha Besar (3x)”
  • Allahumma Antas-Salamu Wa Minkan-Nsalam — “Ya Allah, Engkau adalah Yang Maha Damai, dan dari-Mu datangnya segala ketenteraman”
  • Subhanaka Allahumma Wa Bihamdika — “Maha suci Engkau, Ya Allah, dan dengan rahmat-Mu”
  • Darood dan Doa Akhir — “Ya Allah, ampunilah aku dan para manusiapun dan seluruh makhluk-Ni mengelilingi bumi”.

Doa ini membantu kita mengingat kesalahan diri, bersyukur atas nikmat shalat yang baru selesai, dan memohon perlindungan dari dosa.

Manfaat Doa Setelah Shalat Fardhu

Menurut kajian, doa setelah shalat fardhu memberi banyak manfaat:

  • Mendekatkan diri kepada Allah — doa adalah komunikasi langsung dengan Tuhan
  • Mengingatkan diri pada kesalahan — kita diajak merefleksikan kebaikan dan kekurangan dalam shalat
  • Meningkatkan rasa syukur — mengakui nikmat shalat yang baru selesai
  • Mohon ampun dan perlindungan — memohon agar diberi kekuatan menjauh dari dosa

Rasulullah ﷺ bersabda: “Barangkali seorang hamba itu tidak akan diberi ganjaran kecuali karena doa yang dia doakan setelah shalat fardhu.”

Refleksi

Saya belajar bahwa doa setelah shalat fardhu adalah satu-satunya momen yang bisa kita alokasikan setiap hari untuk beristighfar, memohon ampunan, dan berdoa dengan tenang. Jika kita konsisten, insyaAllah akan terbentuk kebiasaan yang erat dengan Rabb kelak.

Marilah kita jadikan doa ini sebagai rutinitas harian. Dzikir pagi dan petang, serta doa setelah setiap shalat — semua bisa jadi jembatan kita kembali kepada-Nya. Semoga doa-doa ini diterima, dan kita diberi kekuatan untuk konsisten berdzikir. Aamiin.

Simulasi Budget /Bulan: Xiaomi MiMo Pay-As-You-Go vs Token Plan

Dalam era di mana model bahasa besar (LLM) semakin berlimpah, para pengembang (terutama yang aktif memakai CLI seperti OpenCode atau Hermes Agent) kini dituntut untuk selektif memilih penyedia layanan AI yang paling efisien. Salah satu yang muncul dalam dua tahun belakangan adalah Xiaomi MiMo, sekaligus produk andalan Xiaomi untuk programmer dan peneliti.

MiMo menawarkan dua opsi tagihan: Pay-As-You-Go (PAYG) dan Token Plan. Kedua sistem ini tidak dapat saling menggantikan, sehingga pemilihan antara keduanya perlu didasarkan pada pola penggunaan aktual. Pada postingan ini, kami akan mensimulasikan penggunaan dengan budget tetap $5 per bulan, lalu membandingkan berapa banyak token yang kita dapat dari masing-masing opsi, serta kompatibilitasnya dengan alat-alat pengembangan populer seperti Hermes dan OpenCode.

Apa Itu Pay-As-You-Go (PAYG)?

Pay-As-You-Go adalah model di mana setiap token yang Anda gunakan akan ditagihkan langsung ke akun Anda pada akhir bulan. Anda hanya membayar untuk apa yang Anda konsumsi. Cukup fleksibel, tetapi biaya dapat meningkat secara signifikan dengan penggunaan intensif.

Apa Itu Token Plan?

Token Plan adalah langganan bulanan atau tahunan yang memberikan kuota tetap. Ini cocok untuk pengguna yang ingin kontrol penuh atas pengeluaran bulanan mereka, tetapi tidak fleksibel jika penggunaan melebihi kuota.

Tarif Resmi Xiaomi MiMo

Berikut tarif resmi MiMo per 1 Juni 2026:

LayananTarifUnit
PAYG — mimo-v2.5$0.026/1M token
PAYG — mimo-v2.5-pro$0.052/1M token
Token Plan — Lite Annual$63.36/tahun ($5.28/bulan)
Token Plan — Lite Monthly$6.00/bulan
Sumber: dokumentasi resmi Xiaomi MiMo

Simulasi Budget $5/Bulan

Pay-As-You-Go ($5/bulan)

ModelHarga per 1M tokenToken per $5
mimo-v2.5$0.026~192M token
mimo-v2.5-pro$0.052~96M token

Token Plan — Lite Annual ($5.28/bulan)

RencanaBiaya/BulanKuota TokenToken per $5 setara
Lite Annual$5.288000M token~8000M token

Dengan demikian, kita mendapatkan lebih dari 40x lipat token dibandingkan PAYG standar, untuk budget yang hampir sama!

Cara Pakai MiMo dengan Hermes & OpenCode

Ikuti langkah berikut:

export OPENAI_API_BASE = https://api.mimo.ai/v1
export OPENAI_API_KEY  = ***
  • Pilih model (mis. mimo-v2.5 atau mimo-v2.5-pro).
  • Jika menggunakan Token Plan, pastikan API Key terhubung ke paket langganan yang valid.

Penting: Xiaomi MiMo tidak mendukung interoperabilitas antara PAYG dan Token Plan. Anda harus memilih satu sistem pembayaran dan tidak dapat beralih secara dinamis antara keduanya.

Rekomendasi Akhir

  • Jika Anda aktif menggunakan AI untuk coding, riset, atau pengembangan harian, maka Token Plan Lite (Annual) adalah pilihan yang jauh lebih efisien secara biaya jangka panjang.
  • Jika hanya mengekplorasi sekali-sekali, maka Pay-As-You-Go cukup andal.

Sumber

Perbandingan Model AI 2026: Thinking vs Non-Thinking, Multimodal, dan Harga API

Sebagai developer dan peneliti AI, kita kini hidup di era di mana jumlah dan jenis model bahasa besar (LLM) yang tersedia bagi pengguna biasa semakin berlimpah. Setiap bulan, vendor seperti OpenAI, Anthropic, Google, dan lainnya merilis model baru yang menambah kebingungan pilihan. Tapi tidak semua model sama, ada yang fokus pada reasoning, ada yang multimodal, dan ada yang sekadar inginkan solusi yang cepat dan hemat — tanpa mengorbankan kualitas secara signifikan.

Pada Agustus 2026, kami telah mengumpulkan data terbaru dari dokumentasi resmi masing-masing vendor — termasuk repositori ai-pricing yang di-audit pada 5 Agustus 2026 — untuk memberi Anda gambaran jelas tentang:

  • Apa perbedaan thinking mode dan non-thinking mode?
  • Model-model dengan kemampuan vision, audio, dan tool use?
  • Tabel harga API paling akurat hingga kini — lengkap dengan sistem tarif peak/off-peak dari DeepSeek.

Ikuti selanjutnya!


Apa Itu “Thinking Mode”?

Thinking Mode (juga disebut reasoning atau extended thinking) adalah kemampuan model untuk menghasilkan rantai-poin pikir (chain-of-thought) internal sebelum memberikan jawaban akhir. Ini meniru cara manusia “memikirkan dua kali sebelum bertanya”.

Model dengan thinking mode biasanya:

  • Menghasilkan kualitas yang jauh lebih baik pada tugas matematis, kode, dan logika kompleks.
  • Memiliki latensi yang jauh lebih tinggi (sering 10-an detik atau lebih).
  • Menghitung token “pikiran” sebagai bagian dari output — artinya, Anda membayar untuk proses berpikir internal model.

Non-Thinking Mode adalah model yang menjawab langsung, lebih cepat, dan lebih murah. Cocok untuk tugas rutin, ringan, atau percakapan.

AspekThinking ModeNon-Thinking Mode
LatensiTinggi (detik ke-10-an)Rendah (detik pertama)
BiayaLebih mahalLebih murang
Kualitas jawabanUnggul pada matematika, coding, logikaBaik untuk tugas umum
Token yang dihitungInput + Output (termasuk “pikiran”)Hanya Input + Output
Model contoho1, o3-mini, DeepSeek R1, Qwen3-ThinkingGPT-4o, GPT-4.5, Claude Sonnet, Grok

Kemampuan Multimodal (Vision, Audio, Tool)

Beberapa model mendukung lebih dari sekadar teks — mereka dapat memproses gambar, audio, file, dan bahkan menggunakan alat eksternal (tool use).

Vision (Gambar → Teks)

ModelKemampuan
GPT-4o / GPT-4o-mini✅ Gambar input/output, edisi, analisis
GPT-Image-2✅ Generasi & pengeditan gambar tingkat lanjut
Gemini 3.1 Pro✅ Visi multimodal terintegrasi
Qwen3-VL-235B✅ Visi kuat untuk dokumen & gambar kompleks
Pixtral Large (Mistral)✅ Model vision open-weight dari Mistral

Audio (Suara → Teks / Teks → Suara)

ModelKemampuan
GPT-Realtime-2.1 / 2✅ Input & output audio real-time
GPT-Audio-1.5✅ Speech-to-text + text-to-speech
GPT-4o-mini-TTS✅ TTS ringan
Whisper (OpenAI)✅ Transkripsi audio
ElevenLabs API✅ TTS realistis

Tool Use / Agentis

ModelKemampuan
Claude Fable 5✅ Tool use canggih, retrieval, coding
GPT-5.6 Sol✅ Tool use + reasoning lanjut
Grok 4.6✅ Tool use, file input, coding
Qwen3-235B✅ Mode beralih thinking/non-thinking + tool use
Command A (Cohere)✅ Fokus enterprise & RAG

Tabel Harga API (per 1M Token USD)

Catatan penting: Harga dapat bervariasi tergantung provider (OpenRouter, Groq, DeepInfra, dll). Angka di bawah ini merupakan harga resmi dari vendor utama atau rata-rata pasar terendah pada Agustus 2026.

OpenAI

ModelInput ($/1M)Output ($/1M)Thinking ModeCatatan
GPT-5.6 Sol$5.00$30.00Frontier model
GPT-5.6 Terra$2.50$15.00Versi menengah
GPT-5.6 Luna$1.00$6.00Versi hemat
GPT-5.5 Pro$30.00$180.006x lipat dari non-Pro
GPT-4o$2.50$10.00Umum, cepat
GPT-4o-mini$0.15$0.60Ringan
GPT-Realtime-2.1$4.00$24.00Audio real-time

Anthropic

ModelInput ($/1M)Output ($/1M)Thinking ModeCatatan
Claude Fable 5$10.00$50.00Termahal, performa tertinggi
Claude Opus 5$5.00$25.00Setengah harga Fable 5
Claude Sonnet 4.6$2.00$10.00⚠️ OpsionalExtended thinking tersedia
Claude Haiku 4.5$1.00$5.00Cepat dan hemat

Google Gemini

ModelInput ($/1M)Output ($/1M)Thinking ModeCatatan
Gemini 3.1 Pro$2.00$12.00Termasuk Deep Think (bisa lebih mahal)
Gemini 3.6 Flash$1.50$7.50Performa tinggi, biaya rendah
Gemini 3.5 Flash-Lite$0.30$2.50Hemat, cocok untuk skala besar
Gemini 2.5 Pro$1.25$10.00Legacy, masih tersedia
Gemini 2.0 Flash$0.10$0.40Murah, umum

DeepSeek (China)

ModelInput ($/1M)Output ($/1M)Thinking ModeCatatan
DeepSeek V4 Flash~$0.28~$1.32Naik setelah 16 Agustus
DeepSeek V4 Pro~$1.74~$3.9634x lebih murah dari Claude di input
DeepSeek V3$0.14$0.28Legacy
DeepSeek R1$0.55$2.19Fokus pada reasoning

Qwen (Alibaba)

ModelInput ($/1M)Output ($/1M)Thinking ModeCatatan
Qwen3-235B-A22B~$0.20~$0.60Mode beralih, MoE 235B
Qwen3-VL-235B-Thinking$0.45$3.49Visi + thinking
Qwen3-235B-Instruct~$0.20~$0.60Non-thinking
Qwen3-32B~$0.15~$0.30⚠️ OpsionalRingan

Grok (xAI / SpaceXAI)

ModelInput ($/1M)Output ($/1M)Thinking ModeCatatan
Grok 4.6$2.00$6.00Frontier model, 500K konteks
Grok 4.3$1.25$2.50Versi lebih hemat
Grok 4.20$1.25$2.50Reasoning tinggi
Grok 4.1 Fast$0.20$0.50Ringan

Mistral AI (Prancis)

ModelInput ($/1M)Output ($/1M)Thinking ModeCatatan
Mistral Large 3$0.50$1.50Open weights, EU residency
Mistral Medium 3.5$1.50$7.50Seimbang kualitas/harga
Codestral 2508$0.30$0.90Fokus kode
Pixtral Large$2.00$6.00Vision

Kimi / Moonshot & Phi (Microsoft)

ModelInput ($/1M)Output ($/1M)Thinking ModeCatatan
Kimi K3$3.00$15.00Flagship, 1M konteks
Kimi K2.6$0.95$4.00Umum
Phi-4$0.07$0.14Ringan, on-device

Catatan Penting: Peak / Off-Peak Pricing dari DeepSeek

DeepSeek adalah produsen pertama yang memperkenalkan sistem tarif bergumuru — tempat biaya bergantung pada waktu permintaan dikirimkan.

  • Peak hours: 01:00–04:00 UTC & 06:00–10:00 UTC
  • Off-peak: Semua sisa waktu
  • Mulai 16 Agustus 2026, tarif naik secara signifikan:
ModelPeak InputOff-Peak InputPeak OutputOff-Peak Output
DeepSeek V4 Flash$0.28$0.14$1.32$0.66
DeepSeek V4 Pro$1.74$0.87$3.96$1.98

Rekomendasi Berdasarkan Kebutuhan

KebutuhanModel Rekomendasi
Coding asisten + reasoningGPT-5.6 Sol / Claude Fable 5 / Grok 4.6
Chatbot ringan (hemat)GPT-4o-mini / Gemini 3.5 Flash-Lite / DeepSeek Flash
Analisis gambar/dokumenGPT-4o / Gemini 3.1 Pro / Qwen3-VL
Riset ilmiah/matematiko1 / o3-mini / Claude Opus 5 / DeepSeek Pro
Agentis multitoolClaude Fable 5 / GPT-5.6 Sol / Command A
Hosting lokalLlama 4 / Qwen3 / Mistral Large 3 (open weights)

Sumber

Dokumen ini disusun berdasarkan data publik dan dokumentasi resmi. Harga dan ketersediaan model dapat berubah tanpa pemberitahuan sebelumnya.

Berita Coding & Web Dev Terbaru (13 Agustus 2026)

Kumpulan berita coding, web dev & AI paling menarik minggu ini (Kamis, 13 Agustus 2026). Dari rilis Laravel 13.25, TypeScript 7, DeepSeek V4 Pro, sampai peringatan keamanan supply-chain. Berikut 8 yang paling worth-it buat developer.

1. Laravel 13.25: Pause Semua Queue + UI Baru artisan dev

Laravel rilis minor 13.25 dengan tambahan yang menyenangkan buat developer. Kali ini ada perintah queue:pause --all yang bisa menjeda semua queue di semua koneksi sekaligus — berguna saat ada deploy atau maintenance. Selain itu, perintah artisan dev kini berjalan di tabbed terminal UI yang lebih rapi, dan route kini bisa langsung mengembalikan gambar.

Sumber: Laravel News

2. TypeScript 7 Diklaim 10x Lebih Cepat

Anders Hejlsberg mendemokan TypeScript 7 yang konon punya speedup 10x dibanding versi sebelumnya. Kabar ini jadi topik hangat di JavaScript Weekly. Buat proyek besar yang kompilasinya pelan, ini kabar yang sangat ditunggu-tunggu komunitas JS.

Sumber: JavaScript Weekly #796

3. DeepSeek V4 Pro 0813 Rilis — Model Open Source Terbaru

DeepSeek merilis V4 Pro 0813, model open source terbaru mereka yang langsung ramai dibahas (951 poin di Hacker News). Seperti rilisan DeepSeek sebelumnya, kehadirannya menarik perhatian karena performa kompetitif dengan biaya yang cenderung lebih rendah, dan kini sudah tersedia lewat API.

Sumber: OpenRouter

4. Grok 4.6 Rilis, Skor 61 di Artificial Analysis Index

xAI meluncurkan Grok 4.6 yang mencatat skor 61 pada Artificial Analysis Intelligence Index. Rilis ini menjadi salah satu perbincangan terbesar minggu ini (569–575 poin HN), termasuk analisis benchmark yang membedah kekuatan dan kelemahannya dibanding model lain.

Sumber: Artificial Analysis

5. ChatGPT Desktop (Codex Desktop) Kini Tersedia untuk Linux

Kabar baik buat developer Linux: aplikasi desktop ChatGPT/Codex kini tersedia untuk Linux. Banyak developer yang selama ini memakai Codex CLI lewat terminal kini bisa mencoba pengalaman desktop native. Menjadi salah satu topik developer tools paling dibicarakan pekan ini.

Sumber: OpenAI Codex

6. Watermark Baru Anthropic Bikin Pengguna Claude Geram

Anthropic memperkenalkan sistem watermarking baru pada Claude yang ramai diprotes pengguna. Banyak yang khawatir watermark ini akan “ketahuan” saat mereka pakai Claude untuk keperluan kerja atau tugas kuliah. Ini jadi pengingat penting soal kebijakan AI, privasi, dan pro/kontra pendeteksian konten.

Sumber: TechCrunch

7. Terabyte Kredensial Bocor dalam Serangan Supply-Chain

Ada peringatan keamanan serius pekan ini: terabyte kredensial bocor lewat serangan supply-chain yang menyasar sebuah package AI yang disusupi. Datanya disisir dan dieksfiltrasi dari 2.500 pengguna. Cocok jadi pengingat untuk periksa keamanan dependency dan supply-chain di proyek kamu.

Sumber: Ars Technica

8. Laracon US 2026: Semua Pengumuman Penting

Buat pengguna Laravel, Laracon US 2026 baru saja berlangsung dan menghasilkan banyak pengumuman — mulai dari fitur baru, tooling, sampai arah pengembangan framework ke depan. Kalau sempat, artikel rekap ini wajib dibaca biar nggak ketinggalan.

Sumber: Laravel Blog

Itu dia delapan berita paling menarik pekan ini buat developer. Mana yang paling bikin kamu penasaran? Sampai jumpa di kumpulan berita minggu depan!

Belajar Laravel #1: Persiapan & Instalasi — PHP, Composer, dan Project Pertama

Hari ini aku mulai seri baru di blog ini: Belajar Laravel. Rencananya 25 episode, dari nol sampai bisa membuat aplikasi web lengkap — sebuah Sistem Informasi sederhana dengan stack yang sengaja kubuat “bersahaja”: jQuery, Bootstrap, MySQL, dan Blade murni. Aku tidak memakai tool bantu populer yang bisa menyembunyikan cara kerja aslinya, karena tujuanku satu: paham benar bagaimana request masuk, bagaimana Blade merender HTML, dan bagaimana query sampai ke MySQL. Catatan ini kutulis sambil belajar, jadi kalau ada bagian yang terasa membingungkan — tenang, memang begitulah rasanya belajar.

Kenapa Laravel?

Sebelum ngoding, aku sempat bertanya: kenapa harus Laravel, bukan framework lain? Alasanku kurang lebih begini:

  • Paling populer di ekosistem PHP — banyak dipakai perusahaan, jadi banyak lowongan yang butuh skill ini.
  • Pola MVC — kode dipisah rapi: Controller untuk logika, Model untuk data, View untuk tampilan. Lama-lama ini terasa menyehatkan, apalagi kalau project mulai besar.
  • Dokumentasi dan komunitas besar — nyaris semua error yang kuhadapi sudah pernah dialami orang lain, dan jawabannya mudah ditemukan.
  • Artisan — command line tool bawaan yang mempercepat kerja rutin seperti membuat controller, migration, sampai menjalankan server.

Intinya: Laravel memberi struktur tanpa memaksa kita menulis semuanya dari nol, tapi tetap cukup “telanjang” untuk kita pelajari apa yang terjadi di balik layar.

Prasyarat: PHP & Composer

Laravel berjalan di atas PHP, jadi syarat pertama adalah PHP terpasang. Pastikan versi PHP-mu memenuhi syarat minimum yang tercantum di dokumentasi resmi Laravel — jangan asal pakai versi lawas, karena fitur framework terbaru biasanya butuh versi PHP tertentu. Cara mengeceknya:

php -v
composer --version

Composer adalah manajer dependensi untuk PHP — kurang lebih seperti npm di dunia JavaScript. Lewat Composer-lah Laravel diunduh dan semua paket bawaannya dikelola. Kalau perintah composer tidak dikenali, biasanya PATH-nya belum ditambahkan ke sistem; ini salah satu hambatan pertama yang umum terjadi di Windows.

Environment Lokal

Untuk belajar, kita cukup butuh lingkungan lokal yang berisi PHP, Composer, dan MySQL. Pilihannya tergantung sistem operasi:

  • WindowsXAMPP paling umum dipakai pemula karena satu paket: PHP, MySQL, dan Apache. Alternatif yang lebih ringan dan cepat: Laragon.
  • macOSLaravel Valet atau Laravel Herd; ringan, tanpa panel berat, cocok untuk development sehari-hari.
  • Linux — install PHP dan Composer langsung dari package manager.

Yang penting diingat: apapun pilihannya, kebutuhan intinya sama — PHP, Composer, dan MySQL. Jangan terjebak terlalu lama memilih-milih tool; pakai yang paling cepat jalan di mesinmu.

Membuat Project Laravel

Setelah PHP dan Composer siap, membuat project Laravel baru cuma satu perintah:

composer create-project laravel/laravel nama-project
cd nama-project

Catatan jujur: proses pertama kali bisa terasa lama karena Composer mengunduh ratusan paket. Layar terlihat “diam” lama — itu normal, bukan hang. Setelah selesai, struktur folder di dalam project kira-kira begini (versi singkat):

  • app/ — kode inti aplikasi: Models, Controllers di app/Http/Controllers.
  • routes/routes/web.php adalah “pintu masuk” semua request dari browser.
  • resources/views/ — file tampilan Blade (HTML).
  • database/migrations/ — skema tabel dalam bentuk kode.
  • public/ — satu-satunya folder yang “dilihat” web server; index.php ada di sini.
  • .env — konfigurasi (database, APP_KEY).

Menjalankan Server

Laravel punya server bawaan untuk development, dijalankan lewat Artisan:

php artisan serve

Setelah itu buka http://127.0.0.1:8000 — kalau muncul halaman selamat datang Laravel, berarti project-mu sudah hidup. Dua hal yang sering kuhadapi di tahap ini: pesan minta APP_KEY di .env (biasanya sudah ter-generate saat create-project; kalau belum, jalankan php artisan key:generate), dan port 8000 yang sudah dipakai aplikasi lain — ganti dengan php artisan serve --port=8080.

Kesalahan yang Umum

  • Versi PHP terlalu tua — cek php -v, lalu samakan dengan syarat minimum di dokumentasi resmi.
  • Composer tidak dikenali — PATH belum diatur; cari “add Composer to PATH” saat instalasi.
  • Ekstensi PHP kurang — misalnya mbstring atau openssl; aktifkan di php.ini atau panel XAMPP/Laragon.
  • Lupa perbedaan folder — aku sering bingung “file mana yang harus diutak-atik”. Di episode-episode awal, 90% waktu kita habis di routes/, app/Http/Controllers, dan resources/views.

Kesimpulan

Di episode ini kita sudah punya project Laravel yang berjalan di browser. Bagian yang paling membingungkan bagiku di awal ternyata bukan sintaks, tapi peta mental: “request masuk lewat mana, lalu ke mana?” Jawaban singkatnya: browser → routes/web.php → Controller → View. Di episode berikutnya kita akan membedah alur itu satu per satu: routing dan controller pertama.

Sumber