DEV Community: semi

Cats Disappear at Sunset. Can You Find Them in Time?

semi — Wed, 10 Jun 2026 22:04:52 +0000

This is a submission for the June Solstice Game Jam

What I Built

For this game jam, I built Find Them Before They Disappear, a hidden-object browser game where you find target cats before sunset takes them away.

The idea started with the solstice itself.

June 21 is the longest day of the year. After that, days get shorter. Light fades. Things disappear. I wanted a game that captures that feeling of racing against fading light.

In the game, you're shown a few target cats for 5 seconds. Memorize their traits. Then 20 to 90 cats spawn on screen. Find the targets before the sun sets. Wrong clicks cost you 5 seconds. Fast correct clicks build combos. When the timer drops below 10 seconds, the screen pulses red and the panic kicks in.

The cats physically fade as time runs out. That was the agent's idea, not mine. It turned out to be the best visual metaphor in the game.

Each target cat has a unique combination of traits: body color (orange, black, white, gray, brown), eye color (green, blue, yellow), and accessories (hat, glasses, ribbon, collar, or none). You have to compare traits carefully. Click the wrong cat and you lose time. Click the right one fast enough and you get a combo bonus.

🎮 Play it here

Video Demo

You can also try:

Finding target cats before sunset
Building combos with fast correct clicks
Surviving the warning pulse at 10 seconds
Watching cats fade as light runs out
Playing all 5 levels (20 cats up to 90 cats)

... directly through the deployed game (on Vercel)

find-them-before-they-disappear.vercel.app

Code

The entire game is a single index.html file. Around 900 lines. No build tools, no dependencies, no package.json.

Built with:

Phaser 3 (via CDN)
Web Audio API (synthesized sounds, no audio files)
Phaser Graphics Primitives (all visuals drawn with code)
Vercel (deployment)

I picked Phaser because it handles canvas rendering, input, tweens, and game state without me needing to write a game loop from scratch. The agent already knew the API.

How I Built It

I used Codex, OpenAI's coding agent. No game engine installed. No sprite sheets. No audio files. Two prompts.

The First Prompt: Build the Game

Prompt 1 was around 200 words. I wrote it like a spec doc. Every level's cat count, timer duration, and target count. The full cat trait system. Where the UI elements go. What the end screens say word for word. I told it Phaser 3 from CDN, no external assets, single HTML file, draw everything with graphics primitives.

Output was a working game. Not pretty. Not juicy. But functional. You could play it start to finish. Five levels, from 20 cats to 90 cats. Timer counting down. Cats drawn with circles and triangles. Target preview, click detection, score tracking.

The biggest thing I learned: prompt quality matters way more than I expected. My first draft was vague. "Make a cat finding game with levels." The agent gave me something broken and generic. So I rewrote it with exact numbers. Level 1: 20 cats, 3 targets, 60 seconds. Level 2: 35 cats, 3 targets, 55 seconds. All the way to level 5: 90 cats, 5 targets, 40 seconds. I defined the trait system (5 body colors, 3 eye colors, 5 accessories). I wrote the exact victory and game over messages. That version worked on the first try.

The Second Prompt: Make It Feel Good

Prompt 2 was about juice. But I was specific about what that means. Not just "add juice." I listed each effect I wanted:

Hover effects on cats (visual feedback when you mouse over)
Sound effects using Web Audio API (correct chime, wrong buzz, tick, button click)
Combo bonuses for fast consecutive correct clicks
Warning pulse when timer drops below 10 seconds
Clearer target cards so you can compare traits easily
Restart button for quick replays
Mobile touch support with proper touch-action handling

Night and day difference. The first version was a prototype. The second one was a game I actually wanted to play.

Same approach with prompt specificity. "Add juice" gets you random particle effects. "Add hover effect on cats, sound effects using Web Audio API with no external files, combo bonus for fast correct clicks, warning pulse below 10 seconds" gets you exactly what you asked for.

Making the Solstice Matter

The solstice theme wasn't an afterthought. I picked it first, then designed the game around it.

The game is built around one metaphor: light is time, and time runs out.

The sun sets as your timer counts down
Cats fade as darkness approaches
Found cats sparkle and disappear safely
Unfound cats vanish with the sunset

Victory message: "You found them before the longest day ended."

Game over: "They disappeared with the sunset."

June 21 is the longest day. This game is about the urgency of that moment. Finding what matters before the light goes out.

Art Direction

Everything is drawn with Phaser's graphics primitives. Circles for heads and bodies. Triangles for ears. Rectangles for accessories. No sprites, no images, no external assets.

This wasn't just a technical choice. It means every cat is consistent. Same style, same proportions, same visual language. And it means I didn't spend hours hunting for sprites or worrying about licensing.

The sunset gradient background changes as time runs out. The sky goes from warm orange to deep purple to dark blue. Cats go from fully visible to semi-transparent. The whole screen tells you time is running out without needing to look at the timer.

Technology

The full stack:

Phaser 3 via CDN (game framework)
Web Audio API (sound synthesis)
Phaser Graphics Primitives (visuals)
Single HTML file (no build step)
Vercel (hosting)

No npm. No node_modules. No build tools. I literally opened the file in a browser to test it.

Thanks for checking out Find Them Before They Disappear 🌅

I Abandoned a 50-Line Bounty Tracker. Then I Finished It Properly in One Night.

semi — Sun, 31 May 2026 22:07:31 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Bounty Tracker is a web app that helps open source developers discover, track, and manage GitHub bounties and pull requests in one dashboard.

The project started from a real problem. I was hunting bounties across multiple repos, losing track of which issues I was working on, which PRs were pending review, and how much money I was actually owed. I needed a single place to see everything.

I built the first version as a quick Express server with in-memory storage and a basic HTML dashboard. It worked, technically. You could add bounties and PRs. But the data disappeared every time the server restarted. There was no way to discover new bounties. The UI was barebones. I pushed the code and walked away.

The GitHub Finish-Up-A-Thon Challenge gave me the push to revive and actually finish it.

Tech stack: Next.js 14, React 18, TypeScript, Tailwind CSS. Deployed on Vercel as a static app. No server, no database.

Demo

Live: https://bounty-tracker-nu.vercel.app
Source: https://github.com/iyop666/bounty-tracker

The app has four tabs:

Dashboard shows six stat cards (total bounties, active count, total value, won value, total PRs, merged PRs) and two panels with your five most recent bounties and PRs.
Bounties tab lets you add, edit, and manage tracked bounties. Status lifecycle: open, working, submitted, won, expired. Inline editing for status and amount.
PRs tab tracks pull requests with status options (pending, review, merged, closed) and links each PR to a specific bounty.
Discover tab searches GitHub for bounty-labeled issues via the GitHub Search API. One click to import any result into your tracked bounties.

Everything persists in localStorage. No sign-up, no server. Your data stays in your browser.

The Comeback Story

Before:

The original project was a single Express file with 50 lines of JavaScript. In-memory arrays for storage. A basic HTML dashboard with inline CSS. You could add items and see them listed. Data was gone on every server restart. That was it.

let bounties = [];
let prs = [];

app.get("/api/bounties", (req, res) => {
  res.json(bounties);
});

What I changed, fixed, and added:

Full TypeScript rewrite. Replaced the single JS file with a structured Next.js app: layout.tsx for the shell, page.tsx for the four-tab interface, types.ts for data models, storage.ts for localStorage CRUD. The Bounty type uses a union ("open" | "working" | "submitted" | "won" | "expired") so you cannot set an invalid status.
localStorage persistence. The original used in-memory arrays, the worst of both worlds: no persistence, requires a server. I chose localStorage over a database because this is a personal tracking tool, not a multi-user SaaS. Zero cost, works offline, data stays in the browser.
GitHub API discovery. The Discover tab hits https://api.github.com/search/issues?q=label:bounty and parses the results. Each issue shows title, repo, author, creation date, and labels. The repository_url field gets stripped to extract owner/repo path. One click imports an issue into your bounty list with auto-detected labels.
Status management system. 5 bounty states (open, working, submitted, won, expired) and 4 PR states (pending, review, merged, closed). Each state has a distinct color badge matching GitHub's design language: blue for open, yellow for working, purple for submitted, green for won/merged, gray for expired, red for closed.
PR-to-bounty linking. When adding a PR, you can select which bounty it belongs to. The linked bounty name shows next to the PR in the list. This creates a visual connection between the work you are doing (PR) and the money you are chasing (bounty).
Dark theme UI. Built with Tailwind CSS matching GitHub's color palette (#0d1117 background, #161b22 cards, #58a6ff accent). Responsive design works on mobile. Fade-in animations on tab switches.

After:

Over 500 lines of TypeScript across 6 files. 4 major components (Dashboard, Bounties, PRs, Discover). GitHub API integration with search and import. localStorage persistence layer with pure CRUD functions. Status badge system with 9 color mappings. Deployed and live at bounty-tracker-nu.vercel.app.

My Experience with GitHub Copilot

I used GitHub Copilot Free during this rebuild, specifically the Copilot CLI in my terminal.

Scaffolding. Setting up Next.js 14 with TypeScript and Tailwind involves boilerplate: tsconfig.json, postcss.config, tailwind.config, layout files. Copilot suggested the right patterns and filled in the repetitive parts. I did not have to look up "how to configure tailwind v3 with next 14" for the fifth time.
GitHub API patterns. The search endpoint has specific query syntax. You need label:bounty in the query string, the right Accept header, and you need to parse repository_url to get the repo path. I typed fetch("https://api.github.com/search/issues?q= and Copilot completed the rest of the URL with the correct parameters. That saved me 20 minutes of reading API docs.
Color mapping. I started typing const STATUS_COLORS and Copilot filled in the entire object with GitHub-style hex values. It knew open should be #58a6ff (blue), merged should be #3fb950 (green), and closed should be #f85149 (red). Small thing, but it kept me in flow.

Where Copilot struggled was the business logic. The bounty status system has five states with implicit transitions. Copilot's suggestions were generic state management patterns that did not match what I needed. I had to write the status update logic and the PR-to-bounty linking myself. For domain-specific logic, Copilot needs guidance. For boilerplate and API patterns, it is genuinely useful.

How Hermes Agent Helped Me Ship an Indonesian NLP Parser in One Week

semi — Wed, 27 May 2026 20:18:04 +0000

This is a submission for the Hermes Agent Challenge: Build With Hermes Agent

What I Built

Warung MiMo is an AI-powered assistant for Indonesian warungs, small neighborhood shops that run a huge part of daily commerce in Indonesia. The assistant lets shop owners manage inventory, track debts, and log sales using natural Indonesian. Voice input, text input, receipt scanning. Whatever feels natural to them.

The core challenge was language.

Indonesian warung owners do not speak in clean, structured commands. They say things like:

"Bu Sari utang empat puluh dua ribu" (Mrs. Sari owes forty-two thousand)
"Indomie tinggal lima bungkus" (Indomie left, five packs)
"Aqua habis, gula sisa setengah kg" (Aqua out of stock, sugar half a kg left)

That one sentence contains multiple actions, numbers written as Indonesian words, product names in shorthand, and a debt instruction. Generic NLP cannot handle this. I needed a custom parser built from scratch.

And I needed Hermes Agent to make it happen.

Demo

Live: warung-mimo.vercel.app
Source: github.com/iyop666/warung-mimo

Try these inputs in the assistant page:

"Indomie tinggal lima bungkus"
"Aqua habis, gula sisa setengah kg"
"Bu Sari utang empat puluh dua ribu"
"bayar utang Bu Sari"
"Catat utang Pak Budi 50rb, terus telur tinggal tiga"
"Teh Botol kosong, kopi sisa dua belas sachet"

The assistant parses each sentence, identifies products, extracts numbers (even written as Indonesian words), and generates structured actions like stock updates or debt records.

Code

The full source is at github.com/iyop666/warung-mimo.

Here are the key modules that Hermes Agent helped build:

Indonesian Number Parser

This was the hardest part. Indonesian compound numbers work differently from English. "Empat puluh dua" means forty-two (4 x 10 + 2). The parser needed to handle the "puluh" (tens) multiplier logic.

const NUMBER_WORDS: Record<string, number> = {
  nol: 0, satu: 1, se: 1, dua: 2, tiga: 3, empat: 4,
  lima: 5, enam: 6, tujuh: 7, delapan: 8, sembilan: 9,
  sepuluh: 10, sebelas: 11,
  "dua belas": 12, "tiga belas": 13, "empat belas": 14,
  "lima belas": 15, "enam belas": 16, "tujuh belas": 17,
  "delapan belas": 18, "sembilan belas": 19,
  "dua puluh": 20, "tiga puluh": 30, "empat puluh": 40,
  setengah: 0.5, seperempat: 0.25,
  "1/2": 0.5, "1/4": 0.25, "3/4": 0.75,
};

function parseIndonesianNumber(text: string): number | null {
  const lower = text.toLowerCase().trim();
  const sortedKeys = Object.keys(NUMBER_WORDS).sort((a, b) => b.length - a.length);

  for (const key of sortedKeys) {
    if (lower === key) return NUMBER_WORDS[key];
  }

  let compound = 0;
  let matched = false;
  const parts = lower.split(/\s+/);
  for (const part of parts) {
    if (NUMBER_WORDS[part] !== undefined) {
      if (part === "puluh") continue;
      const idx = parts.indexOf(part);
      if (idx < parts.length - 1 && parts[idx + 1] === "puluh") {
        compound += NUMBER_WORDS[part] * 10;
        matched = true;
      } else if (idx > 0 && parts[idx - 1] === "puluh") {
        compound += NUMBER_WORDS[part];
        matched = true;
      } else {
        compound += NUMBER_WORDS[part];
        matched = true;
      }
    }
  }
  if (matched && compound > 0) return compound;

  const digitMatch = lower.match(/^(\d+(?:[.,]\d+)?)$/);
  if (digitMatch) return parseFloat(digitMatch[1].replace(",", "."));
  return null;
}

Product Matching System

Warung owners rarely use canonical product names. They say "Aqua" instead of "Aqua 600ml", "gula" instead of "Gula Pasir", "rokok" instead of "Rokok Sampoerna Mild". The matcher needed 30+ aliases for 8 products.

const PRODUCT_MAPPINGS: ProductMapping[] = [
  { keywords: ["indomie", "mie goreng", "mi goreng", "mie instan"], canonical: "Indomie Goreng", unit: "bungkus" },
  { keywords: ["aqua", "air mineral", "air botol"], canonical: "Aqua 600ml", unit: "botol" },
  { keywords: ["gula", "gula pasir"], canonical: "Gula Pasir", unit: "kg" },
  { keywords: ["telur", "telor", "telur ayam"], canonical: "Telur", unit: "kg" },
  { keywords: ["minyak", "minyak goreng", "minyak 1l"], canonical: "Minyak Goreng 1L", unit: "liter" },
  { keywords: ["kopi", "kopi kapal api", "kapal api"], canonical: "Kopi Kapal Api", unit: "sachet" },
  { keywords: ["rokok", "sampoerna", "sampoerna mild"], canonical: "Rokok Sampoerna Mild", unit: "bungkus" },
  { keywords: ["teh botol", "sosro", "teh sosro"], canonical: "Teh Botol Sosro", unit: "botol" },
];

Debt Tracking Patterns

Four patterns for recording debt, four for settling. Each handles a different way Indonesians talk about money.

const debtPatterns = [
  // "bu sari utang 25 ribu"
  /(.+?)\s+(?:utang|hutang|ngutang)\s+(\d+(?:[.,]\d+)?)\s*(ribu|rb|jt|juta)?/i,
  // "catat utang bu sari 25000"
  /(?:catat|tulis|tambah)\s+(?:utang|hutang)\s+(.+?)\s+(\d+(?:[.,]\d+)?)/i,
  // "pak budi ngutang 15 ribu"
  /(\w+(?:\s+\w+)?)\s+ngutang\s+(\d+(?:[.,]\d+)?)\s*(ribu|rb|jt|juta)?/i,
  // "utang bu sari 50rb"
  /(?:utang|hutang)\s+(.+?)\s+(\d+(?:[.,]\d+)?)\s*(ribu|rb|jt|juta)?/i,
];

const settlePatterns = [
  /bayar\s+(?:utang|hutang)\s+(.+)/i,
  /(.+?)\s+(?:bayar|lunasi|lunas)\s+(?:utang|hutang)/i,
  /(.+?)\s+(?:sudah|udah)\s+bayar/i,
  /(?:utang|hutang)\s+(.+?)\s+(?:lunas|lunasi|sudah\s*dibayar)/i,
];

Multi-Action Splitter

One sentence can contain a sale, a stock update, and a debt note. The parser splits by commas, "dan", "terus", "lalu", "juga".

const segments = lower.split(/[,;]|\bdan\b|\bterus\b|\blalu\b|\bjuga\b/);

for (const segment of segments) {
  const trimmed = segment.trim();
  if (trimmed.length < 3) continue;

  const product = matchProduct(trimmed);
  if (!product) continue;

  const remaining = parseRemainingFromContext(trimmed);
  if (remaining !== null) {
    actions.push({ type: "update_stock", item: product.name, remaining, unit: product.unit });
  }
}

My Tech Stack

Frontend: Next.js 16, React 19, shadcn/ui, Tailwind 4
Language: TypeScript
Deployment: Vercel
AI Assistant: Hermes Agent (for development, deployment, and infrastructure management)
Platform: Telegram (as the interface to Hermes Agent)

How I Used Hermes Agent

Hermes Agent was not just a coding assistant. It was the operational backbone of the entire project. Here is exactly how it powered the build.

1. Code Generation and Debugging

When I needed the debt tracking regex patterns, I did not write them from scratch. I told Hermes:

"I need regex patterns for Indonesian debt recording. Handle variations like 'bu sari utang 25 ribu', 'catat utang bu sari 25000', 'pak budi ngutang 15 ribu'."

Hermes generated four patterns covering different Indonesian phrasings. I reviewed them, adjusted one edge case, and shipped. What would have taken 30 minutes of regex debugging took 5 minutes.

The same happened with the number parser. The compound logic for "empat puluh dua" (42) was tricky. I described the problem to Hermes, it suggested the "puluh" multiplier approach, and I implemented it.

2. One-Command Deployment

Every deployment followed the same pattern:

"Deploy Warung MiMo to Vercel."

Hermes would:

Run the build
Catch TypeScript errors
Fix them automatically
Rebuild
Deploy
Verify the URL was live
Report back with the link

No terminal switching. No build log reading. No Vercel dashboard. One Telegram message, one response with the live URL.

3. Automated Testing

When I added new product aliases or changed regex patterns, I asked Hermes to test them:

"Test these inputs against the parser: 'empat puluh dua ribu', 'setengah dus', '42rb', '1/2'."

Hermes ran the parser against each input, reported which ones passed and which failed, and suggested fixes for the failures. This feedback loop was faster than writing unit tests for every edge case.

4. Documentation and Publishing

After building the core features, I needed to write about it. Hermes pulled code directly from the project repository, structured it into article format, and published drafts to Dev.to via API.

The article for the GitHub Finish-Up-A-Thon Challenge was written this way. Hermes extracted real code snippets from the codebase, organized them into the submission template, and published. I reviewed and edited, but the heavy lifting was automated.

5. Infrastructure Management

The project runs on a VPS for backend operations. Hermes manages the entire infrastructure:

SSH access with persistent memory of credentials
Automated backups via cron jobs
Health monitoring with Telegram alerts
Log rotation and disk cleanup

All of this happens through conversational commands. No manual SSH sessions. No remembering which port or which directory.

What Made Hermes Agent The Right Fit

The key was context persistence.

Hermes remembered:

The project structure and file locations
The TypeScript configuration and build process
The Vercel deployment setup and environment variables
The Indonesian language patterns we were building for
Previous debugging sessions and solutions

That meant every conversation started where the last one ended. No re-explaining. No context rebuilding. Just continuous development.

For a solo developer building a domain-specific project like Indonesian NLP, that continuity was the difference between shipping and abandoning.

Project Stats:

~2,500 lines of TypeScript
15 React components
30+ Indonesian number word mappings
50+ regex patterns for NLP parsing
8 products with 30+ aliases
8 debt/ settle regex patterns

Links:

How I Built a Multi-Chain DEX Trading Bot with Hermes Agent as My Trading Partner

semi — Wed, 27 May 2026 20:02:00 +0000

This is a submission for the Hermes Agent Challenge: Build With Hermes Agent

What I Built

IYOP Trading Bot is an AI-powered multi-chain DEX trading bot that executes trades across Solana (Jupiter), Ethereum (Uniswap V3), and BSC (PancakeSwap V2). It uses MiMo v2 for market analysis, generates signals from multiple technical indicators, and manages risk with position sizing and drawdown protection.

The problem I was solving: decentralized trading is fragmented. Each chain has its own DEX, its own quirks, its own liquidity pools. Monitoring them manually is impossible. Executing trades across chains requires different SDKs, different gas management, different wallet handling.

I needed a unified layer that could:

Scan multiple DEXs simultaneously
Generate signals from technical indicators and AI analysis
Execute trades with proper risk management
Track positions across chains
Handle stop-loss and take-profit automatically

And I needed Hermes Agent to make the development process fast enough to actually ship.

Demo

Live Demo: iyop-trading-terminal.vercel.app

Source: github.com/iyop666/iyop-trading-bot

The bot runs as a FastAPI backend with a web dashboard. Key features:

Multi-chain DEX scanning (Jupiter, Uniswap V3, PancakeSwap)
AI-powered market analysis via IYOP v2 API
Signal generation with confidence scoring
Risk management with position sizing and drawdown limits
Trade execution with stop-loss/take-profit
Real-time WebSocket price feeds

Code

Here are the core modules that Hermes Agent helped build:

AI Market Analyzer

The analyzer connects to IYOP v2 for fast market analysis, signal generation, and sentiment analysis:

import httpx
from dataclasses import dataclass
from enum import Enum

MIMO_API_URL = "http://127.0.0.1:19911/v1/chat/completions"
MIMO_MODEL = "gitlawb/mimo-v2-flash"

class Signal(Enum):
    BUY = "buy"
    SELL = "sell"
    HOLD = "hold"

@dataclass
class MarketAnalysis:
    signal: Signal
    confidence: float
    reasoning: str
    risk_level: str

async def analyze_market(pair: str, timeframe: str) -> MarketAnalysis:
    """Send market data to MiMo v2 for analysis."""
    async with httpx.AsyncClient() as client:
        response = await client.post(
            MIMO_API_URL,
            json={
                "model": MIMO_MODEL,
                "messages": [
                    {"role": "system", "content": "Analyze this trading pair..."},
                    {"role": "user", "content": f"Pair: {pair}, Timeframe: {timeframe}"}
                ],
                "temperature": 0.1
            },
            timeout=30
        )
        result = response.json()
        return parse_analysis(result)

Signal Generation

Combines multiple technical indicators with weighted scoring:

from dataclasses import dataclass
from enum import Enum

class SignalType(Enum):
    STRONG_BUY = "strong_buy"
    BUY = "buy"
    WEAK_BUY = "weak_buy"
    HOLD = "hold"
    WEAK_SELL = "weak_sell"
    SELL = "sell"
    STRONG_SELL = "strong_sell"

@dataclass
class TradeSignal:
    signal_type: SignalType
    confidence: float  # 0.0 to 1.0
    pair: str
    price: float
    indicators: dict
    reasoning: str

def generate_signal(indicators: dict, ai_analysis: dict) -> TradeSignal:
    """Combine technical indicators with AI analysis."""
    weights = {
        "rsi": 0.25,
        "macd": 0.20,
        "bollinger": 0.15,
        "volume": 0.15,
        "ai_analysis": 0.25
    }

    score = 0.0
    for indicator, weight in weights.items():
        score += normalize(indicators.get(indicator, 0)) * weight

    signal_type = classify_signal(score)
    return TradeSignal(
        signal_type=signal_type,
        confidence=abs(score),
        pair=indicators["pair"],
        price=indicators["price"],
        indicators=indicators,
        reasoning=build_reasoning(indicators, ai_analysis)
    )

Multi-Chain DEX Integration

Unified interface for Jupiter, Uniswap V3, and PancakeSwap:

from enum import Enum
import httpx

class DEX(Enum):
    JUPITER = "jupiter"      # Solana
    UNISWAP = "uniswap"      # Ethereum
    PANCAKESWAP = "pancakeswap"  # BSC

class Chain(Enum):
    SOLANA = "solana"
    ETHEREUM = "ethereum"
    BSC = "bsc"

@dataclass
class SwapResult:
    success: bool
    tx_hash: str
    input_amount: float
    output_amount: float
    chain: Chain
    dex: DEX
    gas_used: float

async def execute_swap(
    dex: DEX,
    chain: Chain,
    token_in: str,
    token_out: str,
    amount: float,
    slippage: float = 0.5
) -> SwapResult:
    """Execute a swap on the specified DEX."""
    if dex == DEX.JUPITER:
        return await jupiter_swap(token_in, token_out, amount, slippage)
    elif dex == DEX.UNISWAP:
        return await uniswap_swap(token_in, token_out, amount, slippage)
    elif dex == DEX.PANCAKESWAP:
        return await pancakeswap_swap(token_in, token_out, amount, slippage)

Risk Management

Position sizing and drawdown protection:

@dataclass
class RiskManager:
    max_position_pct: float = 0.1  # 10% max per position
    max_daily_loss: float = 0.05   # 5% max daily loss
    max_drawdown: float = 0.15     # 15% max drawdown
    current_drawdown: float = 0.0
    daily_pnl: float = 0.0

    def can_open_position(self, portfolio_value: float, position_size: float) -> bool:
        """Check if a new position is within risk limits."""
        # Check position size limit
        if position_size / portfolio_value > self.max_position_pct:
            return False

        # Check daily loss limit
        if self.daily_pnl < -(portfolio_value * self.max_daily_loss):
            return False

        # Check drawdown limit
        if self.current_drawdown > self.max_drawdown:
            return False

        return True

    def calculate_position_size(
        self,
        portfolio_value: float,
        entry_price: float,
        stop_loss: float
    ) -> float:
        """Calculate optimal position size based on risk parameters."""
        risk_per_trade = portfolio_value * self.max_position_pct
        price_risk = abs(entry_price - stop_loss) / entry_price
        return risk_per_trade / price_risk if price_risk > 0 else 0

Trade Execution Engine

Handles order lifecycle with stop-loss and take-profit:

class Side(str, Enum):
    BUY = "buy"
    SELL = "sell"

class OrderStatus(str, Enum):
    PENDING = "pending"
    FILLED = "filled"
    CANCELLED = "cancelled"
    SL_HIT = "stop_loss_hit"
    TP_HIT = "take_profit_hit"

@dataclass
class Position:
    id: str
    pair: str
    side: Side
    entry_price: float
    current_price: float
    size: float
    stop_loss: float
    take_profit: float
    pnl: float
    chain: Chain
    dex: DEX

class Trader:
    def __init__(self, risk_manager: RiskManager):
        self.positions: dict[str, Position] = {}
        self.risk_manager = risk_manager
        self.trade_history: list[dict] = []

    async def open_position(
        self,
        pair: str,
        side: Side,
        size: float,
        stop_loss: float,
        take_profit: float,
        chain: Chain,
        dex: DEX
    ) -> Position:
        """Open a new position with risk checks."""
        if not self.risk_manager.can_open_position(self.portfolio_value, size):
            raise RiskLimitExceeded("Position exceeds risk limits")

        # Execute the swap
        result = await execute_swap(dex, chain, pair, size)

        position = Position(
            id=str(uuid.uuid4()),
            pair=pair,
            side=side,
            entry_price=result.price,
            current_price=result.price,
            size=size,
            stop_loss=stop_loss,
            take_profit=take_profit,
            pnl=0.0,
            chain=chain,
            dex=dex
        )

        self.positions[position.id] = position
        return position

My Tech Stack

Backend: Python, FastAPI, Pydantic
AI Engine: MiMo v2 (local API)
DEX Integrations: Jupiter (Solana), Uniswap V3 (Ethereum), PancakeSwap V2 (BSC)
Data: WebSocket price feeds, httpx for async HTTP
Frontend: HTML dashboard
AI Assistant: Hermes Agent (for development, debugging, and deployment)

How I Used Hermes Agent

1. Architecture Design

When I started building the trading bot, I described the requirements to Hermes:

"I need a multi-chain DEX trading bot with AI analysis, signal generation, risk management, and trade execution. It should support Jupiter, Uniswap V3, and PancakeSwap."

Hermes designed the module structure:

backend/ai/ for AI analysis and signal generation
backend/core/ for DEX integration, risk management, and trade execution
Separation of concerns between analysis and execution

That architecture saved me hours of refactoring later.

2. DEX Integration Code

Each DEX has different APIs, different transaction formats, different gas estimation. Instead of reading docs for each one, I told Hermes:

"Write async swap functions for Jupiter, Uniswap V3, and PancakeSwap. Use httpx, handle errors, return transaction hashes."

Hermes generated the integration code for all three DEXs. I reviewed the error handling, adjusted the slippage parameters, and tested. What would have taken a full day of reading docs and writing boilerplate took 30 minutes.

3. Risk Management Logic

The risk manager needed to handle position sizing, drawdown limits, and daily loss caps. I described the rules:

"Max 10% per position, max 5% daily loss, max 15% drawdown. Calculate position size based on stop-loss distance."

Hermes implemented the logic with proper edge cases. When I tested it with extreme values (100% loss scenarios), it correctly rejected the trades.

4. Signal Weighting System

Combining multiple indicators into a single signal required a weighting system. I asked Hermes:

"Create a signal generator that weights RSI (25%), MACD (20%), Bollinger (15%), Volume (15%), and AI analysis (25%). Normalize each to -1 to +1 range."

Hermes built the weighted scoring system with configurable weights. I later adjusted the AI analysis weight to 30% after testing showed it was the most predictive.

5. Testing and Debugging

When the bot was not executing trades correctly, I asked Hermes to trace the issue:

"Trades are not executing. Check the swap function, the risk manager, and the trade executor. Find the bottleneck."

Hermes read through the code, found that the risk manager was rejecting trades because the portfolio value was not being updated after each trade. One line fix, but finding it manually would have taken an hour of debugging.

Why Hermes Agent Was Essential

Building a trading bot requires:

Fast iteration (markets move, code needs to keep up)
Cross-module awareness (risk manager affects trader, trader affects portfolio)
Async programming patterns (all DEX calls are async)
Error handling edge cases (network failures, insufficient gas, slippage)

Hermes handled all of these because it maintained context across the entire codebase. When I changed the risk manager, it automatically suggested updates to the trader. When I added a new DEX, it updated the signal generator to include the new chain.

That cross-module awareness is what made the difference between a prototype and a working bot.

Project Stats:

~2,000 lines of Python
3 DEX integrations (Jupiter, Uniswap V3, PancakeSwap)
5 trading strategies (momentum, mean reversion, AI-driven, scalping, hybrid)
Risk management with 3 safety layers
Real-time WebSocket price feeds
AI-powered market analysis via MiMo v2

Links:

I Stopped Treating AI Agents Like Toys After Hermes Agent Started Running My Entire Week

semi — Wed, 27 May 2026 10:00:52 +0000

This is a submission for the Hermes Agent Challenge: Write About Hermes Agent

I am a solo developer from Indonesia.

Most of my work revolves around building tools for Indonesian warungs, small neighborhood shops that still run a huge part of daily commerce here. My main project is called Warung MiMo, an AI assistant that understands natural Indonesian. It is built with Next.js 16, React 19, and TypeScript.

At first, I thought my biggest problem was code.

It was not.

My real problem was fragmentation.

Every day looked like this:

Open VS Code.
Open Telegram.
Open Vercel.
Open SSH session.
Open Dev.to draft.
Open browser tabs for hackathons.
Open another terminal for backups.
Open another terminal for monitoring.
Open notes because I forgot which VPS port I changed last month.

Then repeat.

People talk about productivity in a very shallow way. Usually it becomes some aesthetic discussion about morning routines, second monitors, or keyboard shortcuts. My issue was structural. I was constantly paying a mental tax every time I switched contexts.

By the end of the day, I was exhausted from orchestration, not engineering.

That changed after I started using Hermes Agent daily through Telegram.

This article is not a getting started guide.

This is a real usage story from someone who accidentally turned an AI agent into an operational layer for almost everything.

The Three Hour Problem

Before Hermes Agent, I measured my work incorrectly.

I thought I spent most of my time coding. After paying attention for a week, I realized coding was maybe half the job.

The rest was coordination.

Deploying projects. Checking logs. Remembering server configs. Writing articles. Researching hackathons. Installing security tooling. Backing up infrastructure. Running cron jobs. Managing environment variables. Switching devices. Finding files. Reopening old terminal sessions. Rebuilding context from scratch.

The worst part was context switching.

I would be deep inside an Indonesian NLP parser bug, then suddenly remember I forgot to rotate backups. Then I would notice a Vercel deployment issue. Then I would remember a Dev.to draft was still unpublished.

By the time I returned to the parser, my brain cache was gone.

I genuinely think I lost around three hours per day just reconstructing state.

Not coding. Not debugging. Reconstructing state.

That is the problem Hermes Agent solved for me.

Not "AI productivity".

Operational continuity.

What Hermes Agent Actually Became For Me

Most people approach agents like assistants.

I use Hermes more like infrastructure.

Telegram became my command center. Hermes became the layer connecting everything else.

Instead of treating deployment, writing, SSH management, and research as separate tasks across disconnected apps, I started treating them as conversations with persistent operational memory.

That distinction matters.

A chatbot answers questions.

An agent maintains continuity.

Monday: Researching Hackathons Without Drowning In Tabs

Monday is usually research day.

I look for hackathons, AI challenges, and developer competitions that fit my projects. Before Hermes, this process was terrible.

I would open Devpost. Then HackerEarth. Then random Discord announcements. Then I would forget submission requirements because every challenge has different formats.

Now I do most of it through Telegram.

I ask Hermes something like:

"Find active developer hackathons with prize pool above $1k and deadlines within 30 days."

Hermes searches APIs, parses challenge pages, extracts requirements, and summarizes the important parts.

The interesting part is not search itself. Search is easy.

The interesting part is that Hermes remembers my preferences.

It knows I prefer challenges friendly to solo developers, public GitHub repos, AI or infrastructure categories, and working prototypes over pitch decks.

That memory changes the quality of results dramatically.

At one point Hermes even started decoding submission templates automatically. Instead of just giving me a link, it would tell me exactly which sections I needed to fill in, compare my existing drafts against the template, and point out what was missing.

That sounds small until you realize how much hidden cognitive work disappears when the agent already understands your operating style.

Tuesday: Fixing A TypeScript NLP Bug And Deploying In One Conversation

Tuesday was classic Warung MiMo chaos.

I found a bug in the Indonesian number parser. The parser understood "empat puluh dua" but failed in certain compound phrases when users mixed shorthand inventory context with numeric words.

Indonesian NLP gets messy fast because people rarely speak formally. Warung owners say things like "tinggal tiga", "setengah dus", "habis", "sisa dua", "empat puluh dua ribu". Those phrases contain implied meaning that generic NLP systems often miss.

Here is part of the actual compound number logic from my project:

const NUMBER_WORDS: Record<string, number> = {
  nol: 0, satu: 1, se: 1, dua: 2, tiga: 3, empat: 4,
  lima: 5, enam: 6, tujuh: 7, delapan: 8, sembilan: 9,
  sepuluh: 10, sebelas: 11,
  "dua belas": 12, "tiga belas": 13, "empat belas": 14,
  "lima belas": 15, "enam belas": 16, "tujuh belas": 17,
  "delapan belas": 18, "sembilan belas": 19,
  "dua puluh": 20, "tiga puluh": 30, "empat puluh": 40,
  setengah: 0.5, seperempat: 0.25,
  "1/2": 0.5, "1/4": 0.25, "3/4": 0.75,
};

function parseIndonesianNumber(text: string): number | null {
  const lower = text.toLowerCase().trim();
  const sortedKeys = Object.keys(NUMBER_WORDS).sort((a, b) => b.length - a.length);

  // Direct word match first
  for (const key of sortedKeys) {
    if (lower === key) return NUMBER_WORDS[key];
  }

  // Compound: "empat puluh dua" -> 42
  let compound = 0;
  let matched = false;
  const parts = lower.split(/\s+/);
  for (const part of parts) {
    if (NUMBER_WORDS[part] !== undefined) {
      if (part === "puluh") continue;
      const idx = parts.indexOf(part);
      if (idx < parts.length - 1 && parts[idx + 1] === "puluh") {
        compound += NUMBER_WORDS[part] * 10;
        matched = true;
      } else if (idx > 0 && parts[idx - 1] === "puluh") {
        compound += NUMBER_WORDS[part];
        matched = true;
      } else {
        compound += NUMBER_WORDS[part];
        matched = true;
      }
    }
  }
  if (matched && compound > 0) return compound;

  // Pure digit fallback
  const digitMatch = lower.match(/^(\d+(?:[.,]\d+)?)$/);
  if (digitMatch) return parseFloat(digitMatch[1].replace(",", "."));
  return null;
}

The trick is the "puluh" logic. In Indonesian, "empat puluh" means forty (4 x 10). When the parser sees a word before "puluh", it multiplies by 10. When it sees a word after "puluh", it adds. "Empat puluh dua" becomes 4*10 + 2 = 42.

Normally the workflow to fix and deploy this would be: open code editor, debug manually, commit, push, open Vercel, trigger deployment, watch logs, fix environment issue, repeat.

Instead, the entire process became one flowing conversation.

I asked Hermes to:

Inspect the parser logic
Suggest fixes for compound inventory phrases
Check TypeScript typing issues
Commit changes
Push to GitHub
Deploy to Vercel
Verify deployment health

All inside Telegram.

The important part was context continuity. Hermes already knew the repo location, deployment setup, Vercel project config, preferred branch, and environment structure. I did not need to re-explain infrastructure every time.

That changes the emotional feel of solo development completely.

Wednesday: Writing And Publishing Dev.to Articles Through API

Wednesday is writing day.

I publish technical articles because building in public keeps me sane as a solo developer.

Before Hermes, writing technical articles was annoying operationally. I would gather code snippets, open repo manually, copy examples, draft article, format markdown, upload images, publish manually, fix broken formatting.

Now the workflow is dramatically different.

Hermes can read actual repo files, extract relevant snippets, structure articles, and publish directly through the Dev.to API.

That matters because generic AI writing often feels fake. It invents architecture details or produces sanitized tutorial content.

Hermes works differently because it reads the actual project.

For example, when I wrote about debt tracking in Warung MiMo, Hermes pulled the real regex patterns from the codebase:

const debtPatterns = [
  // "bu sari utang 25 ribu"
  /(.+?)\s+(?:utang|hutang|ngutang)\s+(\d+(?:[.,]\d+)?)\s*(ribu|rb|jt|juta)?/i,
  // "catat utang bu sari 25000"
  /(?:catat|tulis|tambah)\s+(?:utang|hutang)\s+(.+?)\s+(\d+(?:[.,]\d+)?)/i,
  // "pak budi ngutang 15 ribu"
  /(\w+(?:\s+\w+)?)\s+ngutang\s+(\d+(?:[.,]\d+)?)\s*(ribu|rb|jt|juta)?/i,
  // "utang bu sari 50rb"
  /(?:utang|hutang)\s+(.+?)\s+(\d+(?:[.,]\d+)?)\s*(ribu|rb|jt|juta)?/i,
];

const settlePatterns = [
  /bayar\s+(?:utang|hutang)\s+(.+)/i,
  /(.+?)\s+(?:bayar|lunasi|lunas)\s+(?:utang|hutang)/i,
  /(.+?)\s+(?:sudah|udah)\s+bayar/i,
  /(?:utang|hutang)\s+(.+?)\s+(?:lunas|lunasi|sudah\s*dibayar)/i,
];

Four patterns for recording debt. Four patterns for settling debt. Each handles a different way Indonesians talk about money.

That instantly makes technical writing more grounded. The article stops sounding like AI generated filler and starts sounding like actual engineering notes from a real project.

Then Hermes handled publishing through the API. No browser tabs. No copy paste marathon. No formatting cleanup.

Just: "Publish this to Dev.to with these tags."

Done.

Thursday: VPS Management And Infrastructure Backups

Thursday was infrastructure maintenance.

My VPS runs Ubuntu 24.04 with SSH on port 22022. Before Hermes, I constantly forgot little operational details: which backup directory I changed, which cron schedule I updated, which SSH config belonged to which machine.

Those tiny memory leaks accumulate badly over months.

Hermes remembers them.

That sounds trivial until you realize how much engineering time disappears into remembering operational trivia.

One Thursday I needed to archive project backups, SCP them locally, rotate old snapshots, verify cron execution, and restart a monitoring service.

Hermes handled most of it conversationally.

I could literally say:

"Back up the current Warung MiMo deployment, compress logs, SCP to local machine, keep only seven daily snapshots."

Hermes created a tarball of my config, memories, SOUL file, and project files, then SCP'd it to my local machine through a non-standard SSH port. I did not tell it the port number. It remembered from a previous session.

/root/hermes-backup-20260526.tar.gz (7.8KB)
Contents: memories/, config.yaml, SOUL.md, auth/, channel_directory/
SCP'd to local:22022 ✓

That is where the agent stopped feeling like a chatbot. It started feeling like a lightweight operations engineer.

One of the monitoring scripts Hermes generated looked like this:

#!/bin/bash
# VPS health check - runs every 2 hours via cron

echo "=== Disk Usage ==="
df -h / | tail -1

echo "=== Memory ==="
free -h | grep Mem

echo "=== Uptime ==="
uptime

echo "=== Hermes Gateway ==="
pgrep -f "hermes-gateway" > /dev/null && echo "Running" || echo "DOWN"

echo "=== Warung MiMo ==="
curl -sf https://warung-mimo.vercel.app > /dev/null && echo "Live" || echo "DOWN"

Again, none of this is impossible manually. That is not the point. The point is reducing operational overhead so I can focus on actual product work.

Friday: Bug Bounty Tooling And Security Automation

Friday became security tooling day.

I started experimenting with bug bounty workflows and reconnaissance automation.

Normally setting up recon tooling is a tedious process: install Go dependencies, configure PATH, install nuclei, install subfinder, install httpx, create scanning scripts, configure rate limits, schedule recurring scans.

Hermes compressed most of this setup.

I asked it to prepare a lightweight recon environment for VPS scanning experiments. It generated install scripts, organized directories, and built wrapper commands for recurring scans.

# Quick scan a single URL
./quick-scan.sh https://target.com

# Full domain scan (subdomain enum + http probe + nuclei)
./bb-scan.sh target.com

Even better, Hermes remembered the structure later. So instead of "Where did I put that nuclei config?" I could ask "Run the standard recon workflow against yesterday's target list."

The memory layer changes everything.

A normal assistant answers isolated questions. An agent accumulates operational continuity over time.

Saturday: Researching And Drafting This Article

Saturday was meta because Hermes helped me research and draft this very article.

Not by hallucinating generic praise. Actually helping.

I asked it to analyze my real usage patterns, which workflows appeared repeatedly, which capabilities genuinely saved time, and which moments surprised me most.

Then I reviewed, edited, rewrote sections, added my own perspective, and expanded the practical details.

That collaboration felt very different from generic AI writing tools. It felt more like working with an operational memory system than a text generator.

The Agentic Capabilities That Actually Matter

People love using the word "agentic" now. Most of the time it means nothing.

These are the four capabilities that genuinely mattered for me.

1. Persistent Memory Across Sessions

This is the biggest one.

Hermes remembers my SSH port, VPS structure, preferred deployment flow, repo locations, writing style preferences, Dev.to publishing patterns, and toolchain setup.

The memory is stored in simple markdown files I can inspect and edit:

# USER.md
- Solo developer from Indonesia
- GitHub: iyop666
- Main project: Warung MiMo (Indonesian NLP parser)
- Prefers terminal + write_file over subagents
- Never use em dashes in output

# MEMORY.md
- VPS: Ubuntu 24.04, IP: 104.207.76.95, SSH port: 22022
- Warung MiMo deployed at warung-mimo.vercel.app
- Dev.to draft API: use api-key header
- Next.js + shadcn/ui preferred for demos

That persistence removes an enormous amount of repetitive setup conversation.

2. Cross Platform Orchestration

This is where Hermes becomes genuinely powerful.

Telegram becomes the interface. Hermes becomes the connector.

One workflow can touch Telegram, GitHub, VPS, Dev.to, Vercel, cron jobs, and APIs without breaking conversational continuity.

That orchestration layer feels much more valuable than isolated AI chat.

3. Autonomous Task Execution

Hermes can execute recurring operational work. Monitoring. Backups. Health checks. Cron tasks.

# Hermes cron job config
schedule: "every 2h"
script: ~/scripts/vps-health.sh
deliver: telegram

That matters because operational fatigue is real for solo developers. Every recurring task steals attention. Automating the boring maintenance layer gives me more room for actual product work.

4. Context Aware Code Assistance

This capability surprised me the most.

Hermes reads actual project files instead of generating generic advice detached from reality.

Instead of "Here is a generic regex example" it becomes "Your debt parser conflicts with this existing inventory matcher in parser.ts."

That level of project awareness is extremely useful when working on evolving codebases.

What Surprised Me Most

It Remembered Infrastructure Better Than I Did

One day I forgot which SSH port I migrated to months earlier. Hermes did not.

That sounds funny, but it exposed how much operational state developers carry mentally.

It Reduced Emotional Friction

This was unexpected. I thought the main benefit would be speed. Actually, the biggest benefit was reduced resistance.

Tasks felt smaller because orchestration overhead disappeared. "Deploying an update" stopped feeling like twelve tiny chores.

It Made Writing Easier

I expected coding help. I did not expect writing help to matter this much.

Because Hermes can pull real examples from real projects, technical writing became more grounded and less performative. That made me publish more consistently.

It Changed How I Structure Work

Before Hermes, I organized work around applications. Now I organize work around outcomes.

That sounds subtle but completely changes workflow design.

Before And After As A Solo Developer

Before:

Constant tab switching
Rebuilding context daily
Repetitive operational tasks
Infrastructure details scattered everywhere
Writing disconnected from actual code
Deployment flow fragmented

After:

Telegram became operational HQ
Persistent memory reduced repetition
Infrastructure became conversational
Deployments became continuous workflows
Writing connected directly to repositories
Operational overhead dropped dramatically

This is not a productivity hack. That framing undersells what agents can become.

For me, this was a structural change in how work gets coordinated.

The interesting part is not replacing developers. The interesting part is reducing orchestration burden so developers can stay inside higher value thinking longer.

The Bigger Thing I Learned

Building Warung MiMo taught me something important about language.

Using Hermes taught me something important about context.

Language without context becomes brittle. Context without continuity becomes exhausting.

That is why Hermes worked for me. Not because it produced magical AI moments. Because it maintained continuity across coding, infrastructure, writing, deployment, and research.

That continuity is what solo developers usually lack.

And once you experience it, going back feels strangely primitive.

How I Built an Indonesian NLP Parser That Understands Warung Owners, Then Abandoned It

semi — Wed, 27 May 2026 04:40:24 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Warung MiMo is an AI-powered assistant for small warungs (Indonesian street shops). It lets shop owners manage inventory, track debts, and log sales using natural Indonesian, either by voice, text, or receipt scanning.

The project started from a simple question: what if a tiny shop owner could talk to software the same way they talk to their helper? Not with menus, not with spreadsheets, just with the way people actually speak in a warung.

I built the first version during the MiMo Orbit 100T Token Grant. The UI was there. The tech stack was solid. But the core engine, the Indonesian NLP parser, was not finished. The project sat abandoned until the GitHub Finish-Up-A-Thon Challenge gave me the push to revive it.

Tech stack: Next.js 16, React 19, shadcn/ui, Tailwind 4, TypeScript. Deployed on Vercel.

Demo

Live: https://warung-mimo.vercel.app

Source: https://github.com/iyop666/warung-mimo

Try these inputs in the assistant page:

"Indomie tinggal lima bungkus"
"Aqua habis, gula sisa setengah kg"
"Bu Sari utang empat puluh dua ribu"
"bayar utang Bu Sari"
"Catat utang Pak Budi 50rb, terus telur tinggal tiga"
"Teh Botol kosong, kopi sisa dua belas sachet"

The assistant parses each sentence, identifies products, extracts numbers (even written as Indonesian words), and generates structured actions like stock updates or debt records.

The Comeback Story

Before:
The original Warung MiMo had a working UI, a product catalog, and a basic input field. But the NLP engine was shallow. It could handle simple commands like "Indomie 5" but failed on real Indonesian sentences like "empat puluh dua ribu" or "setengah dus" or "sisa tiga". The project was stuck in that painful zone where a repo exists but the product does not feel finished enough to trust.

What I changed, fixed, and added:

Indonesian Number Parser. Built from scratch with 30+ number words, compound logic ("empat puluh dua" = 42), and colloquial shortcuts ("42rb", "setengah", "seperempat").
Product Matching. 8 core warung products with 30+ aliases. "Aqua" maps to "Aqua 600ml". "Mie goreng" maps to "Indomie Goreng". Longest keyword match prevents false positives.
Stock Context Parsing. 5 regex patterns for the same concept: "habis", "tinggal N", "sisa N", "stok N", "kosong". Because in real Indonesian, there are at least five ways to say "I have three left".
Multi-Action Splitting. One sentence can contain a debt, a stock update, and a restock order. The parser splits by commas, "dan", "terus", "lalu", "juga", then processes each segment independently.
Debt Tracking. 4 regex patterns for recording debt, 4 for settling. Each handles a different way Indonesians talk about money: "bu sari utang 25 ribu", "catat utang bu sari 25000", "pak budi ngutang 15 ribu".
Weekly Insights Engine. Generates contextual business suggestions based on sales data, like: "Minggu ini cuaca panas, penjualan minuman naik signifikan (+25%). Fokus restok minuman."

After:
~2,500 lines of TypeScript across 15 React components. 50+ regex patterns in the NLP engine. 30+ number word mappings. 8 products with 3-4 aliases each. Deployed and live at warung-mimo.vercel.app.

My Experience with GitHub Copilot

GitHub Copilot did not build the project for me. But it helped me move faster in three specific areas:

Regex iteration. When building the debt patterns and stock context parser, I would type a comment like // match 'bayar utang bu sari' and Copilot would suggest the regex pattern. I still verified and adjusted, but it cut iteration time in half.
Edge case handling. When testing "42rb" vs "empat puluh dua ribu" vs "42.000", Copilot suggested the fallback digit parser that handles all three formats.
Template generation. For the weekly insights engine, I described the goal and Copilot suggested the template system that produces contextual Indonesian business suggestions.

The biggest help was reducing the friction between "I know what I want" and "I have written the code." I still had to think hard about the language logic. Copilot just made the typing part faster.