How I built PyFr with a plan, a writer, and a reviewer

🧭 The workflow

Here’s the loop I followed for each milestone:

PyFr was not a one-prompt project. I used agents to build PyFr, but the part that mattered most was the workflow around them:

1. Use the agent to plan the whole project, not just the next function.
2. Build with Claude Code + Superpowers, so planning becomes an artifact instead of a vibe.
3. Use GitHub Copilot to review the pull requests.
4. Keep the reviewer different from the writer. Claude wrote the code, and GPT reviewed it.

I don’t start with code. I start with one long planning session with the agent.

That session turns intent into artifacts: the project’s purpose, constraints, architecture, milestones, and review gates. It is slow, yes — but it is worth it, because the plan becomes the shared global context instead of living only in my head.

This is not outsourcing design. It is making the workflow explicit enough that the model has room to reason, and separating writing from reviewing.

🧩 Start with a plan, not code

Before touching implementation, I used the agent to think through the project itself: what the service should do, what constraints mattered, and what the milestones looked like.

Superpowers helped here. It turns “use the agent to plan” into something more concrete, with artifacts and review steps instead of just vibes.

That mattered because the plan became the shared context. The agent could then build against it, and I could judge the work against the same shape we had already agreed on.

🔁 Separate writing from reviewing

The second habit was to let a different model review the work.

Claude Code wrote the code. Copilot reviewed the pull requests.

That does two things:

• The writer gets a chance to finish its own thought without immediately having to defend it to itself.
• The reviewer has a different set of blind spots.

This is not a claim that the reviewer is always better. It is about catching different kinds of mistakes.

A recent paper on cross-model review, When Does a Second Model Help? Cross-Model Review in LLM Verification, makes this nuance honestly. It found that cross-model review can help, but not because model difference is magic. In one comparison, one fresh same-model review plus one cross-model review matched more planted errors than two fresh same-model reviews. The useful part is that the models can catch partly different errors.

So I did not want a model grading its own homework. I wanted two different minds looking at the same work.

🧭 Make the plan survive the build

Once the plan was good, the actual build was not a stream of “write this for me” requests. It was a set of smaller, scoped steps. That included making sure the generated service was readable, testable, observable, and not accidentally coupled to my own internal tools.

That is the piece most people miss. The useful agent workflow is not “ask a better question.” It is “design a system where review is cheap, explicit, and not done by the same model that made the mistake.”

🔗 The result

The result is PyFr — a cookiecutter template for production-ready Python microservices. It is not a framework, and it does not try to own everything. It glues the right packages into a working service.

I wrote a separate post about why PyFr glues packages into a service, if you want the design story.

The workflow mattered as much as the code. Planning up front, scoped execution, and cross-model review are what made it work.

🔗 Conclusion

Agents are useful, but the workflow around them matters more. For PyFr, the combination of Claude Code, Superpowers, and Copilot gave me a way to keep the work readable, testable, and honest.