Case study — shipped

Provenar

An autonomous engine that types an entire Python codebase and hands your team one reviewable PR. Strictly additive, collision-free by construction, and merged by maintainers who owed me nothing.

Status

Shipped · in production at CallMed AI

Public proof

11 PRs merged across 4 open-source projects

Delivery gate

0 pyright errors, confirmed pre-delivery

Scale

2,029 files mapped in one pass (LangChain)

Safety

Additive-only · Bouncer locks · kernel.log audit

The job nobody ever schedules

Every Python team I've talked to has the same task sitting at the bottom of the backlog, untouched for months: add type hints to the codebase. In plain terms, that means writing down, for every function, exactly what kind of data goes in and what comes out — so the editor can catch a mistake before it ships instead of after. Everyone agrees it would help. It would make the tools smarter, the autocomplete better, the warnings quieter. And nobody wants to spend three sprints of a senior engineer's time doing it by hand, because typing ten thousand functions is miserable, invisible work with no feature to show for it at the end.

That's the gap Provenar fills. It reads a Python codebase, works out what every function actually expects and returns, and hands your team one clean, reviewable pull request with the annotations already written. Your team reviews it and merges it themselves. I never touch your main branch.

(This project shipped under a different name first — Symbiote — until I discovered it collides with an existing, registered trademark in the same space. Renamed in August 2026. Same engine, same results below, just a name that's actually mine to use.)


How it actually works

Three steps. First, the engine reads the whole repository and builds a map of how every file depends on every other file — so it knows, for any single change, exactly what else in the codebase could be affected. On the LangChain project, that mapping pass covered over two thousand files in one run. I hand that map over for free before anyone pays me anything, so a prospective client can see exactly what's missing before committing to a thing.

Second, an AI agent walks that map and writes the type annotations, one file at a time. The rule that matters most here: it only adds. It never rewrites logic, never touches a comment, never shortens a docstring. There's a hard check built in that blocks any write where an existing docstring would shrink by more than 20% — because I've seen what happens when a model rewrites a whole file under pressure to be fast, and it isn't pretty.

Third, delivery: everything happens on its own branch, and you get one pull request, checked to have zero type errors before it ever reaches you. If something goes wrong, the entire rollback is a single command.


The part that stops two AI agents from stepping on each other

The actual hard problem in letting AI agents edit a shared codebase isn't writing a plausible change. It's making sure two agents editing related files at the same time don't produce a merge that looks fine and is quietly broken.

I built a small system for this — I call it the Bouncer. Before any agent writes to a file, it has to be granted a lock, and that lock accounts for everything downstream that file could affect, not just the file itself. Every time a lock is requested, granted, or denied, it gets written to a log with nanosecond precision, and every run ends with one clear line: either everything stayed collision-free, or it didn't. Not a vague summary. A yes-or-no answer you can actually check.


The proof, because I don't think this should be taken on faith

Eleven pull requests, reviewed and merged by real maintainers on real open-source projects who had absolutely no reason to be kind to a stranger's bot: eight on mpfb2, a Blender plugin used by a real community (#377, #378, #380, #383, #384, #385, #390, #403), one on aeon, one on mellea, and one on pypsa-earth.

They merged these because the diffs were correct and boring — exactly what a type-annotation change is supposed to look like. In one internal test, the engine annotated its own codebase, producing over two thousand line changes across nineteen files without a single locking conflict.


What it deliberately doesn't do

Provenar v1 doesn't write docstrings, even though clients ask for it constantly. I tried building it, and found that full-file rewrites, under pressure to move fast, will sometimes quietly compress good documentation on large codebases without anyone noticing for months. That failure mode isn't acceptable, so the feature is waiting for a different architecture — one that edits at a much finer level instead of rewriting whole files. Shipping less felt like the right call, and I still think it was.


The one that didn't go my way

I'd rather link to the miss than pretend it doesn't exist. Here's what happened the one time this exact approach landed badly — it's the honest counterweight to everything above.


Working together

A full pass on a Python repository is $1,500 flat, delivered as one reviewable pull request within 72 hours of starting. The initial scan — the dependency map, the free part — is read-only and comes with a fixed quote. Details at callmedai.com.


PatchwardQG-Synthesis Engine