jay-baleine
Joined 1 year ago
Karma
32
Submissions
6
Member since
Sep 6
https://banes-lab.com/
System Architecture · Infrastructure · Research & Development
View on Hacker NewsRecent submissions
Comment · 1 month ago
Hi HN,
I created Bane's Lab hoping to help developers use their LLMs more efficiently and in a more structured way, so the code the model writes complies with their own standards. Most material on the topic covers prompts, tips and best practices. This site covers the process around them: how to plan the work with the model, how to automate the governance around it, and how to steer the output until it passes your checks.
Work with a model tends to start at the doing: it writes code in its first reply, guesses the goal, and each later reply answers the previous one instead of the task. The method gives every piece of work the same shape, a loop of ten steps from understanding the request to verifying the result, at every size from a one-line fix to a plan that runs for weeks. It splits the work between three parties: the tooling detects problems and repairs what it can, the model repairs what the tooling reports, and the developer decides what the work is for. Rules live in the project as checks instead of in the conversation, where they fade as the session grows.
It's free to read, and each chapter is written as practical lessons you can apply to your own project:
1. Start: how to write the behavior document your agent reads first, with one named line per rule so a correction lands on a name, and how to set the method up in a new project from a template and one file of project details.
2. Plan: deciding whether work is worth doing before you start it, writing the plan as a dependency graph with a check between phases, when the model should stop and ask, and what to do when two rules apply to the same line of code.
3. Build: how the tooling detects, reports and repairs a problem, why the check is written before the code it guards, and why a check should match the shape of a mistake instead of one library's spelling of it.
4. Verify: why "it looked right" isn't evidence, how to test a check before you trust its results, why an unknown result is not a pass, and how to hold documentation to the same checks as code.
5. Collaborate: agents written as contracts instead of personas, and several agents coordinating through shared files with one writer per record.
6. Ship: running every tool through one chain of commands, deploying as a file operation with a way back, and declaring the gaps your checks can't cover.
Beyond the chapters, the PAG page teaches how to write agent instructions in Pattern Abstract Grammar, a structured format defined by a formal grammar, with a guide, patterns and templates to start from. The architecture page shows how anti-patterns form in code a model writes and how to turn an architectural intent into a condition a check can decide, and the ontology collects every principle behind it with its relations and repairs. The anatomy page then shows the method at work on the site's own source.
Every page is also served as Markdown and JSON, so you can point your model at a chapter and work through it on your own project.
Feedback is welcome, especially on parts that are unclear or that don't match how you work with these tools.
Repo of the methodology: https://github.com/Varietyz/Disciplined-AI-Software-Developm...
Comment · 1 year ago
Your four points are correct:
1. Symbol mapping: Yes - ƒ → def, ∀ → for, λ → lambda, π → print, etc. Custom mappings are configurable.
2. Multi-layer caching: Confirmed - source content cache, transpiled Python cache, module import specs, and optimized bytecode with batch writes.
3. PhiRust acceleration: Clarification - it's a Rust-based transpiler that handles the symbol-to-Python conversion for performance, not converting Python to Rust. When files exceed 300KB, the system delegates transpilation to the Rust binary instead of using Python regex processing.
4. HTTP API: Yes - provides endpoints for transpilation, symbol mapping queries, and engine info to enable IDE integration.
The technical decision to use string replacement over AST manipulation came down to measured performance differences.
The benchmarks show 3,000,000+ chars/sec throughput on extreme stress tests and 1,200,000+ chars/sec on typical workloads. Where AST parsing, transformation, and regeneration introduces overhead that makes real-time symbol conversion impractical for large codebases.
The string replacement preserves exact formatting, comments, and whitespace while maintaining compatibility with any Python syntax. Including future language features that AST parsers might not support yet. Each symbol maps directly to its Python equivalent without intermediate representations that can introduce transformation errors.
The cache system includes integrity validation to detect corrupted cache entries and automatic cleanup of temporary files. Cache invalidation occurs when source files change, preventing stale transpilation results. Batch write operations with atomic file replacement ensure cache consistency under concurrent access.
The runtime serves cognitive improvements for domain-specific development. Mathematical algorithms become more readable when written with actual mathematical notation rather than verbose keywords. It can help in game development, where certain functions can benefit from different naming (eg.: def → skill, def → special, def → equipment).
The gradual adoption path matters for production environments. Teams can introduce custom syntax incrementally without rewriting existing codebases since the transpiled output remains standard Python. The multi-layer caching system ensures that symbol conversion overhead doesn't impact execution performance.
Domain-specific languages for mathematics, finance, education, or any field where visual clarity improves comprehension. The system maintains full Python compatibility while enabling cognitive improvements through customizable syntax.
Comment · 1 year ago
What tends to get overlooked is the actual development speeds these projects achieve.
The PhiCode runtime for example - a complete programming language with code conversion, performance optimization, and security validation. It was built in 14 days. The commit history provides trackable evidence; manual development of comparable functionality would require months of work as a solo developer.
The "more work" claim doesn't hold up to measurement. AI generates code faster than manual typing while systematic constraints prevent the architectural debt that creates expensive refactoring cycles later. The 5-minute setup phase establishes foundations that enable consistent development throughout the project.
On scalability, the runtime demonstrates 70+ modules maintaining architectural consistency. The 150-line constraint forced modularization that made managing these components feasible - each remains comprehensible and testable in isolation. The approach scales by sharing core context (main entry points, configuration, constants, benchmarks) rather than managing entire codebases.
Teams can collaborate effectively under shared architectural constraints without coordination overhead.
This isn't about training wheels or learning syntax. The methodology treats AI as a systematic development partner focused on architectural thinking rather than ad-hoc prompting. AI handles syntax perfectly - the challenge lies in directing it toward maintainable, scalable solutions at production speed.
Previous attempts at structured AI collaboration may have failed, but this approach addresses specific failure modes through empirical measurement rather than theoretical frameworks.
The perceived 'strictness' provides flexibility within proven constraints. Developers retain complete freedom in implementation approaches, but the constraints prevent common pitfalls like monolithic files or tangled dependencies - like guardrails that keep you on the road.
The project examples and commit histories provide concrete evidence for these development speeds and architectural outcomes.