Back to Feed
Agents

Linking Code and Prose for Coding Agents

Original: A Literate Programming Environment for Human and Machine Agents

Listen to the summary

Uses a voice available on your device

Audio options
On this page 4 sections
Related concepts 2 concepts

Key Takeaways

  • The notlob system uses a name-graph structure to connect prose and executable symbols for better agent navigation.
  • Bindings are currently provided for Haskell, Python, and TypeScript, allowing for project-specific language integration.
  • A Lark grammar is used as the foundational parser for the system.
  • The environment supports IDE-like functionality, such as jumping to type declarations or function callers via query commands.

Summary & Methodology Analysis

The notlob system addresses the fragmentation between documentation and implementation by co-locating prose and code within a single artifact. It utilizes a name-graph data structure that maps concept names to their corresponding code blocks and prose. This graph allows machine agents to perform navigation and consistency checks, functioning similarly to IDE shortcuts that resolve type declarations or identify function callers. The architecture relies on a Lark grammar to handle the parsing of these mixed-language artifacts. By maintaining this structured mapping, the system aims to provide coding agents with higher quality context than traditional file-based organization allows. The authors implemented language-specific bindings for Haskell, Python, and TypeScript to enable the system to bridge the gap between high-level specifications and executable code. The development of the notlob implementation and example projects was conducted using Claude Code, with the Sonnet and Opus models assisting in the construction process. This approach is intended to maximize the utility of information within the context windows of large language models (a deep learning model that predicts the next token in a sequence to generate text). However, the paper explicitly notes that experimental evaluation of this design is left for future work. A significant limitation identified by the authors involves platform-specific tooling. Development tools integrated into agents, such as grep commands used within Claude Code, frequently employ optimizations that can undermine the file-adjacency benefits of the notlob structure. These tools may restrict output in ways that degrade the effectiveness of the system for machine agents.

Interactive System Flowchart

Click diagram to expand and zoom

Cross-Examination & FAQs

A deeper dive clarifying mechanics, constraints, and baseline evaluations.

Q1. What is the primary goal of the notlob system?

The goal is to manage context and consistency across natural language specifications and code by co-locating them in a single artifact.

Q2. Which programming languages are currently supported?

The system includes implemented bindings for Haskell, Python, and TypeScript.

Q3. Has the system undergone experimental performance evaluation?

No, the paper focuses on design and example programs, leaving experimental evaluation to future work.

Q4. How does the name-graph function for coding agents?

It acts as a navigable structure that allows agents to perform operations similar to jumping to type declarations or function callers in an IDE.

Q5. What is the role of the Lark grammar in this system?

A Lark grammar is used as the basis of the parser for the notlob implementation.

Q6. Which models were used to assist in building the implementation?

The project was built using Claude Code with the Sonnet and Opus models.

Q7. What is a known limitation regarding current development tools?

Some tools, such as grep commands, use optimizations that can restrict output and undermine the context sharing advantages of notlob file adjacency.

Q8. Does the system provide tools for checking consistency?

Yes, the system provides tools including check, build, weave, and query commands to navigate and verify the name-graph.

Q9. Are there specific metrics provided for the efficiency of the name-graph?

The paper does not provide quantitative metrics for the efficiency of the name-graph.

Flag an issue

What is wrong with this summary?

What is wrong?