Forkline: Building AI runners for engineering teams

Alexander Gil Casas — Wed, 29 Apr 2026 15:28:10 +0000

Most AI tooling conversation still treats coding agents as private developer tools.

I became more interested in the company workflow around that work: tickets, repos, PRs, CI, review,
and the feedback loop that tells the team what happened. That is the reason Forkline exists. We are
launching at $2.50/month during a 75% promotion because AI runners only matter if small teams can
afford to use them continuously, and because BYOM keeps Forkline from becoming another bundled AI
seat.

The product category I care about

I do not think Forkline is best understood as a coding assistant.

I think of it as AI runners for engineering teams:

bounded work should enter through tickets, issues, tasks, or CI signals
runner output should land as branches, commits, PRs, logs, and CI output
the model layer should stay interchangeable through BYOM
the human should keep the final gate
the company workflow should get feedback from the runner's work

That is a different operating model from a private editor assistant or a model-native routine surface.

Why this felt worth building

The hard part of software work is often not writing the first draft of code. The hard part is
handling the company-visible workflow around it:

a ticket that needs implementation or follow-up
a maintenance task nobody prioritizes
a broken dependency update
a PR that needs a fix before it can merge
a small cleanup task that never makes the sprint

Those jobs do not need hype. They need visible runners and a feedback loop the team can inspect.

Current scope vs roadmap

This distinction matters.

The strongest public proof today is around:

ticket/task-driven work
maintenance tasks
CI recovery
Bring Your Own Models setup
Git-native visibility through branches, PRs, and logs

What I am not claiming as public launch proof yet:

Jira and Linear integrations
deeper B2B support and enterprise features
advanced cross-system orchestration

Those are part of the roadmap / coming soon direction, and I want that boundary to stay explicit.

Architecture principles

Forkline lives adjacent to the repo, not inside an IDE.

ticket, issue, task, or CI signal
        |
        v
isolated runner
        |
        v
branch + PR + execution context
        |
        v
CI rerun where applicable
        |
        v
human review and workflow feedback

The key idea is simple: runner work should be inspectable by the team.

BYOM changes the economics

BYOM matters for two reasons:

It keeps model choice flexible.
It keeps the product from becoming another bundled AI seat.

If a team already pays for Claude, OpenAI, or local models, the missing piece is not necessarily
another subscription. The missing piece may be runners that connect those models to tickets, repos,
PRs, CI, and review.

Public proof anchor: promrail PR #38

A minimal public example I have right now is a runner-driven maintenance and CI recovery flow on
promrail:

https://github.com/forkline/promrail/pull/38

What happened:

Renovate updated clechasseur/rs-clippy-check from v5 to v6
CI failed because the floating @v6 tag did not exist
a Forkline runner identified that issue and a deprecated action in the same workflow
the runner pushed 2 fix commits
CI reran and passed

Evidence:

Failed CI run: https://github.com/forkline/promrail/actions/runs/24629082165
Fixed CI run: https://github.com/forkline/promrail/actions/runs/24629267346

I use that example to establish that the artifact loop is real: failing signal, runner diagnosis,
commits, PR, and CI result. I do not use it to imply every broader roadmap capability is already
public.

What Forkline is not

not a model provider
not an IDE replacement
not a black-box workflow that asks for trust without artifacts
not just a CI fix tool
not a full enterprise support layer yet

What I want to learn next

The biggest open question for me is not whether AI can generate code. It clearly can.

The real question is whether companies want AI work to stay inside private developer tools, or
whether they want runners that report through shared engineering workflows.

That is the category bet behind Forkline.

Disclosure: I built Forkline. We're launching this week.

Website: https://forkline.dev Proof anchor: https://github.com/forkline/promrail/pull/38

DEV Community: Alexander Gil Casas