News for hackers. Stuff that matters.

lumax15

Re:Show HN: Incorporating AI in engineering on-call workflows on Tuesday February 04, 2025 @06:12PM (#42940566)
We built out a few mechanisms to make sure Lynx only automatically perform safe actions, and you have complete control over it’s access and behavior:

1. Users can set whether Lynx commands run automatically or manually. In manual mode, users can approve, edit, or reject commands before they execute.

2. When manual mode is off, the model was trained to only automatically execute read-only commands. Although it’s theoretically possible to still execute unsafe commands, we audit this internally and have a 0% error rate.

3. Our system supports fine-grained RBAC for various integrations (such as DataDog, Kubernetes, cloud providers), allowing you to grant specific permissions for investigation tasks while restricting sensitive operations.

Re:Show HN: Incorporating AI in engineering on-call workflows on Tuesday February 04, 2025 @05:01PM (#42939541)
Lynx can actually automatically integrate with many dev tools!

You can directly connect Lynx to your environment by installing a lightweight agent on your servers (devbox or dedicated server). This agent leverages unix commands to interface with your systems—including your codebase, logs, metrics, tracing, CI/CD, and cloud services.

The agent uses “chain-of-thought-execution” to automatically explore resources, tooling, configurations, and other context within your environment, so you don’t need to explicitly set up any integrations. We do find that setting specific instructions (e.g. /path/to/git_repo, where credentials are stored, etc) helps Lynx be more efficient, and we set up an easy UI to do this.

Some integrations like Pagerduty, Slack, Jira still need to be manually set up though. Full deployment instructions are available at https://docs.uselynx.ai.

Show HN: Incorporating AI in engineering on-call workflows

Hello HN! My name is Max, and I’m a co-founder at Lynx (https://uselynx.ai). We’re building an AI-powered incident resolution platform to help engineers debug and resolve on-call issues faster. If you’ve ever been paged in the middle of the night and had to spend hours piecing together logs, metrics, and code, we’d love your feedback.* The Problem *On-call hasn’t kept pace with modern...

( Read More... | 4 comments | 6 points | on HN )
Let's talk :). Congrats on the Pynecone launch!
Code discovery and search have been great applications of Copilot and other AI dev tools!
Great questions. We want to keep some of our technical details closer to the chest, so I won't go into the specific technologies we're using here.

I will expand a bit on fine-tuning. It's really hard to get this right, and the iteration speed is slow. Of course these companies can build their own, but we want to save them a lot of headache.

So far, we haven't found any off-the-shelf open source base model that works super well for code completions. We've augmented models with a huge amount of data in order to see our current performance, and we ran into a lot of pain along the way.

This is good for some business teams, but it still doesn't offer self-hosting or fine-tuning.
Let us know, swatcoder!
Thanks ninjaa!
Thanks enono :)
We don't have any rigorous benchmarks against Copilot, but we're working on building an evaluation framework to do so. We've played a bunch with traditional academic metrics for codegen (e.g. pass @ k) and found they don't correlate super well with real-world performance. Also, want to mention that we are not competing directly with Copilot. A benchmark against Copilot is useful as we further improve our product, but our main value add here is not that we perform better than Copilot, but rather that we serve a customer segment that can't use Copilot. Would love to hear any thoughts you have.

For training, we start with a capable open-source base model, augment it with a bunch of permissively-licensed repos, and then fine-tune on the customer codebase.

We currently support C/C++, Go, Gosu, Java, Javascript, Python, Ruby, and Typescript, but we're continuously adding new languages.

Couldn't agree more :)
We're starting off with an open source base model that was trained on The Stack, a dataset containing only permissively-licensed code, and we're further augmenting it with additional repositories with MIT, BSD, or Apache Licenses.