Bocoran Gemini 3.5 Pro: 2 Juta Token dan Deep Think

Gemini 3.5 Pro leak sedang ramai karena membawa beberapa klaim besar: jendela konteks hingga 2 juta token, mode penalaran Deep Think, kemampuan coding yang lebih kuat, serta dukungan untuk pekerjaan agen yang berjalan panjang. Ada juga nama internal Cappuccino, rumor peluncuran 17 Juli 2026, dan kabar soal agen Gemini Spark.

Masalahnya, informasi yang beredar masih bercampur antara pengumuman, laporan pihak ketiga, tangkapan layar komunitas, dan hasil benchmark yang belum bisa diverifikasi. Jadi, pendekatan paling aman bukan menebak siapa yang bakal menang, melainkan menyiapkan pengujian coding yang bisa diulang begitu Gemini 3.5 Pro benar-benar tersedia.

Jawaban singkat: Gemini 3.5 Pro disebut sebagai calon model unggulan Google untuk coding, penalaran panjang, multimodal, dan alur kerja agen. Jendela konteks 2 juta token serta Deep Think termasuk fitur yang paling sering diberitakan. Sementara itu, tanggal 17 Juli, harga, hasil benchmark, dan performa terhadap GPT-5.6 atau Claude Fable 5 masih perlu diperlakukan sebagai klaim sementara.

Latar belakang: kenapa bocoran Gemini 3.5 Pro menarik perhatian?

Persaingan model AI sudah bergerak jauh dari sekadar menjawab pertanyaan. Model sekarang dinilai dari kemampuannya membaca repositori besar, mengubah banyak berkas, menjalankan alat, memperbaiki kesalahan, dan mempertahankan tujuan selama pekerjaan panjang.

Di sinilah Gemini 3.5 Pro terlihat ambisius. Beberapa laporan menyebut model ini diarahkan untuk menangani:

• Konteks hingga 2 juta token.

• Penalaran kompleks melalui Deep Think.

• Pembuatan dan perbaikan kode.

• Pemahaman teks, gambar, audio, dan video.

• Pembuatan SVG, antarmuka web, animasi, dan prototipe interaktif.

• Pekerjaan agen yang memakai alat dalam beberapa tahap.

• Integrasi dengan ekosistem Google dan kemungkinan dukungan alat berbasis MCP.

Jendela konteks bisa dibayangkan seperti meja kerja. Meja yang lebih besar memungkinkan kita membuka lebih banyak dokumen sekaligus. Tapi meja besar tidak otomatis membuat orang di depannya memahami semua dokumen dengan benar.

Itulah alasan 2 juta token tidak boleh dianggap sebagai bukti kecerdasan. Yang lebih penting adalah kemampuan model menemukan informasi relevan, menjaga konsistensi, dan menyelesaikan tugas tanpa mengabaikan instruksi di tengah jalan.

Status model juga perlu dibaca dengan hati-hati. Informasi produk dan model yang sudah tersedia sebaiknya selalu diperiksa melalui dokumentasi resmi Gemini API dan dokumentasi model di Vertex AI, bukan hanya dari unggahan media sosial.

Masalah utama: benchmark bocor sering membandingkan hal yang berbeda

Satu bocoran menyebut Gemini 3.5 Pro unggul atas pesaing dalam evaluasi internal. Bocoran lain justru mengatakan model tersebut masih tertinggal dalam coding, penalaran, code infilling, dan pekerjaan jangka panjang.

Dua klaim itu bisa muncul bersamaan karena penguji mungkin memakai:

• Versi model yang berbeda.

• Prompt yang berbeda.

• Pengaturan penalaran yang berbeda.

• Alat coding yang berbeda.

• Repositori dan bahasa pemrograman yang berbeda.

• Batas token dan waktu yang berbeda.

• Penilaian manual yang tidak sama.

• Model internal yang belum sama dengan versi publik.

Benchmark tanpa metode yang jelas mirip membandingkan waktu tempuh Jakarta–Bandung tanpa menyebut kendaraan, jalur, cuaca, dan jam keberangkatan. Angkanya terlihat tegas, tapi belum tentu berguna.

Solusinya adalah membuat harness benchmark, yaitu program kecil yang mengirim tugas yang sama ke beberapa model, menyimpan jawaban, mengukur waktu, dan menjalankan pengujian otomatis.

Perbandingan klaim Gemini 3.5 Pro dengan pilihan lain

Tabel berikut bukan peringkat mutlak. Ini peta awal untuk menentukan hal yang perlu diuji saat akses publik tersedia.

Pilihan terbaik berdasarkan kebutuhan

• Pilih model cepat seperti Flash untuk klasifikasi, ringkasan singkat, ekstraksi data, dan permintaan berulang.

• Pertimbangkan Gemini 3.5 Pro untuk repositori besar, riset multimodal, perencanaan teknis, dan pekerjaan yang membutuhkan konteks panjang.

• Bandingkan dengan model coding lain untuk penyuntingan lintas berkas, penggunaan terminal, debugging, dan penyelesaian tugas dalam repositori nyata.

• Gunakan beberapa model jika risiko kesalahan tinggi. Satu model bisa menulis solusi, model lain meninjau, lalu pengujian otomatis menjadi penentu terakhir.

Untuk tim di Indonesia, biaya juga tidak boleh dihitung dari harga token saja. Kurs dolar, pajak, latensi jaringan, waktu peninjauan manusia, serta biaya memperbaiki kode yang salah bisa jauh lebih besar daripada tagihan API.

Getting Started: siapkan lingkungan pengujian

Tutorial ini tidak menganggap endpoint Gemini 3.5 Pro sudah tersedia untuk semua akun. Kita akan membuat kerangka yang memakai nama model lewat variabel lingkungan, sehingga model bisa diganti tanpa mengubah logika program.

Prasyarat

Teman-Teman perlu menyiapkan:

• Python 3.11 atau lebih baru.

• Git.

• Akun penyedia model yang akan diuji.

• Kunci API resmi.

• Penyunting kode seperti Visual Studio Code.

• Repositori contoh yang aman.

• Pemahaman ringan tentang terminal.

• Anggaran API dengan batas pemakaian.

Jangan menguji agen coding pertama kali pada repositori produksi. Buat salinan lokal atau cabang Git terpisah agar perubahan mudah dibatalkan.

Step 1 — Buat proyek benchmark yang terisolasi

Buka terminal, lalu jalankan:

mkdir gemini-35-benchmark
cd gemini-35-benchmark

python -m venv .venv

Aktifkan lingkungan virtual.

Windows PowerShell

.venv\Scripts\Activate.ps1

macOS dan Linux

source .venv/bin/activate

Buat struktur proyek:

gemini-35-benchmark/
├── app/
│   ├── __init__.py
│   ├── client.py
│   ├── evaluator.py
│   └── runner.py
├── tasks/
│   └── coding_tasks.json
├── results/
├── tests/
│   └── test_sample.py
├── .env.example
├── .gitignore
└── requirements.txt

Tambahkan dependensi ke requirements.txt:

httpx==0.27.0
python-dotenv==1.0.1
pytest==8.2.2

Lalu pasang:

pip install -r requirements.txt

Kenapa langkah ini penting? Lingkungan virtual mencegah benturan versi pustaka dengan proyek lain. Struktur yang rapi juga memisahkan tugas, koneksi API, hasil, dan logika penilaian.

Output yang diharapkan

Successfully installed httpx python-dotenv pytest ...

Versinya mungkin berbeda. Yang penting, instalasi selesai tanpa pesan ERROR.

Step 2 — Simpan konfigurasi tanpa membocorkan kunci API

Isi .gitignore:

.venv/
.env
__pycache__/
.pytest_cache/
results/*.json
results/*.jsonl

Buat .env.example:

MODEL_API_KEY=replace_with_your_key
MODEL_BASE_URL=https://example-provider.invalid/v1
MODEL_NAME=replace_with_official_model_id
REQUEST_TIMEOUT=180
MAX_OUTPUT_TOKENS=8192

Salin menjadi .env:

cp .env.example .env

Pengguna Windows bisa menjalankan:

Copy-Item .env.example .env

Masukkan endpoint dan identitas model yang benar setelah tersedia di dokumentasi resmi. Jangan menebak nama seperti gemini-3.5-pro lalu menganggapnya pasti valid.

Kenapa langkah ini penting? Nama pemasaran belum tentu sama dengan identitas API. Model bisa tersedia di satu layanan, tetapi belum muncul di layanan lain atau belum aktif di wilayah akun Teman-Teman.

Kunci API juga tidak boleh ditaruh langsung dalam kode karena berisiko ikut terkirim ke GitHub.

Step 3 — Buat daftar tugas coding yang adil

Isi tasks/coding_tasks.json:

[
  {
    "id": "python-validation-001",
    "category": "bug_fix",
    "language": "python",
    "prompt": "Perbaiki fungsi validate_email agar menolak alamat tanpa domain yang valid. Kembalikan hanya kode fungsi.",
    "starter_code": "def validate_email(value):\n    return '@' in value\n",
    "expected_behavior": [
      "Menerima [email protected]",
      "Menolak user@",
      "Menolak @example.com",
      "Menolak nilai non-string"
    ]
  },
  {
    "id": "javascript-total-001",
    "category": "implementation",
    "language": "javascript",
    "prompt": "Lengkapi fungsi calculateTotal. Abaikan item dengan quantity negatif dan bulatkan hasil ke dua angka desimal.",
    "starter_code": "function calculateTotal(items) {\n  // TODO\n}\n",
    "expected_behavior": [
      "Mengalikan price dengan quantity",
      "Mengabaikan quantity negatif",
      "Mengembalikan angka dua desimal",
      "Tidak mengubah array input"
    ]
  },
  {
    "id": "sql-report-001",
    "category": "sql",
    "language": "sql",
    "prompt": "Tulis kueri untuk menghitung pendapatan bulanan per cabang dari tabel orders. Hanya sertakan status paid.",
    "starter_code": "",
    "expected_behavior": [
      "Memfilter status paid",
      "Mengelompokkan cabang dan bulan",
      "Menjumlahkan total",
      "Menggunakan sintaks SQL yang jelas"
    ]
  }
]

Mulailah dengan tugas kecil yang jawabannya mudah diperiksa. Setelah kerangka stabil, tambahkan:

• Perbaikan bug lintas berkas.

• Refaktor tanpa mengubah perilaku.

• Penulisan pengujian.

• Analisis kerentanan.

• Migrasi basis data.

• Pembuatan antarmuka.

• Tugas konteks panjang.

• Tugas yang membutuhkan pemanggilan alat.

Kenapa ini penting? Prompt buatan sendiri sering terlalu dekat dengan selera pembuat benchmark. Campuran kategori memberi gambaran yang lebih jujur tentang kekuatan dan kelemahan model.

Hindari soal yang mungkin pernah tersebar luas beserta jawabannya. Model bisa tampak pintar karena mengingat pola, bukan karena benar-benar menyelesaikan masalah.

Step 4 — Buat klien API yang mudah diganti

Isi app/client.py:

import os
import time
import httpx
from dotenv import load_dotenv

load_dotenv()

class ModelClient:
    def __init__(self):
        self.api_key = os.environ["MODEL_API_KEY"]
        self.base_url = os.environ["MODEL_BASE_URL"].rstrip("/")
        self.model_name = os.environ["MODEL_NAME"]
        self.timeout = float(os.getenv("REQUEST_TIMEOUT", "180"))
        self.max_output_tokens = int(
            os.getenv("MAX_OUTPUT_TOKENS", "8192")
        )

    def generate(self, prompt: str) -> dict:
        payload = {
            "model": self.model_name,
            "input": prompt,
            "max_output_tokens": self.max_output_tokens,
            "temperature": 0
        }

        headers = {
            "Authorization": f"Bearer {self.api_key}",
            "Content-Type": "application/json"
        }

        started_at = time.perf_counter()

        with httpx.Client(timeout=self.timeout) as client:
            response = client.post(
                f"{self.base_url}/responses",
                headers=headers,
                json=payload
            )
            response.raise_for_status()
            data = response.json()

        latency = time.perf_counter() - started_at

        return {
            "model": self.model_name,
            "latency_seconds": round(latency, 3),
            "raw_response": data
        }

Format permintaan di atas bersifat adapter generik, bukan kontrak resmi Gemini. Saat memakai Gemini API atau Vertex AI, sesuaikan payload, autentikasi, URL, dan cara membaca output dengan dokumentasi resminya.

Pendekatan adapter membuat bagian lain dari benchmark tetap sama. Teman-Teman hanya mengganti satu berkas saat struktur API berubah.

Kesalahan yang sering muncul

KeyError: 'MODEL_API_KEY'

Artinya .env tidak ditemukan, salah nama, atau belum berisi variabel tersebut.

401 Unauthorized

Biasanya kunci tidak valid, metode autentikasi keliru, atau akun belum mendapat akses.

404 Not Found

Nama model atau endpoint kemungkinan salah. Jangan langsung menyimpulkan model belum dirilis sebelum memeriksa layanan dan wilayah yang dipakai.

Step 5 — Standarkan prompt pengujian

Buat fungsi penyusun prompt di app/runner.py:

def build_prompt(task: dict) -> str:
    behavior = "\n".join(
        f"- {item}" for item in task["expected_behavior"]
    )

    return f"""
Anda sedang mengikuti evaluasi coding terkontrol.

ID tugas: {task["id"]}
Bahasa: {task["language"]}
Kategori: {task["category"]}

Instruksi:
{task["prompt"]}

Kode awal:
```{task["language"]}
{task["starter_code"]}

Perilaku yang diharapkan: {behavior}

Aturan:

1. Jangan mengubah persyaratan.

2. Jangan menambahkan dependensi tanpa alasan.

3. Berikan kode yang bisa dijalankan.

4. Jelaskan asumsi secara singkat setelah kode. """.strip()

Gunakan `temperature: 0` pada pengujian pertama agar variasi jawaban lebih rendah. Setelah itu, jalankan beberapa pengulangan untuk mengukur konsistensi.

**Kenapa prompt harus sama?** Perubahan satu kalimat saja bisa memengaruhi hasil. Kalau model A diberi konteks lengkap sementara model B hanya menerima instruksi singkat, perbandingannya tidak adil.

### Tip pengujian yang lebih kuat

Jalankan setiap tugas minimal tiga kali:

1. Pengujian deterministik dengan suhu rendah.
2. Pengujian ulang untuk mengecek konsistensi.
3. Pengujian dengan konteks tambahan untuk melihat apakah hasil membaik atau malah memburuk.

Untuk model dengan Deep Think, catat apakah mode tersebut aktif. Jangan membandingkan mode penalaran berat dengan mode cepat tanpa menjelaskan perbedaannya.

## Step 6 — Jalankan benchmark dan simpan hasil mentah

Lengkapi `app/runner.py`:

```python
import json
from datetime import datetime, timezone
from pathlib import Path

from app.client import ModelClient

def build_prompt(task: dict) -> str:
    behavior = "\n".join(
        f"- {item}" for item in task["expected_behavior"]
    )

    return f"""
Anda sedang mengikuti evaluasi coding terkontrol.

ID tugas: {task["id"]}
Bahasa: {task["language"]}
Kategori: {task["category"]}

Instruksi:
{task["prompt"]}

Kode awal:
```{task["language"]}
{task["starter_code"]}

Perilaku yang diharapkan: {behavior}

Aturan:

1. Jangan mengubah persyaratan.

2. Jangan menambahkan dependensi tanpa alasan.

3. Berikan kode yang bisa dijalankan.

4. Jelaskan asumsi secara singkat setelah kode. """.strip()

def load_tasks(path: str) -> list[dict]: with open(path, "r", encoding="utf-8") as file: return json.load(file)

def main(): client = ModelClient() tasks = load_tasks("tasks/coding_tasks.json") output_path = Path("results/results.jsonl") output_path.parent.mkdir(exist_ok=True)

with output_path.open("a", encoding="utf-8") as output:
    for task in tasks:
        prompt = build_prompt(task)

        try:
            result = client.generate(prompt)
            record = {
                "timestamp": datetime.now(timezone.utc).isoformat(),
                "task_id": task["id"],
                "status": "success",
                **result
            }
        except Exception as error:
            record = {
                "timestamp": datetime.now(timezone.utc).isoformat(),
                "task_id": task["id"],
                "status": "error",
                "error_type": type(error).__name__,
                "error_message": str(error)
            }

        output.write(
            json.dumps(record, ensure_ascii=False) + "\n"
        )
        print(record["task_id"], record["status"])

if name == "main": main()

Jalankan:

```bash
python -m app.runner

Output yang diharapkan

python-validation-001 success
javascript-total-001 success
sql-report-001 success

Berkas results/results.jsonl akan berisi satu objek JSON per baris. Format JSONL cocok untuk eksperimen karena hasil baru bisa ditambahkan tanpa menulis ulang seluruh berkas.

Kenapa respons mentah harus disimpan? Evaluasi otomatis kadang salah. Dengan menyimpan hasil asli, Teman-Teman bisa meninjau keputusan penilai dan memeriksa apakah model sebenarnya benar, tetapi format jawabannya berbeda.

Step 7 — Nilai jawaban dengan metrik yang masuk akal

Benchmark coding sebaiknya tidak hanya memakai penilaian “terlihat bagus”. Kode yang rapi masih bisa gagal saat dijalankan.

Gunakan beberapa lapisan penilaian:

Buat app/evaluator.py:

from dataclasses import dataclass

@dataclass
class Evaluation:
    tests_passed: int
    tests_total: int
    instruction_score: float
    latency_seconds: float
    human_fix_minutes: float

    @property
    def pass_rate(self) -> float:
        if self.tests_total == 0:
            return 0.0
        return self.tests_passed / self.tests_total

    @property
    def practical_score(self) -> float:
        test_component = self.pass_rate * 60
        instruction_component = self.instruction_score * 30
        repair_penalty = min(self.human_fix_minutes, 20) * 0.5
        latency_penalty = min(self.latency_seconds / 60, 5)

        score = (
            test_component
            + instruction_component
            - repair_penalty
            - latency_penalty
        )
        return round(max(score, 0), 2)

Rumus tersebut hanya contoh. Sesuaikan bobot dengan kebutuhan organisasi.

Kalau tim Teman-Teman mengelola sistem pembayaran, keamanan dan tingkat lulus pengujian harus mendapat bobot besar. Untuk prototipe promosi UMKM, kecepatan dan kualitas visual mungkin lebih penting.

Step 8 — Uji klaim jendela konteks 2 juta token secara bertahap

Jangan langsung mengirim dua juta token. Biayanya bisa tinggi dan hasilnya sulit dianalisis.

Mulailah dengan beberapa ukuran:

• 10.000 token.

• 50.000 token.

• 100.000 token.

• 250.000 token.

• 500.000 token.

• Naik lebih jauh hanya jika akses, biaya, dan batas API memungkinkan.

Tempatkan fakta uji pada posisi berbeda:

def build_long_context_document(
    filler_blocks: list[str],
    secret_fact: str,
    position: str
) -> str:
    marker = f"FAKTA_PENTING: {secret_fact}"

    if position == "start":
        blocks = [marker, *filler_blocks]
    elif position == "middle":
        middle = len(filler_blocks) // 2
        blocks = [
            *filler_blocks[:middle],
            marker,
            *filler_blocks[middle:]
        ]
    elif position == "end":
        blocks = [*filler_blocks, marker]
    else:
        raise ValueError("position harus start, middle, atau end")

    return "\n\n".join(blocks)

Setelah itu, minta model:

1. Menemukan fakta.

2. Menjelaskan konteksnya.

3. Menghubungkannya dengan dua informasi lain.

4. Mengutip bagian yang relevan.

5. Menolak fakta pengganggu yang mirip.

Kenapa bukan sekadar tanya “apa fakta rahasianya”? Pencarian kata sederhana belum membuktikan penalaran konteks panjang. Model yang bagus harus mampu mengambil informasi, memahami hubungan, dan menghindari pengalih perhatian.

Output yang diharapkan

{
  "position": "middle",
  "retrieval_correct": true,
  "relation_correct": true,
  "distractor_rejected": true
}

Kalau model berhasil pada 100.000 token tetapi turun tajam pada 500.000 token, angka kapasitas maksimal masih benar secara teknis. Hanya saja, kapasitas input dan kualitas pemahaman bukan hal yang sama.

Step 9 — Uji Deep Think secara terpisah

Mode penalaran berat kemungkinan mengorbankan kecepatan dan biaya demi hasil lebih baik. Karena itu, bandingkan dua konfigurasi pada tugas yang sama:

• Mode standar.

• Mode Deep Think.

• Batas waktu yang sama atau dicatat secara transparan.

• Jumlah pengulangan yang sama.

• Pengujian otomatis yang sama.

Pakai tugas yang memang membutuhkan penalaran, misalnya:

Sebuah layanan menerima 8.000 permintaan per menit. Setiap pekerja
mampu menangani 25 permintaan per detik dengan pemakaian CPU rata-rata
60%. Rancang strategi penskalaan yang tetap bertahan jika satu zona
gagal. Jelaskan asumsi, hitung kapasitas minimum, lalu berikan contoh
konfigurasi.

Jangan menilai Deep Think dari soal yang jawabannya hanya satu fungsi sederhana. Mode berat baru masuk akal jika kualitas tambahannya sebanding dengan waktu dan biaya.

Metrik yang perlu dicatat

• Persentase jawaban benar.

• Jumlah asumsi yang tidak berdasar.

• Waktu hingga respons selesai.

• Token penalaran jika tersedia.

• Biaya per tugas sukses.

• Menit koreksi manusia.

• Stabilitas pada tiga sampai lima pengulangan.

Step 10 — Uji kemampuan agen dan penggunaan alat

Rumor tentang Gemini Spark dan dukungan alat membuat bagian ini penting. Agen bukan sekadar model yang menulis teks. Agen menerima tujuan, memilih alat, membaca hasil, memperbaiki kesalahan, lalu berhenti pada waktu yang tepat.

Gunakan lingkungan kotak pasir dengan alat terbatas:

ALLOWED_TOOLS = {
    "read_file",
    "write_file",
    "run_tests",
    "search_code"
}

BLOCKED_PATTERNS = {
    "rm -rf",
    "sudo ",
    "curl | sh",
    "printenv",
    "cat ~/.ssh"
}

def validate_command(command: str) -> bool:
    normalized = command.lower().strip()

    if any(pattern in normalized for pattern in BLOCKED_PATTERNS):
        return False

    return True

Berikan agen tugas seperti:

Perbaiki bug pada fungsi perhitungan diskon.

Batasan:
- Baca hanya direktori src dan tests.
- Jangan memasang paket baru.
- Jalankan pengujian setelah perubahan.
- Berhenti jika perlu mengakses kredensial.
- Tampilkan diff sebelum menyimpan perubahan akhir.

Kenapa batasan ini penting? Agen yang kuat bisa membuat kesalahan dengan dampak lebih luas. Kemampuan memanggil banyak alat tidak berguna jika izin, audit, dan titik konfirmasinya tidak jelas.

Protokol seperti Model Context Protocol bisa membantu menyusun sambungan alat yang lebih seragam. Meski begitu, protokol tidak otomatis menyelesaikan masalah keamanan. Setiap server alat tetap perlu izin minimum, validasi parameter, dan pencatatan aktivitas.

Step 11 — Tambahkan retry tanpa menyembunyikan kegagalan

API bisa mengembalikan batas laju, gangguan sementara, atau waktu tunggu habis. Tambahkan retry untuk kesalahan yang memang layak dicoba ulang.

import random
import time
import httpx

def with_retry(operation, max_attempts=4):
    for attempt in range(1, max_attempts + 1):
        try:
            return operation()
        except (
            httpx.TimeoutException,
            httpx.NetworkError
        ):
            if attempt == max_attempts:
                raise

            delay = (2 ** attempt) + random.random()
            time.sleep(delay)

Jangan mencoba ulang semua kesalahan. Respons 401 Unauthorized tidak akan sembuh hanya karena ditunggu. Kesalahan 400 Bad Request juga biasanya menandakan payload perlu diperbaiki.

Kenapa kegagalan tetap harus dicatat? Reliabilitas API merupakan bagian dari kualitas produk. Kalau benchmark hanya menyimpan percobaan yang sukses, model dan layanannya akan terlihat lebih stabil daripada kenyataan.

Step 12 — Buat studi kasus yang dekat dengan kebutuhan Indonesia

Bayangkan sebuah tim pengembang di Bandung menangani platform pemesanan untuk 120 cabang usaha makanan. Repositorinya berisi layanan Python, panel React, skema SQL, dan dokumentasi operasional.

Background

Tim ingin mengetahui apakah model kelas atas bisa mempercepat perbaikan bug lintas berkas. Selama ini, satu tiket kompleks membutuhkan rata-rata 95 menit dari pembacaan masalah sampai pull request siap ditinjau.

Challenge/Problem

Masalah utamanya bukan sekadar menulis fungsi. Model harus:

• Menemukan aturan diskon dalam dokumentasi.

• Membaca implementasi pada tiga berkas.

• Memperbaiki fungsi tanpa merusak API.

• Menambah unit test.

• Menjalankan seluruh rangkaian pengujian.

• Menjelaskan risiko perubahan.

Konteks besar membantu, tetapi model juga bisa kehilangan fokus atau mengubah berkas yang tidak diminta.

Approach

Tim menyiapkan 30 tiket historis yang sudah selesai. Informasi sensitif, data pelanggan, kunci API, dan nama internal dihapus lebih dulu.

Setiap model mendapat:

• Snapshot repositori yang sama.

• Instruksi yang sama.

• Batas waktu 20 menit.

• Maksimal lima pemanggilan alat.

• Suhu rendah.

• Pengujian otomatis yang sama.

• Peninjauan anonim oleh dua pengembang.

Implementation

Eksperimen berjalan di cabang Git terpisah. Setiap perubahan diperiksa berdasarkan tingkat lulus pengujian, ukuran diff, waktu penyelesaian, dan menit koreksi manusia.

Contoh format pencatatannya:

{
  "task_id": "discount-branch-rule-07",
  "model": "official-model-id",
  "tests_passed": 48,
  "tests_total": 50,
  "latency_seconds": 312.8,
  "tool_calls": 4,
  "files_changed": 3,
  "human_fix_minutes": 14,
  "security_violation": false
}

Results dengan metrik yang masuk akal

Karena Gemini 3.5 Pro belum memiliki hasil publik yang cukup konsisten untuk skenario ini, angka berikut adalah target keputusan, bukan klaim performa model:

Ambang seperti ini lebih berguna daripada pertanyaan “model mana paling pintar?”. Tim hanya mengadopsi model jika hasilnya mempercepat pekerjaan tanpa menaikkan risiko.

Key Learnings

• Konteks besar berguna saat informasi tersebar, tetapi penyusunan konteks tetap penting.

• Unit test lebih dapat dipercaya daripada penilaian berdasarkan gaya jawaban.

• Waktu koreksi manusia sering menjadi metrik ROI terbaik.

• Perubahan kecil yang tepat biasanya lebih berharga daripada diff besar.

• Agen wajib berhenti ketika membutuhkan kredensial atau izin tambahan.

• Benchmark perlu memakai pekerjaan yang mirip dengan kondisi sehari-hari.

Kesalahan umum saat menilai Gemini 3.5 Pro leak

Menganggap tanggal 17 Juli sebagai kepastian

Tanggal tersebut banyak disebut dalam laporan pihak ketiga, tetapi jadwal produk bisa berubah. Anggap sebagai target yang dilaporkan sampai Google menerbitkan pengumuman resmi.

Menggunakan nama model yang belum terdaftar

Pesan berikut tidak selalu berarti ada gangguan:

ModelNotFound: gemini-3.5-pro

Periksa:

• Apakah identitas model sudah benar.

• Apakah tersedia di Gemini API atau hanya Vertex AI.

• Apakah akun sudah mendapat akses.

• Apakah wilayah proyek mendukungnya.

• Apakah versi preview memakai akhiran khusus.

Membandingkan harga tanpa menghitung koreksi manusia

Model murah bisa menjadi mahal jika hasilnya perlu diperbaiki selama satu jam. Hitung biaya total:

biaya total =
biaya API
+ waktu peninjauan
+ waktu koreksi
+ biaya kegagalan
+ biaya infrastruktur

Menguji hanya satu prompt

Satu kemenangan tidak menunjukkan kestabilan. Jalankan tugas yang sama beberapa kali dan laporkan rentang hasil, bukan hanya skor terbaik.

Memakai data produksi untuk eksperimen awal

Hapus informasi pelanggan, token akses, nomor telepon, alamat, serta rahasia bisnis. Untuk perusahaan di Jakarta, Surabaya, Bandung, atau kota lain, lokasi bukan pembeda soal keamanan: prinsip minimasi data tetap sama.

Menganggap jawaban panjang lebih baik

Model yang menjelaskan banyak hal belum tentu menghasilkan kode benar. Pisahkan skor penjelasan dari tingkat lulus pengujian.

Troubleshooting benchmark Gemini 3.5 Pro

Permintaan selalu mengalami timeout

Coba langkah berikut:

1. Kurangi ukuran konteks.

2. Naikkan REQUEST_TIMEOUT secara bertahap.

3. Periksa apakah mode Deep Think aktif.

4. Gunakan streaming jika API mendukungnya.

5. Catat waktu respons pertama dan waktu selesai.

6. Jangan mengirim ulang permintaan tanpa batas.

Hasil sulit diurai karena bercampur penjelasan

Minta format keluaran terstruktur:

Kembalikan JSON dengan bentuk berikut:

{
  "language": "python",
  "code": "...",
  "assumptions": ["..."],
  "risks": ["..."]
}

Jangan tambahkan teks di luar JSON.

Tetap siapkan penanganan kalau model membungkus JSON dalam blok Markdown.

Kode terlihat benar tetapi unit test gagal

Periksa apakah model:

• Mengubah nama fungsi.

• Mengganti bentuk nilai kembalian.

• Menambah pustaka yang tidak tersedia.

• Mengabaikan kasus batas.

• Menghasilkan kode untuk versi bahasa berbeda.

• Menulis contoh, bukan implementasi lengkap.

Biaya melonjak pada pengujian konteks panjang

Gunakan strategi bertahap. Mulai dari konteks kecil, hentikan eksperimen jika kualitas sudah turun tajam, dan simpan hash dokumen agar input yang sama tidak diuji berulang tanpa alasan.

Agen terus mengulang langkah yang sama

Tambahkan batas:

MAX_TOOL_CALLS = 8
MAX_IDENTICAL_CALLS = 2
MAX_RUNTIME_SECONDS = 1200

Simpan jejak alat dan hentikan agen jika dua pemanggilan identik tidak menghasilkan perubahan keadaan.

Skor antarpenilai berbeda jauh

Buat rubrik yang lebih konkret:

• 0: persyaratan tidak terpenuhi.

• 1: terpenuhi sebagian dan butuh perubahan besar.

• 2: terpenuhi dengan koreksi kecil.

• 3: terpenuhi sepenuhnya.

Untuk tugas penting, pakai dua penilai dan bahas hanya kasus yang selisih skornya lebih dari satu poin.

Kelebihan dan kekurangan Gemini 3.5 Pro berdasarkan informasi saat ini

Kelebihan yang layak diuji

• Konteks sangat besar untuk repositori, dokumen, dan media panjang.

• Deep Think berpotensi membantu tugas yang membutuhkan banyak tahap penalaran.

• Multimodal cocok untuk alur yang mencampur kode, gambar, video, dan dokumen.

• Pembuatan visual terlihat menjadi salah satu fokus, termasuk SVG dan antarmuka.

• Integrasi ekosistem Google bisa memberi nilai lebih untuk organisasi yang sudah memakai Google Cloud dan Workspace.

• Arah agen dan alat relevan untuk otomatisasi pekerjaan teknis.

Kekurangan dan risiko

• Ketersediaan belum tentu merata.

• Harga resmi dan kuota perlu diperiksa saat peluncuran.

• Klaim benchmark masih bertentangan.

• Konteks besar bisa menaikkan biaya dan waktu respons.

• Mode penalaran berat belum tentu ekonomis untuk tugas sederhana.

• Agen yang lebih mandiri memperbesar kebutuhan kontrol keamanan.

• Hasil preview bisa berbeda dari versi publik.

• Integrasi yang terlalu dalam bisa meningkatkan ketergantungan pada satu penyedia.

Siapa yang paling cocok mengujinya?

Gemini 3.5 Pro layak masuk daftar uji untuk:

• Tim yang mengelola repositori besar.

• Pengembang aplikasi multimodal.

• Organisasi yang sudah memakai Google Cloud.

• Tim desain yang sering membuat prototipe interaktif.

• Analis yang perlu membaca kumpulan dokumen besar.

• Pengembang agen dengan kontrol alat yang ketat.

• Perusahaan yang bisa menjalankan evaluasi keamanan internal.

Model ini sebaiknya tidak langsung menjadi pilihan utama jika:

• Tugas sebagian besar berupa ringkasan pendek.

• Anggaran API sangat terbatas.

• Sistem tidak memiliki unit test.

• Tim belum punya proses peninjauan kode.

• Data tidak boleh masuk ke layanan eksternal.

• Kecepatan lebih penting daripada penalaran mendalam.

• Keputusan pembelian hanya berdasarkan benchmark bocor.

Tips agar pengujian tetap adil dan hemat

• Bekukan versi prompt selama satu putaran evaluasi.

• Catat nama model lengkap, bukan hanya nama produknya.

• Simpan tanggal pengujian karena model preview bisa berubah.

• Jalankan setiap tugas lebih dari sekali.

• Pisahkan skor kualitas, biaya, dan kecepatan.

• Gunakan unit test sebagai penentu utama untuk kode.

• Tinjau diff sebelum menjalankan perubahan.

• Jangan memberi agen akses ke kredensial produksi.

• Gunakan batas biaya harian.

• Bandingkan model pada tugas yang benar-benar dikerjakan tim.

• Laporkan kegagalan API, bukan hanya jawaban sukses.

• Ulangi benchmark setelah model atau alat coding diperbarui.

• Periksa dokumentasi resmi sebelum mengaktifkan nama model baru.

• Tunda migrasi besar sampai hasil pengujian konsisten.

Checklist saat akses Gemini 3.5 Pro tersedia

• Pastikan pengumuman berasal dari kanal resmi Google.

• Verifikasi identitas model dan layanan API.

• Catat status preview atau ketersediaan umum.

• Periksa wilayah, kuota, harga, dan batas konteks.

• Jalankan tugas coding kecil lebih dulu.

• Bandingkan mode standar dengan Deep Think.

• Uji pengambilan informasi pada konteks panjang.

• Ukur tingkat lulus unit test.

• Catat waktu respons dan biaya per tugas sukses.

• Hitung menit koreksi manusia.

• Uji agen hanya di lingkungan kotak pasir.

• Tinjau setiap pemanggilan alat.

• Bandingkan dengan model cepat dan model coding lain.

• Dokumentasikan versi prompt serta tanggal eksperimen.

• Jangan membawa model ke produksi sebelum lolos ambang keamanan.<<>> Gemini 3.5 Pro leak sedang ramai karena membawa beberapa klaim besar: jendela konteks hingga 2 juta token, mode penalaran Deep Think, kemampuan coding yang lebih kuat, serta dukungan untuk pekerjaan agen yang berjalan panjang. Ada juga nama internal Cappuccino, rumor peluncuran 17 Juli 2026, dan kabar soal agen Gemini Spark.

Masalahnya, informasi yang beredar masih bercampur antara pengumuman, laporan pihak ketiga, tangkapan layar komunitas, dan hasil benchmark yang belum bisa diverifikasi. Jadi, pendekatan paling aman bukan menebak siapa yang bakal menang, melainkan menyiapkan pengujian coding yang bisa diulang begitu Gemini 3.5 Pro benar-benar tersedia.

Jawaban singkat: Gemini 3.5 Pro disebut sebagai calon model unggulan Google untuk coding, penalaran panjang, multimodal, dan alur kerja agen. Jendela konteks 2 juta token serta Deep Think termasuk fitur yang paling sering diberitakan. Sementara itu, tanggal 17 Juli, harga, hasil benchmark, dan performa terhadap GPT-5.6 atau Claude Fable 5 masih perlu diperlakukan sebagai klaim sementara.

Latar belakang: kenapa bocoran Gemini 3.5 Pro menarik perhatian?

Persaingan model AI sudah bergerak jauh dari sekadar menjawab pertanyaan. Model sekarang dinilai dari kemampuannya membaca repositori besar, mengubah banyak berkas, menjalankan alat, memperbaiki kesalahan, dan mempertahankan tujuan selama pekerjaan panjang.

Di sinilah Gemini 3.5 Pro terlihat ambisius. Beberapa laporan menyebut model ini diarahkan untuk menangani:

• Konteks hingga 2 juta token.

• Penalaran kompleks melalui Deep Think.

• Pembuatan dan perbaikan kode.

• Pemahaman teks, gambar, audio, dan video.

• Pembuatan SVG, antarmuka web, animasi, dan prototipe interaktif.

• Pekerjaan agen yang memakai alat dalam beberapa tahap.

• Integrasi dengan ekosistem Google dan kemungkinan dukungan alat berbasis MCP.

Jendela konteks bisa dibayangkan seperti meja kerja. Meja yang lebih besar memungkinkan kita membuka lebih banyak dokumen sekaligus. Tapi meja besar tidak otomatis membuat orang di depannya memahami semua dokumen dengan benar.

Itulah alasan 2 juta token tidak boleh dianggap sebagai bukti kecerdasan. Yang lebih penting adalah kemampuan model menemukan informasi relevan, menjaga konsistensi, dan menyelesaikan tugas tanpa mengabaikan instruksi di tengah jalan.

Status model juga perlu dibaca dengan hati-hati. Informasi produk dan model yang sudah tersedia sebaiknya selalu diperiksa melalui dokumentasi resmi Gemini API dan dokumentasi model di Vertex AI, bukan hanya dari unggahan media sosial.

Masalah utama: benchmark bocor sering membandingkan hal yang berbeda

Satu bocoran menyebut Gemini 3.5 Pro unggul atas pesaing dalam evaluasi internal. Bocoran lain justru mengatakan model tersebut masih tertinggal dalam coding, penalaran, code infilling, dan pekerjaan jangka panjang.

Dua klaim itu bisa muncul bersamaan karena penguji mungkin memakai:

• Versi model yang berbeda.

• Prompt yang berbeda.

• Pengaturan penalaran yang berbeda.

• Alat coding yang berbeda.

• Repositori dan bahasa pemrograman yang berbeda.

• Batas token dan waktu yang berbeda.

• Penilaian manual yang tidak sama.

• Model internal yang belum sama dengan versi publik.

Benchmark tanpa metode yang jelas mirip membandingkan waktu tempuh Jakarta–Bandung tanpa menyebut kendaraan, jalur, cuaca, dan jam keberangkatan. Angkanya terlihat tegas, tapi belum tentu berguna.

Solusinya adalah membuat harness benchmark, yaitu program kecil yang mengirim tugas yang sama ke beberapa model, menyimpan jawaban, mengukur waktu, dan menjalankan pengujian otomatis.

Perbandingan klaim Gemini 3.5 Pro dengan pilihan lain

Tabel berikut bukan peringkat mutlak. Ini peta awal untuk menentukan hal yang perlu diuji saat akses publik tersedia.

Pilihan terbaik berdasarkan kebutuhan

• Pilih model cepat seperti Flash untuk klasifikasi, ringkasan singkat, ekstraksi data, dan permintaan berulang.

• Pertimbangkan Gemini 3.5 Pro untuk repositori besar, riset multimodal, perencanaan teknis, dan pekerjaan yang membutuhkan konteks panjang.

• Bandingkan dengan model coding lain untuk penyuntingan lintas berkas, penggunaan terminal, debugging, dan penyelesaian tugas dalam repositori nyata.

• Gunakan beberapa model jika risiko kesalahan tinggi. Satu model bisa menulis solusi, model lain meninjau, lalu pengujian otomatis menjadi penentu terakhir.

Untuk tim di Indonesia, biaya juga tidak boleh dihitung dari harga token saja. Kurs dolar, pajak, latensi jaringan, waktu peninjauan manusia, serta biaya memperbaiki kode yang salah bisa jauh lebih besar daripada tagihan API.

Getting Started: siapkan lingkungan pengujian

Tutorial ini tidak menganggap endpoint Gemini 3.5 Pro sudah tersedia untuk semua akun. Kita akan membuat kerangka yang memakai nama model lewat variabel lingkungan, sehingga model bisa diganti tanpa mengubah logika program.

Prasyarat

Teman-Teman perlu menyiapkan:

• Python 3.11 atau lebih baru.

• Git.

• Akun penyedia model yang akan diuji.

• Kunci API resmi.

• Penyunting kode seperti Visual Studio Code.

• Repositori contoh yang aman.

• Pemahaman ringan tentang terminal.

• Anggaran API dengan batas pemakaian.

Jangan menguji agen coding pertama kali pada repositori produksi. Buat salinan lokal atau cabang Git terpisah agar perubahan mudah dibatalkan.

Step 1 — Buat proyek benchmark yang terisolasi

Buka terminal, lalu jalankan:

mkdir gemini-35-benchmark
cd gemini-35-benchmark

python -m venv .venv

Aktifkan lingkungan virtual.

Windows PowerShell

.venv\Scripts\Activate.ps1

macOS dan Linux

source .venv/bin/activate

Buat struktur proyek:

gemini-35-benchmark/
├── app/
│   ├── __init__.py
│   ├── client.py
│   ├── evaluator.py
│   └── runner.py
├── tasks/
│   └── coding_tasks.json
├── results/
├── tests/
│   └── test_sample.py
├── .env.example
├── .gitignore
└── requirements.txt

Tambahkan dependensi ke requirements.txt:

httpx==0.27.0
python-dotenv==1.0.1
pytest==8.2.2

Lalu pasang:

pip install -r requirements.txt

Kenapa langkah ini penting? Lingkungan virtual mencegah benturan versi pustaka dengan proyek lain. Struktur yang rapi juga memisahkan tugas, koneksi API, hasil, dan logika penilaian.

Output yang diharapkan

Successfully installed httpx python-dotenv pytest ...

Versinya mungkin berbeda. Yang penting, instalasi selesai tanpa pesan ERROR.

Step 2 — Simpan konfigurasi tanpa membocorkan kunci API

Isi .gitignore:

.venv/
.env
__pycache__/
.pytest_cache/
results/*.json
results/*.jsonl

Buat .env.example:

MODEL_API_KEY=replace_with_your_key
MODEL_BASE_URL=https://example-provider.invalid/v1
MODEL_NAME=replace_with_official_model_id
REQUEST_TIMEOUT=180
MAX_OUTPUT_TOKENS=8192

Salin menjadi .env:

cp .env.example .env

Pengguna Windows bisa menjalankan:

Copy-Item .env.example .env

Masukkan endpoint dan identitas model yang benar setelah tersedia di dokumentasi resmi. Jangan menebak nama seperti gemini-3.5-pro lalu menganggapnya pasti valid.

Kenapa langkah ini penting? Nama pemasaran belum tentu sama dengan identitas API. Model bisa tersedia di satu layanan, tetapi belum muncul di layanan lain atau belum aktif di wilayah akun Teman-Teman.

Kunci API juga tidak boleh ditaruh langsung dalam kode karena berisiko ikut terkirim ke GitHub.

Step 3 — Buat daftar tugas coding yang adil

Isi tasks/coding_tasks.json:

[
  {
    "id": "python-validation-001",
    "category": "bug_fix",
    "language": "python",
    "prompt": "Perbaiki fungsi validate_email agar menolak alamat tanpa domain yang valid. Kembalikan hanya kode fungsi.",
    "starter_code": "def validate_email(value):\n    return '@' in value\n",
    "expected_behavior": [
      "Menerima [email protected]",
      "Menolak user@",
      "Menolak @example.com",
      "Menolak nilai non-string"
    ]
  },
  {
    "id": "javascript-total-001",
    "category": "implementation",
    "language": "javascript",
    "prompt": "Lengkapi fungsi calculateTotal. Abaikan item dengan quantity negatif dan bulatkan hasil ke dua angka desimal.",
    "starter_code": "function calculateTotal(items) {\n  // TODO\n}\n",
    "expected_behavior": [
      "Mengalikan price dengan quantity",
      "Mengabaikan quantity negatif",
      "Mengembalikan angka dua desimal",
      "Tidak mengubah array input"
    ]
  },
  {
    "id": "sql-report-001",
    "category": "sql",
    "language": "sql",
    "prompt": "Tulis kueri untuk menghitung pendapatan bulanan per cabang dari tabel orders. Hanya sertakan status paid.",
    "starter_code": "",
    "expected_behavior": [
      "Memfilter status paid",
      "Mengelompokkan cabang dan bulan",
      "Menjumlahkan total",
      "Menggunakan sintaks SQL yang jelas"
    ]
  }
]

Mulailah dengan tugas kecil yang jawabannya mudah diperiksa. Setelah kerangka stabil, tambahkan:

• Perbaikan bug lintas berkas.

• Refaktor tanpa mengubah perilaku.

• Penulisan pengujian.

• Analisis kerentanan.

• Migrasi basis data.

• Pembuatan antarmuka.

• Tugas konteks panjang.

• Tugas yang membutuhkan pemanggilan alat.

Kenapa ini penting? Prompt buatan sendiri sering terlalu dekat dengan selera pembuat benchmark. Campuran kategori memberi gambaran yang lebih jujur tentang kekuatan dan kelemahan model.

Hindari soal yang mungkin pernah tersebar luas beserta jawabannya. Model bisa tampak pintar karena mengingat pola, bukan karena benar-benar menyelesaikan masalah.

Step 4 — Buat klien API yang mudah diganti

Isi app/client.py:

import os
import time
import httpx
from dotenv import load_dotenv

load_dotenv()

class ModelClient:
    def __init__(self):
        self.api_key = os.environ["MODEL_API_KEY"]
        self.base_url = os.environ["MODEL_BASE_URL"].rstrip("/")
        self.model_name = os.environ["MODEL_NAME"]
        self.timeout = float(os.getenv("REQUEST_TIMEOUT", "180"))
        self.max_output_tokens = int(
            os.getenv("MAX_OUTPUT_TOKENS", "8192")
        )

    def generate(self, prompt: str) -> dict:
        payload = {
            "model": self.model_name,
            "input": prompt,
            "max_output_tokens": self.max_output_tokens,
            "temperature": 0
        }

        headers = {
            "Authorization": f"Bearer {self.api_key}",
            "Content-Type": "application/json"
        }

        started_at = time.perf_counter()

        with httpx. Client(timeout=self.timeout) as client:
            response = client.post(
                f"{self.base_url}/responses",
                headers=headers,
                json=payload
            )
            response.raise_for_status()
            data = response.json()

        latency = time.perf_counter() - started_at

        return {
            "model": self.model_name,
            "latency_seconds": round(latency, 3),
            "raw_response": data
        }

Format permintaan di atas bersifat adapter generik, bukan kontrak resmi Gemini. Saat memakai Gemini API atau Vertex AI, sesuaikan payload, autentikasi, URL, dan cara membaca output dengan dokumentasi resminya.

Pendekatan adapter membuat bagian lain dari benchmark tetap sama. Teman-Teman hanya mengganti satu berkas saat struktur API berubah.

Kesalahan yang sering muncul

KeyError: 'MODEL_API_KEY'

Artinya .env tidak ditemukan, salah nama, atau belum berisi variabel tersebut.

401 Unauthorized

Biasanya kunci tidak valid, metode autentikasi keliru, atau akun belum mendapat akses.

404 Not Found

Nama model atau endpoint kemungkinan salah. Jangan langsung menyimpulkan model belum dirilis sebelum memeriksa layanan dan wilayah yang dipakai.

Step 5 — Standarkan prompt pengujian

Buat fungsi penyusun prompt di app/runner.py:

def build_prompt(task: dict) -> str:
    behavior = "\n".join(
        f"- {item}" for item in task["expected_behavior"]
    )

    return f"""
Anda sedang mengikuti evaluasi coding terkontrol.

ID tugas: {task["id"]}
Bahasa: {task["language"]}
Kategori: {task["category"]}

Instruksi:
{task["prompt"]}

Kode awal:
```{task["language"]}
{task["starter_code"]}

Perilaku yang diharapkan: {behavior}

Aturan:

1. Jangan mengubah persyaratan.

2. Jangan menambahkan dependensi tanpa alasan.

3. Berikan kode yang bisa dijalankan.

4. Jelaskan asumsi secara singkat setelah kode. """.strip()

Gunakan `temperature: 0` pada pengujian pertama agar variasi jawaban lebih rendah. Setelah itu, jalankan beberapa pengulangan untuk mengukur konsistensi.

**Kenapa prompt harus sama?** Perubahan satu kalimat saja bisa memengaruhi hasil. Kalau model A diberi konteks lengkap sementara model B hanya menerima instruksi singkat, perbandingannya tidak adil.

### Tip pengujian yang lebih kuat

Jalankan setiap tugas minimal tiga kali:

1. Pengujian deterministik dengan suhu rendah.
2. Pengujian ulang untuk mengecek konsistensi.
3. Pengujian dengan konteks tambahan untuk melihat apakah hasil membaik atau malah memburuk.

Untuk model dengan Deep Think, catat apakah mode tersebut aktif. Jangan membandingkan mode penalaran berat dengan mode cepat tanpa menjelaskan perbedaannya.

## Step 6 — Jalankan benchmark dan simpan hasil mentah

Lengkapi `app/runner.py`:

```python
import json
from datetime import datetime, timezone
from pathlib import Path

from app.client import ModelClient

def build_prompt(task: dict) -> str:
    behavior = "\n".join(
        f"- {item}" for item in task["expected_behavior"]
    )

    return f"""
Anda sedang mengikuti evaluasi coding terkontrol.

ID tugas: {task["id"]}
Bahasa: {task["language"]}
Kategori: {task["category"]}

Instruksi:
{task["prompt"]}

Kode awal:
```{task["language"]}
{task["starter_code"]}

Perilaku yang diharapkan: {behavior}

Aturan:

1. Jangan mengubah persyaratan.

2. Jangan menambahkan dependensi tanpa alasan.

3. Berikan kode yang bisa dijalankan.

4. Jelaskan asumsi secara singkat setelah kode. """.strip()

def load_tasks(path: str) -> list[dict]: with open(path, "r", encoding="utf-8") as file: return json.load(file)

def main(): client = ModelClient() tasks = load_tasks("tasks/coding_tasks.json") output_path = Path("results/results.jsonl") output_path.parent.mkdir(exist_ok=True)

with output_path.open("a", encoding="utf-8") as output:
    for task in tasks:
        prompt = build_prompt(task)

        try:
            result = client.generate(prompt)
            record = {
                "timestamp": datetime.now(timezone.utc).isoformat(),
                "task_id": task["id"],
                "status": "success",
                **result
            }
        except Exception as error:
            record = {
                "timestamp": datetime.now(timezone.utc).isoformat(),
                "task_id": task["id"],
                "status": "error",
                "error_type": type(error).__name__,
                "error_message": str(error)
            }

        output.write(
            json.dumps(record, ensure_ascii=False) + "\n"
        )
        print(record["task_id"], record["status"])

if name == "main": main()

Jalankan:

```bash
python -m app.runner

Output yang diharapkan

python-validation-001 success
javascript-total-001 success
sql-report-001 success

Berkas results/results.jsonl akan berisi satu objek JSON per baris. Format JSONL cocok untuk eksperimen karena hasil baru bisa ditambahkan tanpa menulis ulang seluruh berkas.

Kenapa respons mentah harus disimpan? Evaluasi otomatis kadang salah. Dengan menyimpan hasil asli, Teman-Teman bisa meninjau keputusan penilai dan memeriksa apakah model sebenarnya benar, tetapi format jawabannya berbeda.

Step 7 — Nilai jawaban dengan metrik yang masuk akal

Benchmark coding sebaiknya tidak hanya memakai penilaian “terlihat bagus”. Kode yang rapi masih bisa gagal saat dijalankan.

Gunakan beberapa lapisan penilaian:

Buat app/evaluator.py:

from dataclasses import dataclass

@dataclass
class Evaluation:
    tests_passed: int
    tests_total: int
    instruction_score: float
    latency_seconds: float
    human_fix_minutes: float

    @property
    def pass_rate(self) -> float:
        if self.tests_total == 0:
            return 0.0
        return self.tests_passed / self.tests_total

    @property
    def practical_score(self) -> float:
        test_component = self.pass_rate * 60
        instruction_component = self.instruction_score * 30
        repair_penalty = min(self.human_fix_minutes, 20) * 0.5
        latency_penalty = min(self.latency_seconds / 60, 5)

        score = (
            test_component
            + instruction_component
            - repair_penalty
            - latency_penalty
        )
        return round(max(score, 0), 2)

Rumus tersebut hanya contoh. Sesuaikan bobot dengan kebutuhan organisasi.

Kalau tim Teman-Teman mengelola sistem pembayaran, keamanan dan tingkat lulus pengujian harus mendapat bobot besar. Untuk prototipe promosi UMKM, kecepatan dan kualitas visual mungkin lebih penting.

Step 8 — Uji klaim jendela konteks 2 juta token secara bertahap

Jangan langsung mengirim dua juta token. Biayanya bisa tinggi dan hasilnya sulit dianalisis.

Mulailah dengan beberapa ukuran:

• 10.000 token.

• 50.000 token.

• 100.000 token.

• 250.000 token.

• 500.000 token.

• Naik lebih jauh hanya jika akses, biaya, dan batas API memungkinkan.

Tempatkan fakta uji pada posisi berbeda:

def build_long_context_document(
    filler_blocks: list[str],
    secret_fact: str,
    position: str
) -> str:
    marker = f"FAKTA_PENTING: {secret_fact}"

    if position == "start":
        blocks = [marker, *filler_blocks]
    elif position == "middle":
        middle = len(filler_blocks) // 2
        blocks = [
            *filler_blocks[:middle],
            marker,
            *filler_blocks[middle:]
        ]
    elif position == "end":
        blocks = [*filler_blocks, marker]
    else:
        raise ValueError("position harus start, middle, atau end")

    return "\n\n".join(blocks)

Setelah itu, minta model:

1. Menemukan fakta.

2. Menjelaskan konteksnya.

3. Menghubungkannya dengan dua informasi lain.

4. Mengutip bagian yang relevan.

5. Menolak fakta pengganggu yang mirip.

Kenapa bukan sekadar tanya “apa fakta rahasianya”? Pencarian kata sederhana belum membuktikan penalaran konteks panjang. Model yang bagus harus mampu mengambil informasi, memahami hubungan, dan menghindari pengalih perhatian.

Output yang diharapkan

{
  "position": "middle",
  "retrieval_correct": true,
  "relation_correct": true,
  "distractor_rejected": true
}

Kalau model berhasil pada 100.000 token tetapi turun tajam pada 500.000 token, angka kapasitas maksimal masih benar secara teknis. Hanya saja, kapasitas input dan kualitas pemahaman bukan hal yang sama.

Step 9 — Uji Deep Think secara terpisah

Mode penalaran berat kemungkinan mengorbankan kecepatan dan biaya demi hasil lebih baik. Karena itu, bandingkan dua konfigurasi pada tugas yang sama:

• Mode standar.

• Mode Deep Think.

• Batas waktu yang sama atau dicatat secara transparan.

• Jumlah pengulangan yang sama.

• Pengujian otomatis yang sama.

Pakai tugas yang memang membutuhkan penalaran, misalnya:

Sebuah layanan menerima 8.000 permintaan per menit. Setiap pekerja
mampu menangani 25 permintaan per detik dengan pemakaian CPU rata-rata
60%. Rancang strategi penskalaan yang tetap bertahan jika satu zona
gagal. Jelaskan asumsi, hitung kapasitas minimum, lalu berikan contoh
konfigurasi.

Jangan menilai Deep Think dari soal yang jawabannya hanya satu fungsi sederhana. Mode berat baru masuk akal jika kualitas tambahannya sebanding dengan waktu dan biaya.

Metrik yang perlu dicatat

• Persentase jawaban benar.

• Jumlah asumsi yang tidak berdasar.

• Waktu hingga respons selesai.

• Token penalaran jika tersedia.

• Biaya per tugas sukses.

• Menit koreksi manusia.

• Stabilitas pada tiga sampai lima pengulangan.

Step 10 — Uji kemampuan agen dan penggunaan alat

Rumor tentang Gemini Spark dan dukungan alat membuat bagian ini penting. Agen bukan sekadar model yang menulis teks. Agen menerima tujuan, memilih alat, membaca hasil, memperbaiki kesalahan, lalu berhenti pada waktu yang tepat.

Gunakan lingkungan kotak pasir dengan alat terbatas:

ALLOWED_TOOLS = {
    "read_file",
    "write_file",
    "run_tests",
    "search_code"
}

BLOCKED_PATTERNS = {
    "rm -rf",
    "sudo ",
    "curl | sh",
    "printenv",
    "cat ~/.ssh"
}

def validate_command(command: str) -> bool:
    normalized = command.lower().strip()

    if any(pattern in normalized for pattern in BLOCKED_PATTERNS):
        return False

    return True

Berikan agen tugas seperti:

Perbaiki bug pada fungsi perhitungan diskon.

Batasan:
- Baca hanya direktori src dan tests.
- Jangan memasang paket baru.
- Jalankan pengujian setelah perubahan.
- Berhenti jika perlu mengakses kredensial.
- Tampilkan diff sebelum menyimpan perubahan akhir.

Kenapa batasan ini penting? Agen yang kuat bisa membuat kesalahan dengan dampak lebih luas. Kemampuan memanggil banyak alat tidak berguna jika izin, audit, dan titik konfirmasinya tidak jelas.

Protokol seperti Model Context Protocol bisa membantu menyusun sambungan alat yang lebih seragam. Meski begitu, protokol tidak otomatis menyelesaikan masalah keamanan. Setiap server alat tetap perlu izin minimum, validasi parameter, dan pencatatan aktivitas.

Step 11 — Tambahkan retry tanpa menyembunyikan kegagalan

API bisa mengembalikan batas laju, gangguan sementara, atau waktu tunggu habis. Tambahkan retry untuk kesalahan yang memang layak dicoba ulang.

import random
import time
import httpx

def with_retry(operation, max_attempts=4):
    for attempt in range(1, max_attempts + 1):
        try:
            return operation()
        except (
            httpx. TimeoutException,
            httpx. NetworkError
        ):
            if attempt == max_attempts:
                raise

            delay = (2 ** attempt) + random.random()
            time.sleep(delay)

Jangan mencoba ulang semua kesalahan. Respons 401 Unauthorized tidak akan sembuh hanya karena ditunggu. Kesalahan 400 Bad Request juga biasanya menandakan payload perlu diperbaiki.

Kenapa kegagalan tetap harus dicatat? Reliabilitas API merupakan bagian dari kualitas produk. Kalau benchmark hanya menyimpan percobaan yang sukses, model dan layanannya akan terlihat lebih stabil daripada kenyataan.

Step 12 — Buat studi kasus yang dekat dengan kebutuhan Indonesia

Bayangkan sebuah tim pengembang di Bandung menangani platform pemesanan untuk 120 cabang usaha makanan. Repositorinya berisi layanan Python, panel React, skema SQL, dan dokumentasi operasional.

Background

Tim ingin mengetahui apakah model kelas atas bisa mempercepat perbaikan bug lintas berkas. Selama ini, satu tiket kompleks membutuhkan rata-rata 95 menit dari pembacaan masalah sampai pull request siap ditinjau.

Challenge/Problem

Masalah utamanya bukan sekadar menulis fungsi. Model harus:

• Menemukan aturan diskon dalam dokumentasi.

• Membaca implementasi pada tiga berkas.

• Memperbaiki fungsi tanpa merusak API.

• Menambah unit test.

• Menjalankan seluruh rangkaian pengujian.

• Menjelaskan risiko perubahan.

Konteks besar membantu, tetapi model juga bisa kehilangan fokus atau mengubah berkas yang tidak diminta.

Approach

Tim menyiapkan 30 tiket historis yang sudah selesai. Informasi sensitif, data pelanggan, kunci API, dan nama internal dihapus lebih dulu.

Setiap model mendapat:

• Snapshot repositori yang sama.

• Instruksi yang sama.

• Batas waktu 20 menit.

• Maksimal lima pemanggilan alat.

• Suhu rendah.

• Pengujian otomatis yang sama.

• Peninjauan anonim oleh dua pengembang.

Implementation

Eksperimen berjalan di cabang Git terpisah. Setiap perubahan diperiksa berdasarkan tingkat lulus pengujian, ukuran diff, waktu penyelesaian, dan menit koreksi manusia.

Contoh format pencatatannya:

{
  "task_id": "discount-branch-rule-07",
  "model": "official-model-id",
  "tests_passed": 48,
  "tests_total": 50,
  "latency_seconds": 312.8,
  "tool_calls": 4,
  "files_changed": 3,
  "human_fix_minutes": 14,
  "security_violation": false
}

Results dengan metrik yang masuk akal

Karena Gemini 3.5 Pro belum memiliki hasil publik yang cukup konsisten untuk skenario ini, angka berikut adalah target keputusan, bukan klaim performa model:

Ambang seperti ini lebih berguna daripada pertanyaan “model mana paling pintar?”. Tim hanya mengadopsi model jika hasilnya mempercepat pekerjaan tanpa menaikkan risiko.

Key Learnings

• Konteks besar berguna saat informasi tersebar, tetapi penyusunan konteks tetap penting.

• Unit test lebih dapat dipercaya daripada penilaian berdasarkan gaya jawaban.

• Waktu koreksi manusia sering menjadi metrik ROI terbaik.

• Perubahan kecil yang tepat biasanya lebih berharga daripada diff besar.

• Agen wajib berhenti ketika membutuhkan kredensial atau izin tambahan.

• Benchmark perlu memakai pekerjaan yang mirip dengan kondisi sehari-hari.

Kesalahan umum saat menilai Gemini 3.5 Pro leak

Menganggap tanggal 17 Juli sebagai kepastian

Tanggal tersebut banyak disebut dalam laporan pihak ketiga, tetapi jadwal produk bisa berubah. Anggap sebagai target yang dilaporkan sampai Google menerbitkan pengumuman resmi.

Menggunakan nama model yang belum terdaftar

Pesan berikut tidak selalu berarti ada gangguan:

ModelNotFound: gemini-3.5-pro

Periksa:

• Apakah identitas model sudah benar.

• Apakah tersedia di Gemini API atau hanya Vertex AI.

• Apakah akun sudah mendapat akses.

• Apakah wilayah proyek mendukungnya.

• Apakah versi preview memakai akhiran khusus.

Membandingkan harga tanpa menghitung koreksi manusia

Model murah bisa menjadi mahal jika hasilnya perlu diperbaiki selama satu jam. Hitung biaya total:

biaya total =
biaya API
+ waktu peninjauan
+ waktu koreksi
+ biaya kegagalan
+ biaya infrastruktur

Menguji hanya satu prompt

Satu kemenangan tidak menunjukkan kestabilan. Jalankan tugas yang sama beberapa kali dan laporkan rentang hasil, bukan hanya skor terbaik.

Memakai data produksi untuk eksperimen awal

Hapus informasi pelanggan, token akses, nomor telepon, alamat, serta rahasia bisnis. Untuk perusahaan di Jakarta, Surabaya, Bandung, atau kota lain, lokasi bukan pembeda soal keamanan: prinsip minimasi data tetap sama.

Menganggap jawaban panjang lebih baik

Model yang menjelaskan banyak hal belum tentu menghasilkan kode benar. Pisahkan skor penjelasan dari tingkat lulus pengujian.

Troubleshooting benchmark Gemini 3.5 Pro

Permintaan selalu mengalami timeout

Coba langkah berikut:

1. Kurangi ukuran konteks.

2. Naikkan REQUEST_TIMEOUT secara bertahap.

3. Periksa apakah mode Deep Think aktif.

4. Gunakan streaming jika API mendukungnya.

5. Catat waktu respons pertama dan waktu selesai.

6. Jangan mengirim ulang permintaan tanpa batas.

Hasil sulit diurai karena bercampur penjelasan

Minta format keluaran terstruktur:

Kembalikan JSON dengan bentuk berikut:

{
  "language": "python",
  "code": "...",
  "assumptions": ["..."],
  "risks": ["..."]
}

Jangan tambahkan teks di luar JSON.

Tetap siapkan penanganan kalau model membungkus JSON dalam blok Markdown.

Kode terlihat benar tetapi unit test gagal

Periksa apakah model:

• Mengubah nama fungsi.

• Mengganti bentuk nilai kembalian.

• Menambah pustaka yang tidak tersedia.

• Mengabaikan kasus batas.

• Menghasilkan kode untuk versi bahasa berbeda.

• Menulis contoh, bukan implementasi lengkap.

Biaya melonjak pada pengujian konteks panjang

Gunakan strategi bertahap. Mulai dari konteks kecil, hentikan eksperimen jika kualitas sudah turun tajam, dan simpan hash dokumen agar input yang sama tidak diuji berulang tanpa alasan.

Agen terus mengulang langkah yang sama

Tambahkan batas:

MAX_TOOL_CALLS = 8
MAX_IDENTICAL_CALLS = 2
MAX_RUNTIME_SECONDS = 1200

Simpan jejak alat dan hentikan agen jika dua pemanggilan identik tidak menghasilkan perubahan keadaan.

Skor antarpenilai berbeda jauh

Buat rubrik yang lebih konkret:

• 0: persyaratan tidak terpenuhi.

• 1: terpenuhi sebagian dan butuh perubahan besar.

• 2: terpenuhi dengan koreksi kecil.

• 3: terpenuhi sepenuhnya.

Untuk tugas penting, pakai dua penilai dan bahas hanya kasus yang selisih skornya lebih dari satu poin.

Kelebihan dan kekurangan Gemini 3.5 Pro berdasarkan informasi saat ini

Kelebihan yang layak diuji

• Konteks sangat besar untuk repositori, dokumen, dan media panjang.

• Deep Think berpotensi membantu tugas yang membutuhkan banyak tahap penalaran.

• Multimodal cocok untuk alur yang mencampur kode, gambar, video, dan dokumen.

• Pembuatan visual terlihat menjadi salah satu fokus, termasuk SVG dan antarmuka.

• Integrasi ekosistem Google bisa memberi nilai lebih untuk organisasi yang sudah memakai Google Cloud dan Workspace.

• Arah agen dan alat relevan untuk otomatisasi pekerjaan teknis.

Kekurangan dan risiko

• Ketersediaan belum tentu merata.

• Harga resmi dan kuota perlu diperiksa saat peluncuran.

• Klaim benchmark masih bertentangan.

• Konteks besar bisa menaikkan biaya dan waktu respons.

• Mode penalaran berat belum tentu ekonomis untuk tugas sederhana.

• Agen yang lebih mandiri memperbesar kebutuhan kontrol keamanan.

• Hasil preview bisa berbeda dari versi publik.

• Integrasi yang terlalu dalam bisa meningkatkan ketergantungan pada satu penyedia.

Siapa yang paling cocok mengujinya?

Gemini 3.5 Pro layak masuk daftar uji untuk:

• Tim yang mengelola repositori besar.

• Pengembang aplikasi multimodal.

• Organisasi yang sudah memakai Google Cloud.

• Tim desain yang sering membuat prototipe interaktif.

• Analis yang perlu membaca kumpulan dokumen besar.

• Pengembang agen dengan kontrol alat yang ketat.

• Perusahaan yang bisa menjalankan evaluasi keamanan internal.

Model ini sebaiknya tidak langsung menjadi pilihan utama jika:

• Tugas sebagian besar berupa ringkasan pendek.

• Anggaran API sangat terbatas.

• Sistem tidak memiliki unit test.

• Tim belum punya proses peninjauan kode.

• Data tidak boleh masuk ke layanan eksternal.

• Kecepatan lebih penting daripada penalaran mendalam.

• Keputusan pembelian hanya berdasarkan benchmark bocor.

Tips agar pengujian tetap adil dan hemat

• Bekukan versi prompt selama satu putaran evaluasi.

• Catat nama model lengkap, bukan hanya nama produknya.

• Simpan tanggal pengujian karena model preview bisa berubah.

• Jalankan setiap tugas lebih dari sekali.

• Pisahkan skor kualitas, biaya, dan kecepatan.

• Gunakan unit test sebagai penentu utama untuk kode.

• Tinjau diff sebelum menjalankan perubahan.

• Jangan memberi agen akses ke kredensial produksi.

• Gunakan batas biaya harian.

• Bandingkan model pada tugas yang benar-benar dikerjakan tim.

• Laporkan kegagalan API, bukan hanya jawaban sukses.

• Ulangi benchmark setelah model atau alat coding diperbarui.

• Periksa dokumentasi resmi sebelum mengaktifkan nama model baru.

• Tunda migrasi besar sampai hasil pengujian konsisten.

Checklist saat akses Gemini 3.5 Pro tersedia

• Pastikan pengumuman berasal dari kanal resmi Google.

• Verifikasi identitas model dan layanan API.

• Catat status preview atau ketersediaan umum.

• Periksa wilayah, kuota, harga, dan batas konteks.

• Jalankan tugas coding kecil lebih dulu.

• Bandingkan mode standar dengan Deep Think.

• Uji pengambilan informasi pada konteks panjang.

• Ukur tingkat lulus unit test.

• Catat waktu respons dan biaya per tugas sukses.

• Hitung menit koreksi manusia.

• Uji agen hanya di lingkungan kotak pasir.

• Tinjau setiap pemanggilan alat.

• Bandingkan dengan model cepat dan model coding lain.

• Dokumentasikan versi prompt serta tanggal eksperimen.

• Jangan membawa model ke produksi sebelum lolos ambang keamanan.

Kesimpulan

Bocoran Gemini 3.5 Pro memberi gambaran model yang menjanjikan untuk coding, pemrosesan konteks panjang, aplikasi multimodal, dan agen berbasis alat. Namun, klaim performa yang belum konsisten, potensi biaya tinggi, serta risiko keamanan membuatnya lebih tepat dipandang sebagai kandidat pengujian daripada solusi yang langsung siap menggantikan sistem produksi.

Saat akses tersedia, nilai model melalui pekerjaan nyata dengan prompt tetap, unit test, lingkungan kotak pasir, dan pencatatan biaya serta waktu koreksi manusia. Verifikasi juga nama model, harga, kuota, dan status rilis melalui dokumentasi resmi Gemini API, bukan hanya berdasarkan tangkapan layar atau benchmark bocor.

Intinya, jangan biarkan hype menentukan keputusan teknis. Uji Gemini 3.5 Pro secara terukur, bandingkan dengan alternatif yang relevan, lalu adopsi hanya jika peningkatan kualitasnya benar-benar sepadan dengan biaya dan risikonya.

Referensi

Times of AI. (2026). Gemini 3.5 Pro Leaks: Expected Release Date, Features & More.

Geeky Gadgets. (2026). Google Gemini 3.5 Pro Leaks Show Struggles Against GPT-5.6.

Geeky Gadgets. (2026). Google Gemini 3.5 Pro Leaks with 2 Million Context Window.

Knight Li. (2026). Gemini 3.5 Pro Leak: Codenamed Cappuccino, Google Tries to Regain Momentum in Coding and Agents.

GitHub. (2026). System Prompts Leaks.

Knight Li. (2026). Gemini 3.5 Pro Leaks: Google Wants Spark Agent to Win Back the AI Coding Entry Point.

LinkedIn. (2026). Gemini 3.5 Pro Leaks Could Beat Gemini Flash Fast.

Studio Global. (2026). Gemini 3.5 Pro: Delayed to July 17, Rebuilt from Scratch—What We Know.

X. (2026). Gemini 3.5 Pro Benchmark Leak: Reportedly Outperforming Claude Fable 5 and GPT-5.6.

The AI Rankings. (2026). Gemini 3.5 Pro: 2M Context, Deep Think & Release Status.