Building PatchFlow for the QwenCloud Hackathon

Over the past few days, I've been building PatchFlow, an experiment in autonomous API reliability.
The idea started from a frustration I've experienced while building backend systems.
When an API fails, the workflow is often the same:

1. Reproduce the issue
2. Search logs
3. Trace the failure
4. Find the relevant code
5. Create a fix
6. Open a pull request Even with modern tooling, much of this process remains manual. I wanted to explore whether some of these steps could be automated.

The Idea
PatchFlow is designed to help developers move from:
Issue → Root Cause → Patch
The goal is not simply to detect failures but to assist with understanding and fixing them.
At a high level, the workflow looks like this:
Plain text
OpenAPI Specification
↓
Endpoint Discovery
↓
Reliability Testing
↓
Failure Analysis
↓
Root Cause Detection
↓
Patch Generation
↓
GitHub Pull Request

Early Challenges
One of the first technical challenges I encountered was endpoint discovery.
My initial idea was to scan repositories and automatically discover API routes regardless of framework.
The more I explored this approach, the more limitations I found.
Different frameworks expose routes differently:
FastAPI
Django
Express
Next.js
Spring Boot
Attempting to support every framework through repository scanning quickly became complex and inefficient.
Why I Switched to OpenAPI
After researching how existing API platforms operate, I realized that many tools rely on OpenAPI specifications rather than trying to discover endpoints from source code.
OpenAPI already provides:

• Endpoint definitions
• Request schemas
• Response schemas
• Methods and parameters

This allows PatchFlow to focus on reliability testing instead of route discovery.
The architecture immediately became cleaner and more scalable.

Building with QwenCloud
For this project, I'm using QwenCloud to power the reasoning and analysis components of the platform.
The ability to work through architectural tradeoffs, evaluate different approaches, and iterate quickly has been particularly valuable during development.
One example was evaluating multiple approaches for endpoint discovery before settling on an OpenAPI-first workflow.
That decision significantly simplified the overall system design.
Current Progress
So far I have:

✅ Defined the product architecture
✅ Chosen an OpenAPI-first testing workflow
✅ Planned GitHub integration for automated pull requests
✅ Started frontend development
Next, I'll focus on:

1. Reliability testing engine
2. Failure analysis workflows
3. GitHub patch generation
4. End-to-end demo preparation

What I'm Learning

One lesson from this project is that many successful developer tools are effective because they reduce complexity rather than add more intelligence
.
My original design attempted to automatically discover every endpoint in every framework.
The current design is simpler, more practical, and closer to how developers already work.
Sometimes the best solution is not the most automated one.
Looking Ahead
The goal for the remainder of the hackathon is to build a working prototype that can:

• Read an OpenAPI specification
• Test critical endpoints
• Identify failures
• Suggest a fix
• Generate a GitHub pull request

I'll continue sharing updates as PatchFlow evolves