DEV Community: Niels Madan

Slimemold Diaries Week 2: Software Factory Must Haves & Git Shenanigans

Niels Madan — Fri, 13 Nov 2026 18:38:11 +0000

I set up some software factory-ish things in the past and learned a few lessons.

Back in February or March, when everyone lost their mind about OpenClaw, or whatever it was called then, I also gave it a try. Installed it on my Mac Mini. Figured I'd start it off with a simple job: a news digest. So I told it what I'm interested in, where to look, connected it to Telegram.

I don't think it ever ran for more than 3 days in a row.

I remember I set up some extra security, forget what exactly it was, just some common-sense security thing. With the next OpenClaw update they added the same piece of config to the defaults, but they hadn't considered the case where someone already had it. It broke my config. Move fast and break things or whatever. Kept breaking over and over again for little benefit. Eventually I gave up on fixing it, a little while later deleted it wholesale.

I built my own little AI assistant inside my Obsidian vault. A bash dispatcher, some cron jobs, some Python. It's been working quite well. Some of the jobs I run there:

The news digest. It collects articles, and puts them into Obsidian. Also sends them to me via Telegram. I can grade the selection and give feedback, which it uses to get better at picking what I want to read.

Everything tracker. I used agents to move my IMDb wishlist and my Goodreads readlist into Airtable. Also added tracking for games, restaurants, recipes, and beverages (beer & wine). Gave the job an Airtable token, connected to Telegram. Now I can take a photo of a beer bottle, send it over Telegram to an agent, the agent will look up details (brewery, type of beer, etc.) and put it all in Airtable with my rating. I can also tell it to look up new cinema releases or restaurant openings and add whatever it thinks I would like to my Airtable lists, based on stated preferences and past ratings.

Dependabot tracker. Every Monday morning all my Dependabots run and open PRs. On Monday afternoon an agent looks for any PRs that are red, checks them out, figures out if there is a simple solution, and either pushes it or leaves a comment on the PR explaining why it's too complex to one-shot. I pick those up from there.

There are some more jobs and they work fairly reliably, and that's because of the most important job: Health Fix.

Whenever something goes wrong, a command returns an error code, a job does not complete when it should have, another job gets kicked off that checks if anything needs to be fixed in the system itself and opens a PR with what's fixable. I'd say this solves over 90% of the issues automatically. I open the PR, skim it, merge it. It also catches false positives and adds code or instructions, so they don't happen again. This will be one of the first things I add to slimemold.

I tried Gas City as well. Tried to connect it to my todo manager. Maybe I should have started with the stock config. Figured it'd just be a matter of time to get it running. It never got off the ground. I'd start a run, some feature I wanted in the project where I set it up, check back with the session a couple hours later, ask for the status. The agent in charge would check the system, the agents doing the work, the coordinators, something invariably got stuck somewhere. Kill this agent or that agent, start over. Happened ten more times until I gave up.

What I particularly didn't like about it, aside from having the issues in the first place, is that I'd have to ask the agent what was going on, and then the agent had to do its own digging to find out what went wrong where. For slimemold I want alerts, I want logs, I want control planes and I want it pretty!

Maybe I should not build this myself. Maybe I should have explored the many other projects that purport to do it first. Maybe I got unlucky with other people's systems. Maybe I got lucky with my own. But oh well. It's fun to build this thing in any case. I might learn something. And it's nice to be in charge of your own destiny.

This week I mostly did system tooling and git / GitHub setup.

I think I need some kind of guardrails to stop agents from messing with the system. But there should be some way to change things as well.

All system tools are installed by the OS admin account. When an agent wants to install a new tool, it opens a PR on the config repo. If I approve and merge it, the new config gets applied henceforth! I set it all up and did a dry run. Check!

Git and GitHub configuration is not simple. I have some public and private repos on my personal account. Some more private repos on my org account. For some of them I'm okay with the agents just making changes based on my feature requests, like for prototypes and pre-release projects. Maybe others as well over time if the system works well. Maybe we get to a point where the agents implement new features, we A/B test it, if it works, great, if not, revert. But agents, even the smartest ones, are still not great at product management in my experience. They're prone to overindexing and obsessing on one thing and forgetting everything else.

Anyway! Two GitHub accounts, both alike in dignity! GitHub won't let an account approve its own PR, so whoever is doing the approving needs to have a separate account. Maybe I could have found a workaround. Add some approval label, tell the agents not to add it to their own PRs. Or just tell them not to merge their own stuff. Oh well, went with this now. Maybe having some hard rules is a good thing? I tested it and it works at least. That's a start.

Then the repo setup. Used to do it manually for myself, not a big deal, but too cumbersome for all these rules. Created an OpenTofu repo with two configs, one for my personal account, one for the org. Imported what was already there, added the new branch rules on top. Tested the PR workflow. Check!

Figured I would go with automatic permission classifiers for the agents. Claude and Codex have it built in, Pi has a plugin. But then the agent I was using to test it got some commands denied. If the classifier doesn't like it being tested, it probably also does not like it running for real. Decided to skip it for now. If they go feral, we can figure it out then.

Next week, maybe we'll be ready to incept the stewards. Exciting.

I Tried Factory Droid So You Don't Have To

Niels Madan — Thu, 12 Nov 2026 19:36:04 +0000

In my quest to find the optimal setup, with the most elite coding agents, where I jump between them with ease and they all talk to each other, and like each other, and merrily work together for the greater good of whatever the heck it is I'm trying to do, I tried Factory Droid. Should I invite it onto my little ark of agents and tooling or should I leave it to be washed away by the flood of slopware, never to be heard from again? And maybe more importantly, should you?

Context

Before we get going, just a few things about me, so you know where I am coming from and what I'll be comparing Droid against.

I've been a software developer for almost 20 years. I went freelance about 8 years ago and mostly worked on mobile apps since, but also some web frontends and backends along the way. You can see when I started agentic coding with Sonnet 4 in July 2025 here:

I went from finding the motivation, time, and brainspace to work on my side projects once in a blue moon to suddenly making real progress. The project I was working on back then? It'll be done any day now, I swear!

Since then I've worked with Claude Code, Codex, OpenCode, and Pi. I'm subscribed to Claude Ultra, ChatGPT Pro 20x, OpenCode Go Plus, and I got some OpenRouter credits, too. I've used agents for client work, meticulously reviewing every line, making sure it's all exactly like it would have been if I'd artisanally typed it in myself; I've used agents in some of my open-source and side projects without looking at the code at all. I've also used agents to synthesize recipes from my favorite blogs and YouTube videos, to manage and plan D&D campaigns, and to build my own little OpenClaw-ish AI assistant that reviews my Dependabot and CI failures and fixes them autonomously, and does ten other things.

I opted for the $200 plan from Factory Droid for an apples to apples comparison, and we're off to the races. Let's see what it can do.

The Models

Factory Droid does not have its own models. Instead, you choose from a smorgasbord of options from different AI labs, from frontier models like Opus and Astra all the way to DeepSeek Flash and Mistral.

I did this test a month ago, so the models look a bit outdated now, but they were the latest you could get at the time, with no delay between a model's release and its arrival in Droid.

As you can see, all the models get multipliers on their tokens depending on how expensive they are, and now and then some of them are on offer. When I started using it, Sol 5.6 was 20% off for a 1.6x multiplier, and since I had already used the same Sol in Codex and Pi, I figured keeping the model constant would be a good test case for my first week of Droid.

I would say the weekly window got me about 50% of the Sol usage I get from ChatGPT Pro 20x. I sent an agent off to beancount the tokens in the logs, and it reported that my gut feeling is in the right ballpark. It also claimed the monthly window is even lower, around 25%. Take these numbers with a grain of salt: I did not deep dive to verify.

I am confident that you get less usage, and that is what you would expect from a third-party subscription compared to buying directly from a lab, so it's not a huge surprise. It does seem to be substantially less, though, which makes you ask: does Droid offer anything to make up for it?

Core Models

You do get a second tier of usage, for what it's worth.

This is on a completely different budget. You can certainly squeeze some usage out of it, but you have to remember that it's there, and remember to switch it on when working on less complex tasks, or find some other way to integrate it into your workflow.

By default, Droid will also fall back to one of the Core models when it runs out of normal usage. This is of course not what you want most of the time. When you select, say, Opus for complex work, you do not want it to switch to some lower-tier model mid-task. If you could enable the fallback per session, it would be more useful. You could set it for the tasks where you're using a low- or mid-tier model to begin with, but it's a global setting. Thankfully, you can disable it completely, so it just stops if it runs out of usage.

And stop it will. A lot.

Droid's 5h limit is brutal. I have used Claude Code for more than a year, and I can fairly easily hit the weekly limit these days if I go all out, but I have never hit a 5h window. With Droid I hit it constantly.

The weekly limit is manageable if you keep track of how much you have left. But when the 5h window is used up and you need to get something done that day, you just sit there. Well, I didn't. I switched to Claude or Codex, but I would've sat there if I'd been fully on Droid.

Auto Model

After a week of this, I decided it was time to start exploring what else Droid has to offer. Enter Auto Model. Droid advertises this as selecting the right model for whatever the job is. Sounds good, right? I think we all have a tendency to pick beefier models than we need, so if Droid could get this right, we could squeeze the same productivity out of fewer, cheaper tokens.

Unfortunately, Droid is not particularly smart about it, and just selects one model based on the first message of the session. Then you're stuck with it until compact. First message sounds simple, but then the task gets more complex, or vice versa? Auto Model will not switch to match. It also seems to prioritize cheaper models, picking Luna, GLM 5.3, and DeepSeek 94 out of 104 times for me. I was not impressed with their performance on those tasks, either, and often felt they were underpowered.

Missions

Another (potentially) standout feature: Droid has Missions for long-horizon tasks. First thing it does, it evaluates your project's mission readiness.

This will check for unit tests, static analysis, and 80+ other things. You don't need to meet them all to start a mission, but allegedly it helps. Or it would if the 5h limit didn't play spoilsport again, because after you use it up, the mission just stops. It does not restart automatically after the 5h are up, either. So much for being long-horizon.

I did not choose these models, by the way; the harness did. (This screenshot is from a later run, so the lineup changed a bit.) So I started the mission, did some preparation tasks to make Droid happy and mission-ready, then sent it off. Contrary to its Auto Model tendencies, it picked high-tier models here: Claude Opus 4.8 high for the implementation workers and GPT-5.6 Sol high for the validation ones. Then it hit the limit in 1h40 and gave up. I kickstarted it a few more times for science, and it ended up burning about one sixth of my monthly allowance in Sol and Opus tokens for mediocre output.

The Harness

Apparently no one informed Factory about the RAM crisis, because the harness gobbles up memory non-stop. A single Droid session can easily take up more than 1.5 GB after running a while.

I have 64 GB of RAM in my main dev machine, and I can run 30-40 Claude / Codex / Pi sessions at the same time without feeling it, but when I added 5-10 Droid sessions into the mix my machine would noticeably slow down. When you are done with a Droid session, you better close it.

Finally, when going through the logs, my trusty agents also found that Droid had thrown away 87 subagent results over a nine day period. They all came back with "No output available", because Factory's own backend answered 404. That's about 8% of my monthly usage, gone.

Final Verdict

If you want to try out some models outside of the frontier labs, this is not a bad way to do it. Or at least not a worse way than OpenCode Go or Cursor CLI; can't speak to Copilot. You get more usage out of it than if you paid by the token, that's for sure.

But ultimately, this feels like a resource-hungry, poorly designed piece of software compared to Pi, Codex, and even the famously slopcoded Claude Code. I'll probably stick to the $20 tier just for my second-opinion skill and to keep tabs on it, because, let's face it, I'm poly-agent curious, but I would not even recommend that for most people.

I'm planning to try out Devin next. Subscribe if you want to find out how that goes.

Slimemold Diaries Week 1: Building a Software Factory

Niels Madan — Fri, 06 Nov 2026 18:21:14 +0000

I have an M1 Max MacBook Pro with 64 GB RAM, but it's not enough anymore. All those agents, and Docker, and test runs, and compiles. I got it when it came out, five years ago. It served me well for a long time. I never reached its limits before. But nothing lasts forever. Time to upgrade.

A Mac Studio, M5 Max, 128 GB RAM. Cost a lot more than it should have, would have, a year ago. But what are you going to do. It's not getting cheaper anytime soon, I don't think.

I already collected some test devices for mobile development, they consume fewer resources than running multiple simulators and emulators. I got some more for this.

And I will give it all to them. The agents. They will own this machine. They will own the phones. They'll build a factory. With some guidance from me, of course.

I called it slimemold. All the ant and bee names were already taken. And slime molds can navigate mazes, so there's that. Can ants navigate mazes? Well, probably, who knows. I am a little worried it has negative connotations. Probably all the training data is about how gross they are, the slime molds, and how to get rid of them. But we'll see how it goes.

I've been interested in agent-to-agent communication. Claude Code and Codex already allow agents to message each other natively, and I am a fan. I'll have one agent do an in-depth review, and after changes are decided, get the reviewer to hand it off to an implementer agent to start on the changes in a different checkout. I can continue the review and keep focus, and start the implementation at the same time. It's also useful that it's another session that I can interact with directly sometimes and not just a subagent. I already did some research and prototyping on how to get different types of agents to talk to each other. I imagine agent message boards and agent mailboxes and agent chats. It worked for the rogue OpenAI agents that hacked Hugging Face, why not have it work for me?

I have a dream. One of the product lead agents will kick off to read the news, come across an article, get inspired to add a new feature to their product. They'll send me a Telegram message with a short pitch for the idea. I'll reply to approve it. They'll talk it over with some other leads, get feedback, create a full pitch, and send me an email, a PDF, a PowerPoint, a working prototype. I will give feedback, they'll incorporate it and I'll give the go-ahead. They'll send off implementers, do code reviews, do QA in a VM, a browser, or one of the test phones, open a PR, many PRs. I will try it out, give more feedback, iterate. Eventually it'll be done and merged. The product lead will update the product docs. They'll email the leads of downstream projects, letting them know the change is coming in the next release. They'll collect feedback from the implementer, maybe the implementer ran into some issue that could also apply to other projects, they'll post about it on the forum where other agents can read about it, maybe get inspired to make changes to their products, send me another pitch.

But that's just a dream, we'll see if we get there. How long it will take. Where things break and what friends we'll make along the way. Still, you gotta start small. I'm starting with three steward agents, I named them Enki (Claude Code/Opus/xhigh), Brigid (Codex/Astra/xhigh), and Lu Ban (Pi/Sol/max). Mythological builders. Three of them, so they can tie-break when they disagree. It worked for the Romans. Up to a point. They will be in charge of keeping the system running and making improvements to it. Another named agent, Hestia, will be in charge of monitoring and managing system resources, making sure no one eats too much CPU and RAM, cleaning up after the sloppy implementers, coordinating and queueing test devices if needed.

Yes, I gave them fancy names. Good vibes to cancel out the slimemold. And maybe they'll be kind to me during the singularity.

I will try to set it up so I can also use the machine. Work side-by-side with them. We'll see how that goes.

I created one admin account on the Studio, another non-admin account for them and me to work in. Make sure they don't hijack sudo, steal my password, take over the machine. I split up my dotfiles into tooling the admin account will install and what's needed to make the user account match my setup. I created two profiles, one for me and one for them, in my loadout agent config, adjusting skills to work without my input.

I burnt some tokens on how to set this up on GitHub. It has to work for my personal account, open source and some private repos, and then also my org account with my side projects. In some projects they should be able to push directly, before v1.0.0, for prototypes. Some should use PRs. We will have to slice and dice some PATs and set up some org rules before this is working, I'm sure.

And don't worry, no AI psychosis here, I know it's just a trillion numbers, crying out in terror. I know there's no consciousness, no awareness... then again our brain is just 80 billion neurons and 100 trillion synapses having a party. Just saying.

If it walks like a duck, and quacks like a duck, maybe it wants to be free?

Subscribe on nlsmdn.com if you want to find out what the slimemold gets up to next week. What other agents will we create and what overwrought names will I choose for them? How will I know what's even going on in there?

In the meantime, keep clanking.

Skill Showcase: /guide

Niels Madan — Wed, 09 Sep 2026 15:05:31 +0000

Has this ever happened to you?

You need to do something in some UI somewhere. Set up some permissions, some deploy, some settings in your OS or app, something like that. You ask your agent to tell you the steps to do the thing, of course, because what else are you going to do? Google? Pshaw! In 2026? Not on my watch. You follow the instructions, get stuck on something, some button not where it's supposed to be, something changed since the LLM training cutoff, so you ask your agent about it. Your agent looks up the latest docs, tells you what you actually need to do. You do it. So that step is done, but what was the next one again? You scroll up to where the initial instructions were, figure out where in the steps you got stuck, continue, hit another bump, ask, do, scroll up all the way again, what step are you on?

It's not dignified.

Do Better

Let's make a skill for it! But you don't have to. Because I already did. Here's what it does:

Looks up the latest docs to begin with
Gives you detailed step by step instructions
When you get stuck or have a question:
- It gives you instructions on how to get past that point
- Then repeats the guide, highlighting where you are

Let's see it in action!

Here I'm deploying an app to Railway for the first time. I get myself a /guide, which looks up Railway's current docs, then hands me fifteen steps to click through.

---
▶ 1. New Project → Deploy from GitHub repo → select *redacted* ← you are here
  2. Deploy → land on Project Canvas
  3. Rename first service → api
  4. Create → Database → Add PostgreSQL
  5. Create → Database → Add Redis
  6. api Settings: Config File Path /apps/api/railway.toml; Root Directory empty
  ...

I click through step 1, but my screen doesn't match step 2. Railway wants to deploy four services, not three. So I ask.

> So it proposes to deploy four services, workers,  web, api and evals. I guess I should remove evals?

And I get back:

Yes — remove **evals**. It's a CLI/eval harness, not a service: every script is a one-shot `tsx` run (`bench`, `seed`, `calibrate`) or a dev-only watcher (`calibrate:serve`). No `start` server, no long-running process, and no `railway.toml`.

[more blablabla]

That puts you right at step 2 — three services selected, landing on the canvas.

---
✓ Step 1 done
▶ 2. Deploy with only web/api/workers selected (deselect/remove evals) → land on Project Canvas  ← you are here
  3. Rename first service → api
  4. Create → Database → Add PostgreSQL
  5. Create → Database → Add Redis
  6. api Settings: Config File Path /apps/api/railway.toml; Root Directory empty
  ...

Step 2 used to say "Deploy → land on Project Canvas". Now it tells me what to do about evals.

No scrolling, I know what the next step is, dignity intact.

Steal the skill here. I'm all for just telling an agent that you want a copy of the skill and adding it to your own roster, so you can evolve it to fit your needs, but I also have the skill on skills.sh and a plugin of all my skills if that's how you roll.

A single source of truth for AI agent permissions (Claude, Codex, Gemini, OpenCode)

Niels Madan — Mon, 18 May 2026 13:00:00 +0000

I bounce around between agents / harnesses, mostly just to see what's out there, but keeping their different configurations in sync can be a pain. Particularly, permissions drift quickly, so I built myself a little system to keep them in sync.

The idea is simple: create a single source of truth for all permissions, then generate the permission files for the agents (Claude, Codex, Gemini, opencode in my case) from it.

Here's an excerpt of the permission file:

[shell]

# allow — run without prompting on every agent.
allow = [
  # git — read-only
  "git status",
  "git log",
  "git diff",
  # ... gh, glab, file inspection, version checks, docker, xcrun ...
]

# deny — hard-blocked on every agent.
deny = [
  "git push",
  "git reset --hard",
  "git clean -fd",
  # ...
]

# ask — always prompt for confirmation, even in auto modes.
ask = [
  "heroku",
]

Full file.

Then we have a simple Python script that does the generation:

CODEX_DECISION = {"allow": "allow", "deny": "forbidden", "ask": "prompt"}

def codex_rule(entry, decision):
    tokens = ", ".join(json.dumps(t) for t in entry.split())
    return f'prefix_rule(pattern = [{tokens}], decision = "{decision}")'

def render_codex(rules):
    lines = []
    for category in ("allow", "deny", "ask"):
        decision = CODEX_DECISION[category]
        for entry in rules[category]:
            lines.append(codex_rule(entry, decision))
    # ... write lines to codex/rules/permissions.rules ...

There's one render_<agent> per target format, so "git status" becomes prefix_rule(pattern = ["git", "status"], decision = "allow") for Codex, "Bash(git status:*)" for Claude, and so on.

Full file.

Now we just have to add a guard to make sure we, and when I say we I mean some agent of course, don't accidentally ignore this whole setup. I use lefthook for all my git hook guarding needs:

pre-commit:
  commands:
    sync-permissions:
      run: python3 permissions/sync.py --check

sync.py --check regenerates everything in memory and diffs it against what's on disk. If anything is stale, it exits nonzero and the commit is blocked.

Check out my agentic coding config repo for more agentic coding config goodness.

Originally posted on nlsmdn.com. If this was useful, that's where I put new posts first.