Forem: LazyDev_OH

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

The Dashboard Was There But I Didn't Know What to Do, So I Let AI Handle It

LazyDev_OH — Fri, 10 Apr 2026 01:57:29 +0000

March 2026 · Lazy Developer EP.03

I had a dashboard. Built it in EP.02. Every day at 3 AM, a Cron job runs. By morning, all of yesterday's data for 12 apps is there. Downloads total, revenue, keyword rankings. Everything on one screen. It took days to build, and it saved me 15 minutes every morning.

But about three days in, a different kind of question lingered. "The finance app downloads dropped 22% today." The number was right there on screen. So what? I didn't know why it dropped. I didn't know what to do about it. The dashboard showed me what happened. The judgment was still on me. Having a dashboard actually made things more tiring in a way — the decisions I needed to make became painfully clear.

So I decided to automate the judgment part too. I built an AI growth agent inside Apsity. That's what this post is about.

Quick Overview

Dashboard shows "what happened," but "why" and "what to do" were still on me

Designed 5 analysis patterns: rank drop diagnosis, hidden markets, keyword optimization, review analysis, revenue breakdown

Confidence badge on every insight: Fact / Correlation / Suggestion

Indie app filter excludes enterprise apps (1,000+ ratings), analyzes only comparable apps

Second Claude API integration — auto-generates 100-character keyword sets, suggests app names, extracts insights

Auto growth stage detection: SEED -> GROWING -> STABLE

Weekly email report added: Monday 8 AM, auto-sent via Resend + React Email

First run: 12 apps, 48 insights generated automatically

What existing tools don't tell you — and the price tag

There are plenty of App Store analytics tools out there. AppFollow, Sensor Tower, MobileAction, plus App Store Connect itself. They all do the same thing. "3,240 downloads this week." "Keyword ranking change: -5." Numbers showing what happened.

The pricing tells the story. Sensor Tower's enterprise plan starts at $30,000/year. AppFollow has a $39/month basic plan, but it caps at 5 apps. Managing 12 means upgrading, and the cost jumps. So most indie developers end up using App Store Connect's built-in analytics.

No matter which tool you use, the "so what?" question remains. Why did it drop? Did a competitor change something? Is my keyword the problem? Is there a signal in the reviews? To figure that out, you have to dig through the data yourself. The tools don't dig for you.

What I wanted was different. Give it data, and it tells me the cause. If there's a cause, it tells me what to do. If it knows what to do, it gives me something I can use right now. Not "you might want to change your keywords" but "copy this 100-character set and paste it into your App Store keyword field."

AI Growth Agent — a system that makes judgments for you

I wrote up my requirements and handed them to Claude. "Not just showing what happened — diagnose the cause, provide verifiable evidence, and deliver ready-to-use outputs." It was a one-line description. Claude broke it into 5 analysis patterns.

// 5 Analysis Patterns
1. Rank Drop Diagnosis — Why it dropped, including competitor changes
2. Hidden Market Discovery — Keywords where my app isn't showing but opportunities exist
3. Keyword Optimization — Current keyword analysis + auto-generated 100-char optimal set
4. Review Keyword Analysis — Recurring patterns extracted from user reviews
5. Revenue Breakdown — Subscription vs IAP anomaly detection + cause hypotheses

Patterns alone are meaningless. What matters is how trustworthy each result is. Not everything AI says is fact. Something read directly from data, something inferred from patterns, and something AI suggests — these are fundamentally different. Without distinguishing them, you'd treat inferences as facts.

Why I added confidence badges

I attached a confidence badge to every insight card. There are three types.

Badge	Meaning
Fact	Directly confirmed from real data. Like "downloads dropped 22% yesterday" — a measured figure.
Correlation	Inferred from patterns between data points. Like "competitor updated their description right before your ranking dropped" — related but not causally confirmed.
Suggestion	AI reasoning based on analysis. Like "adding this keyword could increase impressions" — data-informed but not certain.

Each card also has a [View Evidence] toggle. Click it, and you see the raw data: "34% drop from 7-day download average, competitor A changed 3 metadata fields in the same period." You can check what data the AI used to produce the insight. So you can judge for yourself whether to trust it.

This is a design decision, but it's also a philosophy. You shouldn't just follow what AI says. You should be able to see why it said it. That way, you'll know when it's wrong, too.

Indie app filter — wrong comparisons make analysis useless

While designing the competitive analysis, I hit a problem. Even within the same category, some apps shouldn't be compared. Official apps from major banks, apps from companies like Naver or Kakao. They have different marketing budgets, different ASO strategies, and hundreds of thousands of ratings. If an indie developer gets compared against them by the same standards, no meaningful insight comes out.

I asked Claude, and it suggested a rating-count filter. Apps with 1,000+ ratings get classified as enterprise and excluded from comparisons. Apps with 50-1,000 ratings get classified as indie successes and used as the comparison baseline.

The indie app filter logic is simple. On the App Store, an app's rating count correlates with downloads. Over 1,000 ratings means significant marketing investment — that's not indie. Meanwhile, 50-1,000 ratings means somewhat validated but still indie-scale. That's the range you actually want to compare against.

Competitors menu — checking every day if someone changed something yesterday

Once you register a competitor, a Cron job calls the iTunes Lookup API every day at 4 AM KST to fetch that app's latest metadata. App name, subtitle, description, icon, version. These five fields get saved daily, compared against the previous day, and any changes get logged.

Open the menu and you see the list of registered competitors. Apps with recent metadata changes rise to the top, showing which fields changed. Click on a changed field to see the previous and current versions side by side.

At first I thought, "Does this even matter?" So a competitor changed their description — what can I do about it? Using it changed my mind. Three competitors of my finance app updated their descriptions and keywords on the same day, and my ranking dropped right after. The MetaChange log had the dates and exact changes. It's correlation, not causation, but without this data, tracking down the cause would have taken much longer.

Plugging Claude API into Apsity — in the Keywords menu

I added two more specific features. Auto-generating an optimal 100-character keyword set, and suggesting app names and subtitles based on indie success patterns.

// POST /api/growth/keywords-generate
// App name, category, current keywords -> Claude -> 100-char optimal keyword set

const prompt = `
App: ${appName} (${category})
Current keywords: ${currentKeywords}
Top indie app keyword patterns: ${indiePatterns}

Generate an optimized keyword set within 100 characters for the App Store keyword field.
Remove duplicate words, separate with commas, no spaces after commas.`

There are rules for the keyword field:

No space after commas (even one space counts toward the character limit)
No plurals (App Store auto-matches from singular)
Don't repeat app name or category name (they're already indexed)
Fill all 100 characters (empty space = wasted exposure)
Include review keywords (frequent words from review text act as search signals)

Keyword Optimization — Copy the AI-generated 100-character optimal set with one click / GoCodeLab

Adaptive growth stage mode — from SEED to STABLE

After building all the analysis features, one problem became obvious. Running "revenue anomaly detection" on a freshly launched app is pointless. There's no data. On the flip side, only running basic keyword generation for a well-established app is a waste.

Claude proposed auto-detecting growth stages:

🌱 SEED — Less than 30 days of downloads or under 500 cumulative. Focuses on initial setup: keyword auto-generation, app name suggestions.
🌿 GROWING — Download trend is rising or stable. Rank drop diagnosis, hidden market discovery, and competitor change detection all activate.
🌳 STABLE — Over 3 months of accumulated data. Revenue anomaly detection, review keyword analysis, and long-term trend pattern analysis activate.

Auto growth stage detection — each stage activates different analyses / GoCodeLab

Claude reviewed my code

I tried something new this time. I had Claude review the code it wrote. After everything was built, I said: "Review this entire codebase. Focus on things that could break in production."

The results were more specific than I expected:

// [Critical] 1st Review — Key Issues
1. MetaChange relation missing — DB save without linking relation table
2. JSON.parse unprotected — No try-catch on external API response parsing
3. Cron timeout — Timeout risk when processing 12 apps sequentially

// [Critical] 2nd Review — Key Issues
4. iTunes API rate limit — 429 risk from calling in a loop with no delay
5. Review country hardcoded — Only collecting KR, missing other countries
6. ASC data delay — Yesterday's data may not be available at early morning

There was a strange feeling. Code written by Claude, reviewed by Claude, bugs found by Claude, fixed by Claude. The line between what I built and what it built got even blurrier. But I'll take that feeling over things breaking in production.

Weekly email report — a summary arriving Monday at 8 AM

Insights were being generated, but you could only see them by opening the dashboard. I set up weekly reports to be emailed automatically using Resend + React Email + Vercel Cron.

// vercel.json — Cron schedule
{
  "crons": [
    { "path": "/api/cron/collect", "schedule": "0 18 * * *" },      // 3 AM KST daily
    { "path": "/api/cron/analyze", "schedule": "30 10 * * *" },     // 7:30 PM KST daily
    { "path": "/api/cron/weekly-report", "schedule": "0 23 * * 0" } // Monday 8 AM KST
  ]
}

The email contains last week's per-app download and revenue summary, the top 3 insights (with confidence badges), and one immediately actionable item. Long emails don't get read, so the goal was to fit everything on one screen without scrolling.

Weekly email report — auto-sent Monday 8 AM, everything fits on one screen / GoCodeLab

First run — 48 insights

I deployed the Cron and triggered it manually. 12 apps processed, total execution time 38 seconds. 48 insights generated.

Different kinds of insights came in for each app. The finance app was STABLE, so revenue anomaly detection ran. The habit tracker was GROWING, so competitor change detection ran alongside it. A recently launched app was SEED, so only keyword auto-generation insights came through.

One insight caught my eye. "Over the past 14 days, 3 competitors simultaneously updated their metadata for the 'budget' keyword cluster, and your app's ranking for those keywords dropped an average of 8 positions since." Confidence badge: Correlation. I clicked [View Evidence] and verified the data manually. It checked out.

Below that insight card was a keyword set with a copy button. Claude had generated it incorporating the competitive keyword changes. I copied it and pasted it into App Store Connect. The flow itself — change detection, cause hypothesis, response keyword generation, copy — all happened automatically. That's the point.

FAQ

Q. What exactly is an AI growth agent?

Existing tools show you numbers. "Downloads down 22%." The AI growth agent goes one step further. It proposes a hypothesis for why it dropped, shows the supporting data, and produces a ready-to-use deliverable for your response.

Q. How do the confidence badges work?

Fact means read directly from data. Correlation means inferred from patterns between two data points. Suggestion means AI reasoning. Check the badge and decide how much to trust it.

Q. Why is the indie app filter based on rating count?

Rating count correlates with downloads. Over 1,000 means significant marketing has already gone in, and indie developers shouldn't benchmark against that. The 50-1,000 rating range represents apps that succeeded under similar conditions.

Q. How are the growth stages determined?

They're auto-detected every time the daily Cron runs. It evaluates data collection duration, cumulative downloads, and recent trend direction. When the stage changes, the types of analysis change too.

Q. Can vibe coding really produce features like this?

I built it, so yes. The key is being clear about what you want. Claude structured the code and wrote most of it, but the decisions about which features were needed, ideas like confidence badges — those were mine. It's become more about judgment than coding skill.

Originally published at GoCodeLab

I Got Tired of Checking Revenue for 12 Apps, So I Built My Own Dashboard

LazyDev_OH — Fri, 10 Apr 2026 01:57:26 +0000

March 2026 · Lazy Developer EP.02

I have 12 apps on the App Store. It started with one. One becoming two was natural. Two becoming five was ambition. Five becoming twelve was the result of not stopping. Having more apps isn't bad — the problem is that the number of things to check grows at the same rate.

I built a dashboard that shows all 12 apps' revenue, downloads, and keyword rankings on a single screen. I named it Apsity. I connected the App Store Connect API and set it up to pull data automatically every night. This post is the dev journal of that process.

The dashboard I built — data from all 12 apps on one screen / GoCodeLab

Quick Overview

App Store Connect's Sales and Trends aggregation is being deprecated between 2026–2027

Decided to build my own data pipeline before it disappears

Threw two lines of requirements at Claude and locked in the Next.js + Supabase + Vercel architecture

Connected the App Store Connect API with JWT authentication, parsed TSV data

Vercel Cron auto-syncs at 3 AM daily, after() pattern handles 12 apps in parallel

Now when I wake up, yesterday's data is already there

What's the Problem with App Store Connect?

Let me clear something up first. App Store Connect's Sales and Trends does let you view aggregated data across all your apps. As of now, you can see Units, Proceeds, and Sales bundled for all apps. No need to click into each one — the totals are right there. So saying "ASC can't aggregate" would be wrong today.

The problem is that this is about to go away. In March 2026, Apple announced a major Analytics overhaul and said they're phasing out the Sales and Trends dashboard. Subscription dashboards start disappearing mid-2026, and the rest follows through 2027. The new Analytics comes with over 100 per-app metrics — cohort analysis, peer benchmarks, subscription data. But the ability to view multiple apps aggregated on a single screen? Gone.

John Voorhees at MacStories nailed it: "There will no longer be a single place to see aggregated performance across multiple apps." Steve Troughton-Smith put it as "App Store Connect had a big scary overhaul and now everything is in the wrong place." Apple acknowledged the feedback about cross-app reporting, but acknowledging and fixing are two different things.

I decided to build my own before it all disappears. What I wanted was more specific than what ASC offered anyway. Not just aggregated numbers — I wanted keyword ranking, competitor tracking, and AI analysis, all in one place. The aggregated dashboard was the most urgent piece, so I started there.

I Threw the Requirements at Claude

I didn't architect this alone. I opened a fresh Claude session and just wrote what I needed. "I'm a developer running multiple iOS apps and I want to see revenue on a single screen. App Store Connect API integration. Keyword ranking." Two lines.

Claude came back with a stack proposal:

// Initial architecture proposed by Claude
Framework: Next.js — builds the frontend and backend in one package
DB: Supabase — cloud database with real-time sync, like a spreadsheet but smarter
Auth: Supabase Auth — handles login/session management automatically
Deploy: Vercel — push code and it's live on the internet, with built-in timers
Charts: Recharts — a library for rendering graphs and charts

By the first evening, the basic structure was in place. Things moved so fast that I actually had to make more decisions, not fewer. Claude recorded those decisions in CLAUDE.md. Even when sessions were interrupted, context like "why we recreated the Supabase project in US East instead of the India region" was preserved. The automation I built in EP.01 paid off right here.

Connecting the App Store Connect API — JWT Authentication Was the First Wall

You can't just access the App Store Connect API. You have to generate a JWT token yourself. JWT is like a digital ID card that proves "I'm really the developer." You sign it with a private key issued by Apple, include an expiration time, and match Apple's exact encryption method (ES256). Reading about it makes sense, but when you actually build it, something always goes wrong.

I handed Claude the Apple documentation link and said, "Generate this JWT in TypeScript." I pasted the code it returned, ran it, and the first API call went through. A response came back. In TSV format. TSV is a text file with tab-separated columns — like a spreadsheet but in plain text. When that wall of text hit my terminal, I knew it was just data, but it still felt good. Something was connected.

The next problem was parsing that data. The sales report has dozens of columns. The key one is a field called productType — a single number. 1 means download, 7 means in-app purchase, 8 means subscription. Apple uses this number to classify transaction types. If you scatter this logic throughout your code, you'll have to hunt down every instance when Apple changes the spec. Claude suggested creating a single classification function called categorize(). All type detection goes through this one function, and the rest of the code just reads the result. It still runs that way today.

Currency Conversion Strategy

Revenue aggregation across countries is trickier than it sounds. Sales in Korea come in KRW, sales in Japan come in JPY. If you convert manually using exchange rates, yesterday's revenue might look lower than today's just because of currency fluctuation. Apple already provides a USD-converted value in the proceeds field. Claude suggested aggregating only that value. Consistent dollar-based trends with no exchange rate distortion. Made sense, so I used it as-is.

Vercel Cron Automation — Data Piles Up While I Sleep

The API was connected. I could read the data. Now I needed this to run automatically every day. Vercel has a feature called Cron. Like a smartphone alarm — you set "run this at this time every day" and it handles the rest.

// vercel.json — Cron schedule
"/api/cron/daily-sync"     → Every day at 3 AM KST (UTC 18:00)
"/api/cron/daily-rank"     → Every day at 3:30 AM — keyword ranking collection
"/api/cron/cleanup"        → Weekly — auto-purge old data

3 AM in Korea is 18:00 UTC. I timed it for when the previous day's data is finalized. The first night after deploying, I checked the Vercel logs from bed. The Cron had run, the API had been called, and data was sitting in Supabase. When I opened the dashboard that morning, yesterday's download numbers were already there. I hadn't done anything, but the data was there. That feeling was stranger than I expected. In a good way.

Then a problem appeared. With 12 apps, the sync job needs to run 12 times. Vercel Cron kills any job that doesn't finish within 10 seconds. Processing them one by one takes over 20 seconds. If it gets cut off at 10 seconds, the remaining apps don't get synced.

I explained the situation to Claude, and it suggested the next/server after() pattern. Like a cashier at a convenience store saying "thank you" the moment payment is done, then printing the receipt afterward — respond first, then process in the background.

// Respond immediately → process 12 apps in parallel in the background
export async function GET() {
  after(async () => {
    await Promise.all(apps.map(app => syncApp(app)))
  })
  return NextResponse.json({ ok: true }) // Respond immediately before timeout
}

It returns "job complete" instantly. From Vercel's perspective, a response came back, so no timeout. The actual sync runs in the background inside after(). All 12 apps start at the same time. Like opening 12 bank teller windows at once instead of making 12 people wait in a single line. Applied it, and the timeout was gone.

What's Inside the Dashboard

Here's what the finished product looks like. When you open the dashboard, the first thing you see is four metric cards: total downloads today, total revenue (USD), active subscribers, and best keyword ranking. Each card has a small 7-day trend graph inside it.

Scroll down and there's a per-app performance table. App name, yesterday's downloads, yesterday's revenue — all in one row, sorted by revenue descending. The Revenue tab shows a stacked chart over 30 days with app sales, in-app purchases, and subscriptions color-coded. The Keywords tab shows a scatter plot of keyword rank vs. difficulty. X-axis is difficulty, Y-axis is rank. Upper-left quadrant is the sweet spot — low difficulty, high rank.

// Keyword opportunity score calculation
const opportunity = (1 - difficulty/100) * (200 - rank) / 2

// difficulty = based on rating counts of the top 10 apps for that keyword
// fewer ratings means indie apps can break through
if (score >= 70) → 'Hard'
if (score >= 40) → 'Medium'
else             → 'Easy'

I also built a competitor tracking tab. Register up to 5 apps in the same category, and it compares their metadata changes (name, subtitle, description) daily. The Countries tab shows which countries are driving download growth. The Subscriptions tab shows active subscriber counts and renewal rates. Some of this overlaps with what ASC's new Analytics provides per-app. The difference is seeing all 12 of my apps in one place.

Revenue tab — 30 days of revenue auto-aggregated by type / GoCodeLab

How the Data Gets Stored

Data started flowing in daily as the Cron ran. But accumulating data creates new problems. DB costs go up, old data rarely gets looked at, and cleaning it up manually is yet another chore I don't want. That's where the cleanup Cron came from. Every Sunday at dawn, it automatically deletes data beyond a certain age. Claude suggested this one first. On my own, I probably wouldn't have thought about it until the data had piled up for months.

Keyword ranking collection had its own quirks. If you call the iTunes Search API too fast inside a loop, you get hit with 429 (rate limit). I fixed it by adding a 300ms delay between requests. ASC data also has occasional delays — yesterday's data might not be available at 3 AM. I added retry logic so it tries again 6 hours later if the data isn't ready.

This is the part where vibe coding isn't just "Claude writes code so it's fast." It catches future pain points early. Cleanup Cron, rate limit protection, retry logic — I would have only built these after something broke if I'd been working alone.

The App Works for Me Now

Here's how Apsity runs today. Every day at 3 AM KST, the Cron calls the App Store Connect API. Downloads, revenue, and country-level data from the previous day land in Supabase. 30 minutes later, keyword rankings are collected. When I open the dashboard in the morning, all 12 apps' data from the day before is already there. Aggregation is automatic. Ranking changes are visible immediately.

It took a few days to build. After that, I got back 15 minutes every morning. 15 minutes times 365 days is 91 hours. 91 hours is enough to build the next app. And when Apple finally sunsets Sales and Trends, there will be no way to see cross-app aggregation in ASC. Having my own pipeline before that happens is the right call.

If It's Tedious, Just Build It

There's a pattern that keeps repeating throughout this series. If something is tedious, build a solution. Right now, building things is a lot less tedious than it used to be. Even if terms like JWT, Cron, and after() feel unfamiliar, it doesn't matter. Ask Claude "what is this and how do I use it?" and it explains and writes the code. Hand it a link to official docs and it reads them and implements. When the timeout issue came up, I just described the situation and the fix appeared. My job is judgment — is this the right direction? Does this approach fit our situation?

After building Apsity, the next tedious thing appeared. The dashboard showed data, but the question "so what should I do?" remained. The numbers were going down, sure, but figuring out why was still on me. In EP.03, I talk about the AI growth agent that automates even that judgment.

FAQ

Q. Can't you already see aggregated revenue across all apps in App Store Connect?

Yes. Currently, Sales and Trends does support cross-app aggregation. But Apple announced they're phasing out Sales and Trends starting mid-2026. The new Analytics only supports per-app analysis — cross-app aggregation is missing. It works now, but it won't for long. I built my own pipeline before it disappears.

Q. Isn't connecting the App Store Connect API difficult?

It's unfamiliar at first. You need JWT token generation, ES256 signing, and TSV parsing. But give Claude the Apple documentation link and it writes the code right away. Half a day and the API connection was working. Much faster than digging through the docs yourself.

Q. Do you need coding skills to build an app with vibe coding?

Having a clear idea of what you want matters more than coding skills. If you can describe what you want to build in plain language, Claude handles a significant portion. Making judgment calls and setting the direction is still on you.

Q. Can you automate Cron jobs on Vercel's free plan?

Yes. The free plan has a short timeout, but if you use the after() pattern — respond immediately and process in the background — you can sync all 12 apps without hitting the timeout.

Q. Wouldn't it be better to just use an existing ASO tool instead of building your own?

Depends on what you need. Tools like Sensor Tower or AppFollow are feature-rich but can be expensive for indie developers. If you want exactly the features you need and nothing more, building your own can make sense. And the process of building it is a learning experience in itself.

Originally published at GoCodeLab

AI Writing Tools Compared: ChatGPT vs Claude vs Gemini vs Notion AI (2026)

LazyDev_OH — Fri, 10 Apr 2026 01:40:29 +0000

In an 8-round blind test that started with 134 participants (dropping to 111 by round 8), Claude won 4 rounds, Gemini 3, and ChatGPT 1. For pure writing quality, Claude is the current leader.

But writing quality isn't everything. Here's how all four compare.

Quick Comparison

	Claude	ChatGPT	Gemini	Notion AI
Writing Quality	#1	#2	#3	#4
Versatility	High	Best	High	Limited
Research	Web search	Web + images	Google integration	Workspace
Context	200K (Pro) / 1M (Max+)	128K	2M tokens	Limited
Image Gen	No	GPT Image built-in	Built-in	No
Price	$20/mo	$20/mo	$19.99/mo (AI Pro)	$10 add-on (legacy)

Claude — Writing Quality Champion

In a blind test (source: aiblewmymind, 134 participants in round 1, 111 by round 8), Claude won 4 of 8 rounds. The key strength is tone consistency — even in long pieces, the writing doesn't drift. "Least AI-sounding" was the most common feedback.

Pro defaults to a 200K token context, while Max, Team, and Enterprise unlock 1M. That's enough reference material for style-matched output. The downside: no image generation. You'll need ChatGPT or Gemini for visuals.

ChatGPT — The Swiss Army Knife

Writing, image generation (GPT Image), web search, code execution, data analysis — all in one place. Need a chart while drafting? Just ask. Deep Research mode can search the web, compile sources, and write a draft in one go.

Writing quality is a step below Claude, but it's more than good enough for short-form: social media copy, emails, ad text. Hundreds of millions of weekly users means the largest ecosystem of plugins and references.

Gemini — Research-Powered Writing

The strength is Google integration. Gmail, Google Docs, Google Search — all connected. "Summarize project-related emails from the last 3 months into a report" actually works. Note: Google rebranded Gemini Advanced to Google AI Pro at I/O 2025, priced at $19.99/month.

2 million token context (on Gemini 1.5 Pro) is the real weapon for writing. Feed in 10 papers at once and get a synthesis. For academic writing or research-heavy reports, nothing else comes close.

Notion AI — Your Workspace Knows Context

Different from the other three. Not a standalone AI — it's an assistant attached to your Notion workspace. It reads your project databases, meeting notes, and docs.

"Summarize the status of 50 tasks and identify blockers" — Notion AI can do this because it already has the context. Standalone writing quality falls behind, but in-context writing is where it shines. Legacy subscribers can still attach AI for $10/month, but starting in 2026 new Free/Plus users can't buy the add-on — AI is bundled only into the Business plan ($20/user/month).

Blind Test Results

Tool	Wins (out of 8)	Key Feedback
Claude	4	Most natural, minimal editing needed
Gemini	3	Well-structured, consistent
ChatGPT	1	Fast and versatile

Which One to Pick

Use Case	Pick	Why
Blog posts, essays, long-form	Claude	Natural tone, consistency
Social copy, emails, ads	ChatGPT	Fast, varied outputs
Research papers, reports	Gemini	2M context, Google integration
Team docs, meeting notes	Notion AI	Workspace context
Writing + images together	ChatGPT	GPT Image built-in

You don't have to pick just one. Write the draft in Claude, generate images in ChatGPT, fact-check with Gemini. $40–60/month gets you the full AI writing stack.

Originally published at GoCodeLab. Blind test source: aiblewmymind (134 participants in round 1 → 111 by round 8, Feb 2026, 8 rounds).

Forem: LazyDev_OH

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?

FAQ

Sources

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

Quick Take

MoE vs Dense

Context Window — 10M, 256K, 128K

Benchmarks

Multimodal — Images, Video, Audio

Licenses (Actually Read Before Shipping)

Edge Deployment Reality

How to Combine All Three

FAQ

Sources

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

What Is Harness Engineering

The Full Structure at a Glance

init-harness: From Analysis to Generation

The Command Pipeline

Planner → Generator → Evaluator

What Hooks Enforce

Full Automation Mode

What Changed

Frequently Asked Questions

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

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

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

Q. Can this structure be used for team projects?

Wrapping Up

Harness Engineering — The Environment Matters More Than the Prompt

What Is a Harness

The Limits of Prompt Engineering

The `outline-none` Gotcha