atharux.com
// lab

Building in
Public

Active experiments, things I'm learning, and honest notes from making the jump from UX designer to React developer.

Mar
2026
AI
// 006
Complete

Building a multi-agent AI coordination system for event planning

Built a working demo of a multi-agent research and event planning system targeting the Foresight.org ecosystem — both as a portfolio piece and as funding material. The system coordinates specialised AI agents: one for research, one for scheduling, one for outreach, with a central orchestrator managing handoffs.

The interesting design problem wasn't the AI part — it was the coordination layer. How do you show the user what each agent is doing without overwhelming them? How do you handle failure in one agent without collapsing the whole pipeline? These are UX problems wearing an engineering costume.
// key learnings
  • Agent orchestration is a UX problem as much as an engineering one
  • Visibility into agent state is critical — users don't trust black boxes
  • Structured prompting (contract-first) makes agent outputs auditable and debuggable
  • Failure states need designing before the happy path
// ux lens

Multi-agent systems are just service blueprints with code. The swimlanes are agents. The touchpoints are handoffs. The moments of truth are where one agent's output becomes another's input — and something gets lost in translation.

View demo →
Feb
2026
UX
// 005
In progress

Designing atharux.com for two completely different hiring audiences at once

Most portfolio sites are built for one reader. Mine has two: a hiring manager looking for a React Developer, and one looking for a UX Design Lead. They care about different things, read in different orders, and have different definitions of "evidence."

The solution wasn't two separate sites — it was section ordering and framing. The Apple case study leads because it has institutional weight that both audiences respect. The React projects follow immediately after. The UX systems work comes third. The AI methodology section reframes AI not as a tool I use but as a practice I've structured.

The brutalist theme toggle was a deliberate signal — it shows design range and the ability to build a functioning design system, not just mock one up in Figma.
// key decisions
  • Lead with Apple — it's the credential both audiences trust immediately
  • Space Mono + Syne: monospace for technical credibility, display for design sensibility
  • Dark default theme — positions the work in a dev/engineering context first
  • Brutalist toggle as a portfolio piece in itself — proves it, doesn't just claim it
// ux lens

A portfolio is a persuasion system. Every section order, label choice, and visual decision is an argument. The question isn't "what should I include" — it's "what do I need the reader to believe, and in what order do they need to believe it?"

View site →
Mar
2026
UX
// 004
Ongoing

What UX systems thinking actually transfers to engineering — and what doesn't

There's a version of the "designer learning to code" story that says everything maps cleanly. Design systems → component systems. User flows → state machines. Information architecture → data modelling. And some of it does.

But some things don't transfer at all. Design is reversible at every stage. Code has compounding dependencies. Changing a colour token in Figma takes seconds. Changing a data structure three sprints in costs days. The tolerance for ambiguity is completely different.
// what transfers
  • Systems thinking — components, tokens, reusability
  • User mental models → state and error handling
  • Constraint-first design → writing interfaces before implementation
  • Critique culture — reviewing your own work before shipping
// ux lens

The biggest transfer isn't a skill — it's the habit of asking "what happens when this breaks?" before shipping. Designers call it edge cases. Engineers call it error states. Same instinct, different vocabulary.

Mar
2026
React
// 003
In progress

What I got wrong about useEffect (and what finally clicked)

Drilling core React hooks for a live coding interview. useEffect was the one I kept misplacing — inside the return block, missing the dependency array, firing on every render.

The mental model that fixed it: useEffect is a synchronisation tool, not a lifecycle method. You're telling React "keep this side effect in sync with these values" — not "run this when the component mounts."
// key learnings
  • useEffect always goes at component top level, never inside return
  • Empty dependency array [] = run once. No array = run every render.
  • setCount(count + 1) vs setCount(c => c + 1) — and why the latter is safer
  • Cleanup functions prevent stale subscriptions
// ux lens

Hooks are a lot like design constraints — they feel restrictive until you understand they exist to prevent failure states you haven't encountered yet.

Mar
2026
React AI
// 002
Complete

Advanced prompting — built an interactive guide with live API calls

Put together a reference tool covering three prompting patterns that actually matter in production: ReAct reasoning loops, function calling pipelines, and context engineering. Built as a single HTML file with live Anthropic API demos — each tab lets you run real examples in the browser.

The function calling tab simulates the full four-phase pipeline: model receives request → model calls tool → tool returns data → final response. Makes the architecture tangible in a way that reading about it doesn't.
// key learnings
  • The model never executes functions — it produces structured text your code intercepts
  • Context placement (primacy/recency) affects output more than most people realise
  • One well-chosen few-shot example outperforms three paragraphs of instruction
Live demo →
Feb
2026
React Tooling
// 001
Ongoing

Building a job tracker to track my own job search — and what Supabase RLS actually means

Started building a job tracker app (React + Supabase) partly to have something to demo and partly because I genuinely needed one. Hit a security audit issue where Row Level Security wasn't configured — meaning any authenticated user could read any other user's data.

Writing the RLS policies in SQL was the first time database security felt concrete rather than abstract. auth.uid() = user_id is four tokens that make a meaningful difference.
// key learnings
  • Supabase RLS is opt-in — not having it is a silent failure, not an error
  • Four policies needed: SELECT, INSERT, UPDATE, DELETE — each with auth.uid() check
  • React state and Supabase realtime subscriptions need cleanup on unmount
// ux lens

Security policies are invisible UX. The user never sees them working — they only notice when they're missing. Good constraint design, applied to data.

// no entries match this filter yet

Follow on LinkedIn →