Closing the Loop in the Software Factory

If you're following with latest in the AI space, you would've definitely seen the term ‘software factory’ everywhere by now. It's not a new term, but rather being brought into light again due to how competent the frontier agents have become.

The idea is simple: coding agents could do most of the production work, and people set the intent and approve what ships.

To some, it feels like a paradigm shift for software developers. A talk I watched recently by Zach Lloyd explains it as “You won't be building the product. You'll be building the thing that builds the product”.

And whilst I've been iterating and building my own factory of sort, one of the things that struck me in this talk was the Retro stage. This is a little humorous because at SSW, every sprint, and every event has a retrospective meeting - sometimes it just feels like following the motions, but good retros work for one simple reason; theres an action point at the end.

Retro-fitting a retro

I didn't start from scratch, a couple weeks ago I stumbled across Matt Pocock's Retro skill; so I copied it over and used it *sparingly *in my day-to-day development.

The catch was I had to:

a. catch the friction point

b. remember to run it

The most tiring part of working with AI agents is typing the same correction for the third time, and whilst each one is small, the annoyance can build up.

The night shift

So connecting all of this together I created my version of ‘the night shift’. I used Matt's retro skill as a base and created my own version - every night a scheduled job reads the day's agent sessions and looks for friction points; times I corrected the agent, rejected tool calls or reverted its work.

All logged to a ledger, and when it presents itself as a pattern, a proposal is created. The proposal is an actionable outcome that sees to fix the problem, i.e. updating a skill, a hook, or just a one liner in my CLAUDE.md file.

Each morning I wake up to the suggestions from the day before and get the opportunity to either implement or skip the changes.

The nice thing is this catches trends across numerous sessions, not just anti-patterns observed in a single thread.

End

I've seen some small wins in this process; but it makes sense to me why - our skills, plugins and AI config should contain 2 essential characteristics:

• They're alive - they evolve with time and usage
• They're yours - they're shaped by your workflow and your frictions