Author here. This started as my own frustration: I built a compiler along the lines Karpathy describes in his llm-wiki gist, fed it ~300 files of reading notes accumulated over twenty years, and got back something that looked like an encyclopedia written by a competent stranger. Accurate, well-formatted, philosophically sterile.
The piece argues that Karpathy's compiler frame solves the infrastructure half of the problem (ahead-of-time compilation beats just-in-time RAG) but leaves the architectural half open. Without an explicit governance layer, the compiler defaults to its training distribution and smooths everything into consensus. With one, it can be forced to do the opposite: extract structural claims rather than summarize, name antagonists, find friction points across your existing nodes.
I shared the schema and directory structure I use as an open-source template (linked at the end of the post). Curious whether others who've built something similar found different rules that matter, or whether the antagonist/friction directives feel too philosophical for what should be a pure engineering problem. The qaadika comment on the original llm-wiki thread is the strongest objection I tried to address.
One approach might be to set up two adversarial summarizers and a judge (like common-law litigation). Instead of using one model to identify and resolve all claims, a first model (plaintiff) seeks out the most supportive arguments for, and evidence of, claims across all nodes; then a second model (defendant) antagonizes the first by seeking out only disconfirming evidence and the best counter-arguments; the parties may get one or more replies or sur-replies; and then a third model (judge) evaluates the previous two against one another. The idea could be extended to incorporate appellate models that ensure compliance with the rules and propose changes to rules or addition/subtraction of rules. Appellate decisions could be maintained in a separate directory and accessed by the adversarial models.
More promising food for thought: developing and employing rules of evidence and procedure. For example, evidence may be taken only from immutable files; the first level nodes present issues, not summaries or syntheses; each issue has separate plaintiff, defendant, judge, and appellate nodes, from which a summary or explanation is ultimately created.
Author here. This started as my own frustration: I built a compiler along the lines Karpathy describes in his llm-wiki gist, fed it ~300 files of reading notes accumulated over twenty years, and got back something that looked like an encyclopedia written by a competent stranger. Accurate, well-formatted, philosophically sterile. The piece argues that Karpathy's compiler frame solves the infrastructure half of the problem (ahead-of-time compilation beats just-in-time RAG) but leaves the architectural half open. Without an explicit governance layer, the compiler defaults to its training distribution and smooths everything into consensus. With one, it can be forced to do the opposite: extract structural claims rather than summarize, name antagonists, find friction points across your existing nodes. I shared the schema and directory structure I use as an open-source template (linked at the end of the post). Curious whether others who've built something similar found different rules that matter, or whether the antagonist/friction directives feel too philosophical for what should be a pure engineering problem. The qaadika comment on the original llm-wiki thread is the strongest objection I tried to address.
One approach might be to set up two adversarial summarizers and a judge (like common-law litigation). Instead of using one model to identify and resolve all claims, a first model (plaintiff) seeks out the most supportive arguments for, and evidence of, claims across all nodes; then a second model (defendant) antagonizes the first by seeking out only disconfirming evidence and the best counter-arguments; the parties may get one or more replies or sur-replies; and then a third model (judge) evaluates the previous two against one another. The idea could be extended to incorporate appellate models that ensure compliance with the rules and propose changes to rules or addition/subtraction of rules. Appellate decisions could be maintained in a separate directory and accessed by the adversarial models.
More promising food for thought: developing and employing rules of evidence and procedure. For example, evidence may be taken only from immutable files; the first level nodes present issues, not summaries or syntheses; each issue has separate plaintiff, defendant, judge, and appellate nodes, from which a summary or explanation is ultimately created.
[dead]