But my interest was narrower. I didn’t buy them to talk to AI in public or read dense logs on my lenses. I was chasing a more specific question: could they become a peripheral display for background agent work?

I built a small, self-hosted system called Beacon around one annoying problem: long agent runs should not require me to sit there and babysit the terminal.

Last week, during a workout, Beacon crossed from a fun hack into an actual interface.

Before leaving my desk that afternoon, I kicked off a performance analysis for the puzzle packer for Right Words. A possible v2 feature for community puzzle submissions had dragged packer runtime out of my terminal and into the user experience.

Previously, I didn’t mind if the packer took a few minutes. I’d kick it off and let it run. But in a real-time user-facing flow, waiting minutes for a puzzle to pack was a non-starter.

I asked Claude Code to profile the packer’s phrase-placement loop, with a focus on candidate path generation and dead-space detection. I needed to see which grid constraints caused the heuristics to stall and where the packer was actually spending its time.

Agents are good at that kind of slog: trace the loop, run the profile, compare the stalls, summarize the bottlenecks. The old cost was attention. I still had to sit there, wait for output, and monitor the terminal logs.

Instead, I went to the gym.

Ten minutes into my workout, a line of green text silently flickered into my peripheral vision:

BEACON - rightwords.io
▲ packer-opt: packer profiling complete. 3 core bottlenecks diagnosed.

The message gave me just enough signal to know the terminal had produced something worth reading.

I finished my set, pulled out my phone and remoted into my home session (thx, Tailscale). The glasses stayed out of the interaction. They pointed me back to the place where the next judgment call lived. Because a deep performance profile is not a binary execution block, I needed to read Claude’s analysis, evaluate its diagnostics and decide whether I agreed with its proposed optimizations.

That gym run reframed the problem around attention routing.

For agentic tools, the useful interface is a thin peripheral signal that appears only when the machine has reached the edge of its autonomy and needs a human to choose the next move.

Beacon: A Router, Not a Dashboard

Beacon is the small, self-hosted pipeline I built to test this idea: a local hook, a compression layer, and a push surface that stays quiet until an agent needs my attention.

1. The Hook Layer (Bash): Claude Code’s Stop/Notification hooks trigger a local script, beacon-watch.sh. The script waits 10 seconds, then checks if my terminal window and tmux pane are focused. If I’m already editing or observing the terminal, it stays silent. Otherwise, it pings the relay layer.

2. The Relay Layer (Vercel Edge Function): An edge function receives the payload and passes the last assistant message through Claude Haiku, which summarizes it into a ~50-character, dense HUD message.

3. The Push Layer (Expo Go): For this v1 proof-of-concept, the formatted string is pushed through Expo and Apple’s notification service to my iPhone, where the Even Realities app mirrors it directly to my glasses.1

Beacon is my prototype of an ambient decision surface. It is a sparse peripheral display for routing the state and diagnostic of a background process to your attention.

Status Belongs on the Wall

My first mistake was routing everything to my glasses, including puzzle_solved events from Right Words. It was fun for about five minutes, then obviously useless. Every solve was a micro-distraction.

Puzzle solves are pure status notifications: passive, communal updates that do not require my judgment. That class of data belongs on a wall, maybe even a physical one, like a mechanical Vestaboard clacking quietly in the background of a room as an information radiator.

Beacon only matters at the point where status turns into a decision.

The Side Project Is Multi-Threaded Now

AI changed the topology of my side projects. Historically, developers have worked linearly, picking one repo, focusing on a single branch, and pushing it to completion because the cognitive cost of context-switching is too heavy.

Now, I keep three to five side projects moving in parallel. I might have Claude Code handling a major refactor in one terminal tab, building out a test suite in another, and profiling the puzzle packer in a third.

Working like this used to melt my brain. Background agents let you pipeline execution, but then you need to know when one of those threads has stalled. Before Beacon, I was tabbing through terminal windows like a paranoid security guard flipping between CCTV feeds, making the rounds just to see if anything needed me.

Beacon gives me controlled re-entry. I can leave chained-to-the-desk developer mode entirely. I can go to the gym, cook dinner, or read a book, knowing that if one of those concurrent threads needs me, my glasses will tell me where to look.

Parallel Agents, Serial Judgment

In my last two posts, I wrote about comprehension debt and how AI makes execution cheap but leaves judgment expensive.

If an agent can execute ten hours of work in ten minutes, it will inevitably reach ten moments where it needs to ask you: “Is this actually what you wanted?”

If the agent has to wait for you to sit down at your desk, load the context, and read a PR to answer those questions, the speed advantage evaporates. But if the agent pages you for every minor lint error, file write, or test run, you will throw your laptop out the window.

We are currently trying to solve this with two familiar primitives: notifications and dashboards. Neither quite matches the failure mode of agentic work.

Beyond the Push Notification

The obvious objection here is: “Isn’t this just a phone notification in 2049 cosplay? My CI pipeline already pings Slack when it fails.”

Most notifications report a closed event: X happened. Agent blocks are different. They arrive mid-thread: I ran X, hit Y, and need Z to proceed.

When a standard CI pipeline fails, it stops. The system has no next move. It pages you because the system is mechanical: it can report failure, but it cannot reason through the next move. The only path forward is a human restart. But when an AI agent blocks, it is not dead; it is polling for intent. It has completed 90% of the execution, mapped the immediate tradeoffs, and is waiting for your input to decide the final 10%. It is a living, stateful thread.

If you route that block as a raw log or a generic Slack ping, you have degraded a stateful, high-leverage agent into a dumb cron job. A generic notification says “look at this” and throws you into the pile. A decision surface preserves the useful bit: where judgment is needed.

More importantly, notifications flatten everything into peers. Your phone treats texts, calendar reminders, and an agent’s build failure as the exact same kind of interruption.

An ambient decision surface can take many forms: a HUD in your glasses, a tiny e-ink display on your desk, or a single-line widget on your desktop. The hardware matters less than the rule: keep it sparse, peripheral, and reserved for moments that need judgment.

To be clear, Beacon does not replace the terminal. When I remoted in from the gym, I was still using the same command-line tmux session. But there is a fundamental cognitive difference in how I reached that session. I did not get there by polling a dashboard, and I did not get there by letting an ordinary phone notification pull me into the pile. I got there because a compressed ambient signal told me exactly where my judgment was needed.

I am, admittedly, a sucker for hardware that makes the future feel less theoretical. I want the useful side of cyberpunk: high-agency tools that make one person more capable without turning every surface into an ad slot or another demand for attention. That is what worked about the G2s. They did not try to become my phone. They left me in the real world, adding only a small green status line at the edge of my vision when something was worth my attention.

The Dashboard Fallacy

The other default response is to build an “agent dashboard.”

Dashboards are fantastic when you want to inspect a system. They are terrible when the system’s primary job is to reduce the need for inspection.

A dashboard forces you to play the role of the anomaly detector. You have to poll the interface, scan the green checkmarks, read the log lines, and try to deduce where the agent is stuck or where its design is drifting from your intent.

To put it bluntly: a dashboard is what you build when you don’t yet know what actually deserves a human eye. It means the compression layer has not done its job.

Why Your Phone is the Wrong Surface

But still, the engineer asks: “Why not just route these compressed decision boundaries to my phone Lock Screen? It’s already in my pocket.”

Because the phone is a destination rather than an environment.

To interact with a phone, you must cross a threshold of conscious intent. You pick it up, aim your face at its sensors, unlock it, and step inside. The phone is physically designed to consume 100% of your central attention.

Your phone is a focus casino. The moment you unlock it to resolve a build block, you’re pulling the slot machine’s lever. You are standing in the middle of a carnival of other apps specifically engineered to hijack your focus. Suddenly, a three-second review task has morphed into thirty minutes of brain-melting doomscrolling. The context-switch has already occurred.

A true ambient surface, like smart glasses or a physical status indicator on your desk, lives in your periphery. It has zero nesting depth. There are no folders to open, no other apps to swipe through, and no keyboard to summon. It sits in the room with you: something you can glance at, resolve with a single tap, and dismiss without ever leaving your current physical or mental state.

You do not “go to” an ambient surface. It occupies the background of your life until a decision requires it to step forward.

Calm Technology for Agentic Work

This isn’t a new design challenge, though AI has made it urgent. In the mid-1990s, Xerox PARC researchers Mark Weiser and John Seely Brown introduced the concept of Calm Technology. They argued that the most powerful machines would be those that “fit our lives” by moving seamlessly between our peripheral attention and our central focus.

An ambient decision surface is calm technology applied to the cognitive load of AI.

To work, a decision surface has to enforce a strict rule of context compression. If an agent is blocked, it cannot simply dump a stack trace onto your screen. It has to translate the block into product terms:

1. The Context: What is the active state and diagnostic?

2. The Decision Boundary: Why can’t the agent proceed autonomously?

3. The Resolution Path: What is required of human judgment to unblock it?

In practice, that means Beacon should not tell me that a process emitted 400 lines of logs. It should tell me the one thing I need to know:

The decision surface does not ask you to fix the problem on your wrist or your lens. It gives you enough shape to know what is waiting. When you return to the terminal, you are not spending ten minutes rediscovering the issue. You already know the diagnostic before your hands touch the home row.

Smart Glasses as a Forcing Function

This is where the constraints of smart glasses start doing useful design work.

One reason so many consumer hardware startups struggle is that they try to fit “phone-sized” experiences into wearable form factors. They want you to talk to a pin, or look at a wrist-mounted screen, to do things your phone does ten times better.

Smart glasses punish bad information design. They have almost no room for input, scanning, or explanation, which makes them useful as a forcing function for information density.

Because the G2s have such limited screen real estate and zero keyboard input, they force the developer of the agent interface to write better communication algorithms. If the interface has to explain an architectural block in 15 words, it suddenly becomes very good at summarizing tradeoffs.

The constraint of the glass lens forces the software to respect your skull.

Don’t Answer Back

Even Realities has a built-in “talk to AI” voice feature. A tool like Beacon invites an obvious next question: “Why not let me voice-chat my response back to Claude from my glasses?”

That is where the interface stops being calm.

The moment you dictate refactors to your glasses, you have let the machine take over your environment. You are no longer in your periphery; you are actively context-switching. The glasses are no longer calm.

The useful pattern is the handoff. An ambient surface should do exactly one thing: signal when your input is required. If it’s a binary decision, I might eventually allow a simple physical tap gesture on the frame to choose a default. But if it’s a real architectural decision, it should simply route your attention back to your actual action-oriented operating surfaces, meaning your terminal, your editor, and your computer. The glasses act as the compass, leaving the terminal to serve as the steering wheel.

The Cost of Free Execution

We don’t all need to walk around in smart glasses to make this work. The hardware just makes the interface problem visible: stay out of the way until there is something to judge.

Five agents create five streams of partially resolved work, and every unresolved thread eventually lands back on the same copy desk.

AI made execution cheap, but judgment still bottlenecks on one editor, one context window, one red pen. Build the interface around that constraint.

But what happens when the tools get fast enough to outrun the rider?

Code has become the cheap part. The expensive parts are constraint definition, taste, validation, and figuring out when a technically impressive system makes the product worse.

the tl;dr: I built a word puzzle game called Right Words as a side project while working full-time. You trace two-word phrases in a grid and jump a gap between the two words. Every tile belongs to exactly one phrase.

The Problem Behind the Puzzle

A Right Words puzzle is a cluster of six two-word phrases crammed into a grid. The packing has to meet a series of constraints that are, frankly, deceptively convoluted:

• every cell can belong to only one answer

• consecutive tiles have to be grid-adjacent, including diagonals

• the gap between word1 and word2 of a phrase must be one tile skip (cardinal or diagonal) giving a max of 8 possible tiles to jump to

• no alternative tile arrangement can spell the same phrase (requires exhaustive path enumeration)

• if two tiles share a letter, swapping them can’t produce a valid alternative traversal

• no repeated words across answers, no word1 that doubles as another answer’s word2

• every phrase has to be a real two-word phrase people actually recognize, within a tight character limit

• the difficulty system optionally requires one answer to have a readable “gimme” word while preventing all others from having straight-line words

The packer uses MRV heuristic for phrase selection, seeded RNG for reproducibility, and restart limits to escape dead ends. False positive detection runs DFS against the full grid for every placed answer.

Friends keep asking when it’ll go daily. Six valid, non-overlapping, theme-coherent two-word phrases that pack into a grid with zero false positives and the above constraints is not something I can produce on that schedule (hello, Tracy Bennett? Sam Ezersky?!). 🥲

I hadn’t built a constraint-satisfaction solver before, so I designed the rules and architecture, then used Claude Code to accelerate the implementation. I defined what the solver needed to enforce, Claude built the packer, validator, and path generator. I tested the output and caught the cases it missed, like a path ambiguity bug where two same-letter tiles separated by a different letter could be swapped without breaking adjacency.

That division (I define, Claude builds, I verify) is what made the scope possible.

note: I previously discussed this dynamic in Judgment Doesn’t Scale With Speed

The Breadth Problem Solved

Justin Searls wrote about “full-breadth developers”, people who do both technical execution and product thinking. His take is that AI rewards this combination disproportionately. I’d say it more plainly: I could design Right Words before AI. But I couldn’t implement the full stack alone in any reasonable timeframe. It would’ve sat in the backlog of ideas piled high on my list of purchased and unhosted domain names.

None of the individual subsystems were impossible. In fact, all of them are pretty doable on their own (a constraint solver, puzzle packer, fun UI/UX interactions when selecting words and creating skip chains, and all the usual mobile game goodness in share cards, etc.). The hard part’s keeping product intent coherent across all of them at once, and doing it in the margins of a full-time job. That’s the breadth problem. An AI collaborator that could move between the packer algorithm and a CSS animation timing bug in the same conversation is ultimately what made the scope feasible.

Peter Steinberger (of OpenClaw fame) has a technique for bulletproofing specs using two AI contexts, one generates, one critiques. I applied that combo to a layered doc hierarchy (SPEC.md → ARCHITECTURE.md) that the AI reads every conversation (and applies to its own memory & CLAUDE.md), each layer narrowing from broad product intent to specific code constraints. Precise specs meant precise output, which meant speed. Vague specs meant debugging the spec, not the code, and the bugs nearly always came from the vague parts.

The Human Element Remains

I even had AI try to generate the puzzle content. It returned a Greek mythology theme that included STAR FISH (theme incoherency aside, starfish is one word!). The same list had TROJAN HORSE twice and HERCULES STRENGTH (?), and a bunch of one-word “phrases.” You cannot delegate content curation.

Picking themes is harder than it sounds. The theme name itself is a difficulty lever: “Fast Food” is obvious, “Legendary Lines” requires you to realize these are all idioms from Greek mythology (after ideally spending no more than a couple of minutes looking for a “Here’s Johnny!”). Monday themes run more cryptic than Friday themes, by design. I choose each one knowing that a confused player bounces and a condescended player stops coming back.

Word selection is worse. Every phrase has to be immediately recognizable, but not so common that it shows up in multiple themes. The two words have to be long enough to create interesting paths (minimum three characters each, for now) but short enough to fit the grid. Some perfect phrases just don’t pack: too many common letters create false positives, and consecutively repeated letters leave the packer with no room to route other answers around them. I’ve thrown away dozens of great phrases because the algorithm couldn’t use them without creating an alternate valid path.

I hand-curate every word list. I hand-place the paths I care about. For example, I placed GORDIAN KNOT tile-by-tile in the visual designer, locked it, and told the packer to arrange five other phrases around my shape, a puzzlingly unnecessary use of my time to give one phrase of one puzzle a specific aesthetic. This required building shape-shifting, pre-placed chain support, and updating the CLI to support completion of a --partial pack. Claude built the machinery in an hour. I spent three days deciding what the puzzle should look like. It can build anything you want! It just won’t want it for you (and in an era of creative slop being dispensed like warm soft serve, that’s a good thing).

The Difficulty Trap

I spent entirely too much time building a hard mode that rejected any packing where a word read in a straight line. Maximum difficulty.

Then, a friend played it and said, “95% of the addressable market does these puzzles to feel clever. You get better uptake by adding confetti to winning than figuring out how to obscure things.”

I’d been building for my five most hardcore friends. Analytics revealed that the players who actually left were leaving because they had no foothold.

So I (sadly) scrapped it. Fridays get a word that reads left-to-right. Mondays get one readable vertically on an edge. The “gimme” system exists because someone with fresh eyes identified the difficulty I had grown accustomed to (and thus kept trying to crank higher). I cannot stress the importance of early user testing enough!

Fast Feels Free

The tutorial has a trampoline animation on the gap tile during a jump. Worked fine in the normal game. In the tutorial, it replayed on every subsequent tap.

I prioritized AI “correction” speed over diagnosis and went with the first fix: suppress the pulse on the gap tile. This killed the visual hint showing players which tile to tap next.

Second attempt: stabilize the key so pulse changes wouldn’t remount the tile. Pulse animations went out of sync.

Third: timed effect, apply the trampoline for 500ms then clear it. Rapid tapping re-triggered it.

Fourth: ref-based tracking. Didn’t fire at all on one answer due to setState timing.

Fifth: duplicate the Grid component for the tutorial, decouple the trampoline from React’s key system entirely.

Five worked. But I should have gotten there on attempt one. The bug only appeared in the tutorial because the normal game’s validMoves empties after a jump, a !state.jump gate. The gap tile is never pulsed in normal gameplay. Asking “why only here?” instead of “how do I fix it?” would have saved four attempts.

Claude gave me five implementations in the time it would’ve taken to try two. But I was moving fast because fast felt free, and I skipped the part where you explain the bug to yourself before trying to fix it.

“95% of the addressable market does these puzzles to feel clever. You get better uptake by adding confetti to winning than figuring out how to obscure things.”

What Stayed Difficult

The hard parts were deciding what difficulty means for casual players. Or a puzzle feeling “less fun” until I traced a new version that “felt” right. Or deciding to duplicate a 250-line component rather than risk a small change to the Grid in production, now that there’s a small but loyal group of people who play every week.

That is the part I think people understate about AI-assisted development. It does not remove engineering judgment. It changes where judgment is spent.

Jobs said we’re tool builders, and the best tools amplify our inherent abilities to spectacular magnitudes. The bicycle for the mind assumed the rider knew the route. AI is not a bicycle. It’s an orchestra. You still need a conductor, a score worth playing, and the ear to know when it sounds like shit.

Without Claude Code, Right Words would still be a purchased domain name on my list of ideas I’ll get to someday. 💀 With it, the game shipped, people play it every week, and I spend my time on what the next puzzle should feel like instead of debugging a path validator at 2am. I mean… I still debug path validators at 2am. But now it’s a choice.

One example stuck with me. I merged a refactor last week that passed CI without issue. Three days later, I had to reread the diff to remember why I chose that approach over a simpler one. Nothing was broken, but I wasn't sure it was the right call and that bothered me more than an actual bug would have.

Comprehension Debt

Technical debt is what happens when the codebase degrades. There’s another kind: when your understanding of it degrades. I think of that as comprehension debt. You don’t notice it building until something breaks at 2 a.m., and then you realize you can’t reason about code with your name on it.

I’ve been using AI coding tools aggressively for over a year: agentic tools, chat workflows, autocomplete, all of it. I’m faster than I’ve ever been. I’ve shipped enough code I couldn’t explain a week later to know going faster without understanding it is a trap. Anthropic's own research backs this up. AI tools can absolutely increase output. They can also weaken your ability to reason about the code you ship.

If comprehension debt is the problem, the real question is: what am I protecting when I review AI-generated work? I’m not sure I have this fully answered.

What I Protect, What I Don’t

Most of the discourse is useless binary stuff: either you use AI or you don’t, either you’re a “real engineer” or you’re dependent. You don’t want to be the person flooring it toward a wall with blinders on to everything but the speedometer. But I also don’t want to be the one still taking a horse to work clutching punch cards. The actual skill is knowing which tasks need your full attention and which ones don’t.

What I won’t delegate. Architecture. System design. Tracing a production issue through three services at midnight when something’s on fire (log parsing aside, which AI is fantastic at). All this stuff comes from reps, and I don’t think reviewing AI output builds it the same way.

What I’ve let go. Exact API signatures. CRUD boilerplate. Stuff I've written a hundred times and will never learn anything new from writing again. It's long division at this point. Knowing it exists and when to reach for it is enough.

The middle ground. First drafts of tricky logic. Reading docs vs. asking an AI to summarize them. Manually stepping through a stack trace. I still do these because they keep my instincts sharp… but, the line does move. The question I keep coming back to: is doing this manually still teaching me something, or is it just habit? I don’t always know.

How I Actually Work With These Tools

LLMs list the options. I pick. In unfamiliar territory, I ask for approaches, tradeoffs, and failure modes instead of “the best solution.” If I let the AI make the design decision, I’ve skipped the part of the work that matters most. I’ve caught myself doing this more than I’d like to admit.

I don’t touch code until I can describe what “done” looks like. What am I building? How will I know it works? What’s out of scope? No amount of prompting fixes unclear thinking on my end.

Small pieces, reviewed like someone else wrote them. Because someone else effectively did! I break work into chunks small enough to hold in my head. That’s usually the moment I either catch it or let it compound.

If I’m getting faster but less sure, something’s wrong. These tools should make me faster and more confident. If speed is climbing while certainty drops, I need to change something in the process.

Staying Honest

After doing this long enough, I’ve learned to watch for certain signals in myself. Copying prompts without thinking about what I’m actually asking. Accepting a design I don’t fully understand because the output looks right. Skipping review because the tests passed. That low-grade unease about a piece of code that I convince myself isn’t worth investigating.

When those show up, I take the next piece of work and do it manually. Not because hand-writing code is inherently better, but because the discomfort is telling me I’m losing the thread.

Honestly, the biggest fear is needing AI because I can no longer do the work without it. I want it to make me faster, not to become something I can’t function without.

Where This Lands

I don't have this fully figured out, and it shifts as the tools do. But I've got a framework that’s started to move with it. I keep coming back to this: speed is the easy part now. In my experience, judgment is the hardest thing to build and the easiest thing to weaken if you are not paying attention.