Hey there! If you’ve followed this series, you’ve seen 23 patterns, a messy baseline and a capstone. What I haven’t told you yet is that an AI agent wrote most of that code.

The repository went from an empty folder to a tagged v1.0.0 in about five days, built with Microsoft HVE Core running on GitHub Copilot. This post is about how that worked, what I actually did, and the moments where the guardrails earned their keep.


Agenda:

  1. What Is HVE Core?
  2. Briefs, Not Prompts
  3. Guardrails That Don’t Rely on Memory
  4. The Build, Step by Step
  5. What the Gates Caught
  6. What I’d Tell Anyone Trying This

What Is HVE Core?

HVE Core (Hypervelocity Engineering) is an open-source collection of agents, prompts, instructions and skills for GitHub Copilot. The part I used most is its RPI workflow: Research, Plan, Implement, Review.

The idea is simple, but it changes how the agent behaves:

  • Research only when there’s a real gap in what’s known.
  • Plan before touching any code, and have the plan independently critiqued.
  • Implement the approved plan phase by phase, recording every change.
  • Review the result against the original requirements and acceptance criteria.

Every step writes a file into a .copilot-tracking/ folder: the plan, its critique, a change record and a review. I committed all of them, so anyone can open the repository and see exactly how each part was planned, built and reviewed. In the end that’s 27 plans, along with their critiques, change records and reviews.

flowchart LR
    Brief[Brief in prompts/] --> Plan[Plan and critique]
    Plan --> Implement[Implement phase by phase]
    Implement --> Review[Review against acceptance criteria]
    Review --> Human[I commit and push]
    Human --> CI[CI: build, test, golden master]
    CI -->|green| Next[Next brief]

Briefs, Not Prompts

The single most important decision I made was to not ask the agent to “build a design patterns repo”.

Instead, I planned the whole thing up front (I used Claude to help me turn the plan into briefs), and wrote it down as a folder of markdown files called prompts/:

  • 00-project-brief.md: the shared context. Settled decisions, the folder structure, all 23 smells, the pattern map, the golden master, the definition of done. Every task reads it.
  • One brief per task: foundations, the baseline, two pilot patterns, then a template for the other 21. Later: comparisons, the capstone, the READMEs and the release.

Each brief has the same shape: requirements, acceptance criteria, boundaries (“never edit the baseline after it’s tagged”) and suggested phases.

Why does that matter so much? Because HVE Core’s RPI workflow plans and reviews against a bounded scope. “Apply Facade to this one seam, and here’s how you’ll know you’re done” gives an agent something it can actually verify. “Build the whole thing” doesn’t.

The decisions section did a lot of quiet work too. Things like C# on .NET 10, one full copy of the baseline per pattern and project names never change were marked as settled, so the agent never wasted time re-arguing them.

Guardrails That Don’t Rely on Memory

Here’s a problem specific to this project: the baseline is messy on purpose. An AI coding assistant’s natural instinct is to clean up messy code. One helpful “let me tidy this switch statement” in the wrong place, and a planted smell is gone.

So alongside the briefs, the repo has Copilot instructions that apply to every interaction, RPI or not:

  • .github/copilot-instructions.md for repository-wide rules: smells are intentional, one pattern per seam, never touch the golden master, no pushing.
  • Path-specific instruction files for baseline/** and patterns/**, with stricter rules for each.

The briefs say what to build. The instructions say how to behave while building it.

And the biggest guardrail of all was the golden master test from Meet CornerStore. Every refactor had to reproduce the baseline’s 417-line transcript byte for byte. That one test meant I never had to trust that the agent preserved behaviour. The build proved it every time.

The Build, Step by Step

Foundations. The agent planned first and came back with four questions before writing a file: xUnit v2 or v3? Who holds the copyright? Should line endings be forced to LF so the golden master doesn’t break on Windows? Plain README or front matter? Good questions. I answered them, and it built the skeleton and CI.

The baseline. This was the one I ran manually, one phase at a time, reviewing every planted smell before committing. It’s the code everything else copies, so a mistake here would be copied 23 times. Planning surfaced some genuinely important things:

  • The snapshot-testing library I’d planned to use now required declaring a licensing status in the build, and would break every build once that declaration expired. We dropped it and wrote the golden master as a plain file comparison instead.
  • The brief’s suggested phase order wouldn’t actually compile (checkout needs pricing first), so the agent reordered it into 11 phases.

The patterns. Once the baseline was solid, I switched RPI Agent to Full Auto and gave it an orchestration brief: finish the baseline, run the two pilot patterns, apply their lessons to the template, then generate and run the other 21. It stopped once, by design, so I could review the baseline before it was tagged and copied. Then it worked through the patterns overnight.

At one point the chat ran out of context mid-pattern. No drama: the agent kept a progress file, so I opened a new chat, pointed it at the file, and it picked up exactly where it stopped.

The final tally: 24 tasks (the baseline plus 23 patterns), every one reviewed. Nine came back as Conformant, and fifteen as Conformant with justified divergence, each divergence written down with a reason.

Then the extras: the comparisons guide, the capstone (24 commits, one pattern each), the READMEs and the release.

What the Gates Caught

This is the part I find most interesting. The agent made mistakes, like any developer would. What mattered is that the process caught them.

  • A bug in its own tooling. During the very first pilot, the agent found that the script generating each pattern’s DIFF.md broke in a specific case. It flagged the bug in its review, worked around it and kept going. Later we fixed it properly.
  • Duplicate project names. Every pattern deliberately uses the same project names. That’s fine for each pattern’s own solution, but the umbrella solution that CI builds choked on several identical names in one folder. Every pattern passed on its own. The whole repository didn’t build as one. The fix was to give each pattern its own folder inside the umbrella solution.
  • Line endings, again. CI regenerates every DIFF.md and checks it matches. Files generated on Windows didn’t match files generated on Linux, because of how line endings changed git’s internal hashes. The diffs looked identical to a human, so only an automated check could catch it.
  • The agent refused to start. My favourite moment. The capstone brief said “start only when CI on main is green”. CI wasn’t green, because of that line-ending issue. So the agent didn’t start. It created its plan, stopped and told me exactly which CI step was failing. That’s precisely what a good engineer does.
  • A leftover marker. The capstone’s final check, zero SMELL markers, found one that an earlier step had missed.

None of those were caught by me reading code. They were caught by tests, CI and written-down acceptance criteria.

What I’d Tell Anyone Trying This

  1. Write the plan down before you open the chat. Briefs with acceptance criteria beat clever prompts every time.
  2. Settle decisions explicitly. Anything you leave open, the agent will reasonably spend time researching or asking about.
  3. Make correctness checkable. A golden master, tests and CI turn “I hope it’s right” into “the build says it’s right”. That’s what makes Full Auto safe.
  4. Go manual where mistakes multiply. I stepped through the baseline phase by phase, and only went fully automatic once the template was proven.
  5. Read the questions the agent asks. Its planning questions caught a licensing trap I would have walked straight into.
  6. Check CI after every push. CI had gone red after the big automatic run, and it was the agent’s own preflight check that noticed. Lesson learned.
  7. Keep the externally visible decisions human. During the automatic run, the agent could commit and tag locally. But it never pushed or published anything. Getting code onto GitHub was always my call, after reviewing.

Was it faster than doing it by hand? Enormously. But the speed came from the structure, not the AI on its own. Without the briefs, the instructions and the gates, I’d have got 23 plausible-looking folders and no way to know which ones were right.

The agent brought the speed. The fundamentals decided where it went, and proved it got there. Tools evolve. Fundamentals remain.

The prompts/ folder and the .copilot-tracking/ folder are both public, so you can read every brief I wrote and every plan and review the agent produced.

That’s a wrap on Gang of Four in Action. Thanks for following along, and a huge thank you to Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides for a book that still teaches us so much, more than thirty years later.

As always, if you have any comments, suggestions, or feedback, I’d love to hear from you!

Happy Coding!

Previous: The Capstone · Back to: Introduction