DEV Community

Sam
Sam

Posted on

Meta launched another coding agent last week.

#webdev #ai #automation #news

Your AI Coding Agent Doesn't Need More Instructions. It Needs a Memory.

Meta launched another coding agent last week.

It's called Muse Code, it's powered by Muse Spark 1.2, and it joins an increasingly crowded field that already includes Claude Code, Codex, Copilot, Cursor, Gemini CLI, and others.

That part isn't particularly surprising.

What caught my attention was something else.

Muse Code keeps an activity log so that if a long-running task is interrupted, it can resume rather than starting over.

Reuters reported on the launch here.

Think about what that feature is implicitly admitting:

The model being smart isn't enough. The agent also needs continuity.

And that becomes much more interesting when you put it next to some recent research about the way we're currently giving coding agents context.

Every AI is getting smarter
Every AI is getting smarter. But intelligence and continuity are different problems.

We've gotten very good at giving AI instructions

Most serious AI-assisted codebases now accumulate some version of this:

CLAUDE.md
AGENTS.md
.cursor/rules/
copilot-instructions.md
README.md
architecture.md
Enter fullscreen mode Exit fullscreen mode

We tell the agent:

  • how the repository is structured
  • what commands to run
  • what patterns to follow
  • what not to touch
  • how tests work
  • which architectural conventions matter

This makes intuitive sense.

If a new engineer joined your team, you'd give them documentation.

Why wouldn't we do the same thing for an AI coding agent?

The problem is that documentation and memory solve different problems.

Then the research got awkward

A July 2026 study called "Do Context Files Help Coding Agents?" tested persistent context files across Claude Code and Codex.

The experiment covered:

  • 288 evaluated agent runs
  • 17 real development tasks
  • 3 repositories
  • 2 frontier coding agents

The researchers compared agent performance with different context-injection strategies.

Their conclusion was surprising: context strategy did not measurably move correctness for either agent in their experiment.

Source: Do Context Files Help Coding Agents? — arXiv

That's worth being careful about.

It does not mean AGENTS.md is useless.

It does not mean documentation is useless.

And it definitely doesn't prove that agents should receive less information in every situation.

What it suggests is something more interesting:

Supplying more repository instructions may not solve the failures we think it solves.

The researchers found many failures came down to implementation skill, pattern selection, feature design, and exact wiring rather than simply missing repository knowledge.

Another study found something even more uncomfortable

Earlier in 2026, another study looked specifically at repository-level AGENTS.md files.

The researchers evaluated both generated and developer-written context files across multiple coding agents and real repository tasks.

Their conclusion:

Context files tended to reduce task success rates while increasing inference cost by more than 20%.

Source: Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?

Again, the lesson isn't:

"Delete your AGENTS.md."

The researchers argue for minimal, useful requirements rather than dumping everything into the agent's context.

That's the part I find compelling.

We may be treating context windows like storage.

They aren't.

Context is not memory

Consider these two statements.

Instruction 

All billing changes must go through BillingService.
Never write directly to the subscriptions table.
Enter fullscreen mode Exit fullscreen mode

Useful.

Now consider this:

Memory 

We previously wrote renewal state directly to the subscriptions table.

That bypassed BillingService and caused webhook retries to overwrite
subscription status for annual plans.

We fixed it by routing renewal updates through BillingService.

If modifying renewal logic:
1. use BillingService
2. test annual-plan webhook retries
3. verify idempotency
Enter fullscreen mode Exit fullscreen mode

Those aren't the same thing.

The first tells an agent what to do.

The second tells the agent:

  • what happened
  • why it happened
  • what failed
  • what fixed it
  • how to verify we don't repeat it

That's institutional knowledge.

That's scar tissue.

Instructions describe the road.

Memory remembers where you crashed.

AI tools can still forget you

Software teams already understand this

Human engineering teams rarely operate from documentation alone.

A senior developer knows things that aren't perfectly represented in the README.

They remember:

"We tried that."

"Don't use that library here."

"That endpoint looks synchronous, but the downstream worker isn't."

"Changing this migration breaks old customer imports."

"We fixed this exact race condition six months ago."

A good senior engineer isn't valuable only because they know the current architecture.

They're valuable because they've accumulated consequences.

They know the difference between:

This should work.
Enter fullscreen mode Exit fullscreen mode

and:

We tried this. Here's what happened.
Enter fullscreen mode Exit fullscreen mode

AI agents don't naturally accumulate that kind of experience.

The strange architecture of AI coding today

Our current workflow often looks something like this:

                     ┌─────────────┐
                     │   README    │
                     └──────┬──────┘
                            │
                     ┌──────▼──────┐
                     │  AGENTS.md  │
                     └──────┬──────┘
                            │
                     ┌──────▼──────┐
                     │ CLAUDE.md   │
                     └──────┬──────┘
                            │
                      MORE CONTEXT
                            │
             ┌──────────────▼──────────────┐
             │      CURRENT AI AGENT       │
             └──────────────┬──────────────┘
                            │
                          WORK
                            │
                            ▼

                 session eventually ends
                            │
                            ▼

                      start again
Enter fullscreen mode Exit fullscreen mode

We're getting increasingly sophisticated about what goes into the model.

We're much less sophisticated about what should survive after the session.

And now developers are switching agents constantly

This matters more because there is no longer one obvious AI coding environment.

A developer might use:

Task Tool
Architecture discussion ChatGPT
Repository implementation Claude Code
IDE completion Copilot
Autonomous issue work Codex
Quick experiments Cursor
Another task next month Something that doesn't exist yet

Meta's Muse Code launch makes this fragmentation even more obvious.

Reuters describes Muse Code as being built for long, complex software tasks and able to run multiple sub-agents simultaneously. It also records its activity so interrupted work can resume.

Reuters — August 5, 2026

That is useful.

But it raises a bigger architectural question:

Who should own the memory?

The coding agent?

The IDE?

The model provider?

The repository?

Or you?

Your memory should outlive the model

Models are becoming interchangeable faster than memory is

This is the part I think developers may underestimate.

Models are improving very quickly.

Developer loyalty to any particular model may therefore be temporary.

Today's workflow:

Claude Code
Enter fullscreen mode Exit fullscreen mode

Tomorrow:

Codex
Enter fullscreen mode Exit fullscreen mode

Next month:

Muse Code
Enter fullscreen mode Exit fullscreen mode

Six months from now:

????
Enter fullscreen mode Exit fullscreen mode

If every switch requires rebuilding the same understanding…

Here's the architecture.

Here's why we use Postgres.

Here's what happened to authentication last month.

Here's why this service looks weird.

Here's what we tried already.

Here's how I like PRs structured.

Here are the edge cases we discovered.
Enter fullscreen mode Exit fullscreen mode

…then the smartest AI in the world still wastes time relearning your world.

What should actually persist?

Not everything.

That's important.

A memory system that simply saves every conversation is eventually just another giant context dump.

Useful long-term memory should be selective.

For software work, I think it falls into roughly four buckets.

1. Decisions 

We chose Redis Streams instead of RabbitMQ because...
Enter fullscreen mode Exit fullscreen mode

2. Work history 

The checkout refactor changed these components...
Enter fullscreen mode Exit fullscreen mode

3. Preferences and conventions 

Prefer small composable services over adding methods to the controller.
Enter fullscreen mode Exit fullscreen mode

4. Scar tissue 

Symptom:
Annual subscription renewals occasionally reverted status.

Cause:
Webhook retries bypassed BillingService.

Prevention:
Route renewal changes exclusively through BillingService.

Verification:
Replay duplicate renewal webhook during tests.
Enter fullscreen mode Exit fullscreen mode

That fourth category may be the most valuable.

Scar tissue is different from documentation

This is a concept we've been exploring while building Empirical.

The idea is simple:

A system becomes more trustworthy when it remembers verified failure, not just successful instructions.

Empirical's Scar Tissue plugin structures remembered failures around:

symptom
cause
prevention
verification
scope
Enter fullscreen mode Exit fullscreen mode

Documentation says:

Do X.
Enter fullscreen mode Exit fullscreen mode

Scar tissue says:

Do X because we did Y before and production caught fire.
Here's how we'll know it doesn't happen again.
Enter fullscreen mode Exit fullscreen mode

There is a huge difference.

You can read more about the concept here:

Your AI coding agent needs scar tissue

And the implementation is documented here:

Empirical Scar Tissue plugin

A better model: separate instructions, context, and memory

I think the architecture eventually looks less like this:

EVERYTHING
   ↓
CONTEXT WINDOW
   ↓
MODEL
Enter fullscreen mode Exit fullscreen mode

and more like this:

                 ┌──────────────────┐
                 │   INSTRUCTIONS   │
                 │ How to work      │
                 └────────┬─────────┘
                          │
                          │
┌──────────────────┐      │       ┌────────────────────┐
│ CURRENT CONTEXT  │──────┼─────▶│      AI AGENT      │
│ What's happening │      │       │                    │
└──────────────────┘      │       └─────────┬──────────┘
                          │                 │
                 ┌────────▼─────────┐       │
                 │ PERSISTENT MEMORY│◀──────┘
                 │                  │
                 │ Decisions        │
                 │ History          │
                 │ Preferences      │
                 │ Scar tissue      │
                 └──────────────────┘
Enter fullscreen mode Exit fullscreen mode

And critically:

Claude
   │
Codex
   │
Cursor ──────────▶ SAME MEMORY
   │
Copilot
   │
Muse Code
   │
Whatever is next
Enter fullscreen mode Exit fullscreen mode

The memory belongs above the model.

More context isn't always better

There's another recent piece of research that pushes in this direction.

A 2026 paper asked:

What context does a coding agent actually need to act?

Researchers found that compressed context matched whole-file performance in their experiment while using roughly a third of the context tokens per resolved issue.

Their point is less about memory specifically and more about signal density:

The question isn't:

How much can the model read?

It's:

What information actually helps it act?

Source:

What Context Does a Coding Agent Actually Need to Act?

That feels like an important shift.

We've spent the last few years celebrating context-window size.

Maybe the next phase is about context quality.

The context-window mindset vs. the memory mindset

Context-window mindset Memory mindset
Give the agent everything Retrieve what matters
Repeat project information Preserve durable knowledge
Optimize one session Optimize many sessions
Model owns the conversation User owns the knowledge
Store instructions Store consequences
Start from documentation Learn from history
Agent-specific Portable

The distinction becomes more important every time another coding agent launches.

The real moat may not be the model

This is where the Meta announcement becomes interesting.

We now have some of the world's largest technology companies competing to build better coding agents.

That competition will probably produce incredible models.

Which means developers will keep switching.

If model quality converges — or if different models become best at different jobs — then something else becomes increasingly valuable:

The accumulated knowledge around the work itself.

Your:

  • architectural decisions
  • debugging history
  • conventions
  • failed approaches
  • project state
  • preferences
  • lessons

In other words:

The tools become replaceable.

The memory becomes the asset.

One memory for every AI

This is the bet behind Empirical

We're building Empirical around a fairly simple idea:

One memory for every AI you use.

Rather than making your project knowledge belong to Claude, ChatGPT, Cursor, Codex, or whatever agent you happen to use this week, the memory layer should belong to you.

That means you should be able to preserve useful knowledge once and surface it wherever you're working.

Not every chat.

Not every token.

Not giant transcripts.

The durable stuff.

The things worth remembering.

I don't think AGENTS.md is going away

Nor should it.

Instructions are useful.

Documentation is useful.

Repository context is useful.

But I suspect we're going to stop expecting those things to solve a fundamentally different problem.

An AGENTS.md file answers:

How should you work in this repository?

Memory answers:

What have we learned while working in this repository?

Those sound similar.

They're not.

And as coding agents become more autonomous, the distinction becomes increasingly important.

The question I keep coming back to

Imagine your current AI coding agent disappeared tomorrow.

You switch to another one.

How much would you have to teach it again?

If the answer is:

"A lot."

Then maybe your project doesn't actually have a memory yet.

It has a prompt.

Sources / further reading

  1. Meta launches Muse Code — Reuters, Aug. 5, 2026

    https://www.reuters.com/technology/meta-launches-new-ai-coding-tool-powered-by-muse-spark-12-2026-08-05/

  2. Do Context Files Help Coding Agents? A Two-Agent Ablation Study on Real Repositories — Prakhar Khatri, July 2026

    https://arxiv.org/abs/2607.27250

  3. Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? — Gloaguen et al., 2026

    https://arxiv.org/abs/2602.11988

  4. What Context Does a Coding Agent Actually Need to Act? — Brian Sam-Bodden, 2026

    https://arxiv.org/abs/2607.09691

  5. Empirical: Your AI coding agent needs scar tissue

    https://empirical.gauzza.com/blog/ai-coding-agent-scar-tissue-your-ai-coding-agent-needs-scar-tissue/

  6. Empirical Scar Tissue documentation

    https://empirical.gauzza.com/docs/plugin-scar-tissue/

Try the idea yourself

If you're bouncing between Claude, ChatGPT, Codex, Cursor, or other AI tools and are tired of rebuilding the same project context:

Take a look at Empirical →

One memory. Every AI.

Top comments (0)