Pernah nggak sih kamu ngerasa udah paham banget sama suatu masalah, terus pas bikin solusinya malah error mulu? Itu pengalaman aku minggu lalu waktu bikin bot otomatis buat ngecek stok barang di beberapa marketplace. Aku kira simpel: tinggal panggil API, parse JSON, beres. Tapi realitanya… detail kecil bikin pusing. Dari format tanggal yang beda-beda, rate limiting yang muncul tiba-tiba, sampai field null yang bikin fungsi collapse. Di situlah aku inget lagi esai legendaris John Salvatier tahun 2017: Reality has a surprising amount of detail.

Reality Has a Surprising Amount of Detail: Pukulan Telak Buat Programmer

Kamu mungkin udah sering dengar pepatah “the devil is in the details”. Tapi esai Salvatier ini ngingetin kita bahwa detail bukan cuma “setan kecil” yang nyebelin—tapi justru esensi dari realitas itu sendiri. Ia bilang, dunia nyata itu punya jauh lebih banyak detail daripada yang bisa kita tangkap di model mental kita. Setiap kali kita berpikir sudah mengerti, sebenarnya kita cuma memegang versi yang sangat disederhanakan.

Nah, di dunia AI agent yang lagi hype sekarang, prinsip ini jadi makin relevan. Banyak yang optimis bahwa AI bisa mengatasi kompleksitas dunia dengan prompt ajaib. Tapi realitanya, kalau agent nggak dilatih untuk menangani detail-detail kasuistis, ia akan gagal di production. Kayak bot marketplace-ku tadi—satu field null aja bikin seluruh pipeline ambruk.

Kenapa Esai Ini Kembali Viral di 2025?

Esai “Reality has a surprising amount of detail” awalnya ditulis buat komunitas LessWrong, tapi sekarang banyak dibahas lagi di kalangan AI/ML engineer. Kenapa? Karena ledakan AI generative bikin banyak orang ngeremehkan kompleksitas dunia nyata. Mereka pikir dengan GPT-4 atau Claude, semua bisa dihandle pakai natural language. Padahal agent yang beneran berfungsi harus tangguh terhadap detail-detail kecil yang nggak terprediksi.

John Salvatier ngasih contoh sederhana: bikin pintu. Kamu kira pintu itu cuma kayu, engsel, dan gagang. Tapi begitu kamu benar-benar bikin yang berkualitas, ternyata ada puluhan keputusan kecil: ketebalan kayu, jenis sekrup, toleransi pemasangan, hingga cara mengecat agar tidak mengelupas. Sama kayak software: kita sering anggap enteng integrasi API atau parsing data, sampai ketemu ratusan edge case yang bikin engineer begadang.

Ketika Kode Tidak Sejalan dengan Realitas (Contoh Nyata #1)

Waktu itu aku bikin fungsi normalisasi harga dari berbagai marketplace. Formatnya beda-beda: ada yang pakai titik, koma, spasi, atau bahkan string kosong. Aku bikin fungsi simpel:

def clean_price(raw: str) -> float:
    # Asumsi: input selalu string dengan format "Rp XX.XXX,XX"
    cleaned = raw.replace("Rp", "").replace(".", "").replace(",", ".")
    return float(cleaned)

Kelihatan rapi, kan? Begitu dipasang di production, gagal total. Kenapa? Karena realitanya:
- Ada yang formatnya "Rp 100.000 ,-"
- Ada yang pakai titik sebagai pemisah ribuan dan koma sebagai desimal, tapi ada juga yang kebalik.
- Ada yang ngasih null, hasilnya TypeError.
- Bahkan ada toko yang ngasih harga dalam dolar, tanpa mata uang!

Akhirnya aku nulis ulang fungsinya biar tahan banting:

```python
import re
from typing import Optional

def clean_price_v2(raw: Optional[str]) -> float:
    if raw is None or raw.strip() == "":
        raise ValueError("Harga tidak boleh kosong")
    
    # Buang semua simbol mata uang dan karakter non-numerik kecuali koma dan titik
    clean = re.sub(r"[^0-9,.]", "", raw.strip())
    
    # Cari tahu format desimal: kalau ada koma sebelum dua digit terakhir, itu desimal
    if "," in clean and clean.endswith(",00"):
        clean = clean.replace(",", "")  # ribuan, desimal nol
    elif "," in clean and len(clean.split(",")[-1]) == 2:
        clean = clean.replace(".", "").replace(",", ".")  # titik ribuan, koma desimal
    elif "." in clean and len(clean.split(".")[-1]) == 2:
        clean = clean.replace(",", "").replace(".", ".")  # kebalik
    else:
        clean = clean.replace(",", "").replace(".", "")  # tanpa desimal
    
    return float(clean)

# Test edge cases
try:
    print(clean_price_v2("Rp 1.234,56"))   # 1234.56
    print(clean_price_v2("1,234.56"))      # 1234.56
    print(clean_price_v2(None))            # exception
except ValueError as e:
    print(e)

Lihat betapa banyaknya detail yang harus ditangani? Inilah esensi dari "reality has a surprising amount of detail". Fungsi pertama cuma menangkap model ideal di kepalaku, bukan realitas di lapangan.

## Memperhitungkan Detail dengan Simulasi (Contoh Nyata #2)

Contoh lain: saat bikin scheduler otomatis buat nge-trigger task pagi hari. Awalnya aku bikin cron job simpel: `0 8 * * *`. Ternyata nggak semudah itu. Task-nya ngambil data dari API yang kadang down, kadang response-nya lambat. Kalau cron dijalankan pas API timeout, task gagal dan nggak diulang.

Alih-alih cron sederhana, aku belajar bahwa detail realitas butuh simulasi. Aku buat script Python dengan retry mechanism dan exponential backoff, plus logging. Ini potongannya:

```python
import requests
import time
import logging
from typing import Any

logging.basicConfig(level=logging.INFO, format="%(asctime)s - %(levelname)s - %(message)s")

def fetch_data(url: str, retries: int = 3, backoff: float = 2.0) -> Any:
    for attempt in range(retries):
        try:
            resp = requests.get(url, timeout=5)
            resp.raise_for_status()
            return resp.json()
        except requests.exceptions.RequestException as e:
            logging.warning(f"Percobaan {attempt+1} gagal: {e}")
            time.sleep(backoff ** attempt)  # exponential backoff
    raise RuntimeError("Gagal ambil data setelah beberapa kali percobaan")

# penggunaan
try:
    data = fetch_data("https://api.contoh.com/stok")
except RuntimeError:
    logging.error("Scheduler gagal, akan dicoba lagi di cycle berikutnya")

Di sini aku udah memperhitungkan kemungkinan jaringan bermasalah, server sibuk, dan berbagai hal kecil yang dulu kukira “ah nggak mungkin terjadi”. Ini baru satu API. Bayangkan kalau agent kamu harus mengintegrasikan puluhan API. Detailnya makin berlipat, dan tanpa penanganan seperti ini, agent cuma jadi angan-angan.

## Pelajaran Buat Developer Indonesia: Rangkul Detail, Jangan Dihindari

Dari dua contoh tadi, ada insight penting buat kita yang berkecimpung di tech, terutama developer Indonesia:

1. **Jangan percaya model mental mentah-mentah.** Setiap kali kamu bikin asumsi, tanya: “Apa buktinya?”. Coba eksplorasi edge case dengan unit test yang banyak. Di project AI agent, ini berarti uji agent kamu dengan skenario liar, bukan cuma happy path.

2. **Testing itu wajib, bukan opsional.** Kalau kamu ngoding pakai pendekatan TDD (Test-Driven Development), kamu akan dipaksa memikirkan detail sebelum implementasi. Automated testing kayak di [Belajar Python Automation](https://dovi.my.id/tutorial/belajar-python-automation/) bisa bantu banget.

3. **Gunakan framework yang sudah memikirkan detail.** Di ranah AI agent, banyak framework kayak LangChain, CrewAI, atau AutoGen yang udah punya banyak fitur retry, error handling, dan logging. Kamu bisa lihat perbandingannya di [5 Framework AI Agent Terbaik 2025](https://dovi.my.id/ai-agent/5-framework-ai-agent-terbaik-2025/). Dengan begini, kamu nggak perlu re-invent the wheel.

4. **Detail sering kali jadi keunggulan kompetitif.** Startup atau tools yang menang adalah yang paling aware sama pain points kecil pengguna. Selidikilah flow pengguna sampai ke atom terkecil, dan kamu akan temukan opportunity.

## Mulai dari Sekarang, Perhatikan Detail!

Esai John Salvatier adalah tamparan halus bahwa kita harus selalu rendah hati menghadapi realitas. Di era AI sekarang, overconfidence justru bahaya. Jangan cuma ngandelin prompt canggih; bangun sistem yang resilient terhadap detail kecil.

Kalau kamu lagi develop AI agent atau software apa pun, coba deh audit: udah berapa banyak edge case yang kamu tangani? Apakah kamu cuma ngandelin mental model ideal? Atau sudah benar-benar turun ke lapangan melihat data nyata?

Kita sering terjebak sama abstraksi yang rapi, tapi realita punya detail mengejutkan yang cuma bisa ditaklukkan dengan ketelitian—plus kopi pahit tentunya.

Kalau kamu punya pengalaman lucu atau pahit tentang detail yang merusak rencana, aku pengen denger! Atau kalau kamu lagi riset AI agent dan butuh masukan teknis, jangan sungkan buat diskusi. Email langsung aja ke **kontak@dovi.my.id**. Siapa tahu kita bisa ngobrol seru sambil nyari solusi buat detail-detail yang nyeleneh itu.