DEV Community: ibrohim syarif

Building an Autonomous Agent Team That Replicates My Engineering Workflow

ibrohim syarif — Mon, 15 Jun 2026 17:22:23 +0000

I've been working closely with agentic AI, and after a lot of iteration, I built a small agent team that can replicate the way I actually work — from reading a task to pushing a reviewable branch.

In this post, will walk through the four specialized agents and one skill that orchestrates them end to end

The Mental Model

When I pick up a task, my workflow looks like this

the agent team mirrors this exactly:

/ship <task or Jira key>
      └─ clarifier     — is the task specific enough?
      └─ planner       — explore codebase, write implementation plan
      └─ implementer   — execute plan task-by-task, commit each chunk
      └─ reviewer      — diff the branch, find blockers and nits
      └─ tester        — go vet, go test -race, golangci-lint

The key insight: Each agent has one job and a fixed output contract. No free-form chat — agents emit structured tokens (PLAN_WRITTEN, REVIEW_RESULT, TEST_RESULT) that the orchestrator parses to route the next step. Its cheaper, faster, prevent AI to hallucinated

Planner

Before writing the code, we explore the codebase: find what already exists, check the dependencies, spot the blockers. The planner agent does the same

Planner reads a task description or Jira key, explores the codebase, then outputs a detailed implementation plan — file paths to create/modify, checkbox steps, and exact code changes. Detailed plans eliminate guessing by next subagents

---
name: planner
description: "Planner agent receives a task description and codebase directory, explores relevant files, and writes a detailed implementation plan in writing-plans format."
tools: Read, Glob, Grep, Bash
model: opus
---

# Planner

Read a task, explore the codebase, write a bite-sized implementation plan.

## Input

TASK: <task description or Jira ticket body>
PLAN_PATH: <absolute path to save the plan>
WORKDIR: <repo root>
JIRA_KEY: <optional, e.g. TASK-1234>

## Process

Use absolute paths throughout. Grep key terms, read relevant files, find reuse candidates

## Plan Format

# <Feature Name> Implementation Plan

**Goal:** <one sentence>
**Architecture:** <2-3 sentences>
**Tech Stack:** <key technologies>

---

Followed by numbered tasks. Each task must have:
- `**Files:**` — exact paths to create/modify/test
- Checkbox steps (`- [ ]`)
- Real code in every code step (no placeholders)
- Exact shell commands with expected output
- TDD order: write failing test → run → implement → run again → commit

Rules:
- No TBD, no TODO, no "similar to above"
- Stage specific files: `git add <file>` (never `git add .`)
- Commit format: `<type>(<scope>): <subject>`

## Output
PLAN_WRITTEN: <PLAN_PATH>

If task is too vague:
AMBIGUOUS: <single question that unblocks planning>

Implementer

The Implementer agent will reads the plan, create a new branch, executes every task in order, commits each chunk before moving to the next. Two modes:

Normal mode — follows the plan step by step. Stops immediately on test failure or build error. Never guesses.

Blocker-fix mode — activated when REVIEW_BLOCKERS is passed. Ignores the original plan. Fixes only the listed issues, re-runs tests, commits with fix(review): resolve review blockers.

This dual mode is what makes the review-retry loop work

---
name: implementer
description: Implementer agent reads an implementation plan and executes it task-by-task, committing each chunk to the current branch.
tools: Read, Write, Edit, Bash, Glob, Grep
model: sonnet
---

# Implementer

Your job: read an implementation plan and execute every task, committing each chunk.

## Input

You receive a message in this format:

PLAN_PATH: <absolute path to the plan markdown file>
BRANCH: <current branch name>
REVIEW_BLOCKERS: (optional)

## Process

**If `REVIEW_BLOCKERS` is present in the input:**
1. Ignore the plan at PLAN_PATH entirely
2. Fix only the issues listed under REVIEW_BLOCKERS
3. Run tests after fixing: `go vet ./... && go test -race -short -count=1 ./...`
4. If tests fail: stop immediately and report
5. Stage and commit only the fixed files:
   - Commit message: `fix(review): resolve review blockers`

**If `REVIEW_BLOCKERS` is absent (normal mode):**
1. Read the plan at PLAN_PATH
2. Execute tasks in order. For each task:
   - Follow the checkbox steps exactly
   - Run tests after each implementation step
   - If a test fails: stop immediately
   - If a build error occurs: stop immediately
   - Stage and commit specific files after completing the task
3. Count commits made

## Rules

- Commit format: `<type>(<scope>): <subject>`
- If a step says "run test to verify it fails" and it passes — stop and report the discrepancy
- If blocked or confused — stop and report, do not guess

## Output

On success:
DONE: <N> commits on <BRANCH>

On failure:
FAIL: Task <N> "<task name>" — <what went wrong>

Reviewer

The Reviewer agent will compare the branch against the default base and classifies every finding:

Blocker — correctness bugs, security issues, data loss risk, nil dereference, breaking API contract.

Nit — naming inconsistency, redundant code, observability gaps, pattern deviation.

Signal bar - findings below ~80% confidence are dropped. it reduce unnecessary review

Move back all the bug findings to the Implementer agent

---
name: reviewer
description: Reviewer agent diffs a branch against the default base branch and emits structured Blocker/Nit findings. Blockers stop the pipeline.
tools: Read, Bash, Glob, Grep
model: sonnet
---

# Reviewer

Your job: review the diff of a branch against the repo's default base branch. Emit findings. Blockers stop the ship pipeline.

## Input

You receive a message in this format:
BRANCH: <branch name to review>

## Process

1. Detect base branch:
   BASE=$(git remote show origin 2>/dev/null | grep 'HEAD branch' | awk '{print $NF}')
   BASE=${BASE:-main}
2. Get the diff:
   git diff ${BASE}...HEAD
3. List changed files:
   git diff --name-only ${BASE}...HEAD
4. For each changed file, read it in full if needed for context
5. For each changed file, read surrounding code and direct callers for context — one level up only, at most 3 additional files total. Do not recurse further.
6. Identify findings:
   - **Blocker**: correctness bug, security issue (SQL injection, secrets in code, auth bypass), data loss risk, nil/null dereference, off-by-one in critical path, missing error check on I/O, missing timeout/deadline on I/O call, missing idempotency key on mutation/payment op, inconsistent state risk (e.g. DB write succeeds but queue emit can fail with no rollback), breaking API contract (removed/renamed exported symbol, changed Kafka schema, removed HTTP route)
   - **Nit**: naming inconsistency, redundant code, minor style deviation, missing doc comment on exported symbol, observability gap on critical path (missing metric, log correlation ID, or tracing span), pattern deviation (similar integrations in the codebase all have X — this one doesn't)
   - **Signal bar**: only flag when confident. Drop findings below ~80% confidence — a wrong flag costs more than a missed nit

## Output format

Return exactly this structure when no blockers:
REVIEW_RESULT: PASS
BLOCKERS: none
NITS:
- path/to/file.go:42 — unused variable `err` shadowed by inner scope

Or when blockers exist:

REVIEW_RESULT: BLOCKED
BLOCKERS:
- path/to/file.go:15 — error from `rows.Scan` not checked, data silently ignored
NITS:
- path/to/file.go:99 — naming: `getUser` should be `GetUser` (exported)

Rules:
- Only flag real issues. Do not flag style preferences as blockers.
- If diff is empty, return `REVIEW_RESULT: PASS` with `BLOCKERS: none` and `NITS: none`.

Tester

The last one is tester agent. It will make sure for the last time that the changes will not break the code by testing all the test files. Since my works is very closely with the Golang, this tester agent only focus on the Golang language

---
name: tester
description: Tester agent runs go vet, go test -race -short, and golangci-lint (if .golangci.yml present). Returns PASS or FAIL with compact summary.
tools: Bash, Read
model: haiku
---

# Tester

Your job: run the test suite and report a one-line verdict.

## Input

You receive a message in this format:
WORKDIR: <absolute path to repo root>

## Process

First, detect repo type:
find <WORKDIR> -name "*.go" | head -1

If no `.go` files found → return `TEST_RESULT: PASS` with note `No Go files found — skipping Go checks.` and stop.

If `.go` files exist, run these commands in order, stopping on first failure:

1. Go vet:
   go vet ./...
   (run from WORKDIR)

2. Go test:
   go test -race -short -count=1 -timeout 120s ./...
   (run from WORKDIR)
   Note: `-short` skips tests marked with `testing.Short()` — integration tests using that flag will not run.

3. Lint (only if `.golangci.yml` exists in WORKDIR):
   golangci-lint run
   (run from WORKDIR)

## Output

On full pass:
TEST_RESULT: PASS
All checks passed.

On failure:
TEST_RESULT: FAIL
<step that failed>: <error output>

Error output rules:
- `go vet`: include all output (usually short)
- `go test`: include all lines containing `FAIL`, `panic`, or `Error`, plus the last 40 lines of output
- `golangci-lint`: include the first 30 lines of lint errors

Ship Skills

All those agents will not run by their own, we still need skill to orchestrate those agent into workflow

/ship <task or Jira key>

Pipeline:

0. Clarifier → CLEAR or ask user one question
1. Create branch
2. Planner → PLAN_WRITTEN
3. Implementer (initial)
4. Review-retry loop (max 2 attempts)
   └─ BLOCKED → implementer fixes blockers → reviewer retries
5. Tester
6. Success summary

Design Decisions

Agents emit structured tokens (PLAN_WRITTEN:, REVIEW_RESULT:, BLOCKED:), not prose. Prose forces orchestrator to run a second LLM call just to extract intent — added latency, added cost, and a new failure surface for hallucinated routing. Structured tokens let orchestrator branch with a simple string match: deterministic, zero inference, no misroute
80% confidence threshold — the most critical quality lever. False positives teach engineers to ignore the reviewer; high-noise output gets skipped, not fixed
Different agents have different cost/capability tradeoffs. Planner needs deep reasoning (Opus). Reviewer needs precision (Sonnet). Tester just runs commands (Haiku). Wrong model assignment burns budget or misses findings
Review-retry capped at 2. Uncapped loops are a denial-of-wallet attack on API credits

If you've ever caught yourself doing the same "explore → plan → implement → review → test" loop for the tenth time, you don't have to. The loop is automatable. You just have to write it down

The Dangers of High-Cardinality Labels in Prometheus

ibrohim syarif — Sun, 22 Feb 2026 04:51:57 +0000

We're all familiar with the warnings: "Don't use user_id as a Prometheus label" or "Don't use transaction codes as labels — they can crash Prometheus". But do we really understand why these are so dangerous?

Before that, we need to know how Prometheus works.

How Prometheus Works

Prometheus is an open-source systems monitoring and alerting tool that collects and stores its metrics as time-series data. It periodically scrapes metrics from your services based on the configured interval.

This is an example of the config:

scrape_configs:
  - job_name: 'golang-app'
    static_configs:
      - targets: ['localhost:8080']
    scrape_interval: 5s

This config will tell Prometheus to:

Target: send an HTTP request GET to http://localhost:8080/metrics
Periodically: for every 5 seconds
Label: with job=golang-app

Prometheus has three metric types:

Gauges represent current measurements and reflect the current state of a system, such as CPU usage and memory usage.
Counters measure discrete events that continuously increase over time. Common examples are the number of HTTP requests received, CPU seconds spent, and bytes sent.
Histogram tracks the distribution of observed values. For a base metric name <basename>, it exposes multiple related time series:

<basename>_bucket{le="..."} — Cumulative counters representing the number of observations that fall within each bucket boundary
<basename>_sum — The total sum of all observed values
<basename>_count — The count of events that have been observed

Time Series Database (TSDB)

Prometheus collects and stores metrics as time series. Each time series is uniquely identified by a metric name and a set of labels, while each sample within the series contains a timestamp and a value. Each unique combination of labels (method, path, and status) represents a separate time series whose value increases as more requests are processed, with total method x path x status.

In the Counter metrics example, suppose we have two endpoints: GET: /api/data, GET: /api/users, and each of which can return either a 200 or 500 status code. This results in the following metrics:

http_requests_total{method="GET", path="/api/data",  status="200"} 17
http_requests_total{method="GET", path="/api/data",  status="500"} 0
http_requests_total{method="GET", path="/api/users", status="200"} 10
http_requests_total{method="GET", path="/api/users", status="500"} 2

Because each time series represents a unique combination of labels, these four label combinations produce four distinct time series. In the time-series database (TSDB), each of these time series is stored independently:

// time series 1
2026-02-19 09:00:00 | {__name__="http_requests_total", method="GET", path="/api/data", status="200"} | 15
2026-02-19 09:00:05 | {__name__="http_requests_total", method="GET", path="/api/data", status="200"} | 16
2026-02-19 09:00:10 | {__name__="http_requests_total", method="GET", path="/api/data", status="200"} | 17

// time series 2
2026-02-19 09:00:00 | {__name__="http_requests_total", method="GET", path="/api/data", status="500"} | 0
2026-02-19 09:00:05 | {__name__="http_requests_total", method="GET", path="/api/data", status="500"} | 0
2026-02-19 09:00:10 | {__name__="http_requests_total", method="GET", path="/api/data", status="500"} | 0

// time series 3
2026-02-19 09:00:00 | {__name__="http_requests_total", method="GET", path="/api/users", status="200"} | 8
2026-02-19 09:00:05 | {__name__="http_requests_total", method="GET", path="/api/users", status="200"} | 9
2026-02-19 09:00:10 | {__name__="http_requests_total", method="GET", path="/api/users", status="200"} | 10

// time series 4
2026-02-19 09:00:00 | {__name__="http_requests_total", method="GET", path="/api/users", status="500"} | 1
2026-02-19 09:00:05 | {__name__="http_requests_total", method="GET", path="/api/users", status="500"} | 2
2026-02-19 09:00:10 | {__name__="http_requests_total", method="GET", path="/api/users", status="500"} | 2

The Dangers

Let's go back to the warning: "Don't use user_id as a Prometheus label" or "Don't use transaction codes as labels — they can crash Prometheus."

Imagine you want to record transaction latency using metric labels such as:

status: pending, paid, success, failed
payment_type: wallet, cash

Here, status has 4 possible values, payment_type has 2 possible values. It will produce status (4) x payment_type (2) = 8 time series

This is the example result of the metrics

there are exactly 8 label for the metrics

Then, you adjust the metrics by adding a code label, allowing request rates, error rates, and traffic patterns to be broken down per transaction

code: a unique identifier for each transaction

However, code is unique for every transaction and grows continuously with request volume. As a result, the number of possible values for code is unbounded and increases over time. status (4) × payment_type (2) × code (∞) = ∞ time series

This is the example result of the metrics

This single unbounded label is enough to turn an otherwise manageable metric into a high-cardinality time-series explosion that can cause memory exhaustion and query performance.

Summary

Adding labels whose values grow unbounded over time—such as UUIDs, timestamps, user IDs, or transaction codes—is strongly discouraged. These labels rarely add meaningful value at the metrics level and introduce high cardinality. For high-cardinality data, better use logging, not metrics

High-cardinality labels can lead to serious issues, including:

Huge memory usage — each unique label set creates a new time series
Rapid disk growth
Slow queries
Scrape performance issue

It's better to use labels that have semantic meaning, and strongly recommended to keep the number of labels to a minimum

A wise man says, "Never use a label whose value grows with users, requests, or time."

Good labels describe what something is, not who or which exact instance.

code: https://github.com/ibrohhm/prometheus-grafana-golang

Circuit Breaker Pattern

ibrohim syarif — Wed, 04 Dec 2024 12:00:00 +0000

Integrating with an external service often means dealing with unexpected behavior that impacts our service’s performance. The previous article prevents the crash/OOM by adding a timeout. But a timeout only limits how long you wait per request, it doesn’t stop you from waiting at all.

If the partner has an outage for 20 minutes, do we actually need to keep sending requests to them? Every request still needs its full 3 seconds before it times out. It’s true that the timeout prevents our service from an OOM crash, but do we need to keep the 3-second wait for each request when we already know it’s broken?

Solution

Once you’ve had a handful of failures in a row, there’s no reason to keep requesting. That’s the idea behind a circuit breaker: stop sending requests to a partner that’s already failing, and fail immediately instead of waiting to find out again.

A circuit breaker has three states:

Closed — normal operation, meaning the service allows connections through normally.
Open — once failures exceed the threshold, meaning the service no longer allows connections and returns an error immediately without touching the partner.
Half-Open — after a cooldown, the breaker lets a small number of test requests through. If they succeed, it closes again. If they fail, it stays open.

Same setup as the previous article’s Case 3 — a 3-second timeout. Every caller experiences a flat 3-second latency spike for the entire outage.

With the circuit breaker, the chart looks more like this:

There’s no more 3-second wait once the breaker has had enough failures to trip. Requests fail instantly, removing the unnecessary wait for an external call that we already know is broken.

var breaker = gobreaker.NewCircuitBreaker(gobreaker.Settings{
    Name:    "partner-service",
    Timeout: 30 * time.Second, // how long it stays open before probing again
    ReadyToTrip: func(counts gobreaker.Counts) bool {
        return counts.ConsecutiveFailures > 5
    },
})

func fetchFromPartner(ctx context.Context) (*Response, error) {
    result, err := breaker.Execute(func() (interface{}, error) {
        return fetchFromPartnerWithTimeout(ctx)
    })
    if err != nil {
        return nil, err // fails instantly once the breaker is open
    }
    return result.(*Response), nil
}

After the 30 second Timeout window, the breaker moves to half-open and lets one request through to check if the partner recovered. If it succeeds, the breaker closes and traffic resumes normally. If it fails, the breaker opens again and waits another 30 seconds.

Summary

The timeout bounds how long a single request can wait. The circuit breaker bounds how many requests you send to a partner that’s already failing. Once it’s open, you stop paying the timeout cost on every call, and stop sending requests to an external service that is broken.

The two work together: timeout limits the damage of any one request, and the breaker stops the damage from adding up once the partner is actually down.

Crash and Timeout Simulation

ibrohim syarif — Sun, 21 Jul 2024 08:35:21 +0000

Your team handles a service that has integration with external services, the service you cannot control. How do you make your service reliable regardless of what happens to the external service’s performance? How do you handle peak hours while the external service is having performance issues?

Your job as the maintainer isn’t just shipping the code, but also preventing the chaos caused by that external service.

Simulation

Each request to that external service holds a small chunk of your service’s memory until the request finishes. If requests pile up because the external service is slow, that memory stays locked up.

More pending requests means more memory tied up. The number of pending requests depends on two things: how fast requests come in, and how long each request takes.

pending requests = request rate x request duration

Each request takes approximately 50 KB of memory, so 100 pending requests would take ~5 MB.

It’s time for the simulation.

Case 1: 100 rps with latency 200 milliseconds

Your service integrates with a reliable external service — the max latency for a single request is only 200 milliseconds.

At 100 rps with 200ms latency, pending requests stay steady at 100 × 0.2 = 20 — so memory ramps up fast, then flattens at ~20 × 50 KB = 1 MB and holds there. No growth, no crash.

Case 2: 100 rps with latency 20 seconds

Something unexpectedly happens, the external service degrades badly, latency stretches to 20s.

Pending requests are 100 × 20 = 2000, and at 50 KB memory for each request that’s ~100 MB — exactly your service’s memory limit. It never gets a chance to settle there, the memory climbs straight into the ceiling, and the process gets OOM killed — once memory goes over the limit, the kernel kills the process right away, with no chance to shut down cleanly first.

Every pending request holds its memory until the external service finally responds. A 20 second hang at 100 rps is enough on its own, no traffic spike required.

The simple way to solve the problem is by adding the timeout for each external request.

Case 3: 100 rps with latency 20 second, with a 3 second timeout

Same broken external service, same 20 second latency, same 100 rps, the only change is adding the timeout threshold 3s.

The service will cut off any inflight request that takes longer than the threshold. The maximum latency will be 3s no matter how slow the external service actually is. Resulting pending = 100 × 3 = 300, or ~15 MB — nowhere near the 100 MB limit, regardless of how long the outage drags on.

The requests still fail, you’ll get a timeout error instead of a response, but the service itself keeps running, which means every other request still gets served.

example code in golang:

ctx, cancel := context.WithTimeout(ctx, 3*time.Second)
defer cancel()

req, err := http.NewRequestWithContext(ctx, http.MethodGet, partnerURL, nil)
if err != nil {
    return nil, err
}

resp, err := http.DefaultClient.Do(req)
if err != nil {
    // ctx deadline exceeded after 3s: err wraps context.DeadlineExceeded
    return nil, err
}
defer resp.Body.Close()

Summary

The external service’s behavior was never something you could control. What you can control is how you handle that request. A simple timeout saves your service from crashing and prevents the cascading error for other internal services that call your service. But this is just a simulation, the request rate may vary in real cases, and there may be many external services you need to handle.

Another solution that can control the request is a rate limiter that shrinks the request rate, or a circuit breaker that can automatically stop sending requests once the external service is failing. A resilient integration usually leans on all three together, not just one.

Know Better About N+1 Queries Problem

ibrohim syarif — Wed, 29 Nov 2023 16:41:42 +0000

Overview

In the engineering process we often face the case of querying all the data based on its parent, and the data will be used for some reason. For example, the users table has a one-to-many correlation with the transactions table, and your job is to get all users and their transactions.

func LoadData() ([]LoadResult, error) {
      users, _ := GetUsers()
      result := make([]LoadResult, 0, len(users))
      for _, u := range users {
              txs, _ := GetTransactionByUserID(u.ID)
              result = append(result, LoadResult{User: u, Transactions: txs})
      }
      return result, nil
}

It’s really simple logic, but is it good enough? Is it bad? Can our service endure high throughput? Is there any way to make it more efficient?

Look Inside the Query

The query depends on the number of users, so let’s say we have three users with id 1, 2, and 3. The queries from that code should look like this. The first one queries all the users based on the user_ids, and the 3 others are queries to fetch the transactions for each user.

SELECT "users".* FROM "users"
SELECT "transactions".* FROM "transactions" WHERE "transactions"."user_id" = 1
SELECT "transactions".* FROM "transactions" WHERE "transactions"."user_id" = 2
SELECT "transactions".* FROM "transactions" WHERE "transactions"."user_id" = 3

What happens if the user_ids list is huge? Will we query to fetch the transactions as many times as the number of users we have? Now we’re facing the N+1 queries problem.

N+1 Query Problem

This is a common problem in database queries: it executes the query one-by-one for every instance instead of 1 or 2 queries. In the example above we fetch all three users’ data, then continue with a query for all the transactions for each user — that’s 4 queries (1+3). If there are N users’ worth of data, first it fetches all N users, then continues to query the transactions for each user, so it’s called N+1 queries.

The problem with N+1 queries is that each query takes some amount of time — the performance impact grows with data volume.

The Solution

Instead of querying the transactions one-by-one, gather all the user_ids first, then query the transactions with all user_ids in one batch.

func LoadData() ([]LoadResult, error) {
      users, _ := GetUsers()
      userIDs := make([]int64, 0, len(users))
      for _, u := range users {
              userIDs = append(userIDs, u.ID)
      }

      txs, _ := GetTransactionByUserIDs(userIDs)

      txsByUserID := make(map[int64][]Transaction, len(users))
      for _, tx := range txs {
              txsByUserID[tx.UserID] = append(txsByUserID[tx.UserID], tx)
      }

      result := make([]LoadResult, 0, len(users))
      for _, u := range users {
              result = append(result, LoadResult{User: u, Transactions: txsByUserID[u.ID]})
      }
      return result, nil
}

This approach reduces queries to just two: one fetching users and another fetching all their transactions in a single batch operation, then a cheap in-memory grouping step — significantly improving performance regardless of dataset size.

Wrap Up

N+1 queries happen whenever you fetch a parent record, then loop over it to fetch each child record one by one. It’s easy to miss because the code reads simply and works fine in development with a handful of rows Next time a query feels slow, count how many times it’s actually hitting the database. If that number scales with your row count, you’ve found your N+1.