rohansood15

8 ms·

91.
Show HN: Open-source library documentation for LLMs(docs.codes)
12 points by rohansood15 2y ago|0 comments
92.
by rohansood15 2y ago
We use Vercel and have configured a way to pull the dev environment keys from there. This is of course a very tech stack-specific solution.
93.
No-Code is Trash [video](youtube.com)
3 points by rohansood15 2y ago|1 comments
94.
by rohansood15 2y ago
Not affiliated with FlutterFlow, but I found the first few minutes of the video very compelling - especially when you put it in the context of AI chat interfaces and flow builders. Is there ever a point where a 'code-native' devel
95.
by rohansood15 2y ago
This is cool. Reminds me of my internship days when I had to build a custom 8086 emulator in Java, and I went down the rabbit hole of trying to figure out the best way to represent the architecture.
96.
by rohansood15 2y ago
While this isn't surprising considering how bad it was, it is surprising considering that they recently announced the whole Amazon Q for software development thing. Who's going to trust them with Dev tooling now?
97.
by rohansood15 2y ago
Linters are great at finding syntactical errors like the case you mentioned. But LLMs do a better job at finding logical flaws or enforcing things like non-syntactic naming conventions. The idea is not to replace linters, but to complement
98.
by rohansood15 2y ago
We do. We haven't done a very good job of listing good first issues, but please feel free to create and contribute.
99.
by rohansood15 2y ago
This is where prompting and context is key - you need to keep the scope of the review limited and well-defined. And ideally, you want to validate the review with another LLM before passing it to the dev. Still won't be perfect, but you
100.
by rohansood15 2y ago
I agree and disagree. You definitely need someone competent to take a look before merging in code, but you can do a first pass with an LLM to provide immediate feedback on any obvious issues as defined in your internal engineering standards
101.
by rohansood15 2y ago
There are a few open source projects by the name and we were aware of https://github.com/ssbc/patchwork which is archived. Didn't know of this though. It's a common noun which works really well for patch-base
102.
by rohansood15 2y ago
Aider is great, but the use case is different: 1. You use Aider to complete a novel task you're actively working on. Patchwork completes repetitive tasks passively without bothering you. For e.g. updating a function v/s fixing lin
103.
Show HN: Patchwork – Open-source framework to automate development gruntwork(github.com)
116 points by rohansood15 2y ago|24 comments
104.
by rohansood15 2y ago
I am guessing these are prices on services like AWS Bedrock (their post is down right now).
105.
by rohansood15 2y ago
That license is just hilarious.
106.
by rohansood15 2y ago
Copilot primarily uses GPT-3.5, which is outclassed by Llama3-70B. And this model claims to be slightly better than Llama3-70B. Edit: For those who don't believe me, https://github.com/microsoft/vscode-copilot-rele
107.
by rohansood15 2y ago
Not the same, but we evaluated how good LLMs are at fixing code and just posted it on HN: https://news.ycombinator.com/item?id=40511689
108.
by rohansood15 2y ago
The sentry demo makes me wonder if this chat-based, IDE interface would be the preferred go-to for Devs for multi-tool, multi-step workflows? Or would they prefer to automate the flow as a background, asynchronous task?
109.
Show HN: Patchwork – Open-Source AI Workflows for Dev Chores(github.com)
5 points by rohansood15 2y ago|0 comments