Berpikir Sederhana dalam Koding: Kenapa Lo Harus Mikir Dulu Sebelum Tanya AI

Gue ngeliat pola yang mengkhawatirkan di developer zaman sekarang. Ada error → langsung copy paste ke ChatGPT. Mau bikin fitur → langsung "gimana caranya bikin X di React?" Mau debugging → "kenapa error ini?" Langsung. Tanpa mikir. Tanpa coba.

Gue gak anti AI. Gue pake Claude tiap hari buat nulis artikel dan bantu debug. Tapi ada beda antara pake AI sebagai tools dan pake AI sebagai pengganti otak.

Yang gue liat: junior dev makin sering skip langkah "mikir sederhana." Mereka langsung lompat ke solusi kompleks yang dikasih AI, tanpa nanya "apa ini sebenernya simple?" Atau "apa emang perlu serumit ini?"

Ini bukan artikel "AI itu jelek." Ini artikel tentang skill yang paling penting tapi paling jarang dilatih: berpikir sederhana.

---

Kasus 1: Filter Array 3 Level

Gue liat junior dev nulis ini:

// Pake AI, dapet solusi complex
const result = data
.filter(item => item.status === 'active')
.map(item => item.name)
.filter(name => name.startsWith('A'))
.reduce((acc, name) => {
acc[name] = name.length
return acc
}, {})

Kode-nya "jalan." Tapi pas ditanya "ini ngapain?" dia bingung jelasin. Karena code-nya di-generate AI, dia gak ngerti logikanya.

Simple solution: loop biasa, jelas, gak perlu 4 method chaining.

const result = {}
for (const item of data) {
if (item.status === 'active' && item.name.startsWith('A')) {
result[item.name] = item.name.length
}
}

4 baris. Gak pake .filter().map().filter().reduce(). Lebih cepet di-run, lebih gampang di-debug, lebih jelas maksudnya.

Bukan berarti .reduce() atau chaining jelek. Tapi kalau lo gak ngerti cara kerjanya dan cuma copy paste dari AI, lo gak belajar apa-apa. Dan kode lo jadi fragile - kalau ada bug, lo gak bisa fix karena gak paham.

---

Kasus 2: "Bikin REST API" Padahal Cuma Butuh 1 Endpoint

Gue pernah liat dev junior bikin struktur folder kayak gini buat project internal yang dipake 3 orang:

src/
├── controllers/
├── services/
├── repositories/
├── middlewares/
├── validators/
├── types/
├── utils/
└── config/

Dia pake clean architecture, dependency injection, unit test, integration test - semua best practice. Terus gue tanya: "ini API ngapain aja?"

Dia: "Cuma 1 endpoint, POST /submit, nerima JSON, nyimpen ke database."

Gue: "Kenapa gak 1 file aja? Lo butuh 7 folder buat 1 endpoint yang 50 baris?"

Dia: "Soalnya best practice katanya gitu."

Ini masalah yang gue sebut over-engineering karena takut. Dev junior takut dibilang "gak pake best practice" atau "gak professional." Jadi mereka niru struktur dari tutorial enterprise yang scalable untuk 1000 endpoint - padahal mereka cuma bikin script simpel.

Simple solution buat internal tool 3 user:

// api/submit.js - 1 file, 50 baris, selesai
app.post('/submit', async (req, res) => {
const { name, email, message } = req.body
if (!name || !email) return res.status(400).json({ error: 'required' })
await db.query('INSERT INTO submissions (name, email, message) VALUES ($1, $2, $3)', [name, email, message])
res.json({ ok: true })
})

Bukan berarti arsitektur complex itu salah. Tapi: pilih complexity sesuai kebutuhan, bukan karena "best practice." Best practice buat enterprise 1000 endpoint beda dengan best practice buat internal tool 3 user. Lo harus tau bedanya.

---

Kenapa Dev Makin Sering Skip Berpikir Sederhana

1. AI ngasih jawaban terlalu cepet.

Lo copy error → AI kasih jawaban dalam 5 detik. Lo gak sempet mikir "ini sebenernya error apa?" Lo langsung dapet fix. Tapi lo gak belajar. Besok error yang sama muncul, lo copy lagi ke AI.

Dulu sebelum AI: lo baca error message, lo googling, lo baca Stack Overflow 5 thread, lo nyoba 3 solusi yang gagal, baru yang ke-4 berhasil. Proses itu yang ngajarin lo debugging. Bukan fix-nya, tapi proses-nya.

2. "Best practice" culture.

Ada budaya "ini best practice" yang bikin dev takut mikir sendiri. "Clean architecture itu best practice" - iya buat app 500 file. Buat script 50 baris? Gak perlu. Tapi dev junior gak tau bedanya karena mereka gak pernah diajarin "kapan best practice itu overkill."

3. Ego - "gue harus pake teknologi keren."

Kadang dev pilih solusi complex bukan karena butuh, tapi karena kelihatan keren. "Gue pake Kafka" - padahal cukup pake database queue. "Gue pake microservices" - padahal 1 monolith cukup. "Gue pake Redis" - padahal in-memory cache doang.

Simple solution tuh keliatan "biasa aja." Gak ada yang bilang "wah keren" kalau lo pake for loop instead of reduce. Tapi simplicity itu underrated.

---

Filosofi "Simple First"

Yang gue pegang sekarang: selalu mulai dari solusi paling simple yang mungkin jalan, lalu tambah complexity kalau terbukti perlu.

Bukan: "pake best practice dulu, nanti disederhanain."

Tapi: "pake solusi paling simple dulu, nanti dikompleksin kalau butuh."

// Simple first - 1 file, 50 baris
app.post('/submit', handler)

// Nanti, kalau butuh:
// - Validasi complex? Tambah validator
// - Multiple endpoint? Pisah controller
// - Unit test? Tambah test
// Tapi mulai dari 1 file dulu

Ini beda sama "coding asal-asalan." Lo tetep harus nulis code yang bersih. Tapi jangan nambah layer abstraksi yang gak perlu sebelum ada bukti butuh.

YAGNI - You Ain't Gonna Need It. Prinsip dari Extreme Programming yang udah 20 tahun tapi makin relevan. Jangan nambah fitur/abstraksi sebelum terbukti perlu.

---

Simple Solution Checklist

Sebelum lo nanya ChatGPT atau googling, coba tanya diri lo:

1. "Ini bisa diselesain pake loop biasa?" - Banyak masalah yang keliatan complex tapi solusinya cuma for loop + if.

2. "Ini bisa pake built-in function?" - JavaScript punya .sort(), .filter(), .find(), .includes(). Python punya collections.defaultdict, itertools. Lo tau atau cuma AI yang tau?

3. "Apa masalah beneran atau cuma masalah persepsi?" - Kadang yang keliatan error complex ternyata cuma typo, missing import, atau environment issue. Coba baca error message-nya dulu, jangan langsung copy.

4. "Kalau saya nulis ini dari 0, gimana caranya?" - Sebelum lo pake AI generate 50 baris, coba pikirin: kalau lo nulis sendiri, lo mulai dari mana? Kalau lo gak tau mulai dari mana, AI gak akan ngajarin - AI cuma ngasih jawaban.

5. "Apa solusi 5 baris cukup?" - Kebanyakan masalah programming bisa diselesain dalam 5-10 baris. Kalau solusi lo 100 baris, kemungkinan lo over-engineering.

---

Contoh: Filter Unique Items

// Yang AI generate - complex, pake Map + spread + reduce
const unique = [...new Map(items.map(item => [item.id, item])).values()]

// Simple solution - Set, jelas, readable
const seen = new Set()
const unique = items.filter(item => {
if (seen.has(item.id)) return false
seen.add(item.id)
return true
})

Kedua solusi bener. Tapi yang pertama pake Map + spread + .values() - kalau lo gak paham cara kerja Map, lo gak akan bisa debug kalau error. Yang kedua: Set + filter - jelas, readable, gampang diubah.

---

Yang Bukan Berarti

Berpikir sederhana bukan berarti:
• Gak usah belajar arsitektur - tetap belajar, tapi jangan dipake sebelum butuh
• Gak usah pake AI - pake AI, tapi sebagai tools, bukan pengganti otak
• Code asal-asalan - code tetep harus bersih, cuma jangan nambah layer gak perlu
• Gak perlu best practice - best practice penting, tapi tau kapan harus dipake

Ini tentang keseimbangan. Lo harus tau kapan pake simple solution dan kapan butuh complex architecture.

---

Penutup yang Jujur

Gue juga dulu over-engineer. Bikin struktur folder 7 level buat project yang cuma 200 baris. Pake clean architecture buat script internal. Pake Redis buat cache yang sebenernya cukup new Map(). Gue pikir itu "profesional."

Sekarang gue mulai dari 1 file. Kalau file-nya > 300 baris, gue pisah. Kalau udah > 3 file yang related, gue bikin folder. Bukan karena "best practice," tapi karena code mulai susah di-navigate. Complexity harus driven by need, bukan oleh dogma.

Filosofi yang gue pelajarin: coding itu bukan tentang pake teknologi paling keren. Coding itu tentang nulis solusi yang berhasil, bisa di-maintain, dan lo paham cara kerjanya. Kalau AI nulis code yang lo gak ngerti, lo gak punya code - AI yang punya. Lo cuma operator copy paste.

Kalau lo junior dev yang baca ini: coba next time ada error, jangan langsung copy ke AI. Baca error-nya dulu. 5 menit. Coba pikir: "ini sebenernya masalah apa?" Kalau setelah 5 menit masih mentok, baru tanya AI. Bedanya: 5 menit itu yang ngajarin lo debugging. AI cuma ngasih jawaban.

Kalau lo senior dev: dorong junior lo buat mikir dulu sebelum tanya. Jangan kasih jawaban langsung. Kasih clue. Biar mereka nemu solusinya sendiri. Itu yang bikin mereka tumbuh.