DEV Community: Sam

Meta launched another coding agent last week.

Sam — Mon, 10 Aug 2026 23:51:50 +0000

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. 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

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.

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

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.

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.

and:

We tried this. Here's what happened.

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

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?

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

Tomorrow:

Codex

Next month:

Muse Code

Six months from now:

????

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.

…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...

2. Work history

The checkout refactor changed these components...

3. Preferences and conventions

Prefer small composable services over adding methods to the controller.

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.

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

Documentation says:

Do X.

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.

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

and more like this:

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

And critically:

Claude
   │
Codex
   │
Cursor ──────────▶ SAME MEMORY
   │
Copilot
   │
Muse Code
   │
Whatever is next

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.

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

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/
Do Context Files Help Coding Agents? A Two-Agent Ablation Study on Real Repositories — Prakhar Khatri, July 2026

https://arxiv.org/abs/2607.27250
Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? — Gloaguen et al., 2026

https://arxiv.org/abs/2602.11988
What Context Does a Coding Agent Actually Need to Act? — Brian Sam-Bodden, 2026

https://arxiv.org/abs/2607.09691
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/
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.

What One User Taught Me About AI Memory

Sam — Tue, 28 Jul 2026 23:25:54 +0000

Empirical gave me a separate memory layer when ChatGPT’s built-in memory became unreliable. For long-running continuity work, that extra memory has been more than useful, it has been a blessing.

— Thomas, Empirical user

When I read that response in a user survey, I stopped for a minute. Not because it was flattering, but because it described the problem I had been trying to solve better than I had.

This is what that problem looks like in practice: an AI coding agent reaching into Empirical, finding a lesson from an earlier build, and using it to avoid making the same mistake again.

Empirical surfaces a relevant lesson from an earlier build before the agent changes the code.

AI Is Great at Conversations

Today’s AI models are impressive. They can write code, summarize documents, brainstorm ideas, analyze data, and help us solve problems faster than ever before.

Inside a single conversation, they can feel almost magical. Long-running work, however, is different.

Eventually, the conversation becomes too large. It gets archived. You switch models, open a new coding session, or move from one AI tool to another. Somewhere along the way, pieces of the project begin to disappear.

The AI forgets why you made a decision six weeks ago. It forgets the experiment that failed, the bug you already spent three hours fixing, or the naming convention everyone agreed to stop changing.

Then you find yourself explaining the project again, not because the AI is unintelligent, but because the history it needs is no longer available.

Context Isn’t Memory

This distinction matters.

Context is temporary. Memory is durable.

A conversation gives an AI enough information to respond right now. A memory system preserves useful knowledge so it can be found again later.

Those are not the same thing.

Imagine working with a brilliant teammate who forgot everything after every meeting. They are smart, helpful, and may even do excellent work, but every Monday morning starts from scratch.

That is what long-term AI work can feel like.

A larger context window may delay the problem, but it does not necessarily solve it. More room for text is not the same as knowing what mattered.

A Real Example

The screenshots in this article come from an actual coding session.

A coding agent was working through a timing issue inside a task creation service. The service needed to save a task durably before returning a successful response, while secondary work such as refreshing a search index and publishing a webhook could happen afterward.

The focused test was still reporting the old behavior.

At first, the agent inspected the implementation, changed the code, and ran the test.

There was an important timing detail hiding underneath the obvious fix.

Calling asynchronous integrations directly still allowed their synchronous startup code to run before the promise continuation resumed. The task was technically being saved first, but the response path was still being delayed by derived work.

That is the kind of problem that can consume an afternoon.

It also happened to be the kind of problem the project had encountered before, so the agent queried Empirical.

The memory it found described a similar failure pattern: return after the durable save while allowing duplicate detection, analytics, search indexing, webhook delivery, and other derived work to continue asynchronously.

The agent was not handed a finished answer. It was given the missing project history, and that was enough to recognize the pattern.

Remembering the Scar, Not Just the Fact

I think of memories like this as scars.

A scar is evidence that something happened, but it also carries a warning: do not make the same cut in the same place.

In this case, the earlier project memory helped the agent understand that simply removing await was not enough. The derived work needed to be deferred to the next event-loop turn so the response could continue immediately after persistence.

The agent updated the implementation, preserved the existing error handling, and ran the focused regression test again.

The recalled memory helps the agent defer derived work, preserve error handling, and pass the focused test.

The test passed.

That matters, but the more interesting part is why it passed. The agent did not stumble across the solution as though the project had no history. It found a lesson the project had already paid to learn.

Why I Built Empirical

I did not build Empirical because I wanted another AI chat app. I built it because I wanted a memory layer that belonged to me.

I wanted something that could preserve decisions, experiments, project history, bugs and their causes, lessons learned, recurring patterns, rejected approaches, and ideas worth revisiting.

Not only for one conversation, but across projects, across months, and across whichever AI model, editor, or coding agent I happen to use next.

Models will change. Tools will change. The memory of the work should not disappear every time they do.

The Part That Surprised Me

When I started building Empirical, I assumed people would mostly use it to remember facts.

Instead, some of the most valuable memories preserve thinking: why an idea was rejected, why a reasonable-looking implementation failed, which assumption turned out to be wrong, what tradeoff was deliberately accepted, and what finally worked.

That kind of information rarely survives in normal documentation. It gets scattered across chat transcripts, pull requests, terminal sessions, issue trackers, meeting notes, and somebody’s increasingly unreliable recollection of what happened last Tuesday.

Documentation usually records the final decision, but not the confusion that came before it. That confusion is often where the lesson lives.

Months later, the reasoning behind a decision can be more valuable than the final code. It becomes part of the project’s memory.

Memory Should Keep Learning

After the issue was fixed, the agent recorded the new lesson back into Empirical.

The completed fix becomes durable project knowledge instead of disappearing into the transcript.

That part is important. A useful memory system should not only retrieve what was known in the past. It should keep learning from the work happening now.

The agent recorded the lesson in plain language:

The task must be durably saved before returning, while duplicate detection, auditing, search indexing, webhook delivery, and other secondary work remain asynchronous.

The exact wording is less important than the principle. The project now has a durable explanation of what happened, what was changed, and why.

The memory could then be queried again to verify that it was available for future work.

The project does not merely retrieve old knowledge. It accumulates new knowledge as the work continues.

The loop is simple:

Recall what the project already knows.
Use it to make a better decision.
Record what the project just learned.

The next agent does not have to rediscover the same lesson from zero. Neither does the next developer. Neither do I.

This Isn’t About Remembering Everything

I do not think an AI memory system should save every word of every conversation forever. That would create a different problem: noise.

The goal is not perfect recall. The goal is useful recall.

The decisions that changed the project. The failures that revealed something important. The lessons that would be expensive to relearn. The assumptions that should be questioned next time.

A good memory system should help an AI find the right five sentences, not force it to reread fifty thousand.

Thomas Said It Better Than I Could

The survey response that stayed with me was this:

Empirical gave me a separate memory layer when ChatGPT’s built-in memory became unreliable. For long-running continuity work, that extra memory has been more than useful, it has been a blessing.

That is what I hope Empirical becomes.

A memory that grows alongside AI. Something that lets the work keep its history even as the models and tools around it change.

That is the difference between an AI that helps with today’s task and one that can actually continue the work.

Try Empirical and give your AI a memory that belongs to you.

The forbidden fruit of vibe coding isn’t bad code.

Sam — Fri, 26 Jun 2026 14:20:03 +0000

It’s working code.

Because once something works, your brain **wants **to _trust _it.

The button clicks.
The page loads.
The dashboard renders.
The demo looks real.

And suddenly, it’s tempting to believe the project is further along than it actually is.

But working is not the same as ready.
Working is not the same as secure.
Working is not the same as understood.
And working is definitely not the same as remembered.

That was the surprising part for me.

AI-assisted coding helped me move fast, but it also created a new problem: forgotten assumptions.

The shortcuts.
The warnings.
The “we’ll fix that later” moments.
The decisions that made sense in one session but got fuzzy in the next.

The internet is noticing this too

“A lot of security is contextual.”

Read the full piece in The Verge

— Jack Cable, security researcher

“Speed without control is a liability, not an advantage.”

Read GitLab’s AI Accountability Report announcement

— Manav Khurana, GitLab

That was the surprising part for me.

AI-assisted coding made it easier to build fast.

But it also made it easier to forget why certain decisions were made in the first place.

And when a quick prototype starts becoming real software, that forgotten context starts to matter.

I wrote more about that here:

Empirical - Your vibe-coded app got serious faster than expected

Curious how others are handling this: where do you keep the “don’t forget this before this ships” stuff when working with AI coding tools?

Your AI Coding Agent Needs Scar Tissue

Sam — Mon, 15 Jun 2026 11:38:48 +0000

The most expensive AI mistake is not when your coding agent gets something wrong.

It is when it gets the same thing wrong again tomorrow. That is the part that starts to wear you down. Not because the model failed once.

That happens.

The frustrating part is when you already corrected it.

You explained the repo pattern.
You told it why that migration broke.
You pointed out the weird CI issue.
You showed it the dependency that already failed.

The agent fixed the task.
The session ended.

Then two days later, a new session suggests the same bad idea like none of it ever happened.

That is the problem I have been thinking about lately. AI coding agents do not just need bigger context windows.

They need scar tissue.

What I mean by scar tissue

Scar tissue is remembered failure.
It is not generic documentation.
It is not a massive chat transcript.

It is not another bloated AGENTS.md file that gets stuffed into every prompt whether it is relevant or not.

Scar tissue is the durable memory of what went wrong, why it went wrong, and what should not be repeated.

Examples:

Do not use this migration pattern in this repo.
It passes locally but breaks staging because of X.

Do not replace this middleware.
It looks redundant, but it protects the admin route.

Do not use this package again.
We tried it and it failed on Vercel because of native dependencies.

The Stripe webhook handler must preserve the raw body.
Normal JSON parsing breaks signature verification.

This test failure usually means the mock user is missing a role.
Do not rewrite the auth flow first.

That kind of knowledge is incredibly valuable.

But most of the time, it disappears.

It lives in someone’s head.
Or buried in Slack.
Or trapped in yesterday’s AI session.
Or hidden somewhere in a pull request comment nobody will ever read again.

Context is not the same thing as learning

A lot of AI coding workflows still treat context like the solution to everything.

Add more files.
Add more instructions.
Add more docs.
Add more examples.
Add more project history.

Eventually the prompt becomes a junk drawer. The agent has more text, but not necessarily more judgment. That is the distinction I care about. Context tells the agent what is nearby. Scar tissue tells the agent what it learned the hard way.

Those are not the same thing.

The old pattern

This is what a lot of AI coding sessions look like:

Session 1:
Agent suggests bad approach.
Developer corrects it.
Agent fixes the issue.
Session ends.

Session 2:
Agent has no memory of the correction.
Agent suggests the same bad approach.
Developer loses trust.

The model did not technically “forget.”

It never had durable memory in the first place. It only had temporary working space. Once the session ended, the lesson vanished.

The better pattern

This is the pattern I want instead:

Session 1:
Agent suggests bad approach.
Developer corrects it.
The lesson gets stored as a durable project memory.

Session 2:
Agent starts a similar task.
The relevant scar gets retrieved.
Agent avoids the old mistake.

That is a different kind of AI coding workflow.

Not just faster.
Not just cheaper.
Not just fewer tokens.

More experienced.

Why this matters more as agents get better

The better coding agents get, the more this matters. When agents only wrote tiny snippets, forgetting was annoying. Now they can touch real architecture.

They can refactor files.
They can generate migrations.
They can write tests.
They can modify production-adjacent code.

That makes repeated mistakes more expensive.

If an AI agent is going to operate inside a real codebase, it needs more than instructions.

It needs a memory of consequences. It needs to remember the things that hurt.

Where Empirical fits

This is one of the use cases I am exploring with Empirical.

Empirical is a memory layer for AI tools.

Instead of stuffing every lesson, decision, preference, and warning into a giant prompt, Empirical lets an agent retrieve the specific memory it needs when it needs it.

For coding agents, that means the memory layer can hold things like:

Project decisions
Repo conventions
Failed approaches
Bug history
CI/CD quirks
Security gotchas
Dependency warnings
“Never do that again” lessons

That is the stuff that usually gets lost between sessions.

And it is also the stuff that makes a developer more useful over time.

Why should an AI coding agent be any different?

The future is not just smarter agents

I do not think the next leap in coding agents is only going to come from smarter models.

Some of it will come from better memory.

Not memory as a transcript dump.
Not memory as “load the whole repo into context.”

Memory as accumulated judgment.
Memory as operational history.
Memory as scar tissue.

Because the real win is not just an agent that can write code. The real win is an agent that remembers why the last fix failed.

I wrote more about the idea here:

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

Maybe Bigger Context Windows Aren't the Answer

Sam — Fri, 05 Jun 2026 13:59:12 +0000

When humans need information, we don't load everything we know into our heads at once.

We ask questions.

We look things up.

We pull in details when they become relevant.

AI systems should probably work the same way.

Recently I updated Empirical's CLI documentation system.

Before, I could have dumped the entire command reference into every agent session and called it a day.

Instead, the installer adds a tiny instruction:

empirical doc
empirical doc <topic>
empirical doctor

That's it.

The agent doesn't get the entire manual.

It gets a pointer to the manual.

When it needs help with memory commands, it runs:

empirical doc memory

When it needs installation help:

empirical doc install

When it needs to discover what's available:

empirical doc

The detailed documentation is loaded only when needed.

Less context. Better timing.

What's interesting is that this is becoming a pattern throughout Empirical.

The CLI uses on-demand documentation.

Memory retrieval works the same way.

Conversation context works the same way.

Instead of shoving everything into the prompt and hoping the model finds what matters, Empirical tries to surface only the information relevant to the current task.

I've started thinking of this as progressive disclosure for AI.

Not bigger context.

Better context.

The future may not belong to systems that remember everything. It may belong to systems that know what not to load until it's actually needed.

This idea has become one of the guiding principles behind Empirical.

We're exploring what happens when AI systems retrieve information as needed instead of carrying everything around all the time.

If that sounds interesting, I'd love for you to take a look at Empirical and share your feedback:

https://empirical.gauzza.com

Seen this ChatGPT warning before? Here’s a fix.

Sam — Thu, 04 Jun 2026 13:27:08 +0000

I kept seeing this little warning under ChatGPT’s message box:

ChatGPT gets less accurate and may forget details in long conversations.

For a while, I ignored it.

Then I realized I was keeping months of notes in one long ChatGPT thread.

Dates. Numbers. Observations. Things I actually cared about.

And that warning started to feel a lot less theoretical.

The problem

Long chats feel like memory.

You can scroll back. You can ask for summaries. The thread is still there.

But a chat is not a database.

Eventually, I started noticing small details drift. A date would be off. A number would show up that I did not remember entering. The answer sounded confident, but parts of it were not from my actual notes.

That is the scary part.

Not that ChatGPT forgot.

That it filled in the blanks.

What I changed

I stopped keeping the important stuff only inside the chat.

I connected Empirical and asked ChatGPT to save the tracking data as separate memories.

That changed the setup.

The record no longer lived inside one conversation.

The conversation became one way to reach the record.

So if I start a new ChatGPT thread later, it can pull the saved context back from Empirical
instead of relying on one long chat to remember everything.

👉 Add Empirical to ChatGPT

Why it helps

I asked ChatGPT directly whether saving the data into Empirical actually helps with the long-chat forgetting problem.

Here’s the part that mattered:

Even if a future conversation does not contain the whole old chat, the saved context can still be retrieved from Empirical.

That is the fix.

The chat can forget.

The record does not have to disappear with it.

The takeaway

If you use ChatGPT for something important, do not let the only copy live inside one thread.

Use the chat for conversation.

Use memory for the stuff you actually want to keep.

For me, that means Empirical now holds the record, and ChatGPT, Claude, or Codex can pull from it when needed.

If you use coding agents too:

👉 Install Empirical for coding agents

Original post:
Seen this ChatGPT warning before? Here’s a fix.

Last night at 11:30 pm I screwed up. It led to an unexpected win.

Sam — Fri, 29 May 2026 13:42:53 +0000

Last night at 11:30 pm I screwed up. It led to an unexpected win.

I'd been heads-down in Empirical on something else for a while. Hadn't touched the public site in days. When I finally went to ship, I pushed and watched two weeks of UX work vanish. The site reverted to its pre-redesign state right in front of me.

The new pages were gone. Wasn't caching. Not in main. Not in any branch I could reach. I couldn’t find it anywhere I could realistically untangle at midnight.

So I asked Empirical what it remembered.

It pointed me at an unreachable WIP commit floating in the void after the cleanup. One git cherry-pick later, the redesign was back. Four minutes of recovery. A lot longer spent panicking before I thought to ask.

Unexpected win for Empirical. The use case I never would have pitched, never would have asked for, and absolutely needed at 11:34 on a Tuesday. The hero I didn't want, but the one I needed.

Full write-up👇

Empirical saved my ass. | Empirical Blog

First-person incident report on recovering lost frontend work by querying Empirical memory, locating an unreachable WIP commit, and restoring the missing public-site redesign. Empirical saved my ass.

empirical.gauzza.com

What's the dumbest thing you've ever done to your own repo at midnight?

I Cut Coding Agent Context Usage by 22–45% by Killing Context Bloat

Sam — Tue, 12 May 2026 19:02:23 +0000

A lot of AI coding workflows degrade the exact same way.

At first, everything feels incredible.

Your coding agent:

understands the project
moves insanely fast
eliminates boilerplate
compounds your momentum

Then a few weeks later:

AGENTS.md turns into a novel.

Prompts get bloated.

The model starts missing obvious things.

Responses become inconsistent.

Token usage quietly becomes absurd.

I kept running into this while building Empirical.

Eventually I realized the problem wasn’t:

“The model needs more context.”

The problem was:

“The model is carrying too much irrelevant context at once.”

That distinction changed everything.

The Hidden Failure Mode of Coding Agents

Most teams solve AI memory like this:

“Just add it to the prompt.”

And over time the context fills up with:

Permanent Context Soup

architecture decisions
coding standards
deployment notes
UI preferences
old implementation details
temporary fixes
abandoned experiments
half-finished thoughts

Eventually every request drags all of it around forever.

Even when most of it has absolutely nothing to do with the current task.

That creates a brutal signal-to-noise problem.

The model starts treating temporary junk and critical architecture decisions with equal importance.

You can actually feel the degradation happen.

Symptoms:

the agent gets fuzzier
architecture drift increases
outputs become inconsistent
you spend more time correcting than building

Bigger Context Windows Aren’t the Real Solution

I think the industry is optimizing the wrong thing right now.

Everyone keeps pushing toward:

Bigger Everything

million-token windows
infinite memory
larger context sizes
stuffing more into prompts

But humans don’t work like that either.

Good engineering teams don’t bring every document into every meeting.

Most information is situational.

Most memory should stay dormant until it becomes relevant.

That was the shift for me.

Not:

“How do I fit more into context?”

But:

“How do I load only what matters right now?”

What Worked Better

I started treating AI memory more like layered working memory instead of permanent prompt stuffing.

1. Lean Persistent Context

Keep permanent instructions extremely small.

Only things like:

architecture principles
coding philosophy
project identity
non-negotiables

That layer should stay lean on purpose.

2. Retrieved Context

Pull implementation knowledge dynamically based on:

Relevance Signals

semantic similarity
current task
related code paths
previous work in the same area

Only relevant context enters the active prompt.

3. Session Context

Use temporary working memory for:

Active Work

bugs
in-progress features
short-lived implementation decisions

Then let it expire naturally instead of polluting long-term memory forever.

What Changed

The biggest surprise wasn’t even the token savings.

It was how much sharper the agents became once the noise disappeared.

After reducing context bloat:

responses became more focused
architecture stayed more consistent
prompt babysitting dropped significantly
outputs drifted less between sessions

The token reduction was just the measurable side effect.

Results

Workflow	Context Reduction
Smaller focused tasks	~22%
Larger iterative workflows	Up to ~45%

That compounds fast once agents start looping.

The Bigger Realization

I think a lot of AI tooling is accidentally recreating bad human organizational habits.

We already know what happens when people dump everything into:

Organizational Chaos

giant docs
giant meetings
giant Slack threads
giant Notion pages

Clarity collapses.

Coding agents seem to behave better when memory works more like human working memory:

Better Memory Pattern

small active focus
relevant recall
long-term memory separated from immediate attention

That mattered far more than raw context size.

Full Breakdown

I wrote the complete breakdown here:

retrieval architecture
layered memory strategy
implementation lessons
where the 22–45% savings actually came from

→ Reducing Coding Agent Context Usage by 22–45% with Retrieval-Based Memory Systems

I’ve been using Empirical as my memory layer across AI tools.

Sam — Fri, 08 May 2026 16:36:24 +0000

ChatGPT memory helps.
Local MD files help.

But neither travels cleanly across everything I use, and packing too much into MD files eats context and tokens.

With Empirical, I keep my AGENTS.md lean and let Codex pull context dynamically when it actually needs it.

I can open ChatGPT on my phone, connected to Empirical, and it pulls the same memory context and writing tone I use in Codex or any other connected AI tool.
That means:

less repeated setup
cleaner, cheaper prompts
more consistent output across sessions

This is just the tip of the iceberg.

I wrote up a Codex example here:

How I Used Codex + Empirical to Lock In My Writing Voice | Empirical Blog

April 30 note on using Empirical with Codex to define a repeatable writing voice through guided questions and live revision.

empirical.gauzza.com

I Needed Memory That Survives Context Windows. Memory That Moves Across Environments

Sam — Thu, 09 Apr 2026 13:05:00 +0000

I kept running into the same thing with AI tools:

great context disappears
I repeat myself constantly
Every tool remembers different stuff (or nothing)
Moving between tools my context doesn't follow me

So I built Empirical.

It started in a pretty common place: I was iterating on a Philly-style hoagie roll recipe.

I wanted the AI to remember what I liked, what failed, and what I wanted to try next without re-explaining it every time.

I originally thought Empirical would be its own chatbot. I started down that path, then realized I was solving the wrong problem. Reinventing the wheel.

I didn’t need another chat interface.
I needed a memory layer I could use everywhere.

So I changed lanes and focused on MCP tools.

Now I use Empirical memory across:

Coding CLI's
ChatGPT
Claude Web
Claw Agents

Same memory, different interfaces. Now if ChatGPT is no longer _cool _ or Claude leaks it's entire codebase, I can switch to the latest hot thing and all my context and memories move with me.

Real examples that made this click for me

I can take a pic of a bourbon, say “I like this,” and that preference is saved as persistent memory.

I can send health data and query/chat over it later to help spot patterns.

I can write a PRD while going on a walk with ChatGPT, then pull it back up in a CLI session at my desk.

What’s next

I’m now working on connecting Empirical to more sources so memory reflects more of my actual life/workflow.

Current focus:

better pattern recognition over time
stronger multimodal memory (text + image + structured data)
cleaner memory workflows for agents