DEV Community: Erik Scott

Make Your AI List Its Assumptions Before It Edits Code

Erik Scott — Thu, 16 Jul 2026 21:56:15 +0000

The worst AI code changes start with a quiet guess.

You ask for a small refactor. The tool finds a pattern. It fills the gaps. Then it writes clean code around a false idea.

Tests may still pass.

The fix is simple. Make the tool list its assumptions before writing code.

The failure hides inside the request

Say you ask:

Add retries to failed payment status checks.

The tool may make several guesses:

Every failed request is safe to retry.
A timeout means no work happened.
Two requests cannot cause duplicate work.

Those guesses may be wrong.

The frustrating part is not the mistake. It is how reasonable the code looks afterward.

I kept reviewing the code instead of reviewing its starting beliefs. That was backward.

A good change starts with checked facts.

Use this prompt before risky edits

Paste this before the tool changes any file:

Before editing code, list up to five assumptions you are making.

For each assumption, include:
1. The assumption
2. Evidence from this project
3. The risk if it is wrong
4. What still needs checking

Do not write code yet.

That last line matters.

Without it, many tools will list assumptions and start coding anyway. You want a pause between thinking and changing.

What a useful answer looks like

A weak answer sounds like this:

Retries should be safe because they are common here.

That is not evidence. It is a guess wearing a tie.

A useful answer might say:

The client retries read requests in src/client.ts. Tests cover status codes 429 and 503. Timeout behavior is not tested. We need to check whether the server can finish after the client times out.

Now you have something you can review.

You can open the file. You can read the tests. You can check the timeout case.

The tool has shown where its confidence ends.

Review the evidence, not the confidence

For each assumption, ask one question:

Can I point to proof inside this project?

Good proof includes:

A test that names the behavior
A caller that depends on the behavior
A config value
A current design note
Code that already handles the same case

Weak proof includes phrases like these:

“This is usually safe.”
“Most systems work this way.”
“The name suggests that.”
“This seems low risk.”

Those phrases are not always wrong. They just need checking.

Use it where guesses cost the most

This prompt helps most when a change touches:

Data writes
Login or access rules
Jobs that may run twice
Public API behavior
Error handling
Old code with few tests

You do not need it for every typo.

Use it when a hidden rule could turn clean code into broken behavior.

The goal is not perfect certainty

You will never remove every unknown.

The goal is to make unknowns visible before they become code.

Once the assumptions look sound, tell the tool to continue. If one lacks proof, stop and check it first.

That small pause changes the review. You are no longer asking only, “Does this code look right?”

You are also asking, “Did it start from the right facts?”

Before your next risky edit, paste the prompt and inspect the first assumption.

Tags: ai, programming, productivity, testing

The Decision Lives in a Recorded Call. The Spec Is a PDF. Your AI Can't Read Either.

Erik Scott — Mon, 06 Jul 2026 14:00:22 +0000

The most expensive decision on your project might be sitting in a call recording nobody will ever open.

Here's the moment I keep seeing. A developer asks their AI assistant why the checkout flow caps retries at three. The assistant guesses. It sounds plausible. It's wrong.

The real answer was settled six weeks ago, on a recorded call, at minute 34. The spec that backs it up is a PDF export from design. The proof of the original bug is a screenshot in a Slack thread.

Three artifacts. Zero of them text. Zero of them visible to the assistant.

Your project's memory is not all text

We like to pretend engineering context lives in code and markdown. It doesn't.

The why behind half your architecture lives in:

recorded calls and design reviews
screenshots of errors, dashboards, and mockups
PDFs: specs, contracts, design exports
the occasional whiteboard photo

AI coding tools read text. So all of that context is invisible to them. When the answer isn't reachable, the assistant does the only thing it can: it reconstructs from scratch.

Sometimes it reconstructs wrong. Confidently.

What we built instead

ContextStream indexes media as part of your project's memory. Images, video, audio, and PDFs.

Concretely:

Screenshots get OCR. The error message in that image becomes searchable text.
Calls get transcripts. "What did we decide about retry limits?" finds minute 34, not the whole hour.
PDFs are indexed. The spec's actual constraint surfaces next to the code it constrains.
Clips can be extracted, so the answer is the ninety seconds that matter, not a forty-minute recording.

The point isn't storage. Everything is already stored somewhere. The point is retrieval: the answer surfaces in the session where the work is happening, when you or your agent asks.

What changes day to day

You hit a design question mid-implementation. Instead of pinging the designer and waiting, you ask. The answer comes back from the design review recording, pointed at the moment it was settled.

Your agent is about to "fix" the retry cap. The transcript of the call where that cap was chosen surfaces first. The agent leaves it alone.

A new teammate asks why the API returns 202 instead of 200. The answer exists. It was a screenshot of a client email. Now it's searchable.

Fewer interruptions. Fewer confident wrong guesses. Fewer settled decisions relitigated because the original reasoning was trapped in a format nobody searches.

Why ContextStream matters here

AI assistance is only as good as the context it can reach. Most teams have quietly accepted that a huge slice of their context, the recorded and screenshotted and PDF slice, is unreachable.

That's not a tooling gap. It's context debt. And it compounds: every unreachable decision is one your team, and your agents, will pay to reconstruct again.

ContextStream makes project memory durable and queryable, whatever format it arrived in. Text, image, audio, or video: one memory, one search.

Try it on one file

Pick the one recording or spec PDF people keep asking about. Make it searchable at contextstream.io and watch what stops getting re-asked.

ai #devtools #productivity #programming

What Your AI Agent Should Read Before It Writes a Single Line

Erik Scott — Thu, 02 Jul 2026 01:58:09 +0000

An AI agent rarely fails in the middle of a task.

It fails in the first thirty seconds, before it writes anything, because it starts working without the decisions your team already made.

Here is how that looks in practice.

You ask your agent to add pagination to an API endpoint. It writes clean, plausible code. Offset-based, new helper function, tidy tests.

Three problems:

Your team decided months ago that offset pagination falls over on that table. You moved to cursors for a reason.
A cursor helper already exists. The agent just wrote a second one.
There is a hard-won lesson from a past bug: that endpoint's cache breaks when the response shape changes.

The agent knew none of it. Not because it is a bad agent. Because nobody told it.

The context existed. It just wasn't reachable.

The pagination decision lives in a chat thread. The helper is documented on a wiki page nobody opens. The cache lesson lives in one teammate's head.

So every task starts with a guess.

And you pay for the guess in review comments, in rework, in that sinking "wait, we already solved this" feeling.

Ground the task, not the prompt

This is the exact problem ContextStream's per-task grounding bundles solve.

Before your agent acts, it gets a small bundle of the most relevant prior decisions, docs, and lessons for this specific task. Not the whole knowledge base stuffed into the window. The three things that matter.

For the pagination task, the bundle surfaces:

The decision: cursor pagination on large tables, with the rationale attached.
The doc: the existing cursor helper and how to use it.
The lesson: the cache breaks when the response shape changes. Learned once, carried forward.

Now the agent's first move is informed instead of plausible. It extends the helper instead of duplicating it. It keeps the response shape stable. It writes code your reviewer can trust faster.

Does grounding change outcomes? Measurably.

In ContextStream's published evals, agents hit a 96% agent task success rate with project memory connected (23 of 24 tasks, versus 14 of 24 without it).

Same agent. Same tasks. The difference was whether the work started grounded.

Why this matters

The bottleneck in AI-assisted coding is shifting. Writing code is cheap now. Knowing what not to break is the expensive part.

Grounding bundles move that knowledge to the front of every task, automatically, inside the tools you already use: Claude Code, Cursor, Codex, Cline, and Windsurf.

Decide it once. Document it once. Fix it once. Then let every future task start from there instead of from zero.

Connect a project and watch what your agent's next task starts with: try it at contextstream.io.

Tags: #ai #devtools #programming #productivity

Why Context Matters More Than Ever in AI-Assisted Development

Erik Scott — Sun, 28 Jun 2026 20:53:30 +0000

In the fast-paced world of software development, context is everything. Yet, most AI tools today start from scratch every session, forcing developers to re-explain their project, their decisions, and their pain points. That’s not just inefficient—it’s frustrating.

With ContextStream, we’re rethinking how AI assistants work by giving them persistent memory of your project. Instead of starting cold each time, your assistant picks up where you left off, with a deep understanding of your project’s history, decisions, and lessons learned. This means faster, more grounded decisions, and fewer repeated questions.

The result? You spend less time retraining your assistant and more time building. You avoid the same mistakes twice. And you finally have an assistant that actually knows your project, not just your latest prompt.

ContextStream isn’t just another AI tool. It’s a way to make your assistant a true teammate—one that learns, remembers, and helps you move forward with confidence.

devtools #ai #softwareengineering #productivity #contextstream

Make Your Project Decisions Queryable for AI Coding Sessions

Erik Scott — Sun, 28 Jun 2026 20:52:59 +0000

Tags: #ai #devtools #productivity #programming

Make Your Project Decisions Queryable for AI Coding Sessions

Every project has a layer that never makes it into the repo.

It is the reasoning behind the code:

why you chose this approach over the obvious one
the bug that taught you not to repeat a mistake
which doc is current and which one is stale
the thing the team already decided not to build
the plan you are halfway through

Developers carry most of that context in their heads. Some of it lands in notes. A lot of it gets buried in threads. And too much of it disappears between one AI coding session and the next.

That gap is quietly expensive. It rarely shows up as a disaster. It shows up as small repeats: explaining the same constraint again, correcting the same suggestion again, reopening a decision you already made, or hunting for the note that would have saved you twenty minutes.

Here is a practical habit that helps: treat your project decisions as queryable memory, not scattered breadcrumbs.

Before you ask an assistant for help, capture the context that actually changes the answer:

The decision that shaped what you are working on
The lesson from the last bug, review, or refactor
The plan you are following right now
The doc or note that defines the real constraint
The correction you do not want to make twice

The point is not to write more documentation. The point is continuity.

When you come back tomorrow, or next month, you should not have to rebuild the whole story from memory. The context should be ready when the next question shows up.

That is the problem we are building ContextStream to solve.

ContextStream gives AI coding work persistent, cross-session memory. It remembers project decisions, docs, lessons, and plans, so your assistant can pick up where you left off instead of starting cold. It also learns from real activity over time, so lessons from past sessions can compound instead of resetting.

The part that matters most is not storage. Developers already have plenty of places to store things. The harder problem is surfacing the right context at the right moment.

With ContextStream, decisions, docs, lessons, and plans are queryable. That means the relevant context can show up while you are debugging, planning, reviewing, or deciding what to do next, instead of staying buried until after you needed it.

Why ContextStream matters

Developers lose momentum when project memory is scattered. Teams redo work when old lessons are hard to find. And an AI assistant can only be as useful as the project context it can work from.

ContextStream helps close that gap: less lost context, less repeated work, faster and more grounded decisions, and an assistant that actually remembers your project.

That is the workflow we care about. Not louder tools. Not more tabs. Just real continuity from one session to the next.

I Got Tired of Re-Explaining My Codebase to AI — So I Built a Memory Layer

Erik Scott — Tue, 27 Jan 2026 22:33:04 +0000

It's 9:47 AM. I'm reopening my IDE to continue yesterday's work on an auth system. I ask Claude to pick up where we left off.

"What authentication approach are you using? JWT or sessions? Which OAuth provider? What's your database?"

We literally discussed this yesterday. For an hour.

This kept happening to me. Every. Single. Session.

Disclosure: I'm the founder of ContextStream — I built this because I couldn't stand paying this tax anymore.

The problem nobody budgets for: AI amnesia

AI coding assistants are incredible inside a single chat. They can reason about architecture, write production code, catch bugs.

But the moment you close the window? Total amnesia.

After ~18 years of shipping products, I've learned to notice invisible productivity taxes. This one was huge:

Re-explaining my stack
Re-listing architectural decisions
Re-attaching the same context files
Re-arguing patterns we already settled

I started tracking it. I was spending 10–15 minutes per session just getting the assistant back up to speed.

Why the obvious "solutions" didn't solve it

I tried all the usual workarounds:

Chat history: noisy, not portable across tools, and I still had to scroll and re-read.

Built-in memory toggles: tied to one product; I bounce between tools depending on the task.

Pasting context every time: it works, but defeats the point of having an assistant.

What I actually needed was a memory layer that:

Captures decisions as I make them
Retrieves the right context automatically
Works across the AI tools I use

What I built: a memory layer behind my AI tools

I spent the last year building ContextStream — a memory layer that sits behind my AI tools via MCP (Model Context Protocol). MCP is a protocol that lets AI clients call "tool servers" to fetch context.

The core insight is simple:

Storage is cheap. Retrieval is hard.

If you dump everything into context, token costs explode and the model gets confused. The only thing that works is delivering the right context at the right time.

So ContextStream captures three kinds of "project memory":

Decisions — "We're using JWT with refresh tokens"
Context — indexed code/docs so the assistant can retrieve what matters
Connections — which decisions affect which modules

A tiny "before → after"

Before:

"JWT or sessions? Which provider? Which database?"

After:

"Last time we chose JWT with refresh tokens. OAuth provider is X. The auth code lives in …. Want me to continue with the refresh rotation + middleware?"

That's the bar I wanted: start where we left off, not at square one.

Setup (the happy path is one command)

npx -y @contextstream/mcp-server setup

That's it — it configures MCP for the tool you're using.

What actually changed for me

The obvious win: no more re-explaining.

The surprising win: consistency.

Before, my assistant would suggest camelCase on Monday and snake_case on Wednesday. Now it remembers "this codebase uses camelCase" and stays consistent.

And when bugs resurface (they always do), it can pull the previous fix back into view:

"We saw this before — the issue was X, and we fixed it by Y."

If you've felt this too…

The free tier gives you enough operations to see if it clicks.

If you try it, I'd love one piece of feedback:

What's the #1 thing you wish your AI assistant would remember about your project?

Project: contextstream.io
MCP server repo: github.com/contextstream/mcp-server