There is a lot of excitement around code generation and the development inner loop. But having built DevSecOps startups previously, we know how the bottlenecks developers face often occur in the “outer loop”, especially after the code is written. With Patched, we want to help code get shipped as fast as it is generated.
Patched has two core components. First is the workflow builder that switches seamlessly between no-code and full-code. Second is the chat-based query interface for your code, logs, and issue tracker. When used together, they can help orchestrate and automate the most painful parts of the software development lifecycle.
Here is an example PR created by a patchflow that automates SDK generation with complex type information: https://github.com/stack-auth/stack/pull/300.
Under the hood, Patched is powered by our patchwork library (https://github.com/patched-codes/patchwork) and an LLM optimization proxy(https://github.com/codelion/optillm) - both of which we have open-sourced. You can run these workflows within your CI/CD pipeline, or from the command line, completely independent of our platform. This gives you full control without being locked in, while allowing us to build a monetizable product around it.
While there are some great point solutions for tackling individual tasks, we believe the real solution lies in an open, holistic approach—one that teams can tweak, extend, or self-host.
You can try Patched at https://app.patched.codes/signin - we’d love to hear your feedback on our approach and the user experience.
I'll be trying the free-tier to accomplish this on a hobby project at some point soon, will try to provide feedback! Proof of patching, SBOM, compliance stuff is IMO one of the best moats existing companies have against newcomers - developers typically _hate_ security patching work - so there's money in that use-case for sure!
Oh, edit: Congrats on the launch!
Thanks for giving it a shot - look forward to hearing your feedback!
For a simple PoC typescript CLI tool I had, AutoFix decided to do this several times:
https://i.postimg.cc/1z4Fs663/Screenshot-2024-10-31-at-21-37...
In a straight forwards repo with no README it created a reasonable starting point.
Yet in a more complex repo with an existing and comprehensive README, it decides to replace it completely with a simple one, removing key insights. I suspect the existing README isn't considered at all, making this kind of patch incompatible with most workflows (i.e. creating a README once isn't particularly onerous, keeping it up to date is).
This may be a project to watch, but I'm disinclined to use it at the moment.
Our goal with the default patchflows is to provide a starting point/template and let you tailor it to your needs from there. E.g. with the 'Generate README' workflow, you can add the 'Read File' step to read the existing file and pass it to the context to update it rather than generate a new one from scratch.
- Ensuring compliance with internal engineering standards/coding conventions. - Documentation for change management compliance. - Ensuring no critical/high vulnerabilities in code as flagged by scanners. - Updating tests to maintain code coverage. - Reviewing APM logs (like Sentry) to identify real bugs v/s false alarms.
Given a certain scale, each of these tasks become repetitive enough to warrant some degree of automation.
Also, do you know post code is British for zip code? I thought it was something to do with that.
read: we sprinkled some LLM prompts and some job orchestration
Genuinely curious - what more would you expect with 'AI workflows'?