Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Deterministic, machine-readable context for TypeScript codebases

github.com

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Show HN: Deterministic, machine-readable context for TypeScript codebases

#11

Post by verdverm »

AmiteK wrote: post #10
verdverm wrote: post #8

Earlier quoted context omitted.

As soon as you involve the agent and having it make tool calls, it is no longer deterministic This is in fact the very reason I set out to build my own agent, because Copilot does this with their `.vscode/instruction/...` files and the globs for file matching therein. It was in fact, not deterministic like I wanted. My approach is to look at the files the agent has read/written and if there is an AGENTS.md in that or…

I think there’s a conflation here between artifact determinism and agent behavior. LogicStamp’s determinism claim is about the generated context: same repo state + config ⇒ identical bundles. That property holds regardless of how or when an agent chooses to read them. Tool calls don’t make the artifacts non-deterministic; they only affect when an agent consumes already-deterministic output.

LSP is equally deterministic in that regard and more token efficient

Can you address the token inefficiencies from having to make more tool calls with this method?

Re: Show HN: Deterministic, machine-readable context for TypeScript codebases

#12

Post by AmiteK »

verdverm wrote: post #11
AmiteK wrote: post #10

Earlier quoted context omitted.

I think there’s a conflation here between artifact determinism and agent behavior. LogicStamp’s determinism claim is about the generated context: same repo state + config ⇒ identical bundles. That property holds regardless of how or when an agent chooses to read them. Tool calls don’t make the artifacts non-deterministic; they only affect when an agent consumes already-deterministic output.

LSP is equally deterministic in that regard and more token efficient Can you address the token inefficiencies from having to make more tool calls with this method?

On tool-call overhead: in the MCP flow it’s typically 1–2 calls per task (watch_status once, then read_bundle for the relevant slice). In watch mode we also skip snapshot refresh entirely.

Token-wise, the intent isn’t “dump everything”. it’s selective reads of the smallest relevant bundles. If your workflow already achieves what you want with AGENTS.md + LSP querying, that may indeed be more token-efficient for many sessions.

The trade-off LogicStamp is aiming for is different: verifiable, diffable ground-truth artifacts (CI/drift detection/cross-run guarantees). Tokens aren’t the primary optimization axis.

Re: Show HN: Deterministic, machine-readable context for TypeScript codebases

#13

Post by verdverm »

AmiteK wrote: post #12
verdverm wrote: post #11

Earlier quoted context omitted.

LSP is equally deterministic in that regard and more token efficient Can you address the token inefficiencies from having to make more tool calls with this method?

On tool-call overhead: in the MCP flow it’s typically 1–2 calls per task (watch_status once, then read_bundle for the relevant slice). In watch mode we also skip snapshot refresh entirely. Token-wise, the intent isn’t “dump everything”. it’s selective reads of the smallest relevant bundles. If your workflow already achieves what you want with AGENTS.md + LSP querying, that may indeed be more token-efficient for many…

I'm not sure the comparison I'm hoping to draw out is coming through

This seems more similar in spirit to AGENTS.md than LSP, so I'll make the comparison there. Today, I require zero tool calls to bring my AGENTS.md into context, so this would require me making more tool calls, each of is a round trip to the LLM with the current context. So if I have a 30k context right now, and you are saying 1-2 calls per task, that is 30-60k extra tokens I need to pay for, for every one of these AGENT.md files that needs to be read / checked to see if in sync.

I use git for the verifiable / diffable ground truth artifacts. I can have my LSP query at different commits, there is no rule it can only access the current state of the code

Re: Show HN: Deterministic, machine-readable context for TypeScript codebases

#14

Post by AmiteK »

verdverm wrote: post #13
AmiteK wrote: post #12

Earlier quoted context omitted.

On tool-call overhead: in the MCP flow it’s typically 1–2 calls per task (watch_status once, then read_bundle for the relevant slice). In watch mode we also skip snapshot refresh entirely. Token-wise, the intent isn’t “dump everything”. it’s selective reads of the smallest relevant bundles. If your workflow already achieves what you want with AGENTS.md + LSP querying, that may indeed be more token-efficient for many…

I'm not sure the comparison I'm hoping to draw out is coming through This seems more similar in spirit to AGENTS.md than LSP, so I'll make the comparison there. Today, I require zero tool calls to bring my AGENTS.md into context, so this would require me making more tool calls, each of is a round trip to the LLM with the current context. So if I have a 30k context right now, and you are saying 1-2 calls per task, tha…

I think we’re optimizing for different constraints. If your goal is zero extra round trips and you’re happy with AGENTS.md auto-injection + LSP queries, then I agree LogicStamp won’t be a win on token cost for that setup.

The AGENTS.md comparison isn’t “same thing” - it’s a different layer. AGENTS.md encodes human intent/heuristics. LogicStamp generates semantic ground-truth contracts (exports, APIs, routes) from the AST so they can be diffed and validated mechanically (e.g. CI drift detection).

Git + LSP can diff/query source across commits, but that’s still a query workflow. LogicStamp’s goal is a persistent, versioned semantic artifact. If your workflow already covers that, then it may simply not add value - which is totally fine.

Re: Show HN: Deterministic, machine-readable context for TypeScript codebases

#15

Post by verdverm »

From the readme

> Pre-processed relationships - Dependency graphs are explicit (graph.edges) rather than requiring inference

I suspect this actually is the opposite. Injecting some extra, non-standard format or syntax for expressing something requires more cycles for the LLM to understand. They have seen a lot of Typescript, so the inference overhead is minimal. This is similar to the difference between a Chess Grandmaster and a new player. The master or llm has specialized pathways dedicated to their domain (chess / typescript). A Grandmaster does not think about how pieces move (what does "graph.edges" mean?), they see the board in terms of space control. Operational and minor details have been conditioned into the low level pathways leaving more neurons free to work on higher level tasks and reasoning.

I don't have evals to prove one way or the other, but the research generally seems to suggest this pattern holds up, and it makes sense with how they are trained and the mathematics of it all.

Thoughts?

Re: Show HN: Deterministic, machine-readable context for TypeScript codebases

#16

Post by AmiteK »

verdverm wrote: post #15

From the readme > Pre-processed relationships - Dependency graphs are explicit (graph.edges) rather than requiring inference I suspect this actually is the opposite. Injecting some extra, non-standard format or syntax for expressing something requires more cycles for the LLM to understand. They have seen a lot of Typescript, so the inference overhead is minimal. This is similar to the difference between a Chess Grand…

That’s a reasonable hypothesis, and I agree LLMs are very good at inferring structure from raw TypeScript within a local reasoning window. However, that inference has to be repeated as context shifts or resets.

The claim I’m making is narrower: pre-processed structure isn’t about helping the model understand syntax, it’s about removing the need to re-infer relationships every time. The output isn’t a novel language - it’s a minimal, explicit representation of facts (e.g. dependencies, exports, routes) that would otherwise be reconstructed from source.

Inference works well per session, but it doesn’t give you a persistent artifact you can diff, validate, or assert against in CI. LogicStamp trades some inference convenience for explicitness and repeatability across runs.

I don’t claim one dominates the other universally - they optimize for different failure modes.

Re: Show HN: Deterministic, machine-readable context for TypeScript codebases

#17

Post by verdverm »

AmiteK wrote: post #14
verdverm wrote: post #13

Earlier quoted context omitted.

I'm not sure the comparison I'm hoping to draw out is coming through This seems more similar in spirit to AGENTS.md than LSP, so I'll make the comparison there. Today, I require zero tool calls to bring my AGENTS.md into context, so this would require me making more tool calls, each of is a round trip to the LLM with the current context. So if I have a 30k context right now, and you are saying 1-2 calls per task, tha…

I think we’re optimizing for different constraints. If your goal is zero extra round trips and you’re happy with AGENTS.md auto-injection + LSP queries, then I agree LogicStamp won’t be a win on token cost for that setup. The AGENTS.md comparison isn’t “same thing” - it’s a different layer. AGENTS.md encodes human intent/heuristics. LogicStamp generates semantic ground-truth contracts (exports, APIs, routes) from the…

I think none of us know what we are doing with the new toy and are still trying to figure it out lol. So in some sense, there are a lot of ideas being offered, often in many shapes themselves. Just look to the agent sandboxing space

I still have a hard time seeing why I want something like this in my agentic or organic software development. I tried something nearly identical for Go, and having all that extra bookkeeping in context wrecked things, so on an experiential level, the custom DSL for giving the agent an index to the code base hurt overall coding agent performance and effectiveness.

What works far better is having very similar in content, but very curated "table of contents" for the agent. Yes, I also use the same methods to break it down by directory or other variables. But when it reads one of these, the majority is still noise, which is why overall performance degraded and why curation is such a difference maker.

Do you have evaluations for your project that it leads to better overall model capabilities, especially as they compare to a project that already uses AGENTS.md?

btw, I put this stuff in AGENTS.md now, you can put whatever you want in there, for example I auto generate some sections with Go's tooling to have a curated version of what your project does. I don't see it as a "different layer" because it is all context engineering in the end.

Re: Show HN: Deterministic, machine-readable context for TypeScript codebases

#18

Post by verdverm »

AmiteK wrote: post #16
verdverm wrote: post #15

From the readme > Pre-processed relationships - Dependency graphs are explicit (graph.edges) rather than requiring inference I suspect this actually is the opposite. Injecting some extra, non-standard format or syntax for expressing something requires more cycles for the LLM to understand. They have seen a lot of Typescript, so the inference overhead is minimal. This is similar to the difference between a Chess Grand…

That’s a reasonable hypothesis, and I agree LLMs are very good at inferring structure from raw TypeScript within a local reasoning window. However, that inference has to be repeated as context shifts or resets. The claim I’m making is narrower: pre-processed structure isn’t about helping the model understand syntax, it’s about removing the need to re-infer relationships every time. The output isn’t a novel language -…

> a persistent artifact you can diff, validate, or assert against in CI.

This is definitely something I don't see the value in. Why do I need to diff or look at this file in CI, it should be auto generated from the code, yea?

Why are git diffs insufficient? Models are trained on them and understand them very well. Google has some interesting research on having the models generate patches instead of code syntax directly.

I'm really not sure what pain or problem is being addressed here. Are there evals to show this concept improves overall model performance?

And to be honest, it's going to take a lot to convince me this is helpful when I can put a curated set of this same information in my AGENTS.md files I have all over my code base

> repeatability across runs

I definitely don't see how this holds up, or don't know what you mean. Are you implying your method creates repeatability if I run the same agent/LLM twice on the same input?

Re: Show HN: Deterministic, machine-readable context for TypeScript codebases

#19

Post by AmiteK »

verdverm wrote: post #18
AmiteK wrote: post #16

Earlier quoted context omitted.

That’s a reasonable hypothesis, and I agree LLMs are very good at inferring structure from raw TypeScript within a local reasoning window. However, that inference has to be repeated as context shifts or resets. The claim I’m making is narrower: pre-processed structure isn’t about helping the model understand syntax, it’s about removing the need to re-infer relationships every time. The output isn’t a novel language -…

> a persistent artifact you can diff, validate, or assert against in CI. This is definitely something I don't see the value in. Why do I need to diff or look at this file in CI, it should be auto generated from the code, yea? Why are git diffs insufficient? Models are trained on them and understand them very well. Google has some interesting research on having the models generate patches instead of code syntax direct…

I think the disagreement is about where inference belongs, not whether LLMs are capable.

Git diffs + LLM inference work well for understanding changes once. What I’m targeting is reducing the need to re-infer semantic surface changes every run, especially across large refactors or long-running workflows.

Today, LogicStamp derives deterministic semantic contracts and hashes, and watch mode surfaces explicit change events. The direction this enables is treating those derived facts as a semantic baseline (e.g. drift detection / CI assertions) instead of relying on repeated inference from raw diffs.

By “repeatability” I mean the artifacts, not agent behavior: same repo state + config ⇒ same semantic model. I don’t yet have end-to-end agent performance evals versus AGENTS.md + LSP

Re: Show HN: Deterministic, machine-readable context for TypeScript codebases

#20

Post by verdverm »

AmiteK wrote: post #19
verdverm wrote: post #18

Earlier quoted context omitted.

> a persistent artifact you can diff, validate, or assert against in CI. This is definitely something I don't see the value in. Why do I need to diff or look at this file in CI, it should be auto generated from the code, yea? Why are git diffs insufficient? Models are trained on them and understand them very well. Google has some interesting research on having the models generate patches instead of code syntax direct…

I think the disagreement is about where inference belongs, not whether LLMs are capable. Git diffs + LLM inference work well for understanding changes once. What I’m targeting is reducing the need to re-infer semantic surface changes every run, especially across large refactors or long-running workflows. Today, LogicStamp derives deterministic semantic contracts and hashes, and watch mode surfaces explicit change eve…

> By “repeatability” I mean the artifacts

> Inference works well per session ... doesn't give artifact ... explicitness and repeatability across runs.

When you write this, it sounds like you are talking about repeatability between inference sessions and that this artifact enables that. It does not read that you are applying the repeatability to the artifact itself, which one assumes since it is autogenerated from code via AST walking

Post reply on HN