DEV Community

Alexander Gil Casas
Alexander Gil Casas

Posted on

Forkline: Building AI runners for engineering teams

#devops #ai #github #showdev

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
Enter fullscreen mode Exit fullscreen mode

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

BYOM changes the economics

BYOM matters for two reasons:

  1. It keeps model choice flexible.
  2. 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:

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

Top comments (0)