In a YouTube walkthrough, Michael Shimeles demonstrates how a file of instructions coordinates his coding agents. His “software factory” uses reusable skills, each describing how to do a particular job:

I built my own software factory. Now, when you hear that phrase, you’re probably thinking of a giant custom harness, and that could be far from the truth. To be frank, a proper software factory is more about your workflow, skills, and domain knowledge more than it is the harness. So, a software factory should be harness agnostic and model agnostic.

The harness is the software that runs the coding agent and gives it access to tools.

Shimeles’s instruction file, AGENTS.md, specifies four stages: isolate, build, prove, and ship. First, each agent gets separate working files and a branch for its task, using Git worktrees. That prevents agents from overwriting each other’s working files, though shared resources still need coordination. During the build, a skill specifies how to organize the code. Shimeles explains:

This is just basically a way I like code to be structured because if it ever come a time where I have to manually review this code like it’s 2022 or something then it’s written in a way that is easy for me to digest and get used to. Right?

So for the developers you might disagree with a service architecture. You might want it written in a different way. The point for this is get this skill written in such a way where the code written makes sense to you. For me, a service layer architecture makes sense for me.

Then the agent runs checks and captures the changed behavior. For a visual change, before-and-after images accompany the request to merge the code, called a pull request or PR. An automated code reviewer, Greptile, supplies feedback for the agent to address before passing the PR to Shimeles:

This is not getting merged by me until I get a five out of five. So, my software factory will continue to read the feedback from Greile and then will only give me the PR URL once it’s got a five out of five. Once we’ve reached five out of five status, it’s my job to look at before and after. It’s my job to read the description and then I just merge.

The score doesn’t guarantee correct code. I’d treat the before-and-after evidence as something to inspect separately from the reviewer’s confidence. His shared skills limit the number of review iterations and spell out what’s needed to capture evidence, so there’s setup and adaptation involved in copying this workflow.