Stoneberg Design

Datatype — variable font that turns text into charts

Mon, 27 Jul 2026 00:00:00 GMT

📊

Open Source Alternatives to Popular Software

Tue, 30 Jun 2026 00:00:00 GMT

Open Source Alternatives to Popular Software

Using Claude Code: The unreasonable effectiveness of HTML | Claude

Sat, 06 Jun 2026 00:00:00 GMT

The case from Anthropic for having Claude Code emit HTML instead of Markdown. Specs, mockups, code reviews, and reports get tables, SVG, and interactivity, and a file you can hand someone as a link.

§ Project Kickoff: Start Every Project the Same Way

Thu, 21 May 2026 00:00:00 GMT

I recently published project-briefing, a skill for getting back up to speed on a project after time away. But it depends on having good source material to synthesize: an overview document, an activity log, structured notes. If those files don't exist, the briefing has nothing to work with.

That raised an obvious question: how do I make sure every project starts with the right files in the first place?

The bootstrapping problem

Starting a new project usually means I have a pile of scattered artifacts. Forwarded emails, a requirements PDF, some screenshots, maybe a meeting transcript. It all lives in a folder somewhere, unstructured.

Getting organized takes real effort, especially if I want the structure to be machine-readable for coding agents. And if I'm honest, I skip it more often than I should. I just start working and pay for it later when I can't remember what was decided three sessions ago.

The other issue is consistency. When every project has a different structure, re-orienting is slow. There is no muscle memory for where things live.

What project-kickoff does

project-kickoff is a skill that solves this once. I create a directory, drop in whatever I already have, and invoke the skill. It does four things:

Scans everything in the directory: documents, screenshots, PDFs, emails, whatever I've dumped in
Interviews me with 3-5 targeted questions to fill gaps the artifacts don't cover
Writes an OVERVIEW.md and reads it back for my approval
Scaffolds the rest: an activity log, an agent instructions file, and a scratch directory

The scan-first design is important. Most project kickoffs start with a blank template and make you fill everything in. That ignores the reality that you usually already have information. The skill reads what exists and only asks about what's missing.

When it's done, the project directory looks like this:

my-project/
├── OVERVIEW.md      # What the project is
├── LOG.md           # What's happened so far
├── AGENTS.md        # How agents should work here
├── CLAUDE.md        # Points to AGENTS.md
└── temp/
    └── README.md    # Scratch space for intermediate work

Why these four files

OVERVIEW.md is the single source of truth. Goals, stakeholders, timelines, key facts, open questions, and an index of important files. It's written in plain language so anyone picking up the project cold can understand it. This is also what project-briefing reads when I ask "get me up to speed."

LOG.md is insurance against lost context. Sessions end unexpectedly all the time: token limits, disconnects, timeouts. The AGENTS.md file instructs agents to update the log proactively throughout a session, not at the end. If a session stops mid-task, everything completed up to that point is recorded and recoverable.

AGENTS.md is loaded into every agent session automatically. It contains operational rules, not project knowledge: stay inside this directory, use temp/ for scratch work, update the log as you go, read the overview before starting. Rules in this file get followed session after session without me repeating myself.

CLAUDE.md is a one-liner that points to AGENTS.md. It exists because Claude Code auto-loads files named CLAUDE.md — so this gives Claude a native entry point without putting any content there. The actual rules live in AGENTS.md, which any tool can read. Cursor, Copilot, and other agents don't care about CLAUDE.md, but they can all read AGENTS.md directly.

temp/ is the pressure valve. By giving agents a sanctioned place for messy intermediate work, the rest of the project directory stays clean.

The separation between OVERVIEW.md and AGENTS.md is deliberate. The overview answers "what is this?" The instructions answer "how should I work on this?" They reference each other but never duplicate content. Mixing project facts and operational rules into a single file creates something too long to maintain and too confusing to follow.

The pair

These two skills form a project lifecycle:

Kickoff creates the directory structure with OVERVIEW.md, LOG.md, AGENTS.md, CLAUDE.md, and temp/
Work happens; agents update LOG.md as they go
Return with project-briefing, which synthesizes the overview and log into a quick status update
Repeat because re-entry is fast when the structure is consistent and the log is current

The OVERVIEW.md that project-kickoff creates is specifically designed to give project-briefing everything it needs. The five questions that project-briefing answers (objective, completed work, current milestone, next step, risks) all have their source material in the overview and log files.

Install and use

The skill is open source. Install it by copying the inner directory into your agent's skill directory:

cp -R project-kickoff/project-kickoff ~/.claude/skills/project-kickoff
# or
cp -R project-kickoff/project-kickoff ~/.codex/skills/project-kickoff

Only copy the nested project-kickoff/ directory, not the repo root.

Then create a new project directory, drop in your artifacts, and invoke the skill:

/project-kickoff

The whole process takes a few minutes. At the end, you have a project directory that any agent or human can pick up and work with immediately.

Like project-briefing, this is intentionally agent-agnostic. The files it creates are plain markdown, readable by any tool. Workflow assets should be portable.

The repo is at rocksoup/project-kickoff.

§ Closing the Visual Feedback Loop in AI-Assisted UI Development

Thu, 30 Apr 2026 00:00:00 GMT

The standard feedback loop in AI-assisted UI development looks something like this: you describe a change, the agent writes the code, you look at the browser, you take a screenshot, you paste it into the conversation. The agent looks at it and suggests the next change. You repeat this a dozen times to get a component right.

That manual step in the middle is not neutral. Every time you stop to take a screenshot and paste it back in, you're breaking your working context. You're also creating a gap where the agent is flying blind between changes: it produces output, waits, and has no signal about what that output actually looks like until you bring the information back to it.

I built aieyes to remove that gap. The agent takes its own screenshots and sees what it produced without you in the middle.

What it is

aieyes is a small MCP server that exposes two tools to Claude Code:

screenshot captures any URL and returns the image directly into the agent's context. It supports full-page capture, element-scoped capture via CSS selector, and custom viewport dimensions. The agent can use it exactly the way you would: navigate to a page, take a screenshot, look at it, and decide what to do next.

open_browser opens a URL in your system browser. This one sounds trivial but it fills a real gap: when the agent wants to show you something and have you confirm it, this is how it sends you there. The agent takes the screenshot for its own verification, then opens the browser for yours.

The screenshot tool is the one that changes how you work. The iteration loop that used to require you as an intermediary becomes autonomous. The agent can make a change, capture the result, compare it against what was asked for, and iterate, all within a single session without stopping to ask you to look at something.

The foundation

The screenshot capability is entirely built on shot-scraper, Simon Willison's headless browser screenshot tool. aieyes is a thin MCP wrapper around it: when Claude calls screenshot, the server shells out to shot-scraper, which drives a headless Chromium instance via Playwright, and returns the resulting PNG base64-encoded into the conversation.

I want to be explicit about this because it matters when something breaks. If a screenshot fails, the failure is almost certainly in shot-scraper or Playwright, not in aieyes itself. The tool is thin by design: one external dependency doing the real work, one MCP layer making it available to the agent.

The one honest friction point in the current setup: the path to shot-scraper is hardcoded in index.js. pip installs to a user-specific location that varies by machine and Python version, and there is no clean cross-platform way to resolve this automatically. The README tells you how to find the right path and where to update it. It is a one-time setup step, but it means the repo is not quite clone-and-run.

How I actually use it

The primary use case is iterative UI work. When I'm building a component and want the agent to verify its own output visually, I'll note in the session that the screenshot tool is available. The agent will use it at natural checkpoints: after making a change, before declaring something done, when comparing two layout options.

The selector parameter is underused and worth calling out. You can scope a screenshot to a specific element, which means the agent can focus on the component it changed without capturing irrelevant page context. That's cleaner than a full-page screenshot when you're debugging something specific.

The viewport parameters matter for responsive work. A component that looks right at 1280px can break at 390px. The agent can take both, compare them, and address the mobile layout without you needing to manually resize your browser.

What it doesn't replace

aieyes is for visual output during development iteration. It is not a substitute for live DOM inspection.

If you need to check whether a class was applied at runtime, query computed styles, verify a selector against the actual rendered markup, or confirm that a third-party script didn't inject extra wrapper elements: that's work for the Chrome DevTools MCP, not aieyes. The DevTools protocol works against the rendered DOM and can answer questions that a screenshot can't, because screenshots show what something looks like, not why.

The two tools are complementary. aieyes tells the agent whether it looks right. Chrome DevTools tells the agent what's actually in the DOM when it doesn't look right. I use both in the same sessions without conflict.

Setup

Requirements: macOS, Node.js 18+, Python 3 with pip.

pip3 install shot-scraper
shot-scraper install
which shot-scraper   # note this path

git clone https://github.com/rocksoup/aieyes.git
cd aieyes
npm install

Update the SHOT_SCRAPER path in index.js to match the output of which shot-scraper, then register it as a global MCP server in ~/.claude.json:

{
  "mcpServers": {
    "aieyes": {
      "command": "node",
      "args": ["/absolute/path/to/aieyes/index.js"]
    }
  }
}

Restart Claude Code. The screenshot and open_browser tools will be available in every session.

§ Show, Don't Describe: Analyzing UI Recordings with Claude Code

Tue, 28 Apr 2026 00:00:00 GMT

Text descriptions of UI behavior are lossy by nature. While developing and building with AI I am often passing screenshots of an interface to the agent to communicate what is on screen in a high fidelity way, but when the scenario I want to communicate is dynamic or interactive the quick screnshot is insufficent.

"The modal flickers when you click the button" doesn't tell the agent where in the sequence the flicker happens, what state precedes it, what it looks like at the moment it occurs, or whether it's a flash of the control state before a test variation loads.

A 10-second screen recording is not lossy in the same way. Everything is there. The sequence, the timing, the visual state at each moment.

So I built a skill that lets me hand a recording to Claude Code and get a frame-by-frame analysis back.

How it works

The skill uses FFmpeg to extract key frames from the recording using scene detection tuned for UI work. Standard film-editing thresholds miss subtle transitions, things like a modal opening, a spinner appearing, or a hover state changing. The threshold I landed on (0.1) catches those. It falls back to uniform 1fps sampling if the recording is visually static enough that scene detection doesn't fire.

It then reads every extracted frame directly into Claude's context, along with a contact sheet overview of the full sequence. From there it produces a structured breakdown: the starting UI state, what changes and when, the end state.

The first run surfaced something worth documenting: FFmpeg installed via Homebrew on macOS doesn't include libfreetype, so the drawtext filter for burning timestamps into frames fails silently unless you know to look for it. The skill now omits that filter entirely and notes why, so the next person using it doesn't spend time debugging a filter dependency.

What it caught in the first real test

The first recording I fed it was a 10-second clip of a website showing a behavior that was hard to describe precisely. Within four frames, the skill identified it as a classic A/B test flicker: the control state renders first, then the testing platform's script fires, evaluates its targeting rules, and swaps in the variant. You can see the original layout briefly before the form appears.

That identification was immediate and specific enough to be actionable. The fix isn't in the code, it's in the test platform configuration. That's the kind of answer that takes 30 minutes to reach through text description and back-and-forth clarification.

The iteration happened in the same session

One thing I find genuinely useful about building skills this way: they improve in real time. After the first run, I noticed two things that were wrong.

The temp files landed in /tmp/, which means they scatter outside the project and get cleaned up by the OS at unpredictable times. That's fine for a quick session but annoying in practice. The skill now writes frames to screen-recordings/ inside the project root, so they stay in context and you know where to find them.

The focus hint (the optional second argument for telling the skill what to look for) was optional in the invocation but easy to forget. The skill now prompts for it interactively if you don't provide one. A short question before the FFmpeg work starts is worth it: "general overview" is a valid answer, but "why does the header shift at the moment the modal opens" produces a much more targeted analysis.

Both changes happened in the same conversation where the skill ran for the first time. That feedback loop is one of the things that makes skills worth building.

When to use this versus a screenshot

I already have a skill for screenshot-grounded development (aieyes), which captures the live site at a specific viewport and reads it into context. That's the right tool when you have a static UI state you want to inspect.

Screen recording is for behavior. Anything that involves a sequence of states, a transition, a timing dependency, or something you'd otherwise describe with "when I click X, then Y happens" is a better fit for a recording than a screenshot.

Short clips work best. Under three minutes. If you have a longer recording, QuickTime's trim tool takes about 10 seconds to isolate the relevant segment, and the analysis is sharper for it.

The skill is public

The skill is available at rocksoup/videofeedback. It requires FFmpeg (brew install ffmpeg) and Claude Code. Copy SKILL.md into .claude/skills/screen-recording/ and it registers automatically at next launch.

Building Agent Memory That Survives Between Sessions | Pere Villega

Mon, 13 Apr 2026 00:00:00 GMT

original 170-line CLAUDE.md had Claude ignoring instructions in the middle. This isn’t a quirk, it’s a well-documented phenomenon.

§ Inspect before you ask: wiring Chrome's debug protocol into your AI workflow

Fri, 10 Apr 2026 00:00:00 GMT

I was in the middle of a GA4 event tracking project and needed to know the exact CSS selector for a promo button buried in a mega menu. I didn't know the answer off the top of my head.

I could have opened DevTools in my browser and clicked around. Instead, I queried the live DOM from inside Claude Code and had the confirmed selector in about 30 seconds.

That 30-second lookup is the point of this post.

The pattern: answer your own questions before they become someone else's

When you're coordinating across a project (with collaborators, with an AI doing implementation work, or just with your future self) ambiguity has a compounding cost. A question you can't answer right now becomes a blocker or a guess. With the right tooling, it becomes a 30-second lookup.

This applies at every stage of a project. During discovery, you're checking whether the live site matches the documented spec. During implementation, you're verifying selectors, event bindings, z-index stacking. During QA, you're confirming that the deployed version behaves the way the code says it should.

The common thread: you have a question about the live rendered page, and the answer lives in the DOM, not in the source code. Source tells you what the code intends. The live DOM tells you what actually happened after the framework, the CMS, the lazy loader, and the ad scripts all had their say.

The Chrome DevTools Protocol has been available for years. What's changed is that MCP servers make it a first-class tool in an AI workflow, not a standalone debugging utility. You don't need to leave your terminal to get the answer.

What the Chrome DevTools MCP actually gives you

The Chrome DevTools MCP server connects Claude Code to a running Chrome instance through the Chrome DevTools Protocol. That gives you a set of concrete capabilities:

Navigate to any URL. Load the page as a real browser, not a fetch request. JavaScript executes, lazy content loads, auth cookies apply.
Evaluate arbitrary JavaScript against the live DOM. document.querySelector, getComputedStyle, read dataset attributes, walk the DOM tree. Anything you could type in the Chrome console, the AI can run programmatically.
Extract markup, computed styles, event listener bindings. Not the authored CSS, but what the browser actually applied after cascade, specificity, and media queries resolved.
Take screenshots. Visual confirmation that the page state matches what you're querying. Useful for catching cases where the DOM says one thing and the layout says another.
Inspect network requests. See what resources loaded, what failed, what the response headers look like. Catch third-party scripts misbehaving without opening the Network tab manually.

The critical thing: you're working against the live, rendered site, not the source code, not a static build artifact. If a class gets added at runtime by a JS framework, you see it. If a lazy-loaded element hasn't rendered yet, you know. If a third-party script injects a wrapper div that shifts your layout, it's right there.

For analytics work, this means you can query selectors against the production site and get confirmed answers. No guessing, no "I think this is the right class."

The friction problem, and why it matters

The MCP itself is easy to configure. A few lines in .mcp.json and Claude Code picks it up at session start. The friction is upstream of that.

Chrome needs to be running with --remote-debugging-port=9222 for the MCP to connect. On macOS, that means quitting your existing Chrome session and relaunching with the flag. The first time, it's fine. The fifth time in a week, it's annoying enough that you start skipping it for "small" questions. And small questions answered with guesses are where projects accumulate technical debt.

Two pieces solve this:

A shell function (chrome-debug) that handles the quit-and-relaunch dance in one command. It closes Chrome gracefully, waits for the process to terminate, relaunches with --remote-debugging-port=9222, and polls until the debug port responds. One command, no manual steps, works from any terminal.

chrome-debug() {
  osascript -e 'tell application "Google Chrome" to quit' 2>/dev/null
  while pgrep -x "Google Chrome" > /dev/null; do sleep 0.5; done
  open -a "Google Chrome" --args --remote-debugging-port=9222
  echo "Waiting for debug port..."
  while ! curl -s http://localhost:9222/json > /dev/null 2>&1; do sleep 0.5; done
  echo "Chrome debug port active on 9222"
}

A Claude Code skill (/chrome-debug) that wraps the shell function, verifies the MCP connection is live, and optionally navigates to a URL, all from inside Claude Code without switching windows. The skill calls the shell function, confirms the port is responding, and reports back. From that point, every chrome-devtools MCP tool is available in the session.

The skill part matters more than it sounds. When the tool is one slash command away, you use it reflexively. When it requires a context switch to a terminal, a remembered flag, and a manual verification step, you skip it for "small" questions. Those are exactly the questions where guessing introduces errors.

What this changes about how you work

The selector lookup is a small example. The larger pattern is: when you can inspect the live site directly, a whole category of "I'll need to check on that" questions becomes "let me look that up now."

Need to confirm which elements exist in a mega menu before writing tracking code? Query the DOM.
Not sure whether a component is lazy-loaded or server-rendered? Check the live page.
Wondering if a CMS injected extra wrapper markup that changes your selector path? Inspect and find out.
Want to verify that the deployed site matches what the source code says it should produce? Screenshot and compare.

Each of those is a question that would otherwise stall work, either because you'd need to context-switch to a browser or because you'd guess and move on. The tool doesn't make you faster at guessing. It makes guessing unnecessary.

Any time you're writing code, documentation, or instructions that reference the live site (selectors, page structure, computed styles, loaded resources) the ability to query the real thing from inside your AI workflow eliminates an entire class of "I think this is right" hedging.

The setup

The full setup has three pieces: the MCP server configuration, the shell function, and the skill.

1. MCP server configuration (in .mcp.json at the project root):

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-chrome-devtools@latest"]
    }
  }
}

Claude Code reads this at session start and makes the chrome-devtools tools available automatically.

2. Shell function (in your .zshrc or .bashrc):

The chrome-debug function shown above. Source your shell config or restart your terminal after adding it.

3. Claude Code skill (optional, but recommended):

A skill file at .claude/skills/chrome-debug/ that wraps the shell function with verification. This gives you /chrome-debug as a slash command inside Claude Code, so you never need to leave the session to set up the connection.

Once all three are in place, the workflow is: /chrome-debug → Chrome relaunches with debugging → MCP connects → you can query the live DOM from inside Claude Code. The whole startup takes about five seconds.

When to reach for this versus other tools

This isn't the right tool for everything. Some guidelines from using it on real projects:

Use the Chrome DevTools MCP when you need the live rendered page: runtime-generated markup, computed styles, lazy-loaded content, third-party script effects. Anything where the source code and the browser output might diverge.

Use Playwright or a headless scraper when you need to automate a multi-step flow: click through a navigation, fill a form, capture a sequence of states. The Chrome DevTools MCP is better for point queries; Playwright is better for scripted interactions.

Use curl or fetch when you just need the raw HTML response. If you're checking whether a meta tag exists in the initial HTML, you don't need a full browser.

Read the source code when you're changing the implementation, not inspecting the output. The MCP shows you what the browser did with the code. The source shows you what you intended.

The sweet spot is exactly where I started: you have a specific question about the live page, and you want a verified answer in your current working context, without switching tools.

§ Skills as Lightweight Workflow Packaging: Project Briefing

Thu, 02 Apr 2026 00:00:00 GMT

The most useful agent skills are not magic prompts. They are lightweight workflow packages: a clear trigger, a repeatable method, and an expected output stored in files that can be reviewed and versioned.

That pattern matters because recurring work drifts when its procedure lives only in conversation history. A file-based skill gives the workflow a durable home, makes its assumptions visible, and lets different agents execute the same process.

Project Briefing is one concrete example. I keep many projects in flight and might step away from one for a week or more. When I return, I need a fast answer to three questions: what is this project trying to do, what just finished, and what should happen next?

What it does

The skill is designed to turn a project's real working state into a short, business-readable brief. Instead of dumping tickets or commit messages, it tries to answer five practical questions:

What is the project objective?
What was completed recently?
What is the current milestone?
What is the next concrete step?
What risks or open questions remain?

That structure matters. I usually do not need a changelog when I am re-entering a project. I need something closer to a handoff.

How I use it

The workflow is intentionally simple. I install the skill locally, then trigger it with plain-English prompts like:

get me up to speed
where did we leave this
give me the brief
summarize completed work and what's next

The skill reads across a few high-signal sources:

repo instruction files such as AGENTS.md and README.md
the project tracker, including Beads-backed repos
recent git activity
architecture docs, runbooks, plans, and notes
the current conversation when there is context that has not been written down yet

In practice, that means I can come back to a project and get a quick narrative instead of re-reading a pile of tracker state and commit history.

If you want to try it, install the nested skill directory rather than the repo root:

cp -R project-briefing/project-briefing ~/.codex/skills/project-briefing
# or
cp -R project-briefing/project-briefing ~/.claude/skills/project-briefing

Why I like skills in general

I use skills as lightweight workflow packaging for recurring jobs. They help me avoid rewriting the same instructions every session, and they make outputs more consistent across projects, machines, and agents.

For me, the value is less about magic and more about reducing startup friction. A good skill narrows a vague request into a reliable shape.

This project-briefing skill is a good example of that. It takes a messy mix of tracker state, docs, and recent implementation history and turns it into something I can actually use to decide what to do next.

It is also intentionally agent-agnostic. I want these workflow assets to move with me instead of being locked to one tool.

The repo is public here if you want to look at it or use it yourself: rocksoup/project-briefing.

If you find yourself wishing the source material existed before you need the briefing, take a look at project-kickoff. It's the companion skill that bootstraps new project directories with OVERVIEW.md, LOG.md, and CLAUDE.md so that project-briefing has something good to work with from day one.

§ Control Claude Code from Slack with the Channels MCP

Fri, 20 Mar 2026 00:00:00 GMT

Claude Code sessions are stateful. The agent has context, file access, a running tool environment but the session is tied to a terminal window which means you have to be sitting in front of it to interact with it.

A common occurence for me is to set Claude to work in Claude Code on my Mac and walk away from the computer and when I do that I lose touch with that open process. This solution offers a way to continue interacting with Claude in that session on my Mac via Slack on my phone.

Claude Code terminal on the left, Slack on the right. Message in, work done, reply back in the thread.

The setup: Claude Code is running a session on my laptop. As long as that session is open and the computer is awake and connected to the network I can pick up my phone, send a message to the right Slack channel, and Claude will act on it and reply. No app switching, no VPN, no remote desktop. Just Slack.

From Slack on my phone, mid-afternoon:

Which projects are best to work on next? Like which issues?

Claude ran bd ready, checked priorities, and replied in the thread within a few seconds. I didn't open the terminal.

How it works

You could already do something like this with Open Claw — using a Slack bot that talks to Claude through MCP. But that requires standing up a separate service. Channels looks like it is Anthropic addressing a part of the Open Claw feature set in Claude Code itself: a research preview MCP capability that lets external processes push events directly into a running session. Claude picks them up between turns, it finishes whatever it's doing then reads the message. The asynchronous nature is the point.

The Slack side uses Socket Mode, which opens a persistent WebSocket to Slack rather than waiting for Slack to push to you. No public URL, no ngrok session to babysit. Your machine dials out on startup and keeps the connection alive. It's the same model the official Telegram and Discord plugins use, and it's the right call for a tool running on a dev laptop.

One server file. One Slack bot. Each project gets its own channel configured by env vars in .mcp.json. Claude Code spawns the server at startup and the whole thing is running.

The thing that actually matters

The initial version worked one way: messages arrived, Claude did the work, nothing went back to Slack. The reply tool was listed correctly, but Claude wasn't calling it.

The fix was in the instructions field — the string the MCP server passes to Claude Code, which goes directly into the system prompt. The original wording told Claude to call reply "when appropriate." The working version is more direct:

CRITICAL: The user cannot see the terminal at all. The ONLY way they receive your response is if you call the reply tool. You MUST call reply after every single Slack message — no exceptions.

This is worth internalizing for any MCP tool that expects reliable behavior: the instructions field is your system prompt. Write it like a constraint, not a suggestion. Claude will follow vague guidance vaguely.

One security decision worth naming

An ungated channel is a prompt injection vector. Anyone who can reach the Slack channel can put arbitrary text in front of Claude.

The server gates on Slack user ID, not channel ID. That distinction matters in group channels, where gating on membership would let anyone in the channel inject messages. User ID is the right unit.

The short version

The Channels API turns Claude Code into something you can interact with asynchronously. The "one server, many projects" pattern keeps it from becoming maintenance work — add a project by creating a Slack channel, inviting the bot, and dropping a .mcp.json. Everything else is already running.

It's research preview, and it shows. But the model is right.

Pair it with screenshot-based visual feedback or live site inspection via the Chrome DevTools MCP to build a more complete picture of what the agent is doing while you're away from the terminal.

Next: give the agent eyes on the live site

The Slack bridge lets you send commands remotely, but the agent still can't see what it built. Inspect Before You Ask covers wiring Chrome's debug protocol into Claude Code so it can query live DOM, check layout, and verify its own work without you in the loop.

Resources

If you're building AI-assisted workflows into your team's development process, I work with organizations on exactly this kind of integration.

The Agent Skills Directory

Thu, 19 Mar 2026 00:00:00 GMT

Skills are reusable capabilities for AI agents. Install them with a single command to enhance your agents with access to procedural knowledge.

QuiverAI – Building the Future of Vector Design

Thu, 19 Mar 2026 00:00:00 GMT

Foundational models for Generating, Editing, and Animating vector graphics. Built by researchers. Made for designers.

The Dark Factory Is a .dot file — 2389 Research, Inc

Wed, 18 Mar 2026 00:00:00 GMT

The factory code is dorodango — polish it, throw it away, rebuild from spec. The pipeline files are the durable artifact. They’re the part worth sharing.

--- This resonates. The BPMN-ish build file.

The last year of localhost · Ona

Tue, 17 Mar 2026 00:00:00 GMT

Background agents humming across a software assembly line can't run on a laptop.

--- ++ on cloud environments for agent activity

OpenUI

Tue, 17 Mar 2026 00:00:00 GMT

An open source toolkit to make your AI apps respond with your UI.

DoltHub

Tue, 17 Mar 2026 00:00:00 GMT

Dolt is Git for Data The world's first and only version controlled SQL database

--- turns out I'm going to become an expert at DOLT now that Beads has adopted it...

Beads - Memory for your Agent and The Best Damn Issue Tracker Your're Not Using

Sun, 15 Mar 2026 00:00:00 GMT

The tool provides the memory. You provide the discipline.

--- Beads is in every repo owned by me, indispensable

The Self-Driving Codebase: Background Agents and the Next Era of Software Delivery

Fri, 06 Mar 2026 00:00:00 GMT

A coding agent needs your machine and your attention. A background agent needs neither. It runs in its own development environment in the cloud: full toolchain, test suite, everything. Completely decoupled from your device and your session.

Kick one off from your laptop, check the result from your phone. Trigger it from a PR, a Slack thread, a Linear ticket, a webhook, or just spin one up manually.

You're not steering it. You're not watching it. It's an asynchronous task: delegate, walk away, review later. It runs for as long as it needs to.

--- Strongly agree on the perspective here and looking forward to moving in this direction

§ A Catalog Is Not a Map: Architecture Context for AI Agents

Thu, 26 Feb 2026 00:00:00 GMT

I've been thinking about what makes AI-assisted development actually work at the session level. Not prompt engineering or model choice, but the operational context an agent receives when it starts. What does the agent read when it wakes up, and how accurate is it?

The answer I landed on is a document pattern I'm calling the Linear Walkthrough. I first wrote about it while implementing it on a side project called OnCourt. This week I implemented it here on this site.

The problem it solves

Every AI coding session starts with a context gap. The agent has no memory of the last session, no intuition built up from months of working in the codebase. It has to figure out the system from scratch.

The usual approach is to put a summary in CLAUDE.md: a list of directories, key files, and commands. That's better than nothing, but it's a catalog, not a map. It tells you what files exist, not how they relate. "The blog posts live in data/blog/" is useful. "Blog posts are MDX files that Contentlayer processes at build time, generating typed TypeScript objects that page components import from contentlayer/generated" creates understanding.

The difference is: one is a reference, the other is understanding.

What the Linear Walkthrough is

A single document, docs/architecture.md, that narrates how the system works from the outside in. Not a list of files, but a connected story about how data flows through the app.

It has six sections:

1. What the app is. One paragraph, plain English. What does this thing do and who uses it? Establishes context before diving into tech.

2. System map. An ASCII diagram showing all components and how they connect. Makes the overall topology scannable at a glance before you read the details.

3. Layers. One section per architectural layer, working from the bottom of the stack upward: data storage, content schema, configuration, pages, SEO, feature flags, analytics, and so on. Each layer explains not just what exists but how it connects to the layers above and below it.

4. End-to-end flows. Two or three concrete user journeys traced all the way through the stack. "Visitor reads a blog post" and "AI agent starts a session" on this site. These are the most valuable sections for agents because they stitch the layers into a coherent picture of cause and effect.

5. Infrastructure. Local dev, production, CI/CD. Deploy commands and what auto-deploys vs. requires manual action.

6. Maintenance rules. An explicit list of what changes require updating the document. This is what separates a useful doc from one that quietly goes stale in three weeks.

Key design decisions

Narrative, not catalog. Everything written from the perspective of a reader who needs to understand, not reference. Routes get a table, but the table has a paragraph above it explaining the request lifecycle.

Code snippets as schemas. Inline TypeScript and JSON blocks show data shapes directly. Readers shouldn't need to open contentlayer.config.ts to know what fields a blog post has.

Only verifiable facts. Every endpoint path, field name, and environment variable is copied directly from source. No inferred behavior, no aspirational behavior. This is the constraint that keeps the doc trustworthy.

Surgical updates. When code changes, only the affected section updates, not the entire document. A section-to-source mapping table in the maintenance rules tells you exactly which source files to read for each section.

AI-agent-optimized. The primary reader is an AI agent at session start. The goal is that after reading this document, the agent has enough context to complete routine tasks without exploring files.

On this site specifically

This site is a statically-exported Next.js portfolio site with a Contentlayer MDX pipeline, a blog feature flag, and a GitHub Actions deploy to GitHub Pages. The architecture isn't complicated, but the interactions between the feature flag, the redirect config, the sitemap generation, and the nav rendering are exactly the kind of thing an agent gets wrong without full context.

The system map for this site looks like:

Visitor's browser
  └── stonebergdesign.com (GitHub Pages CDN)
        └── Static HTML/CSS/JS (pre-built at deploy time)

Build pipeline (GitHub Actions)
  └── Next.js static export (EXPORT=1 UNOPTIMIZED=1)
        ├── Contentlayer: processes data/blog/**/*.mdx
        └── Next.js App Router: renders all pages to /out/

That's the whole thing. No server. No database. No auth. Even a simple system benefits from having its interactions documented, especially the blog feature flag, which touches four separate files and controls whether the blog exists at all for visitors.

Enforcing freshness

The pattern only works if the document stays accurate. Two mechanisms enforce that:

The update skill. A runbook at docs/skills/architecture-update/SKILL.md that gives a step-by-step process for updating the doc when code changes. It includes a section-to-source mapping table so you know exactly which files to read for each section, and an explicit checklist for accuracy (no inferred behavior, no aspirational behavior, no historical context).

The CLAUDE.md rule. A mandatory rule in the agent instructions file that lists the specific triggers for updating the architecture doc and points to the skill for procedure. The rule makes the update explicitly non-optional.

The key operational rule is: commit the doc update in the same commit as the code change. Treating it as optional or "I'll do it later" is what causes drift.

Maintenance burden

Realistically: low. Most changes are surgical: one route table, one field name, or one section header. The full document on this site is about 350 lines and took a single focused session to write. Future updates will be measured in paragraphs, not documents.

The discipline isn't writing the doc. It's committing the update alongside the code. That's the only hard part, and it's mostly a habit.

The pattern in one sentence

Write the architecture narrative once, keep it accurate with surgical updates, and give AI agents a rule that makes updating non-negotiable.

The broader principle is not specific to AI. Documentation earns trust when it explains relationships, stays close to verifiable source material, and changes with the system. AI agents simply make the cost of getting that wrong visible faster. A catalog helps an agent search; a map helps it reason.

Writing about Agentic Engineering Patterns for Real Work

Mon, 23 Feb 2026 00:00:00 GMT

I’m using Agentic Engineering to refer to building software using coding agents—tools like Claude Code and OpenAI Codex, where the defining feature is that they can both generate and execute code—allowing them to test that code and iterate on it independently of turn-by-turn guidance from their human supervisor.

--- This lands for me because it is about operating model, not branding. The meaningful shift is that the agent can act, verify, and keep going, which changes how much structure you need around tasks, documentation, and feedback loops.

The A.I. Disruption We’ve Been Waiting for Has Arrived

Wed, 18 Feb 2026 00:00:00 GMT

All of the people I love hate this stuff, and all the people I hate love it. And yet, likely because of the same personality flaws that drew me to technology in the first place, I am annoyingly excited.

The AI hater's guide to code with LLMs (The Overview) | All Confirmation Bias, All The Time

Mon, 16 Feb 2026 00:00:00 GMT

Suddenly, we have a clear technical reason to document everything, to use a clear type system, to clarify things with schemas and plans, to communicate technical direction before we’re in the weeds of editing code. All the things that developers are structurally pushed to do less of, even though they’re always a net win, are rewarded.

An AI Hater's Guide to Coding with LLMs: The How-To

Mon, 16 Feb 2026 00:00:00 GMT

Build Guard-rails

Add more tests. Get the LLM to write tests, and to suggest tests to write.

--- The useful reminder here is not “LLMs are bad” but “verification is the job now.” If the model makes implementation cheaper, then careful review, stronger tests, and tighter constraints become the part worth spending your own attention on.

Don't "Trust the Process"

Sun, 25 Jan 2026 00:00:00 GMT

Don't "Trust the Process" (via) Jenny Wen, Design Lead at Anthropic (and previously Director of Design at Figma) gave a provocative keynote at Hatch Conference in Berlin last September.

--- Impacts of AI tools on "best practices" for designers that apply broadly IMO. I do think that while the traditional process might not be as directly required/valuable now the practice of having run through it many times builds a mindset that I think is super valuable.

Software as clay on the wheel

Tue, 20 Jan 2026 00:00:00 GMT

--- Dries Buytaert on the rate of change in AI

The boundary keeps moving fast. A year ago, I was wrestling with local LLMs to generate good alt-text for images. Today, AI agents build working HTML5 parsers while you watch a movie. It's hard not to find that a little absurd. And hard not to be excited.

AddyOsmani.com - 21 Lessons From 14 Years at Google

Tue, 13 Jan 2026 00:00:00 GMT

The punchline isn’t “never innovate.” It’s “innovate only where you’re uniquely paid to innovate.” Everything else should default to boring, because boring has known failure modes.

Teaching Claude to Design Better: Improving Anthropic's Frontend Design Skill

Sat, 10 Jan 2026 00:00:00 GMT

By Justin Wetch ANTHROPIC DEFAULT FRONTEND SKILL REWRITTEN FRONTEND SKILL View the PR Request After building a GUI for Anthropic's Bloom framework last month (and more recently, proposing ten new behaviors it could test for), I found myself wanting to dig deeper into their ecosy

My Claude Code Workflow for Building Features

Thu, 08 Jan 2026 00:00:00 GMT

A structured workflow for using Claude Code with sub-agents to catch issues, maintain code quality, and ship faster. Plan reviews, code reviews, and persistent task management.

Remote Claude Code: programing like it was the early 2000s | Harper Reed's Blog

Wed, 07 Jan 2026 00:00:00 GMT

Harper Reed's phone setup: Tailscale for the network, Blink for SSH, Mosh and tmux so the session survives. Framed as nostalgia, but the practical result is running an agent from anywhere with no deployment infrastructure.

A field guide to sandboxes for AI

Wed, 07 Jan 2026 00:00:00 GMT

Simon Willison on the isolation options for running untrusted code: containers, microVMs, gVisor, and WebAssembly, and what each one actually protects you from. Relevant the moment you let an agent execute something you did not write.

Helping people write code again

Sun, 04 Jan 2026 00:00:00 GMT

If you have significant previous coding experience - even if it's a few years stale - you can drive these things really effectively. Especially if you have management experience, quite a lot of which transfers to "managing" coding agents - communicate clearly, set achievable goals, provide all relevant context.

A Code-Abundant World - Evis

Thu, 01 Jan 2026 00:00:00 GMT

In many ways, agents have turned codebases into stories, ones that need their narrative explicitly written in case the agent forgets and has to start over. This wasn't the case previously. As humans, we remember where we left off and the decisions we made to get there. Agents don't have that luxury. They need more context. The best part is that when they get it, they are even more productive than before.

Superpowers 4

Fri, 19 Dec 2025 00:00:00 GMT

I'm pleased to announce Superpowers 4.0.

designprompts.dev — Fix AI Design Drift Before It Starts

Fri, 12 Dec 2025 00:00:00 GMT

Drop these prompts into any AI assistant and ship beautiful, consistent interfaces in minutes.

The problem with AI-generated UI isn't the code — it's the aesthetic drift. Each generation pulls toward a bland, generic center unless you direct it with intention. This library addresses that by giving you pre-built style prompts — "brutalist," "glassmorphism," "Swiss grid" — that anchor the model to a specific visual language before it starts generating.

It's a small tool, but the insight behind it is sound: the way to get consistent AI design output is to be more specific about the design direction upfront, not to iterate your way out of mediocrity afterward.

packnplay: Making it easy to run coding agents in containers

Thu, 11 Dec 2025 00:00:00 GMT

a tool to make it easier to run your favorite coding agent in a container without a lot of setup. It's called packnplay. You can find it on GitHub

Improving frontend design through Skills | Claude

Thu, 11 Dec 2025 00:00:00 GMT

Best practices for building richer, more customized frontend design with Claude and Skills.

Accessible by Design: The Role of the 'lang' Attribute - HTMHell

Thu, 11 Dec 2025 00:00:00 GMT

I am here to discuss the importance of the language attribute in your code.

Useful patterns for building HTML tools

Wed, 10 Dec 2025 00:00:00 GMT

So cool!

CleanShot X for Mac

Tue, 09 Dec 2025 00:00:00 GMT

CleanShot is a super powerful replacement for the macOS tool.

The Hammer Hack – Rands in Repose

Wed, 03 Dec 2025 00:00:00 GMT

The other population knows a hammer doesn’t build anything for you; it just makes the act of building easier. Understanding the act of building doesn’t make your product good; it’s the experience of building and deeply understanding what you want to build that makes it great.

Making Software

Sat, 29 Nov 2025 00:00:00 GMT

Dan Hollick's reference manual on how the software you use every day actually works. Touch screens, Gaussian blur, vector graphics, carried by illustrations rather than tutorials.

Modern Illustration

Fri, 28 Nov 2025 00:00:00 GMT

Zara Picken's archive of commercial print work from roughly 1950 to 1975. Matchbox labels, greeting cards, advertising, catalogued with format, date, and creator where known.

OpenCode | The AI coding agent built for the terminal

Tue, 25 Nov 2025 00:00:00 GMT

The AI coding agent built for the terminal

OpenCode is fully open source, giving you control and freedom to use any provider, any model, and any editor.

tree-me: Because git worktrees shouldn’t be a chore | You’ve Been Haacked

Mon, 24 Nov 2025 00:00:00 GMT

Phil Haack's shell wrapper over git worktrees. It derives the repo name and default branch, files worktrees under a predictable path, and drops you into the new one. Useful if you are running several agents in parallel.

Understanding Spec-Driven Development: Kiro, spec-kit, and Tessl

Wed, 12 Nov 2025 00:00:00 GMT

What I like here is that it makes the value of spec-driven development concrete instead of mystical. The tooling will keep changing, but the pattern is already familiar: agents produce better code when you give them intent, boundaries, and acceptance criteria up front.

--- That is the same reason I keep leaning on architecture walkthroughs, issue context, and repo-local skills. The exact product names are less important than the discipline of giving the model a real brief before it starts typing.

Stream Ring: Voice-Activated Ring – Sandbar

Wed, 12 Nov 2025 00:00:00 GMT

A fast, private, & effortless way to capture thoughts in the moment. Whisper in a crowd. Hold to speak, tap to interrupt. Control your music with familiar gestures.

Very cool AI input.

Setting up a codebase for working with coding agents

Tue, 11 Nov 2025 00:00:00 GMT

I'm having great results from maintaining a GitHub issues collection for projects and pasting URLs to issues directly into Claude Code

One my personal favorites as well - GH Issues is my source of truth

§ How I Evaluate a Modern Web Stack

Wed, 15 Oct 2025 00:00:00 GMT

Stack choices are bets about the future. I evaluate them less by how quickly they produce a demo and more by whether a team can operate, change, and eventually hand off the resulting system. My criteria are durability, ecosystem depth, deployment clarity, access for automation and agents, and the cost of reversing the decision later.

My professional foundation is in open-source PHP content management systems, especially Drupal and WordPress. Working more directly with AI-assisted development gave me a useful reason to test those criteria against a different ecosystem, including React and Next.js.

This is a dated stack check-in, not a permanent recommendation. It records what I chose in October 2025, why the pieces fit the work, and what I would reevaluate as the surrounding ecosystem changes.

GitHub: The Hub

The backbone of my preferred stack is GitHub. This is the one part of the stack I don't optimize for portability. I find GitHub to be cost-effective, full-featured, and a platform I can rely on for the long term. I am paying $4/month for a Team account at GitHub to use the features I highlight below.

GitHub’s primary function is managed Git hosting, and it’s the industry standard for version control and collaboration. Beyond the basics, it offers a rich ecosystem of tools that are central to my setup:

GitHub Command Line Interface (CLI)

I use AI coding tools directly in the terminal and a key part of working with an agentic coding partner is having robust command-line tools the AI agents can interact with. The GitHub CLI is well-maintained, feature-rich, and makes it easy for AI agents (and me) to execute tasks directly from the command line.

GitHub Issues

GitHub Issues are a core feature within repositories used to track, plan, and discuss work. They're a flexible way to manage development and collaboration.

Anyone who has worked on my teams knows that rule number one before starting any coding is to “make a ticket.” This simple process ensures we document our intention before starting work. A well-written issue can be passed between contributors, support measuring outcomes against intentions, and serve as living documentation of the codebase.

Having this project management tool natively integrated with the code repository keeps everything connected and simple to use.

Continuous Integration / Delivery

GitHub's CI/CD features are excellent for automating workflows that respond to repository activity such as commits, merges, and pull requests. These automations are key to my development process - below is an outline of my process:

Write code locally on a feature branch aligned to a GitHub Issue.
Test local changes.
Push the branch to GitHub.
On the push activity a new environment is automatically updated with the code from that branch.
Review and QA on that remote environment.
Once approved, merge the branch via pull request.
Following the merge the pull request and associated issue are automatically updated and closed.

The automated provisioning of a lower environment and release orchestration saves an enormous amount of time and keeps deployment friction low.

GitHub Pages

GitHub Pages is one of my favorite GitHub features and something I don't think enough people take advantage of. It's a static site hosting service that takes HTML, CSS, and JavaScript files directly from a repository, optionally runs a build process, and publishes a website with no separate hosting required.

GitHub Pages doesn’t support interpreted languages like PHP, so if your project requires server-side functionality, you’ll need an external host. For static websites, though (like this blog), it’s fast, reliable, and free.

Web Application and Database Hosting

For projects that require dynamic hosting or databases, I look for solutions that emphasize portability. If a service changes its pricing, features, or policies, I want the freedom to migrate quickly without major rework.

I initially used Vercel to host a Next.js application and found the developer experience fantastic. However, I've since chosen to migrate to Netlify and Cloudflare, which offer similar features and align better with my values. This transition highlights why portability matters, I have made architecture decisions prioritizing making it easy to move.

For databases and authentication, I've had a great experience with Supabase. It made adding authentication and authorization straightforward, and its web dashboard and SQL Editor are easy to use while still supporting advanced features like row-level security.

Conclusion

I’m prioritizing rapid prototyping and app development, and this stack is hard to beat. It keeps you close to your code, removes deployment friction, and scales as your project grows. The learning curve is reasonable, documentation is plentiful, and the productivity gains are immediate.

With this flow, I spend more time building and the tools fade into the background.

§ Learning to Build with AI: The Agents I Use

Mon, 06 Oct 2025 00:00:00 GMT

Learning to Build with AI: The Agents I Use

As I’ve started documenting my work with AI-assisted development, I want to share not only what I’m learning conceptually, but also the practical tools and workflows that make this new way of building possible.

My use of AI tools for application development began shortly after the release of Claude Code in February 2025. Since then, a wave of new tools has emerged, each taking a different approach to enabling AI-assisted development.

For my own work, I’ve focused on Claude Code from Anthropic and Codex from OpenAI. These two tools best fit the development approach I prefer—one that maintains a high level of human oversight and code review. I want the AI to contribute meaningfully to the process, but I remain the ultimate approver: directing what work it does, reviewing every output, and ensuring all code meets my standards before it ships - this is "human in the loop" development.

As I’ve learned to develop alongside these new agentic assistants, I’ve been using the entry-level plans from both Anthropic and OpenAI, currently priced at $20 per month each. I often switch between agents for different tasks or when one has reached its usage limits. This ability to move seamlessly between platforms has become an important part of my workflow. It’s also shaping how I approach configuration, planning, development, and testing, ensuring everything I build is tool-agnostic and platform-independent. Managing tokens and usage is a big part of using AI for development right now and something I will be talking about more in future posts.

§ Building With AI After Fifteen Years in Web Technology

Thu, 02 Oct 2025 00:00:00 GMT

Why This Blog

I have spent more than fifteen years watching new technology arrive with promises to transform how teams build for the web. Some changes earned a permanent place in the stack. Others created a burst of activity and quietly disappeared. AI-assisted development feels consequential, but the interesting question is not whether the tools are impressive. It is whether they help us make better systems and better decisions.

This blog is where I share that practitioner view: what I am using in real projects, where it creates leverage, where it introduces risk, and how experience changes the way I evaluate it.

Where I'm Coming From

My career has moved through agency delivery, product and platform work at Tableau and Salesforce, enterprise systems at Veeva, and now independent consulting. Across those environments I have worked beside engineers, designers, product managers, marketers, and executives who needed technology decisions to survive contact with real organizations.

That cross-functional position is a credential, not a disclaimer. I can prototype, debug, and work directly in code, but I also know that shipping code is only part of the job. Architecture, governance, usability, organizational constraints, and the cost of future change matter just as much. AI makes implementation faster; it does not remove the need for judgment.

Why Now

AI has compressed the distance between an idea and a working implementation. That is useful, but speed changes the risk profile. Teams can now produce plausible code faster than they can understand, review, or maintain it. The durable advantage will not come from generating the most code. It will come from pairing faster execution with clear constraints, strong review, and an architecture that can absorb change.

That is the transition I want to examine: not AI as spectacle, but AI as part of a professional delivery system.

What's Next

I will write about workflows, tools, architecture, and case studies grounded in actual projects. Some posts will be time-bound check-ins because the tools are moving quickly. Others will focus on principles that should outlast the current generation of products.

The goal is straightforward: show the work, take positions, and share what changes when experienced practitioners can build more directly without giving up the judgment that experience earned.

Stoneberg Design

Datatype — variable font that turns text into charts

Open Source Alternatives to Popular Software

Using Claude Code: The unreasonable effectiveness of HTML | Claude

§ Project Kickoff: Start Every Project the Same Way

The bootstrapping problem

What project-kickoff does

Why these four files

The pair

Install and use

More on AI-assisted development

§ Closing the Visual Feedback Loop in AI-Assisted UI Development

What it is

The foundation

How I actually use it

What it doesn't replace

Setup

More on AI-assisted development

§ Show, Don't Describe: Analyzing UI Recordings with Claude Code

How it works

What it caught in the first real test

The iteration happened in the same session

When to use this versus a screenshot

The skill is public

More on AI-assisted development

Building Agent Memory That Survives Between Sessions | Pere Villega

§ Inspect before you ask: wiring Chrome's debug protocol into your AI workflow

The pattern: answer your own questions before they become someone else's

What the Chrome DevTools MCP actually gives you

The friction problem, and why it matters

What this changes about how you work

The setup

When to reach for this versus other tools

More on AI-assisted development

§ Skills as Lightweight Workflow Packaging: Project Briefing

What it does

How I use it

Why I like skills in general

More on AI-assisted development

§ Control Claude Code from Slack with the Channels MCP

How it works

The thing that actually matters

One security decision worth naming

The short version

Next: give the agent eyes on the live site

More on AI-assisted development

Resources

The Agent Skills Directory

QuiverAI – Building the Future of Vector Design

The Dark Factory Is a .dot file — 2389 Research, Inc

The last year of localhost · Ona

OpenUI

DoltHub

Beads - Memory for your Agent and The Best Damn Issue Tracker Your're Not Using

The Self-Driving Codebase: Background Agents and the Next Era of Software Delivery

§ A Catalog Is Not a Map: Architecture Context for AI Agents

The problem it solves

What the Linear Walkthrough is

Key design decisions

On this site specifically

Enforcing freshness

Maintenance burden

The pattern in one sentence

More on AI-assisted development

Writing about Agentic Engineering Patterns for Real Work

The A.I. Disruption We’ve Been Waiting for Has Arrived

The AI hater's guide to code with LLMs (The Overview) | All Confirmation Bias, All The Time

An AI Hater's Guide to Coding with LLMs: The How-To

Don't "Trust the Process"

Software as clay on the wheel

AddyOsmani.com - 21 Lessons From 14 Years at Google

Teaching Claude to Design Better: Improving Anthropic's Frontend Design Skill

My Claude Code Workflow for Building Features

Remote Claude Code: programing like it was the early 2000s | Harper Reed's Blog

A field guide to sandboxes for AI

Helping people write code again

A Code-Abundant World - Evis

Superpowers 4

designprompts.dev — Fix AI Design Drift Before It Starts

packnplay: Making it easy to run coding agents in containers