Feeding My AI Workers Templates

Dev Leader Weekly 147

Jul 06, 2026

TL; DR:

Ralph loops make failed AI attempts cheap
My template library is the real unlock
First real end-to-end AI build succeeded
Join me for the live stream (or watch the recording) on Monday, July 6 at 7:00 PM Pacific!

Feeding My AI Workers Templates

I like doing these AI recaps after I’ve had a real stretch of time to sit down and actually build, and this one’s a good one. I recently had a week off work -- my wife was back in Canada visiting friends for her birthday, so I had the house (and the animals) to myself. I still ended up doing some work every day in some capacity, but I also had the flexibility to focus on what I actually wanted to build. Fair warning up front: this is an extension of the stuff I’ve been talking about recently with building things using AI.

You can check out my full thoughts on this in the video below:

Too Many Copilot Tabs, Not Enough Brain

For context: I lean on Copilot CLI for basically everything these days. I keep telling myself I should try other tools more -- I’ve poked at a few this year -- but the flow is working so well that pulling myself away feels actively disruptive. Add in the fact that I’ve got my token limits lifted, and there’s a lot of incentive to just stay put.

My day-to-day looks like juggling a handful of different repositories at once. There’s BrandGhost, the side business I run for automating social media posting and SEO work for other businesses. There’s Needlr, my dependency injection framework for .NET. There’s a consumer app I’m helping a friend build. And then a handful of smaller supporting projects on top of that. In practice, that means I’ve got a PowerShell window open with something like twelve tabs, and I’m just bouncing between them -- prompting Copilot in one, checking on another, prompting a third.

I saw someone online recently put a name to the mental toll of doing this -- and that’s really pointing to the significance of this way of working. Constantly juggling too many AI sessions is a real cognitive cost, and it’s messing with people’s heads a little. I’ve written about the context-switching problem before, but this is a new flavor of it -- it’s not just switching between tasks, it’s switching between agents, each with its own context, its own state, its own thing it’s in the middle of.

Ralph Loops, Orchestration, Spec Kit, and Templates

The system I’ve been building has multiple layers, and the important part is that every layer is optional on its own.

At the bottom is what’s known as a Ralph loop -- a pattern named after Geoffrey Huntley’s tongue-in-cheek nod to Ralph Wiggum, and it’s dead simple: a worker picks up a task, iterates on it inside some constraints, and if it doesn’t meet those constraints in the time it’s given, the work gets thrown away. No wasted human time arguing with an agent that’s gone sideways -- you just scrap the attempt.

On top of that sits an orchestration layer, which follows an open-source specification from OpenAI called Symphony. I’ve got my own C# implementation of it. This is the piece that schedules work across however many Ralph-loop workers are running.

And the third layer is an integration with Spec Kit -- GitHub’s open-source toolkit for spec-driven development. This is what lets you start the whole thing off just by handing it a spec. And I don’t know if I would call this a layer above or below the spec kit integration, but I have a template library that I am building for scaffolding. So it’s not exactly the same as spec kit, but it’s a a solo (or complementary) part of what the spec could include -- all up to my own standards and expectations for how I want something started.

Here’s the part I actually like: none of these layers are required. You can use the inner Ralph loop by itself. You can use the orchestration layer without ever touching a spec. Or -- and this is the version I’ve been testing -- you can hand the whole system a single one-shot prompt and let it use Spec Kit to build out the spec, then use the orchestration layer to schedule the work, then let the agents go execute it.

The One-Shot Calculator Test

To actually test this, I’ve been feeding it about as simple a prompt as I could come up with: “I want a desktop-based calculator app in C#.” That’s it. That’s the entire prompt, on purpose -- I wanted to see whether, given almost nothing, the system would actually finish.

Given how trivial that ask is, my bar was low: I expected spec documents to get created, and I expected a simple app with some buttons that does calculations -- the same basic calculator UI you’ve got on your phone. Tech stack didn’t matter to me -- WinForms, WPF, whatever, I wasn’t specifying it in the prompt. And since it’s such a simple app, I gave it a budget of an hour to get it done.

The early attempts weren’t failures exactly, but I wasn’t happy with them either. The problem was mostly glue -- the connective tissue between all the pieces. I’d come back and find it had burned 30 minutes retrying a single step because a worker session had literally frozen, or gotten stuck in a loop trying to build something it was missing a dependency for. That’s half an hour of a 60-minute budget gone to something completely silly, not to the actual work.

Eventually, though, I got a real end-to-end success. First one. And that felt like a genuine milestone, even for a calculator app -- because it meant the scaffolding, the orchestration, and the loop logic were all finally working together instead of fighting each other.

Why Templates Are the Real Unlock

If you take away one thing from this issue, I’d want it to be this: the real unlock isn’t the fancy orchestration layer. It’s the template library.

I’ve been building up a set of templates -- somewhere north of 10, under 20 -- that represent the foundation I’d expect for any codebase, depending on what I’m building. Want a desktop app in C#? I’ve got an Avalonia template that’s great for getting a cross-platform desktop app off the ground fast, which is exactly what kicked off the calculator build. Every one of these templates already reflects how I like to build things with a plugin architecture, and how I like to wire up dependency injection.

But a template isn’t just a starting solution file and a couple of projects. That’s part of it, sure. The bigger part is that every template ships with my coding standards already turned on -- analyzers and linters configured the way I want them by default. It also ships with my agent instructions: a library of shared instructions that match against file paths. So if an agent is working in a file that ends in test.cs, it automatically gets my standards for what a good test file looks like in C#. And because those instruction files are themselves templated, I can swap in different pieces depending on the stack -- xUnit instructions versus TUnit instructions, for example.

Actionable Tip: if you’re experimenting with anything like this yourself, don’t start with the orchestration layer. Start with a small library of your own project templates and coding standards. That’s the piece I use every single day, regardless of whether the fancier orchestration experiment ever fully pans out.

Put it together and the goal is simple: when I kick off a brand-new project, it’s scaffolded well from the very first commit, fully on autopilot -- instead of me getting an agent to reinvent my standards from scratch every single time.

This Isn’t Just For New Projects

The other half of this system isn’t about kicking off brand-new projects -- it’s about ongoing work. There’s a small web server sitting there listening, and I can just queue work items up to it. It schedules agents against that queue, and if a backlog builds up, an orchestrator looks at priority and dependencies and figures out how to work through it.

Some pieces of this I use constantly, some are still very much an experiment. The templating library and the reusable instruction files -- I’m in those every single day. Because I’m running across so many different Copilot sessions and repos, I keep spotting the same small pattern show up more than once: “oh, this is clearly a recurring problem, let’s get it into the instructions” -- and that feeds straight back into the template library. The same thing happens when I’m building a new feature: sometimes I realize I need a template for this shape of work, sometimes I realize I just need better instruction coverage.

That’s honestly why I’m not worried if the fancier orchestration experiment doesn’t pan out. The templating system is something I get value from regardless -- and it also syncs just the instruction files (not the whole template) across my different projects, so if I improve a standard in one repo, it can propagate to the others.

... Besides, people smarter than me I am sure are already lightyears ahead on the orchestration part!

Teaching the Agent to Ask About UX

After that first successful run, I went and looked at the actual calculator -- and it looked terrible. So I asked Copilot directly: based on the spec, was there anything in there about UX? Nope. Nothing.

So for the next attempt, I changed the one-shot prompt -- and I mean changed it barely at all, because I wanted to keep it close to a true “give it nothing” test. I just added one line: I want a consistently styled user interface that looks modern. That goes in right at the start, and then the same pipeline runs: Spec Kit turns it into a spec, orchestration schedules the work, agents execute.

The part that still catches me off guard, even though I built it: there’s an agent driving the entire Spec Kit conversation on my behalf. I didn’t invent that pattern -- it’s not novel -- but actually watching an agent have that back-and-forth about what I want built, fully hands-off, still feels a little nuts. When we’re this hands-off, we either need to expect things to be done in odd ways or provide significant enough guard rails to keep things on track.

Worth saying too: none of this requires Spec Kit at all. If I want to bring my own spec, or my own prompt, or skip that step entirely, I can just start a new repo and start sending work items straight to the queue. Those work items can just as easily be GitHub issues -- the system integrates with GitHub directly.

Turning This Into Real Eval Scenarios

Once I’ve got this working end-to-end reliably, the next step is turning scenarios like the calculator app into actual eval scenarios. The idea: define requirements that apply across every scenario -- has to finish within a given time window, has to stay under a token budget, has to actually deliver on the spec. That last one needs an LLM judge that reviews the spec against the output and decides whether it actually delivered. I’ve written before about building LLM-as-judge evaluation harnesses in C#, and this is exactly the kind of system that needs one -- I don’t have a ton of eval experience yet, so I’m actively building that muscle.

Why bother? Because it gives me a way to tune the system honestly. If I change how conflict resolution works, or how retries behave, or how work gets scheduled across multiple parallel workers, I want to be able to run it against a handful of eval scenarios and say “yep, this still meets my bar” -- instead of just eyeballing one run and hoping.

One optimization idea that came out of watching this calculator run: it only used a single worker because there wasn’t enough parallel work to justify more. But for anything more complex -- multiple workers, potential conflicts, retry logic -- there’s a real efficiency question buried in here. Instead of spinning up a brand-new working session for every single work item, what if a worker just kept reusing the working directory it’s already sitting in? If a build takes a minute, and you’re chewing through 10 work items, that’s a minimum of 10 minutes out of your budget spent purely on rebuilding from scratch every time. On a 60-minute budget, that’s not a rounding error -- that’s a huge chunk of it.

Why I’m Actually Doing This

Zooming out, I think about all of this in two ways.

The first is that I’m trying to build things, and using AI well, so I need to get better at building the scaffolding that makes AI effective -- that’s my templating library, that’s my instruction file library, and I’m actively working on both.

The second is that I’m experimenting because that’s genuinely how I learn best. Long before AI was part of the picture, this looked like me building a role-playing game as a side project -- not because I ever expected to ship a finished game, but because building it forced me to learn different corners of software engineering I wouldn’t have touched otherwise. Playing around with agent orchestration right now is the same instinct. I’m not sitting here thinking I’ve invented agent orchestration -- I haven’t, and there are people and companies way further ahead of me on this, which is completely fine. I’m happy to go use their stuff when it makes sense. This is just me playing around so I can learn, because that’s how learning has always worked for me.

If you’ve got questions about software engineering, AI, or your career, drop them in the comments, or head to codecommute.com and submit them anonymously -- I’ll make a video response for you and everyone else watching.

Dev Leader Weekly

Discussion about this post

Ready for more?