Practical lessons on building software with LLMs and automated governance

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...