From GitHub Issue to Pull Request: Building a Self-Hosted Autonomous Coding Agent — Blitzlog

September 21, 2026 (1mo ago)

AI coding agents have changed how quickly we can write software. But there is still a surprisingly simple bottleneck:

You usually have to be sitting at your computer to use them.

We ran into this problem ourselves.

We were travelling frequently, often spending hours on trains, while our engineering backlog continued to grow. We could think about the work, create issues, and plan what needed to be done, but actually getting an AI coding agent to work on those tasks still meant opening a laptop and starting a session.

So we built Blitzlog.

GitHub - great-wall-connect/blitzlog: Pin, blitz, merge. Autonomous coding pipeline: GitHub issue → EC2 spot instance → OpenCode agent → pull request. From issue to PR. With a trail.

Blitzlog is an open-source autonomous coding system that lets you turn a GitHub issue into a working pull request. Instead of sitting in front of an AI coding agent and supervising every step, you can give it a well-defined task and let it work independently in a sandboxed environment.

When it finishes, you get a pull request ready for human review.

The idea is simple: let AI handle more of the implementation work without giving up the engineering workflow and controls that teams already rely on.

From Backlog to Pull Request

Most software teams already have a backlog full of tasks that are well understood but aren’t necessarily worth having a developer sit down and execute immediately.

  • Small bug fixes.
  • Dependency updates.
  • Tests.
  • Refactoring.
  • Documentation.
  • API changes.
  • Maintenance work.

These are exactly the kinds of tasks where an autonomous coding agent can be useful.

With Blitzlog, a GitHub issue becomes the starting point. Describe the problem, provide the relevant requirements, and mark it for autonomous execution.

Blitzlog takes care of the rest.

The agent can inspect the repository, understand the existing implementation, make the required changes, run tests, and prepare a pull request.

Your Backlog Can Keep Moving While You Do Something Else

The original reason we built Blitzlog wasn’t because we wanted another coding assistant.

We wanted asynchronous software development.

If you’re travelling, in meetings, working on another project, or simply away from your development machine, your engineering backlog doesn’t have to stop.

You can create an issue, provide the necessary context, and let Blitzlog work on it.

When you return, you don’t have to reconstruct an old AI conversation or figure out what state the agent left the repository in.

You can review a pull request.

That’s a much better boundary for engineering work. The agent does the implementation. The developer reviews the result.

AI Coding With a Human in the Loop

Autonomous doesn’t have to mean unsupervised.

One of the core principles behind Blitzlog is that the agent should be able to do substantial engineering work without making the final decision about what enters your codebase.

Blitzlog can create the branch, make changes, run tests, commit the work, and open the pull request.

It doesn’t need to merge it.

Your existing code-review process remains the final checkpoint.

This makes Blitzlog fit naturally into teams that already use pull requests, code owners, CI pipelines, and review workflows.

You don’t need to replace your engineering process to introduce autonomous coding.

You can add another contributor to it — one that happens to be an AI agent.

Give Agents Real Engineering Tasks

AI coding agents are often demonstrated with prompts such as:

“Build me a todo app.”

Real engineering is different.

Most work happens inside existing codebases with established conventions, dependencies, tests, architectural decisions, and historical context.

Blitzlog is designed around that reality.

You can give an agent a task inside an existing repository and let it work with the code that is already there.

It can inspect the project, understand how the existing implementation works, make changes in context, and validate those changes before creating the pull request.

This makes the system useful for the work that actually fills engineering backlogs — not just greenfield demos.

Automate the Boring Parts of Engineering

Not every task requires a senior engineer’s full attention.

Consider a backlog containing:

  • Add missing test coverage
  • Update an API client
  • Fix a validation bug
  • Refactor a repetitive component
  • Update documentation
  • Add logging around a failure case
  • Upgrade a dependency
  • Implement a small feature
  • Fix a straightforward bug
  • Add an integration test

A developer still needs to define the desired outcome and review the result.

But they don’t necessarily need to spend their time watching an agent navigate the repository and execute each step.

That’s where Blitzlog can create leverage.

The objective isn’t to automate software engineering.

It is to automate more of the execution between the issue and the review.

Let the Agent Run in Its Own Environment

Blitzlog doesn’t require you to dedicate a development machine to your AI agents. Each autonomous task can run in an isolated, temporary environment that exists for the duration of the job.

When the work is complete, the environment can disappear. That means you don’t need to maintain a fleet of always-on machines waiting for the next AI task.

It also gives each task a clean environment rather than allowing state to accumulate between unrelated jobs. For teams running autonomous agents regularly, this creates a much cleaner operational model.

Keep Your Code and Credentials Under Your Control

Blitzlog is designed to be self-hosted.

Instead of sending your repositories through a third-party autonomous coding platform, you can run the infrastructure inside your own AWS environment.

That gives organizations more control over where the agent runs, how credentials are managed, what gets logged, and how the system connects to their repositories.

GitHub access can be provided through a GitHub App with repository-level permissions rather than handing an autonomous process a developer’s personal credentials.

For organizations thinking seriously about autonomous coding, this distinction matters.

The question isn’t only:

“Which AI model should we use?”

It is also:

“Where should our AI coding infrastructure run, and what should it be allowed to access?”

Bring Your Own Model

Blitzlog isn’t tied to one particular model provider.

You can configure the coding agent to use the model infrastructure that makes sense for your organization. That can include cloud-based models, private model endpoints, or even models running on infrastructure you control. This opens up different possibilities for teams with different requirements.

Run Local AI for Sensitive Code

One of the more interesting possibilities is combining Blitzlog with local model infrastructure.

If you have a powerful machine running a local model, Blitzlog can be configured to use that model rather than sending your repository contents to an external inference provider.

For example, you could have a local machine running your preferred inference stack while Blitzlog handles the surrounding autonomous workflow.

This can be particularly interesting for organizations working with sensitive source code or experimenting with private AI infrastructure.

And importantly, if you’ve explicitly configured the system to use a local model, it shouldn’t silently fall back to a cloud provider when that model becomes unavailable.

Your privacy choice should remain a real choice.

Talk to Your Coding Agent From Your Phone

We were sitting on trains with only our phones while engineering work was waiting for us. So we built a way to interact with a running coding agent through Telegram. The experience becomes surprisingly simple. You can start an agent task, leave your computer behind, and communicate with the running agent from your phone when needed.

This isn’t meant to turn Telegram into an IDE or a bash shell. The point is that you don’t always need an IDE.

Sometimes you need to tell the agent:

“Continue with the approach we discussed.”

Or:

“The test failure is expected. Check the existing implementation in the other module.”

Or simply:

“What is the current status?”

The agent can continue doing the heavy lifting while you stay mobile.

Built for Real Engineering Workflows

Blitzlog is designed around the tools engineering teams already use.

That means adopting Blitzlog doesn’t require your team to completely rethink how software gets shipped. Instead, it introduces another way for work to move through the existing process. The biggest change is simply that the implementation step can now happen asynchronously.

Know What Your Agent Did

Autonomous work creates a new requirement: visibility.

When you aren’t watching the agent, you need to be able to understand what happened. Blitzlog keeps execution information and agent sessions so you can investigate completed or failed tasks. If a task produces an unexpected result, you shouldn’t have to rely on the agent saying:

“Trust me, I did the thing.”

You can inspect the execution logs and the resulting pull request. This is particularly important when introducing autonomous coding into a team environment. The more autonomy you give an agent, the more important observability becomes.

Don’t Let an Agent Run Forever

Blitzlog also treats execution limits as a first-class feature. An agent that gets stuck shouldn’t be able to consume resources indefinitely. Tasks have a maximum execution time, after which the worker can be terminated. This protects against a surprisingly important class of problems: agents that don’t know when they’re done.

Autonomy needs boundaries. A useful autonomous system isn’t one that is allowed to do anything forever. It’s one that is given a clearly defined task, a defined environment, appropriate permissions, and a defined amount of time to complete the work.

Open Source and Self-Hosted

Blitzlog is open source because we wanted the architecture and implementation to be inspectable. You can run it yourself, modify it, adapt the workflow to your repositories, and experiment with different models and infrastructure.

For companies, self-hosting also means the system can become part of your existing cloud environment rather than another external SaaS dependency. You can decide how it is deployed, which repositories it can access, what models it uses, and how it fits into your internal engineering workflow.

What We Actually Built

The interesting part is turning that capability into a workflow that can operate independently of a developer sitting at a keyboard. We started with a very practical problem: we wanted to keep engineering while we were travelling. That led us to a simple idea:

What if a GitHub issue could become an autonomous engineering task?

From there, Blitzlog evolved into a system that can take a task, give an AI coding agent the environment it needs, let it work, validate the result, and return a pull request for a human to review.

The result is a different relationship with the engineering backlog.

Instead of constantly asking:

“When will I have time to work on this?”

you can start asking:

“Is this task well-defined enough for an agent to work on?”

That’s a much more interesting question.

The Future of Coding May Be More Asynchronous

The next evolution of AI coding may not simply be better autocomplete or better chat-based coding. It may be the ability to delegate well-defined engineering work and come back to the results later.

The interface becomes the issue.

The output becomes the pull request.

And the developer moves further up the stack — from typing every instruction to defining the work, setting the constraints, and reviewing the result.

That’s what we’re experimenting with through Blitzlog.

Give the agent the issue.

Let it do the work.

Review the pull request.

And maybe, for once, you can finish the journey before the code does.

Ali Farooqi

About the Writer

Ali is a software engineer based in Hong Kong who builds cloud-powered, high-performance web apps. He writes about React, Next.js, DevOps, SEO, and building modern portfolios that scale. When not coding, he's probably hiking mountains or testing new cloud infra ideas.

Originally posted on Medium