Show HN: Grepathy – Claude made a decision nobody approved | Hacker News Reader

Show HN: Grepathy – Claude made a decision nobody approved

github.com

18 pointsevansjp44 comments

hey HN - Claude pre-created users in Clerk with null emails/names as "guest users" on a contract job. Wasn't in any plan. The CTO asked why, and I didn't know! I didn't make that decision!

The reasoning was in a transcript on my laptop. Claude Code deletes those after 30 days by default. Two of my projects lost their whole history that way.

Grepathy distills transcripts locally into markdown committed with the code. Decisions only, never your messages, no server.

List every decision nobody approved:

  grep -rn "agent-initiated" .ai/why/

Ran a blind eval before shipping, published it including the misses (REPORT.md). Agents with Grepathy answered the "why" questions right. Baseline agents made up confident wrong answers.

Open articleView on HN

Good catch on CTOs part. That scenario is one that keeps me awake at night -- that some large PR of mine has come functionality or feature that I didn't ask for and didn't notice.

How did the CTO respond to "Claude did it and I didn't catch it"? Did the AI PR summary mention it? Or did the CTO just read the code?

CTO responded well to it - frankly because we're all using some coding agent and it's just the natural process of code review for them to sniff things out. No mention of it in any PR summary - CTO found it in the migration that would mutate the User record to accept `null` email.

I am fighting against people doing this every day, and we've made it extremely clear that your computer and processes running on it are an extension of you, a human, who is responsible for the actions on your computer.

Won't that slow you down a lot? I get it in principle, but in practice if you have to review everything your coding agent does the productivity gains diminish significantly

I guess you get to choose between reviewing it yourself or wasting someone else’s time

I can’t tell if you are serious. Are you serious?

Whether or not he's serious, as someone who's grudgingly using Claude at work due to mandates, the productivity gains do shrink massively (and sometimes go negative) if you actually attempt to gain the level of understanding you'd have of the system had you written it yourself.

Does it matter if the developers understand the system they maintain?

I guess that depends whether the genAI maximalists turn out to be right.

> Does it matter if the developers understand the system they maintain?

Are they maintaining it if all they do is type prompts into Claude?

Yes, they are.

They may be doing a poor job of it - time will tell.

But, at present, they're still the ones merging PRs and deploying changes to production.

It brings to mind the Chinese Room argument: https://en.wikipedia.org/wiki/Chinese_room

If a person in a Chinese Room doesn't actually understand Chinese, though the system as a whole behaves as if it does - can we say that the engineer merging PRs and deploying to production understands the system or maintains it?

What happens when there’s an outage though? Just hope the LLM can fix it? Who is on the hook if it can’t?

Do you have people frantically trying to reverse engineer a basically unfamiliar-to-them code base at 2am while bleeding cash?

As far as I can tell, yes, the workflow is "assume the LLM can fix it."

I've certainly seen people on this site defend that idea vociferously.

I won't tell you it's impossible - Claude does do legitimately amazing things.

It does not, however, seem to me to actually have deep understanding of what it's doing. "Amazing" does not mean "admirable" or "trustworthy."

Would you rather have one cookie now or two cookies later?

> I didn't know! I didn't make that decision!

Thanks for today's dose of impostor syndrome cure.

I recently took a small contract to help a vibe-founder de-vibe his project a bit. One hour with him has done more for my confidence as a developer than all the good work I’ve done this year. When probing for answers about the app and system he (lovable and Claude) had created he legitimately could not answer a single question and has almost no idea how anything works, even though there is a public web app that is capable of taking subscription payments from authenticated users. We’re living in strange times, and a giant pile of shit is coming at us like floods and tsunamis. If you’re patient and nice to talk to I imagine there will be good work available with which to flex your “I know what I’m doing”

Well done.

This is not just Claude’s behaviour :)

It could be used for every agentic coding as well, because I have experienced such mess so many times in last three years.

One issue repaired, another one touched and changed…

thank you so much! started with a Claude Code adapter, but you think Codex would be a good next one?

OpenCode, Hermes, Codex

Imho OC and H users will appreciate it more than Codex users (although there are more of them).

these are great suggestions! terrific recs - thanks. I think you're right to lean into OC and Hermes

100% important. But what decisions do you care about seeing?

The whole point of the agent is to make decisions for you. If you want to make every little detailed decision, just write the code.

The whole art of this problem is figuring out which decisions matter to you, and how to surface them.

(Disclosure: we're working on this too. https://tern.sh)

How does your solution differ from OPs?

edit:

To me it looks like yours has the following negative qualities:

- closed source

- requires signup for some service

- says code doesnt leave my machine but this connects to your servers

- requires Goose AI as a dependency

So, we tried feeding the logs back to the LLM, and it mostly produced slop. Lots of decisions nobody cared about. The biggest things that moved the needle were:

- Baseline it. We mine previous logs, github comments, etc. for "what you care about." That helps pull out decisions that you actually care to read.

- Anchor to code. "The code enshrines this decision" is more interesting than "the agent self-talked this." Agents don't always self-talk decisions, and the thing that ultimately matters is the behavior in code.

to your edit (and all totally fair):

- Yes, closed source and signup required. A lot of what we're driving towards is easy team sharing, so we're taking the bath early instead of building an OSS thing and rug-pulling later.

- Code doesn't leave your machine. There's an agent that runs locally. I know "trust me" isn't the strongest stance, but this comes from the multi-player future.

- Honestly, Goose AI is a remnant of a previous product. It's inert and we'll clean it up once we've gotten the last couple folks off the previous iteration.

hey that's awesome! yeah the eval showed first pass was only ~65% real decisions. The fix that stuck was an entry has to name a real file it touches or it gets dropped. A code decision names code.

I agree agents don't always self-talk decisions, that's why we distill the whole transcript after the fact instead of asking them to log anything. Your baselining idea is good!

Your .ai/why/main.md is at 97KB and 148 entries. Does anything prune that, or does a long-lived branch keep growing?

Nothing prunes it, atm. Currently I'm not sure if it's valuable that it does? 97KB is ~25k tokens. `grepathy context <file>` filters by the decision's Touches: list - a typical file pulls 3KB, not 97. But, I'm open to hearing a case on pruning!

For comparison the whole git log body on that branch is 3KB; the pack holds 33x the reasoning.

This is what commit messages are for.

Have you tried reading/reviewing the code claude generates? That could have prevented the issue with the accounts.

Can we get the transcript of the session where you had Claude write this post? I want to understand the "why" behind this project, and whether a human being was at any point involved in the "blind, pre-registered evaluation of Grepathy against an honest baseline".

lol yes, agents ran the mechanics. I set the bars before any run and audited the keys. And the "why" behind the project is literally in the repo's .ai/why/ where you grep it if you would like.

The repo's .ai/why/ does not contain the "why" behind the project. It provides a list of dozens of small decisions the agent presumably made as part of implementation; none of them explain what a "why-pack" is, or describe their underlying structure and principles, or detail the thought process behind the decision that "why-packs" are the best strategy to achieve the project's goals.

I would encourage you to treat AI outputs with substantially more skepticism than you're giving them.

> Decisions only, never your messages

For me this is basically the opposite of how it would need to be, the decisions are all in my messages to the agent, almost never directly in the agent's replies, sometimes indirectly though I suppose.

Interesting to see that apparently some people use these tools and are the ones listening and doing what the LLM decide and says, rather than the opposite.

> Ran a blind eval before shipping, published it including the misses (REPORT.md). Agents with Grepathy answered the "why" questions right. Baseline agents made up confident wrong answers.

Is this eval public anywhere? The whole ecosystem severely lacks transparency, and people continue making strong claims without any sort of data or results that backs these up. Is there any public somewhere backing up the idea that it's more accurate that just using whatever agent harness?

> Claude made a decision nobody approved

It irks me a tiny bit that this is essentially clickbait, you don't know for sure Claude "made a decision nobody approved" as you've lost the data because you never thought sufficiently about storing these things in the first place. Most likely it misunderstood you at one point, you didn't carefully read the reply and approved it all, so most surely what you've done lead to that being done. These big models hardly ever just randomly do whatever, you can more often than not trace it to something you did wrong.

- the distiller reads your messages, it just doesn't quote them. Decisions you directed get captured and labeled `directed`.

- eval is public here: https://github.com/evansjp/grepathy/blob/main/docs/REPORT.md

- fair point on the last one too. For the original Clerk incident the transcript is deleted, so I can't prove nobody approved it. Maybe I even waved it through. That's kind of the point though. Right now there's no record either way. I'd rather have some sort of receipt.

I guess it uses `claude -p`? Am I correct that uses API billing not subscription?

whatever your CLI currently uses. so if you use subscription, it'll use that. vice-versa for API.

Couldn't this just be in git commits and give the a skill to look there?

Not really. That's like saying a design document should be pulled out of commit messages. There are a few reasons I can think of why this would be a bad idea. Maybe the biggest is that commit messages should be quickly readable and only explain the changes in the commit. To truly explain the reasons a path was chosen by a LLM you need at least a summary of what was asked for, and related discussions or "don't do" instructions. I've heard of people wanting to commit the entire chat logs as files before, but that is noisy and might only get you halfway there as far as explanations go. I certainly don't want this data bloat, snooping, etc. I would rather for important details to be curated. I can see why maximum details could be helpful sometimes but I don't want to bloat the repo with that.

and this is why you read the code

> The reasoning was in a transcript on my laptop. Claude Code deletes those after 30 days by default. Two of my projects lost their whole history that way.

Wait what? Claude Code (and Codex) transcripts are auto-deleted??

That's a treasure trove of information for all my projects and I had built some tooling and workflows tahat deal with extracting insights from them -- withut ever realizing I mightbe losing old chats. Thanks for this -- I may need to include an archival step for retention.

Yes but it's just a setting you can change I don't think you really need an archival step

Yes done this now. Thanks.

I will still try and include archival -- storage is cheap. A reinstall of Claude Code or buggy upgrade might still wipe history. I also ocassionally use multiple PCs -- so there is some small value in consolidating them all for analytics and insights.

(When I have a weekly quota unused and about to expire -- i task Opus with churning through these archives and surfacing learining, best practices, what's not working etc)

> "cleanupPeriodDays": 99999

Throw that in ~/.claude/settings.json

Thanks. Updated.

Codex apparently does not do auto delete presently.

Need to watch.

Horrifying, isn't it?

Amazing to me how little these companies respect the historic value of the transcripts. Most of my work is captured in them now.

I use https://usegitai.com/ and https://ctx.rs/ to preserve and search them.

Reply on news.ycombinator.com