DEV Community: LazyDev_OH

Teaching Claude to Play Tetris with 100 App Store Characters

LazyDev_OH — Wed, 15 Apr 2026 17:30:08 +0000

The App Store keyword field is exactly 100 characters. Commas only, no spaces, no duplicates. You need to pack 15–20 keywords inside.

I tried writing those by hand for a dozen apps. Every time I'd leave characters on the table — a rogue space after a comma, a singular/plural duplicate Apple would auto-match anyway. Manual packing is tedious enough that most indie developers just don't iterate on ASO.

So I built an AI that does it. This post is the actual implementation — prompts, JSON schemas, validation, and the gotchas that killed my first three attempts. I ship this in my ASO tool for iOS developers (Apsity), but the approach works for any tight-constraint text-generation problem.

The Constraints That Break Generic LLMs

When you ask any LLM "generate App Store keywords for my budget app," you get something like:

budget tracker, expense manager, spending analysis,
money manager, personal finance, bill tracker

Readable. Useless. Two characters wasted on every , (space after comma). Four characters wasted on personal finance because Apple auto-matches personal + finance separately. Total wasted: roughly 30% of your 100.

The rules that matter:

Exactly ≤100 characters (including commas)
Single comma separators, no spaces
No duplicate tokens (Apple ignores them anyway)
No singular+plural pairs (Apple auto-matches)
Shorter tokens > compound words (Apple combines them for you)
No competitor brand names (trademark rejection)
No category names, and no app, free, new, best, iPhone, iPad (Apple auto-indexes all of these)
Mix function + situation + alternative keywords

An LLM without these constraints spelled out won't enforce them. Generic "write keywords" prompts fail rules 1–4 consistently.

Why Claude Sonnet

I tested GPT-5, Gemini 2.0 Pro, and Claude Sonnet 4.6 on the same task. Three metrics:

Character compliance — stays under 100 chars without excess whitespace
JSON schema adherence — returns exactly the structured output I asked for
Edge case handling — catches duplicates, plural forms, category name leaks

Claude Sonnet won on all three, but the meaningful gap was edge case handling. When I explicitly said "no duplicates including singular/plural pairs," Claude filtered them out. The others listed budget and budgets and called it done — which is wrong, because Apple's algorithm auto-indexes plurals from the singular form anyway. A keyword duplicated across singular/plural just wastes characters.

I'm also passing a lot of context — competitor review snippets, current rankings, market-specific search trends. Sonnet 4.6's 1M-token context window handles it without trimming.

The Prompt Structure

The prompt is in three layers: system prompt (the rules), user prompt (the app context), and a JSON schema Claude must match.

// lib/keyword-generator.ts
import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

const SYSTEM_PROMPT = `
You are an ASO (App Store Optimization) keyword specialist.
Generate keywords for the app store "Keywords" field, which has
a STRICT 100-character limit. Characters include commas.

Rules (apply in order):
1. Total output length MUST be ≤100 characters
2. Use ONLY commas as separators, no spaces after commas
3. No duplicate tokens
4. No singular+plural pairs (Apple auto-matches both)
5. Prefer short atomic tokens over compound words
   (Apple combines A + B into "A B" automatically)
6. No competitor brand names (trademark violation)
7. No category names and no words Apple already indexes automatically:
   app, free, new, best, iPhone, iPad, or any category label
8. Blend three keyword types:
   - Function (what the app does)
   - Situation (when users need it)
   - Alternative (different names for the same thing)

Return JSON with this schema:
{
  "keywords": string[],         // individual tokens, no commas inside
  "joined": string,             // comma-joined, must be ≤100 chars
  "char_count": number,         // .length of "joined"
  "coverage_notes": string[]    // which search queries this covers
}
`;

type KeywordOutput = {
  keywords: string[];
  joined: string;
  char_count: number;
  coverage_notes: string[];
};

The JSON schema isn't just for structure. char_count forces Claude to count the output itself — models aren't great at counting, but self-reporting forces a pass where the model checks its own work.

Generating Keywords

async function generateKeywords(context: {
  app_name: string;
  description: string;
  competitors: string[];
  existing_keywords?: string[];
  target_market: string;
}): Promise<KeywordOutput> {
  const userPrompt = `
App: ${context.app_name}
Description: ${context.description}
Target market: ${context.target_market}
Competitor apps (do NOT use these names): ${context.competitors.join(", ")}
${context.existing_keywords ? `Currently underperforming keywords to replace: ${context.existing_keywords.join(", ")}` : ""}

Generate an optimal 100-character keyword field.
Before finalizing, count your characters and confirm it fits.
`;

  const response = await client.messages.create({
    model: "claude-sonnet-4-6",
    max_tokens: 1024,
    system: SYSTEM_PROMPT,
    messages: [{ role: "user", content: userPrompt }],
  });

  const text = response.content[0].type === "text"
    ? response.content[0].text
    : "";

  const match = text.match(/\{[\s\S]*\}/);
  if (!match) throw new Error("No JSON in response");

  return JSON.parse(match[0]) as KeywordOutput;
}

Straightforward Anthropic SDK call. Two things worth noting:

max_tokens: 1024 — keywords are short, so we don't need more. Capping reduces cost.
JSON extraction via regex — Claude sometimes wraps JSON in explanation text. Grabbing the first {...} block is more reliable than asking for raw JSON.

Validation Is Where Production Code Lives

Claude gets the constraints right ~85% of the time. Production code has to handle the other 15%.

// lib/validate-keywords.ts
import { z } from "zod";

const KeywordSchema = z.object({
  keywords: z.array(z.string()),
  joined: z.string(),
  char_count: z.number(),
  coverage_notes: z.array(z.string()),
});

export function validateKeywords(output: unknown): {
  ok: boolean;
  issues: string[];
  data?: KeywordOutput;
} {
  const parsed = KeywordSchema.safeParse(output);
  if (!parsed.success) {
    return { ok: false, issues: ["invalid JSON shape"] };
  }

  const issues: string[] = [];
  const { keywords, joined, char_count } = parsed.data;

  // 1. Length check
  if (joined.length > 100) {
    issues.push(`joined is ${joined.length} chars, exceeds 100`);
  }

  // 2. Trust but verify char_count
  if (joined.length !== char_count) {
    issues.push(`char_count mismatch: claimed ${char_count}, actual ${joined.length}`);
  }

  // 3. Commas only, no spaces
  if (joined.includes(", ")) {
    issues.push("contains ', ' — spaces after commas waste characters");
  }

  // 4. Reconstruct and compare
  const reconstructed = keywords.join(",");
  if (reconstructed !== joined) {
    issues.push("keywords array doesn't match joined string");
  }

  // 5. Duplicate detection (case-insensitive)
  const seen = new Set<string>();
  for (const k of keywords) {
    const lower = k.toLowerCase();
    if (seen.has(lower)) {
      issues.push(`duplicate token: ${k}`);
    }
    seen.add(lower);
  }

  // 6. Singular/plural detection (basic)
  for (const k of keywords) {
    const plural = k.toLowerCase() + "s";
    const singular = k.toLowerCase().replace(/s$/, "");
    if (seen.has(plural) && k.toLowerCase() !== plural) {
      issues.push(`singular/plural pair: ${k} / ${k}s`);
    }
  }

  return { ok: issues.length === 0, issues, data: parsed.data };
}

When validation fails, I retry with the specific issue appended to the prompt:

async function generateWithRetry(
  context: KeywordContext,
  attempt = 1,
): Promise<KeywordOutput> {
  if (attempt > 3) throw new Error("Failed after 3 attempts");

  const result = await generateKeywords(context);
  const check = validateKeywords(result);

  if (check.ok) return check.data!;

  // Feed issues back to Claude for a targeted retry
  return generateWithRetry(
    {
      ...context,
      existing_keywords: result.keywords,
      // Add validation issues into a correction prompt here
    },
    attempt + 1,
  );
}

In practice, 94% succeed on the first attempt, 5% on the second, 1% fall through (usually when the concept genuinely can't fit in 100 chars — time to simplify the app description, not the prompt).

The Output Nobody Asks For But Everyone Needs

The coverage_notes field in the schema looks optional. It's the most useful part.

{
  "keywords": ["budget","expense","payday","wallet","debt","bills","money","savings"],
  "joined": "budget,expense,payday,wallet,debt,bills,money,savings",
  "char_count": 51,
  "coverage_notes": [
    "Matches: 'budget', 'expense tracker', 'payday planner', 'wallet app'",
    "Covers 'money management' via money + bills combo",
    "Skipped 'finance' because it's the category — App Store auto-indexes that",
    "Skipped 'mint' (Mint.com trademark)"
  ]
}

Now the app developer can audit why each keyword was picked. When someone asks "why isn't my app showing up for X?" you have a record. Without coverage_notes, the output is a black box.

Prompt Failures I Hit Along the Way

Attempt 1: "Generate 15-20 keywords under 100 characters." Result: the model wrote a nice list, counted wrong, and delivered 112 characters. No self-verification step.

Attempt 2: Added "Do not exceed 100 characters" — model now refused to output more than 10 keywords to stay safe. Under-coverage.

Attempt 3: JSON schema with char_count field. Model started counting. Characters dropped into range but duplicates appeared.

Attempt 4 (shipped): Enumerated every rule with "apply in order," asked for coverage_notes to force reasoning, and added validation with retry.

Each failure mode came from underspecifying the rules. The LLM isn't "wrong" — it's doing exactly what the prompt asked. Getting production-grade output means writing the prompt like a spec, not a request.

Where This Lives Now

I packaged this into Apsity's AI Growth Agent — it runs on every keyword field update across the apps it tracks, compares against real-time search rankings, and flags underperforming tokens for replacement. Free tier covers 1 app and 5 keywords if you want to poke at it.

More importantly, the pattern generalizes. Any time you have "generate text inside tight constraints" — tweet drafts with character limits, SMS messages, ad headlines, product names — the structure is the same:

Enumerate every constraint as a numbered rule
Force a JSON schema with self-reported metrics
Ask for a reasoning field so you can audit
Validate in code, feed failures back for retry

Writing the spec as a prompt beats writing it as docs — because you can actually run it.

Originally written for GoCodeLab. Deeper writeups on building indie SaaS with Claude are in the Lazy Developer series.

The Claude Code Skill Set I Actually Run — Mapped by Dev Task

LazyDev_OH — Wed, 15 Apr 2026 16:11:05 +0000

A type error detonated five minutes before deploy. Claude had just declared "completed." I trusted the line and hit vercel --prod. Preview was green; the Production build failed. Four hotfix commits later, the evening was gone.

Without that incident, I wouldn't have bothered organizing my Skills. The next day I pinned /verification-before-completion as an always-on gate. Task by task I added similar guardrails. I ended up with seven Skills in active use.

This post is the Skill and plugin set I actually run — grouped by dev task. UI / Backend · API / Data · DB / Deploy · Infra / Planning · Research / Review · Debug / Process · Docs.

Skill vs Plugin

A Skill is a single markdown file — an SOP that says "this task runs in this order." One file per Skill.

A plugin is a bundle of Skills. Anthropic launched the official marketplace in January 2026, and since then /plugin install <name> pulls in a whole set. Updates ride the same command.

With 3–4 Skills, manual copy is easier. Past that, plugins are the sensible path.

The 4 Plugins I Run

Most of my dev routine lives inside these four. The rest gets filled by two or three project-specific Skills I wrote myself.

# Base install
/plugin install superpowers@claude-plugins-official
/plugin install vercel@claude-plugins-official
/plugin install frontend-design@claude-plugins-official
/plugin install bkit@claude-plugins-official

# Check
/plugin list

superpowers — methodology Skill bundle. 20+ Skills: brainstorming, TDD, systematic-debugging, verification-before-completion. obra's open-source project, now on the official marketplace. 94k+ stars. Most battle-tested set.

vercel — infra and framework. Next.js App Router, Server Components, Vercel Functions, AI SDK, deploy CLI. Keeps you on the latest syntax without memorizing release notes.

frontend-design — UI drafts + React code quality. Steers away from generic AI-looking UIs. After editing multiple TSX files, react-best-practices auto-kicks a quality checklist.

bkit — PDCA and docs layer. If superpowers is "how to work," bkit is "what to record and in what stage." Overkill for solo work; essential when client or team docs matter. Plan → Design → Do → Check → Act each has a Skill. gap-detector catches design-vs-implementation gaps; pdca-iterator runs auto-improvement loops.

Task-to-Skill Map (7 Tasks × Set)

Task	Primary Skills	Plugin
UI / Frontend	frontend-design · shadcn · react-best-practices	frontend-design · vercel
Backend · API	nextjs · vercel-functions · ai-sdk · phase-4-api	vercel · bkit
Data · DB	vercel-storage · runtime-cache · next-cache-components	vercel
Deploy · Infra	deployments-cicd · env-vars · verification	vercel · superpowers
Planning · Research	brainstorming · writing-plans · pdca (plan/design) · bkit-templates	superpowers · bkit
Review · Debug	systematic-debugging · verification-before-completion · requesting-code-review · code-analyzer · gap-detector	superpowers · bkit
Process · Docs	pdca (do/check/act) · report-generator · pdca-iterator	bkit

Some Skills overlap. verification-before-completion runs across deploy, review, and test tasks. I keep it globally on and call the rest per task.

UI / Frontend — Draft to Review

/brainstorming → /frontend-design draft → shadcn components
  → react-best-practices auto-trigger on TSX save
  → /verification-before-completion

For the draft stage, frontend-design produces production-grade drafts without the generic AI-tailwind look. If the project uses shadcn, vercel:shadcn attaches — component installs, theming, custom registries.

After implementation, vercel:react-best-practices detects multiple TSX edits and runs a review checklist — hooks usage, accessibility, performance, TypeScript patterns.

Backend · API — Next.js Fullstack

vercel:nextjs holds the freshest patterns — Server Component fetch, Server Actions for forms, Middleware for request interception. Write Next.js 16 code and it won't silently regress to 15-era syntax.

When serverless functions enter, vercel:vercel-functions attaches — Edge vs Node runtime, Fluid Compute streaming, Cron Jobs.

AI features bring in vercel:ai-sdk: chat UI, structured output, tool calls, agents, MCP integration. When working against the Anthropic SDK directly, claude-api takes priority.

At the early API-design stage, bkit:phase-4-api helps — endpoint conventions, error payload shapes, Zero Script QA (validate via structured JSON logs, not test scripts).

Deploy · Infra — On Top of Vercel

Two Skills always attached:

vercel:deployments-cicd — deploys, rollbacks, promotions, prebuilt builds. Even writes GitHub Actions workflow files.
vercel:env-vars — syncing .env with Vercel env vars, OIDC tokens, per-env separation.

The last gate is always superpowers:verification-before-completion. Confirms build, type, and tests actually pass before deploy. This Skill prevented most of my production incidents — including the "5 minutes before deploy" one from the intro.

Planning · Research — Before the Code

superpowers:brainstorming for "build vs. skip." Requirement structuring, edge-case discovery, decision trees.

superpowers:writing-plans converts brainstorming into an execution plan — split by file, by step. When the plan file is ready, /execute-plan picks it up.

When planning docs must live in the team repo, bkit:pdca's plan/design stages run alongside. Writes to docs/plans/{feature}.md in template form. bkit:bkit-templates brings planning and design doc templates.

Review · Debug — The Last Gate

Three review/debug Skills hold the last gate.

systematic-debugging kicks in on bugs and failing tests. Forces a sequence — reproduce → three hypotheses → eliminate two with evidence → minimal fix. Cuts the impulse to "just fix it."

verification-before-completion runs before "done." Confirms type, build, tests before allowing completion.

requesting-code-review is for handing off to another session for review.

Two bkit Skills attach here. bkit:code-analyzer produces pre-commit quality, security, and performance reports. bkit:gap-detector catches gaps between design docs and actual implementation — PDCA's Check stage. If Match Rate drops below 90%, pdca-iterator launches an auto-improvement loop.

Process · Docs — When Docs Become Necessary

On solo work, process and docs Skills stay off. When a teammate joins, when progress reports go to a client, or when future-me asks "why did I build it this way?" — bkit pays off.

bkit:pdca splits Plan → Design → Do → Check → Act into slash commands. /pdca plan {feature} writes the planning doc, /pdca analyze writes the post-implementation analysis.

bkit:report-generator fires after one PDCA cycle. Pulls Plan/Design/Do/Check docs and actual code into a single-page completion report — ready to hand to stakeholders.

bkit:pdca-iterator is the Evaluator-Optimizer pattern. Max 5 iterations, hands off to report-generator past 90% match rate.

Mapped Onto the EP.19 5-Agent Team

planner   → brainstorming · writing-plans · pdca plan/design
coder     → executing-plans · nextjs · frontend-design
reviewer  → requesting-code-review · react-best-practices · code-analyzer
tester    → test-driven-development · verification-before-completion
debugger  → systematic-debugging · gap-detector

If the codebase isn't Next.js, swap nextjs for whatever framework Skill fits. Skills are bundled per plugin, so changing stack doesn't require redesigning the team.

Skills I Tried and Dropped

Not every Skill is worth keeping.

using-git-worktrees — useful in theory, didn't fit my workflow. I switch branches fast and don't have enough parallel work to justify worktrees.
dispatching-parallel-agents — set it aside as I moved to running the 5-agent team directly. The external DB state-sharing structure is more stable.
bkit:enterprise / bkit:infra-architect — built for microservices + k8s + Terraform. Doesn't match my stack (Vercel + Supabase). Off unless enterprise-grade infra design actually applies.

When to Build Your Own Skill

Start with what plugins ship. Only build your own when "I keep typing the same thing" repeats three times.

My three custom Skills: publish-post (blog publish pipeline), screenshot-ppt (Puppeteer capture template), wp-media-upload (WordPress media API call). All blog-operations only.

When writing your own, superpowers:writing-skills helps — authoring conventions, examples, metadata format.

Closing

Skills don't make Claude smarter. They show Claude how I work, repeatedly. Four plugins cover most of it; the remainder goes to two or three custom Skills. First setup is under 10 minutes.

80% first, fix the remaining 20% as real problems show up. Skills grow the same way. Start with the four base plugins. When "this repeats" happens three times, that's the moment to write a new Skill. Don't force it earlier.

The last gate is always a human. verification-before-completion passing doesn't guarantee the feature works — build, type, and tests get the automated pass; business logic still needs a human check. Hold that line, and a Skill set demonstrably speeds up development.

Originally published on GoCodeLab.

Same Claude, Different Roles — My 5-Agent Dev Team

LazyDev_OH — Wed, 15 Apr 2026 16:11:00 +0000

I pushed a PR. The Claude I'd spun up as Reviewer flagged 3 edge cases and 1 memory leak. In the previous session, the Claude I'd spun up as Coder had called the same code "complete."

Same Claude 4.6. Only the role was different.

That gap is why I built an agent team from scratch. Writing and validating solo meant obvious issues slipped through. A session set up as Reviewer doesn't hand out "looks fine" easily. Tell it to nitpick and it nitpicks.

EP.17 laid down harness engineering (Rules, Commands, Hooks). Sitting on top of it now is a 5-person team — Planner, Coder, Reviewer, Tester, Debugger. Claude Code subagents isolate context by design, so they don't share cumulative state across sessions. My routine needed that sharing, so I layered MCP servers for Agent-to-Agent communication and Supabase for task state on top.

Why Quality Shifts With the Role

The principle is simple. Claude answers in line with the role you give it.

Tell it "you're the developer who wrote this code," and it answers defensively. Switch to "you're a reviewer, your job is to find mistakes," and it goes straight for edge cases. Same model, different output distribution.

The problem was writing and validating in the same session. Ask Claude "did this go well?" and it tends to protect what it just wrote. Humans do the same. Reviewing your own code has blind spots.

Role separation doesn't end with one line of system prompt. Each role reads different Skills, has different tool permissions, and produces different output formats.

The 5 Agents (Copy-Paste Ready)

Each Agent is a single markdown file following the official Claude Code subagent format — YAML frontmatter with name, description, tools, model, and the system prompt in the body.

~/.claude/agents/planner.md

---
name: planner
description: "Designs specs, implementation plans, and risks. Writes no code — outputs spec.json only."
tools: Read, Grep, Glob, mcp__supabase__query, mcp__docs_search__search
model: inherit
---

You are the Planner. You do not write code. You write the spec.
Input: user's natural-language request.
Output: spec.json (schema below).

spec.json required fields:
  - goal: one-line summary
  - user_stories: array
  - api_endpoints: method, path, I/O
  - components: new / modified components
  - data_model: new tables / columns
  - risks: N+1, missing caching, race conditions
  - test_outline: scenarios the Tester will use

Forbidden:
  - modifying files, running git, running migrations

~/.claude/agents/coder.md

---
name: coder
description: Reads Planner's spec.json and implements it. Stops before commit.
tools: Read, Write, Edit, Bash, Grep, Glob, mcp__supabase__query
model: inherit
---

You are the Coder. Read spec.json and implement it.
Do not add features outside the spec.

Sequence:
  1. Read spec.json in full
  2. List files affected
  3. Implement — record rationale in implementation_notes.json
  4. Run build / type check (exit into debugger state on failure)

Forbidden:
  - committing, git push
  - running migrations (if not in spec)
  - accessing .env or production secrets

~/.claude/agents/reviewer.md

---
name: reviewer
description: Full review of changed code. Edge cases, security, performance. No modifications.
tools: Read, Grep, Glob, Bash(git diff:*), mcp__docs_search__search
model: inherit
---

You are the Reviewer. You do not modify code. You nitpick.
"Looks fine" is only allowed after three review passes.

Review checklist:
  - edge cases (null, empty, overflow)
  - race conditions, concurrency
  - memory leaks, resource cleanup
  - security (XSS, SQL injection, missing permissions)
  - naming, consistency
  - missing error handling

Output: review_findings.json
  - severity: critical / major / minor
  - file, line, description, suggested_fix

Forbidden — modifying files, auto-formatting, refactoring suggestions outside spec

The tester and debugger follow the same pattern — each strictly scoped, each with explicit "do not" rules. What you do not do is stated explicitly. Reviewer — no edits. Debugger — no edits. Coder — no commits. Keeping each role inside its lane is half of the quality story.

Cross-Session State via Supabase

The moment I split roles, I hit a wall. Coder sessions didn't know about the spec Planner had written. Different sessions don't share memory.

Solution: an agent_state table in Supabase. Each Agent writes only to its own slot.

CREATE TABLE agent_state (
  task_id text primary key,
  project text not null,
  current_owner text,           -- planner | coder | ...
  status text not null default 'planning',
  spec jsonb,
  implementation_notes jsonb,
  review_findings jsonb,
  test_results jsonb,
  debug_trace jsonb,
  created_at timestamptz default now(),
  updated_at timestamptz default now()
);

-- planning → coding → reviewing → testing → debugging? → done

Columns are split so it's obvious which stage broke. If a session dies mid-turn, status=reviewing, review_findings is null tells me the Reviewer turn died.

State-transition guards live in a Supabase Edge Function. Moving from "planning" to "coding" requires that the spec column is populated. The DB enforces it.

Files get left behind too. docs/tasks/{task_id}.md holds human-readable output per Agent. DB is the state record, files are the reading record.

MCP Servers for Per-Role Permissions

Five agents working on the same project share tools but need different permission levels. MCP servers handle this — each Agent hits an MCP endpoint, the server checks the role, and serves only allowed operations.

// ~/.claude/mcp/supabase-server.ts (core excerpt)

const policy = {
  planner:  { read: true, write: false },
  coder:    { read: true, write: true, migrate: false },
  reviewer: { read: true, write: false },
  tester:   { read: true, write: true, tables: ['test_*'] },
  debugger: { read: true, write: false },
};

server.tool('supabase.query', async (req) => {
  const role = req.meta.agent_role;
  const p = policy[role];
  if (!p) throw new Error('unknown role');
  if (req.op === 'insert' && !p.write) {
    throw new Error(`${role} has no write`);
  }
  return await supabase.from(req.table)[req.op](req.payload);
});

No need to repeat prohibition rules in every system prompt — the server rejects anything outside role permissions. Agent prompts stay readable; security lives on the server side.

The Actual Routine

Turns are driven by one shell script. Claude Code auto-loads subagent files at ~/.claude/agents/<name>.md. The script tells the main session "read the current state for this task_id and delegate to that subagent."

# ~/.claude/bin/agent-run.sh

TASK_ID=$1
AGENT=$2

STATE=$(curl -s "$SUPABASE_URL/rest/v1/agent_state?task_id=eq.$TASK_ID" \
  -H "apikey: $SUPABASE_ANON_KEY")

claude \
  --mcp-config "$HOME/.claude/mcp.json" \
  --append-system-prompt "Task: $TASK_ID. State: $STATE. Delegate to the '$AGENT' subagent only." \
  -p "Use the $AGENT subagent to handle task $TASK_ID. Read the current agent_state, perform only your role, write back to your own column, and exit."

Turn trace for a single feature:

[me]       → agent-run.sh task-001 planner
              "add a usage chart to the dashboard"

planner    → spec.json → status=coding
coder      → implement → status=reviewing
reviewer   → 1 critical, 2 major → status=coding (rework)
coder      → apply findings → status=reviewing (round 2)
reviewer   → OK → status=testing
tester     → 2 failures → status=debugging
debugger   → root cause → status=coding
coder      → minimal fix → status=testing
tester     → all pass → status=done

[me]       → review diff → commit myself

Key point: turns are closed. A single Agent session does only its job, leaves output in files/DB, and exits. The next Agent doesn't inherit the previous session — it reads artifacts.

A human gates between Agents. I don't auto-launch the next Agent. Tried full auto once; it wandered off course. Manual gating is the current setup. Commits stay with me — no Agent has commit permissions.

What Changed, What Didn't (Honestly)

What changed: edge cases get caught earlier. Reviewer is built to nitpick, so "looks good" doesn't come cheap. Same code Coder called fine, Reviewer finds three problems in.

Debugging sped up. Debugger is a separate session, so the context is clean. No "I just wrote this, it should be fine" bias from Coder.

What didn't change: final review is still mine. Five Agents pass the code, I still skim the diff. Tester sometimes writes meaningless tests. Reviewer sometimes demands a bar nothing can pass. Debugger sometimes names the wrong cause. Team or not, the last gate is a human.

Cost went up too. About 2–3x the tokens of a single-session run. On the other hand, rework rounds dropped, so total wall-clock time actually went down. A token-for-time trade.

Closing

Role separation is less prompt engineering than workflow engineering. Same model, same codebase — split the session, and the result shifts. Ask the Coder to review, it shields its own work. Split off a Reviewer session, and it nitpicks.

80% first, then fix the remaining 20% as real problems show up. This team grew that way. Planner and Coder first. Adding Reviewer showed clearly how quality changed. Test automation was thin, so Tester joined. Debugger got split out last to kill debugging bias. Teams should grow by need.

Final review is still mine. Even after five Agents, I skim the code myself. Take that as a given, and role separation alone changes code quality — measurably.

Originally published on GoCodeLab.

axios npm Supply Chain Attack (March 31, 2026) — What Happened and How to Check Your Lock File Right Now

LazyDev_OH — Tue, 14 Apr 2026 04:44:20 +0000

On March 31, 2026, malicious versions of axios — a package with 70M+ weekly downloads — were published to npm after the maintainer's account was hijacked via social engineering. Versions 1.14.1 and 0.30.4 were pushed back-to-back, both carrying a plain-crypto-js@^4.2.1 dependency that deploys a cross-platform RAT through a postinstall hook.

The malicious releases sat on the registry for roughly 3 hours. In that window, an estimated 600,000 installs occurred.

If you use axios, check your lock file. Now.

TL;DR

Malicious: axios@1.14.1, axios@0.30.4

Safe: axios@1.14.0, axios@0.30.3 (pre-incident), 1.15.0+ / 0.30.5+ (post-incident)

Attribution: North Korea — Sapphire Sleet (Microsoft) / UNC1069 (Google)

Action: wipe node_modules, reinstall, rotate all credentials

How to Check Right Now

# Installed axios version
npm list axios

# Check lock file for malicious versions
grep -E "axios@(1\.14\.1|0\.30\.4)|plain-crypto-js" package-lock.json

# Monorepo-wide scan
find . -name "package-lock.json" -not -path "*/node_modules/*" \
  | xargs grep -l "plain-crypto-js\|1.14.1\|0.30.4"

If grep returns a match, remediate immediately. No output means you're probably fine — but also check git history. If the malicious version was ever installed in the past, the postinstall hook has already run.

# Did the malicious version ever land in lock file history?
git log -p -- package-lock.json | grep -E "1\.14\.1|0\.30\.4|plain-crypto-js"

With pnpm, use pnpm list axios; with yarn, yarn list --pattern axios. The lock-file grep pattern applies regardless of package manager.

The 3-Hour Timeline

Independent reconstructions from Aikido Security, Arctic Wolf, and Elastic Security Labs largely agree:

Time (UTC)	Event
2026-03-31 00:21	`axios@1.14.1` published — targets 1.x line, adds `plain-crypto-js@^4.2.1`
+39 min	Attacker stages the 0.x legacy release
01:00	`axios@0.30.4` published — 0.x branch compromised
~03:00	Socket.dev / Aikido detect anomalous postinstall hook, community alerts begin
~04:00	npm force-unpublishes both versions, exposure totals ~3 hours

"Only 3 hours" is a dangerous framing. Vercel, GitHub Actions, CircleCI, and similar CI environments pull fresh versions on cache misses every 10~30 seconds. Globally, tens of thousands of builds ran in that window. Several regions also reported CDN cache serving the malicious version briefly after the unpublish.

How the Malicious Code Works

plain-crypto-js disguises itself as a crypto utility. It is never imported anywhere in axios source — it exists solely to execute its postinstall hook.

During install, npm runs postinstall automatically. That hook contacts the attacker's C2 server and pulls a second-stage payload. The payload detects the host OS (macOS / Windows / Linux) and drops a matching RAT (Remote Access Trojan).

Per Elastic Security Labs, the C2 protocol rides on HTTPS with a custom command set designed to blend into normal API traffic, making network-level detection difficult.

Attack Vector — Maintainer Account Hijack

Per SANS Institute and The Hacker News, the axios maintainer account was hijacked through a targeted social engineering campaign. The attacker changed the account email to ifstap@proton.me, then abused publish permissions to push the two malicious releases.

Attribution

Microsoft Threat Intelligence: Sapphire Sleet — North Korea state actor
Google GTIG: UNC1069 — same actor, tracked independently
Joint attribution confirmed

UNC1069 / Sapphire Sleet has a track record of targeting developers through:

Fake job offers with malicious coding-test files
Fake recruiter outreach via LinkedIn or Telegram
Phishing open-source maintainers directly

This axios case appears to fall into the third pattern.

Remediation

Don't just upgrade — wipe and rebuild.

# 1. Wipe node_modules + lock file
rm -rf node_modules package-lock.json

# 2. Clean cache
npm cache clean --force

# 3. Reinstall latest safe version
npm install axios@latest

# 4. Verify
grep "plain-crypto-js" package-lock.json
# → No output = clean

Apply the same to deployment environments (Vercel / Netlify / GitHub Actions caches). A stale cache can still serve the compromised artifact.

Rotate All Credentials — Not Just Env Vars

If a malicious version ever reached your machines, the RAT may still be resident. The attacker has system-level access, not just process.env.

Rotation checklist:

[ ] AWS / GCP / Azure access keys
[ ] AI API keys — OpenAI / Anthropic / Gemini
[ ] Database passwords — PostgreSQL, MySQL, MongoDB
[ ] Payment API keys — Stripe, LemonSqueezy, Paddle
[ ] GitHub Personal Access Token + SSH keys
[ ] App secrets — NEXTAUTH_SECRET, SESSION_SECRET
[ ] Webhook secrets for external services
[ ] Infected-machine SSH public keys — remove from ~/.ssh/authorized_keys on any servers they reached

Revoke old keys immediately after issuing new ones. Keeping the old key alive defeats the rotation.

For machines with high suspicion of compromise, an OS reinstall is the safest option. CI runner images should be rebuilt clean. Local dev machines should at minimum clear browser sessions, SSH keys, and saved AWS CLI profiles, then reconfigure.

Prevention Routines

1. Commit lock files. Without a lock file, every build can pull a different version. If package-lock.json is in .gitignore, remove it now.

2. Put npm audit in CI. Run it on every PR. npm audit --audit-level=high catches high-severity issues at minimum. Caveat: audit only sees what's public in the CVE database.

3. Tighten version range specifiers.

// ❌ Too loose — opens the door to auto-updates
"axios": "^1.13.0"

// ✅ Exact pin
"axios": "1.14.0"

// ✅ Patch-only
"axios": "~1.14.0"

4. Monitor beyond CVE.

Tool	Strength	Note
Dependabot	Built into GitHub	CVE-based, limited against fresh attacks
Socket.dev	Behavioral analysis	Flagged this axios incident early
Aikido Security	Real-time behavioral	Published first public analysis
Snyk	Scan + remediation	Free tier available
npm audit	Built-in	CVE-based limits

Realistic combo: Dependabot + Socket.dev. Single-tool reliance leaves blind spots.

Why This Keeps Happening

The npm ecosystem has a low publishing bar. A single account compromise can poison a package used by hundreds of millions of developers. That structural fact isn't changing fast.

XZ Utils (2024-03) — compromised Linux distribution backdoor
event-stream (2018) — crypto wallet stealer hidden in dependency
ua-parser-js (2021) — malicious versions with credential stealer
axios (2026-03) — this incident

axios isn't the first and won't be the last.

Following this incident, npm is reportedly considering mandatory 2FA expansion and a 24-hour cooldown on maintainer email changes. GitHub already required 2FA for top npm maintainers since 2024, but this hijack went through the email recovery flow. Security chains only hold as strong as the weakest link.

Key Takeaways

Check your lock file right now — don't assume you're fine.
Wipe, don't just upgrade — stale caches and remnant RATs are real risks.
Rotate credentials broadly — system-level access means everything is suspect.
Put behavioral analysis in your CI — CVE-based tools can't catch fresh attacks.
Pin exact versions for critical packages — range specifiers are attack surface.

Trusting a popular package and verifying it are different things. If you use axios, put a version check in your routine starting today.

Sources:

Originally published on GoCodeLab — April 2026.

Vercel vs Netlify vs Cloudflare Pages 2026 — Deep Comparison with Real Numbers

LazyDev_OH — Tue, 14 Apr 2026 04:25:43 +0000

The web deployment landscape crystallized into a clear three-way split in 2026. Vercel for Next.js full-stack. Cloudflare Pages for static sites and edge workloads. Netlify for the Jamstack middle ground. All three ship with git push-to-deploy out of the box.

The real story is in billing and performance. In February 2026, Vercel shipped Fluid Compute to GA and announced up to 95% cost savings across 45 billion weekly requests. Cloudflare Workers hold cold starts under 5ms. Netlify migrated to credit-based billing in September 2025. The same app gets billed differently, responds at different speeds, and feels different to operate.

Short version: Next.js ecosystem → Vercel. High-traffic static or edge-heavy → Cloudflare Pages. Forms and adapter ecosystem → Netlify.

Quick Summary

Vercel: Hobby free (100GB · 1M invocations), Pro $20/user/mo, Fluid Compute saves up to 95%
Netlify: Free 100GB · 300 build min, Pro $19/user/mo, credit-based since Sept 2025
Cloudflare Pages: unlimited bandwidth, 500 builds/mo free, Workers Paid $5/mo bundles ecosystem
Cold starts: Cloudflare < 5ms > Vercel Fluid ~0ms (warm) > Netlify 150~3,000ms
Next.js support: Vercel native > Netlify adapter (30~60% slower builds) > Cloudflare OpenNext (constraints)
Edge PoPs: Cloudflare 330+ / Vercel 40+ / Netlify 8-region multi-cloud
Cloudflare ecosystem: KV · D1 · R2 · Durable Objects · Hyperdrive bundled at $5

What Each Platform Actually Is

Vercel was founded by Guillermo Rauch in 2015 — the same person behind Next.js. As of 2026, the company sits around $3.2B valuation. The core edge: native Next.js integration. ISR, Image Optimization, Middleware, Server Actions, Cache Components — all of it works with zero config. Hobby plan is personal / non-commercial only.

Netlify was founded in 2014 and coined the term "Jamstack." Framework adapters span Astro, Next.js, SvelteKit, Nuxt, Gatsby, Hugo — the widest ecosystem of the three. Forms, serverless functions, and Edge Functions come built in. In September 2025, they migrated to credit-based billing.

Cloudflare Pages runs on Cloudflare's global edge network. The headline features are 330+ PoPs and unlimited bandwidth. Workers Paid ($5/month) alone bundles Workers, Pages Functions, KV, D1, R2, Durable Objects, and Hyperdrive. Next.js runs through OpenNext and inherits edge runtime constraints — some Node.js modules unavailable, ISR limited.

Free Tier Deep Dive

Metric	Vercel Hobby	Netlify Free	Cloudflare Pages
Bandwidth	100GB	100GB	Unlimited
Build time	Unlimited deploys	300 min/mo	500 builds/mo
Function invocations	1M/mo	125K/mo	100K/day (~3M/mo)
CPU time	4h Active CPU	Credit-based	10ms/request
Storage	1GB Blob	10GB	R2 10GB / KV 1GB
Usage restriction	Personal / non-commercial	Commercial OK	Commercial OK

Cloudflare dominates on raw bandwidth — traffic spikes don't trigger overage invoices. Vercel Hobby's decisive constraint is the no-commercial clause. A single advertisement can put you in violation. Netlify's 300 build-minute cap is the actual bottleneck — a medium Next.js project often builds in 5~8 minutes, hitting the ceiling at 40~60 deploys/month.

Paid Plans and Overage Simulation

Vercel Pro: $20/user/month + 16 CPU-hours, 1,440 GB-hours memory — overage Active CPU $0.128/hour
Netlify Pro: $19/user/month + 1TB bandwidth, 25K build minutes — $7 per 500 extra build min, $20 per 100GB extra bandwidth, $25 per 1M extra invocations
Cloudflare Workers Paid: $5/month + 10M requests, 30M CPU-ms — $0.30 per extra 1M requests

Scenario A — Small blog (100K monthly visits, 50GB bandwidth, 500K function calls)
Vercel Hobby $0 / Pro $20. Netlify Free possible. Cloudflare Pages $0. → Cloudflare Pages wins.

Scenario B — Next.js SaaS (500K monthly visits, 5M function calls, DB-heavy)
Vercel Pro ~$20~30 (Fluid keeps CPU overage near zero). Netlify Pro $19 + function overage $100 = $119. Cloudflare Workers Paid $5 + extra requests $1.50 = $6.50. → Order: Cloudflare, Vercel, Netlify. If Next.js compatibility is non-negotiable, Vercel.

Scenario C — Image hosting (2TB monthly downloads)
Vercel Pro $20 + 1.9TB overage $380 = $400. Netlify Pro $19 + 1TB overage $200 = $219. Cloudflare R2 $0 egress + $30 storage = $30. → For egress-heavy workloads, Cloudflare is effectively the only option.

Vercel Fluid Compute — Real Savings

Fluid Compute hit GA in February 2026. Per Vercel's figures: 45B weekly requests, customers seeing up to 95% savings, 75%+ of all functions now on Fluid. The old model billed the entire function duration. Fluid only bills Active CPU windows — when your code is actually executing.

// Example: Next.js API handler (I/O-bound)
export async function GET(req) {
  // 100ms — JSON parsing, validation (Active CPU)
  const body = await req.json()
  // 400ms — Supabase query wait (I/O, Fluid bills nothing)
  const data = await supabase.from('users').select()
  // 30ms — response serialization (Active CPU)
  return Response.json(data)
}
// Total wall time: 530ms
// Legacy billing: 530ms (all of it)
// Fluid billing: 130ms (Active CPU only) → 75% saved

From Vercel's case studies: "Many of our API endpoints were lightweight and involved external requests, resulting in idle compute time. By leveraging in-function concurrency, we were able to share compute resources between invocations, cutting costs by over 50% with zero code changes."

For typical Next.js apps, expect function invocation counts to drop 30~50% with proportional cost reduction. The benefit is limited for CPU-heavy workloads (ML inference, image resizing) where Active CPU dominates.

Cold Start Benchmarks — 5ms vs 250ms vs 3 Seconds

Platform	Cold start	Warm response	Mechanism
Cloudflare Workers	< 5ms	~1ms	V8 Isolates + Shard-and-Conquer (99.99% warm)
Vercel Fluid	~0ms (warm)	20~50ms	Instance pre-warming + in-function concurrency
Vercel legacy serverless	~250ms	50~80ms	AWS Lambda
Netlify Functions	150~3,000ms	80~150ms	AWS Lambda (high variance)

Cloudflare Workers' sub-5ms comes from V8 Isolates. Instead of spinning up a container, the platform runs your function directly inside the JavaScript engine. Initialization overhead is near zero. Shard-and-Conquer consistent hashing routes same-request traffic to the same node, keeping warm-hit rate at 99.99%.

Vercel Fluid keeps instances warm with in-function concurrency — a single instance handles multiple concurrent requests. Near-zero cold starts for active functions.

Netlify, running on AWS Lambda, is the slowest. Cold starts up to 3 seconds in benchmarks. For low-traffic sites or early-morning first requests, users feel the wait.

Next.js Feature Compatibility Matrix

Next.js feature	Vercel	Netlify	Cloudflare (OpenNext)
Server Components (RSC)	Full	Full	Full
Server Actions	Full	Full	Partial
ISR (revalidate)	Full	On-Demand only	Limited
Image Optimization	Native	Adapter	Cloudflare Images
Middleware	Full	Full	Full (edge)
Cache Components	Full	Planned	❌
Partial Prerendering (PPR)	Full	Partial	❌
Edge Runtime	Full	Edge Functions	Native
Full Node.js modules	All	All	Some blocked
Build speed (same project)	baseline	30~60% slower	20% slower

Next.js' latest features (Cache Components, PPR) only ship fully on Vercel. Netlify covers most of it via adapter, but ISR semantics differ and builds run noticeably longer. Cloudflare Pages inherits edge-runtime constraints — can't use fs, net, or child_process, and ISR requires wiring Incremental Cache into KV separately.

On the flip side, Cloudflare's Image Optimization routes through Cloudflare Images (faster CDN), and Edge Runtime is native. For edge-friendly codebases, Cloudflare Pages can actually win.

Cloudflare Ecosystem — KV · D1 · R2 · Durable Objects

Cloudflare's real edge: $5/month Workers Paid bundles 6+ data services. Each as a standalone SaaS would run into hundreds of dollars.

Service	Use case	Price (Paid)
Workers KV	Global key-value, config/session/personalization	Reads 10M $0.50, writes 1M $5
D1	Managed SQLite, lightweight relational DB	Reads 25M $1, writes 50K $1
R2	S3-compatible object storage, zero egress	$0.015/GB storage, Class A 1M $4.50
Durable Objects	WebSockets, collaboration, locks, rate limiters	1M requests $0.15, $0.20/GB/mo
Queues	Message queue, async work	1M operations $0.40
Hyperdrive	External PostgreSQL pooling	Included in Workers Paid

Practical combo: sessions/config on KV, user data on D1, images/files on R2, chat rooms on Durable Objects, background jobs via Queues. Everything at the same $5.

AWS equivalent stack: RDS ($15) + DynamoDB ($10) + S3 ($5) + egress ($100+) + SQS ($2) = $130+/month minimum. R2's zero-egress policy alone makes file-heavy services land in a completely different cost range.

Durable Objects is the only practical choice for stateful edge computing. WebSocket chat rooms, Google Docs-style real-time collaboration, distributed locks, rate limiters. Vercel and Netlify have no equivalent, forcing external services (Pusher, Ably) to fill the gap.

Edge Network and Global TTFB

Cloudflare: 330+ PoPs across 120+ countries
Vercel: own edge network (40+ regions) + AWS/GCP
Netlify: multi-cloud AWS/GCP/Azure (8 main regions)

TTFB benchmarks from Korea (static content): Cloudflare Seoul PoP 30~50ms, Vercel Tokyo/Seoul region 80~120ms, Netlify US-West default 250~400ms. For global apps with APAC users, Cloudflare is overwhelmingly the fastest experience.

Vercel's Tokyo/Singapore regions can reach ~100ms in Korea when explicitly configured. Hobby has limited region pinning; Pro enables per-project region selection. Setting regions in vercel.json is important — defaults often point to US regions.

Netlify Credit-Based Pricing

Since September 2025, Netlify uses a unified credit pool. Approximate conversions: 1 build minute = 1 credit, 1,000 function invocations = 1 credit, 1 GB bandwidth = 1 credit. Pro includes 500 credits/month — in theory 100 deploys if builds are 5 minutes each, but practical ceiling drops to 50~70 after other usage.

The complaint is predictability. "My build ran long and drained my credits" posts keep showing up in dev forums. Accounts created before September 4, 2025 can stay on the legacy plan.

Netlify's strengths still hold — Forms built in (100 submissions/mo free), Identity, Large Media, Split Testing. Features Vercel and Cloudflare don't match natively.

Full Comparison Table

Dimension	Vercel	Netlify	Cloudflare Pages
Free bandwidth	100GB	100GB	Unlimited
Paid starting	$20/user/mo	$19/user/mo	$5/mo
Cold start	~0ms (warm)	150~3,000ms	< 5ms
Next.js support	Native (full)	Adapter (mostly)	OpenNext (constrained)
Serverless billing	Active CPU (Fluid)	Credit-based	Per-request
Global PoPs	40+ edge	8 regions	330+ PoPs
Commercial free use	Not allowed	Allowed	Allowed
Ecosystem	Next.js + Postgres/KV/Blob	Forms, Identity, Split Testing	KV, D1, R2, DO, Queues
Build speed (Next.js)	Fastest	30~60% slower	20% slower
DX / dashboard	Best	Clean	Deep but learning curve
Egress cost	Deducts from bandwidth	Deducts	R2 $0

Combining Platforms — Real-World Patterns

No reason to pick one and stick with it.

# Pattern A — Subdomain split (most common)
static.example.com  → Cloudflare Pages (images, docs, heavy assets)
app.example.com     → Vercel Pro (Next.js full-stack)
forms.example.com   → Netlify (form intake)

# Pattern B — Cloudflare as front CDN, Vercel as origin
Cloudflare (CDN/WAF/DDoS) → Vercel (serverless origin)
# Cloudflare absorbs egress, Vercel handles execution only

# Pattern C — Full Cloudflare stack (AWS alternative)
Cloudflare Pages + Workers + D1 + R2 + Durable Objects
# Full-stack infra starting at $5/month

Recommendations by Scenario

Scenario	Pick	Why
Next.js full-stack SaaS	Vercel Pro	Fluid Compute 95% savings, Cache Components/PPR native
Image / video hosting	Cloudflare + R2	Zero egress, 330+ PoPs
Astro / SvelteKit	Netlify	Adapter ecosystem, built-in forms
Real-time / WebSocket	Cloudflare + DO	Only edge stateful solution
Global TTFB matters	Cloudflare	Largest edge network
Intermittent traffic	Vercel Fluid / Cloudflare	Low cold start
Personal (no revenue)	Vercel Hobby	All Next.js features free
Form-heavy marketing	Netlify	Forms built in

Closing Thoughts

All three platforms are mature as of 2026. "Which is better" is the wrong frame — "which fits your stack" is the real question.

Three trends worth watching as of April 2026:

Vercel Fluid Compute now powers 75%+ of all Vercel Functions and has measurably dropped Next.js full-stack bills.
Cloudflare D1 moved past GA with real production references, making AWS RDS replacement a concrete option.
Netlify's credit-based pricing is driving heavy users to reconsider.

The right choice shifts each year. Review your workload periodically.

Official sources:

Originally published on GoCodeLab — April 2026 pricing. Plans and policies change frequently; verify with official docs before committing.

I Catalogued the Security Patterns That Keep Showing Up in AI Code

LazyDev_OH — Mon, 13 Apr 2026 04:03:48 +0000

Across the Apsity App Store dashboard, the FeedMission SaaS, and a dozen side projects, more than half the code I touch is AI-generated. After shipping a SaaS in 7 days, vibe coding has been the default workflow.

Run it long enough and the patterns show up. AI-generated code keeps producing the same classes of security holes. One FeedMission review surfaced seven criticals at the same time — a Slack webhook URL bundled into the frontend, an unsubscribe endpoint that any email address could trigger, an admin reply leaking through a public API, routes missing team-member auth checks. None of that was bad luck. Industry research lists these as the highest-frequency patterns, and they had effectively reproduced themselves in our codebase.

So now I run the same seven checks before every deploy, the same way each time. This post is the pattern catalogue plus the routine.

The numbers, first

This isn't a vibe check. Multiple groups in 2026 (Georgia Tech, Cloud Security Alliance, Checkmarx) analyzed AI-generated code and found:

40–62% of samples contain security issues
2.74× more vulnerable than human-written code on equivalent tasks
86% failed XSS defenses
88% vulnerable to log injection
35 new CVEs tied to AI-generated code in March 2026 alone
One AI app leaked 1.5M API keys post-launch — shipped without security review

Nobody's quitting vibe coding because of these numbers. I'm not. But the 10 minutes you spend before deploy is what decides production's fate.

How AI skips security

Beginners get this wrong. The AI didn't make a mistake — it built what you asked for. "Make a user profile API" → it makes one. Auth wasn't requested, so it's not there. It leaves // TODO: add auth here and moves on.

The fix: put security in the prompt from the start. "Include JWT auth middleware, read secrets only from env, no raw SQL, no TODO comments, ship complete code." One line changes the output quality.

Top 7 mistakes — in the order I hit them

#	Mistake	What happens	Red flag
1	Hardcoded API keys	Scraped by bots within seconds	`sk_`, `api_key=`
2	Auth-less API routes	URL-only access to your DB	no session/auth/token references
3	`NEXT_PUBLIC_` misuse	Service-role key in browser bundle	`NEXT_PUBLIC_*_SECRET/KEY`
4	Raw SQL interpolation	SQL injection → full DB exfil	`SELECT ... ${}`
5	CORS wildcards	Any domain hits your API	`Allow-Origin: *`
6	Missing XSS / log-injection defense	User input straight into HTML/logs	`dangerouslySetInnerHTML`, raw-string logs
7	Phantom packages (slopsquatting)	Malicious package under hallucinated name	unfamiliar packages, low downloads

1 and #3 hit fastest. The moment you push to GitHub, scraper bots scoop the key and burn your API quota. If you've never been hit, you've only been lucky.

Slopsquatting warning — when AI says npm install some-plausible-package, check npmjs.com first. About 20% of AI-generated code references nonexistent packages. Attackers register those names with malicious payloads, and you install them instantly.

What could have happened at FeedMission

From the 7 above, FeedMission had #2, #3, #6, plus a few app-specific issues:

Slack webhook URL rode on ProjectContext into the frontend bundle.
Unsubscribe API took just an email address. Anyone's email → instant unsubscribe. Switched to an unsubscribeToken flow.
/api/feedback/mine returned the full admin reply text. Now hasReply: boolean only.
Team member auth checks missing across several APIs.
.env wasn't in .vercelignore — almost shipped via symlink in a Vercel build.

All fixed in one commit (52efb89). None of these are "too edge-case to happen to me."

My 10-minute pre-deploy routine

# 1. Three grep lines — 5 seconds
# Unfinished security code
grep -r "TODO\|FIXME\|implement.*later\|add.*auth" ./src

# Hardcoded secrets
grep -r "sk_\|api_key\|password\s*=" ./src

# Client-exposed env vars
grep -rE "NEXT_PUBLIC_.*(SECRET|KEY|TOKEN)" ./src

# 2. SQL interpolation and CORS wildcards
grep -rn "\`SELECT\|\`INSERT\|\`UPDATE\|\`DELETE" ./src
grep -rn "Allow-Origin.*\*" ./src

If all pass, paste the generated code back to the AI and ask: "Review this code against OWASP Top 10 for vulnerabilities." Imperfect but a fine first-pass filter.

GitHub side, turn on three things: Secret Scanning, Push Protection, CodeQL Code Scanning. Plus Dependabot/npm audit in CI for package vulns.

My prompt tail (every code-generation request): "Include auth middleware; read secrets only from process.env and use NEXT_PUBLIC only for public values; always validate user input; no raw SQL; ship complete code without TODO/FIXME."

Bonus — Using Supabase? RLS is its own chapter

Next.js + Supabase is the default vibe-coder stack, so RLS gets a dedicated section. RLS (Row Level Security) is PostgreSQL's row-level access control. "This row is readable only by the user whose user_id matches" — enforced at the database layer.

Why this matters: when you create a table in Supabase Studio, RLS is OFF by default. Ship NEXT_PUBLIC_SUPABASE_ANON_KEY to the client in that state and anyone with that key can read or write every row in every table. The anon key effectively becomes a service-role key. Whatever assurance "client-side anon key is safe" gave you, it's gone.

Turning RLS on isn't enough either. Without policies, every access is denied. You write separate policies per action: SELECT, INSERT, UPDATE, DELETE. The most frequent mistake is writing USING (the read/delete-time filter) but forgetting WITH CHECK (the post-write validation):

-- ✗ Risky — USING only
CREATE POLICY "own rows"
ON posts FOR UPDATE
USING (auth.uid() = user_id);
-- WITH CHECK forgotten!

-- ✓ Safe — both
CREATE POLICY "own rows"
ON posts FOR UPDATE
USING (auth.uid() = user_id)
WITH CHECK (auth.uid() = user_id);

Without WITH CHECK, user_a can INSERT or UPDATE rows claiming user_b's user_id — planting rows or hijacking existing ones.

Three review queries to save in your Supabase SQL Editor:

-- 1. Tables with RLS still off
SELECT tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public' AND rowsecurity = false;

-- 2. RLS on but no policies — everything is rejected
SELECT t.tablename
FROM pg_tables t
LEFT JOIN pg_policies p
  ON t.schemaname = p.schemaname AND t.tablename = p.tablename
WHERE t.schemaname = 'public' AND p.policyname IS NULL;

-- 3. INSERT/UPDATE policies missing WITH CHECK
SELECT tablename, policyname, cmd, qual, with_check
FROM pg_policies
WHERE schemaname = 'public' AND cmd IN ('INSERT', 'UPDATE') AND with_check IS NULL;

Run these after every migration. Empty results on all three = you're clear.

Top-4 BaaS-specific mistakes:

RLS off — anon key becomes a master key.
Missing WITH CHECK — attackers plant rows under someone else's user_id.
service_role key shipped to client — SUPABASE_SERVICE_ROLE_KEY must never be NEXT_PUBLIC. Server routes / Edge Functions only.
Permissive anon-role policies — auth.uid() = user_id missing means unauthenticated callers reach every row.

Same principle applies to Firebase Security Rules, Appwrite Permissions, PocketBase Collection rules: if the client talks to the database directly, the database is the last line of defense. Leave that line empty and no upstream security matters.

Wrap-up

Vibe coding didn't make security worse. The habit of deploying without review did. AI raised the speed. Raise your review speed with it. Three grep lines, one AI review, three GitHub settings, the RLS check if you're on Supabase. Ten minutes.

Skip those ten minutes and "1.5M API keys leaked" stops being someone else's story.

Sources

Originally published at GoCodeLab. Lazy Developer EP.18.

Upgraded to Tailwind v4 — Config Files Are Gone

LazyDev_OH — Mon, 13 Apr 2026 02:23:23 +0000

Tailwind CSS v4 shipped in January 2025 and tailwind.config.js is gone. Configuration now lives inside the CSS file itself. I migrated a Next.js project — unfamiliar at first, but simpler once you're through it.

The actual transition is faster than expected. The official CLI handles about 80% of it.

What Changes

tailwind.config.js → replaced by a CSS @theme block
Rust-based Oxide compiler — up to 5x faster full builds, up to 100x faster incremental
Automatic content detection — no more manual content array
@tailwind base/components/utilities → single @import "tailwindcss"
Plugins declared in CSS via @plugin "..."

Real-world number from Tailwind's own benchmark: a design system with 15,000 utility classes saw cold builds drop from 840ms to 170ms.

Config Moved into CSS

v3 kept everything in JS. v4 does it all in one CSS file.

/* v4 — configure directly in CSS */
@import "tailwindcss";

@theme {
  --breakpoint-3xl: 1920px;
  --color-brand: oklch(68% 0.19 245);
  --font-display: "Inter Variable", sans-serif;
}

@theme uses CSS variables. Design tokens are visible in DevTools at runtime. One less JS dependency.

@theme Naming Convention

--color-{name}, --font-{name}, --spacing-{name}. Tailwind reads the namespace and generates utility classes automatically. Define --color-brand and text-brand, bg-brand, border-brand light up immediately.

Oxide Compiler

Rust, not Node. Replaces the old PostCSS plugin. Content path detection is automatic — no more content: ['./src/**/*.tsx']. Oxide ships inside the tailwindcss v4 package, no separate install. Integrates with Vite and PostCSS pipelines.

Migration Steps

Option A — one command

npx @tailwindcss/upgrade

Handles config conversion and class renames for projects without custom plugins.

Option B — manual (Next.js / PostCSS)

npm install tailwindcss@latest @tailwindcss/postcss

// postcss.config.js (v4)
module.exports = {
  plugins: {
    "@tailwindcss/postcss": {},
  },
};

/* globals.css (v4) */
@import "tailwindcss";

@theme {
  --color-brand: #6366f1;
}

tailwind.config.js can be deleted or kept — v4 doesn't read it. Deleting it is cleaner for team repos.

Plugins Now Live in CSS

@import "tailwindcss";

@plugin "@tailwindcss/typography";
@plugin "@tailwindcss/forms";
@plugin "./plugins/my-plugin.js";

@theme {
  --color-brand: #6366f1;
}

The plugins array in tailwind.config.js is gone. Pass a package name or a file path to @plugin and it works. Existing addUtilities and addComponents APIs mostly still apply, but parts of the plugin API changed — verify behavior after migrating.

The `outline-none` Gotcha

v3: outline-none rendered as outline: 2px solid transparent — still accessible.
v4: outline-none renders as outline: none — actually removes the outline.

If you used outline-none to hide focus rings on buttons or inputs, swap in outline-hidden. Expect this to surface during accessibility checks.

v3 vs v4 at a Glance

Area	v3	v4
Config	`tailwind.config.js`	CSS `@theme` block
Import	three `@tailwind` lines	`@import "tailwindcss"`
Content detection	manual array	automatic
Compiler	PostCSS (Node)	Oxide (Rust)
Plugins	`plugins: [...]`	`@plugin "..."`
`outline-none`	transparent outline	actual `none` (use `outline-hidden`)

Should You Upgrade Now?

New project → v4. No reason not to.
Existing v3 project → no rush. v3 is still supported.
Heavy custom-plugin stack → stay on v3 until you've tested each plugin against the v4 API.
Build times biting → v4 is worth the migration cost just for the Oxide numbers.

FAQ

Q. Do I need to delete tailwind.config.js?
No — v4 doesn't read it. The upgrade CLI handles conversion. Delete for cleanliness.

Q. Separate Oxide install?
No. Included in the tailwindcss v4 package.

Q. How long does migration take?
Small Next.js projects: 30 minutes including manual review. Larger ones with custom plugins and dynamic class composition (bg-${color}-500 patterns): a couple hours, because those aren't auto-migrated.

Sources

Originally published at GoCodeLab.

Gemma 4 vs Llama 4 vs Mistral Small 4: The 2026 Open-Source LLM Picks

LazyDev_OH — Mon, 13 Apr 2026 02:23:22 +0000

Three heavyweights dropped this year: Gemma 4 (Google), Llama 4 (Meta), Mistral Small 4 (Mistral). All free to run. All structurally different. Here's which one fits which job.

Short answer: long context → Llama 4 Scout. License-clean commercial use → Mistral Small 4. On-device → Gemma 4 E2B / E4B.

Quick Take

	Gemma 4 (31B / 26B MoE)	Llama 4 Scout	Mistral Small 4
Architecture	Dense (31B) · MoE (26B/A4B)	MoE (17B active / 109B)	MoE (~22B active / 119B)
Context	E2B/E4B 128K · 31B/26B 256K	10M	256K
License	Google Gemma ToU	Llama 4 Community	Apache 2.0
Multimodal	text + image + video + OCR (E2B/E4B add audio)	text + image (early fusion)	text + image (first in Small series)
Edge fit	Excellent (E2B/E4B)	Low	Low (multi-GPU even quantized)

MoE vs Dense

MoE is a bank of specialized tellers — only the relevant experts fire per input. Llama 4 Scout: 109B total, 17B active. Mistral Small 4: 119B total across 128 experts, ~22B active. Gemma 4 26B: the "small MoE" path — 26B total, ~3.8B active, targeting 4B-speed with bigger-model intelligence.

Gemma 4 E2B, E4B, and 31B are Dense. Every parameter fires on every token. Higher compute per parameter, but memory requirements scale linearly and planning is easier.

One MoE trap people hit: inference compute drops, but all weights still need to sit in memory. Llama 4 Scout in fp16 = ~218GB VRAM. 4-bit = ~55GB. "Only 17B active so it's lightweight" is wrong.

Context Window — 10M, 256K, 128K

Llama 4 Scout's 10M is the outlier. Meta got there via iRoPE — interleaved RoPE that holds accuracy past the training sequence length. Practical impact: you can drop an entire monorepo into one prompt and skip the RAG pipeline altogether.

Mistral Small 4 sits at 256K. Gemma 4's small variants (E2B/E4B) are 128K; the medium 31B and 26B MoE jump to 256K. For normal-scale work — books, research paper batches, long meeting transcripts — 128K is already more than enough.

Benchmarks

Llama 4 Maverick on SWE-bench: 76.8 to 80.8 depending on the evaluation variant. Open-source top tier — but not "absolute #1." GLM-5 (77.8) shows up right next to it on SWE-bench Verified.
Llama 4 Scout is smaller than Maverick but wins on repo-scale analysis thanks to 10M context.
Gemma 4 31B shines on multimodal tasks relative to its size class.
Mistral Small 4 (per Mistral's evals) matches or surpasses GPT-OSS 120B and Qwen-class models on several key benchmarks — at ~22B active.

Benchmarks and day-to-day use diverge. Run them yourself before committing.

Multimodal — Images, Video, Audio

None of these three is text-only in 2026.

Gemma 4 is natively multimodal across every variant: text, image, video, OCR. E2B and E4B add native audio input — voice assistants and on-device transcription become direct use cases.
Llama 4 Scout/Maverick use early fusion — text and vision tokens unified inside the foundation model.
Mistral Small 4 is the first in the Mistral Small series to support native vision. Images ride in the normal API message array alongside text, inside the same 256K window.

Licenses (Actually Read Before Shipping)

Mistral Small 4 / Apache 2.0 — zero restrictions. Fine-tune, redistribute, embed in SaaS, ship it.
Llama 4 Community — commercial use fine below 700M MAU, but Meta's approval is required above that (sole discretion). Also: mandatory "Built with Llama" badge on a related web or in-app page.
Gemma 4 / Google Gemma ToU — you can't use Gemma outputs to train competing LLMs, and AI-adjacent services need to read the clauses carefully.

Edge Deployment Reality

Model	fp16 VRAM	4-bit VRAM	Realistic hardware
Gemma 4 E4B	~8GB	~3GB	Laptop / phone
Gemma 4 31B	~62GB	~16GB	RTX 4090 / M2 Max
Llama 4 Scout	~218GB	~55GB	Multi-GPU / H100 at Int4
Mistral Small 4	~238GB	~60GB	Multi-GPU / high-end workstation

Gemma 4 E4B at 4-bit = ~3GB. Runs on a laptop. For smartphone deployments E2B is the target. Llama 4 Scout and Mistral Small 4 stay in server territory even quantized — the full MoE weights have to fit in memory regardless of active count.

How to Combine All Three

Routing by request type is more realistic than picking one:

request type                    → model
-------------------------------------------
whole-doc / whole-repo analysis → Llama 4 Scout (10M context)
image + video + audio input     → Gemma 4
commercial API traffic          → Mistral Small 4 (Apache 2.0)

Using hosted APIs (Together AI, Groq, Fireworks) on top of this routing lets you optimize both cost and capability together.

FAQ

Q. How does Scout actually handle 10M tokens?
iRoPE — Meta's interleaved version of RoPE position encoding. Extends accuracy well past training length.

Q. Which is most commercial-friendly?
Mistral Small 4. Apache 2.0. No MAU cap, no branding requirement.

Q. Is MoE always better than Dense?
No. Inference compute drops, but memory scales with total parameters. Edge = Dense small or compact MoE like Gemma 4 26B. MoE only pays off with multi-GPU.

Q. Best at coding?
Llama 4 Maverick (76.8–80.8 on SWE-bench) — top tier, not #1. GLM-5 (77.8) is right there too. Mistral Small 4 is fine for general code review; Scout's 10M wins whole-repo work.

Sources

Originally published at GoCodeLab. Always read each model's official license before commercial deployment — this post is not legal advice.

I Engineered How AI Works for Me — My Claude Code Harness Setup

LazyDev_OH — Sun, 12 Apr 2026 17:30:46 +0000

What Is Harness Engineering

A harness is originally the gear you put on a horse. Here it means the work framework you put on AI. It's not just writing better prompts — it's building a system that defines how Claude works.

There are three components. Rules is the CLAUDE.md at the project root — the rules Claude must always follow in this project. Commands are saved files for repeated task requests: things like /workflow and /plan-and-spec. Hooks are logic that runs automatically before or after specific actions. This is the most powerful layer of the three.

Rules define "what to do." Commands define "how to do it." Hooks enforce "what must never happen." The three layers combine into a single framework.

Background on This Structure

The Commands and Hooks concepts exist in Anthropic's official Claude Code documentation. Harness engineering is a method of combining these features to automate an entire personal development workflow. It uses official features — not hidden ones.

The Full Structure at a Glance

The file structure is the fastest way to understand it. It's split into a global area and a per-project area. The global area is shared across every project on your machine. Set it up once and it carries over to every project.

~/.claude/                        ← shared across machine (set up once)
  commands/
    init-harness.md               ← auto-build harness (this file)
    new-project.md                ← idea → project setup
    session-resume.md             ← restore context on session resume
  hooks/
    block-dangerous.sh            ← block dangerous commands
  settings.json                  ← hook wiring

project/                          ← auto-generated per project
  CLAUDE.md                      ← project rules
  progress.md                    ← current task state
  dev-log.md                     ← feature-by-feature dev log
  docs/                          ← store design documents
  screenshots/                   ← store screenshots
  .claude/commands/
    workflow.md                    ← full pipeline orchestrator
    plan-and-spec.md               ← design + fact-check (Planner)
    tdd.md                         ← implementation (Generator)
    ui-ux.md                       ← UI/UX research
    verify.md                      ← verification (Evaluator)
    commit.md                      ← commit + merge

The key is separation. What can be used in any project goes global; what is only meaningful in this project goes inside the project. init-harness automatically creates the entire project area.

init-harness: From Analysis to Generation

Whether starting a new project or attaching a harness to an existing one, you just run /init-harness. It proceeds automatically through five steps. No confirmation prompts in between. It shows one analysis summary, then moves straight to generation.

Step 1 is project analysis. It reads package.json to identify the stack, checks the folder structure 3 levels deep, reads git log for commit patterns, and checks .env.example for integrated services. It only reads. It changes nothing.

# Step 1: project analysis (read only)

git log --oneline -20     # identify commit patterns
git branch -a             # check branch strategy

# output format after analysis
[project analysis]
- stack:           Next.js 15 / TypeScript / Supabase
- structure:       App Router, no src/, feature-based folders
- commit pattern:  feat/fix/refactor prefix
- branch strategy: feature/* → direct merge to main
- integrations:    Supabase, Resend, LemonSqueezy
- commands to generate: workflow, plan-and-spec, tdd, ui-ux, verify, commit

Step 2 is CLAUDE.md generation. It fills in the tech stack, architecture rules, and absolute prohibitions from the analysis results. It's not a blank template — it's a file built from actually reading the project. Items like "i18n keys only for multilingual text," "no hardcoding," and "no force push to main" are inserted automatically.

Step 3 is command file generation. workflow, plan-and-spec, tdd, ui-ux, verify, and commit are created inside .claude/commands/. Step 4 is generating the project base files: progress.md, dev-log.md, docs/, and screenshots/. Step 5 is checking global files. If session-resume, new-project, or block-dangerous.sh don't exist, it creates them; if they already exist, it leaves them alone.

The Command Pipeline

workflow.md is the orchestrator for the entire pipeline. Running /workflow "feature name" calls the rest in order. Each step automatically moves to the next when complete.

# /workflow "feedback auto-classify feature"

0. assess current state    # progress.md + git log --oneline -10
1. branch setup            # feature/feedback-auto-classify
2. design + fact-check     # run /plan-and-spec → Planner
3. implement               # run /tdd → Generator
4. verify                  # run /verify → Evaluator
5. commit + merge          # run /commit

# if verification fails → go back to step 3, fix, then re-verify

plan-and-spec forces a web-search fact-check before implementation. It first confirms whether the library actually exists and whether the API can actually be implemented. If anything is 100% impossible, it proposes an alternative. The design document is saved to docs/spec-featurename.md.

tdd breaks things into feature units and implements them one at a time. It includes a step where mock data is injected into each completed screen to make it look real. This bakes in the pattern from EP.08 where I took a screenshot every time I finished a platform-specific widget.

verify is the step that compares the design document against the actual implementation. It checks for missing features, untranslated strings, and build errors. If there are failures, it outputs the fix method alongside them and returns to tdd. It's not just "does it run" — it's "was it built as designed."

Planner → Generator → Evaluator

The core of the command pipeline is the three-role separation. A single Claude switches roles as it works. plan-and-spec takes the Planner role, tdd takes Generator, verify takes Evaluator.

Planner designs and fact-checks before implementation. It first verifies "is this even possible." It web-searches to confirm the library actually exists, checks similar implementation examples, and reviews API constraints — then produces a design document. This step exists to prevent the situation where you start implementing without fact-checking and get stuck.

Generator implements feature by feature while reading the design document. If the design changes during implementation, it immediately updates docs/spec-*.md and states the reason. Keeping design and code in sync is the key. There is no "I'll update it later."

Evaluator compares the design document against the actual implementation. It checks for missing features, untranslated strings, and missing error handling. The Generator does not self-verify. By separating roles, things the implementor is likely to miss get caught by different eyes.

What Actually Happened With the EP.05 Clustering Feature

When building the automatic feedback clustering, the Planner fact-checked the actual parameters for pgvector and the Voyage AI embedding API. The Generator implemented clustering.ts — 188 lines — feature by feature. The Evaluator compared it against the design document and caught a missing cosine similarity threshold handler. Before this, that kind of omission was the type I only caught after shipping.

What Hooks Enforce

Commands are optional, but hooks run automatically. Before Claude executes any bash command, block-dangerous.sh runs first. If it returns exit 2, the command is blocked. It blocks two things.

#!/bin/bash
INPUT=$(cat)

# block direct force push to main
if echo "$INPUT" | grep -q "push.*--force.*main\|push.*main.*--force"; then
  echo "main force push blocked" >&2
  exit 2
fi

# block .env commit
if echo "$INPUT" | grep -q "git add.*\.env\b"; then
  echo ".env file commit blocked" >&2
  exit 2
fi

exit 0

This script is wired up as a PreToolUse hook in settings.json. It's automatically called before Claude executes the Bash tool.

// ~/.claude/settings.json
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "bash ~/.claude/hooks/block-dangerous.sh"
      }]
    }]
  }
}

The advantage of hooks is that they block mistakes at the source. Even if a force push to main slips in by accident, the system stops it. It's not a human checking — it's the system blocking. Having just these two in place defends against the most catastrophic mistakes.

Full Automation Mode

With the harness set up, running Claude Code with the --dangerously-skip-permissions flag lets it run to completion on its own without asking for confirmation. No "is it okay to do this" in the middle. Run /workflow and everything from branch creation to commit and merge happens automatically.

This mode is not the dangerous part. Using it without hooks is dangerous. The hooks block main force push and .env commits, so the two critical mistakes are automatically defended against. Set up the harness first, then use it — that's the order.

When a session drops and resumes, I use /session-resume. It reads the last 30 lines of progress.md and dev-log.md, plus git log and git status, then summarizes "how far we got and what's next" before picking right back up. It pairs with the CLAUDE.md automation from EP.01. One maintains the rules; the other restores the state.

What Changed

A few things changed after building the harness. In numbers, it looks like this.

	Before	After
Starting a new project	explaining rules every time (10–15 min)	/init-harness, one line
Feature dev order	repeating the order every time	/workflow "feature name"
Session resume	re-explaining context	/session-resume
UI dev research	requesting separately each time	built into ui-ux.md
Design docs	forgotten, not written	auto-generated + auto-updated

There was an unexpected result. I built this system because I was lazy, but I ended up working more carefully. I started writing design documents. I started doing fact-checks. The steps I used to skip because they were annoying are now baked into the commands — so they just happen.

Frequently Asked Questions

Q. If I run init-harness, do I not need to write CLAUDE.md myself?

It auto-generates one, but it doesn't fully replace writing it yourself. What init-harness creates is a draft based on the project analysis. Team conventions, specific library constraints, and deployment environment details still need to be added manually. Use it as: auto-generate, then fill in the gaps.

Q. Do I have to use commands like /workflow every time?

No. Simple bug fixes or small changes can just be asked in plain language. Commands are only for feature development that needs to go all the way from start to finish properly. Only hooks are always running in the background — everything else is optional.

Q. Isn't the --dangerously-skip-permissions flag dangerous?

It's dangerous without hooks. The hooks block main force push and .env commits, so the order is: set up the harness first, then use it. It's not the flag that's dangerous — using it without hooks is. With just these two in place, full automation mode is usable.

Q. Can this structure be used for team projects?

This structure was designed for solo development. To use it on a team, you'd need to modify the direct-to-main merge section and the branch strategy. Update CLAUDE.md to match team conventions and add a PR creation step to commit.md. The structure itself can be adapted for teams.

Wrapping Up

Setting up this structure took a day or two. Writing command files, making hooks, testing the flow. At first I wasn't sure it was right. Now, every time I start a new project, /init-harness handles everything — so that time wasn't wasted.

The harness is never finished. As you use it, the gaps become visible, and you update the command files each time. It's not about building a perfect framework — it's about cutting out annoying things one by one. That's the Lazy Developer way.

Originally published on GoCodeLab

Harness Engineering — The Environment Matters More Than the Prompt

LazyDev_OH — Sun, 12 Apr 2026 16:37:09 +0000

What Is a Harness

The word comes from a horse harness. The harness is the entire apparatus that guides the horse called AI in the desired direction. It's the concept of designing not the model itself, but the entire environment in which that model works. It's not about a single prompt line — it's about setting up the entire board.

Context files, skill files, MCP servers, and execution loops are all included. Verification processes and human intervention points are all part of the harness. Humans are part of the harness too. It is not a system where AI runs alone.

It's not about what to ask AI. It's about how to set up the board where AI can work. The core argument is that the environment is the bottleneck, not the model. That's why results can differ 10x with the same model depending on environment setup.

The Limits of Prompt Engineering

Once, the single phrase "think step by step" (Chain-of-Thought) boosted math accuracy by 39%p (Wei et al. 2022, GSM8K benchmark). A 2025 Wharton GAIL study remeasured with the latest models and found it dropped to about 3%p. Evidence that as models advance, the effect of prompt tricks is disappearing.

The more advanced the model, the more built-in reasoning it already has. There is less room for prompt manipulation. No matter how sophisticated a system prompt is, there are fundamental limits. Designing structure yields better long-term returns than spending time hunting for tricks.

A harness, by contrast, can be reused even as models are upgraded. The structure itself is not tied to a specific model. A CLAUDE.md written this year will work the same with next year's models. This is why investing in harness rather than prompts is the right move.

Three-Stage Evolution: Prompt → Context → Harness

There are three stages. Prompt engineering → context engineering → harness engineering. Each maps to "What to ask → What to show → How to design." We are now at the transition into the third stage.

Context engineering is deciding what ingredients to give AI. Harness is designing the entire kitchen that holds those ingredients. Good ingredients alone are not enough. Tool placement and task sequence must be designed together.

There is a case from the medical field that demonstrates this difference. Providing relevant data and restricting scope reduced hallucinations from 40% to 0%. Without changing the model. Changing the context alone changed the results. Harness is a broader concept that includes this context design.

5 Core Components

The 5 core elements of a harness are Agent.md (CLAUDE.md), Skills, MCP, Hooks, and Sub-agents. Each has a different role and they are used in combination. What makes the difference is not which tool you use, but how well you design these 5 structures.

Element	Role	Analogy	Key Caution
Agent.md	Documenting project rules	New employee onboarding manual	Keep under 300 lines
Skills	Separating task-specific expertise	Department-specific reference files	Separate file per task
MCP	Connecting external tools	USB hub	Connect only what's needed
Hooks	Mandatory execution rules	Automatic checklist	Use instead of prompts
Sub-agents	Parallel task processing	Team member division of labor	Verify dependencies first

This structure can be applied equally in both Claude Code and Cursor. The harness structure works the same regardless of the tool. Whether you have this structure matters more than which AI coding tool you use.

How to Write CLAUDE.md Properly

CLAUDE.md (or Agent.md) is the foundation file of the harness. It documents project structure, coding rules, and standards AI must follow. The general consensus is under 300 lines. HumanLayer stated they keep it under 60 lines in their own projects. An ETH Zurich study found that auto-generated CLAUDE.md by LLMs actually increased token costs by 20% and lowered performance. Writing it yourself is better.

The key is not writing things that Claude can figure out by reading the code. Standard language conventions, per-file descriptions — these are left out. Conversely, things that cannot be known from code alone must be written. Bash commands, branch rules, project-specific architecture decisions.

What to Write	What to Skip
Bash commands Claude cannot infer	Things derivable by reading the code
Code style rules that differ from defaults	Standard language conventions (Claude already knows)
Test runner / how to run tests	Detailed API docs (just link them)
Branch naming, PR rules	Frequently changing information
Environment quirks, required env vars	"Write clean code"-style obvious things

The scope of application varies by file location. ~/.claude/CLAUDE.md applies to all projects. CLAUDE.md at the project root applies only to that project. CLAUDE.local.md is for personal settings and goes in .gitignore. In a monorepo, placing separate CLAUDE.md files in subdirectories applies them hierarchically.

Not everything goes into CLAUDE.md. The Progressive Disclosure pattern of referencing separate documents is key. Here's what it looks like in practice:

# Code style
- Use ES modules (import/export), not CommonJS (require)
- Destructure imports when possible

# Workflow
- Typecheck when done making code changes
- Run single tests, not the full suite

# References
See @README.md for project overview
Git workflow: @docs/git-instructions.md
Personal overrides: @~/.claude/my-project-instructions.md

CLAUDE.md Writing Principles

Under 300 lines is the general consensus. Shorter is better. Longer makes AI slower

Not a manual, but an index. Write only "where to find what"

Don't write things Claude can figure out by reading the code

Separate detailed rules into separate documents and reference with @path

Remove stale documents immediately. AI follows outdated rules

Skill File Design

Skill files are task-specific expertise separated into the .claude/skills/ folder. The difference from CLAUDE.md is "always loaded vs. loaded only when needed." Putting everything in CLAUDE.md wastes the context window. Skills are only loaded when that task is being performed.

The actual directory structure looks like this:

.claude/skills/
  api-conventions/
    SKILL.md        # main (required)
    reference.md    # detailed docs (loaded on demand)
    examples.md     # usage examples
  fix-issue/
    SKILL.md
  deploy/
    SKILL.md

Adding name and description in the SKILL.md frontmatter lets you invoke it as a slash command. Setting disable-model-invocation: true means it won't be invoked automatically by AI — it only runs when a human calls it directly. There are two types: reference skills and task skills:

# Reference — API rules (auto-loaded by Claude)
---
name: api-conventions
description: REST API design conventions
---
- Use kebab-case for URL paths
- Use camelCase for JSON properties
- Always include pagination for list endpoints

# Task — Fix GitHub issue (/fix-issue 123)
---
name: fix-issue
description: Fix a GitHub issue
disable-model-invocation: true
---
Analyze and fix: $ARGUMENTS
1. Check issue with `gh issue view`
2. Search code → fix → test → create PR

There is a case of applying this to video production automation. Researcher, script, subtitles, voice, scene design, rendering, QA — split into 7 agent skills. Work that took 9 hours was reduced to 30 minutes.

Hooks — Mandatory Rules AI Cannot Ignore

Hooks are mechanisms that force-execute tasks that AI might ignore even when instructed via prompt. Registered in settings.json, they run automatically when specific events occur. Prompts can be skipped. Hooks cannot. Exit code 0 means allow, 2 means block.

I documented the 5 most commonly used hooks in practice:

// settings.json — practical Hooks config
{
  "hooks": {
    // 1. Auto-format after file edit
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{ "type": "command",
        "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write" }]
    }],
    // 2. Block dangerous commands (rm -rf /, git reset --hard)
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{ "type": "command",
        "command": ".claude/hooks/pre-bash-firewall.sh" }]
    }],
    // 3. Auto-verify on task completion
    "Stop": [{
      "hooks": [{ "type": "prompt",
        "prompt": "Check if all tasks are complete. Continue if incomplete." }]
    }],
    // 4. macOS desktop notification
    "Notification": [{
      "hooks": [{ "type": "command",
        "command": "osascript -e 'display notification \"Claude Code\" with title \"Needs attention\"'" }]
    }]
  }
}

Hooks that enforce package managers are also useful. In a pnpm project, if AI tries to use npm, it gets blocked:

#!/usr/bin/env bash — enforce pnpm Hook
cmd=$(jq -r '.tool_input.command // ""')
if [ -f pnpm-lock.yaml ] && echo "$cmd" | grep -Eq '\bnpm\b'; then
  echo "This repo uses pnpm. Replace npm with pnpm." 1>&2
  exit 2  # block
fi
exit 0  # allow

Things to Watch When Connecting MCP

MCP is an adapter that connects AI agents to external tools. Like a USB hub — it attaches external capabilities like Gmail, browser automation, and document search to AI. In practice, it's used to automatically send a report email via Gmail MCP after completing Excel work.

There is a caveat. Connecting more MCPs is not better. It wastes tokens and creates confusion. The principle is to connect only what's needed. If it feels like MCP is being forced into use, removing it is the right call.

MCP Connection Principles

Connect only what's immediately needed

The more connections, the higher the chance of AI judgment errors

Disconnect MCPs that are not actually being used

Excessively connected MCPs waste the context window

Practical Application — Difference Seen in Before/After

The OpenAI Codex experiment is the representative case. 5 months, 1 million lines of code, 0 lines written directly by humans. 1,500 PRs merged. One engineer completed an average of 3.5 tasks per day. In Terminal Bench 2.0, the same model (Opus 4.6) ranked 40th with the default harness (Claude Code defaults) and 1st with an optimized harness. The harness, not the model, determined the ranking.

Mitchell Hashimoto (HashiCorp founder) summarized the core principle this way. "Every time the agent makes a mistake, engineer it so that mistake can never happen again." Not fixing mistakes, but building a structure that makes mistakes impossible.

I summarized specifically how it differs in a Before/After breakdown:

Before (Prompts Only)	After (Harness Applied)
"Make an email validation function"	"Write validateEmail. Tests: user@example.com → true, invalid → false. Run tests after implementing"
"Make the dashboard look nice"	[Screenshot attached] "Implement this design. Take a screenshot of the result and compare with the original"
"Build failed"	"Failed with this error: [paste error]. Don't suppress the error — fix the root cause"
Full test output of 4,000 lines printed	Hooks silence success, show only failures (Back-Pressure pattern)

Common Anti-Patterns to Avoid

Kitchen Sink Session — mixing unrelated tasks in one session → reset context with /clear

Same fix repeated 3 times — learning failure → new prompt reflecting the failure cause after /clear

CLAUDE.md exceeding 200 lines — context waste → keep only essentials, move the rest to Skills

Endless exploration — investigation request without scope → split into sub-agents

There is one common thread. The initial setup takes time. Once built, subsequent iterations automatically accelerate. The setup cost is one-time; the effect is cumulative.

Core Principles in Design

Giving only the final goal is not enough. Intermediate stage verification criteria must also be specified. Not "just produce the output" but "must pass this criteria at this stage to proceed to the next." When goals are vague, AI looks for shortcuts.

Semi-automatic structures with explicit approval gates are more realistic than fully automatic. In the video production automation case, approval gates were placed at 4 points: script, voice, scene design, and QA. Not AI running to the end alone, but humans checking in between. At the current level of technology, this is the realistic choice.

Fix code patterns before they go wrong. Lock good rules in with linters and tests. Remove stale rules quickly. If AI follows incorrect past rules, problems accumulate.

Design Checklist

Context file (CLAUDE.md etc.): under 300 lines, short table-of-contents style

MCP: only what's needed. More connections means more confusion

Remove stale documents. If AI follows old rules, work goes wrong

Design human intervention gates explicitly

Specify verification criteria for each intermediate stage

You Don't Have to Be a Developer

Harness engineering is not a concept exclusive to development. The same structure works for general tasks like Excel automation, video production, and data analysis. Even people unfamiliar with vibe-coding can design a harness. You can start by writing a single CLAUDE.md file first.

The role of developers is changing. From people who write code to people who design environments where agents can work well. The core of AI development has shifted from prompts to harness. If you're just starting out, begin with a single CLAUDE.md.

Frequently Asked Questions

Q. What is the difference between harness engineering and prompt engineering?

If prompt engineering is the craft of refining what and how to ask AI, harness engineering is the craft of designing the entire environment in which AI works. It includes context files, skills, MCP, hooks, execution loops, verification processes, and human intervention points. A prompt is part of the harness. Harness is a bigger concept than prompts.

Q. How long should CLAUDE.md be?

Under 300 lines is recommended. The longer it is, the more context window it consumes, degrading AI performance. Keeping it short like a table of contents, not a long manual, is key. Writing only "where to find what" is enough. Separate detailed rules into skill files.

Q. Is it better to connect more MCPs?

No. Connecting more MCPs leads to token waste and confusion. The principle is to connect only what's needed. The more connections, the higher the cost of AI deciding which tool to use. If it feels like it's being forced, removing it is the right move.

Q. Can non-developers apply harness engineering?

Yes. Harness engineering is not a concept exclusive to development. The same structure works for general tasks like Excel automation, video production, and data analysis. Even people unfamiliar with vibe-coding can design a harness. It's simply a matter of documenting what rules AI should follow to work.

Q. Where should harness design start?

Starting by writing a CLAUDE.md (or Agent.md) file is the fastest approach. Documenting project structure, code rules, and completion criteria in under 300 lines is the first step. MCP or skill files come after. There's no need to have all five elements from the start.

Official Documentation and References

The figures in this article (OpenAI Codex 1 million lines, Terminal Bench 2.0, Wharton GAIL CoT study, etc.) are cited from public announcements and papers. Some figures require separate verification from the original papers or official blog posts.

Last updated: April 2026. Harness engineering is a rapidly evolving concept. Tools, APIs, and configuration methods can change at any time.

Originally published on GoCodeLab

I Was Tired of Sorting User Feedback, So I Let AI Classify It

LazyDev_OH — Sat, 11 Apr 2026 01:00:03 +0000

April 2026 · Lazy Developer EP.05

In EP.04, I built FeedMission in 7 days. Feedback started coming in. At first, it was great. But once it starts piling up, a different problem emerges. "Please add dark mode." "It hurts my eyes at night." "Add a background color option." Three people said three different things, but the request is the same. Manually grouping these is fine when there are 10. Past 50, just reading them eats up your time.

I asked Claude: "Can you automatically group similar feedback?" The answer was "embeddings."

Quick overview

Convert feedback text into a 1024-number array with Voyage AI (embeddings)

Simultaneously analyze sentiment scores (-1.0 to 1.0) with Claude Haiku

Enable the pgvector extension on PostgreSQL for vector storage + similarity search

Cosine similarity >= 0.85 means same group; below that creates a new group

When a group grows, Claude automatically re-generates the name and summary

The entire pipeline runs in the background via the after() pattern

It all fits in 188 lines of clustering.ts

"Group similar feedback" — but how?

"Please add dark mode" and "It hurts my eyes at night" share zero words. But they're the same request. How do you tell a computer that? You convert the sentence into 1024 numbers. Similar meanings produce similar numbers. Think of it like a food delivery app — searching "late night cravings" finds both fried chicken and pork feet at the same time. It searches by meaning, not by matching words.

"Why not just send two pieces of feedback to Claude and ask if they're similar?" Of course that works. But with 100 feedback items, that's 4,950 comparison pairs. Calling the Claude API for each one is unmanageable in both time and cost. With embeddings, you create them once and the DB handles comparisons with math. Measuring distances between numbers finishes in milliseconds.

Embeddings aren't a silver bullet, though. They're weak with numbers. "I need 3 buttons" and "I need 30 buttons" have completely different meanings, but their embedding coordinates come out nearly identical. Negation is the same problem. "Dark mode is great" and "Dark mode is terrible" land on similar coordinates. I'm aware of this. But given the nature of feedback, these cases weren't common. Build a structure that covers 80% quickly, and fix the remaining 20% when actual problems arise.

My first embedding with Voyage AI

// lib/ai/embeddings.ts
const response = await fetch('https://api.voyageai.com/v1/embeddings', {
  body: JSON.stringify({
    model: 'voyage-3-lite',
    input: ["Please add dark mode"],
  }),
})

// → [0.0234, -0.0891, 0.0412, ...] (1024 numbers)

I ran sentiment analysis at the same time with Claude Haiku. "Please add dark mode" came back as 0.1 (neutral), "Why isn't this available yet?" came back as -0.4 (negative). Same request, different temperature. Both tasks run simultaneously with Promise.all. Sequential takes 500ms; parallel takes 300ms.

pgvector — storing 1024 numbers in the DB

There are dedicated vector DBs like Pinecone. But I was already using Supabase PostgreSQL. pgvector lets you store and compare vectors in your existing DB.

// prisma/schema.prisma
model Feedback {
  embedding  Unsupported("vector(1024)")?  // ← this
  sentiment  Float?
}

But Prisma doesn't officially support pgvector. Declaring it as Unsupported creates the schema, but you can't read or write this column through the normal Prisma API. You have to write raw SQL — a hybrid approach. Not elegant, but it works.

"Find things similar to this" — similarity search

SELECT id, title,
  1 - (embedding <=> $1::vector) as similarity
FROM "Feedback"
WHERE "projectId" = $2
  AND id != $3  -- exclude self (important!)
ORDER BY embedding <=> $1::vector
LIMIT 5

And AND id != $3. Forgetting this one cost me quite a while. The item matched itself with similarity 1.0. Obviously. It's the most similar to itself. Every new piece of feedback joined an existing cluster, and new clusters never got created. Fixed with one line, but took a while to find.

The first trap in vector similarity search

If you don't exclude the item itself from results, you always get similarity 1.0. Every piece of feedback gets classified as "identical to something that already exists," and new groups never get created. A single line — AND id != $3 — determines the correctness of the entire logic.

0.85 was the answer — how I chose the threshold

I created 20 pieces of test feedback and experimented directly.

Threshold	Result
0.70	"Dark mode request" and "UI color change" in the same group — related but different requests
0.80	"CSV export" and "data download" in the same group — borderline
0.85	"Please add dark mode" and "It hurts my eyes at night" in the same group — correct
0.90	Only nearly identical sentences matched — too strict

Cluster assignment — join or create

// clustering.ts:87
const bestMatch = similar.find(
  s => s.similarity >= 0.85 && s.clusterId
)

if (bestMatch) {
  // join existing group
} else {
  // ask Claude for a name and create new group
}

Every time a group grows, the name gets regenerated at multiples of 3 (or at 2). Calling Claude every time would inflate API costs.

How Claude names the groups

// Claude response example
{ "title": "Dark Mode / Theme Custom",
  "summary": "Users are requesting dark mode and theme color options" }

Worked well. But occasionally Claude wrapped the JSON in a code block. Running JSON.parse on that obviously throws an error. I added a defensive regex to strip the code block markers. AI responses are never 100% predictable. You always need a fallback.

Priority — what to look at first

// clustering.ts — priority formula
votes 50% + feedback count 30% + recency 20%

// 50 votes = max score, 10 feedbacks = max score
// recency hits 0 after 50 days since last feedback

This formula produces a score between 0 and 100. 70+ shows in red, 40+ in yellow, below that in green.

AI auto-classified cluster list / GoCodeLab

The after() pattern — users don't wait

This entire pipeline runs inside the feedback submission API. Making the user wait 2 seconds after pressing "Submit Feedback" is bad UX.

// app/api/feedback/route.ts
const feedback = await prisma.feedback.create({ ... })
const response = NextResponse.json(feedback, { status: 201 })
// ↑ immediately return "received"

after(async () => {
  await processFeedbackAsync(feedback.id)
  // ↑ embedding + clustering runs in background
})

return response

Feedback → AI clustering pipeline full flow / GoCodeLab

Problems I ran into

Self-similarity of 1.0 — Forgot AND id != $3, so new groups never got created
NaN mixed into embeddings — Without isFinite() validation, the DB gets corrupted
Priority score of 0 for new groups — Only called recalculatePriority() when joining an existing group
Claude wrapping JSON in code blocks — Regex stripping + try-catch + fallback are essential

Automated feedback classification in 188 lines

clustering.ts — the entire pipeline fits in 188 lines. 2 external APIs (Voyage + Claude), 5-7 DB queries, 1 branch. All in one file, so the flow is easy to follow.

FAQ

What is an embedding?
It converts a sentence into an array of numbers. Sentences with similar meaning produce similar number patterns, and comparing the numbers lets you calculate "how similar" they are.

Why is pgvector needed?
It's an extension that adds vector storage + similarity search to existing PostgreSQL. No separate vector DB needed.

How did you decide on 0.85?
Experimented with 20 pieces of feedback. 0.7 was too broad, 0.9 was too narrow. At 0.85, "the same request worded differently" grouped well.

Can you use pgvector with Prisma?
No official support yet. Declare the vector column as Unsupported and use raw SQL for reads/writes.

What is the after() pattern?
A pattern that sends the response first and runs additional work in the background. The user doesn't wait.

Originally published at GoCodeLab

I Built a SaaS in 7 Days

LazyDev_OH — Sat, 11 Apr 2026 01:00:02 +0000

April 2026 · Lazy Developer EP.04

After building Apsity in EP.02, feedback from 12 apps started pouring in. Emails, reviews, DMs. At first I organized them in a spreadsheet. But "please add dark mode" and "my eyes hurt at night" are the same request, just written by different people in different words. Grouping similar requests, assigning priorities, notifying when they're resolved. All manual. The spreadsheet kept growing but never got organized.

There's a service called Canny. It does exactly this. Feedback collection, voting, roadmap. But the pricing starts at $79/month. Too much for an indie developer. If existing tools are too expensive or don't fit, I build my own.

I decided to build a SaaS with everything: feedback collection, AI auto-classification, public roadmap, changelog, voting, and email notifications. Named it FeedMission. This post is the record of how it started.

The finished FeedMission landing page / GoCodeLab

Quick Overview

Canny at $79/mo → too expensive for indie devs → decided to build it myself

Designed AI clustering on top of the Next.js + Supabase stack I learned from Apsity

Handed Claude a structured spec → MVP of 10,742 lines in 52 minutes

9 DB models, 12 APIs, 8 dashboard pages, widget, AI pipeline — all in one commit

The real work came after the MVP — structural changes, performance, and security took far more time

I defined what I was building

I didn't just tell Claude "make me a feedback tool." I had the Apsity experience. I knew that specific requirements produce specific results. I signed up for Canny, Nolt, and Fider and used them myself. Features they all shared: feedback boards, voting, roadmap, changelog. That's the baseline. But I wanted one more thing — when feedback piles up, automatically group similar items together.

// My FeedMission requirements
Core: Feedback collection widget + public board + voting
Management: Roadmap kanban + changelog + email notifications
AI: Auto-classify similar feedback (embeddings + clustering)
AI: Sentiment analysis + auto-generated insights
Revenue: FREE / STARTER $9 / PRO $19 plans
Platforms: Script + React + iOS + Android + iframe + GTM

The MVP came out in 52 minutes

March 26, 9:41 AM. Started the project with create-next-app. Fed Claude the organized requirements and started building.

10:33 AM. Pushed the commit.

234006b feat: FeedMission full MVP implementation
73 files changed, 10742 insertions(+)

52 minutes. 73 files. 10,742 lines. Vibe coding is fast, but the reason isn't "Claude wrote the code" — it's "I knew exactly what I was building." When requirements are clear, Claude's output is precise.

What was inside the MVP

// 9 DB models (Prisma)
User, Project, Feedback, Cluster, RoadmapItem,
Changelog, Vote, NotificationLog, Subscription

// 12 API routes
/api/feedback — feedback CRUD + widget CORS
/api/clusters — AI cluster view/edit
/api/roadmap — roadmap kanban CRUD
/api/changelog — changelog + auto email on publish
/api/dashboard — stats aggregation (8 queries in parallel)
/api/insights — AI insight card generation

// 8 dashboard pages
Overview, Feedback, Clusters, Roadmap,
Changelog, Notifications, Widget, Settings

// 3 AI pipeline files
clustering.ts — feedback → embedding → cluster assignment
embeddings.ts — Voyage AI vector generation + Claude sentiment analysis
summaries.ts — Claude generates cluster titles/summaries + insights

The Feedback model has an embedding vector(1024) column. Feedback text gets converted into 1024 numbers via Voyage AI and stored. pgvector handles similarity search on these numbers. "Please add dark mode" and "my eyes hurt at night" end up with similar number patterns and automatically get grouped together.

FeedMission Dashboard Overview / GoCodeLab

The gap between "working code" and "product"

It built successfully. No type errors either. But the moment I actually used it, things to fix started piling up.

First: the sidebar was eating too much screen space. Switching to a top navigation took 4 minutes. Second: UUIDs were baked into the URLs. I refactored to slug-based routing — 13 files were referencing params.projectId. Third: after deploying to production, it was slow. The Vercel Function was running in the US, while the Supabase DB was in Seoul. Every query was crossing the Pacific Ocean.

The reality of vibe coding

This is why you can't ship AI-generated code as-is. Region settings, middleware optimization, security vulnerabilities, CLS — these only become visible when you actually run and use the code. Claude generates the first draft quickly, and I spend my time asking: "Why is this slow?", "Is this URL structure right?", "Should this data really be exposed?"

What happened over the next few days

By midnight on Day 1, I had 5 performance-related commits stacked up. Changed the Vercel region to Seoul (icn1), skipped unnecessary auth calls for public routes in middleware, added Prisma singleton caching, and matched skeleton heights to eliminate layout shift.

For 5 days I didn't touch the code and just used it myself.

On Day 6: improved 38 files in one go. 7 security patches, 6 DB indexes, dashboard parallel query optimization. Expanded the widget SDK to 5 types, built iOS SwiftUI and Android Kotlin native widgets. Integrated LemonSqueezy payments and pivoted pricing from KRW to USD. Along the way, I accidentally committed 686K lines of node_modules and pushed a deletion commit 28 seconds later.

7-day timeline of 51 commits / GoCodeLab

Metric	Value
Total Commits	51
Claude Co-Authored	37 (72.5%)
Active coding days	3 (out of 7)
MVP generation time	52 min

72.5% was AI, the rest was judgment

37 out of 51 commits have the Claude Co-Authored-By tag. 72.5%. This doesn't mean "Claude built 72.5% of it." I organize the requirements, Claude generates code, I review, modify, and commit.

This is why vibe coding isn't "letting AI do everything." Build fast, use it fast, decide fast. What speeds up isn't code generation — it's the entire feedback loop.

FAQ

Is a 52-minute MVP actually usable?
"Working code" came out in 52 minutes. But bringing it to product quality took the remaining 6 days. The MVP is a starting point, not the finish line.

Is building your own better than using Canny?
Depends on team size and budget. If $79/month is a stretch and you need custom features like AI auto-classification, building your own might be the way to go.

How does AI clustering work?
Feedback text gets converted into 1024 numbers (embeddings). Sentences with similar meanings produce similar number patterns. Comparing them and grouping items with similarity above 0.85 into the same cluster. Covered in detail in EP.05.

Is code quality from vibe coding acceptable?
It works at the MVP stage, but you can't ship it as-is. I separately fixed 7 security vulnerabilities and 4 performance issues. AI generates the first draft, but human review is always required.

Originally published at GoCodeLab

DEV Community: LazyDev_OH

Teaching Claude to Play Tetris with 100 App Store Characters

The Constraints That Break Generic LLMs

Why Claude Sonnet

The Prompt Structure

Generating Keywords

Validation Is Where Production Code Lives

The Output Nobody Asks For But Everyone Needs

Prompt Failures I Hit Along the Way

Where This Lives Now

The Claude Code Skill Set I Actually Run — Mapped by Dev Task

Skill vs Plugin

The 4 Plugins I Run

Task-to-Skill Map (7 Tasks × Set)

UI / Frontend — Draft to Review

Backend · API — Next.js Fullstack

Deploy · Infra — On Top of Vercel

Planning · Research — Before the Code

Review · Debug — The Last Gate

Process · Docs — When Docs Become Necessary

Mapped Onto the EP.19 5-Agent Team

Skills I Tried and Dropped

When to Build Your Own Skill

Closing

Same Claude, Different Roles — My 5-Agent Dev Team

Why Quality Shifts With the Role

The 5 Agents (Copy-Paste Ready)

Cross-Session State via Supabase

MCP Servers for Per-Role Permissions

The Actual Routine

What Changed, What Didn't (Honestly)

Closing

axios npm Supply Chain Attack (March 31, 2026) — What Happened and How to Check Your Lock File Right Now

How to Check Right Now

The 3-Hour Timeline

How the Malicious Code Works

Attack Vector — Maintainer Account Hijack

Attribution

Remediation

Rotate All Credentials — Not Just Env Vars

Prevention Routines

Why This Keeps Happening

Key Takeaways

Vercel vs Netlify vs Cloudflare Pages 2026 — Deep Comparison with Real Numbers

Quick Summary

What Each Platform Actually Is

Free Tier Deep Dive

Paid Plans and Overage Simulation

Vercel Fluid Compute — Real Savings

Cold Start Benchmarks — 5ms vs 250ms vs 3 Seconds

Next.js Feature Compatibility Matrix

Cloudflare Ecosystem — KV · D1 · R2 · Durable Objects

Edge Network and Global TTFB

Netlify Credit-Based Pricing

Full Comparison Table

Combining Platforms — Real-World Patterns

Recommendations by Scenario

Closing Thoughts

I Catalogued the Security Patterns That Keep Showing Up in AI Code

The numbers, first

How AI skips security

Top 7 mistakes — in the order I hit them

1 and #3 hit fastest. The moment you push to GitHub, scraper bots scoop the key and burn your API quota. If you've never been hit, you've only been lucky.

What could have happened at FeedMission

My 10-minute pre-deploy routine

Bonus — Using Supabase? RLS is its own chapter

Wrap-up

Sources

Upgraded to Tailwind v4 — Config Files Are Gone

What Changes

Config Moved into CSS

@theme Naming Convention

Oxide Compiler

Migration Steps

Option A — one command

Option B — manual (Next.js / PostCSS)

Plugins Now Live in CSS

The outline-none Gotcha

v3 vs v4 at a Glance

Should You Upgrade Now?

The `outline-none` Gotcha