Repository Is Your Swarm

A self-hosting developer turned their Gitea repository into an autonomous software development system by connecting Google's Antigravity AI agents in headless mode, enabling scheduled agents to analyze code, open pull requests, and build a merge queue, resulting in a surge of PRs that overwhelmed CI/CD pipelines. The developer reported the system has been running for less than a week and described the experience as 'bingeineering.'

Posted on 8/20/2026, 10:18 PM I’ve written before about why I love self-hosting software: real data ownership, total independence, and never having to answer to changing terms of service. But recently, plugging headless AI agents directly into my self-hosted Gitea setup turned my repository into something completely unexpected: my own software Dyson Sphere. The Sanctioned Spark: Headless Antigravity It started innocently enough. While browsing the Google docs for Antigravity, I stumbled upon a piece of information that immediately set off lightbulbs: agy can officially be run in headless mode https://antigravity.google/docs/cli/headless . Here is what struck me: Note:Headless mode uses your cached credentials. Authenticate once with an interactive agy session first. In a non-interactive environment with no terminal for example, CI , a run that is not already authenticated exits with an authentication required error instead of hanging. Hmm, "for example, CI"... That got the wheels turning. As a self-hoster I immediately thought about how I could connect it to my Gitea instance. I already have the k8s system backing things, so adding new secrets and writing the Dockerfiles for the new images for the agent runner containers was as simple as telling Antigravity to do it. From there, I set up an action to trigger an agent task on specific repository events. Just the simple, probably first thing you would think of, run an agent on an issue with an "agent" label. That single action was the first solar panel in what would quickly become a Dyson Sphere surrounding my codebase. The Lightbulb Moment: Autonomous Self-Improvement Once the basic action was working, I had a realization: Why wouldn't I have a scheduled action whose only job is to find something to improve and open a PR? So Antigravity created one. Currently, the action runs twice a day, but it's basically autoresearch https://github.com/karpathy/autoresearch , right? Twice a day, a scheduled headless agent will spin up, analyze the repo, find a refactoring opportunity or missing test, write the code, and submit a tidy PR. It was over for me. Not in the "oh no, my job is over" sense. I developed a new term for it: bingeineering. My downfall had begun, this was just too cool. So, down the road of adding similar agent pipelines across repos, agents starting work on issues, responding to requests for changes in PRs, merging those PRs when approved. I would normally work very closely with LLMs, and these are running YOLO'd in their containers. With these agents being able to run unrestrained the work kept keeps? It hasn't stopped coming. As any software engineer knows, solving one bottleneck immediately reveals the next one. There is always more work. The Bottleneck: From PR Overload to Merge Queues So now I had a different problem: too many pull requests . My CI/CD pipelines were becoming the bottleneck. While they never had great timings, when it was basically me by myself it was not the worst thing. But suddenly I have a team that needs to get work across the line Each PR merged to main means every other open PR needed to be merged/rebased/what have you CI requires latest main , causing a cascade of re-runs and endless pipeline queues. Since issues in my repo were already wired up to dispatch agents automatically, I did what any reasonable developer living in the future would do: I opened an issue asking the agents to build a merge queue system for the repository. It hit me right then: I’m actually building software again And I love that I'm seeing the future future. CLI agents are so... slow? Is that possible? They just made me some multi-x engineer, like, within the last year I've been bingeineering does that work? I don't know what else to call staying up late like I'm a teenager again, staring at code with this Sphere for less than a week. Is this Gas Town https://github.com/gastownhall/gastown ? Not quite. I still read, review, and approve the PRs going into my codebases. It is just really insightful for what I imagine everyone doing by next year, and I'm already thinking about the future bottlenecks. History Repeating: From jQuery to React in Agent Swarms Why did this swarm architecture feel so familiar? I've been building on the web for over a decade at this point, and I'm seeing a parallel from those times: The Eventing Era jQuery & Backbone : Right now, my repository acts like early web apps. It's an event-driven mess where actions trigger events, which trigger agents, which emit more events. It works, but as it scales, tracing what triggered what becomes chaotic and impossible. Two-Way Data Binding Angular : The next phase in web history brought component models and two-way data binding, but brought with it infinite digest loops. I imagine the same case will happen with agents. Endless chatter and burnt tokens. One-Way Data Flow Flux / Redux : In Flux, components were banned from mutating state directly or talking to each other behind the scenes. Everything had to pass through a central dispatcher. For an agent swarm, "One-Way Data Flow" means banning side-channel agent chatter. Agent A can't trigger Agent B directly in an endless loop. Looking Ahead: Next Year? While building this Dyson Sphere around my codebase, I am accumulating some unique "agentic tech debt," but software development has always been about system design and managing complexity. If web history has taught me anything, it's that heavy eventing is just a stepping stone. In web frontends, we moved from event listeners to declarative views. In infrastructure, we moved from event scripts to Kubernetes reconciliation loops. The next real unlock is probably declarative. We won't trigger agents on events. We'll declare desired states, and a reconciliation loop will calculate the diff and dispatch the minimal agent steps needed to get us there. Maybe. Until then, I'm gonna keep bingeineering Did I coin it, yet? in the event storm. Maybe the swarm will help me figure it out.