Membangun model object detection hampir selalu dimulai dari pekerjaan yang sama: menggambar bounding box, memilih label, lalu mengulangi proses tersebut untuk ratusan atau ribuan gambar.

Masalahnya, proses labeling manual bukan hanya memakan waktu. Konsistensi anotasi juga mudah menurun ketika dataset semakin besar, jumlah kelas bertambah, atau beberapa anotator memiliki interpretasi berbeda.

Salah satu pendekatan yang kini dapat digunakan untuk mempercepat tahap tersebut adalah auto-labeling dengan vision-language model. Kita cukup memberikan gambar dan daftar objek yang dicari, kemudian model menghasilkan nama kelas beserta koordinat bounding box.

Dalam artikel ini, kita akan membangun pipeline auto-labeling menggunakan NVIDIA LocateAnything-3B, lalu mengubah hasilnya menjadi anotasi yang dapat digunakan untuk melatih model YOLO.

Apa Itu LocateAnything?

LocateAnything adalah vision-language model untuk melakukan visual grounding dan object localization berdasarkan instruksi bahasa alami. Model ini dapat digunakan untuk beberapa pekerjaan, antara lain:

• open-set dan long-tail object detection;
• dense multi-object detection;
• phrase grounding;
• GUI element grounding;
• OCR dan document-layout localization;
• point-based localization;
• automated dataset annotation.

LocateAnything menerima kombinasi gambar dan prompt teks, lalu menghasilkan label semantik serta koordinat objek yang ditemukan. rompt sederhananya:

Locate all the instances that match the following description:
person, motorcycle, helmet.

Respons model akan memiliki struktur seperti berikut:

<ref>person</ref><box><102><115><434><972></box>
<ref>helmet</ref><box><184><81><292><221></box>

Koordinat tersebut bukan koordinat piksel langsung. LocateAnything menggunakan bilangan bulat dalam rentang 0–1000, yang dapat dibagi dengan 1000 untuk memperoleh koordinat relatif terhadap lebar dan tinggi gambar.

<x1><y1><x2><y2>

dapat dikonversi menjadi:

x1_pixel = x1 / 1000 × image_width
y1_pixel = y1 / 1000 × image_height
x2_pixel = x2 / 1000 × image_width
y2_pixel = y2 / 1000 × image_height

Format relatif ini memudahkan kita mengubah hasil model ke format YOLO tanpa harus terlebih dahulu menghitung koordinat piksel.

Mengapa LocateAnything Menarik untuk Auto-Labeling?

Sebagian besar vision-language model generatif menghasilkan koordinat secara berurutan: nilai x1, kemudian y1, x2, dan y2.

LocateAnything memperkenalkan metode bernama Parallel Box Decoding atau PBD. Melalui PBD, sebuah bounding box diperlakukan sebagai satu unit geometris dan seluruh koordinatnya diprediksi secara paralel.

Pendekatan tersebut dirancang untuk meningkatkan kecepatan decoding sekaligus menjaga konsistensi struktur bounding box. Evaluasi NVIDIA menggunakan satu GPU H100, LocateAnything dilaporkan mencapai 12,7 boxes per second atau BPS. Angka ini lebih dari sepuluh kali throughput Qwen3-VL dan sekitar 2,5 kali throughput Rex-Omni dalam pengujian yang dilaporkan oleh tim peneliti. Perlu diperhatikan bahwa BPS mengukur kecepatan decoding box, bukan jumlah gambar end-to-end per detik. ything memiliki tiga mode inference:

Fast Mode

Mode fast hanya menggunakan parallel decoding. Mode ini memberikan throughput tertinggi dan cocok untuk:

• eksperimen cepat;
• dataset dengan adegan sederhana;
• initial pre-labeling;
• aplikasi yang sensitif terhadap latency.

Slow Mode

Mode slow menghasilkan koordinat secara autoregresif. Kecepatannya lebih rendah, tetapi menjadi mode yang paling stabil untuk:

• final labeling;
• dataset curation;
• offline evaluation;
• kasus dengan objek padat atau saling berdekatan.

Hybrid Mode

Mode hybrid memulai inference menggunakan parallel decoding. Ketika menemukan struktur yang tidak valid atau lokasi yang ambigu, model beralih sementara ke autoregressive decoding.

Mode ini menjadi pilihan default yang masuk akal karena menawarkan keseimbangan antara kecepatan dan kualitas. peline auto-labeling, strategi yang praktis adalah:

Hybrid mode → anotasi awal seluruh dataset
Slow mode   → validasi ulang gambar bermasalah
Human review → koreksi akhir pada sampel atau kasus ambigu

Arsitektur Pipeline

Pipeline yang akan kita bangun memiliki alur berikut:

Folder gambar
     │
     ▼
Daftar kelas atau prompt
     │
     ▼
LocateAnything inference
     │
     ▼
Parse <ref> dan <box>
     │
     ▼
Validasi koordinat
     │
     ├── Simpan respons mentah untuk audit
     │
     ▼
Konversi ke format YOLO
     │
     ▼
Folder labels/*.txt

Pada implementasi produksi, sebaiknya jangan langsung menganggap semua output model sebagai ground truth.

Istilah yang lebih tepat adalah pre-annotation: model menyiapkan anotasi awal, sementara sistem validasi dan manusia tetap menentukan kualitas akhirnya.

Instalasi LocateAnything

Kode resmi LocateAnything tersedia sebagai bagian dari repositori Eagle milik NVIDIA.

git clone https://github.com/NVlabs/Eagle.git eagle
cd eagle/Embodied

pip install -e .

PyTorch perlu dipasang secara terpisah sesuai versi CUDA pada komputer yang digunakan. Repositori resminya menggunakan beberapa dependency spesifik, termasuk Transformers 4.57.1. GPU dapat terdeteksi:

python -c "import torch; print(torch.cuda.is_available())"

Output yang diharapkan:

True

Model dapat diunduh secara otomatis dari Hugging Face ketika pertama kali dijalankan:

worker = LocateAnythingWorker("nvidia/LocateAnything-3B")

Karena implementasi resmi memuat custom model code, penggunaan production sebaiknya melakukan pin terhadap model revision dan meninjau kode yang dijalankan sebelum deployment.

Format Label YOLO

YOLO menggunakan format:

class_id x_center y_center width height

Semua koordinat berada dalam skala 0–1.

Sebagai contoh:

0 0.517000 0.431000 0.284000 0.526000

Jika LocateAnything menghasilkan:

x1 = 200
y1 = 150
x2 = 600
y2 = 750

maka koordinat relatifnya adalah:

x1 = 200 / 1000
y1 = 150 / 1000
x2 = 600 / 1000
y2 = 750 / 1000

Konversi ke YOLO:

x_center = (x1 + x2) / 2
y_center = (y1 + y2) / 2
width = x2 - x1
height = y2 - y1

Karena koordinat LocateAnything sudah dinormalisasi terhadap gambar, kita tidak perlu mengetahui resolusi gambar untuk membuat file YOLO.

Implementasi Auto-Labeling

Buat file bernama auto_label.py:

from __future__ import annotations

import argparse
import json
import re
from pathlib import Path
from typing import Iterator

from PIL import Image
from locateanything_worker import LocateAnythingWorker

MODEL_ID = "nvidia/LocateAnything-3B"

SUPPORTED_EXTENSIONS = {
    ".jpg",
    ".jpeg",
    ".png",
    ".bmp",
    ".webp",
}

# Sesuaikan dengan objek yang ingin dideteksi.
CLASSES = [
    "person",
    "motorcycle",
    "helmet",
]

CLASS_TO_ID = {
    class_name.lower(): class_id
    for class_id, class_name in enumerate(CLASSES)
}

# Format resmi:
# <ref>label</ref><box><x1><y1><x2><y2></box>
DETECTION_PATTERN = re.compile(
    r"<ref>(.*?)</ref>\s*"
    r"<box><(\d+)><(\d+)><(\d+)><(\d+)></box>",
    re.IGNORECASE,
)

def clamp(value: float, minimum: float = 0.0, maximum: float = 1.0) -> float:
    """Membatasi nilai agar selalu berada dalam rentang yang valid."""
    return max(minimum, min(value, maximum))

def normalize_label(label: str) -> str:
    """Membersihkan label yang dihasilkan model."""
    return " ".join(label.strip().lower().split())

def parse_detections(answer: str) -> Iterator[dict]:
    """
    Mengubah output LocateAnything menjadi anotasi terstruktur.

    Koordinat model berada dalam rentang 0–1000 dan langsung
    dikonversi menjadi koordinat relatif 0–1.
    """
    for match in DETECTION_PATTERN.finditer(answer):
        label = normalize_label(match.group(1))

        # Abaikan kelas yang tidak termasuk ontology dataset.
        if label not in CLASS_TO_ID:
            continue

        x1_raw, y1_raw, x2_raw, y2_raw = map(
            int,
            match.groups()[1:],
        )

        x1 = clamp(x1_raw / 1000.0)
        y1 = clamp(y1_raw / 1000.0)
        x2 = clamp(x2_raw / 1000.0)
        y2 = clamp(y2_raw / 1000.0)

        # Jangan memperbaiki box rusak secara diam-diam.
        # Lebih aman mengabaikannya dan mencatat output mentah.
        if x2 <= x1 or y2 <= y1:
            continue

        yield {
            "label": label,
            "class_id": CLASS_TO_ID[label],
            "x1": x1,
            "y1": y1,
            "x2": x2,
            "y2": y2,
        }

def detection_to_yolo(detection: dict) -> str:
    """Mengonversi satu bounding box ke format YOLO."""
    x1 = detection["x1"]
    y1 = detection["y1"]
    x2 = detection["x2"]
    y2 = detection["y2"]

    x_center = (x1 + x2) / 2.0
    y_center = (y1 + y2) / 2.0
    width = x2 - x1
    height = y2 - y1

    return (
        f'{detection["class_id"]} '
        f"{x_center:.6f} "
        f"{y_center:.6f} "
        f"{width:.6f} "
        f"{height:.6f}"
    )

def collect_images(image_directory: Path) -> list[Path]:
    """Mengambil semua gambar yang didukung secara rekursif."""
    return sorted(
        path
        for path in image_directory.rglob("*")
        if path.is_file() and path.suffix.lower() in SUPPORTED_EXTENSIONS
    )

def run_auto_labeling(
    image_directory: Path,
    label_directory: Path,
    audit_file: Path,
    generation_mode: str,
) -> None:
    label_directory.mkdir(parents=True, exist_ok=True)
    audit_file.parent.mkdir(parents=True, exist_ok=True)

    images = collect_images(image_directory)

    if not images:
        raise RuntimeError(
            f"Tidak ditemukan gambar di {image_directory.resolve()}"
        )

    print(f"Memuat model {MODEL_ID} ...")

    worker = LocateAnythingWorker(MODEL_ID)

    with audit_file.open("w", encoding="utf-8") as audit:
        for index, image_path in enumerate(images, start=1):
            try:
                image = Image.open(image_path).convert("RGB")

                result = worker.detect(
                    image,
                    CLASSES,
                    generation_mode=generation_mode,
                    max_new_tokens=8192,
                    verbose=False,
                )

                raw_answer = str(result["answer"])
                detections = list(parse_detections(raw_answer))

                yolo_lines = [
                    detection_to_yolo(detection)
                    for detection in detections
                ]

                relative_path = image_path.relative_to(image_directory)
                output_path = (
                    label_directory / relative_path
                ).with_suffix(".txt")

                output_path.parent.mkdir(parents=True, exist_ok=True)
                output_path.write_text(
                    "\n".join(yolo_lines),
                    encoding="utf-8",
                )

                # Respons mentah disimpan agar hasil dapat diperiksa ulang.
                audit_record = {
                    "image": str(image_path),
                    "label_file": str(output_path),
                    "generation_mode": generation_mode,
                    "classes": CLASSES,
                    "detection_count": len(detections),
                    "detections": detections,
                    "raw_answer": raw_answer,
                }

                audit.write(
                    json.dumps(audit_record, ensure_ascii=False) + "\n"
                )

                print(
                    f"[{index}/{len(images)}] "
                    f"{image_path.name}: "
                    f"{len(detections)} objek"
                )

            except Exception as error:
                error_record = {
                    "image": str(image_path),
                    "error": str(error),
                }

                audit.write(
                    json.dumps(error_record, ensure_ascii=False) + "\n"
                )

                print(
                    f"[{index}/{len(images)}] "
                    f"Gagal memproses {image_path.name}: {error}"
                )

def parse_arguments() -> argparse.Namespace:
    parser = argparse.ArgumentParser(
        description=(
            "Auto-label dataset object detection menggunakan "
            "NVIDIA LocateAnything."
        )
    )

    parser.add_argument(
        "--images",
        type=Path,
        required=True,
        help="Folder yang berisi gambar.",
    )

    parser.add_argument(
        "--labels",
        type=Path,
        required=True,
        help="Folder keluaran label YOLO.",
    )

    parser.add_argument(
        "--audit",
        type=Path,
        default=Path("auto_label_audit.jsonl"),
        help="Lokasi file audit JSONL.",
    )

    parser.add_argument(
        "--mode",
        choices=["fast", "slow", "hybrid"],
        default="hybrid",
        help="Mode decoding LocateAnything.",
    )

    return parser.parse_args()

if __name__ == "__main__":
    args = parse_arguments()

    run_auto_labeling(
        image_directory=args.images,
        label_directory=args.labels,
        audit_file=args.audit,
        generation_mode=args.mode,
    )

Jalankan program:

python auto_label.py \
  --images dataset/images/train \
  --labels dataset/labels/train \
  --audit dataset/auto_label_audit.jsonl \
  --mode hybrid

Struktur hasilnya akan menjadi:

dataset/
├── images/
│   └── train/
│       ├── image_001.jpg
│       ├── image_002.jpg
│       └── image_003.jpg
│
├── labels/
│   └── train/
│       ├── image_001.txt
│       ├── image_002.txt
│       └── image_003.txt
│
└── auto_label_audit.jsonl

Mengapa Respons Mentah Harus Disimpan?

Dalam pipeline machine learning, hasil anotasi sebaiknya dapat ditelusuri kembali.

File auto_label_audit.jsonl menyimpan:

• nama gambar;
• mode inference;
• daftar kelas;
• jumlah objek;
• koordinat hasil parsing;
• respons mentah model;
• pesan error jika inference gagal.

Data tersebut membantu ketika kita menemukan anotasi yang aneh.

Misalnya, model menghasilkan label kosong atau bounding box yang terlalu kecil. Kita dapat memeriksa apakah kesalahan terjadi pada respons model, parser, atau proses konversi.

Audit log juga berguna ketika model, prompt, dependency, atau parameter inference berubah.

Gunakan Ontology yang Jelas

Jangan memberikan daftar kelas yang ambigu.

Daftar berikut berpotensi menghasilkan label yang tumpang tindih:

CLASSES = [
    "vehicle",
    "car",
    "sedan",
]

Satu sedan dapat dianggap sebagai ketiga kelas tersebut.

Ontology yang lebih jelas:

CLASSES = [
    "car",
    "motorcycle",
    "bus",
    "truck",
]

Apabila kelas membutuhkan aturan khusus, tambahkan deskripsi ke prompt.

Contoh:

Locate all workers wearing a construction safety helmet.
Do not label caps, hats, or motorcycle helmets.

Model menerima free-form natural-language description, sehingga prompt dapat memuat konteks visual yang lebih spesifik daripada sekadar nama kelas. ata training dan prompt yang didokumentasikan untuk model ini umumnya menggunakan ekspresi bahasa Inggris yang pendek dan berorientasi pada tugas. Karena itu, prompt berbahasa Inggris biasanya menjadi titik awal yang lebih aman untuk eksperimen. tetap dapat menggunakan nama kelas berbahasa Indonesia. Buat pemisahan antara prompt dan nama label:

PROMPT_CLASSES = [
    "construction worker",
    "safety helmet",
]

DATASET_CLASSES = [
    "pekerja",
    "helm_keselamatan",
]

Jangan Mengandalkan Confidence Threshold

Pada object detector konvensional, kita biasanya menerima:

class, bounding box, confidence

Pada format output resmi LocateAnything yang didokumentasikan, hasil utamanya berupa label semantik dan koordinat terstruktur. Tidak ada skor confidence konvensional untuk setiap bounding box. tu, kita tidak dapat sekadar menulis:

if confidence > 0.8:
    save_label()

Sebagai gantinya, kualitas dapat dikendalikan dengan beberapa mekanisme:

1. Memeriksa validitas koordinat.
2. Menolak bounding box yang terlalu kecil atau terlalu besar.
3. Menjalankan kembali gambar yang mencurigakan dengan mode slow.
4. Membandingkan output dari dua variasi prompt.
5. Melakukan review manual pada sampel dataset.
6. Mengukur precision, recall, dan IoU terhadap subset yang telah diberi ground truth manusia.

Contoh aturan untuk menolak box sangat kecil:

MIN_BOX_AREA = 0.0005

box_area = (
    (detection["x2"] - detection["x1"])
    * (detection["y2"] - detection["y1"])
)

if box_area < MIN_BOX_AREA:
    continue

Nilai minimum tersebut tidak universal. Angkanya harus disesuaikan dengan ukuran objek yang memang dibutuhkan oleh aplikasi.

Human-in-the-Loop Tetap Diperlukan

Auto-labeling tidak berarti menghapus manusia dari proses anotasi.

Pendekatan yang lebih aman:

Tahap 1 — Buat Dataset Pilot

Pilih sekitar 100–300 gambar yang mewakili:

• variasi pencahayaan;
• sudut kamera;
• background;
• ukuran objek;
• kondisi occlusion;
• kepadatan objek.

Label subset tersebut secara manual sebagai validation set.

Tahap 2 — Uji Prompt

Jalankan beberapa variasi prompt dan bandingkan hasilnya.

Contoh:

helmet

dibandingkan dengan:

safety helmets worn by construction workers

Prompt kedua mungkin menghasilkan presisi lebih tinggi, tetapi dapat melewatkan helm yang sedang diletakkan di meja. Pilihan prompt harus mengikuti definisi label dataset.

Tahap 3 — Jalankan Hybrid Mode

Gunakan mode hybrid untuk menghasilkan pre-annotation pada seluruh dataset.

Tahap 4 — Tandai Kasus Mencurigakan

Masukkan gambar ke antrean review ketika:

• tidak ada objek yang ditemukan;
• jumlah box jauh di atas distribusi normal;
• terdapat box berukuran hampir satu gambar penuh;
• box terlalu kecil;
• model menghasilkan label di luar ontology;
• parser menemukan output tidak valid.

Tahap 5 — Re-Inference dengan Slow Mode

Gambar bermasalah dapat dijalankan ulang:

python auto_label.py \
  --images review/images \
  --labels review/labels \
  --audit review/slow_mode_audit.jsonl \
  --mode slow

Tahap 6 — Review Manusia

Gunakan aplikasi anotasi untuk memeriksa dan mengoreksi hasil akhir sebelum memasukkannya ke training set.

Dengan pola ini, anotator tidak lagi menggambar seluruh box dari awal. Mereka hanya memvalidasi, menggeser, menghapus, atau menambahkan box yang diperlukan.

LocateAnything dan YOLO Memiliki Peran Berbeda

LocateAnything bukan pengganti langsung untuk YOLO dalam semua skenario.

LocateAnything berguna sebagai generalist model pada tahap:

raw images → pre-annotation

YOLO digunakan sebagai specialist model pada tahap:

verified annotations → training → production inference

LocateAnything dapat mencari objek berdasarkan natural-language prompt tanpa terlebih dahulu melatih detector khusus untuk setiap kelas.

Sebaliknya, setelah dilatih dengan dataset domain-specific, YOLO biasanya lebih cocok untuk inference berulang yang membutuhkan latency rendah dan format output yang konsisten.

Alur lengkapnya:

Kumpulan gambar mentah
        │
        ▼
LocateAnything pre-labeling
        │
        ▼
Validasi otomatis
        │
        ▼
Koreksi manusia
        │
        ▼
Dataset YOLO
        │
        ▼
Training model YOLO
        │
        ▼
Evaluasi dan deployment

Praktik yang Sebaiknya Dihindari

Memproses Seluruh Dataset Tanpa Pilot Test

Kesalahan prompt pada 100 gambar masih mudah diperbaiki. Kesalahan yang sama pada 100.000 gambar akan menghasilkan technical debt yang besar.

Menerima Semua Kelas dari Model

Selalu gunakan class allowlist. Jangan otomatis menambahkan kelas baru hanya karena model menuliskannya.

Memperbaiki Koordinat Rusak Secara Diam-Diam

Jika model menghasilkan x2 < x1, jangan langsung menukar keduanya tanpa pencatatan. Box tersebut mungkin menandakan output yang tidak stabil.

Lebih aman menolak box dan memasukkan gambarnya ke antrean review.

Mengabaikan Empty Label

File anotasi kosong belum tentu berarti gambar tersebut benar-benar tidak memiliki objek. Bisa saja model gagal mendeteksi objek.

Empty label sebaiknya ikut diperiksa, terutama untuk dataset yang hampir seluruh gambarnya mengandung objek target.

Menghapus Raw Output

Parser dan aturan konversi dapat berubah. Menyimpan respons mentah memungkinkan kita menghasilkan ulang file anotasi tanpa menjalankan inference GPU kembali.

Catatan Lisensi

Pada saat artikel ini ditulis, model card resmi LocateAnything-3B menyatakan bahwa model dirilis untuk penggunaan nonkomersial, termasuk penelitian akademik dan nonprofit. Penggunaan komersial tidak diizinkan kecuali oleh NVIDIA dan afiliasinya. tu, baca dan evaluasi lisensi resminya sebelum menggunakan model untuk:

• produk komersial;
• layanan berbayar;
• dataset klien;
• aplikasi internal perusahaan;
• distribusi ulang model atau turunannya.

Lisensi source code dan lisensi model weights juga dapat memiliki ketentuan yang berbeda.

Kesimpulan

LocateAnything menunjukkan bagaimana vision-language model dapat digunakan bukan hanya untuk menjelaskan gambar, tetapi juga untuk menghasilkan lokasi objek yang terstruktur.

Kemampuan menerima natural-language prompt membuatnya menarik untuk proses pre-annotation, terutama ketika:

• jumlah kelas sering berubah;
• terdapat long-tail objects;
• dataset belum memiliki detector khusus;
• anotasi manual terlalu mahal;
• tim membutuhkan bootstrap dataset dengan cepat.

Namun, keberhasilan auto-labeling tidak hanya bergantung pada kualitas model.

Pipeline yang baik juga membutuhkan:

• ontology kelas yang tegas;
• prompt yang konsisten;
• validasi koordinat;
• audit log;
• subset ground truth;
• pengukuran kualitas;
• serta human-in-the-loop.

Dengan pendekatan tersebut, LocateAnything tidak diposisikan sebagai mesin pembuat ground truth tanpa kesalahan, melainkan sebagai annotation assistant yang mempercepat pekerjaan manusia.

Dan untuk banyak proyek computer vision, penghematan terbesar memang bukan berasal dari menghilangkan anotator — melainkan dari memastikan anotator tidak perlu menggambar setiap bounding box dari nol.

Auto-Labeling Dataset Object Detection dengan NVIDIA LocateAnything: Dari Prompt ke Format YOLO was originally published in DOT Intern on Medium, where people are continuing the conversation by highlighting and responding to this story.

Banyak orang mengira bahwa ketika perusahaan mulai menggunakan software akuntansi, peran spreadsheet seperti Google Sheets akan langsung hilang. Padahal dalam praktiknya, terutama di lingkungan kerja yang serba cepat, hal itu tidak selalu terjadi.

Selama menjalani magang di tim finance, saya justru melihat bahwa Google Sheets dan software akuntansi bukanlah dua alat yang saling menggantikan. Keduanya punya peran yang berbeda. Ketika digunakan secara berdampingan, hasilnya bisa jauh lebih efisien.

Kunci dari manajemen keuangan yang rapi ternyata bukan soal memilih tools mana yang paling unggul, tetapi bagaimana memahami fungsi masing-masing tools dan menggunakannya pada tahap kerja yang tepat.

Dua tools, dua fungsi berbeda

Sebelum membangun alur kerja yang efisien, tim finance perlu memahami karakter dari masing-masing alat.

Google Sheets: fleksibel untuk proses yang dinamis

Google Sheets sangat membantu untuk pekerjaan yang masih berubah-ubah dan membutuhkan penyesuaian cepat. Dalam operasional harian, tools ini cocok digunakan untuk:

• Perhitungan sementara, misalnya simulasi angka sebelum data difinalisasi.
• Tracker internal, seperti catatan pengingat pembayaran, monitoring transaksi, atau checklist pekerjaan harian.
• Analisis data mentah, dengan bantuan formula seperti VLOOKUP, FILTER, atau Pivot Table untuk memilah data dalam jumlah besar.

Keunggulan utama Google Sheets ada pada fleksibilitasnya. Tim bisa mengedit, menambahkan catatan, dan menyesuaikan format kapan saja sesuai kebutuhan.

Software akuntansi: terstruktur untuk pencatatan resmi

Di sisi lain, software akuntansi berperan sebagai sistem utama untuk proses keuangan yang membutuhkan akurasi, konsistensi, dan dokumentasi resmi. Biasanya software ini digunakan untuk:

• Menyusun laporan keuangan otomatis, seperti laba rugi, neraca, perubahan ekuitas, arus kas, atau CALK.
• Mengelola invoice secara sistematis, sehingga status tagihan masuk dan keluar bisa dipantau dengan lebih jelas.
• Mengurangi human error, karena sistem biasanya memiliki struktur akun, validasi data, dan alur input yang lebih ketat.

Kalau Google Sheets unggul dalam fleksibilitas, maka software akuntansi unggul dalam standardisasi.

Tantangan di lapangan

Salah satu tantangan yang saya temui selama magang adalah bagaimana mengelola aktivitas operasional harian yang perubahannya cukup cepat.

Kalau setiap perubahan kecil langsung dimasukkan ke software akuntansi, proses kerja bisa jadi tidak efisien. Terlalu banyak revisi kecil justru berisiko membuat input di sistem utama menjadi kurang rapi.

Namun, kalau seluruh proses hanya bergantung pada Google Sheets, ada risiko lain yang tidak kalah besar: human error. Salah rumus, salah referensi data, atau salah nominal bisa berdampak pada hasil akhir.

Dari situ saya belajar bahwa kedua tools ini tidak seharusnya diposisikan sebagai pilihan salah satu. Justru yang lebih efektif adalah membagi peran keduanya dengan jelas.

Solusi: hybrid workflow

Pendekatan hybrid workflow, yaitu alur kerja yang menggabungkan fleksibilitas spreadsheet dan akurasi software akuntansi.

Secara sederhana, alurnya bisa seperti ini:

1. Pencatatan harian di Google Sheets

Aktivitas operasional yang masih dinamis dicatat terlebih dahulu di Google Sheets. Misalnya, tracker pembayaran, monitoring invoice, atau catatan transaksi yang masih perlu dicek ulang.

2. Review berkala

Data yang sudah terkumpul kemudian ditinjau kembali secara berkala, misalnya mingguan atau bulanan. Pada tahap ini, data dirapikan, dicocokkan, dan divalidasi bersama pihak terkait.

3. Finalisasi di software akuntansi

Setelah data dipastikan bersih dan valid, barulah diinput ke software akuntansi sebagai pencatatan resmi perusahaan.

Dengan alur seperti ini, Google Sheets berfungsi sebagai ruang kerja yang fleksibel, sedangkan software akuntansi tetap menjadi single source of truth untuk laporan keuangan resmi.

Google Sheets vs Software Akuntansi? Di Tim Finance, Keduanya Justru Saling Melengkapi was originally published in DOT Intern on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kalau kamu pernah belajar soal software development, pasti udah nggak asing sama dua kubu besar ini: Agile vs Waterfall.

Di teori, keduanya kelihatan jelas banget bedanya.

Waterfall itu terstruktur, linear, dan rapi.
Agile itu fleksibel, iteratif, dan adaptif.

Tapi… pas masuk dunia kerja, ternyata nggak sesimpel itu.

Berdasarkan pengalaman saya sebagai Project Manager Intern di DOT, realitanya justru lebih abu-abu. Ingat sekali waktu upgrading materi project management, pemateri (salah satu PM di DOT) bertanya ke kami-kami project manager intern begini,

“Menurut kalian, project-project yang kalian pegang ini pakai metode apa? Waterfall atau Agile?”

Surprisingly, hampir dari kami semua kegocek😅 Banyak dari teman-teman salah kira projectnya menggunakan agile. Hanya 1 orang yang benar karena project yang ia pegang beneran agile menggunakan dokumen berita acara sprint-based. Padahal sehari-harinya kami melakukan koordinasi dengan tim dev layaknya metode agile. Nyatanya, selain satu yang benar itu, semua project menggunakan metode waterfall dengan scope, budget, dan timeline yang jelas.

Nah loh, kami semua be like: “Haaaaaah? Kok Bisaaaa?” 😳

Agile vs Waterfall: Versi Singkat

Waterfall itu cocok kalau:

• Scope udah jelas dari awal
• Semua requirement fix
• Perubahan minim

Royce (1970) menjelaskan bahwa model Waterfall berjalan secara berurutan dari tahap requirement sampai maintenance, dengan asumsi bahwa semuanya sudah direncanakan di awal.

Makanya, model ini sering dipakai di project yang berbasis kontrak karena semuanya harus jelas di depan.

Agile, di sisi lain, lebih fleksibel.

• Requirement bisa berubah
• Development jalan per iterasi (sprint)
• Feedback jadi bagian dari proses

Di Agile Manifesto, bahkan disebutkan:

Responding to change over following a plan (Beck et al., 2001)

Alias: perubahan itu bukan masalah, tapi justru bagian dari proses.

Secara teori, dua metode ini kayak berlawanan arah. Saling bertolak belakang. Seperti tidak mungkin saja akan dipakai secara bersamaan.

Tapi di dunia kerja?

Realita di Dunia Kerja, Hybrid is the Real Winner

Di project berbasis client, biasanya kita mulai dengan pendekatan Waterfall:

• Scope ditentukan di awal
• Timeline disepakati
• Deliverables jelas

Tapi masalahnya… client hampir pasti akan kasih feedback di tengah jalan. Feedback itu bisa berupa; revisi kecil, improvement, bahkan request baru.

Di titik ini, kita “dipaksa” buat jadi Agile.

Boehm & Turner (2004) juga menyebutkan bahwa banyak tim akhirnya pakai pendekatan hybrid karena butuh keseimbangan antara struktur (Waterfall) dan fleksibilitas (Agile).

Jadi ya… realitanya seperti ini,
👉 kita planning kayak Waterfall,
👉 tapi survive-nya pakai Agile.

Dan di sinilah peran Project Manager sebagai ujung tombak proyek menjadi penting. pake. banget.

Studi Kasus: Ketika Feedback Client Datang di Waktu yang… Nggak Ideal

Biar nggak terlalu teoritis, saya mau share satu studi kasus dari pengalaman saya.

Singkatnya di satu fase project, tim dev lagi jalan sesuai timeline dan scope yang sudah disepakati. Scope udah clear, development juga lagi on track. Tim sudah optimis akan sesuai ekspektasi awal.

Terus… masuklah sesi review dengan client.
Seperti yang bisa ditebak dan yap, ada feedback^^. Beberapa di antaranya:

• Optimasi performa website
• Penyesuaian tampilan di fitur tertentu
• Adjustment parameter suatu fitur

Sebagian kelihatan simple.
Sebagian lagi… berpotensi “ngebongkar dapur”.

Problemnya di Mana?

Ini dia yang menarik.

Secara waterfall mindset, scope sudah fix dan timeline harus dijaga. Namun secara agile reality, client butuh improvement dan feedback yang masuk nggak bisa dibiarin aja. Selain itu juga belum ada estimasi effort, belum tahu impact ke sistem, dan resource tim terbatas.

Kalau semua langsung dikerjain?

👉 Timeline bisa berantakan
👉 Tim bisa overload

Not a good idea.

Jadi, Apa yang Dilakukan?

Di sini saya belajar satu hal penting sebagai project manager. Jangan reaktif. Harus tetap strategis. Langkah-langkah yang bisa diambil pada waktu itu adalah:

1. Breakdown Dulu, Jangan Panik. Semua feedback dipecah jadi lebih detail. Sebenarnya yang mau diubah apa? Seberapa besar impact-nya? Karena “adjust dikit” dari client, belum tentu kecil di sisi teknis 😄
2. Ngobrol Sama Developer (hukumnya wajib). Project Manager nggak bisa ambil keputusan sendirian, harus melibatkan stakeholder yang terdampak, terutama pada saat feedback seperti ini tim dev merupakan stakeholder penting sebagai eksekutor. Diskusi dengan tim dev tujuannya untuk cek kompleksitas feedback, identifikasi risiko, dan melihat apakah ada kemungkinan side effect yang terjadi.
3. Estimasi Sebelum Eksekusi. Ini krusial banget. PMBOK Guide (PMI, 2017) juga menekankan bahwa estimasi itu penting untuk kontrol waktu dan resource. Tanpa estimasi = blind decision.
4. Prioritization alias nggak semua harus sekarang. Bisa kita pilah dengan memisahkan mana yang urgent, mana yang impactful, dan mana yang bisa ditunda.
5. Alignment ke Stakeholder. Hasil dari penerapan tahap-tahap di atas ini nggak cuma disimpan sendiri aja dong. Semua harus dikomunikasikan baik ke client maupun ke management serta tim internal, mulai dari apa yang bisa dikerjakan sekarang, apa yang masuk next phase, atau apa yang jadi additional scope.

Lesson Learned

Dari sini saya sadar beberapa hal;

Project itu bisa nggak 100% Agile atau Waterfall. Bisa jadi ada campuran. Entah kontrak dan deliverable kepada client secara waterfall, lalu eksekusi dengan tim dev secara agile, atau vice versa.

Project Manager itu bukan tukang forward. Bukan cuma nerusin request dari client ke dev. Tapi juga melakukan filter, analisis, dan sebagai decision maker. Kalau project managernya saja tidak paham konteks, bisa jadi projectnya akan berjalan di tempat.

Estimasi = Senjata Utama. Tanpa estimasi, semua keputusan cuma feeling. No☝️ No☝️ ya☝️ Usahakan keputusan-keputusan yang akan diambil ini memiliki data yang jelas.

Agile vs Waterfall itu memang seru buat dibahas dalam satu forum. Namun di dunia kerja, yang lebih penting bagi Project Manager, balik lagi ke fungsi awalnya, adalah balancing 3 hal penting ini;
👉 Scope
👉 Time
👉 Cost

Karena pada akhirnya, project yang sukses bukan soal metode development yang “paling Agile” atau “paling Waterfall”. Tapi yang paling bisa menghadapi perubahan tanpa kehilangan arah project.

Trust me, di situlah peran Project Manager benar-benar diuji.

Daftar Pustaka

Beck, K., et al. (2001). Manifesto for Agile Software Development.

Boehm, B., & Turner, R. (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley.

Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th ed.).

Pressman, R. S. (2010). Software Engineering: A Practitioner’s Approach (7th ed.). McGraw-Hill.

Royce, W. W. (1970). Managing the Development of Large Software Systems. Proceedings of IEEE WESCON.

Schwaber, K., & Sutherland, J. (2020). The Scrum Guide.

Agile vs Waterfall di Project Nyata: Teori Keren, Tapi Realitanya Nggak Sesimpel Itu was originally published in DOT Intern on Medium, where people are continuing the conversation by highlighting and responding to this story.

In today’s digital age, an Instagram feed is often the first impression potential clients and business partners see, especially for technology and digital companies such as IT agencies.

A minimalist corporate design conveys a professional image and is easy to maintain consistently across various media, but it runs the risk of appearing flat and failing to catch people’s attention as they scroll, while a design that’s too busy can actually damage the brand’s professional image.

This is where the glow effect plays a key role, using subtle lighting techniques that add depth and visual appeal without compromising the minimalist aesthetic, ensuring the feed remains engaging while fostering a positive perception among the audience.

What Is the Glow Effect, and Why Is It Suitable for Corporate Design?

According to Subframe, a well-executed glow effect is one where the chosen color complements the design and enhances the visibility of elements without looking excessive. Simply put, a glow effect is a lighting technique that makes certain elements such as icons, typography, or key visuals appear to emit a soft glow, thereby drawing attention to important parts without making the composition look cluttered.

Rather than adding new elements, the glow effect highlights existing elements to make them more recognizable, creating the perfect balance for a look that remains clean and structured yet feels more modern in the feed.

How Do You Apply a Glow Effect to a Minimalist Corporate Feed?

Here are a few ways to apply a glow effect to minimalist corporate designs.

• Determine the Focal Point
  Before adding a glow, first identify one element you want to highlight such as a logo, product icon, or main headline. Applying a glow to too many elements at once will actually weaken the effect and undermine the principle of minimalism.
• Choose a Glow Color That’s Consistent with Your Brand
  Glow colors should be selected from the brand’s existing color palette typically primary or accent colors. Choose colors that truly support and enhance readability, rather than colors that are so intense they strain the eyes. This ensures the effect blends seamlessly with the overall visual identity, rather than being merely a generic, afterthought embellishment.
• Apply Layered Blur and Opacity to Add Depth
  In Figma, this is done by duplicating the focal point element, then applying a layer blur or background blur with a gradually increasing radius, and reducing the opacity of each layer. Using the right amount of transparency makes the glow appear soft and adds depth without looking too harsh or distracting. This layered approach produces a soft gradation of light, rather than a flat, artificial-looking glow.
• Intensity and Placement Control
  The glow should be strong enough to be noticeable, but still subtle enough not to overpower the minimalist elements around it. Placing the glow slightly off-center or behind the typography often creates a more natural and premium look.
• Consistency Check Across the Grid Feed
  A single post isn’t enough to judge the final result. The glow effect needs to be tested alongside other posts on the Instagram grid to ensure visual consistency and to keep the overall feed looking cohesive and professional.

Case Study: Applying the Glow Effect to DOT Indonesia Conten

As a concrete example, one of DOT Indonesia’s educational slides is titled:

“Don’t Put Business Logic in the Scheduler”

which demonstrates how the glow effect can be effectively applied to minimalist corporate design. Here are a few things we can learn from this design:

• A clear focal point
  The glowing green circle on the left immediately catches the eye and serves as the starting point of the diagram’s flow, connecting the Scheduler, Job, Worker, and Service elements.
• Warna glow konsisten dengan brand
  The bright green color used for the glow effect matches the DOT brand’s accent color, so it blends seamlessly with the logo and visual identity and not just a decorative addition.
• Contrast against the dark background
  The minimalist dark green background allows the glow to really stand out without compromising the readability of the title, subtitle, or chart labels.
• Luminous line and dot elements
  The lines connecting the elements are also given a subtle glow effect, so that the flow of information remains dynamic without being excessive.
• The layout remains structured
  Although there are striking luminous elements, the grid layout, typography, and supporting elements such as photos of interviewees and page numbers (01/07) remain neat and consistent with DOT Indonesia’s minimalist style.

This case study shows that the glow effect doesn’t have to be applied to designs that are bright or colorful. In fact, against a dark, minimalist background, the glow effect can serve as a strong distinguishing element while still maintaining a professional and easy-to-read look.

Why Is This Technique Important for Corporate Branding?

The right use of the glow effect helps a minimalist corporate feed stand out amid a crowded Instagram timeline, without compromising the professional image expected by a corporate audience. This demonstrates that a company pays attention to detail and keeps up with design trends, which can indirectly strengthen the trust of clients and business partners.

Conclusion

Combining a glow effect with a minimalist corporate design allows a brand to remain visually appealing without losing the clean, professional identity that builds audience trust. By defining a clear focal point, staying consistent with the brand’s color palette, applying layered blur and opacity to make the glow look natural, and reviewing the results across the entire feed, designers can enhance the quality of a corporate Instagram presence while maintaining brand consistency, as seen in its application in one of DOT Indonesia’s educational posts.

References :

Subframe. 10 CSS Glow Effect Examples

Adobe. Create a Glow Effect

Onsight B2B Sales Blog. Minimalism in Branding: Is Less More?

Edge Digital. Clean Minimal Branding: Key Strategies for Effective Visual Identity

Enhancing Minimalist Corporate Design with Glow Effect for Instagram Feed was originally published in DOT Intern on Medium, where people are continuing the conversation by highlighting and responding to this story.

Pernah nggak kalian, kenapa button submit serasa lambat pada saat ditekan, padahal hanya merubah satu state?

Yap, mungkin itu jadi alasan kalian sampai ke artikel ini. Ini disebut dengan uncontrolled re-render, yang kalian rasakan adalah hasil dari re-render yang tidak terkontrol dengan baik.

Kenapa re-render buruk?

Bayangin aja, kalian hanya bikin aplikasi simpel, tapi serasa lambatnya minta ampun. UI tidak responsive dan masih banyak lagi. Ini terjadi karena pada perubahan state di component, react akan me-render semua child component tersebut, jika tidak di handle dengan baik. Maka dari itu pada kesempatan ini, aku akan berbagi tips soal mengatasi re-render di react.

Tapi sebelum itu, kita pahami dulu gimana history react secara dasar melakukan render?

React history

Pada tahun 2011 membuat website adalah hal yang mudah membuat frustrasi, walaupun pada saat itu sudah ada beberapa framework yang membantu dalam web development. diantaranya jQuery-Backbone.js dan Angular.js. Framework tersebut adalah inovasi terbesar pada zaman itu.

Namun, seiring aplikasi membesar, struktur kode menjadi berantakan dan sulit melacak bug — fenomena ini dikenal sebagai “jQuery fatigue”.

DOM, Document Object Model. adalah struktur yang ada pada html, semua tag pada html adalah bentuk kecil pada DOM, <html>-<body>-<p>-<div>

Kemudian, Backbone.js hadir dengan struktur yang lebih rapi, memisahkan data (state) dan tampilan (DOM). Sayangnya, fiturnya terlalu minimalis, sehingga developer harus membangun banyak hal dari nol dan perawatannya pun jadi susah.

Lalu munculah AngularJS dengan fitur melimpah. Masalahnya, performanya jadi lambat di aplikasi besar. Angular terus-menerus memeriksa perubahan di seluruh halaman (dirty checking), yang membuat interaksi sederhana seperti klik tombol pun bisa terasa lemot.

Oke, jadi react dibuat untuk mengatasi masalah AngularJS?

Yap, betul. Dibuat oleh Engineer Facebook(Meta), mereka sebagai platform besar menghadapi masalah ini, yang mana mengupdate UI menjadi momok yang menakutkan.

Jordan Walke, salah satu engineer facebook. dia punya ide untuk mengatasi masalah AngularJS ini, yaitu:

Bagaimana kalau daripada mengupdate bagian spesifik pada DOM. kenapa tidak di render ulang semua.

Ya, kalian gak salah baca, dia malah memberikan ide yang berlawanan dengan inovasi AngularJS. Ini karena, me-re render semua bukanlah hal efisien, pada framework sebelumnya sudah ada inovasi spesifik rendering agar lebih mudah dan efisien, malah kembali ke zaman batu. Bahkan engineer lainya juga tidak setuju dengan ide tersebut.

Tapi dia punya ide lagi untuk mengatasi masalah ini. munculah Virtual DOM

Virtual DOM

Anggap saja sebagai salinan ringan dari real DOM. Secara simpelnya begini, setiap state aplikasi berubah react akan membandingkan dengan Virtual DOM versi lama dengan yang baru. Dilihat lah nanti perbandingannya dari paling yang kecil, jika sudah, nanti di aplikasikan ke real DOM.

Hah, masih gak paham?

Oke, Bayangkan kita perlu mengedit halaman 100 dari sebuah buku setebal 300 halaman.

Cara Angular (Dirty Checking):

• Membaca ulang seluruh buku asli dari halaman pertama untuk mencari apa yang berubah.
• Setelah ketemu di halaman 100, langsung mengubahnya di buku asli.

Cara React (Virtual DOM):

• Membuat salinan virtual(semacam daftar isi super detail) dari buku.
• Saat ada editan, React mnegedit pada salinannya lalu membandingkan keduanya untuk menemukan perbedaannya (yaitu, perubahan di halaman 100).
• React kemudian langsung membuka halaman 100 di buku asli dan menerapkan perubahan spesifik itu.

Kayaknya extra steps, bukannya malah cepetan angular?

Sekilas begitu, tapi secara real-practice, melakukan scanning pada virtual copy lebih cepat dan efisien. Terlebih lagi, kita bisa langsung mengedit pada halaman spesifik real dom, tidak perlu melakukan scanning awal pada real dom.

Re-rendering Issue

Okay, begitu, kenapa kita perlu merhatikan re-rendering, kan udah ada vitual dom buat ngurus itu.

Nah, aku jelaskan dulu. Kita semua paham kalau react menggunakan component based. Jadi bagian-bagian dari react berisi dengan komponen-komponen yang bisa membangun sebuah aplikasi yang bisa digunakan.

Nah, komponen ini adalah yang dimaksud dengan bagian kecil dari virtual dom.

Hah gimana?

Oke aku jelaskan, alasan react bisa menjadi cepat dan lebih unggul dari angular salah satunya karena ini, jadi jika ada changes, dia akan mengupdate bagian komponen itu sendiri. Jadi react nanti hanya perlu mengecek pada bagian komponen tersebut. tidak perlu pada semua dom.

Dengan begitu, react bisa menjadi lebih powerful daripada angular.

Oke, kalau begitu kenapa kita perlu memerhatikan re render ini?

Oke, aku sudah jelaskan kalau komponen adalah bentuk paling kecil pada virtual dom. Nah kalau komponen itu update maka dia akan me-render ulang pada semua komponen itu di virtual dom. ya memang kelihatan sepele, orang hanya di virtual dom yang ringan. tapi semakin besar aplikasi kita, maka peforma itu akan semakin terasa.

Untuk menghindari itu, kita harus biasakan dalam menulis kode yang baik, kebiasaan ini dimulai dari hal-hal kecil yang harus disiplin kita lakukan. Berikut beberapa saran untuk mengoptimalkan re-render di aplikasi React Kamu.

1. Simpan data Mutable di useRef daripada useState

Hanya berlaku pada variabel yang belum di render/tidak ditampilkan ke user

Sebagai developer React, kita sering kebiasaan menggunakan useState dan melupakan useRef. Padahal, fungsi keduanya sangat berbeda.

• useState digunakan untuk menyimpan data yang ketika berubah, perlu re-render pada komponen. Contoh, jika kita ingin mengubah counter di tampilan halaman(component yang sudah di render), maka dengan hook ini, React akan mentrigger render ulang.
• useRef tidak mentrigger re-render saat nilainya diubah. Dengan useRef, kita bisa menyimpan dan mengubah variabel tanpa perlu melakukan re-render komponen.

// ❌ Tidak optimal
const FormComponent = () => {
  const [formData, setFormData] = useState({
    name: '',
    email: '',
    // variabel validasi yang tidak perlu ditampilkan
    isValid: false 
  });
  
  // saat validasi di panggil, komponen akan di re-render
  const validateForm = () => {
    setFormData(prev => ({
      ...prev,
      isValid: prev.name.length > 0 && prev.email.includes('@')
    }));
  };
};

// ✅ Optimal
const OptimizedFormComponent = () => {
  const [formInputs, setFormInputs] = useState({
    name: '',
    email: ''
  });
  
  // Gunakan useRef untuk data yang tidak perlu me-render UI
  const formStateRef = useRef({
    isValid: false,
    lastUpdated: null
  });
  
  // saat validasi di panggil, komponen tidak akan di re-render
  const validateForm = () => {
    formStateRef.current.isValid = 
      formInputs.name.length > 0 && formInputs.email.includes('@');
    formStateRef.current.lastUpdated = new Date();
  };
};

Mungkin hal ini sepele, tapi biasanya kita lupa dengan hal ini, seiringnya dengan adanya state-management. kadang kita terpaku dengan menggunakan itu, yang mana case-nya sama-sama mentrigger re-render. useRef memang hal sepele, tapi bisa kita gunakan dengan baik dengan mengetahui fungsinya yang telah di jelaskan di atas.

berikut contoh sebelum dan sesudah

2. Gunakan useMemo, tapi dengan hati-hati!!

💡Terlalu banyak memoization juga buruk untuk performa

Oke, ini hal tricky. Memoization memang penyelamat, tapi semakin banyak penggunaannya, maka semakin buruk. Jadi kita harus berhati-hati kapan menggunakan useMemo dan kapan tidak.

useMemo, memudahkan kita dalam mengkontrol re render ini. Dengan useMemo, kita bisa menyuruh sebuah function atau komponen untuk melakukan update ke memori dengan ketentuan spesifik, jadi tidak selalu di lakukan re-render setiap state change.

Kita ambil contoh, anggap kita perlu membuat component yang statis, contoh saja disini membuat opsi sleect yang bersisi data constant.

const MainKompt = () => {
 const [state, setState] = useState()
 
 const StaticKomp = () => {
  const heavyDataPros = () => {
   const options = ["A", "B", "C", "D", "E", "F", "G", "H", "I"]
   new Promise(() => setTimeout(3000))
   return options.map((it) => {
    label: it,
    value: it
   })
  }
  
  return <Select placeholder="Select options" options={heavyDataProps} />
 }
 
 return <>
   <button onClick={() => setState((prev) => prev++)}>increment</button>
   <h1>{state}</h1>
   <StaticKomp />
  </>
}

Dari sini kita bisa dilihat, kalau StaticKomp memiliki data statis yang akan sama terus menerus, tapi membutuhkan perhitungan lama. Ketika react melakukan render ulang pada MainKompt, component tersebut akan merender ulang child trsebut, meskipun tidak ada hubungan state.

Daripada melakukan re-render pada child, kita bisa membuat child untuk menggunakan useMemo. Jadi kita cukup mengingat component ini, tanpa perlu melakuakn re-render berkali-kali.

const MainKompt = () => {
 const [state, setState] = useState()
 
 const StaticKomp = useMemo(() => {
  const heavyDataPros = () => {
   const options = ["A", "B", "C", "D", "E", "F", "G", "H", "I"]
   new Promise(() => setTimeout(3000))
   return options.map((it) => {
    label: it,
    value: it
   })
  }, [])
  
  return <Select placeholder="Select options" options={heavyDataProps} />
 }
 
 return <>
   <button onClick={() => setState((prev) => prev++)}>increment</button>
   <h1>{state}</h1>
   <StaticKomp />
  </>
}

dengan ini, maka useMemo akan mengingat StaticKompt, yang mana jika sudah di render saat pertama kali load. Dengan ini, ketika state update pada MainKompt, load akan lebih cepat, karena StaticKompt tidak perlu di render ulang.

Ini contoh sebelum dan sesudahnya.

3. Gunakan component <Suspense/>

Hanya berlaku pada penggunaan framework yang support SSR(Server Side Rendering)

Kadang dalam menghandle fetching data, kita perlu menampilkan loading state agar user dapat mengetahui kalau aplikasi sedang melakukan fetching data.

Sering kita menggunakan conditional operator && untuk mengatasi ini, tapi itu bukanlah hal efektif karena beberapa hal yang diperhatikan:

• Kita perlu menulis berkali-kali kondisi ini untuk menampilkan loading state. Sedangan dengan suspense, kita bisa membuat custom component untuk loading dan menggunakannya dimana saja.
• Dengan suspense kita bisa melakukan partial loading pada halaman tersebut, yang bisa melakukan improvisasi pada Performance Metrics
• Kode lebih enak di baca dengan adanya suspense

Berikut contoh yang bisa diambil di praktekkan dengan React biasa:

import { use } from "react";

const fetchUser = async () => {
  // artificial 2 second delay
  await new Promise((resolve) => setTimeout(resolve, 2000));

  const response = await fetch("https://meowfacts.herokuapp.com/");
  if (!response.ok) {
    throw new Error("Failed to fetch user");
  }

  const { data } = await response.json();
  return data;
};

const promise = fetchUser();

const MeowPage = () => {
  const data = use(promise);
  return <h1>{data[0]}</h1>;
};

export default MeowPage;

import { Suspense } from "react";
import MeowPage from "./meow";

const MeowClient = () => {
  return (
    <Suspense fallback={<p>💭 Lagi loading….</p>}>
      <MeowPage />
    </Suspense>
  );
};

export default MeowClient;

Berikut contoh sebelum dan sesudah

Memang sekilas agak terlihat rumit, tapi jika usecase dalam sebuah project kita menggunakan framework sepertireact-query dan nextjs. mereka secara langsung mensupport keberadaan suspense ini, yang mana di react-query, cukup dengan menggunakan useSuspenseQuery dan ReactQueryStreamedHydration dari react query

query/examples/react/nextjs-suspense-streaming at main · TanStack/query

import { useSuspenseQuery } from "@tanstack/react-query";

const fetchUser = async () => {
  // artificial 2 second delay
  await new Promise((resolve) => setTimeout(resolve, 2000));

  const response = await fetch("https://meowfacts.herokuapp.com/");
  if (!response.ok) {
    throw new Error("Failed to fetch user");
  }

  const { data } = await response.json();
  return data;
};

const MeowComponent = () => {
  const { data } = useSuspenseQuery({
    queryKey: ["meong"],
    queryFn: fetchUser,
  });
  return <h1>{data[0]}</h1>;
};

export default MeowComponent;

import { Suspense } from "react";
import MeowPage from "./meow";
import {
  QueryClient,
  QueryClientProvider,
} from '@tanstack/react-query'
import { ReactQueryStreamedHydration } from '@tanstack/react-query-next-experimental'

const MeowClient = () => {
 const queryClient = new QueryClient()

  return (
   <QueryClientProvider client={queryClient}>
      <ReactQueryStreamedHydration>
      <Suspense fallback={<p>💭 Lagi loading….</p>}>
        <MeowPage />
      </Suspense>
     </ReactQueryStreamedHydration>
   </QueryClientProvider>
  );
};

export default MeowClient;

Sedangkan pada nextjs, bisa kita manfaatkan fitur app router, yang mana cukup dengan membuat file bernama loading.tsx di direktori, maka secara langsung saat menggunakan component Suspense, akan menggunakan file tersebut sebagai fallback.

4. React Compiler

Minimum Support React 17

Diperkenalkan pada 2021 di React Conf, saat itu masih dinamai React Forget. Tujuan dibuat ini, untuk melupaakan optimisasi react. Maksudnya kita cukup menjalankan react compiler maka useMemo dan optimisasi lainnya akan dilakukan secara otomatis dengan mudah.

Berikut contoh optimisasi-nya

Untuk dokumentasi, bisa kita lihat di halaman react berikut

React Compiler - React

Tau gini, langsung kasih tau dong dari awal!

Ya memang sih, tapi dengan mengetahui semua itu. Kita bisa memahami bagaimana cara menulis kode di react dengan baik dan benar. Ingat semua dimulai dari kebiasaan kecil 🫡

Berikut untuk source code aplikasi yang mempraktekkan perbedaan sebelum dan sesudah

GitHub - lleans/render-optimize

Kesimpulan

Sampailah kita ke kesimpulan. Disini kita bisa belajar kalau optimiasai react itu dimulai dengan dari kedisiplinan kita sendiri, abagimana kita cara menulisa kode, bagaimana kita menhandle variable dan komponen, dan masih banyak lagi. Selain dari cara penulisan kode, ada juga dari kebiasaan kita dalam menggunakan library.

Sedikit tips kecil, jika memang hal itu simpel atau mudah untuk di lakukan, cukup lakukan saja. Jangan malas menggunakan libary atau apa, selama itu masih bisa di selesaikan seacara dasar, maka lakukanlah. Oke segitu aja tips dari aku, happy coding ✨.

Referensi

• Why React Re-Renders * Josh W. Comeau
• React re-renders guide: everything, all at once
• React Re-render optimisation
• When to use useRef() instead of useState()
• File-system conventions: loading.js | Next.js

Optimisasi Re-Render Pada Project React was originally published in DOT Intern on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bikin chatbot berarti kamu harus berurusan dengan LLM, berurusan dengan LLM identik dengan berurusan dengan Python (setidaknya itu sih yang aku tau). Framework yang paling famous buat urusan LLM sudah pasti LangChain, dan LangChain adalah Python based framework.

🗣️“T-tapi bang, aku alergi Python”

Agak aneh sih mau ‘mainan’ LLM tapi alergi Python, tapi gapapa, LangChain juga ada kok buat JavaScript. N8N juga bisa jadi alternatif yang bagus kalau kalian gamau ngoding.

🗣️“N8N??? Alergi bang, aku maunya ngoding”

️️️🗣️“JavaScript??? T-t-tapi bangg, aku sukanya TypeScript, trus LangChain masih bau Python, gasuka gelay~”

ribet bener…yaudah sini aku kenalin sama Mastra AI.

Mastra AI adalah TypeScript based framework (yes, bahasa favorit kalian) yang bisa kalian manfaatkan untuk membuat Chat Agent berbasis AI atau mungkin aplikasi berbasis AI. Bedanya sama LangChain, Mastra AI lebih bersahabat dengan developer karena banyak fitur yang membantu banget selama proses development. Di Mastra, kamu bisa memanfaatkan fitur seperti Agents, Workflow, RAG, Memory, Tools, dan masih banyak lagi.

🗣️“Lah, gituan juga ada bang di LangChain.”

Yes and no, sini aku jelasin fitur-fitur penting yang bisa kamu pake buat bikin chatbot sekalian aku kasih tutorial simple untuk bikin chatbot pakai Mastra.

Sebelum masuk ke penjelasan, make sure bikin direktori untuk projectnya dan jalanin command ini untuk bikin project Mastra-nya

bun create mastra

Setelah itu tinggal ketik aja nama projectnya apa, ketik dimana folder srcnya, pilih default AI provider, masukkin API key (bisa diskip) dan udah. Kalau mau simple, setelah ketik nama project bisa langsung enter-enter aja. Terakhir jangan lupa setup .env dan jalanin command ini untuk install semua dependency-nya.

bun i

Udah? yok aku jelasin perbedaannya!

Apa Bedanya Bang?

Walaupun kalau dibaca-baca terlihat dan terdengar sama, tapi sebenernya ada perbedaan yang cukup mencolok loh.

Agents

Mirip LangChain, Mastra AI juga punya fitur Agent yang memungkinkan kalian untuk membuat sebuah AI Agent yang bisa bertindak sesuai dengan prompt yang kalian kasih dan bisa menggunakan tools yang dia punya.

🗣️“Lah kalo mirip apa bedanya bang?”

Nah, bedanya adalah di LangChain kalian harus ‘ngerakit’ agentnya (modular), mulai dari OutputParser, PromptTemplate, Tools secara manual. Kalau di Mastra, tinggal pake aja, bener-bener tinggal pake karena udah terintegrasi!

Biar ga bingung, aku kasih contoh aja ya!

LangChain:

import os
from langchain_openai import ChatOpenAI
from langchain_community.tools import DuckDuckGoSearchRun
from langchain.agents import AgentExecutor, create_openai_tools_agent
from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder
from langchain_core.tools import tool

@tool
def hitung_panjang_kata(kata: str) -> int:
    """Fungsi ini akan mengembalikan jumlah huruf dalam satu kata."""
    return len(kata)

search_tool = DuckDuckGoSearchRun()

tools = [hitung_panjang_kata, search_tool]

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

prompt_template = ChatPromptTemplate.from_messages([
    ("system", "You are a helpful weather assistant that provides accurate weather information and can help planning activities based on the weather.

      Your primary function is to help users get weather details for specific locations. When responding:
      - Always ask for a location if none is provided
      - If the location name isn't in English, please translate it
      - If giving a location with multiple parts (e.g. "New York, NY"), use the most relevant part (e.g. "New York")
      - Include relevant details like humidity, wind conditions, and precipitation
      - Keep responses concise but informative
      - If the user asks for activities and provides the weather forecast, suggest activities based on the weather forecast.
      - If the user asks for activities, respond in the format they request.

      Use the weatherTool to fetch current weather data."),
    ("human", "{input}"),
    MessagesPlaceholder(variable_name="agent_scratchpad")
])

agent = create_openai_tools_agent(llm, tools, prompt_template)

agent_executor = AgentExecutor(
    agent=agent,
    tools=tools,
    verbose=True # verbose=True akan mencetak proses "berpikir" agent
)

if __name__ == "__main__":
    print("Agent siap! Silakan ajukan pertanyaan...")
    
    pertanyaan = "Siapa presiden Indonesia saat ini, dan berapa panjang nama lengkapnya?"
    
    # Kita "memanggil" (invoke) executor dengan input kita
    hasil = agent_executor.invoke({
        "input": pertanyaan
    })
    
    print("\n--- HASIL AKHIR ---")
    print(hasil["output"])

Mastra:

import { Agent } from '@mastra/core/agent';
import { Memory } from '@mastra/memory';
import { LibSQLStore } from '@mastra/libsql';
import { weatherTool } from '../tools/weather-tool';
import { scorers } from '../scorers/weather-scorer';

export const weatherAgent = new Agent({
  name: 'Weather Agent',
  instructions: `
      You are a helpful weather assistant that provides accurate weather information and can help planning activities based on the weather.

      Your primary function is to help users get weather details for specific locations. When responding:
      - Always ask for a location if none is provided
      - If the location name isn't in English, please translate it
      - If giving a location with multiple parts (e.g. "New York, NY"), use the most relevant part (e.g. "New York")
      - Include relevant details like humidity, wind conditions, and precipitation
      - Keep responses concise but informative
      - If the user asks for activities and provides the weather forecast, suggest activities based on the weather forecast.
      - If the user asks for activities, respond in the format they request.

      Use the weatherTool to fetch current weather data.
`,
  model: 'google/gemini-2.5-pro',
  tools: { weatherTool },
  scorers: {
    toolCallAppropriateness: {
      scorer: scorers.toolCallAppropriatenessScorer,
      sampling: {
        type: 'ratio',
        rate: 1,
      },
    },
    completeness: {
      scorer: scorers.completenessScorer,
      sampling: {
        type: 'ratio',
        rate: 1,
      },
    },
    translation: {
      scorer: scorers.translationScorer,
      sampling: {
        type: 'ratio',
        rate: 1,
      },
    },
  },
  memory: new Memory({
    storage: new LibSQLStore({
      url: 'file:../mastra.db', // path is relative to the .mastra/output directory
    }),
  }),
});

Bedanya emang tipis sih kalau dilihat dari kodenya aja, tapi sebetulnya kelebihan yang dimiliki Mastra bukan cuma dari kodenya yang lebih simple, rapi, dan mudah dipahami. Letak kelebihannya justru berada di tool debugging dan visualisasi.

️️️🗣️“Kalo cuma itu mah LangChain juga ada kali”

Ya ga salah sih, tapi tapi tapiii, di Mastra ini tool debugging dan visualisasinya udah built-in loh! Kalian gaperlu lagi install tool tambahan seperti LangSmith, gaperlu daftar dulu, daftarin API keynya dulu, not so demure 💅🏼. Tinggal run command ini

bun dev

Habis itu udah deh, akses playground Mastra nya dan udah deh kalian bisa debugging dengan mudah tanpa harus install ini itu.

🗣️“Wihh simple juga ternyata”

Sesimple itu. Oh iya, kalian bisa atur kepribadian, behaviour, dan seberapa halu (temprature) AI Agent kalian di sini ya. Misal nih aku mau agentku lebih ramah, kalau ada user yang chat dia jawabnya pakai “kak”, tinggal ubah aja di bagian instruction. Ganti pake model lain? bisa banget, tinggal ganti aja dan jangan lupa untuk atur API key sesuai dengan model yang dipake. Tools yang dipake sama AI juga bisa diatur, mau ditambah, dikurangin, atau diatur urutan penggunaan toolsnya juga bisa.

Workflow

Sesuai sama artinya, workflow memungkinkan kalian untuk bisa memberi arahan atau langkah-langkah yang harus dilakukan sama si AI Agent kalian.

🗣️“Workflow nih mirip sama chains kah? atau mirip sama workflow N8N bang?”

Hampir mirip sama Chainsnya LangFuse dan mirip banget sama workflow N8N. Bedanya apa? dikutip dari Google Gemini 2.5 Pro Student Plan (hehe) Chainsnya si LangFuse ini lebih ke pipelining data dan butuh karakter “|” untuk bisa kalian debug pakai LangFuse, sedangkan Mastra lebih seperti mendefinisikan langkah-langkahnya seperti apa, mirip kayak ngajarin anak kecil step-by-step mengendarai sepeda.

🗣️“Mirip N8N? bisa human-in-the-loop juga dong bang?”

Ding ding ding…💯buat kamu. Bener banget di Mastra kita bisa kasih human-in-the-loop juga di workflownya.

const fetchWeather = createStep({
  id: 'fetch-weather',
  description: 'Fetches weather forecast for a given city',
  inputSchema: z.object({
    city: z.string().describe('The city to get the weather for'),
  }),
  stateSchema: z.object({
    geocodingResults: z
      .array(
        z.object({
          latitude: z.number(),
          longitude: z.number(),
          name: z.string(),
          country: z.string().optional(),
          country_code: z.string().optional(),
          admin1: z.string().optional(),
        }),
      )
      .optional(),
  }),
  suspendSchema: z.object({
    prompt: z.string(),
    options: z.array(
      z.object({
        index: z.number().int().min(0),
        label: z.string(),
      }),
    ),
  }),
  resumeSchema: z.object({
    selectedIndex: z.number().int().min(0),
  }),
  outputSchema: forecastSchema,
  execute: async ({ inputData, state, setState, suspend, resumeData }) => {
    if (!inputData) {
      throw new Error('Input data not found');
    }

    // Fetch and store geocoding results in state if not present
    let geocodingResults = state.geocodingResults;
    if (!geocodingResults) {
      const geocodingUrl = `https://geocoding-api.open-meteo.com/v1/search?name=${encodeURIComponent(inputData.city)}&count=10`;
      const geocodingResponse = await fetch(geocodingUrl);
      const geocodingData = (await geocodingResponse.json()) as {
        results: {
          latitude: number;
          longitude: number;
          name: string;
          country?: string;
          country_code?: string;
          admin1?: string;
        }[];
      };

      if (!geocodingData.results?.[0]) {
        throw new Error(`Location '${inputData.city}' not found`);
      }

      geocodingResults = geocodingData.results;
      setState({ ...state, geocodingResults });
    }

    // If multiple options and no selection yet, suspend for human choice
    if (geocodingResults.length > 1 && (resumeData?.selectedIndex === undefined || resumeData.selectedIndex === null)) {
      const options = geocodingResults.map((r, idx) => {
        const placeParts = [r.name, r.admin1].filter(Boolean).join(', ');
        const countryPart = r.country ? `${r.country}${r.country_code ? ` (${r.country_code})` : ''}` : 'Unknown country';
        return { index: idx, label: `${placeParts ? `${placeParts}, ` : ''}${countryPart}` };
      });

      return suspend({
        prompt: `Multiple matches found for '${inputData.city}'. Please select the correct location:`,
        options,
      });
    }

    const selectedIndex = Math.max(0, Number(resumeData?.selectedIndex ?? 0));
    const selected = geocodingResults[selectedIndex] ?? geocodingResults[0];
    const { latitude, longitude, name, country } = selected;

    const weatherUrl = `https://api.open-meteo.com/v1/forecast?latitude=${latitude}&longitude=${longitude}&current=precipitation,weathercode&timezone=auto,&hourly=precipitation_probability,temperature_2m`;
    const response = await fetch(weatherUrl);
    const data = (await response.json()) as {
      current: {
        time: string;
        precipitation: number;
        weathercode: number;
      };
      hourly: {
        precipitation_probability: number[];
        temperature_2m: number[];
      };
    };

    const forecast = {
      date: new Date().toISOString(),
      maxTemp: Math.max(...data.hourly.temperature_2m),
      minTemp: Math.min(...data.hourly.temperature_2m),
      condition: getWeatherCondition(data.current.weathercode),
      precipitationChance: data.hourly.precipitation_probability.reduce(
        (acc, curr) => Math.max(acc, curr),
        0,
      ),
      location: country ? `${name}, ${country}` : name,
    };

    return forecast;
  },
});

Kode di atas adalah salah satu contoh workflow yang mengimplementasikan human-in-the-loop, dalam step di atas aku udah kasih “suspend” untuk ngepause jalannya workflow dan akan dilanjut menggunakan “resume” setelah user menjawab pertanyaan data cuaca di lokasi mana yang user inginkan.

🗣️“Debuggingnya gimana bang? katanya ada visualisasinya?”

Nihh aku kasih screenshotnya

Jangan diliat errornya plis, itu gara-gara API key geminiku udah habis free quotanya (kalau ada yang berbaik hati berbagi API key gemini gratis boleh dong hehe).

Dan masih banyak lagi sih, kalian bisa eksplor sendiri yes!

Tools

Tools ibarat tangan dan kakinya si AI Agent. Tanpa tools, AI cuma bisa halu karena dia gapunya alat apapun yang membantu dia untuk mencari informasi terkait.

Konsepnya sama juga seperti LangChain, tapi lagi lagi perbedaannya ada di developer experience dan type validation.

🗣️“Semua-semua sama bang, gimana sih”

Ya sabar, di LangChain tools yaudah tools aja seperti biasa, tapi di Mastra kalian bisa mendefinisikan tool pakai function defineTool. Satu lagi, Mastra udah terintegrasi sama Zod Schema. Jadi, pas si LLM “berpikir” mau manggil tool kalian (misal getWeather(location: "Jakarte")), Zod di Mastra bakal auto-validate inputnya. Kalau si LLM-nya lagi ngaco (misal getWeather(location: 123)), Mastra bakal nangkep itu sebelum fungsi kalian error ga jelas.

Contohnya ada di bawah ini!

import { defineTool } from 'mastra';
import { z } from 'zod';

export const weatherTool = defineTool({
  schema: z.object({ 
    city: z.string().describe("Nama kota yang mau dicek cuacanya") 
  }),
  description: "Mendapatkan info cuaca saat ini di kota tertentu.",
  
  async handler({ city }) {
    const response = await fetch(`https://api.cuaca.com/v1?q=${city}`);
    const data = await response.json();
    
    return data.currentWeather;
  }
});

See? Dengan adanya Zod, kalian “maksa” si AI buat ngasih input yang bener sesuai skema. Gaperlu lagi tuh handling error if (typeof city !== 'string') atau if (!city) di dalem fungsi kalian. Si Mastra udah ngurusin di depan.

Retrieval-Augmented Generation (RAG)

Ini dia fitur yang bikin AI kalian pinter beneran, bukan cuma pinter halu. RAG ini intinya adalah teknik biar si AI bisa ngebaca dokumen kalian sendiri (PDF, TXT, file Notion, database) sebelum ngejawab. Jadi, jawabannya bisa sesuai fakta dari data kalian, bukan ngarang bebas dari data latihannya si LLM.

🗣️“Halah, ini mah RAG. Di LangChain juga udah jadi makanan sehari-hari bang.”

Yes betul sekali. Konsepnya emang itu-itu juga. Mau di LangChain, mau di Mastra, yang namanya RAG ya pasti prosesnya: Load -> Split -> Embed -> Store -> Retrieve.

🗣️“NAH KAN SAMA AJA! Terus bedanya apaan dong?!”

Bedanya lagi-lagi di kemudahan dan Unified API.

Di LangChain, kalian dikasih kotak Lego yang sebanyak itu. Ada loader buat PDF, loader buat CSV, loader buat YouTube, masing-masing kadang cara pakenya beda dikit. Terus ada 50 jenis vector store (Chroma, Pinecone, FAISS, dll) yang API-nya juga beda-beda. Fleksibel sih, tapi jujur… bikin pusing di awal.

Di Mastra, dia lebih fokus ke alur kerjanya. Mastra nyediain API yang lebih terpadu. Misalnya, dia punya UnifiedVectorStore API. Jadi, kalian belajar satu cara aja buat upsert atau query data, nanti di belakang layar mau ganti dari Chroma ke Pinecone gampang, kodenya ga banyak berubah.

Intinya, Mastra ga bikin kalian tenggelam dalam lautan pilihan. Dia ngasih jalur yang lebih jelas buat nge-RAG, dan integrasinya ke Agent atau Workflow-nya juga lebih seamless alias mulus.

Memory

Ini fitur wajib kalau kalian bikin chatbot. Masa tiap kali ngirim pesan baru, si AI-nya lupa kita lagi ngomongin apa. Pikun dong! Memory ini yang bertugas nyimpen riwayat obrolan biar konteksnya nyambung terus.

🗣️“Eh bang, di contoh kode weatherAgent Mastra di atas, aku liat ada ginian:”

memory: new Memory({
    storage: new LibSQLStore({
      url: 'file:../mastra.db', // path is relative to the .mastra/output directory
    }),
  }),

🗣️“Itu kan?! LangChain juga punya ConversationBufferMemory, ConversationSummaryMemory, dll. Trus apa bedanya bang?”

Emang mirip sih, tapi memory LangChain sama memory Mastra itu beda. Di LangChain, memory itu objek terpisah yang harus kalian manage dan suntikkin secara manual ke dalam AgentExecutor kalian. Kalian juga harus pastiin prompt kalian punya placeholder yang bener.

Di Mastra, memory itu bagian native dari definisi Agent. Liat aja kode di atas. Kalian tinggal deklarasiin memory: new Memory(...) pas bikin agent. Selesai. Ga perlu pusing inject sana-sini. Si agent Mastra otomatis tau cara pake memory-nya. Lebih rapi, lebih integrated.

Gak cuma itu, memory Mastra juga canggih. Dia ga cuma nyimpen obrolan terakhir (kayak BufferMemory). Dia punya konsep built-in kayak:

• Working Memory: Ingatan jangka pendek buat tugas yang lagi dikerjain si agent.
• Semantic Recall: Ini gokil sih. Ini ingatan jangka panjang. Si agent bisa nyimpen fakta penting dari obrolan kalian ke vector store. Jadi, kalau sebulan lagi kalian chat, dia bisa inget fakta itu (misal: “Oh iya, si Reza kan sukanya kopi Gayo, bukan Robusta”).

Jadi, bedanya:

• LangChain: Memory itu tambahan yang harus kalian pasang dan manage sendiri.
• Mastra: Memory itu fitur bawaan yang udah terintegrasi erat sama si agent.

Kesimpulan

Selesai sudah pembahasan terkait apa sih bedanya LangChain sama Mastra.

🗣️“Itu aja bang?”

Ya sementara itu dulu sih, sebenernya masih banyak lagi fitur-fitur di Mastra yang bisa dihighlight seperti voice interaction yang memungkinkan kalian untuk bikin chatbot yang bisa diajak ngobrol pake suara beneran, bukan cuma ketik ketik aja.

🗣️“Kalo dipikir-pikir emang lebih enak di Mastra sih, debuggingnya lebih simple dan gaperlu daftar ini itu”

Yes, kelebihan dari Mastra yang udah aku sebutin dari awal sampai akhir ini adalah Developer Experience-nya. Mastra memanjakan developer dengan playground dan debugging feature yang built-in biar developer bisa fokus sama Mastra aja, gaperlu lagi install tools tambahan hanya untuk debugging dan visualisasi. Satu lagi, ini pake TypeScript, jadi lebih kenceng, lebih type-strict juga kalau dibanding pakai Python (setidaknya itu sih yang dibanggakan sama yang suka TypeScript).

🗣️”Jadi bingung bang, enaknya pake LangChain atau Mastra ya?”

Kalau kalian butuh environment debugging yang built-in, gamau ribet install ini itu cuma buat debugging ya pake Mastra aja, tapi kalau cari dukungan library yang lengkap banget, dan butuh fleksibilitas saat develop pake aja LangChain.

Btw bukannya tadi bilang cuma mau ngoding TypeScript ya? gitu masih bingung mau pake apa.

Udah ada niat buat bikin chatbot sendiri? Gas, pake Mastra aja!

Bikin Chatbot Pakai Mastra.AI Atau LangChain? was originally published in DOT Intern on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reframing Innovations Programs Through the Lens of User Experience

When employees are less motivated to participate in innovation programs, it may not be about the idea , but about the experience.

Perusahaan sangat menyukai inovasi. Mungkin karena inovasi memiliki beberapa manfaat untuk perusahaan dan bisa dijadikan solusi untuk meningkatkan keterlibatan dari manusia-manusia yang ada di dalamnya. Tetapi ketika perusahaan memberikan wadah kepada para karyawan untuk berinovasi, angka partisipan mengatakan yang sebaliknya seperti sedikit yang mendaftar, sedikit diskusi, dan kurangnya excitement dalam merespon program inovasi.

Apa yang salah?

Ada beberapa karyawan yang tidak bergabung karena mereka tidak punya waktu atau tidak punya ide. Tetapi bagaimana jika masalahnya adalah bagaimana pengalaman karyawan ketika berinovasi itu dirancang?

Innovation as a User Journey

Let’s take a look from User Experience (UX)’s lens.

Di dalam UX, desain dirancang untuk user bukan dari sistem. Timbul pertanyaan utama ini,

“ Apa yang memotivasi mereka?”

“Dimana mereka mengalami suatu hambatan?”

“Emosi apa yang mereka rasakan selama proses?”

Pertanyaan-pertanyaan itu akan menjadi dasar ketika prinsip-prinsip UX akan diterapkan ke program inovasi. User di sini adalah karyawan dan journey adalah ketika mereka mendengar bahwa ada program inovasi, dilanjutkan ketika mereka melakukan brainstorm, berkolaborasi, mengumpulkan proposal, dan melihat ide-ide mereka diimplementasikan secara nyata.

Apabila suatu saat mereka merasa bahwa proses ini membuat mereka merasa frustasi, mengintimidasi, atau tidak relevan buat mereka, maka mereka akan mengundurkan diri.

Case Study: When The Engagement Drops

Di DOT Indonesia, terdapat sebuah program inovasi bernama Innovation Award. Di tahun 2025, program inovasi tersebut mengalami penurunan partisipan. Dari yang awalnya ada 21 peserta di tahun 2024 menjadi 10 peserta di tahun ini.

Survei karyawan menunjukkan:

“Tidak ada waktu.”

“Tidak tahu harus berinovasi tentang apa. Tidak ada ide.”

“Ada kendala di proses pengerjaannya. Setiap ide harus terselesaikan.”

“Kurangnya support.”

Ketika memetakan pengalaman karyawan dari perspektif UX menunjukkan bahwa:

• Time Friction — misaligned context of use

“Tidak ada waktu.”

Program belum disesuaikan dengan ritme kerja karyawan sehingga untuk berpartisipasi terasa seperti beban tambahan bukan bagian dari alur kerja alami.

• Ideation Friction — lack of scaffolding for creativity

“Tidak ada ide.”

Karyawan ingin berkontribusi tapi belum tau proses menemukan ide yang relevan dengan tema. Hal itu mungkin disebabkan karena tidak ada ruang eksplorasi bersama dan tidak ada alat bantu seperti ideation canvas atau media lain yang bisa memicu pemikiran.

• Process Friction — rigid system and high completion demand

“Ada kendala di proses pengerjaannya, jadi setiap ide harus terselesaikan.”

Desain proses terlalu kaku dan berorientasi pada output-driven bukan eksplorasi ide sehingga akan menciptakan tekanan kognitif dan menghambat rasa aman untuk bereksperimen.

• Emotional Friction — lack of psychologycal safety & support

“Kurangnya support.”

Karyawan merasa tidak ada dukungan atau apresiasi yang cukup dari manajemen maupun perusahaan. Rasa takut gagal akhirnya menurunkan motivasi untuk berpartisipasi.

Designing Innovation Like a Product

Melakukan pendekatan terhadap program inovasi akan membuat perusahaan terjadi peningkatan melalui feedback dan testing.

• Emphathize

Melakukan survei singkat untuk memahami bagaimana karyawan mengalami program inovasi dalam konteks kerja sehari-hari. Berfokus pada momen-momen dimana ada munculnya keterbatasan waktu, kebingungan, atau kurang percaya diri.

• Define

Memetakan titik-titik friksi utama sepanjang perjalanan partisipasi dalam program inovasi.

• Ideate

Menciptakan solusi bersama antara karyawan dan pengelola program seperti:

1. Menyederhanakan alur pengajuan ide atau memungkinkan bentuk partisipasi kecil.
2. Menyediakan alat bantu terstruktur untuk berpikir kreatif.
3. Membangun feedback loop dan sistem mentoring untuk meningkatkan rasa aman.
4. Menanamkan elemen apresiasi di setiap tahap, bukan hanya akhir program.

• Prototype

Uji coba inisiatif skala kecil yang menargetkan friksi tertentu, contohnya tantangan inovasi di tingkat divisi dengan durasi lebih singkat sehingga melibatkan leader dan manager.

• Test & Iterate

Mengumpulkan umpan balik dan ukur metrik pengalaman seperti:

• Kemudahan partisipasi

“Seberapa mudah prosesnya dijalani?”

• Persepsi Dukungan

“Apakah peserta merasa didampingi dan diarahkan?”

• Keterlibatan Emosional

“Apakah program terasa memotivasi atau justru menekan?”

Key Point Takeaways

UX Prinsiple → Aplikasi

• User Research → Memahami motivasi dan kendala karyawan.
• Journey Mapping → Mengidentifikasi hambatan di berbagai titik karyawan.
• Prototyping → Menguji format baru sebelum melakukan Innovation Awards.
• Emotional Design → Membangun keamanan psikologis dan mengapresiasi segala bentuk progres.
• Feedback Loops → Menjaga transparasi melalui komunikasi.

Reframing innovation programs through the lens of User Experience offers a practical yet human-centered approach to revitalizing participation.

Ketika karyawan merasa bahwa perjalanan mereka didukung dan bermakna, mereka cenderung terlibat kreatif. Intinya, inovasi akan berkembang dan engagement akan meningkat tidak hanya melalui proses tetapi melalui pengalaman yang dirancang dengan empati, kejelasan, dan tujuan.

Design for people first — innovation will follow.

Referensi:

Hassenzahl, M., & Tractinsky, N. (2006). User Experience — a research agenda. DOI: 10.1080/01449290500330331

Sutcliffe, A. (2016). Designing for User Experience and Engagement. https://doi.org/10.1007/978-3-319-27446-1_5

Interaction Design. Innovation in UX/UI Design. https://www.interaction-design.org/literature/topics/innovation?srsltid=AfmBOoprlYdclNCYYs5M4HlI4nLHhqsw5TCumtp4MYT9AsObCYSUAqzm#1._examine_the_most_avenues_in_their_design_process-3

Why Innovation Programs Fail — And What UX has to Do with It was originally published in DOT Intern on Medium, where people are continuing the conversation by highlighting and responding to this story.

Masuk ke dunia magang dan profesional di salah satu agency membuat aku banyak belajar juga, dimana penggunaan AI memang sudah dilakukan di banyak bidang dan penggunaannya untuk mendukung produktivitas kerja. Sebagai video editor, aku juga punya banyak akses untuk bisa belajar dan mengetahui banyak tipe dan jenis AI yang sudah ada dan membuat aku sadar ternyata perkembangan AI luar biasa cepat. Aku akan share beberapa tools AI yang selama magang di posisi video editor sering ngebantu pengerjaan task aku.

1. Hygen.com

Hygen ini jadi tools AI pertama yang aku gunain saat baru banget masuk menjadi video editor. Saat itu aku sudah tau kalo AI itu bisa mengubah gambar menjadi video, tapi saat tau cara pengaplikasian lebih detailnya justru aku jadi amazed karena ternyata AI itu sudah berkembang sangat pesat. Pada dasarnya Hygen ini salah satu website AI yang bisa digunain untuk membuat video yang bahkan suaranya bisa kita ganti-ganti sesuai dengan logat atau nada yang kita butuhkan. Bahkan, hasilnya bener-bener realistis karena kelihatan seperti manusia asli. Enggak sampe situ aja, Hygen ini juga bisa membuat avatar yang kita mau sampe customize ekspresi wajah yang mau ditampilin saat berbentuk video nanti, style baju sampe movement objeknya nanti. Nah, Hygen ini aku gunakan kalo butuh footage atau objek yang berbicara gitu tapi gausah untuk take-take lagi karena hanya perlu ganti prompt script yang diinginkan.

2. Lovable.dev

Kebayang ga bisa punya web sendiri sesuai yang kita mau hanya dalam hitungan menit? Lovable bisa banget buat bikinin web yang sesuai keinginan kita. Bukan cuman website, Lovable bisa banget buat bikinin kamu aplikasi juga loh cuman modal chatting dengan AI dan describe style website atau aplikasi yang kita butuhin dan langsung jadi. Menurut aku, sejauh aku belajar saat magang, ini jadi salah satu AI paling keren karena beneran bisa website cuman dari satu kali klik aja.

3. Lovart.ai

Kalo ini cocok banget buat cari inspirasi dan style untuk mendesain sesuatu. Simply kayak kita punya designer pribadi, Lovart.ai bisa kasih masukan design ke konsep yang kita kasih ke AI ini. Di Lovart.ai ini kita bisa buat storyboard dan brainstorming sama AI nya untuk nentuin style yang cocok sampe kasih saran untuk estetikanya. Tapi Lovart.ai ga cuman buat design 2D, AI ini juga bisa banget untuk buat design berupa video, 3D dan bentuk-bentuk lainnya. Jadi, kalo butuh temen diskusi untuk konsep dan ide design bisa banget buat pake Lovart.ai buat optimalisasi kerjaan kalian.

4. Higgsfield

Ini mungkin jadi tools AI yang paling align sama posisi video editor ya karena secara sederhana ini AI yang bisa bikin visual effect ke video atau foto yang kita import ke website Higgsfield. Kelebihan dari Higgsfield ini karena pilihan efeknya beragam banget dan kece juga bikin tampilan video kita lebih engaging dan jadi salah satu daya tarik juga. Karena pilihannya banyak banget jadi bisa disesuaikan sama kebutuhan untuk marketing, edukasi, atau entertaining video.

Nah, jadi itu top 4 tools AI yang pernah aku pake selama kegiatan magang aku di video editor. Tentunya masih banyak sekali tools AI yang sudah berkembang lebih jauh diluar sana, tapi 4 list diatas merupakan sedikit tools yang aku bisa sebutkan. Terlepas dari perdebatan penggunaan AI diluar sana, aku yakin perkembangan teknologi menjadi salah satu hal yang tidak bisa kita cegah, termasuk AI. Dengan kita menutup mata dengan perkembangan teknologi, semakin kita akan merasa tertinggal dan akan kehilangan banyak kesempatan juga. Di sisi lain, AI juga bisa loh untuk mengoptimalkan kinerja kita selama digunakan dengan bijak dan sesuai takaran tanpa menghilangkan esensi karya yang mau kita buat. Perkembangan teknologi yang masif juga mewajibkan kita untuk harus pintar tanpa ketinggalan zaman karena perkembangan AI ini banyak hal yang bisa terkesan “digantikan” dengan keberadaannya. Namun, kita juga harus lebih cermat menggunakan dan pandai untuk memaksimalkan perkembangan AI sehingga kemampuan kita tetap bisa eksis dan bisa bersaing juga dengan AI tanpa menolak keberadaan AI melainkan mengoptimalkan perkembangannya.

ANTARA INOVASI DAN INTERUPSI: BAGAIMANA MENYIKAPI PERKEMBANGAN AI? was originally published in DOT Intern on Medium, where people are continuing the conversation by highlighting and responding to this story.

Banyak orang menganggap magang cukup sekali — sekadar formalitas buat nambah pengalaman sebelum lulus. Tapi buat aku, pengalaman magang di DOT justru bikin pengen balik lagi. Lucunya, setelah magang pertama aku di DOT, aku sempat kerja sebagai profesional full-time di luar sana. Waktu itu aku ngerasa udah cukup paham soal ritme kerja, tanggung jawab, dan dunia profesional yang sebenarnya. Aku pikir, fase magang udah selesai di hidupku. Tapi ternyata, waktu kesempatan buat balik ke DOT datang lagi, aku langsung ambil tanpa mikir panjang. Rasanya kayak pulang ke rumah kedua — tempat yang udah akrab, tapi selalu punya hal baru buat dieksplor.

Balik magang setelah sempat kerja profesional tuh rasanya unik. Di satu sisi, aku udah punya pengalaman kerja yang lebih matang. Tapi di sisi lain, aku sadar kalau magang bukan sekadar “posisi sementara,” melainkan ruang buat terus belajar tanpa tekanan berlebihan. DOT justru jadi tempat di mana aku bisa menyeimbangkan dua hal itu — profesionalitas dan rasa ingin tahu.

Sebagai graphic designer, hal yang paling aku syukuri dari DOT adalah kebebasan berkreasi. Di sini aku nggak dibatasi oleh aturan perusahaan yang kaku. Aku bebas nyoba layout baru, gaya ilustrasi yang berbeda, atau eksplorasi warna yang mungkin di tempat lain dianggap “nggak sesuai guideline.” Setiap ide diterima dengan terbuka, bahkan yang awalnya kelihatan nyeleneh pun bisa jadi titik awal sesuatu yang menarik. DOT ngasih ruang buat bereksperimen, dan itu bikin proses kerja terasa jauh lebih hidup.

Yang bikin aku betah tentu juga orang-orangnya. Teman-teman yang supportif, selalu siap bantu, saling backup satu sama lain. Mentornya juga humble dan terbuka — nggak cuma ngarahin, tapi juga ngajak diskusi. Rasanya lebih kayak kolaborasi daripada bimbingan satu arah. Karena itu, setiap tugas terasa ringan. Capek sih pasti ada, tapi capek yang dibarengi rasa fun itu beda — nggak berat. Makanya, selama di DOT, aku ngga pernah ngerasa adanya tekanan selama baik itu ngerjain kerjaan atau diskusi bareng tim.

Satu lagi hal yang aku suka dari DOT itu di mana nggak ada jarak berlebihan antara intern, karyawan, atau mentor. Semua orang punya ruang buat didengar. Buat aku, hal sesederhana itu justru bikin suasana kerja terasa nyaman. Aku jadi lebih berani buat ngomong, ngasih ide, atau bahkan nanya hal-hal kecil tanpa takut salah. Terdengar sederhana, namun lingkungan yang seperti ini nggak mudah ditemukan di banyak tempat.

Dari dua kali magang ini, aku belajar kalau tempat kerja yang baik bukan cuma soal proyek besar atau fasilitas lengkap. Tapi tentang ruang buat tumbuh, dukungan dari orang-orang di sekitarnya, dan rasa nyaman buat jadi diri sendiri. Di DOT, semua itu ada.

Magang di DOT bukan cuma soal belajar desain, tapi juga belajar berproses — gimana menikmati pekerjaan, menghargai ide orang lain, dan tetap kreatif. Aku juga belajar bahwa “belajar” nggak berhenti meskipun udah sempat kerja profesional. Kadang, justru dengan balik ke tempat yang bikin nyaman, kita bisa lihat seberapa banyak diri kita berkembang.

Kenapa Nggak Pernah Bosan Magang di DOT — dari Seseorang yang Sudah Pernah Magang Dua Kali was originally published in DOT Intern on Medium, where people are continuing the conversation by highlighting and responding to this story.

Pernah merasa progres sudah jauh, tetapi merge request (MR) mentok karena konflik, commit berisi “fix kode” yang tidak deskriptif, atau judul MR yang tidak menjelaskan apa pun?

Di masa magang, saya pernah mengalaminya. Pelan-pelan, saya belajar bahwa manajemen branch yang rapi bukan soal gaya, melainkan fondasi kolaborasi: mulai dari sinkronisasi awal, penamaan branch yang jelas, strategi push yang tertata, sampai menulis MR yang nyaman untuk ditinjau. Artikel ini merangkum praktik harian yang saya pakai secara ringkas dan mudah diterapkan.

Persiapan: Sinkronisasi & Penamaan Branch
1. Sinkronisasi sebelum memulai
Salah satu penyebab utama konflik saat Merge Request (MR) adalah memulai pekerjaan dari basis kode yang sudah usang. Tanpa sadar, kita mengerjakan fitur di atas versi proyek yang sudah ketinggalan, sementara rekan tim lain mungkin sudah menambahkan pembaruan penting di branch utama (main atau develop).

Satu langkah preventif yang wajib dilakukan sebelum menulis kode adalah menyelaraskan repository lokal dengan versi terbaru yang ada di server (GitLab).

Caranya adalah dengan berpindah ke branch utama dan menjalankan perintah git pull.

# Pastikan berada di branch utama
git switch main

# Tarik semua perubahan terbaru dari server
git pull origin main

Perintah git pull diatas memastikan kita mengambil semua pembaruan dari server dan menerapkannya di proyek lokal. Dengan memulai dari “garis start” yang sama dengan semua orang, kita dapat mengurangi risiko konflik di kemudian hari.

2. Penamaan Branch yang Informatif
Setelah basis kode sinkron, langkah selanjutnya adalah menciptakan branch(ruang kerja) baru untuk task yang akan dikerjakan. Nama branch yang buruk seperti “fitur-baru” atau “perbaikan” tidak memberikan konteks apa pun kepada tim. Sebaliknya, praktik terbaik adalah mengintegrasikan informasi dari issue board (seperti GitLab Issues) langsung ke dalam nama branch.

Saran format yang baik untuk penamaan branch seperti berikut:
tipe/nomor-isu-deskripsi-singkat
keterangan :

• tipe: Menjelaskan tujuan branch (misalnya: feature, fix, refactor, adjust)
• nomor-isu: Nomor tiket dari task yang sedang dikerjakan
• deskripsi-singkat: Beberapa kata yang merangkum task tersebut

Gambar diatas adalah contoh card issue yang ingin dikerjakan, sehingga pembuatan branch baru dapat dinamakan adjust/1-update-deskripsi-readme

3. Perintah Modern untuk Berpindah Branch
Setelah memiliki nama branch yang ideal, saatnya untuk membuat dan langsung berpindah ke dalamnya. Untuk itu, kita bisa menggunakan perintah git switch dengan flag -c (singkatan dari create).

# Membuat dan langsung berpindah ke branch baru 
git switch -c adjust/1-perbarui-readme

Apa bedanya dengan git checkout -b?

Kita mungkin lebih sering melihat perintah git checkout -b digunakan untuk tujuan yang sama. Keduanya memang menghasilkan output yang identik. Namun, git switch diperkenalkan di versi Git yang lebih baru (2.23) untuk memisahkan fungsi.

Perintah git checkout di versi lama memiliki dua fungsi utama yang sangat berbeda:

• Berpindah branch (contoh: git checkout nama-branch).
• Mengembalikan perubahan pada file (contoh: git checkout — nama-file.txt).

Karena fungsi gandanya bisa menimbulkan ambiguitas, git memperkenalkan dua perintah yang lebih spesifik untuk mengatasi hal tersebut :

• git switch: Didesain khusus hanya untuk berpindah atau membuat branch.
• git restore: Didesain khusus hanya untuk mengembalikan file.

Menggunakan git switch membuat niat lebih eksplisit dan jelas, sekaligus menerapkan praktik modern yang mengurangi ambiguitas dan risiko kesalahan. Setelah menjalankan perintah, kita akan berada di branch yang baru dan aman.

Pengerjaan: Workflow & Perintah Git Saat Pengembangan
1. Pesan Commit yang Jelas dan Informatif

Pesan commit yang buruk seperti “fix bug” atau “update code” mungkin cukup, tetapi ketika ada orang lain yang mencoba memahami riwayat perubahan akan mengalami kesulitan.

Praktik yang baik adalah mengikuti sebuah format sederhana untuk konsistensi. Salah satu yang paling populer dan mudah diadopsi adalah Conventional Commits. Format dasarnya adalah:
tipe: deskripsi singkat
keterangan :

• tipe: Satu kata yang mengkategorikan perubahan yang dilakukan seperti: feat, fix, adjust, dst.
• deskripsi singkat: Kalimat ringkas yang menjelaskan apa yang dilakukan.

Pesan commit yang informatif mengubah git log dari sekadar daftar perubahan acak menjadi cerita yang terstruktur. Dampaknya, proses code review lebih mudah, penelusuran sumber bug di masa depan lebih cepat, dan changelog (catatan perubahan) untuk rilis baru bisa dihasilkan secara otomatis.

2. Simpan Perubahan Sementara(Stash)
Seringkali saat mengembangkan fitur, kita berada di persimpangan jalan. Mungkin kode yang kita tulis sudah berjalan, tetapi kita merasa logikanya kurang efisien dan ingin mencoba pendekatan yang sama sekali berbeda. Masalahnya, kita tidak ingin membuang perubahan yang sudah ada, tetapi juga belum siap untuk menyimpannya sebagai commit.

Selain itu, skenario lain yang umum terjadi adalah ketika datang permintaan darurat (misalnya perbaikan bug) di salah satu fitur, padahal pekerjaan saat ini belum selesai dan tidak bisa di-commit.

Dalam kedua situasi tersebut, git stash berperan sebagai laci penyimpanan sementara. Perintah ini memungkinkan kita untuk menyimpan semua perubahan yang belum di-commit dengan aman, dan mengembalikan kondisi proyek ke keadaan commit terakhir.

Mari kita bedah perintah-perintah yang digunakan pada contoh di atas:

• git stash push -m “WIP: tambah bagian Catatan di README” : Menyimpan perubahan yang belum di-commit ke dalam “laci” sementara dengan pesan deskriptif.
• git stash list : Menampilkan daftar semua simpanan (stash) yang ada.
• git stash show stash@{0}: Mengintip ringkasan perubahan di dalam stash tanpa mengeluarkannya.
• git stash pop stash@{0} : Menerapkan perubahan dari stash dan langsung menghapusnya dari daftar. Sebagai alternatif, bisa menggunakan git stash apply stash@{0} yang akan menerapkan perubahan tanpa menghapusnya dari daftar.

git stash memberi fleksibilitas untuk bisa bereksperimen dengan aman atau menangani interupsi tanpa harus membuat commit “setengah jadi” (WIP). Sehingga dapat menjaga riwayat commit tetap bersih dan hanya berisi perubahan-perubahan yang sudah final.

Penyerahan Perubahan: Dari Push hingga Merge Request
1. Push Kode ke Remote
Sebelum membagikan hasil kerja ke tim, ada baiknya melakukan satu sinkronisasi terakhir. Ini untuk memastikan kita tidak melewatkan pembaruan apa pun yang mungkin masuk ke branch utama (main) saat sedang mengerjakan task.

Jalankan git pull sekali lagi pada branch utama untuk memastikan semuanya selaras. Setelah yakin tidak ada yang terlewat dan semua perubahan sudah di commit, saatnya untuk mengirimkan (push) branch dari komputer lokal ke server GitLab.

Dengan selalu menuliskan nama remote (origin) dan nama branch secara lengkap, kita membangun kebiasaan untuk selalu sadar dan yakin ke mana kode kita akan dikirim. Sehingga dapat mengurangi risiko kesalahan, seperti secara tidak sengaja melakukan push ke branch yang salah.

2. Merge Request yang Jelas & Informatif
Setelah branch berhasil di-push, pekerjaan di terminal telah selesai. Langkah terakhir adalah membuat Merge Request (MR) di GitLab agar perubahan yang kerjakan bisa digabungkan ke branch utama.

MR yang baik mempercepat proses review dan membuatnya lebih efisien. Bukan sekadar notifikasi, melainkan ringkasan konteks yang memudahkan reviewer menilai perubahan dengan jelas.

Mari kita bedah setiap bagian penting dari Merge Request yang kita buat di atas:

• Judul (Title): Judul MR dibuat ringkas dan informatif, mengikuti format yang sama dengan pesan commit (tipe: deskripsi) sehingga bisa langsung dipahami inti dari MR tersebut.
• Deskripsi (Description): Bagian untuk memberikan konteks. Di dalamnya, ada beberapa komponen kunci:
  Issue: Selalu tautkan MR ke issue yang relevan agar membantu melacak pekerjaan dari awal hingga akhir.
  What did you do: Jelaskan secara singkat perubahan apa yang dibuat dan mengapa.
  Screenshot / Video: Melampirkan screenshot atau bukti visual lainnya yang membuktikan bahwa perubahan sudah sesuai harapan.
  Note for Deployment: Memberikan catatan yang diperlukan jika perubahan membutuhkan pengaturan tambahan pada saat deploy.

Kita telah melalui seluruh siklus kerja, dari persiapan branch hingga membuat Merge Request yang siap direview. Pada akhirnya, manajemen branch yang efektif bukanlah sekadar kumpulan aturan teknis, melainkan sebuah kebiasaan untuk berkomunikasi secara baik dengan tim. Alur kerja ini membuat riwayat proyek lebih jelas dan kolaborasi tim lebih efisien.

Semoga bermanfaat!

Manajemen Branch Git yang Efektif: Dari Task Baru Hingga Siap di Review was originally published in DOT Intern on Medium, where people are continuing the conversation by highlighting and responding to this story.