Pelajari cara menghemat token Claude AI saat vibe coding Laravel 12 dengan tips praktis dan workflow yang efisien. Studi kasus menggunakan proyek Pesantren Digital untuk developer Indonesia yang ingin maximize produktivitas tanpa boros budget.
Bagian 1: Kenapa Token Itu Mahal & Cara Kerja Claude
Kemarin ada student BuildWithAngga DM saya: "Mas Angga, kok saya vibe coding Laravel pakai Claude, baru 2 jam udah habis limit? Padahal baru bikin 3 controller doang."
Dan ternyata bukan dia doang yang ngalamin ini.
Setelah saya review cara dia prompting, masalahnya klasik: copy-paste seluruh file tanpa filter, prompt bertele-tele, dan satu chat dipake untuk semua hal dari bikin migration sampai debugging deployment.
Vibe coding dengan Claude AI itu powerful banget. Tapi kalau caranya salah, token habis sebelum fitur selesai. Di artikel ini, saya akan share tips yang sudah saya pakai sendiri untuk build berbagai project — dan kita akan pakai proyek Pesantren Digital sebagai studi kasus.
Pesantren Digital ini sistem manajemen lengkap: data santri, pembayaran SPP, absensi, manajemen kamar, sampai laporan untuk wali santri. Kompleksitasnya pas untuk ilustrasi berbagai skenario vibe coding.
Apa Itu Token?
Sebelum bahas tips, kita perlu paham dulu apa itu token.
Token adalah unit terkecil yang diproses oleh AI. Bukan per-kata, tapi per-potongan kata. Satu token kira-kira setara 4 karakter dalam bahasa Inggris. Untuk Bahasa Indonesia, biasanya lebih boros karena kata-kata kita cenderung lebih panjang dan tidak ada di vocabulary dasar model.
Contoh konkret:
"Hello" = 1 token
"Assalamualaikum" = 4-5 tokens
"PembayaranSppController" = 6-7 tokens
Kenapa ini penting? Karena Anda bayar per-token. Claude menghitung dua jenis token: input tokens (semua yang Anda kirim termasuk context) dan output tokens (response dari Claude). Output tokens biasanya lebih mahal dari input.
Jadi kalau Anda minta Claude generate file 500 baris yang sebenarnya bisa 100 baris, Anda bayar 5x lebih mahal untuk output yang sama fungsinya.
Cara Claude "Membaca" Context
Ini yang banyak orang tidak sadar: Claude membaca seluruh conversation setiap kali memberikan response.
Bayangkan Claude seperti orang yang harus baca ulang semua chat dari awal setiap kali mau reply. Message pertama, kedua, ketiga, sampai message terakhir — semuanya dibaca ulang.
[Message 1: 500 tokens]
[Message 2: 800 tokens]
[Message 3: 1200 tokens]
[Message 4: 600 tokens]
...
[Message 20: 400 tokens]
Total context yang dibaca untuk response ke-21:
500 + 800 + 1200 + 600 + ... + 400 = ribuan tokens
Makin panjang conversation, makin banyak token yang dipakai per-response. Chat yang sudah 50 messages bisa makan 10x lebih banyak token dibanding chat baru untuk task yang sama.
Claude punya context window sampai 200K tokens untuk Opus. Kedengarannya banyak, tapi kalau Anda copy-paste 10 file Laravel sekaligus (masing-masing 200-500 baris), itu bisa habis 20-30K tokens hanya untuk satu prompt.
Kesalahan Umum yang Bikin Boros Token
Dari pengalaman mentoring ratusan developer, ini kesalahan paling sering:
1. Copy-paste seluruh file tanpa filter
Anda mau tambah 1 method di controller yang sudah 300 baris. Tapi instead of paste hanya method yang relevan, Anda paste seluruh file. Itu 300 baris yang sebenarnya tidak perlu dibaca Claude.
2. Tidak mulai chat baru setelah topik berbeda
Selesai bikin modul Santri, langsung lanjut bikin modul Pembayaran di chat yang sama. Context modul Santri yang sudah tidak relevan tetap dibaca di setiap response berikutnya.
3. Prompt terlalu verbose
// BAD - 150 tokens
Halo Claude, saya sedang mengerjakan project Laravel untuk sistem
pesantren. Saya sudah membuat beberapa model dan sekarang saya ingin
membuat controller untuk mengelola data santri. Controller ini harus
bisa menampilkan semua santri, menampilkan detail satu santri,
membuat santri baru, mengupdate data santri, dan menghapus santri.
Tolong buatkan controllernya ya.
// GOOD - 40 tokens
Buat SantriController dengan method: index, show, store, update, destroy.
Pattern: sama seperti controller sebelumnya.
Hasil sama, token beda 3-4x lipat.
4. Minta generate ulang file yang sudah ada
Anda sudah punya SantriController dengan 5 method. Mau tambah 1 method baru. Instead of minta tambah method itu saja, Anda minta "buatkan ulang SantriController dengan tambahan method export". Claude generate ulang 6 method, padahal 5 sudah ada.
5. Tidak pakai referensi
Setiap bikin controller baru, Anda jelaskan ulang response format, error handling pattern, validation approach. Padahal semua sudah sama dengan controller sebelumnya.
Baseline: Berapa Token untuk Task Umum?
Supaya punya gambaran, ini estimasi token untuk task umum di proyek Laravel (tanpa optimasi):
| Task | Estimasi Token |
|---|---|
| 1 Migration + Model sederhana | 1.500 - 2.500 |
| 1 CRUD Controller lengkap | 3.000 - 5.000 |
| 1 Repository + Service | 2.000 - 3.500 |
| 1 FormRequest dengan validation | 800 - 1.500 |
| Debug 1 error dengan context | 2.000 - 4.000 |
| 1 Modul lengkap (5-7 files) | 12.000 - 18.000 |
Untuk proyek Pesantren Digital yang punya sekitar 10 modul utama, tanpa optimasi bisa habis 120.000 - 180.000 tokens.
Target kita: hemat 40-60% dengan tips di artikel ini.
Artinya proyek yang sama bisa selesai dengan 50.000 - 70.000 tokens. Itu beda yang signifikan untuk budget dan juga untuk kecepatan development (karena less back-and-forth dengan Claude).
Quick Wins Sebelum Lanjut
Kalau Anda sedang di tengah project dan butuh hasil cepat, ini 3 quick wins yang bisa langsung dipraktekkan:
Quick Win 1: Mulai chat baru untuk setiap modul
Selesai modul Santri? Start fresh chat untuk modul Pembayaran. Jangan lanjutkan di chat yang sama.
Quick Win 2: Constraint output di setiap prompt
Tambahkan di akhir prompt: "Output: code only, tanpa penjelasan, format compact."
Quick Win 3: Reference, jangan repeat
Instead of jelaskan pattern dari awal, tulis: "Pattern sama seperti SantriController yang sudah dibuat."
Tiga hal ini saja bisa hemat 20-30% token langsung.
Di bagian selanjutnya, kita akan bahas persiapan project yang bikin setiap prompt jadi lebih efisien. Investasi 30 menit di awal bisa hemat berjam-jam dan ribuan token di sepanjang development.
Bagian 2: Persiapan Project yang Bikin Prompt Efisien
Prinsip utama di bagian ini: investasi di awal, hemat di sepanjang jalan.
Analoginya seperti bikin rumah. Anda bisa langsung manggil tukang dan improvisasi setiap hari. Atau Anda bisa spend waktu bikin blueprint dulu, lalu tukang tinggal eksekusi dengan jelas.
Approach pertama kelihatan lebih cepat di awal, tapi total waktu dan biaya pasti lebih besar. Sama dengan vibe coding — sedikit effort untuk setup documentation bisa save ribuan token di setiap prompt setelahnya.
Buat Project Brief yang Ringkas tapi Lengkap
Project brief adalah dokumen singkat yang menjelaskan project Anda. Fungsinya: setiap kali mulai chat baru, Anda tinggal attach file ini dan Claude langsung punya context yang cukup.
Ini contoh BAD brief yang sering saya lihat:
Saya sedang membuat aplikasi untuk pesantren. Aplikasinya nanti akan
digunakan oleh admin pesantren untuk mengelola data santri, pembayaran,
absensi, dan lain-lain. Saya menggunakan Laravel sebagai framework
backend dan nanti akan ada frontend-nya juga tapi itu nanti dulu.
Untuk database saya pakai MySQL dan...
(300+ kata yang bisa diringkas jadi 50 kata)
Ini contoh GOOD brief untuk Pesantren Digital:
# PROJECT BRIEF: Pesantren Digital API
## Stack
- Laravel 12 (API Only)
- MySQL 8.0
- Sanctum Authentication
- Spatie Permission (roles: admin, guru, bendahara)
## Architecture
- Service Repository Pattern
- Form Request Validation
- API Resource untuk response formatting
## Core Modules
1. Santri (CRUD + transfer kamar)
2. Kamar & Gedung (master data)
3. Wali Santri (CRUD + link ke santri)
4. Pembayaran SPP (create, mark paid, history)
5. Absensi (daily record, rekap bulanan)
## Response Format
Success: { "success": true, "data": {...}, "message": "..." }
Error: { "success": false, "errors": {...}, "message": "..." }
Pagination: { "data": [...], "meta": { "current_page", "total", ... } }
## Current State
- Authentication sudah selesai
- Base Controller dengan response helper sudah ada
- Modul Santri & Kamar sudah selesai
Brief ini cukup untuk Claude memahami:
- Tech stack yang dipakai
- Pattern arsitektur
- Scope modules
- Format response standar
- Progress saat ini
Simpan sebagai PROJECT-BRIEF.md di root project. Setiap mulai chat baru, attach file ini.
Definisikan Conventions Sekali, Reuse Selamanya
Conventions adalah aturan-aturan yang konsisten di seluruh project. Kalau Anda tidak definisikan, Claude akan assume — dan assumption-nya mungkin berbeda setiap chat.
Buat file CONVENTIONS.md:
# CONVENTIONS: Pesantren Digital
## Naming
- Model: singular PascalCase (Santri, PembayaranSpp, WaliSantri)
- Controller: {Model}Controller (SantriController)
- Repository: {Model}Repository
- Service: {Model}Service
- FormRequest: {Action}{Model}Request (StoreSantriRequest, UpdateSantriRequest)
- Route: kebab-case plural (/api/v1/santri, /api/v1/pembayaran-spp)
## File Locations
- Controllers: app/Http/Controllers/Api/V1/
- Repositories: app/Repositories/
- Services: app/Services/
- FormRequests: app/Http/Requests/
## Response Helpers (di BaseController)
- return $this->success($data, $message, $code)
- return $this->error($message, $errors, $code)
- return $this->paginate($query, $resource)
## Validation Messages
- Bahasa Indonesia
- Format: "{field} {rule}" → "Nama wajib diisi", "Email format tidak valid"
## Error Handling
- Custom exceptions di app/Exceptions/
- Handler return JSON untuk API routes
- Log error ke daily log
## Database
- Soft deletes untuk semua master data
- Timestamps selalu ada
- Foreign key dengan naming: {table_singular}_id
Dengan file ini, prompt Anda bisa jadi sangat singkat:
Buat PembayaranSppController.
Follow conventions yang sudah ada.
Methods: index, store, show, markAsPaid.
Claude akan pakai naming, location, response format sesuai conventions. Tanpa file ini, Anda harus jelaskan semua itu di setiap prompt.
Siapkan ERD dalam Format Text
ERD (Entity Relationship Diagram) biasanya berupa gambar. Tapi untuk Claude, text-based ERD jauh lebih efisien karena:
- Token lebih sedikit dibanding describe gambar
- Claude bisa langsung "baca" relasi
- Mudah di-copy-paste ke prompt
Format yang saya rekomendasikan:
# ERD: Pesantren Digital
## Tables & Fields
santri
- id: bigint PK
- nis: string unique
- nama: string
- jenis_kelamin: enum(L,P)
- tanggal_lahir: date
- alamat: text nullable
- kamar_id: FK → kamar
- wali_id: FK → wali_santri
- status: enum(aktif,alumni,keluar) default:aktif
- timestamps, soft_deletes
kamar
- id: bigint PK
- nama: string
- gedung_id: FK → gedung
- kapasitas: int
- timestamps
gedung
- id: bigint PK
- nama: string
- timestamps
wali_santri
- id: bigint PK
- nama: string
- phone: string
- email: string nullable
- alamat: text nullable
- timestamps
pembayaran_spp
- id: bigint PK
- santri_id: FK → santri
- bulan: tinyint (1-12)
- tahun: year
- nominal: decimal(12,0)
- status: enum(pending,paid) default:pending
- paid_at: timestamp nullable
- created_by: FK → users nullable
- timestamps
absensi
- id: bigint PK
- santri_id: FK → santri
- tanggal: date
- status: enum(hadir,izin,sakit,alpha)
- keterangan: string nullable
- recorded_by: FK → users
- timestamps
## Relations
- santri belongsTo kamar, wali_santri
- santri hasMany pembayaran_spp, absensi
- kamar belongsTo gedung
- kamar hasMany santri
- wali_santri hasMany santri
Dengan ERD ini, Claude bisa langsung generate migration yang benar, model dengan relasi lengkap, dan validation rules yang sesuai field types.
Buat Shell Files di Awal Project
Konsep shell files: buat file kosong dengan struktur dasar, tapi belum ada implementasi. Claude tinggal "mengisi" shell yang sudah ada.
Contoh shell untuk Repository:
<?php
namespace App\\Repositories;
use App\\Models\\Santri;
class SantriRepository
{
public function __construct(
protected Santri $model
) {}
// Methods akan diimplementasikan sesuai kebutuhan
}
Contoh shell untuk Service:
<?php
namespace App\\Services;
use App\\Repositories\\SantriRepository;
class SantriService
{
public function __construct(
protected SantriRepository $repository
) {}
// Business logic akan diimplementasikan di sini
}
Register semua shell di AppServiceProvider:
public function register(): void
{
// Repositories
$this->app->bind(SantriRepository::class);
$this->app->bind(PembayaranSppRepository::class);
$this->app->bind(AbsensiRepository::class);
// Services
$this->app->bind(SantriService::class);
$this->app->bind(PembayaranSppService::class);
$this->app->bind(AbsensiService::class);
}
Benefit shell files:
- Claude tahu file sudah exist — tidak perlu create from scratch
- Namespace dan dependencies sudah benar
- Pattern konsisten di semua files
- Prompt lebih singkat: "Implement method X di SantriRepository"
Routes Blueprint
Sebelum coding, list semua routes yang akan dibuat:
# ROUTES BLUEPRINT
## Santri
GET /api/v1/santri → index (list + pagination + filter)
POST /api/v1/santri → store
GET /api/v1/santri/{id} → show
PUT /api/v1/santri/{id} → update
DELETE /api/v1/santri/{id} → destroy
POST /api/v1/santri/{id}/transfer-kamar → transferKamar
## Pembayaran SPP
GET /api/v1/pembayaran-spp → index (filter: bulan, tahun, status)
POST /api/v1/pembayaran-spp → store
GET /api/v1/pembayaran-spp/{id} → show
PATCH /api/v1/pembayaran-spp/{id}/mark-paid → markAsPaid
GET /api/v1/santri/{id}/pembayaran → getBySantri
## Absensi
GET /api/v1/absensi → index (filter: tanggal, status)
POST /api/v1/absensi/batch → storeBatch (input banyak santri sekaligus)
GET /api/v1/absensi/rekap → rekap (summary per bulan)
GET /api/v1/santri/{id}/absensi → getBySantri
Routes blueprint membantu:
- Claude tahu endpoint apa saja yang dibutuhkan
- Tidak perlu explain route naming di setiap prompt
- Konsistensi URL pattern
Checklist Persiapan (Copy-Paste Ready)
Sebelum mulai vibe coding project baru, pastikan checklist ini done:
## Pre-Vibe-Coding Checklist
[ ] PROJECT-BRIEF.md
- Stack & architecture (max 100 kata)
- Core modules list
- Response format standar
- Current state
[ ] CONVENTIONS.md
- Naming conventions
- File locations
- Response helpers
- Validation message format
- Error handling approach
[ ] ERD.md
- All tables dengan fields & types
- Foreign key relations
- Enum values
[ ] Shell Files
- Repository shells untuk setiap model
- Service shells
- Registered di AppServiceProvider
[ ] ROUTES-BLUEPRINT.md
- All endpoints per module
- HTTP method + URL + action name
[ ] .env.example
- All required variables
- Comments untuk yang perlu setup khusus
Total effort: 1-2 jam di awal project.
Total savings: 40-60% token di seluruh development cycle.
Worth it? Absolutely.
Di bagian selanjutnya, kita akan masuk ke teknik prompting spesifik — bagaimana struktur prompt yang hemat token tapi tetap menghasilkan output akurat.
Bagian 3: Teknik Prompting Hemat Token
Sekarang masuk ke inti artikel — teknik prompting yang sudah teruji hemat token tanpa mengorbankan kualitas output. Prinsip dasarnya: 20% effort di prompt, 80% akurasi di hasil.
Semua teknik ini akan saya ilustrasikan dengan contoh konkret dari proyek Pesantren Digital.
Teknik 1: State-First Prompting
Kesalahan paling umum adalah langsung minta sesuatu tanpa kasih tahu kondisi saat ini. Claude harus assume, dan assumption seringkali salah.
BAD Prompt:
Buatkan controller untuk santri dengan fitur CRUD lengkap.
Controllernya harus bisa handle validasi dan return response JSON.
Problem:
- Claude tidak tahu model sudah ada atau belum
- Tidak tahu repository/service pattern dipakai atau tidak
- Tidak tahu response format yang diinginkan
- Akan generate semuanya from scratch
GOOD Prompt:
STATE:
- Model Santri sudah ada dengan relasi: belongsTo(Kamar), hasMany(PembayaranSpp)
- SantriRepository sudah ada dengan methods: getAll(), findById(), create(), update(), delete()
- SantriService sudah ada, memanggil repository
- Response format: $this->success($data) dan $this->error($message)
TASK: Buat SantriController
- Methods: index (dengan pagination), show, store, update, destroy
- Inject SantriService
- Gunakan StoreSantriRequest dan UpdateSantriRequest untuk validasi
OUTPUT: Code only, tanpa penjelasan
Dengan state yang jelas:
- Claude tahu apa yang sudah exist
- Tahu dependency yang harus di-inject
- Tahu pattern yang harus diikuti
- Output langsung akurat, tidak perlu revisi
Teknik 2: Reference, Don't Repeat
Setelah Anda build satu komponen, komponen berikutnya yang mirip tidak perlu dijelaskan dari awal. Cukup reference yang sudah ada.
BAD Approach:
// Prompt 1 - SantriController (panjang, detail)
// Prompt 2 - KamarController (panjang lagi, detail lagi, padahal pattern sama)
// Prompt 3 - GedungController (panjang lagi...)
GOOD Approach:
// Prompt 1 - SantriController
[detail lengkap karena ini yang pertama]
// Prompt 2 - KamarController
Buat KamarController dengan pattern yang sama seperti SantriController.
Perbedaan:
- Model: Kamar
- Service: KamarService
- Relasi di show: load gedung
- Filter di index: gedung_id
// Prompt 3 - GedungController
Buat GedungController, pattern sama seperti Kamar.
Perbedaan: tidak ada relasi yang perlu di-load.
Savings: ~500-800 tokens per controller setelah yang pertama.
Untuk proyek Pesantren Digital dengan 10+ controllers, ini bisa hemat 5.000-8.000 tokens total.
Teknik 3: Incremental Building
Jangan minta semuanya sekaligus. Pecah jadi steps yang bisa di-review per-step.
BAD Prompt:
Buatkan modul pembayaran SPP lengkap dengan:
- Migration
- Model dengan relasi
- Repository dengan semua methods
- Service dengan business logic
- Controller dengan semua endpoints
- FormRequest untuk validasi
- API Resource untuk formatting
- Routes
- Seeder untuk testing
Problem:
- Output sangat panjang (banyak token)
- Kalau ada error di satu bagian, harus minta generate ulang semuanya
- Sulit review karena terlalu banyak
GOOD Approach — Pecah jadi 4-5 prompts:
// Prompt 1
Buat migration untuk pembayaran_spp dengan fields:
- santri_id (FK)
- bulan (tinyint 1-12)
- tahun (year)
- nominal (decimal 12,0)
- status (enum: pending, paid)
- paid_at (nullable timestamp)
- created_by (FK nullable ke users)
- timestamps
// Prompt 2
Migration done. Sekarang buat Model PembayaranSpp:
- Fillable sesuai migration
- Casts: paid_at → datetime, nominal → integer
- Relasi: belongsTo Santri, belongsTo User (creator)
- Scope: scopePending(), scopePaid(), scopeByPeriod($bulan, $tahun)
// Prompt 3
Model done. Buat PembayaranSppRepository:
- create(array $data)
- findById(int $id)
- getByPeriod(int $bulan, int $tahun, ?string $status)
- getBySantri(int $santriId)
- markAsPaid(PembayaranSpp $pembayaran)
Pattern sama seperti SantriRepository.
// Prompt 4
Repository done. Buat PembayaranSppService:
- Inject PembayaranSppRepository
- createPembayaran() — validasi tidak boleh double di bulan/tahun yang sama
- markAsPaid() — update status dan paid_at
- getPembayaranSantri()
// Prompt 5
Service done. Buat Controller + Routes + FormRequests.
[detail endpoints]
Benefits:
- Setiap step bisa di-review dan test
- Kalau ada error, fix di step itu saja
- Total tokens mungkin sama atau sedikit lebih, tapi akurasi jauh lebih tinggi
- Less rework = less tokens in total
Teknik 4: Output Constraints
Secara default, Claude akan memberikan penjelasan, komentar, dan formatting yang verbose. Untuk coding tasks, ini seringkali tidak perlu.
Tambahkan constraints di setiap prompt:
OUTPUT CONSTRAINTS:
- Code only, tanpa penjelasan sebelum/sesudah
- Minimal comments (hanya untuk logic kompleks)
- No blank lines berlebihan
- Skip boilerplate docblocks
Contoh perbedaan output:
Tanpa constraint (150 baris):
<?php
namespace App\\Http\\Controllers\\Api\\V1;
use App\\Http\\Controllers\\Controller;
use App\\Services\\SantriService;
// ... imports
/**
* Class SantriController
*
* This controller handles all CRUD operations for Santri entity.
* It uses SantriService for business logic and follows REST conventions.
*
* @package App\\Http\\Controllers\\Api\\V1
*/
class SantriController extends Controller
{
/**
* The santri service instance.
*
* @var SantriService
*/
protected SantriService $service;
/**
* Create a new controller instance.
*
* @param SantriService $service
* @return void
*/
public function __construct(SantriService $service)
{
$this->service = $service;
}
/**
* Display a listing of santri.
*
* This method returns a paginated list of all santri records.
* It supports filtering and sorting through query parameters.
*
* @param Request $request
* @return JsonResponse
*/
public function index(Request $request): JsonResponse
{
// ... implementation
}
// ... dan seterusnya dengan docblocks panjang
}
Dengan constraint (70 baris):
<?php
namespace App\\Http\\Controllers\\Api\\V1;
use App\\Http\\Controllers\\Controller;
use App\\Services\\SantriService;
use App\\Http\\Requests\\StoreSantriRequest;
use App\\Http\\Requests\\UpdateSantriRequest;
use App\\Http\\Resources\\SantriResource;
use Illuminate\\Http\\Request;
class SantriController extends Controller
{
public function __construct(
protected SantriService $service
) {}
public function index(Request $request)
{
$data = $this->service->getAll($request->all());
return $this->paginate($data, SantriResource::class);
}
public function store(StoreSantriRequest $request)
{
$santri = $this->service->create($request->validated());
return $this->success(new SantriResource($santri), 'Santri berhasil ditambahkan', 201);
}
public function show(int $id)
{
$santri = $this->service->findById($id);
return $this->success(new SantriResource($santri));
}
public function update(UpdateSantriRequest $request, int $id)
{
$santri = $this->service->update($id, $request->validated());
return $this->success(new SantriResource($santri), 'Santri berhasil diupdate');
}
public function destroy(int $id)
{
$this->service->delete($id);
return $this->success(null, 'Santri berhasil dihapus');
}
}
Savings: 50%+ output tokens untuk hasil yang functionally identical.
Teknik 5: Template Reuse
Untuk komponen yang pattern-nya sama (FormRequest, Resource, Repository), minta Claude generate template sekali, lalu reuse.
Prompt 1 — Buat Template:
Buat template FormRequest untuk project ini.
Template harus include:
- authorize() return true
- rules() dengan format array
- messages() dengan Bahasa Indonesia
Contoh untuk StoreSantriRequest dengan rules:
- nis: required, unique
- nama: required, max:255
- kamar_id: required, exists
Saya akan reuse pattern ini untuk semua FormRequest.
Output template yang bisa di-reuse:
<?php
namespace App\\Http\\Requests;
use Illuminate\\Foundation\\Http\\FormRequest;
class StoreSantriRequest extends FormRequest
{
public function authorize(): bool
{
return true;
}
public function rules(): array
{
return [
'nis' => ['required', 'string', 'unique:santri,nis'],
'nama' => ['required', 'string', 'max:255'],
'kamar_id' => ['required', 'exists:kamar,id'],
];
}
public function messages(): array
{
return [
'nis.required' => 'NIS wajib diisi',
'nis.unique' => 'NIS sudah terdaftar',
'nama.required' => 'Nama wajib diisi',
'nama.max' => 'Nama maksimal 255 karakter',
'kamar_id.required' => 'Kamar wajib dipilih',
'kamar_id.exists' => 'Kamar tidak valid',
];
}
}
Prompt berikutnya cukup:
Isi template FormRequest untuk StorePembayaranSppRequest:
- santri_id: required, exists
- bulan: required, integer, between:1,12
- tahun: required, digits:4
- nominal: required, numeric, min:0
Claude akan generate dengan pattern yang sama, tanpa perlu explain ulang structure.
Teknik 6: Diff-Only Updates
Saat update file yang sudah ada, jangan minta regenerate seluruh file. Minta diff atau method baru saja.
BAD Prompt:
Ini SantriService saat ini: [paste 100 baris]
Tambahkan method transferKamar(Santri $santri, Kamar $kamarBaru).
Buatkan ulang seluruh file dengan method baru.
GOOD Prompt:
Tambahkan method ini ke SantriService:
transferKamar(Santri $santri, Kamar $kamarBaru): Santri
- Validasi kamar baru tidak sama dengan kamar lama
- Validasi kapasitas kamar baru masih tersedia
- Update kamar_id santri
- Return updated santri
OUTPUT: Method baru saja, bukan seluruh file
Output:
public function transferKamar(Santri $santri, Kamar $kamarBaru): Santri
{
if ($santri->kamar_id === $kamarBaru->id) {
throw new ValidationException('Santri sudah berada di kamar ini');
}
if ($kamarBaru->santri()->count() >= $kamarBaru->kapasitas) {
throw new ValidationException('Kamar sudah penuh');
}
$santri->update(['kamar_id' => $kamarBaru->id]);
return $santri->fresh();
}
Savings: 70-80% tokens untuk file updates.
Teknik 7: Batch Similar Tasks
Kalau ada beberapa task yang mirip, gabungkan dalam satu prompt.
BAD — 3 prompts terpisah:
// Prompt 1
Buat migration untuk tabel kamar...
// Prompt 2
Buat migration untuk tabel gedung...
// Prompt 3
Buat migration untuk tabel wali_santri...
GOOD — 1 prompt batched:
Buat 3 migrations sekaligus:
1. create_gedung_table
- nama: string
2. create_kamar_table
- nama: string
- gedung_id: FK
- kapasitas: integer
3. create_wali_santri_table
- nama: string
- phone: string
- email: nullable string
- alamat: nullable text
Semua dengan timestamps. Format compact.
Savings: Overhead prompt berkurang karena context hanya dibaca sekali.
Cheatsheet Prompt Patterns
Simpan ini untuk reference cepat:
## Pattern: Create New Component
STATE: [list existing files/components]
TASK: Create [component name]
SPEC: [specifications]
CONSTRAINT: Code only, compact format
## Pattern: Update Existing File
FILE: [path]
CURRENT STATE: [relevant snippet atau "method X sudah ada"]
ADD: [what to add]
OUTPUT: New code only, bukan seluruh file
## Pattern: Follow Existing Pattern
REFERENCE: [previous component name]
CREATE: [new component]
DIFFERENCES:
- [diff 1]
- [diff 2]
## Pattern: Batch Creation
CREATE [N] [component type]:
1. [Name 1]
- [specs]
2. [Name 2]
- [specs]
FORMAT: Compact, no explanations
## Pattern: Template Fill
TEMPLATE: [reference template atau "seperti X yang sudah dibuat"]
FILL FOR: [new component name]
VALUES:
- field1: [rules]
- field2: [rules]
Dengan 7 teknik ini, Anda bisa hemat 40-60% token untuk task yang sama. Di bagian selanjutnya, kita akan bahas workflow lengkap — bagaimana menggabungkan semua teknik ini dalam alur development yang efisien.
Bagian 4: Workflow Vibe Coding yang Efisien
Teknik prompting sudah dikuasai. Sekarang kita gabungkan semuanya dalam workflow yang sistematis. Mindset utamanya: conversation management — setiap chat punya fokus, ada batasan kapan harus mulai baru, dan ada checkpoint untuk tracking progress.
Aturan Emas: 1 Chat = 1 Fokus
Ini aturan paling penting yang sering dilanggar.
Satu chat sebaiknya fokus pada satu modul atau satu concern. Jangan campur:
- Bikin modul Santri + debugging error Pembayaran + tanya tentang deployment
- CRUD Santri + CRUD Kamar + CRUD Gedung + CRUD Pembayaran
Kenapa? Karena setiap response baru, Claude membaca seluruh history. Kalau chat sudah berisi 30 messages tentang berbagai topik, setiap response baru membaca 30 messages yang sebagian besar tidak relevan.
Rule of thumb:
- 1 modul CRUD lengkap = 1 chat
- Debugging specific error = 1 chat terpisah
- Refactoring existing code = 1 chat terpisah
- Setup/config = 1 chat terpisah
Workflow Step-by-Step: Modul Pembayaran SPP
Mari kita praktekkan dengan membangun modul Pembayaran SPP dari Pesantren Digital. Saya akan tunjukkan exact prompts dan flow-nya.
Step 1: Mulai Chat Baru dengan Context Minimal
PROYEK: Pesantren Digital API
STACK: Laravel 12, MySQL, Sanctum, Service Repository Pattern
MODUL BARU: Pembayaran SPP
ERD:
pembayaran_spp
- id: bigint PK
- santri_id: FK → santri
- bulan: tinyint (1-12)
- tahun: year
- nominal: decimal(12,0)
- status: enum(pending,paid) default pending
- paid_at: timestamp nullable
- created_by: FK → users nullable
- timestamps
EXISTING:
- Model Santri sudah ada
- BaseController dengan $this->success() dan $this->error()
- Pattern yang sama sudah diterapkan di modul Santri
TASK 1: Buat migration pembayaran_spp
OUTPUT: Code only
Claude akan generate migration yang tepat karena:
- Tahu exact fields dan types dari ERD
- Tahu foreign key ke table yang sudah exist
- Tidak perlu assume apapun
Step 2: Lanjut ke Model (Masih Chat yang Sama)
Setelah migration selesai dan Anda sudah review:
Migration done ✓
TASK 2: Buat Model PembayaranSpp
- Fillable sesuai migration (exclude id, timestamps)
- Casts: nominal → integer, paid_at → datetime
- Relations: belongsTo Santri, belongsTo User (as creator)
- Scopes:
- scopePending($query)
- scopePaid($query)
- scopeByPeriod($query, $bulan, $tahun)
- scopeBySantri($query, $santriId)
OUTPUT: Code only
Step 3: Repository
Model done ✓
TASK 3: Buat PembayaranSppRepository
Pattern sama seperti SantriRepository yang sudah ada.
Methods:
- getAll(array $filters) — filter by bulan, tahun, status, santri_id dengan pagination
- findById(int $id) — with santri relation
- create(array $data)
- getBySantri(int $santriId) — history pembayaran santri
- markAsPaid(PembayaranSpp $pembayaran, int $userId)
OUTPUT: Code only
Notice: saya reference "pattern sama seperti SantriRepository" — Claude tahu struktur, dependency injection, dan style yang harus diikuti.
Step 4: Service dengan Business Logic
Repository done ✓
TASK 4: Buat PembayaranSppService
Inject: PembayaranSppRepository
Methods:
- getAll(array $filters) — pass ke repository
- create(array $data) — validasi: tidak boleh double entry untuk santri + bulan + tahun yang sama
- findById(int $id)
- getBySantri(int $santriId)
- markAsPaid(int $id, int $userId) — throw exception jika sudah paid
Custom exception yang dibutuhkan:
- PembayaranAlreadyExistsException
- PembayaranAlreadyPaidException
OUTPUT: Service + exceptions, code only
Step 5: Controller, Routes, FormRequests
Service done ✓
TASK 5: Buat PembayaranSppController + FormRequests + Routes
Controller methods:
- index(Request) — list dengan filter
- store(StorePembayaranSppRequest) — create baru
- show(int $id) — detail
- markAsPaid(MarkAsPaidRequest, int $id) — update status
- getBySantri(int $santriId) — history per santri
FormRequests:
1. StorePembayaranSppRequest
- santri_id: required, exists:santri,id
- bulan: required, integer, between:1,12
- tahun: required, digits:4
- nominal: required, numeric, min:0
2. MarkAsPaidRequest
- notes: nullable, string, max:255
Routes prefix: /api/v1/pembayaran-spp
OUTPUT: All files, code only, compact format
Step 6: Review & Test (Manual)
Setelah semua code di-generate:
- Copy ke project
- Run migration
- Register service provider jika perlu
- Test endpoints via Postman/Insomnia
- Fix issues jika ada
Kalau ada error, buat chat baru khusus debugging (lihat section debugging di bawah).
Kapan Harus Mulai Chat Baru?
Ini guidelines yang saya pakai:
| Kondisi | Action |
|---|---|
| Selesai 1 modul, mau mulai modul lain | Chat baru |
| Chat sudah 10-15 exchanges | Pertimbangkan chat baru |
| Ganti topik (dari coding ke debugging) | Chat baru |
| Stuck di loop error yang sama | Chat baru dengan context fresh |
| Mau refactor code yang sudah jadi | Chat baru |
Red flags yang menandakan harus chat baru:
- Claude mulai "lupa" conventions yang sudah disepakati
- Response makin lama makin tidak akurat
- Anda harus repeat context yang sudah pernah diberikan
- Claude generate code yang conflict dengan yang sudah ada di chat
Simpan Checkpoints
Setelah selesai 1 modul, simpan checkpoint di notes Anda:
## CHECKPOINT: Modul Pembayaran SPP ✓
### Files Created:
- database/migrations/2024_01_15_create_pembayaran_spp_table.php
- app/Models/PembayaranSpp.php
- app/Repositories/PembayaranSppRepository.php
- app/Services/PembayaranSppService.php
- app/Http/Controllers/Api/V1/PembayaranSppController.php
- app/Http/Requests/StorePembayaranSppRequest.php
- app/Http/Requests/MarkAsPaidRequest.php
- app/Exceptions/PembayaranAlreadyExistsException.php
- app/Exceptions/PembayaranAlreadyPaidException.php
### Routes:
GET /api/v1/pembayaran-spp
POST /api/v1/pembayaran-spp
GET /api/v1/pembayaran-spp/{id}
PATCH /api/v1/pembayaran-spp/{id}/mark-paid
GET /api/v1/santri/{santriId}/pembayaran
### Tested: ✓
### Notes:
- Validasi double entry sudah jalan
- markAsPaid update paid_at dan created_by
Checkpoint ini berguna untuk:
- Reference di chat berikutnya ("modul Pembayaran sudah selesai dengan pattern X")
- Tracking progress project
- Onboarding kalau ada developer lain join
Workflow untuk Debugging
Debugging punya workflow berbeda. Jangan paste semua error + semua code di chat yang sedang build fitur. Buat chat baru khusus debug.
BAD Debugging:
[di tengah chat build modul Pembayaran]
Eh mas Claude, tadi saya jalankan code-nya error nih:
SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or
update a child row: a foreign key constraint fails (`pesantren`.
`pembayaran_spp`, CONSTRAINT `pembayaran_spp_santri_id_foreign`
FOREIGN KEY (`santri_id`) REFERENCES `santri` (`id`))
[paste seluruh stack trace 50 baris]
[paste seluruh controller 100 baris]
[paste seluruh service 80 baris]
[paste seluruh repository 60 baris]
Tolong fix ya
Problem:
- Context chat sudah panjang, ditambah paste ratusan baris
- Claude harus cari needle in haystack
- Token explode
GOOD Debugging (Chat Baru):
DEBUG: Foreign Key Constraint Error
ERROR MESSAGE:
SQLSTATE[23000]: Integrity constraint violation: 1452
Cannot add or update a child row: FK constraint fails
on pembayaran_spp.santri_id → santri.id
CONTEXT:
- Trying to create pembayaran_spp record
- santri_id yang dikirim: 999
- santri dengan id 999 tidak exist di database
CODE YANG RELEVANT:
```php
// PembayaranSppService@create
public function create(array $data): PembayaranSpp
{
return $this->repository->create($data);
}
QUESTION: Bagaimana best practice handle ini? Options:
- Validasi di FormRequest dengan exists rule
- Validasi di Service sebelum create
- Catch exception di Controller
Mana yang recommended untuk pattern saya?
Dengan prompt ini:
- Context minimal dan fokus
- Error jelas
- Code yang relevan saja
- Question specific
Claude bisa langsung kasih solusi tanpa harus parse ratusan baris code.
### Workflow untuk Refactoring
Refactoring juga sebaiknya di chat terpisah dengan scope yang jelas.
**Contoh prompt refactoring:**
REFACTOR REQUEST
FILE: app/Services/PembayaranSppService.php CURRENT STATE: [paste file, atau attach]
REFACTOR GOALS:
- Extract validasi double entry ke private method
- Add logging untuk setiap operasi
- Wrap create dan markAsPaid dalam DB transaction
CONSTRAINTS:
- Jangan ubah method signatures (public methods)
- Jangan ubah return types
- Keep existing functionality
OUTPUT: Full refactored file
### Anti-Pattern yang Harus Dihindari
Dari pengalaman mentoring, ini kesalahan workflow yang paling sering:
❌ **"Tolong buatkan seluruh backend Pesantren Digital"**
Terlalu broad. Pecah per modul.
❌ **Copy-paste 10 file sekaligus tanpa context**
Claude tidak tahu mana yang relevan. Specify file mana yang sedang dibahas.
❌ **Debugging dengan paste seluruh stack trace**
Stack trace Laravel bisa 100+ baris. Ambil yang relevan saja (biasanya 5-10 baris pertama).
❌ **Minta rewrite file yang baru saja di-generate**
Kalau ada yang salah, specify apa yang salah. Jangan minta generate ulang semua.
❌ **Conversation 50+ messages untuk 1 modul simple**
Kalau sudah 15-20 messages dan belum selesai, ada yang salah dengan approach. Reset dan mulai dengan prompt yang lebih baik.
❌ **Campur coding + deployment + database design dalam 1 chat**
Setiap concern punya konteks berbeda. Pisahkan.
### Template Workflow per Modul
Ini template yang bisa Anda copy untuk setiap modul baru:
```markdown
## Workflow: [Nama Modul]
### Chat 1: Build Module
1. [ ] Migration
2. [ ] Model dengan relations & scopes
3. [ ] Repository
4. [ ] Service dengan business logic
5. [ ] Controller + FormRequests + Routes
6. [ ] API Resource (jika perlu formatting khusus)
### Chat 2: Testing & Fixes (jika ada error)
- [ ] Debug errors
- [ ] Fix edge cases
### Chat 3: Enhancements (jika perlu)
- [ ] Refactoring
- [ ] Performance optimization
- [ ] Additional features
### Checkpoint
- Files created: [list]
- Routes: [list]
- Tested: [ ]
- Notes: [any notes]
Dengan workflow yang sistematis, Anda bisa build modul dengan lebih cepat, lebih sedikit error, dan tentu saja lebih hemat token.
Di bagian terakhir, kita akan bahas tools dan automasi yang bisa membantu, plus recap semua tips dalam checklist yang actionable.
Bagian 5: Tools, Automasi & Penutup
Di bagian terakhir ini, kita akan bahas tools yang bisa membantu workflow vibe coding, estimasi token yang lebih konkret, dan recap semua tips dalam format yang mudah di-reference.
Tools yang Bantu Hemat Token
1. Script Generate Context Otomatis
Setiap mulai chat baru, Anda perlu attach context project. Daripada manual compile, buat script yang auto-generate.
#!/bin/bash
OUTPUT="CONTEXT.md"
echo "# PROJECT CONTEXT" > $OUTPUT
echo "Generated: $(date)" >> $OUTPUT
echo "" >> $OUTPUT
echo "## Current Models" >> $OUTPUT
echo '```' >> $OUTPUT
ls -1 app/Models/*.php 2>/dev/null | xargs -I {} basename {} .php >> $OUTPUT
echo '```' >> $OUTPUT
echo "" >> $OUTPUT
echo "## Current Controllers" >> $OUTPUT
echo '```' >> $OUTPUT
ls -1 app/Http/Controllers/Api/V1/*.php 2>/dev/null | xargs -I {} basename {} .php >> $OUTPUT
echo '```' >> $OUTPUT
echo "" >> $OUTPUT
echo "## Routes (api.php)" >> $OUTPUT
echo '```php' >> $OUTPUT
cat routes/api.php >> $OUTPUT
echo '```' >> $OUTPUT
echo "" >> $OUTPUT
echo "## Recent Migrations (last 5)" >> $OUTPUT
echo '```' >> $OUTPUT
ls -1t database/migrations/*.php 2>/dev/null | head -5 | xargs -I {} basename {} >> $OUTPUT
echo '```' >> $OUTPUT
echo "Context generated: $OUTPUT"
Jalankan sebelum mulai chat baru:
chmod +x generate-context.sh
./generate-context.sh
Lalu attach CONTEXT.md ke chat. Claude langsung tahu state project saat ini.
2. Snippet Library untuk Prompt Templates
Simpan prompts yang sering dipakai di file atau snippet manager (VS Code snippets, Alfred, Raycast, dll).
# PROMPT TEMPLATES
## New CRUD Module
---
PROYEK: Pesantren Digital API
STACK: Laravel 12, Service Repository Pattern
MODUL BARU: [NAMA_MODUL]
ERD:
[TABLE_NAME]
- [fields]
EXISTING:
- BaseController dengan $this->success() dan $this->error()
- Pattern sama seperti modul [REFERENCE_MODULE]
TASK: [SPECIFIC_TASK]
OUTPUT: Code only, compact format
---
## Add Method to Existing File
---
FILE: [path]
EXISTING METHODS: [list methods yang sudah ada]
ADD METHOD:
- Name: [method_name]
- Parameters: [params]
- Logic: [description]
- Return: [return type]
OUTPUT: New method only, bukan seluruh file
---
## FormRequest Template
---
CREATE: [Name]Request
RULES:
- field1: [rules]
- field2: [rules]
MESSAGES: Bahasa Indonesia
OUTPUT: Code only
---
## Debug Error
---
ERROR: [error message singkat]
CONTEXT:
- Action: [apa yang sedang dilakukan]
- File: [file yang error]
- Line: [line number jika ada]
RELEVANT CODE:
```[language]
[snippet]
QUESTION: [specific question]
Setiap kali butuh, tinggal copy template dan fill the blanks. Konsisten dan hemat waktu.
#### 3. Git Hooks untuk Auto-Documentation
Buat git hook yang update documentation setiap commit:
**`.git/hooks/post-commit:**
```bash
#!/bin/bash
# Update file list
echo "# PROJECT FILES" > FILES.md
echo "Updated: $(date)" >> FILES.md
echo "" >> FILES.md
echo "## Models" >> FILES.md
ls -1 app/Models/*.php 2>/dev/null >> FILES.md
echo "## Controllers" >> FILES.md
ls -1 app/Http/Controllers/Api/V1/*.php 2>/dev/null >> FILES.md
echo "## Services" >> FILES.md
ls -1 app/Services/*.php 2>/dev/null >> FILES.md
echo "## Repositories" >> FILES.md
ls -1 app/Repositories/*.php 2>/dev/null >> FILES.md
Setiap commit, FILES.md otomatis update. Berguna untuk quick reference.
Estimasi Token Usage: Real Numbers
Berdasarkan build proyek Pesantren Digital, ini perbandingan actual token usage:
Per Task
| Task | Tanpa Optimasi | Dengan Optimasi | Hemat |
|---|---|---|---|
| Migration + Model | 2.000 tokens | 800 tokens | 60% |
| Repository | 1.800 tokens | 700 tokens | 61% |
| Service + Exceptions | 2.500 tokens | 1.000 tokens | 60% |
| Controller + Routes | 3.000 tokens | 1.200 tokens | 60% |
| FormRequests (2 files) | 1.500 tokens | 500 tokens | 67% |
| 1 Modul Lengkap | ~11.000 tokens | ~4.200 tokens | 62% |
Per Debug Session
| Scenario | Tanpa Optimasi | Dengan Optimasi | Hemat |
|---|---|---|---|
| Simple error fix | 3.000 tokens | 800 tokens | 73% |
| Logic bug | 5.000 tokens | 1.500 tokens | 70% |
| Complex multi-file issue | 8.000 tokens | 3.000 tokens | 63% |
Full Project Pesantren Digital
| Metric | Tanpa Optimasi | Dengan Optimasi |
|---|---|---|
| Total Modules | 10 | 10 |
| Tokens per Module (avg) | 15.000 | 5.500 |
| Debug/Fix Sessions | ~20 | ~10 (less rework) |
| Tokens Debug (avg) | 4.000 | 1.200 |
| Total Project | ~230.000 | ~67.000 |
| Savings | - | ~163.000 tokens (71%) |
Angka-angka ini dari pengalaman actual. Your mileage may vary tergantung kompleksitas project, tapi range 50-70% savings itu achievable.
Kapan Worth It "Bayar Lebih"?
Tidak semua harus di-optimize. Ada situasi di mana lebih baik spend token lebih untuk hasil lebih baik:
1. Architecture Decisions
Saat design system architecture, worth it untuk deep conversation. Salah architecture di awal = refactor besar nanti.
Saya mau design payment system untuk Pesantren Digital.
Requirements: [detail]
Constraints: [detail]
Tolong bantu analyze:
1. Pilihan arsitektur (sync vs async, event-driven vs direct)
2. Database design options
3. Integration patterns dengan payment gateway
4. Error handling strategy
Ini conversation untuk brainstorming, jadi boleh elaborate.
2. Security Review
Jangan hemat token untuk security. Paste full code kalau perlu.
SECURITY REVIEW REQUEST
File: app/Http/Controllers/Api/V1/AuthController.php
[paste full file]
Review untuk:
1. Authentication vulnerabilities
2. Authorization bypass
3. Input validation gaps
4. Sensitive data exposure
Be thorough, ini untuk production.
3. Performance Optimization
Query optimization butuh full context.
PERFORMANCE ISSUE
Query ini slow (2-3 detik):
[paste query atau Eloquent chain]
Table sizes:
- santri: 5000 rows
- pembayaran_spp: 50000 rows
Current indexes: [list]
Tolong analyze dan suggest optimization.
Full context penting di sini.
4. Complex Debugging
Kalau bug sudah di-investigate dan masih stuck, provide full context.
STUCK BUG - Need Full Analysis
Sudah coba:
1. [approach 1] - hasil: [X]
2. [approach 2] - hasil: [Y]
Files involved:
[paste relevant files]
Test case yang fail:
[paste test atau steps]
Error:
[full error]
Butuh fresh eyes untuk analyze root cause.
Recap: 10 Tips Hemat Token
Simpan ini sebagai quick reference:
## 10 TIPS HEMAT TOKEN CLAUDE AI
### Persiapan (Investasi Awal)
1. ✅ Buat PROJECT-BRIEF.md — max 500 kata, reuse di setiap chat baru
2. ✅ Buat CONVENTIONS.md — naming, patterns, response format
3. ✅ Buat ERD.md — text-based, bukan gambar
### Prompting (Setiap Prompt)
4. ✅ State-first — selalu mulai dengan kondisi saat ini
5. ✅ Reference, don't repeat — "pattern sama seperti X"
6. ✅ Output constraints — "code only, no explanation"
7. ✅ Diff-only updates — jangan regenerate full file
### Workflow (Conversation Management)
8. ✅ 1 chat = 1 fokus — mulai baru untuk modul/topik baru
9. ✅ Incremental building — pecah task besar jadi steps
10. ✅ Checkpoint — simpan summary setelah modul selesai
### Bonus
- Batch similar tasks dalam 1 prompt
- Buat template library untuk prompts yang sering
- Script untuk auto-generate context
- Debugging di chat terpisah dengan minimal context
Penutup
Vibe coding dengan Claude AI mengubah cara kita develop software. Produktivitas bisa meningkat 3-5x lipat dibanding coding manual. Tapi seperti tools powerful lainnya, cara pakai menentukan hasil.
Dengan menerapkan tips di artikel ini, Anda bisa:
- Hemat 50-70% token untuk output yang sama
- Build lebih cepat karena prompt lebih fokus dan akurat
- Reduce frustration karena lebih sedikit back-and-forth
- Scale ke project besar tanpa worry budget token
Kuncinya ada di tiga hal:
- Preparation — invest waktu di awal untuk documentation
- Precision — prompt yang specific dan terstruktur
- Process — workflow yang sistematis dan disciplined
Untuk proyek seperti Pesantren Digital, ini bukan teori — ini sudah dipraktekkan dan terbukti works.
Rekomendasi Kelas BuildWithAngga
Kalau Anda ingin lebih dalam mempelajari Laravel dan teknik vibe coding:
┌─────────────────────────────────────────────────────────┐
│ 🎓 KELAS PREMIUM BUILDWITHANGGA │
├─────────────────────────────────────────────────────────┤
│ │
│ 🔥 RECOMMENDED untuk Laravel Developer: │
│ │
│ ✅ Mastering Laravel 12 │
│ Fundamental sampai advanced, project real-world │
│ │
│ ✅ Backend API Development dengan Laravel │
│ REST API, authentication, best practices │
│ │
│ ✅ Vibe Coding & AI-Assisted Development │
│ Workflow efisien dengan AI tools │
│ │
│ ✅ Database Design & Query Optimization │
│ Schema design, indexing, performance tuning │
│ │
│ 📚 KELAS PENDUKUNG: │
│ • Clean Architecture Laravel │
│ • Testing Laravel Application (PHPUnit, Pest) │
│ • DevOps untuk Laravel (Docker, CI/CD, Server) │
│ • TypeScript untuk Full-Stack Developer │
│ │
├─────────────────────────────────────────────────────────┤
│ │
│ 🎁 BENEFIT MEMBERSHIP: │
│ • Akses semua kelas seumur hidup │
│ • 50+ project portfolio real-world │
│ • Sertifikat completion │
│ • Private community Discord │
│ • Weekly mentoring session │
│ • Update materi mengikuti teknologi terbaru │
│ • Career support & job referral │
│ │
│ 👉 buildwithangga.com/kelas │
│ │
└─────────────────────────────────────────────────────────┘
Kalau ada pertanyaan tentang tips di artikel ini atau mau diskusi tentang vibe coding workflow, feel free untuk reach out di komunitas BuildWithAngga.
Happy coding, hemat token! 🚀
— Angga Risky Setiawan Founder, BuildWithAngga
