Engineers Don't Want to Push More Slop

Shan — Tue, 18 Aug 2026 20:34:27 +0000

One thing I keep hearing around AI coding tools is that engineering leaders want more velocity, while engineers are increasingly worried about what that velocity actually looks like.

Nobody wants to spend their day pushing slop.

A team can open more PRs than ever and still end up spending a surprising amount of time reviewing weird diffs or asking why the agent changed something that seemed fine before.

And if enough of those changes make it through, customers eventually notice. Bugs show up and small behaviors change. Things feel a little less reliable for everyone.

When that starts happening, the obvious reaction is to add more guardrails. Catch the bad diffs before they merge. Or pull back and let agents write less code.

There's another option we're more interested in: make the agent less likely to produce the bad diff in the first place.

The model can often write perfectly reasonable code. The problem is that it has no idea what happened six months ago at your company.

Say there's some ugly authentication code. An agent looks at it, sees an obvious cleanup, runs the tests, and opens a PR. Looks good.

Except six months earlier, an engineer spent an afternoon debugging an auth issue that only happened for one customer with a strange SAML setup. They tried the cleaner approach already and eventually landed on the ugly workaround.

None of that is obvious from the code.

Maybe pieces of the story are in a PR, Slack thread, or an old agent session. More likely, some of it was just typed into the agent's prompt while the engineer was debugging.

The next agent doesn't know any of that. This is something we're working on with OliverGraph.

We're trying to save what happened during the work, not just the final diff. If another agent touches that part of the codebase later, it should know what the previous engineer and agent already learned.

When an agent starts working on something, it shouldn't just retrieve relevant code. It should be able to retrieve some of the history behind that code too.

Something as simple as:

This workaround came from an incident three months ago. Someone already tried removing it and hit a race condition.

That's the direction we're betting on.

Teams are going to keep using agents to ship more code. I'd rather help make those diffs better than build increasingly large filters to catch the bad ones afterward.

When Everyone Has AI Agents, Who Knows What They’re Doing?

Shan — Mon, 17 Aug 2026 00:26:28 +0000

We started building OliverGraph to give teams and their AI agents shared context across GitHub, Slack, docs, and the other places where work happens.

At first, we thought the main problem was retrieval. Company knowledge is scattered across GitHub, Slack, docs, tickets, and people so we could connect those systems and get the right context to the agent when needed.

But we ran into another problem. Agent runs were becoming another place where important context lived.

An agent also gets context directly from the engineer using it. An engineer might tell an agent that the team tried something before, that a customer depends on a certain behavior, or that there's a constraint that isn't documented anywhere else.

The agent uses that context while doing the work, but when the run ends, it can disappear with it. The next engineer's agent may see the resulting code without knowing what context was given to the previous agent.

This gets messier during outages. Several engineers might be investigating at once with their own agents. One agent rules out a recent deploy while another discovers an issue with a database query. Those findings are now spread across separate agent sessions, and another agent might spend time investigating something that was already ruled out.

Humans already deal with this

Companies have fragmented context. One engineer remembers an old outage and another engineer remembers that the team already tried an approach but abandoned it.

So we ask each other.

Who worked on this?
Why is this here?
Didn’t we try this already?

You might not know the answer, but you know John worked on that part of the system. John remembers the PR and the PR points to an incident. People slowly build a mental map of where all that context lives in the company.

Agents don’t have that. As everyone starts using more agents, it becomes harder for humans too. My agent may be changing onboarding while your agent is modifying authentication. Another teammate’s agent may have just discovered an API limitation that affects both. The team can suddenly have much more work happening than anyone has visibility into.

What we’re building with OliverGraph

We want to keep the useful history from agent runs and connect it to artifacts that exist within the company (such as PRs, docs, outages, etc.)

If an agent changes a service, we want to capture what it was trying to do, what it changed, and why it happened.

Then we connect that history to artifacts in OliverGraph: the code, PRs, conversations, previous agent runs, decisions, and people involved.

When another agent starts working on something related, that history can be retrieved and fed back into its context.

The next agent should know what previous agents already tried, and the team can see what those agents have been working on and why.

If you’re running multiple coding agents across your engineering team, I’d be curious how you’re handling this today. We’re also looking for a few teams to try OliverGraph with us: olivergraph.com so please send us an email at ryan@olivergraph.com

DEV Community: Shan

Engineers Don't Want to Push More Slop

When Everyone Has AI Agents, Who Knows What They’re Doing?

Humans already deal with this

What we’re building with OliverGraph