That is a much bigger claim than a design refresh.

What actually changed

The core change is simple.

Claude Code now supports parallel sessions as the center of the product. You can run multiple Claude tasks side by side, manage them from one sidebar, branch into side chat without polluting the main task, review large diffs, use an integrated terminal, make spot edits with an in-app file editor, preview apps and files, and move panes around like a control surface. The official framing from Anthropic is that agentic coding now involves “many things in flight” with the human in the orchestrator seat.

That sounds incremental until you think about what it changes downstream.

If a product assumes one thread, it optimizes for prompting. If a product assumes many threads, it optimizes for dispatch, review, and approval.

That is not a small product decision. That is a different model of work.

The most revealing detail

The most important thing about this redesign is not any single feature.

It is what sits at the center of the interface.

Anthropic did not make the editor more central. It made orchestration more central. Even though the product includes an in-app file editor for spot changes, the experience is not built around sitting in a code editor all day. The visual center of gravity is the task list, the diff, the preview, the terminal, and the review flow.

That matters because it tells you what Anthropic thinks comes next.

Not better autocomplete. Not a cleaner chat panel. Not an AI assistant sitting beside the IDE.

Their bet is that the interface for AI work should look more like a command center than a writing surface.

The second half of the launch is Routines

Anthropic also launched Routines on the same day.

Routines let Claude run work automatically in three ways:

• On a schedule

• Via API trigger

• From GitHub events: pushes, pull requests, issues, workflow runs

Anthropic’s own examples include backlog triage, docs drift checks, deploy verification, alert triage, and code review checklists — recurring jobs that no longer need someone to remember to start them.

That pushes the product one step further.

Claude stops being just a tool you open. It starts becoming a system that runs when you are not there.

The desktop redesign is the orchestration layer. Routines is the scheduling layer. Together they move Claude Code from “AI coding assistant” toward “always-on worker with human review.”

What Anthropic is actually betting on

This update is not really about new panes or nicer chrome.

It is about product philosophy.

Anthropic is betting that the IDE, at least in its old shape, is the wrong interface for the agent era.

Traditional developer tools assume one person moving through one thread of work at a time. Claude Code now assumes multiple tasks running in parallel, isolated from one another, with a human reviewing outputs and steering the system. That creates a clean split in the market:

Editor-first tools are still built around writing. Orchestration-first tools are built around managing agents.

That changes the competition. The question stops being only who has the best model, the best autocomplete, or the cleanest editor plugin.

It becomes: who lets one human manage the most work at once? Who isolates that work cleanly? Who makes review fast enough that parallelism is actually usable?

That is a different category fight.

The case against this thesis

This is where coverage of this launch can get too excited. There is a strong case against overstating what this means.

First, Claude Code is still a developer product. Most non-technical users are not going to wake up tomorrow and start living inside a multi-pane desktop app with git worktrees, diff viewers, and GitHub-triggered routines.

Second, parallelism sounds powerful until the bill shows up. The skeptical coverage on launch day was not subtle. Both The Register and The New Stack flagged the same concern: more parallel sessions mean more token usage, more cost, and potentially more waste if outputs still require heavy review.

Third, not all work should be parallelized. Some jobs are tightly coupled. Some require one careful thread, not five half-supervised ones.

Fourth, the “editor is dead” framing goes too far. Anthropic itself included an in-app file editor in the redesign. The editor is not gone. It is demoted.

So the sober version of the argument is better than the hype version. Claude Code has not proven that the IDE is finished. It has shown that the IDE is no longer the only center of gravity.

That is still a significant claim.

The real takeaway

This launch matters because it makes Anthropic’s worldview visible.

From one prompt, one output, one loop — to many tasks running in parallel, with a human reviewing and directing.

Claude Code is no longer trying to be only a better assistant for writing code. Anthropic is trying to turn it into a control layer for multiple agents. Maybe that becomes the dominant interface for AI work. Maybe it does not.

But April 14 was the clearest signal yet that one of the biggest labs in AI thinks the future looks less like a chat window and more like an orchestration surface.

The question is no longer which AI writes better code. It is which AI lets one person manage the most.

Reply and tell me, are you building with Claude Code, or are you still editor-first?

— Aj, @ thevibefounder

Subscribe now

They need better memory.

Not perfect memory. Useful memory. A system that helps them remember what they saved, what they learned, what they decided, what changed, and what still matters.

Right now, most of us live in the opposite world.

We save articles we never revisit. We bookmark threads we cannot find later. We keep notes in one app, screenshots in another, PDFs in a folder, voice notes somewhere else, and half-finished thoughts scattered across tabs, chats, documents, and desktops.

We are not short on information.

We are drowning in uncompiled information.

The villain is your notes app

Notion. Evernote. Apple Notes. Google Keep. Obsidian. Bear.

They all promise the same thing: organize your thinking.

They all deliver the same thing: storage.

You save something. Tag it. Maybe highlight it. Then mostly forget it exists.

That is not because you are disorganized. It is because every traditional knowledge tool still depends on a human doing the hardest part of the work: deciding what matters, summarizing it, connecting it to other things, revisiting it later, and turning it into something useful.

That is the maintenance burden nobody keeps up with.

Your notes app is a filing cabinet that never files itself.

And filing cabinets do not think.The idea that changed how people see this problem

Andrej Karpathy recently described a workflow that made this click for a lot of people. 14.2 million views. 85,000 bookmarks. Not because it was flashy — because it was obvious in the way the best ideas are.

He collects source material into a raw/ folder, then uses an LLM to incrementally compile it into an interlinked markdown wiki. The model maintains summaries, backlinks, and concept pages. The human curates sources, asks questions, and reads the result. At around 100 articles and 400,000 words, you can ask complex research questions and the model synthesizes answers from the interconnected wiki — no RAG pipeline, no vector database, no infrastructure. Just files.

The key insight is not that the system answers questions. It is that the wiki becomes a persistent, compounding artifact that gets richer over time instead of forcing the model to rediscover everything from scratch on every query.

Nick Spisak then did something equally important: he made the idea feel startable. His beginner flow — create a few folders, fill them with source material, write a schema file, tell the AI to compile — reduced activation energy to near zero. His expansion post hit 132,000 views, and the lead capture page for a downloadable “skill” that sets up the system proved the demand was real. People did not just want to admire the idea. They wanted the first 20 minutes solved.

But both versions are still starter systems.

They work beautifully for research. Papers do not change every hour. Articles stay fixed. A single person benefits from a growing map of the field.

Real life requires more than a librarian.

Not everything you save is the same kind of information

This is the part most people miss.

A wiki treats everything as knowledge. But most people do not just need help remembering what they read. They need help remembering what they decided, why they decided it, what is true right now, what changed since last week, what constraints matter, and what should happen next.

A wiki is good at knowledge. Life and work need memory, live state, decisions, behavior rules, and action.

That is why the next version of this category is not an AI wiki. It is an agent brain.

The difference is one layer of separation:

An AI wiki says: raw sources → compiled knowledge → better answers.

An agent brain says: sources + memory + live state + decisions + behavior rules → useful views, drafts, and actions.

Here is what each layer actually is — with a real example of what a file in that folder looks like.

Sources. Original materials. Articles, meeting notes, screenshots, PDFs, transcripts. These are evidence. They stay close to original. Example file: sources/karpathy-ai-wiki-tweet-march-2026.md — a saved copy of the original thread.

Memory. What seems worth keeping. Key facts, recurring themes, important people, summaries, relationships. This is the durable layer. Example file: memory/ai-knowledge-systems.md — a compiled summary of what you know about this space, updated as new sources come in.

State. What is true right now. Calendar, tasks, current projects, recent analytics, short-term priorities. This is the fresh layer. Example file: state/current-priorities.md — three bullet points about what matters this week.

Decisions. What was chosen and why. The question, the options, the choice, the rejected paths, the reasoning, the evidence, and the date. This is how you recover judgment later. Example file: decisions/2026-03-newsletter-platform.md — why you chose Substack over Beehiiv, with the tradeoffs you weighed.

Behavior rules. How the AI should behave. Tone, confidence, confidentiality, approval rules, style boundaries. This is how AI stops feeling generic. Example file: BRAIN.md — a root-level instruction file that tells the model what this system is for and how careful it should be.

Views. What the human actually wants to read. A one-page brief. A weekly plan. A comparison. A dashboard. These are generated from the layers above, not stored as permanent truth.

That separation is the whole idea.

A screenshot from last week is not the same kind of thing as a durable insight. A summary is not the same thing as the original source. A calendar snapshot is not the same thing as a decision record. A generated dashboard is not the same thing as a piece of evidence.

The better your system separates those layers, the more trustworthy it becomes.What my own system looks like

I have been running a version of this for my newsletter workflow.

My sources/ folder has saved Anthropic help docs, product announcements, and X threads I pull when researching a post. My memory/ folder has compiled notes on every AI product I have covered — what I said about it, and what changed since. My state/ folder tracks what I am working on this week, what posts are in progress, and what is queued. My decisions/ folder has notes like “why I chose to frame the Claude Code leak as an architecture story, not a security story” — short files that capture reasoning I would otherwise forget in a week.

The BRAIN.md file at the root tells the model: you are helping a solo founder write analysis for builders. Be direct, not tutorial-mode. Prioritize original framing over feature recaps. Flag when a claim needs a source. Never assume the reader is non-technical.

When I sit down to write, I do not start from zero. I ask the system: “What do I know about this topic? What have I already said about it? What has changed since the last time I covered it?” The answers come back grounded in my own files, not a generic model’s best guess.

That is not a second brain.

It is a first draft of useful institutional memory for a team of one.

How a normal person can start this week

The mistake would be dumping the full architecture on people all at once.

Here is the beginner version I would actually recommend.

Step 1: Pick one area, not your whole life.

Do not try to build a brain for everything. Choose one area where information is already piling up: a job search, health research, a move, learning a topic, content planning, one work project, college applications, a home purchase.

Step 2: Create five folders.

my-brain/
  sources/
  memory/
  state/
  decisions/
  views/

Simple enough for anyone to start, but already better than a single raw/ folder because it introduces the most important distinction early: not everything you save is the same kind of information.

Step 3: Add 10 to 20 real files.

Drop in things you already have. Articles, notes, screenshots, PDFs, meeting notes, transcripts, a rough task list, a current calendar summary, old plans. Do not over-organize by hand. That is the AI’s job.

Step 4: Create one instruction file.

At the root, add BRAIN.md. This is the file that turns a generic AI into your AI. Here is a starter template you can copy and edit:# BRAIN.md

## What This System Is For
A personal knowledge base about [YOUR TOPIC].
The goal is to help me remember what I’ve learned, what I’ve decided,
and what matters right now — not just store files.

## How the Folders Work
- sources/ contains original material. Never modify these files.
- memory/ contains durable knowledge the AI maintains. Summaries, key
  facts, recurring themes, important relationships.
- state/ contains what is true right now. Tasks, priorities, deadlines,
  current status. This changes frequently.
- decisions/ contains records of choices I made and why. Include the
  question, options considered, what I chose, what I rejected, and the
  reasoning.
- views/ contains generated outputs. Briefs, overviews, comparisons.
  These are presentation, not truth — regenerate them anytime.

## Rules for the AI
- Always cite which source a claim comes from
- Mark uncertain claims as uncertain
- Never modify files in sources/
- When information conflicts, flag it instead of picking a winner
- Keep memory/ entries concise — one file per concept or theme
- Mark anything in state/ with a “last updated” date
- Use plain language. No jargon unless the source material uses it.
- When I ask a question, check memory/ and state/ before sources/

## What Counts as a Good Output
- Short. One page or less unless I ask for more.
- Grounded. Every important claim should trace back to a source.
- Honest about gaps. Say “I don’t have information on this” when true.

Edit this to match your topic, your tone, and your standards. The more specific you are about how the AI should behave, the less generic the outputs become.

Step 5: Ask the AI to compile, not just answer.

Do not ask “What do these files say?” Ask “Turn these files into a system.”

A simple starting prompt:

Read everything in sources/.

Then:
1. Summarize each important source
2. Extract recurring ideas
3. Put durable takeaways in memory/
4. Put time-sensitive information in state/
5. Create decision notes in decisions/ when the files show a real choice was made
6. Create a readable overview in views/ explaining what matters most right now
7. Include confidence and source references for important claims

That one instruction already moves the system beyond a generic chatbot.

Step 6: Review before promoting.

Do not let every AI output become permanent memory. Check it. Correct mistakes. Delete fluff. Rewrite vague points. Keep uncertain claims out of durable memory.

Run periodic health checks. Here is a prompt you can use:

Review the full knowledge base. Check for:
1. Claims in memory/ that have no source in sources/
2. Contradictions between memory/ files
3. Anything in state/ that looks stale or outdated
4. Decision records in decisions/ that are missing reasoning or date
5. Wiki-style summaries that have drifted from the original source
6. Gaps — important topics mentioned repeatedly but never summarized

Report what you find. Do not auto-fix. Let me decide.

Karpathy’s own pattern includes linting and health checks for contradictions, stale claims, and unsupported ideas. That is not a side detail. It is one of the most important product truths in this space: filed-back errors compound.

Step 7: Use recurring questions.

Once the first version exists, come back to it regularly. Here are prompts worth reusing:

What changed this week?
What decisions have already been made?
What is still uncertain or unresolved?
What themes keep repeating across these files?
What should I focus on next based on current state?
What in state/ is stale and needs updating?
What deserves a one-page brief right now?

This is when the system starts feeling alive. You are not just querying files. You are querying a compiled version of your own thinking.

Step 8: Add more layers only when needed.

Only after the simple version proves useful should you expand. Here is what a more mature system looks like:

my-brain/
  sources/          ← original materials, never modified
  memory/           ← durable knowledge, AI-maintained
  state/            ← what is true right now
  decisions/        ← choices made and why
  views/            ← generated outputs and briefs
  guides/           ← trusted reference material you want the AI to follow
  protocols/        ← behavior rules, tone, boundaries
  tools/            ← approved capabilities and integrations
  logs/             ← action history and change tracking
  BRAIN.md          ← the operating manual

That is the graduation path, not the starting point.

Why local-first matters

The winning version of this category should be local-first.

Not because it sounds sophisticated. Because people trust what they can inspect.

One reason Karpathy’s setup is compelling is that it is built on plain files and markdown. The wiki is readable by humans. The sources are visible. The structure can be versioned. The whole thing can live in a normal folder. That is a huge contrast to black-box systems where nobody can tell what the assistant knows, where it got the answer, or how the answer changed over time.

If AI is going to help with memory, decisions, and action, the underlying system has to stay legible. Files should remain inspectable. Raw sources should stay preserved. Generated summaries should be distinguishable from evidence. Live state should be marked as fresh or stale. Actions should be logged.

Local-first is not a technical preference. It is a product design decision about trust.

The next wave of AI is not more content. It is more continuity.

The best AI systems will not just answer one question at a time. They will accumulate context. Preserve reasoning. Track what changed. Distinguish between evidence and summary. Help people recover decisions. Produce useful views. And eventually take limited, permissioned action.

Karpathy proved the pattern. Nick proved people wanted the shortcut. The next step is to turn it into a real category.

Not just an AI wiki. Not just a second brain.

A local-first agent brain that turns scattered files, decisions, and live context into usable memory.

Once you see it, it becomes very hard to settle for a chatbot that forgets everything the moment the tab closes.

— Aj, @thevibefounder

A way to organize tasks. A cleaner sidebar. A little more structure.

That’s not what this is.

Anthropic just gave Claude Cowork something it was missing: persistent state.

Not just memory in the abstract. Not just another place to save files. A durable workspace where related work can accumulate context, instructions, scheduled tasks, and memory over time.

That matters more than it sounds.

Because the real problem with most AI workflows is not capability.

It’s reset.

You ask for help. You get output. You move on. Then you come back later and have to rebuild the whole frame again. What are we doing? What files matter? What rules should Claude follow? What happened last time?

That constant reconstitution is where a lot of useful AI work quietly dies.

Projects don’t make Claude smarter.

They make your work less disposable.

What Actually Shipped

Projects in Cowork let you group related tasks into separate workspaces that carry their own instructions, context, scheduled tasks, and project-scoped memory.

You create a project in one of three ways: start from scratch, import from an existing Claude chat project, or point it at a folder already on your machine. You give it a name, add instructions for how Claude should work inside that project, drop in files, and turn on memory.

That is the whole setup. Takes about sixty seconds.

The deeper change: Claude now has somewhere to stay oriented.

Why This Matters More Than Another “Organization” Feature

People underestimate how much work depends on continuity.

Not raw intelligence. Not beautiful output. Continuity.

The weekly competitor brief is not hard. The ongoing product cleanup pass is not hard. The recurring research project is not hard.

What’s hard is keeping all the context stable enough that the work improves instead of restarting every time.

That’s why most AI workflows feel impressive once and annoying after that. The first run is useful. The second run requires setup. The third run drifts. By the fourth run, you’re managing the tool instead of the work.

Projects are Anthropic’s answer to that specific problem. Instead of asking Claude to “remember” in a loose conversational sense, you give it a bounded operating environment: these files, these rules, this context, this memory, this recurring work.

That’s not chat. That’s closer to a standing desk, inbox, and playbook for a specific role.

The Real Upgrade Is Not Storage. It’s Memory With Boundaries.

This is the detail that matters.

Anthropic didn’t just add a place to dump files. They added project-scoped memory.

Claude remembers context from tasks you’ve run in a project and applies that context to future tasks in the same project — while keeping that memory completely separate from other projects.

That scoping is the real design decision. AI systems get less useful when memory becomes mush. If everything bleeds into everything else, you don’t get continuity. You get contamination.

I noticed this immediately. My Content Creation project knows my brand voice, my formatting rules, my writing examples. My YouTube Only project knows my video structure, my upload cadence, my thumbnail preferences. Those two worlds don’t touch each other. The newsletter research doesn’t drift into my YouTube titles. The YouTube context doesn’t pollute my Substack drafts.

Scoped memory means you can let Claude build up familiarity with a lane of work without dragging every other lane into it. That’s a better architecture for actual work — because most useful work is role-based.

What I Actually Set Up

I have two projects running right now.

Content Creation is where all my Substack and Instagram work lives. I pointed it at my content folder, gave it my writing skill file, my brand guidelines, and instructions on how I want output formatted. Every time I run a task inside that project — find a social media post, create an X on Insta graphic, draft a newsletter section — Claude already knows what “good” looks like because it learned from the last ten runs.

The first week I used this, I asked Claude to find a tweet and reframe it for Instagram. It read my brand file, applied my voice rules, and output a design that matched my style without me explaining any of it. That used to take two paragraphs of setup every single time. Now it takes one line.

YouTube Only is scoped to video work. Script outlines, thumbnail concepts, topic research — all isolated from everything else. When I’m in that project, Claude thinks like a video producer. When I’m in Content Creation, it thinks like a newsletter writer. Same AI, different operating context.

Neither of those setups is complicated. They’re boring. That’s the point. They get better when context accumulates — and that’s exactly the test for whether something belongs in a Cowork project or not.

Will this work improve if context carries forward?

If yes, make it a project.

If no, a one-off Cowork task is probably enough.

That’s the decision boundary.

What This Signals

This is not just Anthropic adding parity with “projects” as a category.

Claude already has chat Projects on the main product — available broadly, including to free users. Those are built around chat histories and knowledge bases.

Cowork Projects are different: local, task-centered, desktop-only workspaces designed for execution runs, not general chat organization.

That distinction matters.

Chat Projects are for organizing knowledge. Cowork Projects are for organizing execution.

That is a very different product move.

Zoom out, and you see a clear sequence. First Cowork got execution. Then it got scheduled tasks. Now it gets persistent project structure with memory.

Not better answers — better delegation, better rhythm, better compounding.

It suggests Anthropic sees Cowork becoming less like “Claude, but with tools” and more like a local operating layer for recurring work. I can feel that shift in how I use it.

The Limitations Matter Too

This is still early.

Projects require the latest Claude Desktop, are only available inside Cowork, and Cowork itself is still a research preview for paid plans on macOS and Windows. No cloud sync means this is not yet a cross-device system. No project sharing means it’s not yet a team collaboration layer.

This is not finished infrastructure. It’s local infrastructure. The one I feel most is no cloud sync — I work across two machines and right now these projects live on one of them.

But for solo founders, operators, and small teams — local plus persistent is already a massive upgrade over “start over every time.”

What This Changes for You

The biggest thing AI has changed for solo founders is not speed. It’s scope.

You can now operate with more continuity than your head alone can carry. And most founder bottlenecks are really state-management problems. Not “I don’t know what to do” — more like “I keep resetting the context every time I come back to this.”

Projects reduce that reset tax. They give recurring work a home. And once recurring work has a home, it becomes easier to schedule, easier to improve, and easier to hand off.

The Shift

If chat is where you think with Claude, and Cowork is where you assign Claude work — Projects are where that work finally starts to persist.

Claude Cowork didn’t just get folders. It got a place to stay oriented. A place to remember what matters in one lane without dragging the rest of your work into it.

Once AI has execution, memory, and a bounded workspace, you stop interacting with it like a chatbot. You start working with it like an operator.

Projects don’t make Claude smarter.

They make your work stop starting over.

Reply and tell me what project you’d set up first.

— Aj, @thevibefounder

It’s not.

Anthropic just changed Claude from something you sit down and prompt into something you can assign recurring work to. You describe the job once. You set the cadence. Claude runs it on your desktop using the same tools, connectors, and skills you already have configured.

That is a different relationship with AI.

The Second Prompt That Never Happens

Every take I’ve seen so far frames this as automation. Technically accurate. Completely misses the point.

The real bottleneck for most people using AI is not “getting a good answer.”

It’s remembering to come back and do the same useful thing again.

The first time you prompt Claude to build a competitor digest, it’s great. Real insight. You think: I should do this every week. Then you don’t. Not because it stopped being useful. Because you got busy. Because the task wasn’t hard enough to put on your calendar but valuable enough that skipping it costs you.

That is where most AI value dies. Not in the first prompt. In the second one that never happens.

Scheduled tasks fix that specific failure mode.

What Actually Shipped

Cowork now lets you create recurring and on-demand tasks. Open Claude Desktop, go into Cowork, type /schedule or click Scheduled in the sidebar. Write the prompt once, pick the cadence, it runs.

Anthropic’s own examples are telling. Daily briefings from Slack, email, or calendar. Weekly reports from Drive or spreadsheets. Recurring research on competitors or market topics. File organization. Team updates built from project tools.

When a scheduled task runs, Claude uses your original prompt as instructions, executes at the cadence you chose, and saves the result as its own Cowork session. You write the job once. It stays written.

How It Works Under the Hood

Cowork runs directly on your computer. Not purely in the cloud. It executes tasks in an isolated environment and delivers outputs back to your file system.

Scheduled tasks inherit that same local model. They access connected tools, plugins, skills, files, and whatever connectors you already have configured.

This is not “Claude sends me a reminder.” It can do work against your environment. Pull from Slack. Read local files. Generate the report. Leave the output waiting.

What I Actually Put on a Schedule

I didn’t start with something flashy.

I picked the task that kept slipping: Sunday session prep.

Every week I run a live building session. The prep is always the same. Scan what shipped that week in AI tools. Check what’s trending on X. Figure out what the audience cares about right now so the session lands on something real, not something stale.

It takes maybe 30 minutes when I do it well. The problem is I don’t always do it well. Some weeks I’m deep in ClawShip. Some weeks I’m behind on content. The prep gets compressed into Saturday night or skipped entirely, and I walk into Sunday running on instinct instead of signal.

So I scheduled Claude to run that scan every Saturday morning. Pull trending AI topics from X. Surface tool launches and feature drops from the past seven days. Leave the output waiting.

On the first run, I expected a rough list. What I got was closer to a briefing.

It had flagged a tool launch I’d missed completely.

Not a minor update. A shipping product that was already getting traction in builder communities while I was heads-down on other work. The kind of thing I would have caught if I’d done my normal scan that week. But I hadn’t. Because the prep had slipped again.

That was the moment.

Not because the output was magical. Because it caught something real that I’d already missed by doing my prep manually and inconsistently.

The feature stopped being theoretical right there.

This isn’t about Claude being smarter than me at research. It’s about the fact that a task I already knew mattered finally had a clock attached to it. And the first time it ran, it proved why it needed one.

The Best Use Cases Are Boring on Purpose

This is where people get distracted. They hear “scheduled AI tasks” and jump to agent fantasies.

The real value is in boring repetition.

A daily morning briefing built from Slack and email. A weekly competitor digest dropped into a doc. A recurring research pass on one market you care about. A regression checklist run on a cadence.

Conservative use cases are usually where product-market fit hides. If a tool saves you from redoing the same useful thing every week, it compounds fast.

Not “what’s the craziest thing Claude could do on schedule?”

Instead: “what am I repeatedly doing that is valuable, annoying, and structurally delegable?”

The Catch

This is not a cloud worker that runs forever while your laptop sleeps in the other room.

Cowork scheduled tasks only run while your computer is awake and the Claude Desktop app is open. It requires a paid plan. It is still labeled a research preview. Anthropic explicitly warns users not to schedule tasks involving sensitive files, purchases, or actions hard to undo.

It means this is not yet “infrastructure.” It is still “your laptop as infrastructure.”

And honestly, that’s fine for now.

Because the real breakthrough is not that Claude is fully autonomous. The breakthrough is that the work itself can be defined once and executed repeatedly.

What This Changes for Solo Founders

The most valuable thing AI has done for solo founders is not making code faster. It’s making org structure cheaper.

First you got help generating work. Then you got help executing work. Now you’re getting help remembering and repeating work.

That sounds small until you realize how much founder drag lives in repeated tasks.

The weekly research doc never gets compiled. The Monday review never happens. The pipeline check gets skipped. The operating rhythm collapses under everything else.

The problem is not “I don’t know what to do.”

The problem is “I know what to do, but I have to manually trigger it every single time.”

Scheduled tasks change that. Not by making Claude autonomous. By giving it a clock.

You Are No Longer Just Prompting

The old model: open AI, ask for help, wait for output.

The new model: define work, assign it, review results, improve the system.

That is a manager’s loop.

Still early. Still rough. Still tied to an awake desktop.

But the direction is obvious.

Claude stops responding only when you remember to ask.

It starts showing up on a cadence.

For anyone building alone, that is a very different kind of leverage.

Reply and tell me what task you’d put on a schedule first.

— Aj, @thevibefounder

Yesterday, OpenAI shipped subagents for Codex in general availability.

Not a preview. Not behind a feature flag. GA. Available now.

Sam Altman said something when the Codex team announced it worth sitting with: the hardcore builders he knows have all switched to Codex.

Hardcore builders.

That’s not enterprise positioning. That’s for people who build like their life depends on it — solo founders, small teams, people doing the reps.

That’s us.

Here’s what this actually means — what it is, how it works, and what happened when I ran it.

Everyone’s Getting the Headline Wrong

Every article right now is calling this a parallelism feature.

Run multiple agents at once. Go faster. More throughput.

That’s technically accurate and completely misses the point.

The reason subagents matter has nothing to do with speed. It has to do with a problem that every single person using AI coding tools has hit, whether they know what to call it or not.

OpenAI calls it context pollution and context rot.

Here’s what that means in plain English.

When you run a complex task in one thread — exploring a codebase, writing new features, running tests, debugging failures, updating docs — everything accumulates in the same context window. Exploration notes. Stack traces. Dead ends. Outdated observations. The model’s working memory fills up with noise from its own process.

Over time, the signal-to-noise ratio degrades. The model starts making decisions based on stale observations from earlier in the thread. Output quality drops.

This isn’t a model capability problem. It’s an architectural problem.

Subagents fix the architecture.

Each agent gets a clean context. It does its job. It reports back with a focused summary. The main agent — your orchestrator — never sees the mess. It only sees the output.

The main agent stays clean the entire time.

That’s the actual insight. Not parallelism. Role isolation with orchestration.

How It Actually Works

Codex ships with three built-in agents out of the box. No config required.

default — General-purpose fallback. Works for most things.

worker — Execution-focused. For implementation tasks. Designed to run large numbers of small tasks in parallel.

explorer — Read-heavy. For exploration and scanning. Stays out of your write scope.

You can use these immediately just by referencing them in a prompt. But the real power is in custom agents.

Custom Agents

Custom agents live as TOML files in one of two places:

• ~/.codex/agents/ — personal agents available across all your projects

• .codex/agents/ — project-specific agents checked into your repo

Every custom agent needs three things:

toml

name = "reviewer"
description = "PR reviewer focused on correctness, security, and missing tests."
developer_instructions = """
Review code like an owner.
Prioritize correctness, regressions, security, and missing test coverage.
"""

Everything else is optional but powerful. You can override the model, reasoning effort, and sandbox mode per agent:

toml

name = "explorer"
description = "Lightweight scanner for codebase mapping and dependency tracing."
developer_instructions = """
Map code paths. Trace dependencies. Surface relevant context.
Do not write or modify files.
"""
model = "gpt-5.3-codex-spark"
model_reasoning_effort = "low"
sandbox_mode = "read-only"

Model Selection

Two main choices:

gpt-5.4 — Full reasoning. Use for your main orchestrator and anything requiring judgment. Complex logic, security analysis, synthesis.

gpt-5.3-codex-spark — Optimized for speed. Use for worker agents. Exploration, scanning, mapping, quick summaries.

The pattern that works: main agent on gpt-5.4 with high reasoning effort. Worker agents on Spark with low or medium reasoning effort.

You pay more in tokens. You save more in time and context quality.

Runtime Controls

Two global settings worth knowing:

toml

[agents]
max_threads = 6
max_depth = 1

max_threads controls how many agents run concurrently.

max_depth controls delegation depth — whether agents can spawn their own subagents.

Keep max_depth = 1 unless you specifically need nested delegation. Subagents inherit the parent session’s sandbox and approval state. They’re parallel workers inside the same runtime policy, not independent sessions with looser permissions.

Try This Right Now

Open Codex and run this prompt on your project:

Review my project. Spawn 3 subagents:
1. Check for security vulnerabilities
2. Identify missing test coverage
3. Suggest performance improvements
Wait for all three, then give me a prioritized action list.

That’s your first run. Ten minutes. See what comes back.

What I Actually Ran

I wasn’t trying to build something new when I tested this.

I had work that had already shipped. I needed the documentation to catch up.

Sprint summary. Feature matrix. Changelog. Regression checklist. Backfilled narrative for the March 16-17 iterations. The kind of work that always falls behind because it competes with building. It’s not the product. It’s the record of the product.

I asked Codex to handle it.

First it inspected the repo — git history, existing docs, everything that had actually been pushed versus everything the docs claimed existed.

Then it spawned three subagents with non-overlapping write scopes:

A sprint agent to create a new sprint summary for the March 12-17 work.

A PM tracking agent to update the feature matrix, changelog, and regression checklist so the docs matched live code.

A session-history agent to backfill the narrative docs with the missing March 16-17 iterations.

Three jobs. Three owners. No shared files. No coordination overhead.

Ten minutes later, all three reported back.

The Moment

The PM tracking agent flagged something on its way out.

It had removed stale $7 pricing language from the docs.

Not because I asked it to catch pricing errors. Because the docs no longer matched the code, and it was doing its job.

That’s when I stopped.

Not because it was impressive. Because of what it meant.

The docs weren’t just incomplete. They were confidently wrong. In multiple places. The kind of wrong that lives quietly in a repo for weeks until someone makes a decision based on outdated information.

That’s not a writing problem. That’s a reconciliation problem.

And reconciliation is exactly what subagents are built for — because the real work isn’t typing new content. It’s reading what exists, comparing it against reality, and surfacing the contradictions.

One agent in one thread would have done that sequentially, accumulating noise the whole way through. Three agents with clean ownership did it in parallel and reported back with focused outputs.

The main agent focuses on decisions. The subagents handle the noise.

What This Replaced

Before subagents, I’d budget 45-90 minutes of focused senior work for the same job.

Read recent commits. Inspect diffs. Update multiple docs. Catch contradictions. Review the final state.

If humans were splitting it: an engineer doing repo archaeology plus a PM doing a docs pass afterward. Two people. Handoff overhead. Still probably missing something.

Ten minutes. Three focused agents. One consistency pass.

That’s not a speed upgrade.

That’s a different way of operating.

When to Use Subagents (and When Not To)

Use subagents when the work has clean separable parts — PR review, codebase exploration, documentation sync, bug triage across multiple issues, test coverage where one agent writes and another validates.

The rule: if you can assign a job title to it, you can probably make it a subagent. Most knowledge work has job titles.

Do not use subagents when:

Agents need to write to the same files — you’ll get conflicts. Tasks are sequential where step two depends on step one — agents can’t coordinate mid-run. The task is simple and single-file — unnecessary overhead and token cost.

Subagents consume significantly more tokens since each one does its own model and tool work independently. Use them when parallelism genuinely makes sense, not as a default.

What This Actually Signals

This isn’t AI helping you go faster.

This is AI helping you operate at a scale that used to require a team.

Think about what a real code review actually requires. Someone tracing code paths. Someone checking security and correctness. Someone verifying the APIs. Someone synthesizing all three into priorities.

That’s four roles. Before yesterday, a solo founder either did all four passes sequentially in one degrading context window, or didn’t do it at all.

Now the structure exists.

And critically — you steer individual agents as work unfolds. This isn’t fire-and-forget automation. You’re in the loop. You can redirect a running subagent, stop it, or close completed threads.

You don’t get to remove yourself. You move up a level.

The senior engineer doesn’t write every line. They decompose the problem, assign roles, synthesize findings, make the call.

That process is now available to someone with a laptop and a Cloudflare Worker.

Not approximately. Actually.

The Part That Doesn’t Change

Subagents fail when the work isn’t actually separable.

The quality of the output is still a function of the quality of the roles you define.

A narrow, opinionated agent with clear instructions outperforms a vague general-purpose one every time. Once one agent has too many responsibilities, you lose most of the benefit — mixed responsibilities create mixed context. The output gets blurry.

You still need judgment. You still need to know when decomposition makes sense and when it doesn’t.

AI removes friction. It doesn’t remove responsibility.

But if you have judgment, and you’ve been doing the reps, the tools just handed you an organizational structure you couldn’t have bought.

Build while the gap is open.

Reply and tell me what task you’d split into subagents first.

— Aj, @thevibefounder

Most people who set up an AI agent hit the same wall.

The bot is live. It responds. It sounds smart. But every time you open it, you start from scratch. You re-explain the task. You re-set the context. You babysit the output.

That’s not automation. That’s just a chat window with extra steps.

The problem is not the bot. The problem is that the bot has no instructions to follow when you’re not there. No process. No memory of how you want things done. Nothing to run on except whatever you type next.

There is a fix. It’s called a skill. And most people building with AI have never heard of it.

I run live building sessions every Sunday. 450+ builders, screen share, no script, shipping real things in real time. Last session, 50 people got their first AI agent live on ClawShip. Within 20 minutes, most of them were stuck for exactly the reason above.

So I scrapped the agenda and spent the rest of the session building a skill live on screen. Start to finish. Every prompt, every step.

This post is the full method.

What A Skill Actually Is

Before the steps, get this clear. Most people get it wrong.

A skill is not a prompt.

A prompt is a one-time instruction. You type something, the model responds, done. Tomorrow you type it again. Nothing is remembered. Nothing is systematised. You are always the bottleneck.

A skill is a packaged framework. Inputs, process steps, output format, constraints. Installed into an agent so it executes the same task the same way every time, without you re-explaining anything.

Think of it this way. A prompt is asking someone to cook you dinner. A skill is the recipe you hand a chef so they can make the same dish every Tuesday without asking what goes in it.

Most people are optimising for better prompts. That’s the wrong target. The goal is a process written down clearly enough to hand off. When you have that, you’re not using AI once. You’re installing a system.

The Method: Find, Copy, Enhance, Package, Install

Every skill I build follows this sequence. Carousel posts. Research memos. Lead summaries. Doesn’t matter what the task is.

For Session 26, I used it live to build a skill that automates casual Instagram carousels. The format that consistently pulls 10,000+ views with minimum effort.

Here’s every step.

Step 1: Find Something Worth Copying

Start with an example of the output you want.

Not inspiration. Something to reverse-engineer.

I found a carousel with the right structure. The pacing, the length, the visual format. The question I always ask first: if someone handed me this output and said “make more like this,” what would I need to know?

Take a screenshot or copy the text. That’s your raw material.

What makes a good template: a clear repeatable structure, an output format you can describe in words (number of slides, word count, visual style), and something you’d want to produce at least weekly.

Step 2: Ask Claude To Copy It

Open Claude. Give it the example with this prompt:

“Here is a [post/template/format] I want to replicate. Create a copy using made-up content. Keep the exact structure, style, and format. Don’t improve it, just match it.”

You want a rough copy first. Not your version. Just proof the model understood the structure.

Why copy before you enhance? Because if the structure is wrong, your enhancements are built on a broken foundation. Get the skeleton right before you touch the aesthetics.

Review what comes back. Same rhythm? Same length? Same moves? If yes, move to step three.

If it’s off, correct specifically. “The original had 5 slides, this has 9. Keep it to 5.” Fix structure before touching anything else.

Step 3: Enhance It

Now you add your taste.

For the session I wanted the carousel to feel like a newsroom. Typewriter aesthetic, higher contrast, punchier copy. I told Claude exactly that:

“I like typewriter-style fonts and I want this to feel more like a newsroom. Enhance the design direction and make the copy more punchy.”

Two things that matter here.

Be specific about what you want changed. “Make it better” does nothing. “Cut the word count by 30% and increase contrast between the hook and the body” does something.

Change one dimension at a time. Copy, then visual style, then pacing. So you can see what each change does. If you change everything at once, you don’t know what worked.

Save the version you like. That becomes your master example.

Step 4: Package It As A Skill

Most people stop at the output they like. That’s the mistake.

With your enhanced version open, give Claude this prompt:

“Turn this into a reusable skill. Include: the inputs required, the step-by-step process, the output format, and any constraints or rules to follow every time.”

What comes back is your skill file. It will typically include a reference name, brand and context notes, input requirements, process steps, and output format.

Review it carefully. Make sure it captured everything from the enhancement step. Word count rules, visual style, structural constraints. If something’s missing, add it manually.

This file is the instructions your agent follows every time. It’s the recipe.

Step 5: Install It

Once you have the skill file, you can request it to be added to your ClawShip bot.

The skill gets assigned to your bot and becomes part of how it operates. You give the bot a topic, tell it to use the carousel skill, and it produces the output without you explaining anything.

We tested the finished skill on both Claude and GPT-4 during the session. Claude produced output closer to the original structure. GPT-4 understood the intent but drifted from the format. Worth knowing if you’re building across platforms. Build on Claude first. It’s more literal with structured frameworks. Once you have a working version, adjust the language to tighten it for other models.

What This Looked Like In Practice

The carousel skill we built on Sunday was for the Stat Hook format. The deep-dive 10-slide carousel. Same structure, same typewriter aesthetic, same pacing. Different topics, zero re-explaining.

Same format. Built once. Runs every time.

Your First Skill

Pick one task you do at least twice a week. Doesn’t have to be content. A brief, a research summary, a call recap. Anything with a consistent structure.

Do it once manually. Write down every step.

Give it to Claude with the method above.

By step four, you have a skill. By step five, your agent runs it.

The first one is slow. The second is faster. By the fifth, you’ll see the system.

The Full Process

1. Find: an example of the output you want

2. Copy: exact structure, made-up content, verify the format

3. Enhance: add your voice, aesthetic, constraints, one dimension at a time

4. Package: inputs, process, output format, rules, all in one file

5. Install: request it on your ClawShip bot, run a live test

Every skill I’ve built follows this sequence. Carousels. Research memos. Launch posts. Content audits.

The tool is not the bottleneck.

The task you haven’t written down yet is.

— Aj, @thevibefounder

I’ve raised over $30+ million.

Built companies used by more than 20 million people.

Shipped products at scale. Hired engineers. Managed teams. Generated real revenue.

And last year, when AI coding tools started exploding, I felt behind.

I wasn’t new to AI. I was building Simplified.com when AI writing, design, and video tools started going mainstream. We rode that wave early. Tens of millions of people used those products.

So it wasn’t that I didn’t understand what was happening.

But this wave was different.

The first AI wave lowered the barrier to content.

This one lowered the barrier to software.

Suddenly, people who had never written code were building landing pages, bots, internal tools, mobile apps. Shipping things in hours.

Replit. Claude. Lovable. Codex. Something new every week.

And I hadn’t written real code in 15 years.

I could talk product strategy all day. I could raise capital. I could design a roadmap.

But watching non-engineers ship faster than I was forced me to confront something uncomfortable.

Execution was no longer scarce.

Judgment was.

Watching Wasn’t the Problem. Not Building Was.

I could have quietly learned.

Bought a course. Watched tutorials at night. Played with the tools privately until I felt competent.

That would have been safe.

But I’ve learned something about myself.

If I don’t create pressure, I drift.

And I didn’t want to drift through this moment.

So I did something slightly irrational.

I said I would build something every Sunday. Live.

No slides.

No curriculum.

No “10-step framework.”

Just opening Zoom and building something in real time.

If we were building a landing page, I had to understand the stack.

If we were deploying a bot, I had to think through the product.

If we were charging money, I had to think through the market.

Public accountability forced private reps.

And reps sharpen judgment.

It Wasn’t Clean

At the same time, I was starting another company — Otto AI, a finance platform for creators.

Moving from venture-backed to bootstrap.

Rebuilding from scratch.

I was overworked. Overcommitted. Behind on almost everything.

I’ll give you a specific Sunday so you know what I mean.

The session was about deploying an AI bot — OpenClaw, the first fully autonomous bot that runs in the cloud, remembers everything, takes actions on your behalf. I’d been working on a platform called ClawShip to make deployment simple for non-technical people. The problem I was solving was real: the manual setup takes weeks, involves cloud infrastructure, API keys, security configs. People were abandoning it at step four.

Five minutes before going live, I was still coding. Still fixing things. I thought: shit, this is not gonna work.

I went live anyway.

iPhone mirroring failed. My own Telegram token was bad — I got stuck on the same step as the audience. Then 23 people deployed bots simultaneously, the machine limit hit, and my credit balance went to zero. I was topping up credits live while 20+ people sat in the Zoom waiting.

I promised session recordings that didn’t go up for months.

Some Sundays failed like this.

Tools broke.

Prompts didn’t work.

APIs refused to connect.

People watched it happen live.

There were weeks I asked myself if I should stop.

It would have been easier.

But I kept showing up.

Not because I had it figured out.

Because I didn’t.

And that started to matter.

The First Signal

At first, about 20 people showed up.

Five or seven came back every week.

Same names. Same questions.

That consistency mattered more than growth. They weren’t just watching — they were building.

After a few weeks, people started asking if there was a group. So I created a WhatsApp.

No funnel strategy. No marketing playbook.

Just Instagram → Zoom → WhatsApp.

The group grew to over 450 builders. Substack crossed 7,000 subscribers. Sessions now get 200+ RSVPs, around 60 live.

Not viral. But real.

Consistency compounds.

From Millions to $175 — And Why That Matters

I’ve built companies that generated millions in revenue.

This time, I was building alone. With AI.

ClawShip went from zero to 30 customers in about 10 days. $175 in revenue.

Not impressive on paper.

But here’s what actually happened on that Sunday session after I fixed the credit issue and got the machines running:

27 out of 33 bots ended up live. One of the people in that session — David — told me he’d spent two full days trying to deploy the same bot on his own. Tried AWS. Tried other cloud setups. Couldn’t get past the configuration. Gave up. Then found me on Instagram Friday, showed up Sunday, and had a working bot in 40 minutes.

He wasn’t missing motivation.

He wasn’t missing intelligence.

He was missing a clear first step and someone to debug alongside.

That’s the whole thing.

You don’t need a team. You don’t need funding. You don’t need to relocate to a tech hub. You don’t even need to be an engineer.

You need judgment.

You need reps.

You need the willingness to ship something small and fix it live.

The size of the problem doesn’t matter. The size of the company doesn’t matter.

What matters is crossing zero to one.

That first user. That first dollar. That first proof that something you built creates value.

Once you cross that line, everything changes.

You stop asking “Can this work?”

You start asking “How do I improve it?”

When Everyone Can Build, Building Isn’t the Advantage

Building is no longer rare.

You can type plain English into a model and get working software. Landing pages. Bots. Internal tools. Mobile apps.

Execution is cheap. Judgment is not.

David’s two days of frustration before that Sunday session wasn’t a skill problem. It was a clarity problem. He didn’t know which step to take first. He didn’t know which errors mattered and which to ignore. He didn’t know when to push through and when to start over.

That’s what AI doesn’t give you.

The tool isn’t the bottleneck anymore.

Knowing what to build. Knowing what not to build. Knowing how to test something cheaply. Knowing when to ignore hype. Knowing when to double down.

AI removes friction. It does not remove responsibility.

That’s why I don’t care about being the first to try every tool.

I care about building judgment through repetition.

That’s what Sunday became. A forcing function for decision-making. A way to develop thinking, not just execution.

What This Substack Is

This is where I document how judgment gets built.

Not through theory — through weekly reps. Each post is a direct record of what we built, what broke, what the prompts actually looked like, and how I’m thinking about product and revenue in a world where execution is no longer the hard part.

You’re not getting a newsletter about the future of AI. You’re getting the actual workflow of someone navigating this shift in real time — making mistakes publicly, fixing them live, and sharing what’s worth keeping.

The goal isn’t for you to follow my exact path. It’s for you to see that the path exists, that it’s messier than the highlight reel, and that the only thing separating you from your first working product is a clear first step and the willingness to show up before you’re ready.

That’s the deal.

If you feel behind, you’re not late.

You just haven’t done the reps yet.

Reply and tell me what you’re building.

— Aj, @thevibefounder