Bart van de Lint

A coding-agent platform, judged by its pull requests

I built and run a self-hosted server where autonomous coding agents take GitHub issues to reviewed, CI-green pull requests. The platform's code is private, but its bot, 1-Bort-1, works in public: every number on this page links back to pull requests anyone can read.

181merged public pull requests
14public repositories
634reviews on public PRs
30 hmedian open to merge
4merged by other maintainers

One user: me. Every number here is my own use of the platform.

01Why

Why I built it

I maintain open-source Julia packages for airborne wind energy simulation with a few other maintainers. There was always more work than people. Letting agents loose produced changes nobody wanted to review.

What I learned

Building the tooling was the relatively easy part. The hard part is defining how the agent should work and write: its rules, the code standard its reviewer checks against, and the shape of a pull request description. Feedback from the developers reviewing its pull requests made me rework those instructions, and that made the biggest difference: a reviewer can now judge a change from the description alone.

02Output

Merged pull requests over time

Cumulative public pull requests, by merge date. One user: all of it is my use of the platform. Work in private repositories, mostly the platform building itself, is not counted.

Table view

Pull requests merged per week

Public pull requests by the week they merged, weeks starting on Monday. The last week runs to the snapshot date.

Table view

Where the public work landed

Merged pull requests per public repository: scientific Julia packages for simulating airborne wind energy systems, plus a data standard and a browser viewer.

Merged by me Merged by another maintainer
Table view

Time from open to merge

Merged public pull requests by how long each stayed open, from the draft pull request opening to its merge. That includes agent review, CI and my review.

Table view
03Loop

How a task runs

Every change goes through the same loop. Agents never merge; a person does.

  1. Issue

    An owner labels an issue, assigns the bot, or tags it in any thread. It becomes a task within a minute.

  2. Plan

    Before writing code the agent rewrites its acknowledgement into a plan on the issue, so a wrong plan is caught in a minute rather than in a pull request.

  3. Implement

    In its own git worktree, inside a systemd unit with memory, CPU and idle limits, read-only mounts and a scoped token. Claude Code or opencode.

  4. Test gate

    The repository's tests and rules pass locally, then a draft pull request opens with a card explaining the change.

  5. Agent review

    A second agent on the other harness reviews it, so the two don't share blind spots. Each finding goes back to the implementer.

    ↺ back to implement

  6. CI and conflicts

    The first red check's log, or a merge conflict with the base, goes back to the agent to fix.

    ↺ until green

  7. Human review

    Out of draft, my review is requested. My comments reach the agent like any other. A maintainer of the repository merges it.

    ↺ until approved

  8. After merge

    Checks on the default branch are watched for twelve hours. A red merge becomes a priority task whose pull request is the fix or a revert.

Quota failover

When a harness runs out of quota mid-task, the other writes a handover note from the stopped session and picks the task up in the same worktree.

Slack with approvals

A Slack assistant answers about the fleet. Anything that writes, such as opening issues or running a command, waits for a thumbs-up on the exact action.

Inside the API budget

The notification feed, one aliased GraphQL query per pass and git transport for merge checks keep the whole fleet under GitHub's rate limits.

04Pull requests

Merged by other maintainers

Pull requests accepted by people with no stake in the bot.

    Longest review threads

    Design-heavy changes that went through many rounds of review before merging.

      05Also mine

      OpenFastChat

      Bring-your-own-key AI chat

      My own product since June 2026. Every answer runs through an editable, shareable flow: a graph of processing nodes. It has its own tool-calling loop, web search and document grounding, context compaction and streamed responses, and runs on any OpenAI-compatible provider. Go and PostgreSQL backend, React and TypeScript frontend. Open core under AGPL, plus a hosted service.

      Data from GitHub as of 24 October 2026.