Repository navigation
Home
LLM-assisted tooling for improving and generating Python code: find repositories, run static analysis and an LLM over their files, generate tests, and open a pull request on a fork.
This wiki carries the detail that does not fit in the README, and records the places where the README and the code have drifted apart. Verify anything here against the code if it matters, and read the gotchas before your first real run.
| Script | Role |
|---|---|
scraper.py |
The Finder. Searches GitHub for Python repositories matching size, quality and freshness criteria, and writes them to JSON |
iamnotacoder.py |
The Optimizer. The main tool: static analysis, LLM improvement, test generation, commit and pull request |
process.py |
The Orchestrator. Runs the Optimizer across everything the Finder produced |
create_app_from_scratch.py |
The Team. Generates a small application from a description, using several LLM roles |
- The Optimizer: the command, every flag as the code actually defines it, and what a run does step by step
-
Configuration and prompts:
config.toml, the prompt files, and a config format problem worth knowing about - Finder and Orchestrator: working across many repositories at once
- The Team: generating an application from a description
- Known gotchas: documented flags that do not exist, a first example that cannot work, and the safety rails to keep on
It clones a repository, changes source files with an LLM, commits, pushes and opens a pull request. That is a lot of authority to hand to a model.
The defaults are built for that: --fork-repo works on a copy in your own account, --dry-run performs the whole run and writes nothing, and --local-commit stops before the pull request. Use them in that order the first few times. The project's own status note says it plainly: this is experimental, LLM-assisted tooling, and generated code and pull requests should be reviewed before they go anywhere.