Forem: Shakirul Hasan

How I'm running an autonomous Claude Code loop on a real shipped product

Shakirul Hasan — Tue, 28 Apr 2026 08:56:56 +0000

type.win is a Balatro-styled typing arcade I built — two games, a leaderboard, live on Cloudflare Workers. The interesting part isn't really the game, though. It's that the bulk of the routine commits to it are written by an autonomous Claude Code loop, not by me directly.

I review a dev branch periodically and merge it to main. The loop never touches production and never deploys. It opens PRs, auto-merges them when CI is green, and builds shared knowledge across sessions through a handful of markdown files in the repo.

This post is about how that loop is structured, what works, and what's already broken.

The MAPE-K shape

MAPE-K is a self-adaptive systems pattern from early-2000s autonomic computing: Monitor, Analyze, Plan, Execute, plus shared Knowledge. The shape maps surprisingly well onto autonomous coding agents.

Each session of the loop runs the same five phases inside an isolated git worktree.

1. Monitor — load shared knowledge before doing anything

The session has no memory of prior runs except what's persisted to the repo. So phase one is reading:

.claude/invariants.md — hard rules. "Leaderboard logic must remain server-trusted." "No theme toggle." "Desktop only."
The last 20 entries of changelog.md — what predecessors did, what's partial or blocked.
.claude/rejected-decisions.md — proposals already explored and explicitly rejected. Don't re-propose.
nextideas.md — my directional file. Priorities, ideas, occasional hard directives.
gh pr list --state open — currently-open PRs, mapped to the files they touch. Those files are claimed; this session must not modify them.

This phase is non-negotiable. Skipping it produces drift, duplicate work, and re-litigation of decisions I already made.

2. Analyze — pick exactly one task by tier

Strict priority order:

Tier A — a real bug. Run bun run test, npx tsc --noEmit, bun run check. If anything fails on main, that's the highest priority. Otherwise scan recent commits, dead code, missing test coverage on security paths, a11y gaps.
Tier B — planned work. Smallest shippable slice from nextideas.md.
Tier C — improve an existing AI-authored PR. Rebase, fix CI, address reviewer notes.
Tier D — a new idea. Only if A through C produced nothing.

The phrase "do not invent bugs" under Tier A is load-bearing. Without it, the loop fabricates problems to look productive.

3. Plan — scoped, explicit, security-aware

For anything touching the leaderboard, HMAC, or session tokens, the plan has to walk through the entire tamper surface. For anything touching the PixiJS scene, the plan has to address the React-isn't-aware-of-frame-state pattern (more on that below).

4. Execute — TDD, then PR

Tests first. Code second. Open a PR against dev (never main). Auto-merge if CI is green.

5. Knowledge — append to changelog

The session writes a single changelog.md entry: what was done, what's left, what surprised it. The next session reads this. It's the only memory across sessions.

Stack notes for anyone curious

The product is TanStack Start (React 19, file routing, SSR) on Cloudflare Workers. PixiJS v8 for Word Fall, plain DOM for Type Race. Drizzle + Neon Postgres. Clerk for auth.

A few non-obvious choices worth pulling out:

PixiJS inside React without re-render storms

The Word Fall scene is a plain TS class instantiated once in a useEffect. It owns the app.ticker.add loop and mutates Pixi objects directly every frame. Per-frame state never goes through React — that would re-render the tree at 60fps and tank everything. React only hears about gameplay through a batched event emitter for the HUD (score, WPM, lives, streak).

There's also a React-owned ResizeObserver that imperatively calls scene.forceSize(w, h), in addition to PixiJS's own resizeTo. PixiJS's observer can silently fail on iOS Safari URL-bar animations, leaving app.screen stuck at 0 and freezing the loop. The redundant path is intentional — don't remove it.

Leaderboard tamper-proofing

Client is fully untrusted. Every score submission has to satisfy:

Clerk auth (no token → 401)
HMAC-signed session token, single-use, 1h expiry, replay-protected via a used_sessions PK
Zod discriminated union (Word Fall and Type Race have different shapes and caps)
Math-consistency check on the submitted score
Server-side WPM recomputation for Type Race — client never supplies WPM
Cloudflare native rate-limit binding, 5 req / 10s / user

// wrangler.jsonc
"ratelimits": [
  {
    "name": "LEADERBOARD_RATE_LIMITER",
    "namespace_id": "1001",
    "simple": { "limit": 5, "period": 10 }
  }
]

20 dedicated unit tests cover tamper vectors. Any change to that path has to keep them green — and the loop knows this from the invariants file.

What's already broken

A few honest failures from the first few weeks:

Drift toward speculation. Once Tier A and B are exhausted, sessions reach for Tier D too eagerly. My current guards are rejected-decisions.md plus the strict tier order, but the loop will sometimes invent borderline-justified work to look productive.
File-claim race. Two sessions starting within the same minute occasionally both pick the same file before one publishes its draft PR. Solvable, but ugly.
Changelog noise. Sessions over-document the obvious. I haven't found the right prompt phrasing to keep entries terse without losing useful signal.

If you're running a similar loop on a real product, I'd love to hear what broke first for you, and how you guard against scope drift after the obvious bugs are fixed.

Try it

Live: ~type.win~. Desktop only — PixiJS particle layer plus keyboard-first input.
Roast everything. Especially the loop architecture — I want to know where this falls apart at scale.

Why Should You Not Use px?

Shakirul Hasan — Wed, 10 Jan 2024 15:09:35 +0000

Using px or pixels in CSS sizing is generally not recommended. This document explores alternative units of measurement that can be employed instead of px. But first, let's delve into why px is often considered a poor choice.

The Problem with Pixels

Everything displayed on a screen comprises pixels. But why does using pixels for measurement pose a problem? Websites are viewed on a variety of screens, each differing in size, orientation, zoom levels, and pixel geometries. What looks perfect on one screen might be distorted on another.

Consider a div on your website set to 600px, occupying half of your screen. When you resize the screen, zoom in or out, or view the site on a mobile device, your website might not display as intended. Moreover, in CSS, a pixel doesn't always correspond to a physical pixel on your screen. On high-resolution displays, several device pixels can combine to form a single CSS pixel.

Additionally, pixel-based sizing scales poorly. For users with poor eyesight who have increased their device's font size, a fixed font size like 14px on your website might render the text unreadable, as it doesn't adjust to their preferred settings.

Alternatives to Pixels

So, what are the alternatives to using px? Units like em, rem, ch, ex, vh, vw, and others offer more flexibility. Let's explore them in detail.

Understanding `rem` and `em`

The rem unit is relative to the font size of the root element of the document, which is usually the <html> element. This means that if the font size of the <html> element is set to 16 pixels, 1rem will be equivalent to 16 pixels. Using rem for font sizes, margins, padding, and other properties ensures consistency throughout your website. For example, setting paragraph font sizes to 1rem means that they will scale appropriately if the user has different default font size settings in their browser. This makes rem particularly useful for maintaining accessibility, as it adapts to the preferences of users with poor eyesight.

The em unit is relative to the font size of the element it's used on. It's useful for scaling designs within an element, such as for text, margins, and padding. If em is used for an element's font size, it's relative to its own font size. For other properties, it's based on the element's text size.

Take a look at the example:

<style>
  html {
    font-size: 16px;
  }
  h2 {
    font-size: 2.5rem;
  } /* 40px if root font size is 16px */
  h2 span {
    font-size: 2em;
  } /* Twice the font size of h2 */
</style>

<h2><span>Larger</span> Text</h2>

In this example, changing h2's font size automatically adjusts the <span> size, showcasing em's adaptability.

What Are `ch` and `ex`?

Ch and ex units refer to the width and height of a character, respectively. 1ch is the width of the character 0, and 1ex is the height of the x character in your font. For instance, if you want a paragraph with a consistent character count per line regardless of font size, you can use:

<style>
  p {
    max-inline-size: 30ch;
  }
</style>

<p>Long text...</p>

Viewport Units

Viewport units are responsive to the size of the user's browser window. 1vw represents 1% of the viewport's width, and 1vh is 1% of its height. To create a div that takes half of the viewport's width, set its width to 50vw. The same concept applies to vh.

Additionally, vmin and vmax are based on the smaller and larger dimensions of the viewport. A div with width: 50vmin and height: 50vmax occupies 50% of the viewport's smallest width and largest height.

Percentages (%)

Percentages are relative to the size of the parent element. For example:

div {
  width: 600px;
}

div p {
  width: 50%;
}

In this case, the p tag inside the div will be 300px wide.

Absolute Lengths

CSS also offers units like cm, mm, in, pt, etc., based on physical measurements. However, like px, these units can vary depending on the screen and are typically not recommended.

In conclusion, while pixels may seem straightforward, they often lead to less flexible and accessible designs. Embracing alternative units like em, rem, ch, ex, vw, vh, vmin, vmax, and percentages can make your web designs more adaptable and user-friendly.

Read the post on Medium, Substack or LinkedIn