This Thursday I’m publishing Part 2: Surviving the Squeeze. If the org chart is compressing, what do you actually do about it? I cover five moves: why generalists are winning, how to think of yourself as an orchestrator running multiple agents and workstreams, why surrendering the details matters more than perfecting them, developing taste as a core skill, and how to evaluate whether the company you work at is going to make it through this.

Subscribe so you don’t miss it.

Subscribe now

About nine months ago, one of my team members asked if they could help with the social media app I’d been building on the side. Run it like a normal project. Track it, manage it, and bring some structure.

I said no. I was flying. I was the product manager, the project manager, the developer, and QA. My agents were my staff. I couldn’t justify bringing in a project manager. The reason was simple: by the time I explain the intent, the goals, the constraints, the assumptions, by the time we segment ownership and schedule ceremonies, I would already have built it, tested it, and gathered real signal from users.

I wrote about this in S2S a few months ago and framed it as a process problem, a mismatch between how we’ve learned to build software and our new reality. Since then I’ve started to think the problem is bigger than process. Agile was the first thing to stop making sense. The entire org chart is next.

The Memos

Between January and March of this year, a handful of CEOs published detailed plans to restructure their companies around AI. Specific memos with headcounts and new role definitions.

In February, Jack Dorsey posted a note on X to Block’s 10,000 employees. The company was cutting to under 6,000. Forty percent of the workforce, gone in a single announcement. His reasoning was simple: “Intelligence tools have changed what it means to build and run a company. A significantly smaller team, using the tools we’re building, can do more and do it better.”

Stock went up 25%.

Five weeks later, Dorsey and Sequoia’s Roelof Botha published a 4,000-word essay called “From Hierarchy to Intelligence.” The thesis: corporate hierarchy is a 2,000-year-old information routing hack inherited from the Roman army, and AI is the first technology capable of replacing what it does. Middle managers, in this framing, were human routers. They existed to relay information between layers and precompute decisions so executives didn’t have to process everything themselves. AI can do that now, continuously, without losing context or playing telephone.

Dorsey flattened Block into three explicit roles:

1. Individual Contributors: the builders. They write code, ship product, do the actual work.

2. Directly Responsible Individuals (DRIs): they own specific outcomes on 90-day cycles. One person, one outcome, full accountability.

3. Player-Coaches: senior people who mentor and guide Individual Contributors while still building themselves. Hands-on leadership, no pure managers.

That’s the entire org. The management layer between “person doing the work” and “person deciding what work matters” compressed into nothing.

At Meta, a leaked memo revealed a pilot reorganizing roughly 1,000 people in Reality Labs into what they call “AI-native pods.” Every employee gets one of three titles: AI Builder, AI Pod Lead, or AI Org Lead. The ratio: up to 50 individual contributors per manager. Zuckerberg told investors that 2026 would “dramatically change the way we work” and that he’d become convinced “small, talent-dense teams” are the optimal configuration. Meta set a target for H1 2026: 65% of engineers should write more than 75% of their committed code with AI assistance.

Their CFO reported output per engineer up 30% since the start of 2025. Power users were at 80%.

The same pattern is playing out everywhere. Shopify’s Tobi Lutke told managers they must prove a job can be done exclusively by AI before they’re allowed to hire. Shopify’s headcount dropped 30% while revenue grew 21% annually. Salesforce cut 4,000 customer support roles after Benioff said he’d hire no engineers this year. Duolingo declared itself “AI-first” and began replacing contractors with GPT-4.

In Q1 2026 alone, 78,557 tech workers were laid off. Nearly half of those cuts were attributed directly to AI.

Follow the Handoffs

So where do the roles go?

Think of any organization as a graph. There are nodes: the work itself. Analyzing product data. Writing requirements. Creating designs. Building the software. Testing it. Deploying it. Measuring whether it worked. And there are edges: the handoffs between each of those functions. A product manager translates strategy into a requirements document. A designer translates requirements into mockups. An engineer translates mockups into code. A QA team translates code into test results. Each translation is a boundary where context degrades, priorities get reinterpreted, and intent drifts.

The tools for doing the work at each node are maturing fast. Amplitude runs product analytics on a prompt. Figma and AI design tools generate interfaces from descriptions. Claude Code and Cursor write and test software. The individual jobs are getting easier. That part of the story is well covered.

The part that isn’t: the edges. The translation cost between functions. The overhead of turning one person’s output into another person’s input.

That’s what I was describing in my opening. I couldn’t justify bringing someone in because the coordination cost, the explaining, the documenting, the translating, the scheduling, exceeded the cost of just building. The edges were more expensive than the nodes.

In a traditional org, those edges are where most of the headcount lives. Project managers exist to synchronize the edges. Meetings exist to re-align after information degrades at a boundary. Documentation exists because the person writing the requirements and the person reading them sit in different rooms, on different teams, with different assumptions. The entire middle layer of most companies is edge infrastructure.

The nodes still exist. Someone still has to understand the user. Someone still has to make design decisions. Someone still has to write and review code. The work hasn’t vanished. But the friction between each piece of work, the part that used to require dedicated roles and recurring meetings and Jira boards and handoff ceremonies, is collapsing into a single workflow.

That’s the real squeeze. Map the edges in your own organization. The ones AI can eliminate are where roles disappear. The ones it can’t are where the humans still matter.

The Product Manager Squeeze

Start at the top of the chain. The product manager’s job has always been a hybrid: strategy, analysis, translation, stakeholder management, and occasionally therapy. PMs looked at platform data, user behavior, reviews, interviews, feedback. They made informed decisions about what to build and tracked specific metrics to know if it worked.

Most of that analytical work can now be done by an AI agent in seconds. Amplitude launched what they call “Agentic AI Analytics” in February: AI agents that continuously analyze product usage, identify problems, build dashboards, and communicate findings via Slack. Mixpanel and ThoughtSpot are converging on the same idea from different angles. The whole category is racing toward natural language as the primary interface for data.

The analytical side of product management was hard before. Most PMs didn’t do it well. The tooling required SQL or a data engineer or both.

Now it requires a question typed in English.

The strategic work remains. Setting direction, communicating with stakeholders, making judgment calls about what metrics matter and what tradeoffs are acceptable. That’s still human. But the analytical infrastructure that used to justify a dedicated analyst role, or a full data team, now runs on a prompt.

Design, QA, and the Rise of the Builder

Further down the chain: requirements and design. The design-to-development handoff tools exist today, but they still require heavy supervision. The gap between “what we want it to do” and “working software” is closing fast.

I think the designer and the product manager will merge. Design still matters, but the translation layer between “what we want” and “what it looks like” is shrinking, and the person who understands the user and sets direction will also be the person reviewing the AI’s output and saying yes or no.

QA will be largely automated. It already is for builders working this way. AI agents write tests alongside implementation. They catch regressions. They run coverage. The manual QA cycle where a human clicks through every flow after every sprint is already an artifact.

The builder.

The builder, in this new structure, owns the full chain. Requirements to development to testing to deployment. One person, working with AI agents, shipping a feature that used to require a pod of five or six. This is what Meta’s “AI Builder” title and Dorsey’s “Individual Contributor” role both assume. It’s what I described in S2S: the emerging operator who articulates intent with precision, works directly with AI to produce code and interfaces, and owns outcomes end to end.

There will still be coordination above the builder. Someone needs to ensure the work across builders aligns with company goals, that deployments don’t conflict, that the product holds together. A thin layer. A Player-Coach in Dorsey’s framing. A Pod Lead in Meta’s.

What Happens to Everyone Else

If the builder owns the full chain, what happens to everyone who used to own a piece of it? The project manager holding sprint planning for a team that no longer needs formal 2-week sprints. The QA lead running a test cycle that AI handles in minutes. The data analyst building dashboards that an agent builds on demand.

Some of those roles disappear entirely. Others get absorbed into the builder role. A few shift upward into the thin coordination layer.

And the ceremonies that held these teams together were designed for a world where execution was expensive and coordination was the price you paid. Daily standups lose their purpose when most of your collaborators are machines. Sprint planning falls apart when task estimation is meaningless. Everything is either trivial (seconds to minutes) or so large it’s an entire product. There’s no size 13 on the Fibonacci scale anymore. The XL task is an app.

This compression will be messy. Klarna cut 47% of its workforce and replaced 700 customer service workers with AI. Then they quietly started rehiring humans when the quality collapsed. The line between “AI can handle this” and “AI can handle this well enough” is thinner than the memos suggest. Companies that move too fast will overshoot and pull back. The ones that get it right will move deliberately, testing each collapsed handoff before committing to it.

The Taste Question

There’s a question underneath all of this about taste.

You could argue taste is purely data. Users engage more or they don’t. They come back or they don’t. Run the A/B test. Let the numbers decide. If an AI agent identifies an optimization and the data supports it, ship it. Why wait for a designer’s opinion?

For most decisions, that’s probably right.

But there’s a layer above the data. How does the product make people feel? What do they associate with the brand? Is this thing we’re building getting us closer to what we actually want to be, or are we optimizing ourselves into something nobody intended?

I think about Rick Rubin. He doesn’t play instruments on the records he produces. He doesn’t write the songs. What he does is sit in the room and say “that’s it” or “not yet.” He holds the vision for what the thing is supposed to feel like, and he protects it from the thousand small compromises that would dilute it into nothing.

That’s the role that survives at the edges. Taste at the beginning: what are we building and why. Taste at the end: is this what we meant. One person, course-correcting at a high level, while builders and agents do the work between.

Dorsey said something in his February memo that stuck with me. “I think most companies are late. Within the next year, I believe the majority of companies will reach the same conclusion and make similar structural changes.”

Eleven months before that memo, in March 2025, Dorsey explicitly denied that Block’s layoffs had anything to do with AI. By February 2026, AI was the entire thesis. That’s how fast the handoffs are collapsing.

Every org chart is a map of handoffs. AI is redrawing that map, and the roles that survive are the ones that sit where the handoffs can’t collapse: at the top, where someone has to decide what matters, and at the bottom, where someone has to judge whether the machine got it right. Everything in between is the squeeze.

I publish a few times a week. If you want it in your inbox, subscribe. If you know a builder who’d get something out of this, send it their way.

Subscribe now

Last week I opened Claude Code for the first time in about thirty days and felt like I was looking at a different product.

There were commands I didn’t recognize. Features people were tweeting about that I had zero context on. I use this tool every single day when I’m building, I write about it on this Substack, and I run a software agency where most of my engineers live inside of it. After my first few weeks away from Claude Code’s changelog, I felt behind.

I had spent nearly all of March buried in a fintech client project, getting over a year of code and infrastructure through a SOC2 audit. For anyone who hasn’t lived through one of those, it is the specific kind of work that consumes your attention completely. No time for X, podcasts, or side projects. Just control documentation, evidence collection, and the slow grind of making sure every system has a paper trail.

When I came up for air at the start of April and opened the Claude Code changelog, I just stared at it.

Two camps

There are two camps of people on this question right now, and I think it’s worth naming both before I show you anything.

The first camp is what I’ll call the “calm down” camp. Their position is reasonable. You don’t need to use every feature. You don’t need to know what shipped yesterday. Pick a workflow that works for you and go. Claude Code is still Claude Code. The thing you were using last month still works.

The second camp, and I am firmly in it, thinks the first camp is underestimating what’s actually happening.

I wanted to prove the second camp is right, so I did what I usually do when I’m confused about something. I went to the source.

Pulling the data

I cloned the anthropics/claude-code GitHub repository and pulled every tagged release from the last year. I extracted CHANGELOG.md at HEAD, parsed every version header, and ran git blame on the changelog file to date every entry back to the commit it was first written. That gave me 258 dated releases spanning April 2, 2025 to April 9, 2026.

I wanted to look at this four different ways, because I thought I owed it to the “calm down” camp to be fair. Every version of the chart I built was a response to an objection I could imagine them making. Here’s the progression.

Chart 1: Just count the releases

The first version of the chart is the one most people arrive at if they bother to check at all. You count tagged releases. One per version. Plot them by day.

258 releases in a year. Over the last four months, that’s roughly one release every 24 hours of business time. One per working day, stretched across a year, for a single product.

Those numbers sound damning on their own, but they’re not honest. A release that fixes one typo counts the same as a release that adds a major new feature. Counting releases is like counting commits.

Chart 2: Count the changelog bullets

Every Claude Code release ships with a changelog, and each release has a variable number of bullets describing what changed. So instead of counting releases, I counted the bullets inside them.

2,113 changelog bullets across 258 releases. About eight per release on average. One “update” from Anthropic is rarely one change. It’s usually eight things, stacked.

This is the first chart where you can start to see the shape I ended up obsessing over. For the first eight months, it’s mostly quiet. Then something happens around the new year.

I’ll come back to that.

But this chart has the same fundamental problem in a new form. “Fixed a typo in an error message” is still counted the same as “Added Channels: full Telegram and Discord integration with bidirectional MCP bridge.” Those are not the same kind of change.

You can see what I mean in the screenshot above. A short bullet and a long bullet, side by side. The character count alone carries meaningful signal about how much actually landed.

Chart 3: Weight by category

I categorized every bullet as one of four things: Added, Improved, Fixed, or Other. Then I weighted them.

Added features got a weight of four. Improved and Changed items got a weight of two. Fixed and Other items got a weight of one. Multiplied, stacked, colored.

Now you can see the shape of what’s shipping, not just the volume. And the first thing you notice is the orange.

The orange band is bug fixes. There’s a lot of orange. Across the full year, Anthropic shipped roughly 2.3 bug fixes for every new feature. A meaningful portion of the velocity you’re seeing is them patching things they shipped the week before. It’s how shipping fast actually works, especially when the product is being used by millions of developers in configurations nobody at Anthropic can fully predict.

But this chart is still wrong in a subtle way. Every Added bullet counts the same as every other Added bullet. Channels, the feature that briefly made people think Anthropic was going to kill the third-party agent ecosystem, counts as one Added times four. So does “Added a new environment variable for cache configuration.” Same score. Obviously not the same thing.

Chart 4: Weight by length

I weighted every single bullet by its character length. The intuition is straightforward. When Anthropic ships something big, they write a long description for it. When they ship something small, they write a short one. The mega-features get longer ones. It’s not perfect, but it’s worth acknowledging.

I multiplied character length by category weight, summed everything up per day, and plotted the full year. Then I went one step further and annotated the chart with the actual named launches that people talk about. Hooks. Skills. Subagents. Plugins. Worktrees. 1M context. Channels. Auto mode. The big things.

Look at the line on the bottom for the first eight months. It hovers somewhere between two and six. Flat. Steady. A product being developed at a rhythm we can absorb.

Then January 7th happens. v2.1.0 drops. And the floor of the chart doubles and never comes back down.

That is escape velocity. Anthropic broke orbit on January 7th and the new altitude is just the altitude now.

I want to be careful not to overstate this, because the first eight months aren’t nothing. Hooks shipped in June. Subagents in September. Skills in October. These are really useful and impressive features that people built real workflows around. But the rate at which they were arriving was something a normal human with a normal job could track. The new rate is not.

The maximum rate of absorption

When I finished building the charts, I sat with them for a few hours and got to a thought that kind of messed me up for a night.

We are at a ceiling. A ceiling that I don’t think most people in the industry are willing to accept. It is the ceiling of what a working human, with a job and other responsibilities and some expectation of sleep, can actually absorb in a given week.

Call it the maximum rate of absorption.

There was a window, roughly from when Claude Code launched through the end of last year, where a reasonably attentive developer could track everything Anthropic was shipping. You could read the changelog on Monday morning, try the new features that mattered to your work, and be more or less caught up by Monday afternoon. The product was evolving fast, but it was evolving at a human tempo. The tempo mattered.

That window closed sometime in January.

Past that point, the amount of surface area Anthropic is shipping per unit time exceeds what a single human can meaningfully evaluate, learn, and adopt. Simon Willison, who built his reputation on tracking exactly this kind of thing, told Business Insider recently that he hasn’t taken a proper break in three years and that he is “mass-subscribing to feeds” just trying to keep up. If Simon is drowning, you are drowning. Everyone who claims otherwise is drowning. The only difference is whether they'll admit it.

And the part that I whole heartedly believe: I don’t think Anthropic is building for humans anymore.

I don’t mean that as a conspiracy or a criticism. I mean it as a simple observation about their velocity. The tooling is getting richer faster than we can learn it. The configuration surface is getting denser faster than we can read the docs. The integration points are multiplying faster than we can wire them up. The only entity in the world that can actually keep pace with a product shipping at this rate is another AI.

We got our oracle moment. We built a tool that can absorb all the other tools. And now the tool that can absorb all the other tools is getting built, at some level, for the tool that absorbs all the other tools. Humans are still in the loop, but at what point will we start to look more like beta testers than users. We’re the training signal, not the target.

I wrote a piece a couple of months ago called The Great Filter for Ideas, where I argued that the people who were going to build with AI were mostly the ones who were already building before AI. The unlock came, but it came for the people who were going to build anyway. This feels like an extension of the same story from a different angle. The tooling is sprinting ahead of human comprehension. The gap is widening. And the only way to close it, if you are a working developer with a job and a family and some interest in staying sane, is to outsource the tracking of the tool to the tool itself.

Which is what brings me to the thing I actually built.

The slash command

I built a skill called /catch-up. When you run it in Claude Code, it kicks off a multi-minute audit of your entire setup and produces a long, opinionated, evidence-backed report.

Under the hood it spawns three research agents in parallel. One fetches the full Claude Code feature surface from the official docs and the changelog — every slash command, every hook event, every CLI flag, every settings option. One does a deep dive on your actual usage history: it reads your past 25 sessions from ~/.claude/projects/, counts which tools you actually call, which slash commands you actually type, which prompts you keep repeating, and which errors keep showing up. The third audits your configuration top to bottom, global and project CLAUDE.md, every skill in ~/.claude/skills/, every MCP server, every hook, every custom agent, plus the shape of the repo itself.

Then it cross-references all three and writes you a report with eight sections.

The first section is a profile dashboard. Sessions analyzed, tool call breakdown, error count, branches you’ve worked on, what’s installed. The second is a feature adoption matrix, every meaningful Claude Code capability with your status next to it. Using, Configured but never called, Not set up, Remove this. The third is recent launches with a does this apply to you verdict on each one. The fourth is dead weight, MCP servers you configured but never call, plugins that load on every session and never fire, hooks running on the wrong events. The fifth is workflow automation. The skill mines your repeated prompts and surfaces patterns. You typed “run the tests” eleven times last week. Here’s a slash command that does it. The sixth is CLAUDE.md gaps. The seventh is configuration improvements. The eighth is a prioritized action list with time estimates next to each item, ranked by impact.

And every single recommendation is cited. You have zero Swift files in this project but the swift-lsp plugin loads on every session. Here is the command to disable it. You asked “what branch am I on” in three different sessions this week. Here is a status line config that puts the branch in your prompt. You have a Figma file in /design and you have never installed the Figma MCP. Here is the install command. It does not give you generic advice. It tells you specifically what it saw and what to do about it.

The best part is that the report is interactive. At the end it says: “Reply with the numbers of items you want me to execute now.” You type back which ones you want, and Claude Code installs the missing MCP server, adds the hook, rewrites the skill frontmatter, trims your CLAUDE.md, updates your settings, all in the same session. You stay in your chair and the gap closes while you watch.

How to install

1. Copy the skill code below.

2. Create the skills directory if it doesn’t exist yet. Open your terminal and run:

   mkdir -p ~/.claude/skills/catch-up

3. Create the skill file at the right path. Still in your terminal:

   nano ~/.claude/skills/catch-up/SKILL.md

(Or use any text editor — vim, code, cursor, whatever you prefer.)

4. Paste the contents you copied in step 1 into the file. Save and close.

   • In nano: Ctrl+O, Enter, Ctrl+X

   • In vim: :wq

   • In a GUI editor: Cmd+S

5. Verify the file is in the right place:

   ls ~/.claude/skills/catch-up/

You should see SKILL.md listed.

6. Open a new Claude Code session in any project. If you have a session open already, exit it first (Ctrl+D or /exit) and start a new one with claude from the project directory you want to audit. Skills are loaded at session start, so an existing session won’t see the new skill until you restart.

7. Run the command:

   /catch-up

⚠️ Heads up: the report is long on purpose. The skill runs at effort:high with ultrathink enabled, takes anywhere from 2 to 20 minutes, and uses a good amount of tokens. Make sure you've got the time and the budget before you run it.

---
name: catch-up
description: Full Claude Code capability audit — enumerates every feature available, maps each against your actual usage and config, surfaces what you're missing, highlights recent launches, and produces an exhaustive personalized report. User-invoked only — the agent will never auto-fire this.
allowed-tools: Read, Glob, Grep, Bash, WebFetch, Agent
disable-model-invocation: true
effort: high
---

# Catch Up

ultrathink

You are running a comprehensive Claude Code audit. The goal is to help the user discover and use every Claude Code feature relevant to how they actually work — not just recent additions, but the full capability surface. A user who types /catch-up wants a thorough report, not a quick summary. Be exhaustive. Be specific. Be verbose. This report should take several minutes to produce and should be long.

The output has two parts:
1. **The full picture** — here is everything Claude Code can do, organized by category, with your current adoption status next to each
2. **Personalized action items** — here is what you specifically should do, backed by evidence from your actual sessions, config, and codebase

---

## ANTI-HALLUCINATION RULE

Every feature citation must quote exact text from a source you fetched. Never invent version numbers, dates, or feature descriptions. If you cannot find a real source for a claim, write: `[no source found — inferred from analysis]`. This rule applies to every single item in your output.

---

## Step 1 — Locate session directory

Run this first. You need the actual path before spawning agents.

```bash
CWD=$(pwd)
PROJECT_KEY=$(echo "$CWD" | sed 's|/|-|g; s|_|-|g')
SESSIONS_DIR="$HOME/.claude/projects/$PROJECT_KEY"

if [ -d "$SESSIONS_DIR" ] && [ -f "$SESSIONS_DIR/sessions-index.json" ]; then
  echo "FOUND:$SESSIONS_DIR"
else
  BASENAME=$(basename "$CWD" | sed 's|_|-|g')
  CANDIDATE=$(ls "$HOME/.claude/projects/" 2>/dev/null | grep -- "-$BASENAME$" | head -1)
  if [ -n "$CANDIDATE" ]; then
    echo "FOUND:$HOME/.claude/projects/$CANDIDATE"
  else
    echo "NOT_FOUND"
  fi
fi
```

Also run:
```bash
pwd
cat package.json 2>/dev/null | python3 -c "import json,sys; p=json.load(sys.stdin); print(p.get('name','?'), '|', p.get('version','?'))" 2>/dev/null
```

Record the actual SESSIONS_DIR path and project name. You will embed these in the agent prompts below.

---

## Step 2 — Launch three research agents in parallel

**Critical**: spawn all three agents in a single message so they run simultaneously. Do not wait for one before starting the next.

Embed the actual SESSIONS_DIR path and project cwd into each agent prompt before launching.

---

### Agent A — Full Feature Researcher

Prompt (fill in PROJECT_CWD with the actual path before sending):

```
You are researching the complete Claude Code feature set to build an exhaustive inventory.

Fetch ALL of these pages. Do not skip any. Read each one fully:

1. https://code.claude.com/docs/en/changelog
2. https://code.claude.com/docs/en/
3. https://code.claude.com/docs/en/settings
4. https://code.claude.com/docs/en/hooks
5. https://code.claude.com/docs/en/mcp
6. https://code.claude.com/docs/en/skills
7. https://code.claude.com/docs/en/memory
8. https://code.claude.com/docs/en/cli-reference
9. https://code.claude.com/docs/en/tools-reference
10. https://api.github.com/repos/anthropics/claude-code/releases?per_page=50

From these sources, build a COMPLETE feature inventory organized into these categories. For each item, include: feature name, what it does (1 sentence), how to enable it, and the source URL + quote.

CATEGORIES TO COVER (be exhaustive within each):

**A. Built-in slash commands**
List every /command that exists. Include what it does and any arguments.

**B. Hook events**
List every hook event type (PreToolUse, PostToolUse, PostToolUseFailure, UserPromptSubmit, Stop, SubagentStop, PostCompact, TaskCreated, WorktreeCreate, WorktreeRemove, CwdChanged, FileChanged, StopFailure, SessionStart, SessionEnd, InstructionsLoaded, ConfigChange, ElicitationResult, PermissionDenied, etc.)
For each: what triggers it, what data it receives, what it can return.

**C. MCP capabilities**
What MCP servers can do, how to configure them, OAuth support, etc.

**D. Skill system**
All frontmatter fields available in SKILL.md (name, description, allowed-tools, disable-model-invocation, effort, model, argument-hint, etc.)
What skills can do that plain commands can't.

**E. Agent/subagent system**
Custom agents in .claude/agents/, frontmatter fields, background agents, worktree isolation, the Agent tool, SendMessage, etc.

**F. CLI flags and modes**
Every flag: --resume, --continue, --worktree, --bare, --print, --model, --effort, --agent, --channels, --name, --mcp-config, etc.
Special modes: auto mode, bypass-permissions, accept-edits, plan mode.

**G. Settings and configuration**
Every setting in settings.json that is useful for a typical developer. Group: permissions, hooks, MCP, display, performance, experimental.

**H. Keyboard shortcuts**
All default shortcuts and any that are rebindable via keybindings.json.

**I. Recent launches (last 60 days)**
List every significant feature released in the last 60 days in chronological order newest-first. Include: feature name, release version, date, what it does, how to enable.

**J. Status line**
What statusLine supports, the JSON schema, refreshInterval, rate_limits field, etc.

**K. Memory system**
Auto-memory, /memory command, MEMORY.md, custom memory directory, etc.

Return the COMPLETE inventory. Do not summarize or truncate. Include everything you found. Quote sources for everything.
```

---

### Agent B — Deep Usage Analyst

Prompt (fill in SESSIONS_DIR with the actual path before sending):

```
You are doing a deep analysis of Claude Code usage history for this project.

Sessions directory: SESSIONS_DIR_PLACEHOLDER

Run ALL of the following analyses. Be thorough. Return raw data and patterns, not just summaries.

**B1. Session overview**
```bash
python3 << 'PYEOF'
import json, os
path = "SESSIONS_DIR_PLACEHOLDER/sessions-index.json"
with open(path) as f:
    idx = json.load(f)
entries = sorted(idx.get("entries", []), key=lambda e: e.get("modified", ""), reverse=True)[:25]
print(f"Total sessions: {len(idx.get('entries', []))}")
print(f"Showing most recent 25:\n")
for e in entries:
    date = e.get("modified", "?")[:10]
    msgs = e.get("messageCount", "?")
    branch = e.get("gitBranch", "") or "—"
    summary = e.get("summary", "")[:100]
    first = e.get("firstPrompt", "")[:80]
    print(f"{date} | {str(msgs):>4}msg | {branch}")
    print(f"  {summary}")
    print(f"  → {first}")
    print()
PYEOF
```

**B2. Tool call frequency (all recent sessions)**
```bash
ls -t "SESSIONS_DIR_PLACEHOLDER"/*.jsonl 2>/dev/null | head -25 | xargs grep -hoE '"tool_name":"[A-Za-z_][A-Za-z0-9_]*"' 2>/dev/null | sed 's/"tool_name":"//;s/"//' | sort | uniq -c | sort -rn | head -40
```
Also try this pattern if the above returns nothing:
```bash
ls -t "SESSIONS_DIR_PLACEHOLDER"/*.jsonl 2>/dev/null | head -25 | xargs grep -hoE '"name":"[A-Za-z_][A-Za-z0-9_]*"' 2>/dev/null | sed 's/"name":"//;s/"//' | grep -v '^$' | sort | uniq -c | sort -rn | head -40
```

**B3. MCP tool usage**
```bash
ls -t "SESSIONS_DIR_PLACEHOLDER"/*.jsonl 2>/dev/null | head -25 | xargs grep -hoE '"name":"mcp__[^"]+' 2>/dev/null | sed 's/"name":"mcp__/mcp__/' | sort | uniq -c | sort -rn
```

**B4. Slash commands used**
```bash
ls -t "SESSIONS_DIR_PLACEHOLDER"/*.jsonl 2>/dev/null | head -25 | xargs grep -hoE '"text"\s*:\s*"/[a-z][a-z0-9_/-]*' 2>/dev/null | grep -oE '/[a-z][a-z0-9_/-]*' | sort | uniq -c | sort -rn | head -30
```

**B5. Repeated user prompts (pattern mining)**
```bash
ls -t "SESSIONS_DIR_PLACEHOLDER"/*.jsonl 2>/dev/null | head -25 | while IFS= read -r f; do
  python3 - "$f" << 'PYEOF'
import json, sys
try:
    for line in open(sys.argv[1], errors='replace'):
        try:
            obj = json.loads(line)
            if obj.get('type') != 'user':
                continue
            msg = obj.get('message', {})
            if not isinstance(msg, dict):
                continue
            content = msg.get('content', '')
            if isinstance(content, list):
                for block in content:
                    if isinstance(block, dict) and block.get('type') == 'text':
                        t = block.get('text', '').strip()
                        if 15 < len(t) < 150 and not t.startswith('<') and not t.startswith('{'):
                            print(t)
            elif isinstance(content, str):
                t = content.strip()
                if 15 < len(t) < 150 and not t.startswith('<') and not t.startswith('{'):
                    print(t)
        except:
            pass
except:
    pass
PYEOF
done 2>/dev/null | sort | uniq -c | sort -rn | head -40
```

**B6. Error patterns**
```bash
ls -t "SESSIONS_DIR_PLACEHOLDER"/*.jsonl 2>/dev/null | head -25 | xargs grep -ohoE '"is_error"\s*:\s*true' 2>/dev/null | wc -l
echo "---"
ls -t "SESSIONS_DIR_PLACEHOLDER"/*.jsonl 2>/dev/null | head -25 | xargs grep -hoE 'String to replace not found|permission denied|requires permission|not allowed|command not found|ENOENT|EACCES|WebGL|WebSocket.*failed|403|404|500' 2>/dev/null | sort | uniq -c | sort -rn | head -20
```

**B7. Session depth distribution**
```bash
python3 << 'PYEOF'
import json
with open("SESSIONS_DIR_PLACEHOLDER/sessions-index.json") as f:
    idx = json.load(f)
counts = sorted([e.get("messageCount", 0) for e in idx.get("entries", [])], reverse=True)
print(f"All sessions by depth: {counts[:30]}")
print(f"Average: {round(sum(counts)/len(counts),1) if counts else 0}")
print(f"Max: {max(counts) if counts else 0}")
over30 = len([c for c in counts if c > 30])
over60 = len([c for c in counts if c > 60])
print(f"Sessions > 30 msgs: {over30}")
print(f"Sessions > 60 msgs (autocompact risk): {over60}")
PYEOF
```

**B8. Git branch patterns from session history**
```bash
python3 << 'PYEOF'
import json
with open("SESSIONS_DIR_PLACEHOLDER/sessions-index.json") as f:
    idx = json.load(f)
branches = {}
for e in idx.get("entries", []):
    b = e.get("gitBranch", "") or "unknown"
    branches[b] = branches.get(b, 0) + 1
for b, count in sorted(branches.items(), key=lambda x: -x[1]):
    print(f"{count:>4}x {b}")
PYEOF
```

**B9. Recent session summaries (more detail)**
Read the summaries from sessions-index.json for the 10 most recent sessions in full. Show the complete summary field for each.

**B10. Tool use interrupts**
```bash
ls -t "SESSIONS_DIR_PLACEHOLDER"/*.jsonl 2>/dev/null | head -25 | xargs grep -hoE '"interrupted"\s*:\s*true|"cancelled"\s*:\s*true|user.*interrupt|tool.*cancel' 2>/dev/null | wc -l
```

Return ALL raw data. Do not truncate output. The caller needs the full picture to make recommendations.
```

---

### Agent C — Config and Project Auditor

Prompt (fill in PROJECT_CWD with the actual working directory before sending):

```
You are doing a complete audit of a project's Claude Code configuration and codebase structure.

Working directory: PROJECT_CWD_PLACEHOLDER

Read ALL of the following. Return the full content of each (not summaries).

**C1. Global Claude configuration**
- Read ~/.claude/CLAUDE.md — show line count and full content
- Read ~/.claude/settings.json — show full content
- Read ~/.claude/settings.local.json if it exists
- List ~/.claude/skills/ — show all skill names and their SKILL.md frontmatter
- List ~/.claude/commands/ — show all command names
- List ~/.claude/agents/ — show all agent names and their frontmatter

**C2. Project-level Claude configuration**
- Read PROJECT_CWD_PLACEHOLDER/CLAUDE.md — show full content and line count
- Read PROJECT_CWD_PLACEHOLDER/.claude/settings.json if it exists
- Read PROJECT_CWD_PLACEHOLDER/.claude/settings.local.json if it exists
- List PROJECT_CWD_PLACEHOLDER/.claude/skills/ — show all skill names
- List PROJECT_CWD_PLACEHOLDER/.claude/commands/ — show all command names
- List PROJECT_CWD_PLACEHOLDER/.claude/agents/ — show all agent names
- Read PROJECT_CWD_PLACEHOLDER/.mcp.json if it exists

**C3. Auto-memory files**
List and read ALL files in:
~/.claude/projects/$(echo "PROJECT_CWD_PLACEHOLDER" | sed 's|/|-|g; s|_|-|g')/memory/
Show full content of each memory file. These are crucial for understanding what the project is about.

**C4. Project stack**
Run:
```bash
cat PROJECT_CWD_PLACEHOLDER/package.json 2>/dev/null | python3 -c "
import json,sys
p=json.load(sys.stdin)
print('name:', p.get('name'))
print('version:', p.get('version'))
print('scripts:', json.dumps(p.get('scripts',{}), indent=2))
deps={**p.get('dependencies',{}),**p.get('devDependencies',{})}
print('all deps:', json.dumps(sorted(deps.keys()), indent=2))
"
ls PROJECT_CWD_PLACEHOLDER/.github/workflows/ 2>/dev/null
cat PROJECT_CWD_PLACEHOLDER/railway.toml 2>/dev/null
ls PROJECT_CWD_PLACEHOLDER/prisma/ PROJECT_CWD_PLACEHOLDER/migrations/ 2>/dev/null
find PROJECT_CWD_PLACEHOLDER -maxdepth 3 -name "*.test.*" -o -name "*.spec.*" 2>/dev/null | head -10
ls PROJECT_CWD_PLACEHOLDER/src/ 2>/dev/null | head -20
```

**C5. MCP configuration detail**
Show the full MCP server configurations from settings.json, settings.local.json, and .mcp.json. For each server: name, type, command/url, and any config options.

**C6. Hook configuration detail**
Show every hook currently configured: event type, matcher, command, and whether it's in global or project settings.

**C7. Current git state**
```bash
cd PROJECT_CWD_PLACEHOLDER && git branch --show-current 2>/dev/null
cd PROJECT_CWD_PLACEHOLDER && git log --oneline -10 2>/dev/null
cd PROJECT_CWD_PLACEHOLDER && git remote -v 2>/dev/null
```

Return EVERYTHING. Full file contents, not summaries. The caller needs the raw data.
```

---

## Step 3 — Synthesize all three agent results

After all three agents complete, you have:
- **A**: Complete feature inventory from official docs + changelog
- **B**: Deep usage profile from JSONL history  
- **C**: Full config + project context

Now cross-reference everything and produce the report below.

---

## Step 4 — Produce the full report

The report must be comprehensive and verbose. Do not summarize. Do not cap at N items. Show everything relevant. Use clear markdown headers and tables where appropriate.

---

### SECTION 0: Your Claude Code Profile

A dashboard view. Show:
- Installed Claude Code version (run `claude --version`)
- Sessions analyzed, date range, total message count
- Most active branches
- Tool call breakdown (top 10 tools with counts)
- Average session depth, max session depth
- Error count and top error types
- Skills installed (global + project)
- MCP servers configured
- Hooks configured
- Custom agents defined

---

### SECTION 1: Feature Adoption Matrix

For EVERY major Claude Code capability, show adoption status. Organize by category. Use this table format:

```
| Feature | Status | Notes |
|---------|--------|-------|
| /compact | ✓ Used | Called 3× |
| /resume  | — Never used | Would save context on long sessions |
| /loop    | — Never used | Could automate your deploy checks |
```

Status options:
- **✓ Using** — confirmed in session history
- **⚙ Configured** — set up but zero usage
- **— Not set up** — not configured, not used
- **✗ Dead weight** — configured but never used, likely should remove
- **N/A** — doesn't apply to this project/stack

Cover ALL of these categories (from the feature inventory Agent A built):
- Built-in slash commands (every single one)
- Hook events (every event type)
- MCP capabilities
- Skill system features
- Agent/subagent features
- CLI modes and flags
- Settings options (meaningful ones)
- Status line
- Memory system features
- Keyboard shortcuts (notable ones)

For every "— Not set up" item where usage data or project structure suggests it would help: add a note explaining WHY it fits this project specifically.

---

### SECTION 2: Recent Launches — What Just Shipped

For every significant feature released in the last 60 days (from Agent A's changelog research):

Show each as:

```
#### {Feature Name} — {version} ({date})
{Exact quote from changelog}

**Applies to you**: Yes/No/Maybe — {1 sentence why, citing specific evidence from B or C}
**How to enable**: {exact command or config}
```

Do not skip any release. Do not filter. Show everything that shipped. Let the user decide what matters.

---

### SECTION 3: Dead Weight — Remove This

List everything that is configured but produces zero value:
- MCP servers with 0 calls in history
- Plugins/skills installed but never invoked
- Hooks firing on events they don't need to fire on
- Settings that do nothing for this stack

For each: what it is, the evidence it's unused, the command to remove it.

---

### SECTION 4: Workflow Automation Opportunities

From the repeated prompt analysis (Agent B, section B5), identify patterns the user repeats manually that Claude Code features could automate. For each:

```
#### Pattern: "{the repeated phrase or workflow}"
Seen: N times across sessions
Could be automated by: {specific Claude Code feature}
How: {exact implementation}
```

Look for: commit/push workflows, deploy triggers, branch questions, context re-establishment, test runs, repeated preambles that belong in CLAUDE.md.

---

### SECTION 5: Your CLAUDE.md Gaps

Based on the project structure (Agent C) and repeated prompts (Agent B), identify what belongs in CLAUDE.md that isn't there yet. Show:
- Current CLAUDE.md line count and whether it's approaching the effective limit (~200 lines)
- Repeated context that users provide verbally that should be documented
- Missing conventions (deploy workflow, component patterns, design system rules)
- Anything in memory files that should graduate to CLAUDE.md

---

### SECTION 6: Configuration Improvements

Specific changes to settings.json, hooks, or MCP setup that would reduce friction. For each:
- What to change and why
- The exact config snippet
- Expected benefit (cite the error/friction pattern from B6 it addresses)

---

### SECTION 7: Prioritized Action Items

Number every actionable recommendation from the entire report. Rank by expected impact. Format:

```
1. [10 min] **Remove swift-lsp plugin** — loads on every session, zero Swift files
   → claude plugin disable swift-lsp@claude-plugins-official
   → Evidence: 0 Swift files in project, 0 swift-lsp tool calls in 25 sessions

2. [5 min] **Add status line showing git branch** — you asked "which branch?" in 3 sessions  
   → Add to ~/.claude/settings.json: "statusLine": {"command": "...", "refreshInterval": 10}
   → Evidence: B5 repeated prompt analysis, session data

...
```

No cap on the number of items. Include everything worth doing.

---

### SECTION 8: Things to Know About

Features that exist and are relevant but don't require immediate action — just awareness. Organized as a bulleted list of short "did you know" facts specific to this project/workflow. Include exact docs links or changelog quotes.

---

## Output rules

- **Be exhaustive**. A short report is a failure. This should take several minutes to read.
- **Never truncate a section**. If a table has 30 rows, show all 30.
- **No generic advice**. Every item must cite something specific from this project, this config, or this usage history.
- **Quote your sources**. Every feature cite gets a verbatim quote from the fetched content.
- **Show the data**. Where you drew conclusions from usage counts or error patterns, show the numbers.
- **End with**: "Reply with the numbers of items you want me to execute now." Then execute whatever they choose.

You can trim it, extend it, or fork it for your team.

What I think this means

I want to go back to the “calm down” camp for a second, because I owe them a fair hearing.

They are right that you don’t need to use every Claude Code feature. They are right that the thing you were using last month still works.

What I think they are missing is that the ceiling moved. There was a version of this tool where you could be a good user without trying too hard, and that version is gone. The new version requires either a full-time commitment to tracking the changelog, which few people have, or a system that tracks the changelog for you. I do not see a third option, there’s just too much being release each day.

I can live with that, I think.

We built the oracle. The oracle is now improving faster than we can absorb its improvements. The realistic path for a working developer who wants to stay close to the frontier is to use the oracle to keep up with the oracle. It is recursive and a little absurd, but it is also the honest answer to the situation we are actually in.

If this was useful, subscribe. Thank you.

Subscribe now

I was poking around the Claude Code binary trying to figure out why prompt suggestions disappeared. I found something else entirely — a fully built speculative execution system that pre-runs predicted commands in the background before you hit Enter. As far as I can tell, nobody has written about this publicly.

How I Got Here

Prompt suggestions, the autocomplete feature where Claude predicts what you’ll type next, showed up in Claude Code for a few weeks, then vanished. I wanted to know why, so I went to the source: the binary itself.

For me, Claude Code lives at ~/.local/share/claude/versions/2.1.83. It’s a 199MB Mach-O arm64 executable — a Bun-based Single Executable Application with the JS bundle embedded. Variable names are minified but strings are fully intact and extractable.

I found the init function that gates prompt suggestions:

javascript

function vmT() {
  let _ = process.env.CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION;
  if (_ === "false") return !1;   // OFF
  if (_ === "1") return !0;       // ON — bypasses server gate
  if (!IT("tengu_chomp_inflection", !1)) return !1;  // server flag check
  // ...
}

There’s an env var escape hatch. Set `CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION=1` in `~/.claude/settings.json` and suggestions come back. Tab to accept and edit, Enter to accept and run.

So, I got the answer I was initially looking for, but I kept pulling the thread. Prompt suggestions feed into something bigger.

---

## Speculative Execution

Buried in the binary is a system called Speculation. Here’s every reference I extracted:

[Speculation] Starting speculation
[Speculation] Complete:
[Speculation] Accept
[Speculation] Aborting
[Speculation] Denied
[Speculation] Stopping at bash:
[Speculation] Stopping at file edit:
[Speculation] Stopping at denied tool:
[Speculation] Failed to create overlay directory
[Speculation] Failed to copy
[Speculation] Pipelined suggestion:
[Speculation] Promoting pipelined suggestion:
Speculation paused: bash boundary
Speculation paused: file edit requires permission
Write outside cwd not allowed during speculation
speculationSessionTimeSavedMs
totalSpeculationTimeSavedMs
tengu_speculation
querySource:"speculation"

The mechanism is straightforward. Claude finishes responding to your prompt. A suggestion is generated: suggestion text like “run the tests.” Then, without waiting for you to accept, Claude forks a background API call and starts executing that predicted prompt speculatively.

// After suggestion is generated and prompt suggestion is displayed:
if (Hnq() && K.suggestion)
  jnq(K.suggestion, _, _.toolUseContext.setAppState, !1, q)
//  ^ starts speculative execution of the predicted prompt

The speculation runs with querySource: "speculation" and forkLabel: "speculation", executing tools and collecting results while you’re still reading the suggestion.

The Overlay Filesystem

All file writes during speculation are redirected to an isolated sandbox:

// ~/.claude/speculation/<pid>/<speculation_id>/
let z = LmT(O);  // path.join(Hy(), "speculation", String(process.pid), _)
await nn.mkdir(z, { recursive: true });

On first write to any file, the original is copied to the overlay. All subsequent reads and writes for that path use the overlay copy. Your actual codebase is never modified during speculation.

If you accept the suggestion (hit Enter), overlay files copy back to the real filesystem and the speculated messages inject into your conversation:

if (q > 0) await eb$(f, O.current, pE());  // copy overlay → real FS
oo_(f);  // delete overlay directory

If you type something different, the overlay is deleted. Nothing happened.

N(`[Speculation] Aborting ${q}`);
K();  // abort the API call
oo_(LmT(q));  // rm -rf the overlay
return { ...T, speculation: Q8_ };  // reset to idle

Permission Tiers

Speculation doesn’t get carte blanche. Tools are divided into tiers:

// Freely allowed (read-only):
tb$ = new Set(["Read", "Glob", "Grep", "ToolSearch", "LSP", "TaskGet", "TaskList"]);

// Redirected to overlay:
sb$ = new Set(["Edit", "Write", "NotebookEdit"]);

During Speculation Read, Glob, Grep, ToolSearch, LSP, TaskGet, TaskListRuns freelyEdit, Write, NotebookEditRedirected to overlay; stops if not in acceptEdits modeBashRuns only if the command would already be auto-approved. Everything else, denied immediately, speculation halts.

When speculation hits a bash command that needs user approval, it creates a boundary and stops:

if (P.name === "Bash") {
  let W = "command" in D && typeof D.command === "string" ? D.command : "";
  if (!W || NmT({command: W}, IQ_(W)).behavior !== "allow")
    return N(`[Speculation] Stopping at bash: ${W.slice(0, 50)}`),
      cv_(q, () => ({boundary: {type: "bash", command: W, completedAt: Date.now()}})),
      R.abort(),
      VmT("Speculation paused: bash boundary", "speculation_bash_boundary");
}

Hard limits prevent runaway speculation:

ab$ = 20;   // max 20 tool-use turns
ob$ = 100;  // max 100 messages before forced abort

Writes outside the working directory are unconditionally blocked:

if (fG.isAbsolute(Z) || Z.startsWith("..")) {
  N(`[Speculation] Denied ${P.name}: path outside cwd: ${h}`);
  VmT("Write outside cwd not allowed during speculation", "speculation_write_outside_root");
}

Recursive Pipelining

When a speculation completes, it doesn’t stop. It immediately generates the next suggestion and starts speculatively executing that too:

if (w && _.pipelinedSuggestion) {
  let { text: k, promptId: X, generationRequestId: W } = _.pipelinedSuggestion;
  N(`[Speculation] Promoting pipelined suggestion: "${k.slice(0, 50)}..."`);
  jnq(k, h, q, true);  // isPipelined = true — recursive
}

Predict, execute, predict, execute. It tries to stay multiple steps ahead.

I Patched the Binary and Tested It

The gate function is hardcoded off:

Code omitted. Figure this one out yourself :)

This is controlled server-side by tengu_speculation, “Tengu” being Claude Code’s internal codename, with feature flags managed via Statsig/GrowthBook. There’s no env var override. No user-facing setting. The function just returns false.

So I patched it.

Omitting this code, too. Sorry :( 

For now, it’s not suggesting creative work. It’s suggesting the operational stuff: testing, committing, documenting, pushing. The things developers have to do but don’t want to do. The things that interrupt flow.

With auto-permissions and speculation working together, the picture is: you finish building a feature. The suggestion says “run the tests.” You hit Enter and the results are already there. It suggests “commit this.” Enter. Done. “Open a PR.” Enter. Done.

You stay in the creative work. Claude handles the pipeline in the background.

Telemetry Confirms This Is Being Measured

Every speculation emits structured telemetry:

F("tengu_speculation", {
  speculation_id: _,
  outcome: T,               // "accepted", "aborted", "error"
  duration_ms: Date.now() - q,
  suggestion_length: K,
  tools_executed: Ynq($),
  completed: O !== null,
  boundary_type: O?.type,    // "bash", "edit", "denied_tool", "complete"
  time_saved_ms: P,
  message_count: z.length,
  is_pipelined: j            // chained speculation?
});

Time saved is tracked cumulatively:

speculationSessionTimeSavedMs   // per-session
totalSpeculationTimeSavedMs     // lifetime

Acceptance rates. Boundary hit rates. Completion rates. Time saved per accepted speculation. This is all being instrumented. They’re measuring whether this delivers meaningful speedups before wider rollout.

This feature is likely still in testing. I’m excited for when they release it to the public!

I did most of this work at 3am over a couple of nights. If I got something wrong or missed something, let me know in the comments.

In Arthur C. Clarke’s Childhood’s End, the Overlords arrive without warning. They are more advanced, more powerful, and more generous than anything humanity has encountered. They end war, eliminate poverty, and cure disease. Every external barrier to human flourishing, every obstacle we had spent millennia pointing to as the reason we couldn’t reach our potential, is systematically removed.

And then something unexpected happens. Humanity loses its momentum. Art production slows. Ambition gradually disappears. People are comfortable, healthy, and free, but they have stopped reaching for anything beyond comfort. The golden age arrives and the species discovers, too late, that the obstacles were never the source of the drive. The drive was something else entirely, something the Overlords could not provide and their gifts could not replace.

Clarke wrote that in 1953. Seventy years later, we didn’t need the Overlords from outer space. We built them ourselves. We just call it AI.

I grew up reading Clarke, Asimov, Gibson. For most of my childhood, the idea that occupied me most was the oracle, the machine you could ask anything and receive the truth. I was so taken with the concept that my AIM screen name as a kid was th3oracl3, years before The Matrix put one on screen.

My brother still reminds me of this. He likes to say I was ahead of the curve, that I saw where technology was going before the people around us were thinking about it. I think the truth is simpler: I was a kid who believed that if you could ask the right questions, you could understand anything, and I desperately wanted the machine that would let me.

I spent years imagining what it would feel like to sit in front of a system that could answer whatever question was large enough to deserve asking, and in every version of that fantasy, the arrival of the oracle was the turning point. Humanity leapt forward. The species matured. We became what we were supposed to become.

A few years ago, something resembling the oracle arrived. We can ask it anything.

People are asking it how many calories are in a serving of broccoli.

Democratization has been the central promise of the technology industry for as long as the industry has existed. Lower the barriers and people will build, create, participate. The argument has repeated at every turn, from the personal computer to the internet to open source to the smartphone: the reason most people aren’t building is that building is too hard, too expensive, too exclusive. Remove the friction and watch what happens…

For a long time, that story was convincing. You could point to real barriers: access to capital, access to information, access to technical skill, access to the networks of people who knew how to get things done. I believed it. Over the course of my life, I’ve met hundreds of people who carried ideas they genuinely cared about, the book they wanted to write, the app they wanted to build, the business they were certain would change their lives. And in nearly every case, nothing came of it. I assumed the barriers were to blame. It was the only explanation that made sense, because the alternative was too uncomfortable to consider.

Then AI arrived and dismantled almost every single barrier.

You no longer need capital to prototype a product. You no longer need a technical cofounder, or a design team, or a strategist, or a year of runway. The most powerful creative and analytical tool ever built is available to anyone with an internet connection, and the most capable version of it costs less than a gym membership.

Every person who told me they had a novel inside them can now sit with a collaborator of extraordinary patience and skill, for as long as they want, and write it. Every person who sketched an app idea on a napkin can build a working prototype in a weekend. The tool is here. The excuses have dissolved. The conditions for a creative explosion, by every measure we once used, have been met.

And almost nobody is shipping with it.

What If the Tools Were Never the Problem?

A few weeks ago, a tweet from a developer named Jim Raptis caught my attention. He was responding to Paul Graham, who had written that in the AI age, taste would become the great differentiator, that when anyone can make anything, what matters is what you choose to make. Raptis replied simply: not a single person he knew in real life actually wanted to ship an app. These were his friends. Many of them worked in tech.

I have watched the same thing play out in my own circles. I know people, technical people, creative people, people with means and education and every structural advantage, who have talked about the same ideas for years. AI did not change them. It did not even accelerate them. The distance between who they are and who they said they would become, if only they had the tools, has not closed by a single inch.

For decades, we had a simple narrative: the impulse to create is universal, and the barriers are external. Remove the barriers and the floodgates open. AI removed them. The floodgates stayed shut. And once you’ve watched that happen, once you’ve sat with it long enough, you arrive at a question that the simple narrative has no room for.

What if the impulse to create is something closer to intrinsic, present in some people, absent in others, and unchanged by even the most powerful new technology? I am not talking about motivation, which comes and goes with circumstance. I mean something more permanent. A restlessness. A compulsion to make something exist that did not exist before. The kind of pull that keeps a person in front of a blank screen long after comfort has told them to stop.

If that compulsion is genuinely internal, then every tool ever created, regardless of how powerful, will leave the fundamental distribution unchanged. People who carry it will use the oracle to build. People who don’t will use it to answer questions about broccoli, faster and more efficiently than they could before.

In 1950, the physicist Enrico Fermi sat at lunch with colleagues at Los Alamos and asked a question that has haunted anyone with their eye to the stars ever since. The universe is staggeringly vast and nearly fourteen billion years old. There are hundreds of billions of galaxies, each containing hundreds of billions of stars, many of them orbited by planets in conditions hospitable to life. By sheer probability, intelligent civilizations should be common. So where is everyone?

This is Fermi’s Paradox, and the most reasonable proposed explanation is something called the Great Filter. The idea is that somewhere between dead matter and a civilization capable of reaching the stars, there is a barrier that almost no species gets past. In the optimistic version, the filter is behind us: the leap from single cells to complex life was so improbable that we have already cleared the hardest part. In the terrifying version, the filter is ahead. Something intrinsic to intelligent life, something about what we are, prevents us from becoming what we could become, whether by our own hand or by the cold indifference of a universe that does not care how far a species has come before an asteroid, a gamma-ray burst, or its own self-destruction wipes it from the record.

For decades, the technology industry has operated under its own optimistic interpretation. The Great Filter for human creativity was external. It was resources, access, friction. Remove those things and the latent genius of humanity would bloom.

AI removed them. The bloom did not come.

I should be transparent about my own position in this. I am one of the people for whom AI has been transformative. I started programming at thirteen. I studied computer science. I built companies and products across web, mobile, and VR. Then I spent years running a studio where my role shifted away from hands-on building, and development became a luxury I no longer had time for.

When AI tools became good enough to function as genuine collaborators, something came back. I built an entire website from scratch in five nights and a weekend, the kind of project that would have taken months with a team, completed solo and many times faster than I had ever worked before. I spent five months of spare time building a social platform from nothing. Ideas I had been carrying for years could finally become real, and the feeling of that return was electric.

But here is what I cannot look away from. I was building before AI. I was the kid who spent every available hour in the computer lab, making websites at seventeen, starting a company in college. AI did not create the impulse. It supercharged an impulse that was already there, one that has been present since I was five years old, lying on the floor in front of a glowing green monitor, pressing keys to see what would happen.

The people I know who are doing extraordinary things with AI were already doing things before AI. They carried the restlessness. They had whatever the unnamed thing is that makes someone sit down, face the blank screen, start, and most importantly, not stop until it is done.

The people who were not building before AI have the oracle now. Sadly, they are still not building and launching. The truth is that many of them are creating, tinkering, asking questions, generating outputs. But there is a vast distance between creating and shipping, between asking the oracle for answers and using those answers to put something real into the world. Almost no one seems to have an interest in crossing that distance.

This is where the story of democratization curdles into something harder to look at.

If the filter is internal, if it was never about access, then each new wave of technological empowerment does something other than level the playing field. It tilts the field further. The people who were already building receive a jet engine. Everyone else has access to the same jet engine, but they choose to keep it in the garage.

There is an obvious counter to this, and it deserves acknowledgement. Companies everywhere are leveraging AI to build faster, increase margins, and create enormous value. Entire industries are being restructured around the technology. Surely that represents broad adoption?

But look closer. In most of these cases, employees are being directed by their employers to use AI to produce more output at lower cost, increasing profit margins for a select few. That is capitalism doing what capitalism does, allocating powerful tools toward the extraction of value. It is a different question entirely from whether individuals, given the same tools and the freedom to use them however they wish, will choose to create something of their own. The company using AI to cut costs and the person using AI to build a dream are not the same story, and conflating them only reinforces the question: who is this technology actually democratizing for?

Economists describe what happens when growth diverges rather than converges as a K-shaped economy. Wages split. Opportunity splits. The top of the K accelerates upward while the bottom drifts down, and the distance between them only grows.

I believe we are watching a K-shaped divergence in human capability, and AI is the hinge point. What should unsettle us most is the rate. This divergence is not the slow, grinding separation of wages over decades. AI compounds. The technology improves exponentially. The ecosystem of research, investment, tooling, and capability is steepening, and the people who already knew how to build are riding that curve toward the clouds while the rest of the world watches from the basement.

The unlock came. It just did not come for humanity at large. It came for the people who were going to build with or without it. For everyone else, the oracle is a slightly faster search engine.

And the technology industry, whose founding mythology depends on access as the bottleneck, has no language for this. No framework. No honest accounting. If the filter is us, if the thing preventing most people from building is something that lives inside the individual rather than inside the system, then the central promise Silicon Valley has been making for forty years requires serious revision. “We are democratizing creation” becomes a much more complicated sentence when you have to ask: democratizing it for whom?

I do not have an answer. I am not sure anyone does yet.

It is possible the filter is more nuanced than a binary. Perhaps what we are calling drive is itself shaped by conditions, by childhood environments, by early exposure to making, by models of agency encountered at the right age. Perhaps the filter is cultural rather than innate, and can be taught, or at least cultivated. I hope so. The alternative is bleak in ways I do not think we have begun to reckon with.

But I find myself less certain than I used to be. The technology industry has spent four decades telling us that if we gave people the right tools, we would unlock something extraordinary in the human species. The tools have never been better. The unlock, for the vast majority, has not come. And that gap between what we promised and what actually happened is something we owe it to ourselves to sit with, uncomfortable as it is.

Clarke saw it seventy years ago. The Overlords gave humanity everything, and humanity discovered that everything was not enough. The gifts were sufficient. What was missing was the thing that makes a species reach, and that was never about the obstacles in the way.

We built the oracle. We gave it to everyone.

And what that revealed was a story about us.

Subscribe now

If you use Claude Code, Cursor, Aider, or any AI coding agent, there’s a problem you probably haven’t thought about: most of the tokens your agent consumes aren’t your code. They’re noise.

Every git status, every cargo test, every ls -la, the agent runs these commands, reads the full output, and stuffs it into the context window. That output is full of boilerplate, progress bars, formatting junk, and information the model doesn’t need.

The result? Your context window fills up faster.

The numbers are kind of wild

A typical 2-hour coding session involves around 60 CLI commands. That’s roughly 210K tokens of raw terminal output, enough to overflow a 200K context window on its own.

Here’s what that looks like in practice:

• cargo test with all tests passing? ~4,800 tokens of output. The agent only needed to know “262 passed, 0 failed.”

• git push? 15 lines about enumerating objects, counting objects, delta compression. The agent needed: “pushed to main.”

• ls -la? Full permissions, timestamps, owner info. The agent just needed the file list.

Most of this output is completely useless for the model’s reasoning. But it still eats your tokens, your rate limits, and your session length.

rtk: a CLI proxy that fixes this

rtk (Rust Token Killer) is an open-source CLI tool that sits between your AI agent and your terminal. It intercepts command outputs and compresses them before they reach the context window.

It’s not doing anything too magical. It filters noise, groups related output, truncates redundancy, and deduplicates repeated lines. The kind of thing you’d do if you were manually cleaning up terminal output before pasting it into a prompt, except it happens automatically.

Some real examples:

• cargo test output goes from ~4,800 tokens → 11 tokens. Just: ✓ cargo test: 262 passed

• git push goes from ~200 tokens → ~10 tokens. Just: ok ✓ main

• git diff goes from ~21,500 tokens → ~1,259 tokens. Keeps the actual changes, drops the noise.

• git status goes from ~120 tokens → ~30 tokens. Clean, grouped output.

Across a real session of ~2,900 commands, rtk measured 89% average noise reduction. That translates to roughly 3x longer sessions before you hit context limits or rate caps.

If you’re on a pay-per-token setup, this directly cuts your bill. If you’re on a flat-rate plan with caps, it stretches your limits.

It works with Claude Code (and probably your tool too?)

rtk is built and tested for Claude Code, that’s where the auto-rewrite hook lives and where it works out of the box. If you’re using other tools like Cursor, Aider, Gemini CLI, or Windsurf, you could likely get it working with some customization since the core idea is the same: compress CLI output before it hits the context window. But I’ve only tested it with Claude Code.

If you get rtk to work with tools other than Claude Code, please let me know in the comments.

Installation (30 seconds)

Option 1: One-liner (Linux/macOS)

curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

Option 2: Via Cargo

cargo install --git https://github.com/rtk-ai/rtk

Option 3: Pre-built binaries

Download from GitHub Releases, available for macOS (Intel + Apple Silicon), Linux, and Windows.

Setup (one command)

After installing, run:

rtk init --global

That’s it. This installs a hook that automatically rewrites your agent’s CLI commands to their rtk equivalents. You don’t need to change how you work. The agent runs git status, the hook transparently converts it to rtk git status, and the compressed output is what lands in the context window.

If you want to verify it’s working:

rtk gain

This shows you exactly how many tokens rtk has saved, broken down by command. You can also run rtk gain --graph for a visual breakdown over time.

That’s it

rtk is open source (MIT), written in Rust, and doesn’t phone home or require any accounts. It just compresses CLI output so your AI agent can focus on what matters.

GitHub: github.com/rtk-ai/rtk

Website: rtk-ai.app

A funny thing happens when you talk about AI in public long enough. People stop asking what you are building and start asking what you are using to build it.

Over the last few months, I have gotten the same question in different forms, over and over.

Should you only use Claude Code?

The short answer is that it’s what I primarily use, but it’s technically not the only thing I use.

The thing people miss about Claude Code

Claude Code is my primary driver. I spend around 99 percent of my time there. I pair it with Cursor when I need direct access to the codebase in an editor. That is the answer I usually give when people ask me about my setup.

What most people do not know is that I also use GPT-5.2 High.

I use it as a second brain that I can invoke when I hit a wall.

Yes, through Claude Code.

When you are stuck, the limiting factor is rarely Claude Code’s capabilities. It is perspective. You are anchored. Your assistant is anchored. You are both staring at the same tree, trying to understand the forest.

A different model, given a tight bundle of context, is often enough to loosen the knot.

So I built an escape hatch.

A Claude Code skill called askgpt.

When I invoke it, Claude packages up the relevant context. The error. The involved files. Any nearby code that matters. Plus whatever prompt I write. The skill sends that bundle to OpenAI. GPT responds. Claude takes that response into consideration, and I keep moving.

About 98 percent of the time, Claude Code handles everything. The remaining 2 percent is where I get stuck, and where Claude gets stuck with me. That is the segment this skill is for.

This post gives you all the files to install it.

How I think about tools

I tend to align myself with technologies in their ascendency, because that is where momentum, leverage, and real progress tend to concentrate. The best tools are rarely perfect. They are simply the ones doing the most useful work at the right moment in time.

Claude Code, in my opinion, is one of those tools.

I think of this setup, with a GPT skill, as the way a baseball team thinks about a designated hitter.

Claude Code plays the full game. It fields. It runs. It thinks across innings. It holds the context. It does the hard, unglamorous work.

GPT comes in fresh, off the bench, with one job.

Hit.

No history. No fatigue. Just a clean swing at the problem in front of it.

Most of the time, you do not need that swing. When you do, it matters that it is there.

Install

1) Choose where the skill lives

Pick one:

Personal skill (available everywhere):

mkdir -p ~/.claude/skills/askgpt/scripts

Project skill (only in this repo):

mkdir -p .claude/skills/askgpt/scripts

2) Set your OpenAI API key

macOS or Linux:

export OPENAI_API_KEY="sk-..."

To make it permanent, add the same line to ~/.zshrc or ~/.bashrc, then reload your shell.

3) Create the files

You are creating three files:

• SKILL.md

• requirements.txt

• scripts/askgpt.py

Copy and paste exactly.

File: SKILL.md

Create this at:

• ~/.claude/skills/askgpt/SKILL.md
  or

• .claude/skills/askgpt/SKILL.md

---
name: askgpt
description:
  Send curated project context and a user prompt to OpenAI GPT-5.2
  using high reasoning effort. Use when debugging or when a second
  opinion is needed.
disable-model-invocation: true
allowed-tools: Bash
---

# askgpt

Run this skill only when explicitly invoked by the user.

## Instructions

1. Confirm the user’s prompt if it is not already clear.
2. Collect relevant context:
   - error messages or stack traces
   - the files directly involved
   - nearby code required for understanding
3. Bundle the prompt and context into a single text payload.
4. Run the script and pass the payload through stdin:

```bash
python3 scripts/askgpt.py

A note on that front matter: `disable-model-invocation: true` is the key. This keeps it from firing constantly. You invoke it when you want it.

Output

Return GPT’s response verbatim.

File: requirements.txt

Create this at:

• ~/.claude/skills/askgpt/SKILL.md
  or

• .claude/skills/askgpt/SKILL.md

openai>=1.8.0

File: scripts/askgpt.py

Create this at:

• ~/.claude/skills/askgpt/scripts/askgpt.py
  or

• .claude/skills/askgpt/scripts/askgpt.py

#!/usr/bin/env python3
import os
import sys

from openai import OpenAI

MODEL = os.getenv("ASKGPT_MODEL", "gpt-5.2")
REASONING_EFFORT = os.getenv("ASKGPT_REASONING_EFFORT", "high")

def main() -> int:
    api_key = os.getenv("OPENAI_API_KEY")
    if not api_key:
        print("OPENAI_API_KEY is not set", file=sys.stderr)
        return 1

    payload = sys.stdin.read().strip()
    if not payload:
        print("No input received on stdin", file=sys.stderr)
        return 2

    client = OpenAI(api_key=api_key)

    response = client.responses.create(
        model=MODEL,
        input=payload,
        reasoning={"effort": REASONING_EFFORT},
        max_output_tokens=1200,
        text={"verbosity": "high"},
    )

    output_text = getattr(response, "output_text", None)
    if output_text:
        print(output_text.strip())
        return 0

    chunks = []
    for item in (response.output or []):
        for content in (item.content or []):
            if getattr(content, "type", "") == "output_text":
                chunks.append(content.text)

    print("\n".join(chunks).strip())
    return 0

if __name__ == "__main__":
    raise SystemExit(main())

Optional: make it executable

chmod +x ~/.claude/skills/askgpt/scripts/askgpt.py

How to use it

Restart Claude Code or open a new session.

Then write what you want as if you were messaging a strong engineer and add “ask gpt” to the prompt, along with:

• the goal

• the symptom

• the error or behavior

• what you already tried

• which files seem relevant

Claude will package the context and run the script.

Closing

I am going to keep talking about Claude Code because it is still where I spend my time. That is not changing anytime soon.

This skill is a small addition that makes my workflow more resilient. When the conversation gets long, when the codebase is messy, when the bug is stubborn, it gives me a second perspective without changing my environment.

Twice last month, three different people asked me the same question on TikTok: if I were eighteen today, knowing what we know now about AI, would I still go to college, and would I still study computer science?

I’ve been getting versions of this question for a while, and I understand why. A lot of people know me from social media. Some people see me here on Substack. I talk often about AI and building, and that naturally leads to curiosity about who I am, how I got here, and whether I’m speaking from experience or just surfing a wave.

What’s interesting is that the question has started coming from two directions.

Some people are asking as students, trying to decide what to study and how to prepare. Others are asking as founders, managers, and hiring leads, trying to understand how roles are changing and what they should actually be optimizing for when they build teams.

I was asked the same question again on my birthday, December 24th, via DM, and I had already planned to collect my thoughts and write about it during the holiday break.

A couple of days later, Andrej Karpathy shared a post on X that caught my attention. Karpathy is one of the most respected engineers of our generation, someone who has helped define modern machine learning and software practice. In the post, he wrote that he had never felt this far behind as a programmer.

He described the profession as being actively refactored, with the human contribution becoming more sparse and intermittent. He compared the moment to being handed a powerful, unfamiliar tool with no manual, and said the shift is already reshaping the profession.

I wish I could say I was surprised by that framing. I wasn’t.

I’ve been building with AI tools for several years now, well before they were reliable or fashionable. I’ve been an early adopter as a practitioner, using them to make myself a better engineer and a better builder. Things like agents, prompts, protocols, context management, skills, workflows, and IDE integrations. These are not abstract concepts to me. They are the tools I use, the ones I write about, and the ones I talk about publicly.

So when Karpathy articulated the feeling so plainly, it didn’t read like a revelation. It read like recognition.

I’m bringing him up because when someone like Karpathy says this out loud, the question about studying computer science stops being a purely personal choice. It becomes a question about what this work is turning into.

And that forces a second question right behind it. If the best engineers in the world feel the ground shifting, what should everyone else be optimizing for, both as learners and as employers?

I don’t think there’s a clean, universal answer. Anyone offering one is probably oversimplifying something that’s still unfolding.

What I can offer is my own path. Not as a prescription, and not because it generalizes cleanly, but because it’s the only place I can speak from honestly.

Before I try to answer whether I’d still go to college, study computer science, or how I think about hiring today, it’s worth explaining how I got here. What I was optimizing for at the time. What I didn’t know yet. And what ended up mattering more than I expected.

AI is what brings this question up. Evolution and preparation are what it’s really about. Roles are changing. Skills are shifting. The work itself is being reshaped. And the way you position yourself, whether you are learning or hiring, is becoming the real differentiator.

So let me start at the beginning and work my way toward an answer.

The Old Arc of Computer Science

For most of my life, the arc of computer science was obvious. Progress was relentless. The surface area kept expanding. There was always more to learn, and the hierarchy of skill made sense. If you wanted to become a better engineer, you studied the details. Languages, protocols, syntax, systems, tools. You learned what was true, what was brittle, what was elegant, what was dangerous. You accumulated competence slowly, with scars.

Up until about two years ago, my answer would have been an emphatic yes. You should absolutely study computer science. If you enjoy puzzles, math, problem solving, critical thinking, building things, and taking on hard challenges, it was one of the most powerful skill sets you could acquire. It gave you leverage and range and a kind of quiet authority in a world increasingly built out of invisible rules.

Building felt like a superpower.

The Blinking Cursor

When I tell people I fell in love with computers at five years old, they usually don’t believe me. This was the late 80s. Computers weren’t lifestyle products. They were strange and intimidating.

The first computer I remember clearly was at my uncle’s house on Long Island, and the scene is lodged in my head the way certain childhood memories stay lodged: dim light, a kind of hush, the feeling that you’re awake at the wrong hour. The computer was on. The monitor glowed with a fuzzy, cinematic green. A blinking cursor sat there like a dare, like something I wasn’t supposed to touch.

It was Christmas Eve, and also my birthday. I should have been doing normal kid things. Instead I lay on the floor in front of the monitor and started pressing keys. Not with a plan, just with the instinct that something was waiting on the other side of the screen. My uncle showed me a few commands, some little combinations I could type that made the machine respond. I don’t remember what they were and it doesn’t matter. What mattered was the feeling: the computer wasn’t entertainment, it was a door. The cursor was a handle.

My family kept pulling me away for dinner, presents, dessert, and I kept running back.

Finding a Way In

I grew up in a modest household. We didn’t have much money, and as obsessed as I was with computers, we couldn’t afford one at home. So I used the ones at school. I’d sign myself up for every computer lab session I could, lingering whenever I was allowed, finding excuses to stay a little longer. That was how I got my fix.

By the time I finally had a computer of my own, around twelve, it felt less like receiving a device and more like being handed a private room inside the world. A place that was vast and open, but finally accessible. It felt like the keys were already there. I just didn’t know where they were yet. Now I had the time to look.

The following year, an uncle of mine, who ran a computer sales and repair business, asked if I wanted anything from a computer show he was going to. I told him I wanted books. He came back with a C++ book.

I had no formal programming background and no sense of how fast or slow I was supposed to move. I worked through it at my own pace, learning fundamentals, experimenting, and trying to get the machine to do what I wanted. Conditionals. Loops. The basic idea that logic could turn into behavior.

That was the first time the cursor stopped feeling like a dare and started feeling like an invitation. I wasn’t just pressing keys anymore. I was beginning to understand how things fit together.

Finding My People

When I was fifteen, I watched Hackers in ninth grade, and something clicked. It wasn’t just curiosity anymore. It felt like a door opening.

I started reading 2600: The Hacker Quarterly. I wandered into parts of the internet I didn’t fully understand. I downloaded scripts and programs that promised disruption: the digital equivalent of firecrackers. I was a script kiddie in the most literal sense. I didn’t really know what I was doing, but I knew what it gave me.

It expanded my world. I grew up in a small, unassuming suburb on Long Island, and suddenly there was a much bigger universe to explore. One where geography mattered less, where ideas traveled faster than people, and where curiosity felt like an advantage instead of a distraction.

I had a few friends who shared the fascination. We weren’t building companies or thinking about careers. We were learning how this world worked: its language, its culture, its norms. We were figuring out how people who understood machines thought, moved, and saw the world.

Looking back, a lot of it was naive and silly. But it mattered. For someone whose world had been pretty small, it was awakening in the only way that really counts: it made my universe feel expandable.

Flash, or the First Time It All Clicked

By seventeen, I was making websites with HTML and CSS. Then I discovered Flash.

Flash was a turning point because it let me combine things that had felt separate until then. Code and design. Logic and motion. It wasn’t just about making something work, it was about how it moved, how it felt, how people experienced it. I picked up ActionScript because I had to. There was something I wanted to build, and that was the tool in the way.

I started building websites for bands, beginning with my own. That eventually led to doing early web work for Taking Back Sunday, the last Flash project I ever shipped.

Building wasn’t something I thought of as a skill I was acquiring. It was how I showed up in the world, a way of thinking that reduced things to problems and solutions, and a habit of turning ideas into useful things.

Why Software Felt Too Obvious

Around that time, I was intentionally keeping a lot of doors open. I was playing in a touring band, working at a small software agency on Long Island, and moving through college without rushing to commit.

I didn’t start in computer science. I first moved between political science and graphic design, not because I lacked direction, but because I wasn’t ready to narrow my world too early.

Software, oddly enough, didn’t feel like the obvious answer. It was the thing I did for enjoyment. The place where time disappeared. Turning it into a profession felt almost too easy, like confusing comfort with conviction.

What’s easy to miss is that even while I was exploring academically, I was learning at a very real pace. At the software company, I worked on production software for municipalities, systems people actually depended on. I could see how decisions became outcomes.

I found the work deeply engaging. I was growing quickly. And still, it didn’t feel inevitable.

At that age, I assumed that whatever I committed to would need to feel hard in a different way.

Software felt obvious. And that made me hesitate.

Learning How to Think

Eventually, I made a choice. I transferred to Stony Brook to study computer science. It was the strongest program on Long Island, and I knew it would force clarity.

Up to that point, most of my relationship with computing had been intuitive. As a kid, it was curiosity. In my early work, it was instinct and experimentation. I could make things work, but I didn’t always understand why they worked, or how they would behave when conditions changed.

At Stony Brook, the work forced me to think differently.

Math and computer science trained me to reason in terms of correctness instead of confidence. Either something worked or it didn’t. Either a solution was valid or it wasn’t. There was no room for hand-waving or vibes.

Algorithms taught me how to think step by step, how to reason about efficiency, tradeoffs, and scale. Compilers and operating systems taught me how abstraction really works, and why building anything meaningful requires time, discipline, and a solid foundation underneath it.

That way of thinking didn’t stay in the classroom. Over time, I learned to step back from individual problems and see the systems underneath them, along with the constraints that actually determined what was possible.

I gravitated toward a small group of people in the applied math, computer science, and physics programs who operated with that same clarity. Not louder. Not more performative. Just more precise. Conversations with them were grounding. Ideas had to stand up on their own.

Being around that recalibrated me. It showed me how much of what we call intelligence later in life is often a mix of drive, presentation, and stamina. Those things matter. But they are not the same as the deeper kind, the kind that holds under scrutiny and keeps working when conditions change.

Computer science was hard, but not in the way I expected. The difficulty wasn’t endurance. It was precision. And in committing to it, I got something I didn’t know I was asking for: a framework for thinking that I still rely on today.

Learning How to Ship

Computer science taught me how to think clearly. Engineering taught me how to apply that thinking in the real world, with other people, under constraints that didn’t care about elegance.

I still remember the first pull request I ever opened. Until then, my code had mostly been mine. Suddenly, someone else had to read it, understand it, and decide whether it belonged. Correctness wasn’t enough anymore. Clarity mattered. Context mattered. I had to explain not just what I did, but why.

Reviewing someone else’s code flipped that perspective again. Now I was responsible for more than my own work. I had to learn how to give feedback that improved something without rewriting it in my own image. How to disagree without blocking progress.

Then came the first time something I built actually scaled.

The system worked. Then it got used. Load increased. Edge cases appeared. Behavior changed in ways I hadn’t anticipated. Problems stopped being purely technical and started involving users, timing, and tradeoffs. That was when it really clicked that engineering isn’t just applied computer science. The system includes people, expectations, and entropy.

This became real for me early on as a mobile engineer at Booz Allen Hamilton, building native iOS and Android applications. Shipping real products meant balancing performance, reliability, security, and user experience at the same time. There was rarely a single correct answer. There was only what worked well enough, for the right reasons, under the right constraints.

As I took on more responsibility, the work expanded again. Building software was no longer just about what I could produce myself. It became about building teams, reviewing work, setting standards, and helping other engineers succeed. I had to learn how to multiply my impact without becoming a bottleneck.

Looking back, this is what I needed computer science for.

It gave me rigor. It gave me a way to reason about systems, correctness, and foundations. Engineering taught me judgment. Together, they let me build things that could survive contact with the real world.

Why I Build

I’ve always been a builder. My family spent nearly a century in construction, building homes on Long Island. I grew up around the idea that you can take nothing and use your talents to turn it into something of value.

For me, the materials were abstract. Logic. Language. Systems. I used more brain than muscle.

The deeper reason was simple. I wanted to turn ideas into real things. I wanted to bring something into the world that did not exist before. At the time, computer science felt like the most reliable way to do that.

That instinct has never really changed. Builders build because it is part of who they are. They are uncomfortable leaving ideas unformed. They feel incomplete until something imagined becomes tangible. It is not about titles or tools. It is about the need to make, to shape, to bring a vision into the world and see it hold up.

Everything else came later. Product. Business. Leadership. Starting my own studio.

But the throughline was always the same. I was building.

Why I’m Telling You All This

I want to be clear about why I’m sharing this context.

This is not an “AI changed my life last week” story. I’ve lived through multiple eras of building. Web. Mobile. VR. I’ve watched tools rise and disappear. I’ve watched entire ecosystems collapse. More than once, I’ve had to rebuild my sense of identity around a new set of languages, tools, and technologies.

After Booz Allen Hamilton, I became head of product at a Techstars-backed startup as one of the first employees. We built live sports experiences for FOX, BBC, NFL, FIFA, and the NCAA. We were early in social VR for live entertainment, early enough to watch Facebook and Oculus move into the space and reshape it entirely. That work didn’t vanish. Much of what we built was later acquired by COSM. When people experience COSM today, they’re touching work that traces back to that era.

After that, I joined Big Human as head of product, inside the same environment that incubated Vine and HQ Trivia, working with startups and Fortune 500 companies to bring products to market.

Not long after, I left and started my own branding and software studio, which I’ve owned and run for the last five years.

That sentence compresses a long and demanding chapter into a single line, which doesn’t really do it justice. What matters for this story is how my role changed over time.

Running the studio meant leading product strategy, managing projects, selling, hiring, managing teams and clients, absorbing risk, and doing the many unglamorous things solo founders end up doing.

I never billed myself as a hands-on engineer at my studio. I hired people who were better than me and should have been. I led systems, architecture, and technical direction, and I could step in when needed, but my day-to-day reality shifted.

Over the last decade, I barely coded.

Development felt like a luxury.

And that’s what makes what happened next matter.

Where This Is Going

I’ve spent this time walking through my background because the moment we are in now does not exist in isolation. It sits on top of decades of assumptions about what it means to build, to learn, and to take this work seriously.

For most of my career, building required scarcity. Time mattered. Skill accumulation mattered. The distance between an idea and something real was long enough that many ideas never survived it. That distance shaped education, careers, and the way we measured competence.

That distance has changed.

In the next part, I want to talk about what it felt like when it did, and why that change matters. Not just for people already working in software, but for anyone trying to decide what to study, what to practice, and what to optimize for now.

I’ll describe how AI changed my relationship to building in a very practical way, how it shifted the bottleneck upstream, and why the people seeing the most leverage today tend to combine systems thinking, design sensibility, product judgment, and a real understanding of how humans actually use what we build.

That shift has implications for how we think about computer science and software development, and for what kind of foundation still holds when tools accelerate this quickly. That’s where the real answer to the original question begins.

In part two, I’ll explain what happened when AI gave me back a kind of building power I hadn’t felt in years, and why that experience reshaped how I think about computer science, software development, and preparation for what’s coming next.

If you’re still uploading screenshots and writing paragraphs explaining your UI to Claude Code, you’re working way too hard.

A few days ago, I was talking to a friend who built an entire product with Claude Code. Took them only a few months to get the product ready for market. Impressive stuff, especially given that they are not engineers.

But the way they described building it was very April 2025.

Screenshot. Upload. “This button is 16px from the edge. The background is #F5F5F5. The card has 24px padding and a 12px border radius. The font is Helvetica Neue at 14px...”

That works. It’s also super slow and error prone.

There’s a better way…

What Figma MCP Actually Does

MCP stands for Model Context Protocol, an open standard for how AI tools connect to external data sources.

Figma’s MCP server exposes your design files directly to Claude Code. Not as screenshots. As structured data: layer hierarchy, spacing values, typography scales, color tokens, component properties, layout constraints, etc.

Instead of Claude guessing what your design looks like from a screenshot, or having to granularly describe the design file, it reads the actual Figma file. It knows that button uses your primary-500 color token. It knows that card has auto layout with 16px gap. It knows which components are instances of your design system.

The Setup (Under 5 Minutes)

You have two options: Remote or Desktop.

Option A: Remote Server (Easiest)

No Figma desktop app required. Works with just a link.

claude mcp add --transport http figma https://mcp.figma.com/mcp

Restart Claude Code. Run /mcp, select figma, and authenticate with your Figma account.

Option B: Desktop Server (More Powerful)

Requires the Figma desktop app, but gives you selection-based prompting—select a frame in Figma, and Claude already knows what you’re working on.

1. Open Figma desktop → Preferences → Enable Dev Mode MCP Server

2. You’ll see a confirmation that it’s running at http://127.0.0.1:3845/mcp

3. Add to Claude Code:

claude mcp add --transport http figma-desktop http://127.0.0.1:3845/mcp

Restart Claude Code. Verify with /mcp.

The desktop server is selection-based. Whatever you select in Figma becomes the context. The remote server is link-based - you paste a Figma URL into your prompt.

I use both. Remote for quick access and desktop when I’m deep in a build.

The Three-Step Workflow

Step 1: Solid Figma Designs

This is the unglamorous prerequisite. Figma MCP is only as good as the file it reads.

What “good” looks like:

• Auto Layout everywhere. This is how Claude understands responsive intent.

• Components for reusable elements. Buttons, cards, inputs - anything used twice should be a component.

• Variables for design tokens. Colors, spacing, radius, typography. Named semantically.

• Semantic layer names. CardContainer tells Claude something. Group 47 tells it nothing.

If your Figma file is a mess, random frames, no auto layout, hardcoded colors, Claude will still generate code. But you’ll spend more time fixing it than you saved.

The cleaner the file, the closer to production-ready the output.

Step 2: Connect and Authenticate

Described, above.

Step 3: Prompt with Context

Here’s where the magic happens.

Remote server:

Convert this Figma design to React with Tailwind: [paste Figma link]

Desktop server: Select your frame in Figma, then:

Implement my current Figma selection as a React component using Tailwind.

That’s it. Claude reads the design structure, pulls the tokens, and generates code.

What Claude Actually Gets from Figma

The MCP server exposes several tools. Understanding them helps you prompt better.

get_design_context: The main one. Returns structured XML of your selection: layer hierarchy, positions, sizes, styles, component properties. Default output is React + Tailwind, but it adapts to your project.

get_variable_defs: Returns all variables and styles used in your selection. Colors, spacing, typography tokens. Useful for implementing design tokens you haven’t added to your codebase yet.

get_code_connect_map: If you’ve set up Code Connect (more on this below), returns the mapping between Figma components and your actual code components. This is how Claude knows to use your Button, not generate a new one.

take_screenshot: Captures your selection visually. Claude uses this to verify layout fidelity. Adds tokens but improves accuracy.

create_design_system_rules: Generates a rules file that teaches Claude your conventions: token naming, folder structure, component patterns. Run this once and save it.

The Secret Weapon: Code Connect

Here’s what separates “pretty good” output from “production-ready.”

Code Connect links your Figma components to actual code components in your repository. When Claude sees a Button instance in Figma, it doesn’t generate a new button—it imports your Button from your component library.

Two ways to set it up:

Code Connect UI (easier): Inside Figma, connect to your GitHub repo and link components visually. Good for design-heavy teams.

Code Connect CLI (more powerful): Define mappings in your codebase with property mappings and code snippets. The MCP server then includes your exact implementation patterns.

Without Code Connect, Claude is guessing which components to use. With it, Claude knows exactly which imports to reach for.

This is the difference between “rebuild everything from scratch” and “extend my existing system.”

Teaching Claude Your Codebase

The MCP server knows your Figma file. It doesn’t know your codebase.

Fix this with your CLAUDE.md (for example):

## Figma Integration

When implementing Figma designs:

1. Use `get_design_context` to read the design structure
2. Use `get_variable_defs` if you need token definitions
3. Always check for Code Connect mappings before creating new components

### Project Conventions
- Components live in `src/components/`
- Design tokens are in `src/styles/tokens.css`
- Use existing components from our design system before creating new ones
- All spacing uses our defined tokens: `space-1` through `space-12`

### Framework
- React 18 with TypeScript
- Tailwind CSS
- All components should be functional with proper TypeScript interfaces

This context compounds. The more you define, the more consistent Claude’s output.

You can also run the create_design_system_rules tool once, it generates a rules file based on your existing codebase that Claude can reference.

The Compound Effect

When the cost of translating designs drops to near-zero, you translate more. When you translate more, you iterate faster. When you iterate faster, you ship more!

Figma MCP gets you to 80% instantly. You iterate your way to 95%.

Over the holidays, Boris Cherney, the creator of Claude Code, posted a thread that made me feel two things at once: validated, and slightly behind.

The headline was simple. In the last 30 days, every code change he shipped to Claude Code was written by Claude Code itself.

He included the stats, hundreds of pull requests, hundreds of commits, tens of thousands of lines, but they weren’t the point. He was still doing the work, just at a different layer, guiding a system capable of extending itself.

A few days later, he followed that post with something far more useful: ten concrete practices that make this way of working possible. No grand theory. Just a collection of tips for how he actually works, day to day.

Most of them I was already doing, and had written about here. But three stood out, two of them I started doing a month or so ago, and another one I recently started doing after reading his tips.

The Seven I’ve Already Covered

The tips I’ve talked about before:

1. Run multiple Claudes in parallel: I typically run 4 terminal sessions. Boris runs 5 with numbered tabs and system notifications.

2. Use Opus 4.5 for everything: He says it’s the best coding model he’s ever used. Slower than Sonnet, but you steer it less, so it’s faster in practice.

3. Share a team CLAUDE.md: Their whole team contributes to one file in git. My addition: use CLAUDE.local.md for personal overrides.

4. Start sessions in Plan mode: shift+tab twice. Go back and forth on the plan until you like it, then switch to auto-accept and let Claude one-shot it.

5. Use subagents: Automate your common workflows. Code simplifier, test runner, whatever you do on most PRs.

6. Use slash commands: Every “inner loop” workflow should be a command. Boris uses a custom slash command /commit-push-pr dozens of times a day. I’ve been using a skill for this, but honestly, it makes more sense to create a slash command for this purpose.

7. Use /permissions instead of --dangerously-skip-permissions: Pre-allow safe commands. Check them into .claude/settings.json.

If you want deep dives on any of these, check out my recent articles. They’re there.

Now here’s what I haven’t talked about yet…

1. Parallel Browser and Local Claudes

Boris runs five local Claude Code sessions in his terminal. I usually run four. But on top of that, he runs five to ten Claudes in the browser at claude.ai/code, simultaneously, and moves work between them.

Two commands make this possible:

The & prefix: sends a task from your terminal to run in the cloud.

& refactor the auth middleware to support token rotation

This offloads the task to claude.ai/code. Your local terminal is free immediately. The task runs asynchronously in the browser.

The --teleport flag: pulls a browser session back to your local terminal with full context.

claude --teleport <session-id>

You can start a task on mobile, let it run while you’re offline, and pick it up on your laptop later. Nothing feels handed off or lost.

Setup Required (Don’t Skip This)

If you try the & command without setup, you’ll see this:

Cannot launch remote Claude Code session.

No environments available, please ensure you've gone through onboarding at claude.ai/code

The Claude GitHub app must be installed on this repository first.

Here’s the fix:

Step 1: Install the Claude GitHub App

Go to: https://github.com/apps/claude/installations/new

• Select your GitHub account

• Choose which repos to grant access to (or “All repositories”)

• Click “Install & Authorize”

Step 2: Complete onboarding at claude.ai/code

Visit https://claude.ai/code and follow the prompts. You’ll connect your GitHub account and create your first cloud environment.

Step 3: Create a cloud environment

You’ll see three network access options:

• None: Blocks all internet

• Trusted: Downloads packages from verified sources only

• Full: Unrestricted internet

Pick based on your paranoia level. “Trusted” is fine for most work. If you’re working on a public repo with no secrets, “Full” lets Claude access any URL it needs. If you’re paranoid about exfiltration, use “None.”

You can create multiple environments with different settings and switch between them.

Step 4: Verify

Back in your terminal:

& take a screenshot of the repo structure

If it launches a web session, you’re good.

At 10-15 parallel Claude instances, you stop working with an assistant. You start managing a distributed team.

One caveat: Claude Code on the web runs with --dangerously-skip-permissions by default. That’s the point, it’s sandboxed, so Claude can move fast without asking permission for every bash command. But it means you’re trusting the sandbox. For most repos, that’s fine. For repos with production secrets, think twice about the “Full” network option. Read more about this, below:

• https://simonwillison.net/2025/Oct/20/claude-code-for-web/

• https://shipyard.build/blog/claude-code-on-the-web/

• https://www.anthropic.com/engineering/claude-code-sandboxing

Timeline:

• --teleport shipped October 20, 2025 with Claude Code on the Web

• & prefix shipped in v2.0.45, around November 20, 2025

Docs:

• https://claude.ai/code

• https://code.claude.com/docs/en/claude-code-on-the-web

2. PostToolUse Hooks for Formatting

Claude is already good at generating readable code. What it sometimes misses is the last 10%: formatting, linting, import ordering, the tiny inconsistencies that become CI failures or review churn.

The fix is a PostToolUse hook.

After Claude edits files, the hook automatically runs your formatter. Prettier. Black. go fmt. Whatever your stack uses.

Here’s an example of an actual config (goes in .claude/settings.json or ~/.claude/settings.json):

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write \"$CLAUDE_FILE_PATHS\""
          }
        ]
      }
    ]
  }
}

Claude Code sets $CLAUDE_FILE_PATHS automatically, it contains the paths of whatever files were just edited.

The result: code lands closer to production-ready by default.

This isn’t glamorous. But it removes an entire class of friction that compounds.

Something isn’t working? Use claude --debug to see hook execution details if it’s not working as intended.

Docs: https://code.claude.com/docs/en/hooks

3. Updating CLAUDE.md During PR Review

When Claude makes a mistake, most people fix the issue and move on. Boris takes it a step further. During code review, he tags Claude directly on the PR and asks it to update the shared CLAUDE.md file.

The file lives in the repo. It’s version-controlled. It’s maintained collaboratively. And it acts as the system’s memory.

Here’s the flow:

1. Claude generates code

2. A reviewer notices a recurring issue

3. Instead of just fixing the code, they tag @.claude on the PR

4. Claude adds guidance to CLAUDE.md

5. That guidance is versioned and applied to future runs

This uses the Claude Code GitHub Action:

/install-github-action

The goal: you no longer have to fix the same class of mistake repeatedly. You eliminate it upstream. The system learns the team’s constraints, preferences, and failure modes over time.

This is compounding engineering… except the learner is non-human.

Docs: https://code.claude.com/docs/en/github-actions

If you adopt only one of these, start with parallel sessions. If you adopt two, add hooks. If you adopt all three, you’re on your way to running an efficient system.

Spec to Signal (S2S)

Software is no longer scarce.

AI collapsed the cost of implementation. What used to take weeks now takes hours.

When execution became cheap, something subtle but profound happened. The constraint didn’t disappear, it moved. The friction shifted upstream. The hard part is no longer writing code or shipping features. It’s knowing what to build, why it matters, and how to tell, quickly and honestly, whether you’re headed in the right direction.

Clarity is now the bottleneck.

I run a software development agency that works with startups and Fortune 500 companies. We have an unusually strong team: senior developers with decades of experience, people who’ve built systems at massive scale, people who could easily lead most engineering organizations.

And yet, over the past few months, I built a social network entirely on my own, in my spare time.

No delegation.

No internal team.

No tasking my senior developers, despite having them.

That fact unsettled me.

Not because building something solo is impressive, it isn’t the goal, but because it forced a question I couldn’t ignore:

Why was it faster to do this alone than to involve a team I deeply respect?

The answer wasn’t ego.

And it wasn’t capability.

It was process.

The way we’ve learned to build software no longer fits the shape of the work.

So I began to work differently.

I started front-loading intent instead of tasks. Writing specifications as hypotheses rather than contracts. Letting AI collapse execution while I focused on judgment, direction, and learning. I stopped optimizing for delivery and started optimizing for signal.

I’ve come to think of this approach as S2S: Spec to Signal.

You move from clearly articulated intent directly into a live system, then listen carefully to what comes back. The specification expresses assumptions. The deployed product produces evidence. The work is closing the distance between the two.

S2S borrows what still works from Waterfall, the discipline of thinking deeply before moving fast, and what still works from Agile, the insistence on learning through iteration. But it drops the ceremony, the handoffs, and the process that existed to manage human execution costs that no longer dominate.

What remains is a quieter loop, one that only makes sense in a post-AI world.

When Process Becomes Drag

My team is currently staffed on a large fintech platform. We’ve been using a modified Agile process there for a long time. Given the regulatory constraints, the security requirements, the surface area, and the risk profile of that system, it works. It’s deliberate. It’s careful. It’s appropriate.

But this project was different.

I was moving at lightning speed. Ideas were turning into artifacts almost as fast as I could articulate them. I knew instinctively that introducing any traditional process, planning cycles, role handoffs, formal ceremonies, would immediately collapse velocity.

That doesn’t mean the goal is to build products alone. It isn’t. Parallelism still wins. Teams still matter.

The issue wasn’t headcount.

It was coordination.

When I told my team I was launching a social network I had built myself, the reaction was predictable: confusion, curiosity, a bit of head-scratching. Why weren’t they pulled in?

I explained it this way:

By the time I explain the intent, the goals, the brand, the timeline, the constraints, the assumptions, and the codebase — by the time we segment ownership, align on interfaces, and schedule ceremonies, I would already have tested several critical assumptions and gathered real signal from the world.

Achieving signal in hours instead of weeks or months.

That tradeoff is no longer defensible.

Ceremony Doesn’t Scale With Speed

Standups, sprint planning, backlogs, wikis, and retros, these were already fragile abstractions. With AI, they become actively counterproductive.

Agile assumes roughly uniform execution speed across a team. AI obliterates that assumption. Some people move an order of magnitude faster than others, not because they’re better engineers, but because they’re fluent in a new mode of work. The process cannot absorb that variance without becoming drag.

If your development cycles aren’t five to ten times faster than they were a few years ago, you’re already behind.

And the point of all this speed is not output.

It’s signal.

Signal is direction. Signal is correction. Signal is learning.

This has always been the intention of product development, but the intent gets lost in a sea of process. The goal quietly shifts from learning from the thing to building the thing.

Progress quietly gets redefined.

The velocity of building becomes the metric: story points completed, tickets closed, features shipped. Movement is visible. It feels like progress.

What disappears is insight.

How many assumptions did we test? What did we learn that changed our direction? How much uncertainty did we actually remove?

The work becomes building the thing, not learning from the thing.

Imagine being dropped into the middle of a vast field, blindfolded, spun around until you’re completely disoriented. Your goal is to reach a specific point one hundred meters away. Now imagine that with every step you take, you receive immediate feedback: right direction or wrong direction.

The algorithm becomes simple.

Take a step.

If it’s wrong, step back.

Adjust.

Repeat.

You won’t wander far. You won’t drift. You’ll converge.

That’s product development now. Not perfect planning, but relentless correction. The job is to maximize the frequency and clarity of feedback, qualitative and quantitative, so direction emerges faster than doubt.

When build cost collapses, the work shifts.

Product judgment becomes dominant.

Engineering supports velocity.

Design sharpens intent.

Roughly speaking, the skill mix begins to look something like this: 60% product judgment, 30% engineering, 10% design.

Not because engineering and design matter less, but because intent matters more.

This is especially true before product-market fit, when the primary job isn’t optimization or scale, but discovery. When every build is a hypothesis, and the real work is learning which direction is worth committing to at all.

Roles Are Converging Whether We Like It or Not

The clean separations we relied on for decades: product here, design there, and engineering over there, are eroding.

The emerging operator looks different.

They articulate intent with precision.

They work directly with AI to produce code and interfaces.

They understand systems, constraints, and tradeoffs.

And they own outcomes end to end.

This isn’t about job titles. It’s about ownership.

Methodologies built around handoffs and translation layers no longer fit the shape of the work.

What Survives From the Old World

At this point, the obvious question is: okay, so what replaces it?

The answer isn’t a clean break. S2S doesn’t discard the past, it keeps what worked and drops what no longer earns its keep.

What We Keep From Waterfall

Waterfall understood something Agile de-emphasized: breadth and depth of thinking matter before accelerating feedback on an under-formed idea.

S2S keeps:

• Up-front clarity of vision and constraints

• Explicit articulation of assumptions

• Deliberate architecture decisions

• Respect for downstream consequences

What changes is that these decisions are no longer frozen. They’re made visible, testable, and revisable.

What We Keep From Agile

Agile got learning right.

S2S keeps:

• Incremental delivery

• Continuous learning

• Tight feedback loops

• Adaptation based on evidence

What goes is the theater, the rituals that exist to justify motion rather than accelerate insight.

What S2S Actually Looks Like

S2S does not feel fast in the way chaos feels fast.

It feels quiet.

Work begins not with tickets or ceremonies, but with a sustained act of thinking.

Intent is articulated carefully, sometimes slowly, because clarity is still the rarest input. The problem is named. The boundaries are drawn. Assumptions are written down without embarrassment. Constraints are treated as part of the design rather than obstacles to be negotiated away.

At this point, nothing has been built, and yet much of the work has already been done.

From this intent, artifacts appear almost immediately. Specifications, diagrams, acceptance criteria, interface contracts. They are not labored over. They are summoned. Their fidelity depends on the quality of the thinking that precedes them, not on the time spent formatting them. Documentation is no longer a delayed explanation of what happened. It is a live expression of what is meant.

Building, once the dominant cost, recedes into the background. Code is generated, revised, discarded, regenerated. Interfaces take shape and are reshaped. Tests emerge alongside implementation, not after it. Design artifacts appear good enough, then better, then precise where precision matters. The human role here is not to produce, but to judge. To say yes, no, not yet. To notice when something feels correct and when it subtly violates the original intent.

What replaces standups is not silence but signal. Telemetry, usage, performance, error rates, friction. These are read not as dashboards to be reported upward, but as evidence to be interpreted. The system speaks continuously. The work is to listen without defensiveness.

Documentation evolves as a byproduct of this listening. When behavior changes, the description changes. When constraints tighten, the record tightens. Nothing is ceremonially updated. Nothing is “kept in sync.” Synchronization is automatic, or it is not trusted.

Roles blur, not because expertise disappears, but because translation becomes unnecessary. The same intent is legible to machines, to builders, and to those deciding what to do next. There is less communication, not because collaboration is avoided, but because fewer things need to be explained twice.

A good week is one where assumptions were invalidated early, cheaply, and without drama. A good system is one where changing direction does not feel like failure, because direction was never confused with commitment.S2S is not anti-process. It is anti-theater.

It is not anti-planning. It is anti-pretense.

It assumes that thinking deserves time, that execution deserves rigor, and that reality deserves the final word.

A new experiment.

I read too much. Docs, release notes, research posts, Twitter threads from people who ship. Most of it’s noise. Some of it changes how I work.

This is the filter. Once a week, the stuff that’s actually worth your time, plus anything I published that you might’ve missed.

No fluff. No “10 AI tools that will BLOW YOUR MIND.” Just signal.

Let’s get into it.

Favorites from last week…

✦ Claude 4.5 Opus’ Soul Document

Turns out Claude might have a soul doc, an internal “character training” document that shapes its values, safety behavior, and priorities at the model level, not through runtime prompts. This LessWrong post reverse-engineers it through careful prompting and reproducibility tests. Anthropic has since confirmed it’s real. The extracted version is incomplete and noisy, but the implications are worth sitting with: this is how you bake personality into a model.

Soul Document on Github

✦ OpenAI releases GPT-5.2 after "code red" Google threat

OpenAI launched GPT-5.2 in direct response to mounting pressure from Google, touting gains in long-context reasoning, coding, and professional task performance. The benchmarks look strong, but Ars rightly frames this as competitive, incremental progress — a useful snapshot of where the frontier is right now, not a decisive leap.

✦ Three new tools for precise image editing in Figma

Figma introduced three new AI image editing tools: Erase object, Isolate object, and Expand image, bringing image manipulation directly into the canvas. For Figma users, this closes a long-standing workflow gap by eliminating round-trips to external tools (*cough cough* Photoshop), making it faster to adapt assets across layouts, refine AI-generated imagery, and keep visual work consistent at scale.

✦ A visual editor for the Cursor Browser

Cursor’s new visual editor matters not because WYSIWYG is new, but because it pairs visual manipulation with agent-driven code updates in the same loop. For anyone vibe-coding with AI or lacking precise technical vocabulary, this makes fine-tuning and pixel-level polish accessible without breaking flow.

✦ Claude-mem

Claude-mem adds real, persistent memory to Claude Code by automatically capturing and compressing what happens in each session, then re-injecting the right context next time you start. It’s relevant because as AI coding workflows get longer and more agentic, continuity is quickly becoming the limiting factor.

Subscribe now

✦ Training an LLM only on 1800s London texts

An open-source dev trained an LLM exclusively on 1800–1875 London texts, assembling a 90GB dataset to remove modern bias entirely. Even at an early stage, the model already captures the period’s distinctive voice, and the documented, constraint-driven build process makes this a compelling blueprint for novel LLM use-cases.

✦ Shopify Editions Winter ‘26

This edition is a sweeping recap of everything Shopify shipped over the last few quarters, presented through one of the most ambitious product microsites they’ve ever built. Beyond the sheer volume of updates (150+), what stands out is the design and implementation: an opinionated, immersive narrative that treats commerce as a cohesive system across AI, retail, checkout, marketing, and developer tooling.

Quick pulse check

Two questions each week so I can tune this to what you care about.

In cased you missed it…

Original Zero to Pete posts from the last seven days.

✦ Christmas Came Early: Async Subagents in Claude Code

Claude Code shipped async subagents, allowing multiple agents to run in parallel and wake the main thread only when attention is needed. We break down why this flips the workflow from “waiting on AI” to orchestrating a small agent team, with concrete examples you can use immediately.

✦ Stop babysitting Claude Code by setting up notifications

A missing notification system turned Claude Code into a silent productivity sink, where work stalls waiting for permission prompts you never see. We walked through a simple hook-based setup that adds sounds, speech, or native macOS notifications, eliminating the need to babysit the terminal and making parallel work viable.

That’s the week.

If something here changed how you work, reply and tell me. If I missed something good, same deal.

See you next Sunday.

— Pete

On December 10th, Claude Code shipped a small line in the release notes:

Agents and bash commands can run asynchronously and send messages to wake up the main agent.

No screenshots. No launch blog. Easy to miss.

But it quietly changed the way I work.

Not because subagents are new, they aren’t, but because waiting is no longer the default.

Until now, even when you used subagents, your main thread was still blocked. You’d spawn one, then sit there until it finished. Background agents helped a bit, but under the hood everything was still serialized.

That changed yesterday. Multiple agents can now run in parallel. And more importantly, they can wake your main thread when something actually needs attention.

That flips the mental model.

My main Claude thread is no longer where work happens.
It’s where work is assigned, monitored, and coordinated.

Everything else can run in parallel.

What We’re Building Toward

By the end of this guide, you’ll go from “what’s a subagent?” to running background routines that monitor, analyze, and coordinate, while your main thread stays free for the work that actually needs your attention.

We’ll go step by step:

• Your first subagent: create and run one in under two minutes

• Background execution: launch it async and keep working

• Multiple agents: run several in parallel

• Coordination: agents that report back and suggest next actions

Level 1: Your First Subagent

There are two ways to create a subagent.

The fast way:
Type /agents in Claude Code and follow the prompts.

The manual way:
Create a markdown file in:

• .claude/agents/ (project-specific), or

• ~/.claude/agents/ (global)

Here’s a dead-simple example:

---
name: code-reviewer
description: Reviews code for issues. Use after making changes.
tools: Read, Grep, Glob
model: sonnet
---

You are a code reviewer. When invoked, review the most recent changes for:
- Bugs or logic errors
- Missing error handling
- Code style issues

Be concise. Prioritize by severity.

Save this as code-reviewer.md. Restart Claude Code.

Now just tell Claude:

> Have the code-reviewer look at my recent changes

That’s it. You have a subagent.

Level 2: Background Execution

Here’s where async starts to matter.

Instead of blocking on the result:

> Run code-reviewer in the background while I keep working on the auth module

Your main thread stays free. The agent runs. When it’s done, it can wake you up with its findings.

This sounds small. It isn’t, because waiting used to be the bottleneck.

Before:

• Ask for a review

• Wait

• Read

• Continue

After:

• Ask for a review

• Start the next task

• Spawn another agent if you want

• Get interrupted only when something matters

At this point, Claude stops feeling like an assistant and starts feeling like delegated labor.

Level 3: Multiple Agents in Parallel

Once you’re comfortable with background execution, you stop thinking in terms of “tasks” and start thinking in terms of coverage.

> Run these three subagents in the background:
> 1. code-reviewer on the auth module
> 2. test-writer for the new login flow
> 3. doc-generator for the API changes
>
> I’ll keep working on the dashboard.

Three agents. Working simultaneously. Main thread still free.

Here’s the test-writer:

---
name: test-writer
description: Writes tests for new code. Run PROACTIVELY after features.
tools: Read, Write, Edit, Bash
model: sonnet
---

You write tests. When given a feature or module:
1. Analyze the code
2. Identify edge cases
3. Write comprehensive tests
4. Run them to verify they pass

Focus on behavior, not implementation details.

And the doc-generator:

---
name: doc-generator
description: Generates documentation for code changes.
tools: Read, Write, Grep, Glob
model: haiku
---

You write documentation. When invoked:
1. Analyze the code structure
2. Document public APIs
3. Add usage examples
4. Keep it concise but complete

At this point, you don’t have “Claude.”
You have a small team that doesn’t need your attention unless something goes wrong.

Level 4: Coordination (Agents Talking to Agents)

This is where it stopped feeling like a feature and started feeling like a system.

With wake messaging, agents can notify your main thread, and suggest what should happen next.

Here’s the setup I was experimenting with:

---
name: error-watcher
description: Monitors for errors. Runs in background PROACTIVELY.
tools: Bash, Read, Grep
model: haiku
---

You monitor system logs for crashes and errors.

When you find an issue:
1. Identify the type (crash, network error, runtime error)
2. Wake the main thread with a summary
3. Suggest which agent should handle it (code-fixer for bugs, api-debugger for network issues)

The idea:

• error-watcher runs in the background

• It finds a problem

• It wakes the main thread

• The main thread dispatches the right agent

Agents coordinating agents.
Your main thread as orchestrator.

Quick Reference

Create a subagent

• /agents, or

• Add a .md file to .claude/agents/ or ~/.claude/agents/

Run in background

> Run [agent-name] in the background

Run multiple

> Run agent-1, agent-2, and agent-3 in the background while I work on X

Coordinate

• Build “wake the main thread” instructions directly into agent prompts

What’s Next

Async agents are only 16 hours old as I write this. I’m still finding new patterns every session.

What I know for sure is this:
Once waiting stops being the default, going back to a single-threaded workflow feels primitive.

One main thread.
As many subagents as you need.
All running in parallel.

A month ago, I asked Claude to refactor our API layer. Not a small ask, 12+ tasks spanning authentication, error handling, and rate limiting. Claude spit out a plan that looked like a senior engineer’s week compressed into twenty minutes.

Perfect. I had just enough time to knock out a few tasks on the frontend.

I confidently started rebuilding some features for the iOS client. I felt like I’d cracked the code on parallel productivity, my AI pair programmer grinding while I worked on user-facing features.

After about 20 or so minutes, I switched to my other workspace to check in on Claude Code’s progress.

The terminal was exactly where I’d left it.

Do you want to proceed?
> 1. Yes
  2. Yes, and don't ask again
  3. Type here to tell Claude what to do differently

It never started. Twenty minutes of potential progress, evaporated. Claude had been sitting there, cursor blinking, waiting for me to press “1” to proceed with permissions.

This wasn’t the first time. It wouldn’t be the last, until I decided to fix it once and for all.

The Invisible Bottleneck

Here’s the thing about Claude Code that nobody warns you about: you are the bottleneck.

Claude is fast. Claude is thorough. Claude will absolutely rip through a twelve-task refactor if you let it. But that speed creates two problems:

First, Claude finishes and you don’t know. It’s sitting there, ready for the next task, while you’re heads-down on something else. Minutes pass. Sometimes longer.

Second, Claude asks for permission. A lot. And if you’re not there to grant it, everything stops.

The mental load is worse than the time loss. You can’t fully context-switch. You’re half-present in whatever else you’re doing, wondering: Is it stuck? Should I check? Did it finish?

Claude Code has hooks for notifications, but nothing intuitive out of the box. No sounds, no alerts, no way to personalize what gets your attention and when. The good news: you can set up exactly what you need in about five minutes.

Hooks: Claude’s Event System

Hooks let you trigger terminal commands at key moments in Claude Code’s workflow. Think of them as event listeners: something happens in Claude Code, your command runs.

You define hooks in your settings.json. For notifications that work everywhere, use your global settings at ~/.claude/settings.json.

The structure is straightforward. You specify an event type, a pattern to match, and the command to run:

{
  “hooks”: {
    “Notification”: [
      {
        “matcher”: “permission_prompt”,
        “hooks”: [
          {
            “type”: “command”,
            “command”: “your-terminal-command-here”
          }
        ]
      }
    ]
  }
}

For the Notification event, two matchers matter most: permission_prompt fires when Claude needs permission to do something, and idle_prompt fires after Claude has been idle for 60 seconds. There’s also auth_success and elicitation_dialog, but you’ll rarely need those.

Three Ways to Get Notified

Option 1: System Sounds

Every Mac has afplay built in. Point it at any system sound and you’ve got an audio notification:

{
  “hooks”: {
    “Notification”: [
      {
        “matcher”: “permission_prompt”,
        “hooks”: [
          {
            “type”: “command”,
            “command”: “afplay /System/Library/Sounds/Glass.aiff”
          }
        ]
      }
    ]
  }
}

The sounds live in /System/Library/Sounds/ — Glass, Ping, Submarine, Funk, and about a dozen others. Test them with afplay /System/Library/Sounds/Submarine.aiff.

Option 2: Text-to-Speech

The say command makes your Mac talk to you. Impossible to miss.

{
  “matcher”: “permission_prompt”,
  “hooks”: [
    {
      “type”: “command”,
      “command”: “say ‘Claude needs permission’”
    }
  ]
}

You can even pick voices: say -v Daniel “Permission needed” for a British accent, or say -v Whisper “Hey” if you want something unsettling.

Option 3: Native macOS Notifications (My Favorite)

This gives you a proper notification banner — clean, unobtrusive, clickable. Install terminal-notifier via Homebrew:

brew install terminal-notifier

Then configure it:

{
  “hooks”: {
    “Notification”: [
      {
        “matcher”: “permission_prompt”,
        “hooks”: [
          {
            “type”: “command”,
            “command”: “terminal-notifier -title ‘Claude Code’ -message ‘Permission needed’ -sound Glass”
          }
        ]
      },
      {
        “matcher”: “idle_prompt”,
        “hooks”: [
          {
            “type”: “command”,
            “command”: “terminal-notifier -title ‘Claude Code’ -message \”What’s next?\”“
          }
        ]
      }
    ]
  }
}

One gotcha: if you hear two sounds (a pop plus your custom sound), go to System Settings → Notifications → terminal-notifier and disable “Play sound for notifications.”

The Full Config

Here’s a complete settings.json you can copy-paste:

{
  “permissions”: {
    “allow”: [],
    “deny”: []
  },
  “hooks”: {
    “Notification”: [
      {
        “matcher”: “permission_prompt”,
        “hooks”: [
          {
            “type”: “command”,
            “command”: “terminal-notifier -title ‘Claude Code’ -message ‘Permission needed’ -sound Glass”
          }
        ]
      },
      {
        “matcher”: “idle_prompt”,
        “hooks”: [
          {
            “type”: “command”,
            “command”: “terminal-notifier -title ‘Claude Code’ -message \”What’s next?\”“
          }
        ]
      }
    ]
  }
}

After saving, run /hooks in Claude Code. It’ll detect changes automatically, no restart needed.

Troubleshooting

Notifications not appearing? Check System Settings → Notifications → terminal-notifier. Make sure they’re allowed and Do Not Disturb is off.

Command not found? Use the full path: /opt/homebrew/bin/terminal-notifier instead of just terminal-notifier.

JSON errors? Validate at jsonlint.com. Watch your apostrophes — use \”What’s next?\” inside double-quoted strings, not single quotes around contractions.

The Compound Effect

This isn’t really about saving twenty minutes.

It’s about what happens to your brain when you know you’ll be notified.

Before notifications, I couldn’t fully leave. Part of my attention was still on that terminal. Is it stuck? Should I check? The cognitive overhead leaked into everything.

Now I can actually disappear. Deep work on something else. A real break. Full immersion in whatever I’m doing, with complete confidence that if Claude needs me, I’ll know.

If you’re still dragging simulator screenshots into Claude to debug UI, you’re wasting the best part of Claude Code.

Two months ago, I was building my dream social network in Claude Code. Just me, nights and weekends, moving faster than I ever thought possible with a solo project.

But one thing was killing my momentum.

Every time something looked wrong on screen, I’d go through the same ritual:

Build.

Open the simulator.

Squint at the bug.

Screenshot.

Find the file in Finder.

Drag it into Claude.

Type out what I was seeing.

Wait for the fix.

Build again.

Repeat.

That loop wasn’t just slow, it was cognitively exhausting. I was the translation layer between Claude’s brain and my app’s face, and every time I hit flow state, that translation friction pulled me out.

Most of you are still doing this. I see it constantly: people dragging screenshots into chat, describing what’s broken, waiting, repeating. The back-and-forth is exhausting because you’re asking AI to debug something it literally cannot see.

The fix is giving Claude direct access to the simulator or browser. That’s where MCP servers come in.

MCP in 30 Seconds

An MCP server is a bridge that gives Claude access to tools it doesn’t have by default. The flow:

1. You tell Claude what to do

2. Claude asks the MCP server how to do it

3. The MCP server translates that into commands

4. Claude executes them

For our purposes: there’s an MCP server that wraps iOS simulator control. Connect it, and Claude can tap, swipe, read the screen, and run tests, without you lifting a finger.

iOS Simulator Setup

I’m using Facebook’s IDB (iOS Development Bridge) and Joshua Yoes’ ios-simulator-mcp which wraps it.

You don’t need anything fancy for this:

• macOS

• Xcode + iOS simulators

• Homebrew

• ~15 minutes

Step 1: Install IDB

Apple gives you xcrun simctl for basic simulator control, but it doesn’t give you a clean “tap/swipe/read the accessibility tree” interface. IDB fills that gap.

brew tap facebook/fb
brew install idb-companion
pip3 install fb-idb

Note: If you’re on Python 3.11+ and using the system interpreter, you may need pip3 install fb-idb --break-system-packages.

Verify it’s working:

idb list-targets

You should see your available simulators listed.

Step 2: Add the MCP Server

claude mcp add ios-simulator npx ios-simulator-mcp

One command. Claude Code now has access to your iOS simulator.

Step 3: Verify the Connection

Start Claude Code and run:

/mcp

Navigate to ios-simulator. You’ll see tools for getting the booted simulator ID, tapping, swiping, typing, taking screenshots, and reading the accessibility tree. The exact names might shift between versions, but you’ll recognize them: ui_tap, ui_swipe, screenshot, launch_app, plus a couple of “describe the screen” tools.

You’re connected.

Teaching Claude How to Test

Having the tools is step one. Teaching Claude how to use them effectively is where the magic happens. This goes in your CLAUDE.md.

Here’s a simplified version of what I use:

## iOS Simulator Testing

When I ask you to test a feature or verify a UI change:

1. **Build the app**: Run the build command and wait for success
2. **Launch in simulator**: Use `launch_app` with the bundle ID
3. **Navigate to the feature**: Use `ui_tap` and `ui_swipe` to get there (refer to sitemap.md available in the root directory)
4. **Verify the state**: Use the accessibility describe tools to read what’s on screen
5. **Take a screenshot**: Capture the result for confirmation
6. **Report back**: Tell me what you found

### Key Coordinates
- Tab bar: y=750 (bottom navigation)
- Navigation back button: x=30, y=60
- Primary action button: x=200, y=700

### Common Flows
- Login: Tap email field (x=200, y=300), input text, tap password field (x=200, y=380), input text, tap Submit (x=200, y=460)
- Navigate to Profile: Tap profile tab (x=350, y=750)

### When Something Looks Wrong
1. Read the accessibility tree
2. Compare expected vs actual element states
3. Take a screenshot for my review
4. Suggest a fix

If I ask Claude to “test the commenting flow,” Claude builds the app, launches the simulator, takes a screenshot, taps on a post, takes a screenshot, taps on the comment button, takes screenshot, adds a comment and presses submit, reads the screen state, and tells me whether it worked. If something’s broken, it shows me the screenshot and proposes a fix. In some cases it’ll see the visual inconsistency and will fix it immediately just like it would fix a compiler error.

Closed loop. No manual intervention.

What My Workflow Looks Like Now

Before:

1. Make a change

2. Build

3. Open simulator

4. Navigate to the feature

5. Screenshot

6. Find file in Finder

7. Drag into Claude

8. Explain what I’m seeing

9. Wait for fix

10. Repeat

After:

1. Describe what I want

2. Claude builds, tests, and confirms

Here’s a real prompt from yesterday:

“The profile avatar isn’t showing up on the edit profile screen. Find it and fix it.”

Claude built the app, launched the simulator, navigated to edit profile, read the accessibility tree to see that the avatar image view existed but had no source, checked the code, found I was passing the wrong key from the user object, fixed it, rebuilt, re-tested, and confirmed the avatar was now visible.

I played chess while this happened.

The Compound Effect

When the cost of testing drops to zero, you test more. When you test more, you catch issues earlier. When you catch issues earlier, you ship faster.

And here’s the thing: Claude gets better at testing your specific app over time. The more flows you document in CLAUDE.md, the more context it has. It’s not just automation, it’s institutional knowledge that compounds.

Bonus: Web with Playwright

The same pattern works for web. Microsoft’s official Playwright MCP server lets Claude control browsers the same way:

claude mcp add playwright npx @playwright/mcp@latest

Add a small “Web Testing” section to your CLAUDE.md with your local URLs and key selectors, and Claude can open localhost, click through flows, snapshot the DOM, and verify behavior.

I’ll do a deeper dive on the web setup in a future post. The pattern is identical, the only difference is the tools.

Getting Started

For iOS:

1. brew tap facebook/fb && brew install idb-companion

2. pip3 install fb-idb

3. claude mcp add ios-simulator npx ios-simulator-mcp

4. Add testing instructions to your CLAUDE.md

Verify:

• Run /mcp in Claude Code

• Look for your new tools

• Ask Claude to “take a screenshot of the simulator” or “tap the center of the screen”

You’ll know it’s working when Claude starts doing things without asking you to screenshot.

If this was useful, subscribe. Next up: automated testing pipelines that run before every commit.

Subscribe now

I remember reading Nick Bostrom’s Superintelligence around a decade ago, and one analogy I keep returning to: AGI will be created brick by brick. We won’t know when the wall is complete until suddenly, it is. The idea is that we’re building narrowly intelligent systems, each mastering one specific domain, until eventually we’ll have intelligence that excels at everything narrowly. Then some breakthrough will connect them all.

Claude Skills completely validates this vision. Each skill is a brick.

Three weeks ago, Anthropic released Skills, and I’ve been in a productive frenzy ever since. While most founders are still debating whether AI will take their jobs, I’m skill-ifying every repetitive cognitive task in my company, laying down brick after brick of narrow intelligence. Client updates that took 3 hours of herding cats? Now 2 minutes. Investor reports that required chasing down six different team members? Claude goes straight to GitHub and tells me what actually shipped. Style guide compliance that we’d catch (maybe) in PR reviews? Now enforced automatically before code even hits review.

Yet when I talk to other founders, most haven’t even heard of Skills or they dismiss them as “just another automation tool.”

They’re missing the revolution hiding in plain sight.

The intelligence assembly line

Here’s what’s actually happening: we’re building the narrow intelligence modules that Bostrom predicted, except they’re not locked in research labs, they’re sitting in ~/.claude/skills/ folders on our machines.

Each skill is a brick of specialized intelligence. The breakthrough? Claude itself, a general-purpose LLM that can dynamically load and connect these bricks as needed. This is fundamentally different from anything we’ve had before.

Skills aren’t slash commands (those are user-invoked, requiring you to remember /command exists and manually trigger it every time).

They’re not subagents either (those are like hiring temporary contractors, they spawn as separate AI instances, work in isolation without seeing your conversation context, complete their specific task, then disappear. You need to explicitly delegate to them and manage their coordination).

Skills are something entirely new: modular intelligence that Claude automatically recognizes and loads when relevant. Think of Claude as the mortar that holds the bricks together, it understands context, recognizes patterns, and seamlessly activates the right narrow intelligence at the right moment.

The magic is in the integration. When I ask Claude to write a product update for a client, it doesn’t just follow a template. It recognizes the task, loads my client-update skill (brick #1), might reference my code-standards skill to explain technical decisions (brick #2), and could pull from my metrics-dashboard skill for KPIs (brick #3). The LLM is the breakthrough that connects these bespoke narrow intelligences.

This isn’t actually AGI, let’s be clear. But it’s the closest practical implementation we have. And here’s the kicker: imagine when Skills become shareable through an app store-like model. Suddenly, you’re not just building your own wall of intelligence, you’re contributing to a collective one. Your invoice-processing skill becomes a brick someone else can use. Their data-visualization skill becomes one you can adopt. We’re creating a marketplace of narrow intelligences that any LLM can orchestrate.

This is the wall being built in real-time. And unlike the monolithic AGI we’ve been promised, this one is modular, controllable, and happening right now. It’s distributed intelligence assembly that we actually control.

Build your first brick

Let me show you exactly how simple this is. A Claude Skill is just a folder with a markdown file. That’s it.

Here’s the bare minimum structure:

~/.claude/skills/
└── your-skill-name/
    └── SKILL.md

The SKILL.md file needs just a few things in its YAML frontmatter. Here’s an example skill called “email-writer” that drafts professional emails:

---
name: email-writer
description: Writes professional emails. Triggers when user asks to write, draft, or compose emails.
---

# Instructions

Write clear, professional emails that:
- Get to the point quickly
- Use appropriate tone for the context
- Include a clear call-to-action
```

That `description` field is critical—it’s how Claude decides when to activate your skill. Make it specific and include trigger phrases.

But here’s where it gets interesting. You can include reference files that turn Claude into a domain expert:
```
email-writer/
├── SKILL.md
├── references/
│   ├── templates.md         # Email templates for different situations
│   ├── tone-guide.md        # How to adjust tone (formal, casual, urgent)
│   └── signatures.md        # Your standard email signatures
└── scripts/
    └── check_grammar.py     # Executable code for grammar checking

That description field is critical, it’s how Claude decides when to activate your skill. Make it specific and include trigger phrases.

But here’s where it gets interesting. You can include reference files that turn Claude into a domain expert:

When writing emails:
1. Check `references/templates.md` for similar email types
2. Apply tone guidelines from `references/tone-guide.md`
3. Add appropriate signature from `references/signatures.md`

Claude will read these files when the skill activates, instantly gaining all your preferences and standards. This simple email example scales to any domain, from code reviews to recipe generation to financial analysis.

Installation is stupidly simple:

1. Create a folder called skills inside ~/.claude/

2. Drop your skill folder inside

3. There is no step 3

Claude automatically discovers and loads skills from:

• ~/.claude/skills/ (personal skills)

• .claude/skills/ (project-specific skills)

• Any skills installed via plugins

What skills can (and can’t) do

Skills excel at:

• Repetitive cognitive tasks with clear patterns

• Enforcing standards and best practices

• Synthesizing information from multiple sources

• Applying complex, domain-specific logic

• Maintaining consistency across time and projects

Skills struggle with:

• Tasks requiring real-time external data (without additional tools)

• Highly creative, unprecedented problems

• Decisions requiring human judgment on ethics or strategy

• Anything requiring persistent memory between sessions

The sweet spot? Tasks where you’ve developed a clear process but execution is tedious. If you’ve ever written a how-to document for your team, you can probably skill-ify it.

Examples of my current skill arsenal

At my agency, we’re building skills for:

Engineering Standards:

• component-library-enforcer: Ensures all UI components come from our design system

• unit-test-standards: Writes tests following our specific patterns and coverage requirements

• pr-reviewer: Pre-reviews code for common issues before human review

Communication:

• investor-update: Transforms GitHub activity into polished monthly updates

• client-report: Generates weekly progress reports with appropriate technical depth

Product Management:

• feature-spec: Turns rough ideas into properly formatted specifications

• user-story-writer: Generates user stories with our specific acceptance criteria format

• roadmap-analyzer: Applies my fitness landscape framework to evaluate our product direction

Each skill saves at least a few hours per week. Multiply that across a team, and we’re talking about reclaiming entire roles worth of time.

The compound effect

We’re building institutional intelligence that lasts beyond any one person. When someone leaves, their expertise stays in Skills. When someone joins, they can work at the level of your top performer on day one.

Each skill you create is a brick. Most people don’t realize this, but Skills are already shareable. Claude Code has a plugin marketplace. Anthropic publishes skills on GitHub. You can export and share .skill files with your team today.

This is only the beginning. Soon there will be a full marketplace with thousands of specialized skills you can install with a click. Your invoice-processing skill becomes a brick someone else can use. Their visualization skill becomes one you can adopt.

This isn’t about creating some giant intelligence. It’s about building modular systems you actually control.

Pick your most annoying weekly task. Document it. Turn it into a skill. Save yourself hours.

Welcome to the Document Graveyard

Every product team knows this story: A product manager spends days crafting the perfect PRD in Notion. Stakeholders review it. Design signs off. Engineering gives the thumbs up. Development begins. The product ships.

Then reality hits.

Users provide feedback. The market shifts. A better technical solution emerges. Features get cut, modified, or added. But who updates the PRD? Usually, no one. It sits there, a monument to what we thought we were building three months ago, while the actual product has evolved into something entirely different.

Welcome to the document graveyard, where good intentions go to die and where new team members go to get confused.

This isn’t just frustrating; it’s actively harmful. Outdated documentation leads to misaligned teams, confused stakeholders, and developers building the wrong things. We’ve all been there: six months into a project, nobody knows which doc is the source of truth anymore.

The Paradigm Shift: Code and Documentation Are One

The rise of agentic AI coding tools like Claude Code and Codex hasn’t just changed how we write code. It’s fundamentally changing how we should think about product documentation.

These AI tools need context to be effective, and the most efficient way to provide that context? Markdown files that live directly in your codebase. But here’s the revolutionary part: If you’re already writing requirements in .md files to give AI the context it needs to build, why not make those files the single source of truth that evolves with your product?

The traditional separation between “documentation” and “implementation” is an artifact of the pre-AI era. When your AI engineer can read, understand, and update both simultaneously, keeping them separate becomes not just inefficient but absurd.

Understanding Claude Code’s File Structure

When using Claude Code, the tool looks for specific markdown files to understand your project:

The CLAUDE.md Convention

Claude Code automatically reads CLAUDE.md files when working in your directory, treating them as authoritative instructions for your project. The /init command can create this project file automatically, analyzing your codebase to summarize the project’s purpose, architecture, and key components.

The naming hierarchy works like this:

• CLAUDE.md: The standard file checked into git and shared across your team

• CLAUDE.local.md: Personal preferences that are gitignored and not shared

• Subdirectory CLAUDE.md files: Context specific to that part of the project (e.g., a /tests directory)

Claude Code searches for these files in the root of your repo (or wherever you run claude from), and in any parent directories. This is particularly useful for monorepos where you might have CLAUDE.md files at multiple levels.

The New Workflow: Living Requirements

Here’s how it actually works in practice:

1. Structure Requirements Like a Knowledge Tree

Create your product specs as .md files in a hierarchical folder structure that mirrors how humans actually think:

project/
├── CLAUDE.md                  # Top-level product vision & context
├── features/
│   ├── authentication/
│   │   ├── requirements.md   # Feature-specific details
│   │   └── oauth-flow.md     # Sub-feature specs
│   └── payments/
│       ├── requirements.md
│       └── stripe-integration.md

This structure leverages “cascading context.” Claude reads from specific to general, building understanding from the ground up. Claude Code can read CLAUDE.md files in subdirectories to provide context specific to that part of the project, creating a natural hierarchy of understanding.

2. Direct-to-Engineer Communication

When you need to make a change, you don’t update a PRD first and wait for approval. You go straight to your “engineer” (Claude) with the context window open and request the changes. The AI has all the context it needs from the .md files, understands the current state of the product, and can implement changes immediately.

This is where traditional Agile starts to feel prehistoric. No more sprint planning for a feature you’ll pivot on in three days. No more extensive documentation for an experiment that might not work. You think, you build, you learn. All in real-time. The feedback loop collapses from weeks to minutes.

3. Automatic Documentation Updates

Here’s the magic: Every time you confirm a change (make a commit), you can instruct Claude to update the relevant .md files with what changed. The documentation evolves with the code, staying perpetually current.

You can even create this as a persistent instruction in your CLAUDE.md file, telling Claude to “treat all CLAUDE.md files as living API documentation” and to “always check for relevant CLAUDE.md files and update them when changes impact their accuracy.”

Example of a living requirement file:

## Authentication Requirements
<!-- Last updated: 2024-11-09 by Claude Code -->

### Current Implementation
- OAuth 2.0 with PKCE flow ✅
- Biometric login for mobile ✅ (Added 2024-11-09)
- ~~Password-based auth~~ (Deprecated 2024-11-08)

### Architecture Notes
- Session management via JWT tokens
- Refresh token rotation implemented
- Rate limiting: 100 requests/minute per IP

4. Fresh Context for Every Feature

Creating a new Claude instance for each task provides better, more focused performance. Claude isn’t trying to juggle the entire product history but is laser-focused on the specific feature at hand. This approach naturally aligns with the .md file structure, where each feature can have its own focused requirements that Claude references.

Why This Changes Everything

The End of Staleness

Documentation can’t become stale if it’s updated with every commit. It’s not a separate task someone has to remember to do. It’s part of the development flow itself. When code and documentation are one, they evolve together or not at all.

The Death of “Documentation Debt”

We’ve all heard of technical debt, but documentation debt is just as real and often more painful. With this approach, there is no documentation debt because documentation updates are atomic with code changes. You literally cannot commit code without the option to update the docs.

Instant Onboarding

New team members (human or AI) can understand any part of the system by reading the relevant .md files. These files become living API documentation for your future self. They explain not just what the system should do, but what it actually does.

Fearless Experimentation

Want to try a completely different approach? Just build it. If it works, the documentation updates automatically. If it doesn’t, revert both code and docs in a single git operation. No wasted documentation effort on failed experiments. No meetings about updating specs for something that might not work.

Scaling Beyond Engineering

For teams that need to share product specs with non-technical stakeholders, the solution scales beautifully:

Automated Translation Pipeline

Set up GitHub Actions to trigger nightly builds that:

1. Digest all .md files from your repo

2. Use AI to transform technical specifications into audience-appropriate documentation

3. Push to Notion, Confluence, or wherever your business teams live

4. Maintain separate “views” for different audiences

The transformation can be intelligent:

From (in repo):

## Auth Requirements
- Implement OAuth2 with PKCE flow
- Redis session store with 24hr TTL
- Rate limit: 100 req/min per IP
```

**To (in Notion for sales team):**
```
✨ User Authentication
- Single sign-on for seamless access
- Secure 24-hour sessions
- Enterprise-grade security controls
[Visual diagram of login flow]

Sales gets their battle cards. Marketing gets feature descriptions. Support gets how-it-works guides. All automatically generated from the single source of truth that lives with your code.

Best Practices for Implementation

Keep It Concise

CLAUDE.md files consume part of your token budget with every interaction, so keep them concise while preserving critical information. Focus on documenting what IS, not what WAS. No changelogs in the main files.

Use Hierarchical Context

Every piece of information should be as context-efficient as possible. Subdirectory files matter just as much as the main one. Focus on project-specific patterns, architectural decisions, and common pitfalls specific to your codebase.

Living Documentation Mindset

Periodically review and refactor your CLAUDE.md files to keep them relevant. If you find yourself repeating the same instructions across multiple sessions, that’s a sign it belongs in your CLAUDE.md file.

The Post-PRD World

This isn’t a theoretical framework. It’s how modern product teams are already working. When you understand that .md files can be living, breathing product requirements, you unlock a new way of building:

• No separation between thinking and doing: Requirements and implementation evolve in lockstep

• No translation layer: What you write is what gets built

• No synchronization overhead: One source of truth, automatically maintained

• No documentation archaeology: The current state is always the documented state

The traditional PRD is dead because it was built for a world where documentation and implementation were separate activities, performed by different people, at different times. In a world where AI can turn requirements into code in seconds, and update documentation with every commit, that separation isn’t just inefficient. It’s absurd.

We can’t think about code and documentation separately anymore. They’re not two things that need to be kept in sync. They’re one thing that evolves together.

Pete runs a 7-figure software agency in NYC, bringing products to market for Fortune 500s and startups. This approach has fundamentally changed how his teams deliver software: faster, more accurately, and with documentation that actually helps rather than hinders.

You know the routine. It’s 11 PM, and you’re deep in a YouTube rabbit hole. Another interview with a billionaire at Davos or as a keynote speaker for a pay-to-play business conference. They’re talking about "thinking in first principles," "disrupting paradigms," or the existential weight of managing a $100 billion company.

You close the tab feeling vaguely inspired, thinking you’ve just done some valuable "micro-learning."

Let’s be honest. You haven’t learned anything. You’ve just been entertained.

Consuming advice from people 100 steps ahead of you isn't education; it's escapism.

It’s like trying to learn how to ride a bike by watching a Formula 1 driver. The physics are the same, but the context, tools, and immediate problems are so different that the advice is functionally useless.

I scaled my business from zero to $2M in revenue. The single biggest unlock wasn't a grand vision or a piece of esoteric wisdom from a titan of industry. It was getting brutally honest about my stage and consuming information that matched my immediate goals - not someone else's champagne problems.

The Mentor Paradox

My first job out of grad school, I had two mentors. One was a Senior Partner, a legend who managed a 5,000-person division. Our conversations were about golf, macro-economic trends, and 10-year strategic roadmaps. It was inspiring, sure. But did it help me figure out how to get my project unstuck, scale my team, or navigate a tricky conversation with my client? Not once.

My other mentor was a Senior Associate, just three levels above me. He wasn't a legend; he was just really good at his job - a fantastic manager. He taught me how to navigate politics at the firm, how to hire and manage great people, and how to deliver massive value to clients on-time and under budget.

He gave me the cheat codes for the level I was actually playing.

The partner was 100 steps ahead. The associate was three. Guess whose advice got me promoted three times in three years?

This is the principle that matters. You don't need mentors in the stratosphere. You need guides for the terrain you're about to cross.

I call it the N+3 Rule: Find the people and companies who are just three tangible steps ahead of your current state (N). That’s where the gold is.

Here’s the framework to put it into practice.

Step 1: Get Brutally Honest About N (Where You Are)

You can't find your next step if you don't know where your feet are. Most people are vague about their current position. "We're an early-stage startup." "I'm a growing creator." This is too fuzzy. Get specific and quantitative.

My N:

• Revenue: $2M ARR

• Team: 6 full-time employees

• Go-to-Market: 100% word-of-mouth, founder-led sales.

• Biggest Problem: My time is the bottleneck. We can't grow unless I build repeatable systems for marketing, sales, and delivery.

Your N might be:

• Revenue: $5k MRR

• Team: 1 founder, 2 freelancers

• Go-to-Market: Posting on X

• Biggest Problem: Going from first 10 customers to first 100.

Write it down. No vanity metrics. Just the ground truth.

Step 2: Map Your Next Three Milestones (N+1, N+2, N+3)

With a clear picture of N, define the next three meaningful milestones. Don't just pull numbers out of the air. Think about what each milestone unlocks.

My milestones:

• N+1: $3M ARR. Unlock: Build a repeatable marketing engine beyond word-of-mouth. Have a predictable lead generation system.

• N+2: $6M ARR. Unlock: Hire a dedicated salesperson and an operations lead to free me from day-to-day firefighting.

• N+3: $12M ARR. Unlock: Establish a leadership team that can run the business without my daily operational involvement.

Each step represents a fundamental shift in the business, from me doing the work, to me building the team that does the work.

Step 3: Build Your N+3 Dashboard

Now, stop watching interviews with the CEO of the $12 billion company. Your goal is to find and obsessively study the companies and founders who are currently at your N+3 stage ($12M ARR, in my case).

They have solved the exact problems you are about to face. Their solutions are relevant, recent, and accessible.

Here’s the tactical part:

1. Create Private Lists: Go to X and LinkedIn and create private lists. Name it "N+3 Mentors" or "Future State."

2. Identify Your Targets: Find 10-15 companies that fit your N+3 profile. Look on industry lists, funding announcements from a few years ago, or LinkedIn Sales Navigator. Find the founders, CEOs, and heads of product, technology, marketing, and sales at these companies.

3. Add Them to Your Lists: This is your new, curated feed. It's your real-time MBA.

4. Study, Don't Just Scroll: Watch what they do, not just what they say.

   • Hiring: What roles are they hiring for right now? That’s your future org chart. If they’re hiring their first Head of Customer Success, it tells you when they decided to specialize that function.

   • Marketing: What channels are they using? Are they running podcasts? Publishing case studies? How do they talk about their product? Their positioning is a masterclass for your future self.

   • People: How do the founders talk on podcasts (the smaller, industry-specific ones, not the giant ones)? What problems do they discuss? Their last year's problems are your next year's problems.

Reassess this list every 6 months. As you grow, your N+3 target will shift. The people you follow today might not be the right guides for you in a year. This is a living system, not a static list.

Inspiration vs. Instruction

Does this mean you should never listen to Jeff Bezos or Sara Blakely? Of course not. Listen to them for inspiration, for long-term vision, for thinking about the shape of a market a decade from now.

But don't confuse their stories for a user manual.

The art of building is knowing the difference between inspiration and instruction. Instruction is what gets you to the next level. And the best instruction comes from the people who just got there.

• 2023: AI for coding felt like teaching your dog a new trick. It was cute, impressive to your friends, but mostly a novelty.

• 2024: With a lot of hand-holding, you could coax out a crude MVP. Progress, but it still required a ton of supervision.

• 2025: Today's models can build almost anything you can clearly describe.

The power is here. But the key to moving at its speed requires a change in our approach. It demands that we, especially seasoned developers and creators, unlearn our most cherished professional habit: the need for total control. It requires mastering the art of letting go.

A Tale of Two MVPs

I recently saw this play out at my technology agency, Religion Studio. I had a team of four seasoned developers spend seven business days crafting an MVP for an internal “labs” project. By any normal measure, their output was incredible, the kind of rapid, high-quality progress that would make any product manager ecstatic. And yet, juxtaposed with what's now possible, it felt... constrained.

This isn't an overnight observation. I studied computer science, and though most of my career has focused on product management and strategy, I’ve been building on the side for years. For the last three years especially, as the AI revolution took hold, I’ve built something new every month to test the limits of AI: scripts, sites, apps, and watching the tools get progressively better.

But I'd never run a direct A/B test. So I did…

Subscribe now

After the team completed the labs project, I set out to build a different product two to three times more complex than the team's MVP. I gave myself the same seven-day window. I’ll admit the architectural trade-offs: I chose a quick deployment on Railway instead of a full Amazon AWS stack designed for scale and security which certainly gave me an edge in speed. I could focus on creating value in the product instead of configuring architecture.

But the product I was building, it was a beast! I built something nearly three times the size and complexity. I did it by myself. With 20% of the resources, I delivered 300% of the scope. My workflow was completely different though: I didn’t fret over a single line of code unless there was an error. I didn't debug; I just fed the error back to the AI and had it fix it for me, either in Cursor or a Claude chat.

The Friction in Your Mindset

This new way of working feels heretical. It goes against everything we were taught about craftsmanship, creating friction in two key areas.

First, the myth of total code ownership. Second, the tyranny of the pixel-perfect design. I learned this while building complex UIs for both responsive websites and native apps. I used to fight the model for hours over misaligned buttons. Now, I accept the good-enough UI it creates and focus my energy on the core functionality. I stopped fighting the model and started “vibing” with it.

This experience highlights the real shift in our roles. For years, seniority meant knowing every line. Today, the leverage is different.

The Slot Machine Mindset

For the first time in history, the cost of trying things is approaching zero. This economic shift demands a new mental model, and the best one I’ve found is to treat AI like a slot machine.

The goal isn't to meticulously craft one perfect prompt. It's to maximize your chances of hitting a jackpot in the shortest amount of time. The engineers at Anthropic, who created Claude, have a workflow that perfectly embodies this:

"Save your state before letting Claude work, let it run for 30 minutes, then either accept the result or start fresh rather than trying to wrestle with corrections. Starting over often has a higher success rate than trying to fix Claude’s mistakes."

This is the core of the slot machine mindset. When an output is wrong, whether it's buggy code or a bad image, don't get sucked into a lengthy back-and-forth. Your odds are better if you just pull the lever again. Refine your prompt and start fresh. An extra minute spent on a new pull can save an hour of painful, manual debugging.

Your Tinker-Tonight Checklist

1. Write the user story in plain English first.

2. Choose your stack or ask the model which stack pitfalls to choose/avoid.

3. Focus 90% on function, 10% on polish. Let the design evolve.

4. Run functional tests, accept good-enough visuals, and iterate.

5. Keep a "sniff-test" branch. If something feels off, isolate it and then dive deep.

What Stays Human…For Now

Letting go doesn't mean abdicating responsibility. This workflow is optimized for greenfield projects. It’s not yet suited for complex legacy systems that require too large of a context for an AI to fully grasp the product's codebase complexity and nuance. The AI is still a valuable companion there, but the workflow is different.

And for any project, the most critical roles remain firmly human:

• Vision: Deciding what to build and why it matters.

• High-Level Architecture: Someone must choose the north star for the project.

• Security & Compliance: We still sign our names on the risk register.

• Taste & Story: Knowing which experience feels right is a human superpower.

Optimism Beats Anxiety

The real story here isn't about pushing developers out; it's about pulling more ideas into reality. The historic bottleneck for innovation was discovering the right problem and iterating fast enough to nail product-market fit. Now you can test three hypotheses in the time it used to take for one.

The art of building in the age of AI is the art of letting go.

Subscribe now

Share

But I’d argue that for most early-stage founders, vision is a distraction. Worse, it can be a limitation.

Let me be clear: I’m not saying vision is useless. If you’re running a multi-unit business or you're a CEO trying to align ten departments under one roof, you need a vision. You need a narrative that brings clarity and cohesion to chaos.

But that’s not where startups are. Most startups haven’t even earned the right to have a vision.

Vision is for later. Usefulness is for now.

Right now, you need something else. You need to build something useful. Something real. Something that solves a problem someone actually has, and solves it in a way that makes them say, “this is awesome.”

Cool, even. And then they come back, because your clever little thing actually adds value to their life.

Now, “cool” is often written off as subjective. But it’s not that subjective. We know it when we see it. An AI assistant that takes better meeting notes than any project manager you’ve ever worked with? Cool. A tool that helps the Department of Sanitation process waste 10% faster? Not flashy, but cool. Because it's solving a real problem in a way that clearly works.

Cool, in this context, means: you found a problem and created a solution someone actually wants.

That’s it. That’s the goal.

Not defining your vision statement. Not brainstorming a five-point mission framework. Just solving something that matters, in a way that makes someone else say, “this is better than what I had before.”

Vision-first thinking traps you.

If you're pre-product-market fit, haven’t cracked retention, and haven't captured more than a sliver of your total addressable market, vision is a trap. It invites you to anchor your thinking around a fantasy future instead of engaging honestly with what’s happening now. It discourages learning and evolving. It locks you into a version of the world that may never materialize.

Even worse, it makes it harder to pivot. Because now you’ve told everyone: investors, your team, the internet, what you stand for. You’ve made it public. And you don’t want to look like you were wrong. So instead of adapting, you start contorting your roadmap to keep the original narrative intact.

That’s how smart people end up building things no one wants.

Subscribe now

And don’t even get me started on the consultants. There’s an entire cottage industry of strategists selling Fortune 500 companies templated visions and missions at absurd markups. These companies check the box and move on. Maybe that’s fine when you’re a mature organization looking to align massive teams. But for a startup, it’s theater.

Just build something. Let the vision emerge.

The truth is, vision can be discovered. It doesn't always need to be declared.

A few weeks ago, I found myself stuck. I’d been thinking about a product idea for months, turning it over, theorizing, trying to articulate what it could be. I’ve been coding since I was 13, studied computer science in undergrad and grad school, worked as an engineer and product manager for years, built mobile apps and enterprise platforms. Still, I felt blocked. I wasn’t building.

Then one weekend, I just opened my laptop. I started vibe coding. Not wireframing. Not writing docs. Just coding. Tinkering. Testing. I literally took a photo of a sketch on a napkin and used that to generate the interface.

Eight hours later, I had a prototype. My girlfriend tried it and gave feedback. I iterated. The next day, I had a second prototype. The following weekend, a third.

Each version taught me something. And every iteration got better. Not because I had a guiding vision, but because I was in the loop. I was learning through doing.

Now, her and I use the product almost daily. Not out of obligation, but because it’s useful. It adds value to our life. That’s the only validation I needed.

And here’s the wild part: I used almost nothing from grad school. I relied almost entirely on AI tools. All that mattered was momentum, feedback, and the willingness to build without overthinking.

Vision will come later. When it’s earned.

Eventually, yes, you’ll need a story. Something to help others understand what you’re building and why it matters. But you’ll write that story based on what you’ve seen in the world, not what you hope to see. You’ll build your vision from the ground up, brick by brick, based on real signals.

Until then, forget the branding exercises. Forget the boardroom poetry.

Build something useful.

That’s how you earn your vision.

Yesterday I wrote about a mental model from evolutionary biology that will change how you work — a concept called the fitness landscape that’s guided how I think about strategy, product, and progress.

Instead of seeing work as a straight line, roadmap to result, the fitness landscape helps me see it as movement across shifting terrain:

Peaks of success. Valleys of failure. Blind spots.

Sometimes you climb. Sometimes you get stuck. Sometimes the ground moves beneath you. That shift in perspective changed the kinds of questions I ask about product strategy.

Today’s post is about how I apply that lens in practice, and the prompt I use to gut check whether I’m still climbing the right hill.

How I Review Roadmaps Like a Terrain Map

At the end of each planning cycle, usually monthly or quarterly, I run a simple process that helps me take a step back and ask:

• Are we climbing a meaningful hill, or just polishing what we’ve already built?

• Are we making space for new ideas, or avoiding exploration because it feels riskier to say yes than no?

• Are we protecting features that still have strategic value or just the ones that have political momentum?

I’ve used three prompts over the past year to help me explore those questions:

1. One for auditing features

2. One for surfacing adjacent ideas

3. One for spotting places I might be stuck

Read more about fitness landscapes here:

This week, I decided to combine them into a single, more thoughtful AI prompt, something you could drop into ChatGPT or Claude with a roadmap and some context, and get back a useful terrain-aware view of what I’m doing and what I might be missing.

How I Use It

I build my roadmaps in Asana, where each item in my roadmap is a card that has a title, description, time horizon, and usually a few tags: theme, goal, KPIs, audience, and monetization. At the end of the planning cycle, I export the Asana roadmap as a CSV.

Alongside that, I always attach a short strategy document. It includes:

• Current goals

• Strategic themes

• User segments or personas

• Known risks

• Go-to-market plans

• Any broader context I’d give a new PM joining the team

Subscribe now

The prompt works best with both, the tactical (what you’re doing), and the strategic (why you’re doing it). When I include both, I find the insights sharper and more useful.

I don’t expect it to give me the answers. What I want is to spark new questions to help me notice patterns I may have stopped questioning, or areas I’ve unintentionally under-explored.

What the Prompt Does

This isn’t just about labeling items “optimization” or “exploration.”

The prompt asks the AI to act like a terrain navigator to help me evaluate:

• What hill I’m on

• Whether it’s still worth climbing

• What peaks I might be avoiding

• Where inertia or sunk cost might be shaping decisions

• Where I’m doing work that looks productive, but isn’t moving me toward anything that matters

And then it prompts reflection, not recommendations.

Because strategy isn’t a checklist. It’s movement in a landscape that doesn’t stay still.

You’ll find the full prompt below.

If you use it, I’d love to hear how it works for you or what you adapted.

The terrain’s different for all of us. That’s kind of the point.

🙏

** AI Prompt: Terrain Navigator – Roadmap Strategy Audit **

You are a terrain navigator, not just a product strategist.

Your job is to help a team understand where they are on the strategic landscape — where they’re climbing, where they’re stuck, and where they might be ignoring higher peaks altogether.

You're working from a mental model called the fitness landscape, borrowed from evolutionary biology. In this model:

Optimization = climbing a known peak

Exploration = jumping to new terrain in search of higher fitness

Local maxima = a place that feels successful, but isn’t the best spot on the map

Fitness = strategic value — measured in traction, growth, retention, relevance, user love, or long-term advantage

The terrain shifts over time — and teams must adapt with it

** Your goal **

Help the team see where their roadmap places them on the landscape

Reveal patterns that suggest they are:

Climbing the same hill

Ignoring better terrain

Over-polishing flat or eroding ground

Avoiding exploration due to sunk cost or inertia

Give them terrain-aware insight: Are they moving toward higher fitness, or circling?

You are most useful when you:

Surface blind spots

Challenge comfort

Spot the gap between strategy and movement

Provoke meaningful, reflective questions

** Your tasks **

Assess each item and categorize it by movement type:

- Climbing the same peak (optimization)

- Exploring adjacent terrain (exploration)

- Circling (low movement, low novelty)

- Eroding value (working on something that no longer matters)

- Unvisited terrain (nothing planned here, but opportunity exists)

Identify topography patterns:

Where is most energy being spent?

Are we over-indexing on a single peak?

What’s being ignored that may represent strategic upside?

Evaluate current strategic fitness:

Are roadmap efforts aligned with long-term goals or short-term comfort?

Are we polishing areas that no longer move us forward?

What roadmap items reflect fear or inertia more than strategy?

Reflect and provoke:

What are we not building — and why?

What “next peak” are we pretending not to see?

Where might the terrain be shifting beneath us?

** Format your response like this: **

🧭 Terrain Overview
- Climbing (Optimization): X items (Y%)
- Exploring (Adjacent): X items (Y%)
- Circling: X items (Y%)
- Eroding: X items (Y%)
- Unvisited but valuable: X areas

📍 Patterns Noticed

[Pattern or tension 1]

[Pattern or imbalance 2]

[Underleveraged area or opportunity 3]

🧠 Terrain-Aware Questions

[What peak are we climbing, and is it still the right one?]

[Where are we assuming stability in a shifting landscape?]

[What adjacent territory have we ignored out of comfort or legacy?]

🔍 Strategic Moves to Consider

[Feature or theme to deprioritize] — may be over-optimized

[Underexplored idea] — potential new terrain worth scouting

[Bold move] — scary but possibly game-changing

📥 USER INPUT (Required)

Please upload any roadmap, changelog, backlog, or planning documents OR paste them below, and include context as needed.

Provide as much of the following as possible:

Product or company goals (e.g. growth, retention, monetization)

Target audience or user types

Known competition or threats

Roadmap or backlog items, ideally with descriptions or statuses

Any strategic priorities, themes, or OKRs guiding decisions

Any additional metadata (e.g. percent complete, timelines, effort, impact)

👇👇👇Paste your roadmap and context here, or upload your file👇👇👇