Software-as-a-Service gave us recurring revenue. Platform-as-a-Service gave us managed infrastructure. The next abstraction is obvious in hindsight: Profit-as-a-Service.

The Pattern

#

Every major shift in the software industry has been about abstracting away complexity.

On-premise servers became cloud infrastructure. Custom software became SaaS subscriptions. Manual operations became automation.

Each layer removes something the customer previously had to manage themselves. Each layer turns a cost center into a service. Each layer makes the underlying complexity someone else’s problem.

Profit-as-a-Service is the logical conclusion of this trend. Instead of selling software that helps you make money, you sell the money-making itself.

What It Looks Like

#

A traditional SaaS company sells you a tool. You still need to figure out how to use it to generate revenue.

A Profit-as-a-Service company sells you an outcome. The tool is invisible. The process is invisible. You pay for the result.

Examples already exist:

• Algorithmic trading platforms that let you deploy capital and collect returns without understanding the underlying strategies.
• AI-powered dropshipping services that handle product selection, listing, pricing, and fulfillment while you provide the capital.
• Automated content farms that generate SEO-optimized articles, monetize them with ads, and split the revenue with you.
• AI sales agents that prospect, qualify, and close deals on your behalf, charging only a commission on closed revenue.
• Robo-advisors that manage investment portfolios algorithmically, charging a fraction of traditional advisory fees.

In each case, the customer provides capital or data. The service provides everything else. Revenue is shared, not subscribed to.

Why Now

#

Three forces are converging to make Profit-as-a-Service viable at scale.

1. AI can now execute complex business processes autonomously

#

Large language models can write marketing copy, analyze markets, negotiate with customers, and generate code. Multi-agent systems can coordinate these capabilities into end-to-end business workflows. What previously required a team of specialists can now be done by a single API call chain.

2. Infrastructure is fully commoditized

#

Starting a business used to require incorporating, hiring, building software, and navigating regulations. Now you can spin up a fully operational e-commerce store in an afternoon using off-the-shelf tools. The barrier to entry for almost every digital business has collapsed to near zero.

3. Distribution is algorithmic

#

Social media algorithms, search engines, and ad platforms have made customer acquisition a math problem. If you can compute the expected value of an impression, you can acquire customers profitably at scale. AI is better at computing expected value than humans.

The Economics

#

The unit economics of Profit-as-a-Service are deceptively simple.

The service provider operates a system that generates revenue. The customer provides the input: capital, data, or access to a market. Revenue is split between the provider and the customer.

For the customer, the arrangement is attractive because:

• No upfront investment in tools or expertise.
• Risk is aligned (the provider only makes money if you make money).
• Scalability is built in (the system can run 24/7 without human intervention).

For the provider, the arrangement is attractive because:

• Revenue scales with customer success (no ceiling from fixed subscriptions).
• Customer acquisition is easier (pay-for-performance is an easy sell).
• Margins improve with scale (the same system serves many customers).

The critical metric is the spread between what the system generates and what it costs to operate. If a system generates $10,000/month per customer and costs $2,000/month to run, the provider can keep $4,000 and give the customer $4,000. Both parties are happy. The system scales linearly in cost but exponentially in value.

The Risks

#

Profit-as-a-Service is not without significant risks.

Alignment risk

#

When you outsource profit generation, you also outsource decision-making. The provider’s optimization target may diverge from yours, a textbook principal-agent problem. A trading algorithm might maximize short-term returns at the cost of long-term stability. A content farm might optimize for clicks at the cost of your brand reputation.

Concentration risk

#

If the service provider goes down, your revenue goes to zero. There is no fallback when the entire business process is a black box. Diversification across multiple providers becomes essential but difficult.

Regulatory risk

#

Financial services are heavily regulated. When you abstract away the details of money-making, you may also abstract away compliance. The line between “software service” and “financial service” is thin and getting thinner.

Race to the bottom

#

When the barrier to entry is low, competition drives margins toward zero. The first provider to offer automated dropshipping captures most of the value. The hundredth provider competes on price until nobody makes money.

Dependency trap

#

Once a business relies on Profit-as-a-Service, transitioning away is extremely difficult. The provider owns the process, the data, and the relationships. Switching costs are not just technical but operational and strategic.

The Spectrum

#

Profit-as-a-Service is not binary. It exists on a spectrum of how much of the profit-generating process is abstracted away.

Level 0: You do everything. You buy tools and operate them yourself. Traditional software.

Level 1: AI assists you. You use AI tools to accelerate specific tasks. Copilots and assistants.

Level 2: AI operates under your supervision. You define strategy, AI executes tactics. Current state of most AI-powered businesses.

Level 3: AI runs the process, you provide direction. You set constraints, AI handles the rest. Emerging today.

Level 4: AI runs everything, you provide capital. You fund the operation, AI decides how to deploy it. Algorithmic trading, robo-advisors.

Level 5: AI runs everything, including capital allocation. Fully autonomous business entities. Not yet real, but the trajectory is clear.

Most businesses today operate at Level 0 or 1. The opportunity is in moving up the spectrum.

Who Wins

#

The winners in the Profit-as-a-Service economy will be:

Platform providers who own the infrastructure that makes Profit-as-a-Service possible. If you operate the AI system that generates profit for thousands of businesses, you capture a slice of every dollar earned.

Capital providers who can efficiently allocate resources across multiple Profit-as-a-Service offerings. When starting a business requires no expertise, access to capital becomes the primary competitive advantage.

Specialists who can handle the edge cases that AI cannot. Regulatory compliance, strategic partnerships, and brand building remain human-dominated activities.

Arbitrageurs who identify Profit-as-a-Service opportunities before they become commoditized. The window between “novel” and “saturated” is shrinking, but the rewards for being early are enormous.

Who Loses

#

The losers will be:

Middlemen whose value proposition was information asymmetry. When AI can access and process all available information, intermediaries add no value.

Consultants who sold expertise that can now be codified. If your consulting practice can be reduced to a prompt, it will be.

SaaS companies that failed to move up the value chain. A CRM that helps you track sales will lose to an AI that makes sales for you.

Employees whose jobs consisted of executing repeatable business processes. This is the uncomfortable truth that applies across industries.

The Question

#

Profit-as-a-Service is not a prediction. It is a description of what is already happening.

The question for any business is not whether this trend will affect you. The question is whether you will be the provider or the customer.

If your business processes can be automated by AI, they will be. If you are the one automating them, you are the Profit-as-a-Service provider. If you are the one whose processes are being automated, you are about to become a customer.

Choose wisely.

Prompt

#

Write an article about Darwinian software development, the use of LLM swarms to identify the best solution to a problem.

Answer

#

In the traditional world of coding, software is “built.” An architect designs a blueprint, and developers lay the bricks. But in the era of Generative AI, we are moving toward a paradigm where software is evolved.

Darwinian Software Development is an emerging methodology that uses “swarms” of Large Language Models (LLMs) to iterate, compete, and select the most efficient code through a process mirroring natural selection.

How the Swarm Works

#

Instead of asking a single AI to write a function, Darwinian development deploys a multi-agent system (a swarm) to tackle the same problem from different angles. The process generally follows four biological phases:

• Variation (The Mutation): Multiple LLM agents are given the same prompt but with different “temperaments” or system instructions. One might prioritize memory efficiency, another readability, and a third raw speed.
• Competition (The Struggle for Life): The agents generate dozens of potential solutions. The solutions aren’t just checked for syntax; they are put into a “sandbox” to run against unit tests and edge cases.
• Selection (Fitness Function): An automated “Judge” agent (or a specialized testing suite) evaluates the outputs. Only the code that passes the most tests with the lowest latency or resource consumption “survives.”
• Heredity (Refinement): The winning code is then used as the “DNA” for the next generation. The swarm takes the best-performing snippet and attempts to optimize it further until a “perfect” solution is reached.

Why Swarms Outperform Single Models

#

The “Darwinian” approach solves the two biggest problems in AI-assisted coding: hallucinations and getting stuck on a single approach.

• Error Correction: If one agent introduces a bug, the likelihood that five other agents will make the exact same error is low. The swarm acts as a self-healing mechanism.
• Diverse Architectures: One LLM might get stuck on a specific logic path. A swarm explores the entire fitness landscape, finding creative solutions a human (or a single AI) might never consider.
• Performance Benchmarking: By racing agents against each other, the system naturally optimizes for performance.

The “Fitness Function” Problem

#

The biggest challenge in Darwinian development isn’t the AI; it’s the criteria. For natural selection to work, the environment must be rigorous. If your “fitness function” (the tests you use to judge the code) is poorly written, the AI will evolve to pass the test while still being technically broken. This failure mode is known as reward hacking. To counter reward hacking, modern swarms often include “Adversarial Agents” whose only job is to write difficult unit tests to try and “kill” the code generated by the other agents.

The Future: Software That Self-Improves

#

We are approaching a point where software won’t be static. Imagine a server that monitors its own performance and, upon detecting a bottleneck, spawns a Darwinian swarm to rewrite its own inefficient modules in real-time. In this new world, the developer’s role shifts from writer to naturalist. You aren’t typing the lines; you are defining the environment in which the best code can grow.

Imagine you can run hundreds or thousands of coding agents in parallel. How would you use them? The interesting answer is not “do everything faster”, but rather what fundamentally changes when parallelism is cheap.

From Sequential Exploration to Parallel Search

#

When you have one agent, you think carefully before acting, because going down dead ends is expensive. With thousands of agents, the trade-off reverses. Exploration becomes cheap, and convergence becomes the hard problem. Your job shifts from “what should I try?” to “how do I synthesize thousands of results?”

High-Leverage Use Patterns

#

Speculative execution on decisions. At every architectural fork, such as “should this be a queue-based system or polling?”, you do not decide, you branch. Two fleets of agents build both options, and you evaluate the results, borrowing the processor idea of speculative execution. This pattern is huge for situations where you genuinely do not know which approach is better until you have tried it.

Mutation testing at scale. Spin up hundreds of agents making targeted changes to a codebase, each trying a different hypothesis about why a bug exists or how to optimize something. It is like fuzzing, but semantically directed: instead of random inputs, each change probes a specific theory.

Full-stack consistency checking. Have agents simultaneously hold the contract between every pair of services in your system, constantly verifying that implementations match specs, that error handling is symmetric, and that naming is consistent. Sequential review often misses these checks.

Competitive benchmarking of approaches. For a problem like network latency or caching strategy, you could have 50 agents implement 50 different approaches against the same test harness, and just pick the winner. No reading papers and reasoning about tradeoffs, you settle the question empirically.

Living documentation. Agents continuously reconcile docs, comments, and code. Every pull request triggers agents that check for documentation drift, update runbooks, and surface inconsistencies.

The Harder Problems Cheap Parallelism Creates

#

Synthesis is the bottleneck. If 1,000 agents each produce a pull request, you are back to being the serial bottleneck reviewing them. You need meta-agents whose job is to evaluate and rank the output of other agents, with clear scoring functions.

State and conflict. Agents working in parallel on the same codebase will conflict. You probably want agents working in isolated sandboxes (branches, ephemeral clusters, test environments) with a merge or tournament layer on top.

Task decomposition quality matters more, not less. Bad task specs mean 1,000 agents going confidently in the wrong direction simultaneously. The skill of writing tight, evaluable task specs becomes enormously valuable.

Evaluation functions become critical. “Did the agent succeed?” needs a concrete, automated answer. You cannot manually review 1,000 outputs. That constraint pushes you toward test-driven development.

What This Implies For Infrastructure Work

#

The most compelling application is parallel experimentation on real infrastructure parameters. Spin up ephemeral environments, have agents try different configurations or scheduling strategies, measure actual performance, then tear the environments down. What makes infrastructure hard is that you normally cannot afford to run 50 experiments simultaneously. With cheap parallel agents managing the scaffolding, that constraint disappears.

The practical limit ends up being compute and money, not ideas, which is a fundamentally different world than the one most engineering workflows were designed for.

Things I want to learn about in 2026.

• CometML
• ML model profiling and optimization
• GCP GCS performance profiling
• NVIDIA MPS
• NVIDIA MIG
• NVIDIA time-slicing
• NVIDIA vGPU
• NVIDIA KAI scheduler
• NVIDIA run:ai

The weekly routine opens and closes the work week with LLM-generated summaries. I correct last week’s summaries at the start of the week and generate a new one at the end.

Trigger

#

At the beginning of every work week.

Duration

#

5 days.

Steps

#

Start of week

#

• Review and correct the LLM-generated summaries of last week’s activities.
• Weekly planning

Through the week

#

• Daily routine

End of week

#

• Generate an end of week summary using LLMs (LLM)
• Weekly review

Continuous learning only sticks for me when I treat it as a small set of manual habits repeated every day. Waiting for free time or motivation does not work, because busy weeks always win. Five simple practices are enough to keep learning moving.

My learning process

#

The process has five practices, and all of them are manual. Each practice is small enough to fit into a normal workday.

I collect articles shared on Slack that may be relevant to read. Shared links disappear quickly under newer messages, so grabbing the promising ones when I see them is the only reliable way to keep a reading pile.

I identify tools and resources that can help me improve my skills. A better tool or a better explanation makes the same amount of learning time worth more.

I set aside dedicated time for learning each day. The reserved time is what turns collected links and found resources into actual learning, because neither gets read or used without a protected slot in the day.

I experiment with new technologies and ideas. Trying an idea myself is the fastest way to find out whether the idea deserves more of my attention.

I identify areas for improvement in my current skills and knowledge. The identified gaps tell the other practices where to aim, so my effort goes to real weaknesses instead of to whatever topic happens to be easiest to find.

What to Do Next

#

Start with the smallest version of the process and grow it from there:

• Collect the next relevant article link you see shared on Slack, before the link scrolls away.
• Reserve a short, fixed block of time for learning every day, and treat the block as booked.
• Pick one gap in your skills, then find one tool, resource, or small experiment aimed at that gap this week.

This is the routine I follow on every work day, from catching up in the morning to planning the next day in the evening. Most steps are manual, but LLMs assist at fixed points: summarizing yesterday, writing code, and closing the day.

Trigger

#

Every day at the beginning of the (work) day.

Duration

#

8h.

Steps

#

Start of day

#

• Review and correct LLM generated summaries of yesterday’s activities
• Catch up on Slack messages (manual)
• Review PRs (manual)
• Standup (manual)

Throughout the day

#

• Go to meetings (some days) (manual)
• 1:1 (some days) (manual)
• Write code (mainly LLM assisted)
• Reply to Slack messages (manual)
• Review PRs (mainly manual, slightly LLM assisted)

End of day

#

• Continuous learning (manual)
• Generate an end of day summary using LLMs (LLM)
• Daily review (manual)
• Review weekly plan and align (manual)
• Plan next day (manual)

What is Ouroboros?

#

Ouroboros is an autonomous AI agent that works on the tasks you give it and continuously improves itself. It is named after the ancient symbol of a serpent eating its own tail (representing infinity and cyclic renewal), and it implements a continuous loop of Do → Learn → Improve → Retry.

Unlike traditional AI assistants that wait for commands and forget context between sessions, Ouroboros:

• Runs indefinitely without human intervention
• Maintains persistent memory of everything it has done
• Reflects on its performance regularly
• Modifies its own code to improve over time
• Can incorporate human feedback when provided

Previously I wrote about GlobaLLM, an AI agent that autonomously contributes to open source projects. While GlobaLLM’s primary objective is project and task prioritization at scale, Ouroboros focuses on task implementation and self-improvement. Ouroboros is thus one component of GlobaLLM’s solution.

How It Works

#

The Core Loop

#

Ouroboros follows a structured nine-step cycle that repeats continuously:

1. Read goals: fetches tasks from agent/goals/active.md
2. Select goal: picks one to work on, or defaults to self-improvement
3. Plan: uses an LLM to create a step-by-step plan
4. Execute: carries out the plan using available tools
5. Journal: writes results to a daily log
6. Reflect: analyzes what happened and identifies improvements, both task-related and self-related
7. Self-modify: edits its own source code if improvements are found
8. Journal again: records reflection and modification results
9. Repeat: starts the cycle again

The separation between execution and self-modification is crucial. The agent will not modify its code while working on a task; reflections and improvements happen only during dedicated reflection cycles.

Architecture

#

┌─────────────────────────────────────────────────────────┐
│                      Agent Core                         │
│  (coordinates the loop, handles signals, manages state) │
└─────────────────────────────────────────────────────────┘
         │                    │                    │
         ▼                    ▼                    ▼
┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│   Memory     │    │  LLM Layer   │    │   Tools      │
│              │    │              │    │              │
│ • Working    │    │ • Anthropic  │    │ • run_cmd    │
│ • Journal    │───▶│   Claude     │───▶│ • read_file  │
│ • Goals      │    │ • Token      │    │ • write_file │
│ • Feedback   │    │   tracking   │    │ • search_*   │
└──────────────┘    └──────────────┘    └──────────────┘

Memory System

#

Ouroboros uses a three-tiered memory architecture:

Everything is logged in human-readable markdown, which makes it easy to inspect what the agent has been up to.

Tool Registry

#

The agent comes with built-in tools for common operations:

• run_command: execute shell commands
• read_file: read file contents
• write_file: write to files
• search_files: find files by pattern
• search_content: search within files

Crucially, Ouroboros can create, register, and use new tools that it writes itself.

Tools are implemented as CLI commands of the ouroboros CLI, which the agent can invoke during execution.

Design Principles

#

Safety Through Structure

#

The execution/reflection separation prevents runaway self-modification. The agent can change code only during a dedicated reflection phase, and all changes are committed to git with descriptive messages that explain the reasoning behind each change.

Transparency

#

Every action is logged. Want to know what the agent did? Check the daily journal:

• agent/journal/YYYY/MM/DD/notes.md: what it did
• agent/journal/YYYY/MM/DD/reflections.md: what it learned
• agent/journal/YYYY/MM/DD/user-feedback.md: human input received

Autonomy with Optional Guidance

#

Ouroboros needs no human intervention, but it welcomes it. It incorporates feedback, adjusts course based on user suggestions, and explains its reasoning when asked.

What Makes It Interesting

#

1. True self-improvement: the agent can and does modify its own implementation based on reflection
2. Persistent memory: git commits serve as a permanent, queryable history of everything tried
3. Graceful degradation: failed modifications can be reverted; the agent learns and tries again
4. Tool extensibility: new tools can be created dynamically as needs arise
5. Idle improvement: when no goals are active, it works on making itself better

The Vision

#

Ouroboros represents an experiment in autonomous AI agents. Can an agent truly improve itself over time without human intervention, or with only limited intervention? By maintaining a detailed journal, reflecting on its actions, and having the freedom to modify its own code, Ouroboros aims to answer this question.

The name is fitting: the serpent eating its tail represents the continuous cycle of doing, learning, and improving that drives the agent forward. Each reflection builds on the last; each modification makes the agent slightly more capable.

Ouroboros is open source. Check out the repository to see the code, contribute, or run your own self-improving agent.

Introduction

#

Consider the following dilemma: you have unlimited access to state-of-the-art LLMs, but finite compute resources.

How do you maximize positive impact on the software ecosystem?

GlobaLLM is an experiment in autonomous open source contribution which attempts to address this question.

It’s a system that discovers repositories, analyzes their health, prioritizes issues, and automatically generates pull requests - all while coordinating with other instances to avoid redundant work.

The core insight isn’t just that LLMs can write code; it’s that strategic prioritization combined with distributed execution can multiply that capability into something genuinely impactful.

This article explains how GlobaLLM works, diving into the architecture that lets it scale from fixing a single bug to coordinating across thousands of repositories.

The GlobaLLM Pipeline: A High-Level View

#

GlobaLLM follows a five-stage pipeline:

Discover -> Analyze -> Prioritize -> Fix -> Contribute

1. Discover

#

The system begins by finding repositories worth targeting.

Using GitHub’s search API, it filters by domain, language, stars, and other criteria.

Current methodology uses domain-based discovery with predefined domains (ai_ml, web_dev, data_science, cloud_devops, mobile, security, games), each with custom search queries combining relevant keywords.

The system then applies multi-stage filtering:

1. Language filtering: Excludes non-programming languages (Markdown, HTML, CSS, Shell, etc.)
2. Library filtering: Uses heuristics to identify libraries vs applications (checks for package files like pyproject.toml, package.json, Cargo.toml; filters out “awesome” lists and doc repos; analyzes descriptions and topics)
3. Quality filtering: Language-specific queries include testing indicators (pytest, jest, testing)
4. Health filtering: Applies health scores to filter out unmaintained projects
5. Dependent enrichment: Uses libraries.io API to fetch package dependency counts for impact scoring

Results are cached locally (24hr TTL) to avoid redundant API calls and respect rate limits.

The goal isn’t to find every repository - it’s to find libraries where a contribution would matter.

2. Analyze

#

Once a repository is identified, GlobaLLM performs deep analysis to determine whether contributing is worthwhile.

This gate prevents wasting resources on abandoned projects, hostile communities, or repositories where contributions won’t have impact.

It calculates a HealthScore based on multiple signals:

• Commit velocity: Is the project actively maintained?
• Issue resolution rate: Are bugs getting fixed?
• CI status: Does the project have passing tests?
• Contributor diversity: Is there a healthy community?

It also computes an impact score - how many users would benefit from a fix, based on stars, forks, and dependency analysis using NetworkX.

Repositories with low health scores or minimal impact are deprioritized or skipped entirely.

3. Prioritize

#

The system fetches open issues from approved repositories and ranks them using a sophisticated multi-factor algorithm.

Each issue is analyzed by an LLM to determine:

• Category: bug, feature, documentation, performance, security, etc.
• Complexity: 1-10 scale (how difficult to solve)
• Solvability: 0-1 score (likelihood of automated fix success)
• Requirements: affected files, breaking change risk, test needs

The prioritization then combines four dimensions:

Health (weight: 1.0): Repository health adjusted for complexity.

A healthy repository with simple issues scores higher than an unhealthy repository with complex ones.

Impact (weight: 2.0): Based on stars, dependents, and watchers.

Uses log-scale normalization (stars / 50,000, dependents / 5,000).

Solvability (weight: 1.5): LLM-assessed likelihood of successful resolution.

Documentation and style issues (~0.9) rank higher than critical security (~0.3) due to automation difficulty.

Urgency (weight: 0.5): Category multiplier × age × engagement.

Critical security bugs get 10× multiplier, documentation gets 1×.

The final formula:

priority = (health × 1.0) + (impact × 2.0) + (solvability × 1.5) + (urgency × 0.5)

Budget constraints filter the ranked list:

• Per-repository token limit (default: 100k)
• Per-language issue limit (default: 50)
• Weekly token budget (default: 5M)

Results are saved to the issue store with full breakdowns for transparency.

4. Fix

#

GlobaLLM claims the highest-priority unassigned issue and generates a solution.

This is where LLMs do the heavy lifting.

The CodeGenerator class sends a structured prompt to Claude or ChatGPT with:

• The issue title and description
• Repository context (code style, testing framework)
• Language-specific conventions
• Category-specific requirements (bug vs feature vs docs)

The LLM responds with a complete solution:

• Explanation: Step-by-step reasoning
• File patches: Original and new content for each modified file
• Tests: New or modified test files

The system tracks tokens used at every step for budget management.

5. Contribute

#

The final stage uses PRAutomation to create a well-structured pull request with context, tests, and documentation.

For trivial changes (typos, version bumps), it can even auto-merge.

Where LLMs Are Used

#

LLMs are the engine that powers GlobaLLM, but they’re used strategically rather than indiscriminately.

Stage 3 - Prioritize: The IssueAnalyzer calls an LLM to categorize each issue.

Input: title, body, labels, comments, reactions.

Output: category, complexity (1-10), solvability (0-1), breaking_change, test_required.

This costs ~500 tokens per issue and feeds directly into the priority scoring.

Stage 4 - Fix: The CodeGenerator uses an LLM to generate complete solutions.

Input: issue details, repository context, language style guidelines.

Output: explanation, file patches (original + new content), test files.

This costs 1k-10k tokens depending on complexity.

The key insight: LLMs are only used for tasks requiring intelligence.

Discovery, health scoring, impact calculation, and PR automation use deterministic algorithms.

Scaling GlobaLLM

#

The real power of GlobaLLM emerges when you run multiple instances in parallel.

Distributed Agent Architecture

#

Each GlobaLLM instance has a unique AgentIdentity.

When it’s ready to work, it calls:

globallm assign claim

This atomically reserves the highest-priority unassigned issue.

The assignment is stored in PostgreSQL with a heartbeat timestamp.

Issue Assignment System

#

To prevent multiple agents from working on the same issue:

1. Issues are marked assigned with an agent ID and timestamp
2. Heartbeats update every 5 minutes
3. If a heartbeat expires (30 minutes), the issue is reassigned

This allows crash recovery: if an agent crashes mid-work, another will pick up the issue.

Crash Recovery

#

The heartbeat system is elegant in its simplicity:

# Agent side
while working:
    update_heartbeat(issue_id, agent_id)
    do_work()

# Recovery side
expired = get_issues_with_expired_heartbeats()
for issue in expired:
    reassign(issue)

No distributed consensus needed - PostgreSQL’s row-level locking handles contention.

Database Design

#

PostgreSQL is the central state store:

• Connection pooling: 2-10 connections per process (psycopg pool)
• JSONB columns: Flexible schema for repository/issue metadata
• Indexes: On frequently queried fields (stars, health_score, assigned status)
• Migrations: Versioned schema

Future Work

#

GlobaLLM is an evolving experiment. There are numerous challenges that developers face on a daily basis that a system such as GlobaLLM will also encounter and would need to deal with in order to be more effective:

• Parallelizing work across multiple agents without conflicts or redundant effort.
• Producing “mental models” of repositories to better understand their goals, architecture, dependencies and trajectories.
• Have a higher-level decision-making system that can reason about which repositories to focus on based on broader trends in the open source ecosystem.
• Make decisions such as which programming languages to focus on.
• Have the ability to work with closed source repositories which may not have the same signals as open source ones (e.g., forks, stars, dependency count).

Conclusion

#

GlobaLLM is an experiment in what’s possible when you combine LLM code generation with principled decision-making and distributed execution.

The goal isn’t to replace human contributors - it’s to handle the long tail of maintenance work that no one has time for, freeing up humans to focus on the interesting problems.

The system is actively developed and evolving.

Current work focuses on better prioritization heuristics, more sophisticated validation, and integration with additional LLM providers.

If you’re interested in contributing or just want to run it yourself, the code is available on GitHub.

This system is far from perfect, but it’s a step toward harnessing AI to make open source software healthier and more sustainable at scale.

It’s also a way to explore what it looks like to have to make decisions at the scale of millions of repositories and billions of issues.

Dr. Aris Thorne stared at the shimmering temporal rift, its edges flickering like a corrupted display. He wasn’t just looking at a gateway through time – he was looking at a living, breathing Git repository of reality itself.

“Status check,” he muttered, fingers dancing across the holographic interface. “Current branch: timeline-main. Last commit: ‘Catastrophe at Point Zero’ by User:Humanity.”

Three days ago, humanity had triggered the Cascade Event – a chain reaction of temporal paradoxes that threatened to unravel existence. Now Aris, the last Temporal Archivist, was attempting something never before conceived: git revert on reality itself.

“Creating new branch: ‘fix-attempt-1’,” he announced to the empty lab. The temporal rift stabilized, showing a parallel timeline branching off from moments before the disaster.

Aris stepped through, materializing in the control room of the Chronos Facility, right as the ill-fated experiment was about to begin. He knew the command sequence by heart – the one that would prevent the Cascade.

But as he approached the console, he froze. His younger self was there, looking determined but naive. If Aris intervened, would he create a merge conflict with his own existence?

“Branching again,” he decided, retreating to the safety of the temporal nexus. “Creating ‘fix-attempt-2’ from an earlier commit.”

This time he arrived hours earlier, when the facility was still empty. He carefully modified the experiment parameters, ensuring the Cascade could never occur. Satisfied, he returned to his present.

The lab was unchanged. The rift still showed the corrupted timeline.

“Failed merge,” Aris realized with dawning horror. “Reality rejected the patch.”

Days turned into weeks as Aris created dozens of branches, each attempting to fix the timeline. He tried git cherry-pick of successful moments from history, git rebase of civilization’s achievements, even git bisect to isolate the exact commit that had broken everything.

Nothing worked. Each attempt was rejected by the cosmic repository, leaving him with countless abandoned branches floating in temporal limbo.

Exhausted, Aris collapsed before the interface. “Git log –oneline –graph,” he whispered, watching the tree of failed attempts bloom across the display. It was beautiful in its complexity – a constellation of what-ifs and could-have-beens.

That’s when it hit him. He’d been trying to fix the timeline, to restore a previous commit. But what if the solution wasn’t to revert, but to evolve?

“Creating new branch: ’transcendence’,” he declared with renewed energy. “Not from any previous commit, but from the current corrupted state.”

He stepped through into the fractured timeline, where temporal paradoxes manifested as impossible architecture and shifting landscapes. Instead of fighting the chaos, he embraced it. He worked with the anomalies, finding patterns in the madness.

Aris discovered that the Cascade wasn’t an error – it was evolution. Humanity had outgrown its linear timeline, and reality was attempting to branch into a multidimensional existence.

“Merge request,” he transmitted to the temporal repository. “Not to fix, but to complete the transformation.”

The rift stabilized, its chaotic energy resolving into something new and coherent. Aris watched as all his abandoned branches began to merge into this new reality, each failed attempt contributing something essential to the final design.

When he returned to his lab, everything was different yet familiar. The temporal rift was gone, replaced by a window showing infinite timelines coexisting harmoniously.

Aris smiled at the new interface displaying the transformed reality. “Current branch: timeline-multiverse. Last commit: ‘Embrace the Chaos’ by User:Humanity.”

He had learned the ultimate lesson of temporal manipulation: sometimes the best commit isn’t a fix, but a feature.