Congrats on the launch! One piece of feedback - I find the tagline confusing. I had no idea what "post-code tasks" meant until I clicked around and saw a few examples.
We have tired a few different ways to convey what we do but it is hard. We want to refer to all software development activities that happen after the developer commits the code into a source control system. “Post-code” seemed a good way to capture that.
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.
Thanks for trying - and for the fair feedback! We'll look at the AutoFix result and improve it.
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.
Certainly agree about the bottleneck around DevSecOps. I wonder if this might be useful for the typical "scan everything, patch everything, SBOM for everything" loop that typically lands on DevOps teams and becomes a classic devops tug-of-war situation.
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!
We think this does reduce DevSecOps friction - even simple things like passing scan results through an LLM to eliminate obvious false positives have an outsized impact.
Thanks for giving it a shot - look forward to hearing your feedback!
Dev teams—especially in larger organizations—need to perform many repetitive tasks outside of code generation. Patched helps them create automation for those tasks in a way that can meet their specific needs around customization and privacy. Hope this clarifies? :)
- 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.
We were reluctant to add a chat interface at first tbh, but there were so many real-world cases where a single-pass interaction just wasn't enough. Debugging logs is another case.
Congrats on the launch! One piece of feedback - I find the tagline confusing. I had no idea what "post-code tasks" meant until I clicked around and saw a few examples.
That’s funny because I knew exactly what it meant. And I think that it’s a clever way to differentiate what they do.
We have tired a few different ways to convey what we do but it is hard. We want to refer to all software development activities that happen after the developer commits the code into a source control system. “Post-code” seemed a good way to capture that.
Congrats on the launch; the idea and process is a good one, but the results so far are less impressive.
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.
Thanks for trying - and for the fair feedback! We'll look at the AutoFix result and improve it.
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.
Certainly agree about the bottleneck around DevSecOps. I wonder if this might be useful for the typical "scan everything, patch everything, SBOM for everything" loop that typically lands on DevOps teams and becomes a classic devops tug-of-war situation.
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!
We think this does reduce DevSecOps friction - even simple things like passing scan results through an LLM to eliminate obvious false positives have an outsized impact.
Thanks for giving it a shot - look forward to hearing your feedback!
I thought "post-code" was referring to an era when we don't code anymore, because AI does it all. Made my heart jump a bit.
Sorry to give you that scare - Happy Halloween I guess? ;)
still not sure what the value add is here
Dev teams—especially in larger organizations—need to perform many repetitive tasks outside of code generation. Patched helps them create automation for those tasks in a way that can meet their specific needs around customization and privacy. Hope this clarifies? :)
What are some examples of those tasks? It’s difficult for me to tell what problems this is intended to solve
Sure here are some examples:
- 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.
“AI workflows”
read: we sprinkled some LLM prompts and some job orchestration
We tried our best to be transparent about our approach - you can actually download the code for the workflows from the app.
Genuinely curious - what more would you expect with 'AI workflows'?
It's cool that there's a chat interface in addition to the PR's. I find that for most reviews a little bit of back and forth is helpful.
We were reluctant to add a chat interface at first tbh, but there were so many real-world cases where a single-pass interaction just wasn't enough. Debugging logs is another case.
Its seems very nice, I will try it