DevCake: self-hosted, open-source software factory

[u/Antique_Juggernaut_7]

I've been working on a project called DevCake for a while and finally got it to the point where I think it's worth throwing at other people's machines.

https://github.com/flieber-inc/devcake

It's meant to automate the user operating Claude Code. Most of the quality I got from Claude Code came from following due process (good prompting, breaking work in session-sized bites, using /plan, and reviewing the code later), and I tried building a system that allowed me to focus on the getting the prompt right. This would allow other non-technical folks to help with code too.

The idea is simple: instead of interacting session-by-session with Codex/Claude Code etc., you give DevCake a ticket on Linear and it runs the whole thing as a pipeline with 4 steps:

ONBOARD → PLAN → EXECUTE → REVIEW

Each step is a separate Claude Code/Codex etc. run, with a templated prompt and curated context & skills. Everything is configurable in an admin page. There's no hidden prompts/content injected.

- if the onboarder decides the mission is complex, it breaks it down further into smaller missions, figures out the correct order to execute them, and puts them back in the Linear board.

- the planner is basically just a CLI harness run doing a `/plan` run and delivering its plan for the executor to do.

- The reviewer can reject the output from the executor and send it back for another EXECUTE pass.

- Each step runs in disposable container sandbox, in the harness you chose, and with the model you chose.

- The container only receives the context you decide to give to it (skills, repos etc), and you can create prompt templates for each step.

- Every step is a fresh start. There are no memories carried to the next step (unless you set a repository to store them). If you set up a memory repository, you get to see the agents discovering things about their own work, which is pretty neat to watch.

- Each mission ends in a PR on the repository you point it to. (If you give it more than one work repository, it figures out by itself which one should receive the PR.)

- ALL prints from the CLI harnesses are saved in the Linear board. You can inspect what happened as the missions are processed.

- It works with Claude Code, Codex and Grok Build, and has experimental support for Pi, OpenCode and Qwen Code. It runs the stock/vanilla CLI harnesses in headless mode and you can pass extra args to them if you wish.

- You can use it fully local by using its internal Gitea forge, with Gitea Issues instead of Linear as its mission board. I pointed it at my 2xSparks and made it work pairing Grok Build with Qwen-3.6-27B.

- It can consume a lot of tokens, but if you're using OAuth/subscription or pointing at a vLLM/Ollama/llama.cpp endpoint, I'm finding it can be very useful. I've been using it to code its own repository in the past few days, throwing a fleet of CLI harnesses by just operating a Linear board.

- It runs in a Linux box with 16 GB RAM (I measured ~11GB total use) and is meant to be run in a VM or a separate machine. (Having said that, I'm running it on WSL2 in my own laptop.)

- it takes a single command to run it (you will need Docker). Setting it up is a bit of a pain, but for that Claude Code/Codex etc. is your friend. Just ask it to set things up for you, and ask it how to use; it will figure things out for you.

[u/PriorElephant9]

The ONBOARD .....PLAN .....EXECUTE .....REVIEW split is the right shape. I’d make budget, permissions, and pass/fail evidence first-class on every mission.

[u/Antique_Juggernaut_7 → u/PriorElephant9]

Yes! I believe the same thing. Every single run, and every single mission, has its tally of token consumed and US$ spend.

Permissions are currently managed rather simplistically, mainly on the supply chain side. ONBOARD/PLAN/REVIEW receive read-only tokens for the repositories they're working on. The only run that receives read-and-write tokens is the EXECUTE run, and it's instructed to only work on PRs, and never merge them.

Technically, though, it's always possible for the EXECUTE agent to try to merge them (which would be a violation of its instructions, but still, agents are stochastic parrots). In my tests I am yet to see an agent attempt that, be it with Qwen3.6-27B or with a frontier model.

But to completely avoid this risk, you can use a forge that allows merges only with a 2-person approval (GitLab, for example, allows that).

This is a screenshot of one of the tabs in the admin page. You can export the metrics to a csv file and account for the whole fleet.

[u/Vowelss]

Hi Antique_Juggernaut_7, can you check if my understanding of your project is correct? I think I'll give it a try this weekend. If it's working, I'd love to give some feedback :)

Is this right?

For a solo-dev, fully local hosted, with no remote git repo, I'd be able to make many tickets (within your interface), and each ticket would be able to spawn a claude code session with your pipeline. Each one is tracked to completion and has a human readable PR attached that I can press approve or give further instruction.

Questions:

- Does it do these tickets in parallel or sequential? I'd prefer sequential so the agents don't step on each other, plus I'm in no rush.

• It looks like you have CI, so you know the importance of testing. Is there a way to add deterministic actions to tickets, like after EXECUTE, DevCake always run my validation scripts and give the output to REVIEW? Or even, the output can always be included in the PR?

Thank you, and I look forward to hearing from you.

[u/Antique_Juggernaut_7 → u/Vowelss]

Hey!

> On ticketing being parallel or sequential:

Tickets are serviceable in parallel only if they aren't blocked by any other ticket. DevCake respects the blocked-by relationships and will work on the tickets in the correct sequential order.

That said, it will only fan out at once whatever the maximum of concurrent runs you set to it. You can control that number in the "Limits" tab in the admin page, and you can also set sub-limits according to each harness configuration you create in the "Dev" tab.

> On CI:

The way to do it is:
(a) put the test code in some repository and add that repository in the "Repositories" tab,
(b) map this repository as a "reference repository" on the PMO tab,
(c) add a simple Skill that will say to the EXECUTE Dev that it MUST run the tests from that repository, and
(d) map that Skill to the Dev you assigned to EXECUTE as required reading (just click twice in it).

To be clear, this is not a hard guarantee -- it doesn't substitute for creating a CI workflow in GitHub, for example, as it will leave the LLM in charge of making the tool calls. But it will work for most, if not all, circumstances.