# Edu Wass

> Senior Full-Stack Engineer building production systems and high-performance web platforms with TypeScript, PHP, and modern backend stacks.
Source: https://eduwass.com/

---

# Contact
Source: https://eduwass.com/contact/

You can reach me at: **eduwass [at] gmail.com**

If you'd prefer to chat, book a slot below:

---

# About
Source: https://eduwass.com/about/

- [Resume](/resume/): Check my experience. Available to download or print.
- [Testimonials](/love/): A collection of kind words from clients and colleagues.

---

# Resume
Source: https://eduwass.com/resume/

# Edu Wass
Senior Software Engineer (Full-stack)

## About

I'm Edu Wass, a senior full-stack engineer with a Computer Science background and 10+ years of experience building production web platforms and backend-heavy systems.

I specialise in system design, API architecture, real-time features, and performance optimisation. I'm comfortable owning features end-to-end — from scoping with stakeholders through to shipping and rollout — and I make pragmatic decisions when trading off speed and completeness.

Comfortable across TypeScript and PHP, from Node.js and custom APIs to database modelling and cloud infrastructure. I've worked across startup-to-scale transitions, managing technical debt while keeping systems reliable.

Outside of work you'll find me enjoying music production, sports and fitness, or gaming.

## Work Experience

### 2020 — Now — Senior Full-stack Engineer / Consultant — Toptal & Arc.dev — Remote

Senior full-stack consulting across product teams at growth-stage companies, owning features from scoping through to production. Focused on platform architecture, API design, performance, and reliable delivery.

- [MailCharts.com](https://web.archive.org/web/20250127114105mp_/http://MailCharts.com): Owned development of the marketing and product platform for an email intelligence tool used by data-driven marketing teams. Built scalable content systems and maintained high-availability front-end infrastructure.

- [Harver.com](https://web.archive.org/web/20250127114105mp_/http://Harver.com): Led redesign and implementation of a high-scale assessment platform serving enterprise customers, with a focus on reliability and performance under load.

- [GirlsWhoCode.com](https://web.archive.org/web/20250127114105mp_/http://GirlsWhoCode.com): Improved platform performance and stability for a high-traffic nonprofit site running large-scale campaigns.

- [MediaMath.com](https://web.archive.org/web/20250127114105mp_/http://MediaMath.com): Designed and built an internal product catalogue system, working across data modelling, API integration, and orchestration within a wider martech ecosystem.

### 2025 — Now — Lead Engineer — EventIntel — Remote

Building an event intelligence platform integrating third-party APIs including Ticketmaster and RateHawk. Designed the system architecture, data models, and API layer from scratch. Shipping iteratively in a lean setup with a strong focus on getting working product in front of users fast.

### 2016 — 2018 — [CTO at Container Studio](https://web.archive.org/web/20180203092811/http://containerstud.io/) — London / Barcelona

Technical lead at a small product studio, responsible for architecture decisions, stack choices, and delivery across client projects.

- Built a headless architecture bridging a PHP CMS backend with a React front-end via a custom REST API layer, allowing teams to decouple content management from UI delivery.

- Built containerised deployment infrastructure using Docker with PHP, Nginx, Git, and webhooks, cutting environment setup time significantly and standardising deployments across projects.

- Designed and shipped UX and front-end for Harbour Space, a technology university in Barcelona, and led development of the new Ubiqum platform, an international coding bootcamp.

### 2017 — [Lecturer at HARBOUR.SPACE University](https://harbour.space/faculty/edu-wass) — Barcelona

Lectured on technology stack decisions across MVP, growth, and scaling stages — covering infrastructure, backend, mobile, and front-end tradeoffs. Applied and practical, aimed at students building real products.

### 2016 — [Lead Developer at Tribe Interactive](https://www.madebytribe.com/) — Remote

Led development across ecommerce client projects, with a focus on growth automation, conversion optimisation, and custom platform builds. Worked closely with the commercial team to understand client goals and translate them into technical solutions.

### 2015 — 2016 — [Full Stack Developer at TheGeorge](https://www.iamthegeorge.com/home/en) — Barcelona

Full-stack engineering at an international agency working with large-brand clients including Microsoft, Pearson, Samsung, and Nestlé.

- Designed and built the Microsoft Windows 10 Italy campaign site, a high-traffic promotional platform coordinating content from Italian YouTubers to drive product adoption.

- Architected and delivered the Monza F1 circuit website, solving for spike traffic during race season using caching and load balancing techniques.

- Built the Wall Street English multisite network (~25 country sub-sites), designing shared infrastructure with per-locale customisation.

- Planned and built the backend of AskCucu, an Airbnb-style student housing platform for the Asian market.

## Education

### 2010 — 2016 — [BSc Computer Science at Universitat Politècnica de Catalunya](https://web.archive.org/web/20250127114105/https://www.upc.edu) — Barcelona

Computer Science degree from one of Spain's leading technical universities, covering algorithms, systems design, databases, and software engineering fundamentals.

## Certifications

### 2018 — [Startup School 2018 — Y Combinator](https://web.archive.org/web/20250127114105/https://www.startupschool.org/)

---

# One Theme, Every Tool: monotheme
Source: https://eduwass.com/building-monotheme/
Date: 2026-06-24

I change color themes the way other people change desktop wallpapers. The problem: my "environment" isn't one app, it's twenty. Ghostty, tmux, Neovim, VSCode, Cursor, Zed, btop, lazygit, yazi, fzf, bat, opencode, Claude Code, even the macOS accent color and Raycast. Switching themes meant hand-porting the same six colors into twenty config formats, getting bored halfway, and living with a half-themed setup forever.

So I built [monotheme](https://github.com/eduwass/monotheme): one source of truth, one command, everything reskins at once.

<video src="demo.mp4" autoplay loop muted playsinline style="width:100%;border-radius:8px"></video>

```bash
theme set <name>
```

Repo: **[github.com/eduwass/monotheme](https://github.com/eduwass/monotheme)**.

## The canonical format problem

The naive approach is to invent your own theme schema — a little YAML file with `background`, `foreground`, eight ANSI colors — and generate everything from that. I tried. It falls apart the moment a real editor wants syntax highlighting, because "the color of a comment" isn't one color. It's the resolution of a TextMate scope like `comment.line.double-slash.ts` against ~140 scope rules with fallbacks.

A 16-color palette can't represent that. So I flipped it: the **canonical format is the full VSCode theme** — the fat one, all 140-odd TextMate scopes intact. That's the source of truth. Everything else *projects down* from it.

- A dumb tool (fzf, btop) gets the normalized 16-ANSI palette.
- A smart tool (Neovim, bat) gets the full scope resolution.

Keep the richest representation as canonical, lose nothing, throw away detail only at the edges where the target can't use it anyway.

## The pipeline

Four stages, each boring on purpose:

```
load → project → adapter → target
```

`load` parses the VSCode theme JSON. `project` derives the normalized palette — bg, fg, ANSI 16, accents — and exposes `resolveToken`, which maps any TextMate scope to its color through a matcher algorithm I ported from VSCode's own resolver. Then each **adapter** renders that into one tool's native format, and each **target** writes the file to the right place and reloads the running app.

The split between adapter (what to write) and target (where to put it and how to reload) is the part that made the whole thing extensible. Adding a new tool is one adapter + one target, and it never touches the core.

## Live reload

`theme set` doesn't just write configs — it reloads the apps that are already running. tmux gets a `source-file`, Ghostty re-reads, Neovim instances get poked. The win isn't really the command, it's that there's no follow-up: no "now restart your terminal," no stale half-themed windows. You run one command and the whole screen flips.

## Install

Needs [Bun](https://bun.sh).

```bash
git clone https://github.com/eduwass/monotheme
cd monotheme && bun install && bun link
```

That puts a `theme` command on your PATH:

```bash
theme list          # installed + bundled themes
theme set <name>    # project to every tool + live-reload
theme current       # active theme
theme check         # self-check, no writes
```

Drop `theme init` in your shell rc so a fresh shell re-applies the active theme, and you're done.

It won't touch tools you don't have — if Zed isn't installed, that target is skipped. Start with one or two tools, add adapters as you go.

Repo: **[github.com/eduwass/monotheme](https://github.com/eduwass/monotheme)**.

---

# A Raycast-Style Command Palette for tmux
Source: https://eduwass.com/tmux-palette/
Date: 2026-05-13

<video src="demo.mp4" autoplay loop muted playsinline style="width:100%;border-radius:8px"></video>

Tweeted a screenshot of this earlier today, people asked for the code, open-sourced it the same day: **[github.com/eduwass/tmux-palette](https://github.com/eduwass/tmux-palette)**.

tmux has a million commands and zero discoverability. You either know the bind or you don't. Raycast fixed that for macOS apps. This does the same for tmux: hit a key, fuzzy-find, run.

## The opentui detour

First version used [opentui](https://github.com/anomalyco/opentui) — flexbox layout in the terminal, theming, mouse events. Tutorial-clean code, ~50 lines per palette.

It shipped. It was slow.

```
=== bun no-op ===              0.00 s
=== bun + opentui import ===   0.19 s
```

opentui ships native Yoga bindings. They deserialize on import. Every popup open paid 190ms loading them before drawing a single character. Felt like a 200ms hiccup every time. `bun build --compile` doesn't help — it bundles the runtime, not the imports.

## The rewrite

I dropped the framework. The renderer now writes ANSI escape codes straight to stdout, like the prototype I started with.

```ts
stdout.write("\x1b[?2026h\x1b[?25l\x1b[H" + frame + "\x1b[?2026l")
```

That's the whole render call. `?2026h/l` is synchronized output — tmux 3.4+ swaps the frame atomically, so holding the arrow key doesn't flicker. Cold start went from 190ms to 20ms.

The framework gained ~100 lines for manual width/scroll/mouse handling. Each palette stayed the same size. Net wash on lines, 10× speedup.

## User-land config

Customization lives in `~/.config/tmux-palette/`. Four JSON files, one job each. Add your own commands without forking:

```json
// ~/.config/tmux-palette/commands.json
[
  { "icon": "", "title": "Toggle Diff Viewer", "category": "Tools",
    "action": { "tmux": "run-shell '~/scripts/diff-viewer.sh'" } }
]
```

`shortcuts.json` overrides the right-side label. `theme.json` overrides colors. `aliases.json` adds chips. The source-level `definePalette()` API is still there for power users, but nobody should have to fork to label a key.

## The dispatch trick

tmux's `confirm-before` and `command-prompt` need stdin. If you run them *inside* the popup, they hang — the popup owns stdin.

So the palette doesn't run the command. It writes the encoded command to a tempfile and exits. The bash wrapper reads the file *after* `display-popup` returns and runs it in the host context. Prompts get stdin, users press y/n, world keeps spinning.

```bash
tmux display-popup -E "TMUX_PALETTE_CMD='$CMD_FILE' bun src/cli.ts"
[ -s "$CMD_FILE" ] && eval "tmux $(cat "$CMD_FILE")"
```

Embarrassingly long to figure out the first time. Sub-100-byte fix.

## Install

```bash
git clone https://github.com/eduwass/tmux-palette ~/Sites/tmux-palette
cd ~/Sites/tmux-palette && bun install
```

Then in `.tmux.conf`:

```tmux
bind -n C-Space run-shell "~/Sites/tmux-palette/bin/tmux-palette.sh"
```

Reload, hit Ctrl+Space.

The README has an agent-handoff prompt — paste it into Claude Code / Codex / opencode / Cursor and it does the install, asks you which key to bind, optionally reads your terminal config and writes a matching theme. Onboarding via "paste this into your agent" feels right for 2026.

Repo: **[github.com/eduwass/tmux-palette](https://github.com/eduwass/tmux-palette)**.

---

# Replacing WordPress with 2,300 Lines of Bun
Source: https://eduwass.com/replacing-wordpress-with-2300-lines-of-bun/
Date: 2026-04-23

The site you are reading is around 2,300 lines of TypeScript, Edge templates, and CSS in `src/`. It scored 99/90/100/100 on PageSpeed the first time I ran it, with no performance work done. It builds in under half a second and deploys to a Cloudflare Worker in under 30 seconds on warm caches. It used to be WordPress.

This is the story of why and how I replaced a perfectly working WordPress site with a hand-rolled static site generator, what I built instead, and the weird decisions that ended up being the right ones.

## The old setup

The old eduwass.com was a WordPress install running locally on LocalWP, statically exported to a `/static/` directory via Simply Static, pushed to GitHub, and deployed as a Cloudflare Pages project watching `static/*`. The theme was a custom thing pieced together with the usual plugin pile: Perfmatters for lazy loading, ASE for email cloaking, a dark-mode toggle block, Yoast for SEO, the works.

It worked. It was also constantly costing me small bits of attention: plugin updates, theme drift, a PHP-ish local dev experience, an export step that occasionally produced weirdness, a local MySQL service running for no reason when I'd rather just edit markdown.

The irony was that I was writing plain content in the WordPress editor, then the export produced HTML files, then CF served them statically. At no point in the served-to-visitor path was there any dynamic WordPress behavior. I was paying WordPress's full complexity budget for the authoring side and getting a static HTML stack anyway.

So I ripped it up.

## The goal

Hard constraints I wrote down before starting:

- Every line in the repo is something I understand and can change. No "framework did this magic."
- Content stays portable. Markdown with YAML frontmatter, so if I ever want to move to Astro or Hugo, I copy `content/` and plug it in.
- Dev loop has to feel instant. Not "hit save, see reload a second later" instant — *actually* instant, with state preservation.
- No "click a link, wait for a blank page, see content" navigation feel. Prefetching, speculation rules, whatever it takes.
- Feature parity with the old site's quality-of-life stuff: email cloaking, redirect shortlinks (including cloaked ones that hide the destination), analytics, a GitHub contribution graph, syntax-highlighted code blocks.

I didn't write "deploy to Cloudflare" explicitly but it was implicit — the old site already lived there and I liked the edge-first distribution.

## The stack

Five production dependencies:

```
edge.js            templating
shiki              syntax highlighting
edge-iconify       icon rendering
@iconify-json/*    icon data (Lucide + Simple Icons)
```

Bun handles everything else: it's the runtime, the bundler, the dev server, the YAML parser, the markdown parser, the TypeScript transpiler. No Vite, no Webpack, no Astro runtime, no Node.js installed. One tool.

This was a deliberate bet. Bun is new enough to be nervous about, but it's good enough at each of those individual jobs that pulling in a separate tool for each felt like adding weight for marginal quality.

## The build pipeline

`src/build.ts` is 103 lines. Top to bottom, it:

1. Wipes `dist/` and rebuilds CSS and JS with content-hashed filenames.
2. Copies static media (avatar, favicons).
3. Runs an idempotent optimization pass: any raw PNG/JPG becomes AVIF at q60; any MP4 over 1.5MB gets re-encoded with x264 CRF 28 and audio stripped. On an already-optimized repo this is a no-op.
4. Loads every content collection in parallel (posts, pages, projects, site config, redirects, home content).
5. Fetches the GitHub contribution graph via `gh api graphql` at build time (no token shipped; the local `gh` CLI auth is trusted).
6. Constructs the speculation-rules URL list (every internal page, so the browser can prerender on hover).
7. Creates one Edge instance per build with all those collections attached as globals.
8. Renders each page, copies colocated assets, writes redirects, writes the sitemap, RSS feed, and robots.txt.

On a real run: 28 pages, 17 redirects, ~300ms. Warm dev server rebuilds in ~100ms.

## Content as portable markdown

Content lives in `content/`. Every page is markdown with YAML frontmatter:

```markdown
---
title: About
layout: about
links:
  - title: Resume
    href: /resume/
    description: Check my experience.
  - title: Testimonials
    href: /love/
    description: Kind words from clients and colleagues.
---
```

The `layout:` field names a template in `src/templates/pages/`. If absent, it falls back to the default prose wrapper. This is the same convention Hugo and Jekyll use, which means `content/` is fully portable: rename a file, drop it into an Astro or Hugo project, and it works.

The resume is the interesting case. It's a `.md` file with *no* body — everything is structured frontmatter (name, role, experience array, education array, etc.) — and it points at `layout: resume`, which is a standalone Edge template that emits its own `<!doctype html>` (no site chrome, matches how resumes want to look).

I experimented briefly with `.edge` files holding both data and layout in one file — a sort of single-file page format — and it's clever but it makes content less portable. Reverting to "content is markdown, layouts are templates" was the right call.

## The HMR trick

The dev server is where I spent the most design time, because I wanted it to feel *better* than framework dev servers, not worse.

The standard full-reload approach wastes everything. You're iterating on a CSS tweak, you scroll to the bottom of a long post to check a margin, save, and the page reloads back to the top. Every time. Intolerable.

So the HMR client (`src/dev/hmr-client.ts`, 90 lines) does a morph instead. On every file save:

1. Fetch the current URL's new HTML.
2. If the hashed CSS link changed, swap the `<link href>` — browser re-fetches styles, no flash.
3. If the hashed JS bundle changed, inject a fresh `<script src="/app.NEW.js">`. The new bundle takes over.
4. Use [idiomorph](https://github.com/bigskysoftware/idiomorph) to morph `<main class="wrap">` in place. Scroll position, focus, iframes — all preserved.

The JS hot-swap is the part I'm proudest of. Client-side app code usually can't safely re-execute because it binds event listeners; running init twice doubles them. My `app.ts` uses an AbortSignal pattern:

```ts
function setup(signal: AbortSignal): void {
  initThemeToggle(signal);
  initLazyMedia(signal);
  initHeatGraph(signal);
  initCalWidget(signal);
  initClickTracking(signal);
}

// At module top-level:
window.__appAc?.abort();           // kill the previous instance's listeners
const ac = new AbortController();
window.__appAc = ac;
setup(ac.signal);
```

Every `addEventListener` call inside `setup` takes `{ signal }`. When the signal aborts, all listeners detach automatically. That means re-executing the whole bundle is safe: the new instance aborts the old one, wires up fresh listeners, and the DOM never accumulates duplicates.

In prod this costs a single property write (`window.__appAc = ac`) and is never read. In dev it's the entire reason live JS edits work without reload.

The result: I edit a template, a CSS rule, or a TypeScript file in `src/scripts/`. The page updates in under 200ms, my scroll position is preserved, the theme toggle's state survives, any dev-only toolbar I have mounted (more on that in a moment) stays alive across the swap.

## Agentation for live feedback

Speaking of dev-only toolbars: for most of this rebuild I had [Agentation](https://www.agentation.com) mounted in dev. It lets me click any element on the page, write a comment, and have it delivered to the AI pair-programming in my terminal.

I paired it with a tiny webhook: the in-page toolbar's `onAnnotationAdd` callback POSTs the annotation to a dev-server route that appends to `/tmp/agentation-events.jsonl`, which Claude Code tails via a `Monitor` background task. Result: I drop a pin on a button, type "make this outline variant", and within seconds the change lands.

I shipped about twelve annotation-driven fixes this way during the rebuild. The feedback loop is absurdly tight — think of it as the visual equivalent of a REPL.

Critical to keeping it tight: no full page reloads. The HMR morph + AbortSignal dance means the Agentation toolbar's React tree survives every code edit. If I had to reload and re-mount it after every save, the whole loop breaks.

## Feature parity with WordPress plugins

**Email cloaking.** The old ASE plugin used HTML entity encoding, bidirectional text reversal, and a decoy span to fool scrapers while rendering correctly to humans. I ported it to `src/render/lib/email-cloak.ts` in 57 lines — random entity/percent encoding, reversed halves wrapped in `unicode-bidi: bidi-override; direction: rtl`, a hidden decoy string between them. Any bare email in markdown gets cloaked automatically during rendering.

**Redirect cloaking.** Some of my shortlinks (`/love` → my Senja testimonials page) I don't want search engines to index or casual URL-inspectors to see at a glance. The old WP setup used a plugin for this. In the new setup, redirects declare their type:

```yaml
- from: /love
  to: https://senja.io/p/eduwass/x4uHU08
  type: cloak
```

`type: 302` generates a meta-refresh page plus an entry in the `_redirects` file for Cloudflare to handle at the edge. `type: cloak` generates an HTML page that embeds the target in a full-bleed iframe — the browser URL stays `/love`, the content is the destination.

**Analytics.** Self-hosted Umami, script tag in a shared `components/analytics.edge` partial so both the main `<head>` and the redirect pages include it. I also added a ~15-line click tracker to `app.ts` that fires `umami.track("outbound", {url})` on external link clicks and `track("download", {file})` on file extensions. The old WP plugin did the same thing.

**GitHub contribution graph.** Built at build time via `gh api graphql`, cached to `.cache/` for an hour of fast rebuilds. The layout math is ported from the MIT-licensed `heat-graph` package — one function, 70 lines, no runtime dep.

**Speculation rules.** Declarative JSON in `<head>`: list every internal URL with `eagerness: "moderate"`, and Chrome prerenders on ~200ms hover. Clicks feel instant. This isn't a plugin in the WordPress world either — it's just a browser feature nobody uses.

## The deploy

I set up Cloudflare Workers (not Pages). The pitch for Workers is that one deployment serves both static assets and arbitrary dynamic code. Today the `wrangler.jsonc` declares pure-assets mode:

```jsonc
{
  "name": "eduwass",
  "compatibility_date": "2026-01-01",
  "assets": {
    "directory": "./dist",
    "not_found_handling": "404-page"
  }
}
```

No `main:` entry, so it's exactly a static site, same as Pages. But the day I want to add `/api/hello`, I add `main: "src/worker.ts"` and write a Worker — no migration.

GitHub Actions handles the build: install Bun, cache apt packages (libavif-bin needed for media optimization), cache Bun's install directory, run `bun run build`, deploy via `wrangler deploy`. 29 seconds end-to-end on warm caches.

One subtle piece: the workflow also runs on a daily cron (`17 6 * * *`, offset from the hour to avoid GitHub's :00 thundering herd). That keeps the GitHub contribution graph on the homepage fresh without me needing to push anything. The site literally rebuilds itself daily.

## The numbers

- **2,289 LOC** in `src/` total (TS + CSS + Edge).
- **5 production dependencies**. Everything else is devDeps.
- **99 / 90 / 100 / 100** PageSpeed mobile, out of the box.
- **0.8s** First Contentful Paint, **1.8s** LCP, **0** CLS, **0ms** TBT.
- **~300ms** full cold build. **~100ms** warm incremental rebuild in dev.
- **29s** GitHub Actions end-to-end deploy on warm caches.

I did not spend a single minute on performance optimization. These numbers fell out of: small client bundle (~7KB app.ts), system fonts, lazy media, content-hashed assets with long cache headers, speculation rules, content-visibility on below-the-fold grids. Good defaults compound.

## What I'd do differently

I flip-flopped on one design decision four times over the course of the rebuild: colocation (single `.edge` file with data-and-template) versus separation (`.md` content in `content/`, `.edge` layouts in `src/templates/`). I tried both, landed on colocation, got uncomfortable with the mixed extensions, and ended up back at separation. The lesson is that the thing that felt clever (one file for resume data + resume layout) was actually costing portability — and portability is the explicit goal. Don't get attached to clever structures when they fight your own constraints.

The other thing I'd tighten: I wrote a lot of comments explaining what the code does, then swept through and removed 250 lines of restating-the-obvious, keeping only the ones that explain *why* something non-obvious exists. The finished codebase is genuinely easier to navigate. If I'd been disciplined about this from the start, it would have saved time.

## What's next

Nothing, really. This post is the twelfth entry. The site loads under a second. The dev loop is faster than it needs to be. I can write posts in markdown, deploy by pushing to `main`, and forget about it until the next idea.

If you're considering a rewrite like this: the question isn't whether a tiny custom stack is technically feasible — it's whether you'll use the time you save not maintaining it on things worth doing. For me, the answer is yes. For a site with frequent contributors, a CMS with dashboard logins, or anything resembling a commerce flow: this is the wrong answer and you should use a framework.

For a personal site where you're the only one touching it and you value owning every line, 2,300 lines is plenty.

---

# More Agents Won't Save You
Source: https://eduwass.com/closing-the-loop-with-ai-agent-teams/
Date: 2026-03-10

Multi-agent coding is finally real enough to be useful, but only if you stop treating it like "more agents = more output".

What actually works is more disciplined than that:

- split work into vertical slices
- keep each slice independently testable
- run a tight red/green/refactor loop inside each slice
- group slices into waves
- add guard steps before the next wave
- keep a human orchestrator responsible for integration, judgment, and course correction

That is the workflow I keep coming back to, whether the tooling is Claude Code agent teams, Codex multi-agent workflows, or plain old terminal panes with separate worktrees.

The key idea is simple: parallelism is useful, but only if you preserve feedback loops.

## Why This Matters Now

Both Anthropic and OpenAI now expose explicit multi-agent workflows:

- [Claude Code agent teams](https://code.claude.com/docs/en/agent-teams) are designed for multiple sessions with a lead and teammates, with direct inter-agent communication and a shared task list. Anthropic explicitly frames them as best for research, reviews, new modules, and cross-layer work where parallel exploration adds value.
- [Codex multi-agent workflows](https://developers.openai.com/codex/multi-agent/) let the main agent spawn specialized agents in parallel, collect summarized results, and keep noisy intermediate work off the main thread.
- Both platforms also quietly point toward the same operating model: parallelize independent work, then centralize synthesis. Anthropic even documents hook points for blocking task completion or sending teammates back to work, which is basically a built-in place to enforce quality gates.

That last point matters more than it sounds. OpenAI's [Codex concepts docs](https://developers.openai.com/codex/concepts/multi-agents) explicitly call out `context pollution` and `context rot`: if you dump logs, notes, stack traces, and half-finished exploration into the main thread, the session gets less reliable over time. Their recommended answer is to offload noisy work to sub-agents and bring back summaries instead of raw junk. If you want the longer research backdrop on this, read Chroma's paper on [Context Rot](https://research.trychroma.com/context-rot).

This matches what many of us have learned the hard way: if the main thread becomes a landfill, the system stops thinking clearly.

For a good long-form conversation on the agentic loop side of this, the [Lex Fridman interview with Peter Steinberger](https://lexfridman.com/peter-steinberger) is worth watching: https://www.youtube.com/embed/YFjfBk8HI5o

## The Real Unit of Parallel Work Is the Vertical Slice

A lot of agent failures come from assigning work in horizontal layers:

- one agent does schema
- one agent does API
- one agent does UI
- one agent does tests

That looks parallel on paper. In practice it creates handoff debt, merge conflicts, and ambiguity about whether anything actually works end-to-end.

The better unit is a thin vertical slice:

- one behavior
- one observable outcome
- one acceptance test
- one narrow blast radius

In my own workflow, that usually means every slice should be demoable, reviewable, and verifiable on its own. If a slice cannot be tested independently, it is usually too wide.

This is also why skills and worktree-based setups matter. A good skill is not just a macro. It is a boundary. It narrows the job, encodes the operating procedure, and reduces how much improvisation the agent has to do. The same is true of one-issue-per-worktree setups, proof-oriented review flows, and repo-local rules like the ones behind this repo's `linear-workflow`, worktree conventions, and `reflect` habit.

## Red, Green, Refactor Is Even More Important With Agents

Matt Pocock made the point well in his [TDD workflow write-up and video lesson](https://www.aihero.dev/skill-test-driven-development-claude-code): agents tend to produce worse results when asked to write a whole feature and then test it afterward. That encourages horizontal slicing and imagined coverage.

If you want the video version directly in the article, here is a linked thumbnail to the AI Hero lesson:

[![Matt Pocock on TDD with Claude Code](https://image.mux.com/OFCUFTrdZ5nWYitP48eZfzaC3BRH9An1H3Zuab9dGvc/thumbnail.webp?time=0)](https://www.aihero.dev/skill-test-driven-development-claude-code)

The safer loop is the classic one:

1. `Red`: write one failing test for the next bit of behavior.
2. `Green`: write the minimum implementation to make it pass.
3. `Refactor`: clean up while the test suite stays green.
4. Repeat.

[Martin Fowler's TDD write-up](https://martinfowler.com/bliki/TestDrivenDevelopment.html) describes the same cycle as the heart of TDD: write a test for the next bit of functionality, write code until the test passes, then refactor both new and old code into a better shape.

For agents, this is not just software craft purity. It is a control system.

Why it works:

- it constrains the task size
- it creates a concrete feedback signal
- it limits hallucinated implementation
- it reduces the odds of the agent "cheating" by drifting the test to match broken code
- it gives the orchestrator a natural checkpoint after every meaningful step

When people say agents work best on "small tasks", this is often what they actually mean: tasks that still close the loop fast enough to produce trustworthy feedback.

## Waves and Gates Beat Unbounded Parallelism

The pattern that has worked best for me is to divide work into waves, then put a guard step between waves.

Within a wave, slices should be parallel-safe:

- separate files or directories
- clear ownership
- minimal hidden dependency between slices
- obvious verification for each slice

Between waves, the orchestrator runs a gate:

- merge or integrate the completed work
- run lint, typecheck, and tests
- run a smoke check if UI or runtime behavior changed
- inspect whether the architecture still makes sense
- decide whether to refactor before expanding the surface area

That gate is where you close the loop.

![](/closing-the-loop-with-ai-agent-teams/shapes-at-26-03-10-15.27.29-scaled.avif)

This is close to how I think about agent teams in practice:

- the wave creates concurrency
- the gate restores coherence

Without the gate, you do not have a workflow. You have fan-out and hope.

## "Closing the Loop" Is the Right Mental Model

Peter Steinberger uses language around the `agentic loop` and `closing the loop` that I think gets at something important. His [Lex conversation page](https://lexfridman.com/peter-steinberger), the [full transcript](https://lexfridman.com/peter-steinberger-transcript), and related essays like [Just Talk To It](https://steipete.me/posts/just-talk-to-it) and [My Current AI Dev Workflow](https://steipete.me/posts/2025/optimal-ai-development-workflow) all point in the same direction: autonomy gets more useful when the surrounding loop gets tighter.

In his conversation with Lex Fridman, the discussion is not just about letting agents run. It is about building the surrounding loop: queuing, memory, harnesses, follow-up actions, and the tricky balance between autonomy and human oversight. Lex explicitly frames the question as the tension between keeping a human in the loop and creating an agentic loop that is highly autonomous.

That is exactly the design problem.

For coding workflows, "closing the loop" means at least four things:

1. The agent gets a bounded task with a real verification target.
2. The result gets checked by something external to the agent's own narration.
3. The orchestrator decides whether to integrate, refactor, retry, or stop.
4. The learning gets captured so the next loop is cheaper and sharper.

That last step is underrated. In my own repo workflow, that can mean:

- updating repo rules
- tightening a skill
- improving a prompt template
- preserving a useful command or proof checklist

If you do not feed the lesson back into the system, you are not really closing the loop. You are just surviving one run at a time.

## A Practical Multi-Agent Pattern

Here is the operating model I would recommend for real work:

![](/closing-the-loop-with-ai-agent-teams/Untitled-2026-02-10-2224-1-1024x848.avif)

A few practical rules:

- Use parallel agents mostly for read-heavy exploration, bounded implementation, review, and verification.
- Avoid parallel writes to the same file.
- Keep 3-5 active workers unless the tasks are extremely uniform.
- Prefer one clear owner per slice.
- Do not let the main thread drown in worker output. Ask for summaries and proof.
- Refactor between waves, not only at the very end.

## Example 1: Shipping a Search Filter Feature

Imagine a product task like this:

> Add a "family-friendly" filter to event discovery, including ranking effects, UI state, and analytics.

Bad split:

- Agent 1: database
- Agent 2: backend
- Agent 3: frontend
- Agent 4: tests

Better split:

### Wave 1

- Slice A: represent `familyFriendly` in the search contract and verify it flows through the API
- Slice B: expose the filter in the UI and verify it survives reload/share state
- Slice C: add ranking behavior for the filter and prove relevant results move upward

### Gate 1

- typecheck
- API tests
- UI smoke test
- manual or scripted verification of search behavior

### Wave 2

- Slice D: analytics and observability
- Slice E: docs and reviewer proof

Why this split works:

- each slice is independently testable
- each slice has a visible user outcome
- the gate happens before more polish work accumulates

## Example 2: A Mid-Sized Production Repo

A mid-sized production repo naturally suggests multi-agent work when it already has strong procedural boundaries:

- a workflow tool pushes work into vertical slices, waves, and gates
- worktree conventions isolate branches and local environments
- a smoke-first testing harness supports UI verification
- recording and asset-upload tools turn verification into reviewable artifacts
- a "reflect" step closes the session by turning lessons into durable rules
- domain skills such as scraper, deployment, observability, and feature-port work encode specialized operating procedures

That means you can give agents jobs like:

- one agent ports a feature view
- one agent writes the smoke path
- one agent captures proof artifacts
- one agent updates the docs

That is not "AI doing random stuff in parallel". It is a small production system with explicit contracts between workers.

## Example 3: An Operations Task

This pattern is not just for features.

Say you want to investigate a production issue:

> Search latency spiked after a deploy and users report mixed relevance quality.

Useful split:

- Agent 1: review logs and traces
- Agent 2: inspect ranking changes and feature flags
- Agent 3: compare recent deploys and config drift
- Agent 4: draft the rollback/fix options

Gate:

- synthesize evidence
- decide on rollback vs patch
- run the lowest-risk fix
- verify the result
- record the operational learning

This is exactly where agent teams shine: competing hypotheses, read-heavy investigation, and fast convergence. It is also exactly where they fail if everyone edits production code at once.

## Prompting for This Style of Work

The most useful prompts are not magical. They just encode the workflow.

### Multi Agent Team prompt

```markdown
Create an agent team for this task.

Break the work into vertical slices, not horizontal layers.
Each slice must be independently testable and have a clear owner.
Work in waves.
After each wave, stop for a gate:
- summarize what changed
- list proof for each slice
- run lint/typecheck/tests or the closest equivalent
- identify refactors before starting the next wave

Avoid overlapping file ownership.
Prefer small, end-to-end slices over large component buckets.
```

## Where This Works Best

This workflow is a great fit when:

- the work can be decomposed into low-collision slices
- verification is cheap and reliable
- multiple hypotheses are worth testing in parallel
- there is clear orchestrator ownership

It is a bad fit when:

- the task is fundamentally sequential
- multiple workers need to edit the same hot files
- the system lacks tests, smoke paths, or observability
- nobody is available to synthesize and make decisions at the gates

The orchestrator is not optional. If nobody owns synthesis, the team becomes a very expensive source of inconsistent drafts.

## The Bigger Shift

The interesting change is not that coding tools can now spawn helpers.

It is that software work starts to look more like managing a compact engineering system:

- architecture as task design
- prompts as operating procedures
- tests as control surfaces
- gates as quality checkpoints
- rules and skills as organizational memory

That is why I think "closing the loop" is the right phrase.

The goal is not to maximize agent activity.

The goal is to create a loop where decomposition, execution, verification, refactoring, and learning reinforce each other. Once you have that, the extra agents help. Without it, they just make the mess faster.

## Further Reading

### Official docs

- [Claude Code: Orchestrate teams of Claude Code sessions](https://code.claude.com/docs/en/agent-teams)
- [OpenAI Codex: Multi-agents](https://developers.openai.com/codex/multi-agent/)
- [OpenAI Codex Concepts: Multi-agents](https://developers.openai.com/codex/concepts/multi-agents)

### TDD and red/green/refactor

- [Matt Pocock: My Skill Makes Claude Code GREAT At TDD](https://www.aihero.dev/skill-test-driven-development-claude-code)
- [Martin Fowler: Test Driven Development](https://martinfowler.com/bliki/TestDrivenDevelopment.html)

### Context management and parallelism

- [Chroma Research: Context Rot - How Increasing Input Tokens Impacts LLM Performance](https://research.trychroma.com/context-rot)

### Peter Steinberger / closing the loop

- [Lex Fridman Podcast #491 with Peter Steinberger](https://lexfridman.com/peter-steinberger)
- [Transcript: Peter Steinberger on the agentic loop, human-in-the-loop balance, and running multiple agents](https://lexfridman.com/peter-steinberger-transcript)
- [Peter Steinberger: Just Talk To It - the no-bs Way of Agentic Engineering](https://steipete.me/posts/just-talk-to-it)
- [Peter Steinberger: My Current AI Dev Workflow](https://steipete.me/posts/2025/optimal-ai-development-workflow)

---

# Git Worktrees + Worktrunk: A Setup for Parallel AI Agents
Source: https://eduwass.com/git-worktrees-worktrunk-a-setup-for-parallel-ai-agents/
Date: 2026-02-16

If you're using AI coding agents — Claude Code, Codex, Cursor — and you're still working on a single branch, you're leaving a massive productivity multiplier on the table.

I've been running parallel AI agents on a monorepo and the single biggest workflow unlock wasn't a better prompt or a faster model. It was **git worktrees**, managed by [Worktrunk](https://worktrunk.dev).

## The Problem: Agents Need Isolation

Here's what happens when you run multiple AI agents on the same repo:

1. Agent A is refactoring the auth system
2. Agent B is building a new search feature
3. Both edit `package.json`. Both touch shared types. Both run the dev server on the same port.
4. Everything breaks.

Separate clones? Duplicated `node_modules`, `.env` files, git history. On a monorepo with heavy dependencies, each clone costs gigabytes.

## Git Worktrees: The Primitive

Git worktrees let you check out multiple branches from the **same repository** simultaneously, each in its own directory. They share the `.git` object store — no duplication.

The problem is the native UX is terrible:

```bash
git worktree add -b feat/auth ../my-project.feat-auth && cd ../my-project.feat-auth
```

Paths are manual. Cleanup is manual. There's no lifecycle hooks, no coordination, no agent awareness.

## Enter Worktrunk

[Worktrunk](https://worktrunk.dev) (`wt`) wraps git worktrees with a proper developer experience. Branch names become the primary identifier, paths are computed from templates, and lifecycle hooks let you automate the boring parts.

Three commands cover 90% of the workflow:

```bash
wt switch -c claude/proj-141    # Create worktree + branch, cd into it
wt list                          # See all worktrees with status
wt merge main                    # Squash-merge, cleanup, done
```

Compare that to the raw git equivalent and it's night and day.

## My Actual Workflow

### One Worktree Per Task

Each ticket gets its own worktree. I use a naming convention that encodes the agent and issue:

```bash
wt switch --create claude/proj-141-auth-refactor --base=^
```

This creates the worktree, checks out a new branch from `main`, and `cd`s me into it. Worktrunk's hooks handle the rest: copying `.env` files, symlinking `node_modules`, setting up dependencies.

### Launch an Agent Directly

Worktrunk's `-x` flag lets you launch an agent in one shot:

```bash
wt switch --create claude/proj-141 --base=^ -x claude -- \
  "Read the ticket for PROJ-141. Propose a plan first."
```

That creates the worktree, switches into it, and spawns Claude Code with the initial prompt. One command, fully isolated agent session.

### Deterministic Ports, Zero Coordination

Each issue maps to a port: `PROJ-N → port 3000 + N`. No coordination needed between agents:

```bash
PROJ-128 → port 3128
PROJ-142 → port 3142
```

When I run the dev server inside a worktree, it auto-detects the branch name, derives the port, and starts in lite mode (just the web server — no duplicate workers or schedulers).

### Lifecycle Hooks Do the Housekeeping

This is where Worktrunk really shines. In `.config/wt.toml`, I define hooks for every phase:

**post-create** — Fresh worktree is immediately runnable:

- Copies `.env` and other ignored files
- Symlinks `node_modules` (no reinstall needed)
- Symlinks heavy data directories

**pre-merge** — Automated verification gate:

- Lint → typecheck → tests
- Failures abort the merge

**post-remove** — Kills orphaned dev servers, cleans up routing config.

No manual cleanup. No forgotten processes hogging ports.

### Merge and Clean Up

When an agent finishes:

```bash
wt merge main           # pre-merge hooks verify, squash-merge, auto-remove worktree
```

Or the PR-first flow:

```bash
git push -u origin claude/proj-141
# Merge via GitHub
wt remove claude/proj-141
```

## Why This Beats the Alternatives

| Approach | Shared history | Disk cost | Setup time | Agent isolation | Lifecycle hooks |
| --- | --- | --- | --- | --- | --- |
| Single branch | Yes | Zero | Zero | None | N/A |
| Separate clones | No | High | Slow | Full | None |
| Raw `git worktree` | Yes | Low | Medium | Full | None |
| **`wt` (Worktrunk)** | **Yes** | **Low** | **Instant** | **Full** | **Yes** |

## The Multiplier Effect

The real power isn't "two agents instead of one." It's that worktrees + Worktrunk remove the **coordination overhead** between parallel workstreams. Without them, you're stashing, rebasing, and resolving conflicts just to let two agents coexist. With them, each agent operates in a clean environment, and you deal with integration at merge time — which is exactly when you *want* to think about how pieces fit together.

On a typical day I'll have 2–3 worktrees active: one for a feature, one for a bug fix, and the main tree as a control room for review. Each with its own agent session, its own dev server. The throughput increase isn't linear (merge conflicts and review are still sequential), but it's meaningfully higher than working serially.

## Getting Started

1. Install Worktrunk: [worktrunk.dev](https://worktrunk.dev)
2. Create your first worktree:

```bash
   wt switch --create my-feature --base=^
```

3. Add hooks in `.config/wt.toml` to automate your setup (copy env files, symlink deps, etc.)
4. Launch an agent inside it:

```bash
   wt switch --create my-feature --base=^ -x claude -- "Fix the auth bug"
```

5. When done: `wt merge main`

No plugins, no complex infra. Just a CLI that makes git worktrees actually usable — and turns them into the perfect isolation layer for the age of agentic coding.

## Bonus: Shell Aliases

Once worktrees become second nature, even `wt switch --create` feels verbose. I keep these in my `~/.zshrc`:

```bash
# worktrunk aliases
# see: https://worktrunk.dev/tips-patterns/
alias wtc='wt switch --create'   # wtc feat/whatever (create new worktree)
alias wts='wt switch'            # wts feat/whatever (switch to existing)
alias wtr='wt remove'            # wtr feat/whatever (clean up)
alias wtm='wt merge'             # wtm main (verify + squash-merge + remove)
```

Now the full lifecycle fits in muscle memory:

```bash
wtc claude/proj-141               # create
# ... agent does its thing ...
wtm main                          # merge + cleanup
```

Four aliases. That's the entire workflow.

---

# Agent Rules That Actually Work
Source: https://eduwass.com/agent-rules-that-actually-work/
Date: 2026-02-16

You've got an AI coding agent. You've given it access to your codebase. It's productive for about 20 minutes — then it `console.log`s in production code, installs a dependency with `npm` instead of `bun`, queries your database with raw `psql`, and commits without running the linter.

The problem isn't the model. It's that you haven't told it how your project works.

I maintain a set of rules for AI agents across my codebase. Not prompts — **persistent, versioned, synced rule files** that every agent session loads automatically. Here's what I've learned about writing rules that agents actually follow.

## The Setup: One Source of Truth

All my rules live in `.rulesync/rules/` at the repo root. Each file covers one concern. A sync tool [**rulesync**](https://github.com/dyoshikawa/rulesync) distributes them to wherever each agent expects them — `CLAUDE.md` for Claude Code, `.cursor/rules/` for Cursor, `.github/copilot-instructions.md` for Copilot.

```markdown
.rulesync/rules/
├── 03-code-style.md        # TypeScript, React, import conventions
├── 05-patterns.md          # Canonical code examples
├── 07-donts.md             # Hard prohibitions
├── 09-ai-guidelines.md     # Behavioral rules for thinking
├── 11-code-quality.md      # Pre-commit ritual
├── 13-agent-cli-tools.md   # Purpose-built CLI tools
├── 15-dependency-management.md
├── 16-logging.md           # Structured event shapes
└── ...
```

You edit one place. Every agent gets the update. Rules are versioned in git alongside the code they govern.

You are free, no lock-in, can switch agents whenever you like.

## What Makes a Good Rule

After months of iteration, I've found that effective agent rules share a few properties.

### 1. Be Specific and Absolute

Agents don't do well with "prefer X over Y." They do great with "NEVER do X. ALWAYS do Y."

Bad:

```markdown
Try to use bun instead of npm when possible.
```

Good:

```markdown
NEVER use npm, yarn, or pnpm. ALWAYS use bun. This is non-negotiable.
```

My "Don'ts" file is a list of 7 absolute prohibitions. No wiggle room, no judgment calls:

- `bun` only — no npm/pnpm/yarn
- TypeScript only — no `.js` files
- No `any` types
- Structured logging only — no `console.log`
- Secrets in `.env` only — never hardcoded
- No skipping the linter
- No hand-editing autogenerated files

Each one prevents a whole class of bugs. Agents follow absolutes far more reliably than preferences.

### 2. Show, Don't Just Tell

A rule that says "use Drizzle ORM" is less useful than a rule that shows your actual query patterns:

```typescript
// How we query in this project
const events = await db
  .select()
  .from(schema.events)
  .where(eq(schema.events.cityId, cityId))
  .orderBy(desc(schema.events.startDate))
  .limit(20)
```

I keep a "Patterns" file with canonical examples for every common operation: route definitions, controller shapes, service patterns, template syntax. The agent pattern-matches against these instead of inventing its own style.

### 3. Provide the Right Tools (and Block the Wrong Ones)

This is the single highest-impact rule category. Instead of letting agents use general-purpose tools like `psql` or `curl`, I built purpose-built CLI wrappers and wrote rules that make them mandatory:

```markdown
| Task             | Use This              | NEVER This                    |
|------------------|-----------------------|-------------------------------|
| Query database   | `bun run db --toon`   | psql, raw SQL clients, pg_dump|
| Check logs       | `bun run logs --toon` | grep, tail, cat on log files  |
| Test endpoints   | `bun run api --toon`  | curl commands                 |
```

The `--toon` flag formats output for token efficiency — ~40% fewer tokens than JSON tables. The CLI tools are read-only by design, so agents can't accidentally mutate data.

Check out: [Token-Oriented Object Notation **(TOON)**](https://github.com/toon-format/toon)

This isn't just about safety. It's about **token efficiency**. An agent that runs `psql` and gets back a raw table dump burns through context fast. A purpose-built tool returns exactly what's needed in a compact format.

### 4. Rules for Thinking, Not Just Syntax

The most underrated category. Beyond code style, I have rules for how agents should *approach* problems:

- **Surface assumptions explicitly** — don't hide confusion, ask
- **Simplicity first** — no speculative features, no over-engineering
- **Surgical changes** — touch only what's needed, match surrounding style
- **Goal-driven** — define what success looks like before writing code

These sound obvious, but without them agents tend to refactor neighboring code "while they're in there," add error handling for impossible scenarios, and create abstractions for one-time operations.

### 5. Verification Is a Rule, Not a Suggestion

For UI changes, I have a hard rule: **you must visually verify with Playwright before claiming completion.** Not "it would be nice to check" — it's a required workflow step.

```markdown
Before marking a visual task complete:
- [ ] Code change is saved
- [ ] Dev server is running
- [ ] Used Playwright to view the page
- [ ] Visually confirmed the change looks correct
```

For non-visual changes, the pre-commit ritual is codified:

```bash
bun lint && bun typecheck    # Before every commit
bun run test                 # Before every PR
```

Agents that know they'll be checked do better work.

### 6. Pin Your Dependencies

This one bit me early. An agent decided to "update" a dependency while fixing a bug. Cascading breakage.

The rule is simple: **all dependencies use exact versions.** No `^`, no `~`. Shared versions go in a root-level catalog to prevent drift:

```json
{
  "catalog": {
    "react": "19.1.0",
    "drizzle-orm": "0.44.2"
  }
}
```

Agents can add dependencies. They cannot change versions of existing ones without explicit permission.

### 7. Structured Logging as Law

Without a logging rule, agents will `console.log` their way through debugging and leave the mess behind.

The rule mandates structured events with a canonical shape:

```typescript
// Required shape
logger.info({ event: 'search_completed', outcome: 'success', results: 42 }, 'Search returned results')

// Violations
console.log('search done')           // ❌ No console.log
logger.info('search done')           // ❌ No string-only messages
```

This isn't pedantic — it's what makes logs queryable in production.

Related, and a great read: [**https://loggingsucks.com**](https://loggingsucks.com)

## Rules That Don't Work

Some things I've tried that agents consistently ignore or misapply:

- **Vague preferences**: "Try to keep functions small" — meaningless without a threshold
- **Context-dependent rules**: "Use pattern A for new code, pattern B for legacy" — agents can't reliably judge which is which
- **Rules about rules**: "Read all rules before starting" — they read them, but meta-instructions about process get lost
- **Negative examples without alternatives**: "Don't do X" without "do Y instead" leaves agents guessing

## The Maintenance Loop

Rules aren't write-once. My process:

1. Agent does something wrong
2. I fix it and ask: "Would a rule have prevented this?"
3. If yes, I write the rule in `.rulesync/rules/`
4. `rulesync` propagates it to all agent configs
5. Next session, the agent knows

The rule set grows over time but stays curated. I remove rules that prove unnecessary and sharpen ones that agents misinterpret. After a few months, the rules stabilize — most new sessions "just work" because the common mistakes are all covered.

## Getting Started

You don't need 18 rule files on day one. Start with three:

1. **Don'ts** — 5-7 absolute prohibitions specific to your project
2. **Patterns** — 3-5 canonical code examples showing "how we do things here"
3. **Tools** — Which CLI commands to use (and which to never touch)

Put them in a `.rulesync/rules/` directory, set up [rulesync](https://github.com/dyoshikawa/rulesync) to distribute them, and iterate from there. Every time an agent makes a mistake that a rule would have caught — write the rule.

The goal isn't to constrain the agent. It's to encode your project's conventions so the agent can focus on the actual problem instead of reinventing your style guide every session.

---

# Hello world!
Source: https://eduwass.com/hello-world/
Date: 2026-01-21

> **Update (Apr 2026):** Killed this whole WordPress setup three months after writing this. Rewrote the entire site from scratch — see [Replacing WordPress with 2,300 Lines of Bun](/replacing-wordpress-with-2300-lines-of-bun/).

---

[Bento.me](http://bento.me) is sunsetting.

So after many years of putting off building my own site, I found myself forced to. I liked the layout and usability of Bento.me and figured I could build something very similar using WordPress.

This is what I had there:

![](/hello-world/005139.gif)

I decided to fork Rich Tabor's [Kanso](https://rich.blog/kanso/) theme which is nice and minimal and tweaked it to make the layout similar to what I had in Bento.

Plus added in this blog you are reading and a couple of pages that I'll need to work on; including a read.cv (which has also been sunset — sigh) inspired [Resume](/resume/) page.

And this is what my version looks like as of right now:

![](/hello-world/005140.gif)

*Dark mode — finally!*

Anyways, here it is, this time I have full ownership and will be able to play with it, so that's cool.

I'm guessing the next post can be me geeking out in the technical details.

PS: Open up your dev tools for a cool easter [egg](#activateHacks).