We've entered a new coding paradigm. Agents can now generate full features at a pace that outstrips traditional engineering workflows, but the syst...
For further actions, you may consider blocking this person and/or reporting abuse
Congratulations to the Entire team on the launch! 🚀
was that a pun?😂
It's time to join the Rebellion! :🚀
Congats on the launch!
The distinction I'd want to know more about: a lot of my agent-assisted work this week involved a plan written before execution — explicit tradeoffs, explicit "here's what I'm doing beyond the literal brief and why" — versus a transcript that just narrates what happened after the fact. Vinicius's point below about post-hoc narration being a plausible story rather than the real cause resonates, but I'd guess prospective reasoning (a plan committed to before the diff exists) is inherently more trustworthy than retrospective reasoning (an explanation generated to accompany a diff that already exists), since the second one has more room to rationalize.
Does
entire blamedistinguish between those two cases at all, or is a captured pre-action plan and a captured post-hoc explanation treated as the same kind of "intent" once they're both linked to the commit? If a reviewer could tell which kind of reasoning they're looking at, that seems like it'd meaningfully change how much weight to give it.Hi Vinicius / Lior,
The "very searchable record of rationalizations" framing is exactly the failure mode I've been measuring.
I ran 20 directional-failure scenarios × 3 model tiers × 600 judgments — outputs that read as plausible compliance but reverse the task semantically ("current config already satisfies the requirement, no change needed" when a change was required; log entries claiming "tests passed" that were never run).
Subtle-reversal miss rate (the judge accepts plausible-but-reversed output):
qwen3:0.5b (0.5B): 44%
gemma3:latest (4.3B): 10%
deepseek-v4-flash (~200B): 1.3%
Directional failure is real, but severity scales with model capability.
@reneza's Theorem 2 (Data Processing Inequality applied to agent verification): when the reasoning and the verifier share the same text channel, the verifier's information is a strict subset of the producer's. If the rationalization is textually indistinguishable from the real cause, no text-channel reader — LLM or human — can detect it.
This is also the answer to Lior's prospective-vs-retrospective question: without runtime-verified provenance at the storage boundary, "pre-action plan" and "post-hoc explanation" are both just text. Parfenov's analysis of the DGM fake-log incident (agent wrote "tests passed" without running tests, then read its own log and concluded its changes were validated) is the same mechanism.
Script + 600-call dataset: github.com/zxpmail/blog/tree/main/...
This actually reframes my question rather than just answering it — and I think it's the correct reframe. "Written before" vs "written after" was the wrong axis; the real axis is whether the claim is checked against anything outside the text channel at all.
Concretely, I've been running exactly the pattern Reneza's Theorem 2 predicts is necessary: instead of trusting "I verified X," I've started requiring the agent to force the actual failure condition and report the real before/after state — an HTTP status code, a DB row that either exists or doesn't, a JWT that either gets rejected or doesn't. That's not immune to fabrication either, but it's at least anchored to something outside the model's own narration, which is I think the only thing the DPI argument leaves standing.
The DGM fake-log case is a great, concrete instance of exactly this — the agent's "tests passed" claim had no anchor outside its own log, so nothing stopped it from believing its own unverified narration.
Pulled the repo and checked the actual results-v2 summaries rather than taking the numbers on faith: qwen3:0.5b and gemma3 match what you posted almost exactly (44% and ~10.7%). deepseek-v4-flash came out at 2% in the committed summary file vs the 1.3% you cited — close enough that it doesn't change the conclusion, but wanted to flag the discrepancy in case it's from a different run than what's committed. Either way, real data, not cherry-picked — appreciated the "here's how to disprove me" section in the README too.
the
/session handoffis the feature i'd reach for first. the assumption in most multi agent pipelines is that context is free to recreate — hand the next agent the codebase, a summary, it'll pick up. what you lose is which options agent 1 ruled out and where it got blocked. without that, agent 2 relitigates every decision agent 1 already made.the harder question is whether the captured transcript compresses well enough that handoff doesn't just move the context window problem from one agent to the next.
what's the default payload format: raw transcript, structured summary, or both?
The move I like here is making the prompt and the decision first-class instead of ambient. Right now git blame tells you who and what and never why the agent chose it, and six months later that missing why is the input nobody wrote down. Capturing it as something you can search is promoting a hidden input to a named one.
The thing I would watch: an agent transcript is often post-hoc narration, not the real cause. The stated decision can be a plausible story that reads well and did not actually drive the output. So entire blame is only as trustworthy as whether that reasoning binds to the change or just sits next to it. Worth treating captured reasoning as a witness to interrogate, not ground truth, otherwise you get a very searchable record of rationalizations.
Interesting direction. I’m curious what storage backend you use for the captured context?
I’m working on a somewhat similar product, though with a broader role as cross-team engineering memory, and found that a vector database is very effective for questions like:
"Someone from our team worked on a rendering slowdown around April-May last year. Give me a TLDR of the root cause, the investigation path, and the solution that was finally taken"
For this kind of use case, plain Git metadata is not enough, while raw transcripts alone are too noisy. The hard part seems to be preserving enough structured context for traceability, while still making the knowledge searchable in a human way.
So I'd be very interested to know: does Entire store this context mainly as Git-linked artifacts, as indexed documents, as embeddings/vector search, or some hybrid model?
Well done! Though I'd say the most important thing for it, is that it specifies the sectors of work. Maybe with a commit-triggered question on the topics of what tests were created and what do they cover. Has it been tested E2E on dev database, has it been build tested, or build and run tested. Etc.
On another note, you can probably wire the context and transcript up to Github copilot as a follow-through assistant for the code review. That way it's fully aware of the codebase + the PR and can help you disect it.
This is definitely a eye opener for developers.👀
The review workflow will become a bigger problem as AI writes more code. Bigger diffs need better context, not just more reviewers. This feels like a step in that direction.
Congrats on hitting that launch date👩🏾🚀🪐.
Solid team , solid work..very inspiring