A Python agent harness that turns database engineering tasks into Git patches through repository scouting, tool-driven edits, SQL probes, and evidence-based review.
Database changes must preserve more than query syntax: result grain, NULL behavior, ordering, concurrency, and caller contracts can all affect correctness. An agent needs repository evidence, runnable checks, and a controlled way to finish within a time and cost budget.
Developed the Python execution harness around an LLM-driven database engineering agent, including repository tools, database probes, context management, submission review, and Git patch delivery.
The harness accepts a problem statement in a checked-out repository. A read-only scout can supply a concrete edge case anchored to task and source quotes. The main agent iterates through code inspection, edits, shell checks, and SQL probes while a constraint ledger preserves requirements. Submission checks can return actionable feedback to the agent before the harness extracts and checks the final patch.
A source-derived view of a single Python harness: agent_main owns the run lifecycle, drive orchestrates the model/tool loop, and supporting components manage evidence, resources, and patch delivery.
Accepts problem_statement, uses the current repository, tracks time and estimated model spend, and reserves room for finalization. Default configuration targets a $1 cost ceiling and a 1,500-second wall-clock allowance; these are configurable limits, not measured run costs.
Handles model requests, usage accounting, bounded retries, and optional fallback models. The ledger retains task constraints and is reintroduced after edits; transcript trimming drops older bulky tool output while preserving retained messages.
Provides file reading, search, edits, file creation, shell execution and polling, SQL execution, and submission. Git tracks the working diff; subprocess output is bounded and background jobs are collected or stopped.
A separate read-only model pass looks for a concrete case before editing. Task and production-code quotes are checked against their sources before the case is handed to the writer. The scout is skipped when its budget or time thresholds are not met.
Discovers reachable PostgreSQL and ClickHouse connections. With the default SQL guard enabled, PostgreSQL probes are wrapped for rollback and ClickHouse probes are restricted to read statements. Child-process limits, memory monitoring, and cache cleanup constrain execution overhead.
Collects baseline and changed-code findings, checks declared patch shape and names, records executed checks, and reviews the diff against retained constraints when resources allow. Findings can send the writer back for another edit.
Capture the repository baseline and problem statement; start budget tracking, resource monitoring, baseline checks, and database discovery.
When admitted, run the read-only scout and validate its source anchors. Assemble the writer context and extract a constraint ledger.
The writer calls repository, shell, and SQL tools. Tool results feed the next model turn; requirements remain visible as older output is trimmed.
On submit, inspect patch shape, code findings, test evidence, and task constraints. If a check holds submission and budget remains, return to the edit loop.
The default path keeps a single draft. Optional modes can generate additional candidates and choose by agreement or medoid similarity; an optional example-test pool can help distinguish drafts.
Stop background jobs, capture the diff, restore the repository, trim excluded artifacts, and check patch applicability. Attempt salvage when needed, then return the patch string and log the final status.
Review feedback → another edit and focused check → submit again, while the remaining budget permits.
Submission checks are resource-aware and may stand down near the deadline; a returned patch is not proof that all tests passed or that applicability was confirmed. Dependency shims can support test collection but are not equivalent to testing against the real dependency. SQL and subprocess controls are harness safeguards, not a security sandbox. The source does not establish the reported 36% solve rate; benchmark results and evaluation details are still needed to substantiate it.
The implementation balances evidence gathering against limited time and spend, separates pre-existing test failures from change-related findings, retains requirements when tool output is trimmed, and handles model timeouts and long-running subprocesses. Database probes use engine-specific restrictions, while finalization reserves time for cleanup and patch applicability checks.
Reported results supplied for this portfolio; not independently verified. Evaluation datasets, sample sizes, and measurement periods have not been provided.