frmoretto

• frmoretto 14 Jan 2026 15:39 UTC

  1 point

  0

  in reply to: omegastick’s comment on: Cod­ing Agents As An In­ter­face To The Codebase

  With great pleasure! The experience was so revealing that led me to codifying the process and prepare the Stream Coding Manifesto (available on GitHub here: Stream Coding), just launched last month btw.

  I’ve also created the relative Claude Skill in order to make it immediately actionable, downloadable as well via GitHub.

• frmoretto 13 Jan 2026 19:58 UTC

  2 points

  0

  on: Cod­ing Agents As An In­ter­face To The Codebase

  The “attack dog” metaphor is definitely sticky but personally I’ve found that you can build the fence directly INTO the task definition, so the dog runs free but in a “directed” and “constrained” path.

  When context is ambiguous and objective (the “why”) isn’t clear enough, it doesn’t matter how much the model is smart, problems are going to arise and technical debt is certain. If you invest in complete and crystal-clear specs your chances that the plans come out right increases in a significant way (the so called Context Engineering).

  I ran this as an experiment: I’ve invested about 80% of my time into specs building, then code generation became literally automatic. As a result Claude produced 7 modules (46 endpoints) in 4.5 hours (including testing), and the code was virtually bug free and production-ready. The spec was so complete and all hard decisions already made that Claude didn’t have to guess, having in this way more time to do the right things instead wasting time in trying to decide a course (a task where it’s often wrong).

  Of course you lose the vibe coding exploration, but that experience moves upstream: into the process of spec-building. The hard thinking still happens, but just earlier and with a sizable prize: predictability and peace of mind for the “day two” onward.

• frmoretto 10 Jan 2026 11:21 UTC

  1 point

  0

  in reply to: Dhruv Trehan’s comment on: Why LLMs Aren’t Scien­tists Yet.

  Hi @Dhruv Trehan, thanks for the honest breakdown. I’ve personally experienced how complex and definitely not straightforward this topic could be. For example, even the allegedly more trivial parts (e.g authors metadata) have seen deep changes over time and are sometimes full of peculiarities or clear errors (due to sloppy formatting or when converted from LaTeX).

  I’ve prepared in the last weeks an online platform that parses ar5iv HTML (and ArXiv HTML for recent papers) in order to create a “meaningful skeleton” for each paper and cross-reference the context (the distilled paper’s text + claims + equations) against figures. It’s still in beta but the first outputs are interesting. The idea is to have a super-compact package (50/​60 KB for each paper including figures interpretation) that can be given with confidence to LLMs without losing all the precious context that is embedded troughout the length of the full paper.

  Given your direct experience I’d be very happy if you can take a look at it and give me your honest opinion, the url is: arxiparse.org

Pre-Inges­tion: An Over­looked Source of RAG Hallucinations

Clar­ity Gate: Open-Source Epistemic Qual­ity Ver­ifi­ca­tion for RAG Systems

• frmoretto 8 Jan 2026 20:31 UTC

  2 points

  0

  on: Why LLMs Aren’t Scien­tists Yet.

  A quick practical question: you said that the agent behind idea generation processed more than 135 papers and I presume that most of them are equation-heavy. How did your agents handle the math?

  I’ve been working on the same problem: when papers are transformed in PDF equations aren’t always available as structured math. If they’re treated as images in extraction they become hard to understand and to put in context by LLMs.

  Have you used LaTeX source or ar5iv HTML? Or just hope that the surrounding text carried enough signal?