Hacker News: Front Page

Evidence (YC S21) Is Hiring Software Engineers

hughess — Mon, 19 Oct 2026 17:21:33 +0000

Comments URL: https://news.ycombinator.com/item?id=50155172

Points: 0

# Comments: 0

Launch HN: Laminar (YC S24) – We trained a model to catch silent agent failures

skull8888888 — Mon, 19 Oct 2026 16:00:18 +0000

Hi HN, we’re Robert and Din from Laminar (https://laminar.sh). We’ve been building open-source observability for AI agents since 2024. Recently, we released flow-1, a model trained with RL to find errors in agent traces. On our benchmark (https://laminar.sh/blog/flow-1), it matches GPT-6-sol in detection quality while being 23x cheaper. This makes it affordable to analyze every production agent trace, without sampling.

Here’s a one-minute walkthrough: https://youtu.be/KJa3h6ZJNLQ

We also put together a post with example traces and analyses from flow-1 and other models: https://laminar.sh/blog/flow-1-in-action

Agent observability is crowded, so instead of a bullet list of how Laminar differs from X, we’ll explain how we’re solving agent observability from first principles.

Agents now run for many steps and fail implicitly. An agent can click the wrong button or cite the wrong document while every call completes successfully. These errors are the most useful ones to catch and understand. To find them, you need to understand what the agent was trying to do and inspect its LLM calls and tool results. Simply looking at the final agent output is not enough.

Collecting traces alone doesn’t solve this. A lot of agent observability platforms are still data collectors at their core. You can end up paying to store traces that nobody has time to read or extract value from.

Using another LLM to inspect traces is THE solution, but capable models are expensive at scale and cheaper ones often miss errors or flag unrelated things.

So we built our model to solve exactly this problem. We finetuned a small OSS model and then post trained it with RL on thousands of synthetic investigations of realistic agent workflows in software, legal, customer support, etc. We got a model that is both good at agent trace analysis and very cheap to run.

flow-1 runs inside a harness we call Signals. It acts as a coding agent, treating an agent trace like a repo, with each span (an LLM call, tool call, etc.) as a file. It starts from a compressed string representation of a full agent trace and a user prompt, then greps across spans and reads the relevant ones in full.

The beauty of Signals is that it can respond to a general prompt. You can ask it to identify user frustration, check whether your browser agent completed a checkout, and so on. It’s not limited to raw error detection. It returns findings as JSON in a schema users can freely define. We call these signal events.

Once you’re analyzing every trace, you also have too many individual events to read. That’s why we automatically group similar signal events into clusters. You can see recurring problems and how often they happen, then drill into individual events and the traces behind them.

You can use traces from a cluster to build an eval dataset for that type of failure. You can then use your favourite coding agent to hillclimb on those evals and check that the fix works across these cases before shipping it to prod.

Trace → analyze → catch errors and form clusters → fix → release. Making this loop easy is why we built Laminar.

We’ve put the same thought into the rest of Laminar. Our blog (https://laminar.sh/blog) explains how looking closely at how agents actually work led us to build 20x trace compression, a custom SQL query engine and automatic task extraction.

Laminar is Apache 2.0 and self-hostable (https://github.com/lmnr-ai/lmnr). We make money from the managed cloud.

We’d love to hear how you track your agents’ performance today. How much do you learn from user feedback versus your own monitoring? And when you fix something, how do you check that it hasn’t introduced a different failure?

Comments URL: https://news.ycombinator.com/item?id=50154029

Points: 18

# Comments: 4

Degraded availability for GitHub Actions, GitHub Pages and Webhooks

gateauxd — Mon, 19 Oct 2026 15:52:26 +0000

Article URL: https://www.githubstatus.com/incidents/8tzbpcnl75jp

Comments URL: https://news.ycombinator.com/item?id=50153934

Points: 107

# Comments: 82

CERN and Mistral join forces to accelerate AI for science

kensai — Mon, 19 Oct 2026 15:28:24 +0000

Article URL: https://home.cern/cern-and-mistral-join-forces-to-accelerate-ai-for-science/

Comments URL: https://news.ycombinator.com/item?id=50153630

Points: 126

# Comments: 18

Ontology-Driven Observability: Building an End-to-End Knowledge Graph at Netflix

tosh — Mon, 19 Oct 2026 15:10:20 +0000

Article URL: https://netflixtechblog.com/ontology-driven-observability-building-an-end-to-end-knowledge-graph-at-netflix-scale-421392cf5adf

Comments URL: https://news.ycombinator.com/item?id=50153431

Points: 70

# Comments: 17

Maybe There Was an Egg Cartel After All

iamnothere — Mon, 19 Oct 2026 14:31:11 +0000

Article URL: https://www.politico.com/news/magazine/2026/10/18/egg-prices-conspiracy-affordability-issue-01100411

Comments URL: https://news.ycombinator.com/item?id=50152970

Points: 125

# Comments: 97

A hacker broke into John Deere and SharkNinja with an army of AI agents

dkobia — Mon, 19 Oct 2026 14:23:17 +0000

Article URL: https://www.theverge.com/ai-artificial-intelligence/1013643/ai-agents-hack-john-deere-shark-ninja-cummins

Comments URL: https://news.ycombinator.com/item?id=50152877

Points: 45

# Comments: 3

Show HN: KiviDB, a faster Redis-compatible memory database and vector cache

murtazayusuf — Mon, 19 Oct 2026 13:53:52 +0000

Hi all,

So I have been working on this project KiviDB from February 2026. It started as a project for me to understand rust, having a product with no GC pauses, memory blow up after snapshots and getting OOM on running pods, and that was actually an issue I faced with Dragonfly. I wanted to have something picking the best of Rust, but also picking the best parts of other alternatives like Garnet and Dragonfly. I used AI a lot, but I was the one making the design decisions based on the tests that claude picked from my history of troubleshooting sessions as part of my job. KiviDB supports both RESP2 and RESP3 protocol. I had some founders credits on my AWS account which helped me with the infra, and running instances I could perform benchmark on.

Its keyspace is sharded across threads, it is multi-threaded in nature, and performs best on Linux due to io_uring, I used the tokio_uring crate for this. It also has tokio fallback for other OS's. I hadn't open sourced it until recently as I felt it was not ready yet, the best way to learn it was to build a cloud managed service for it across all three widely used cloud providers i.e AWS, GCP and azure. Since I used to mainly work with cloud, I had some insights on what would be the best ways for the deployments, how to conduct failovers, manage SLAs, etc. And that's what I took help from claude to fast pace it. The website does look like AI slop but it works for now, given my limited resources, that's all I had. You may check it out at : https://kividb.io, I open sourced the core engine under AGPLv3, didn't want to have just source available, because that is available with other tools too. It supports apprx 98-99% of the redis 8.10 commands, few have issues and you can find them at https://github.com/kividbio/kividb/issues, contributors are welcome.

Now the numbers, for the final benchmark, I used 2 c7gn.metal servers, in the same placement group in us-east1, and I used memtier-benchmark tool for this. The setting was : 10M keys, 100B each, 32 cores in use with both pipeline and un-pipelined runs.

pipeline 16 GET: KiviDB 21.2M ops/sec vs Dragonfly 2.0 9.1M, Redis 8.10 2.4M, Redis Cluster 32 shards 4.7M

When not pipelined, Dragonfly performed slightly better at 3.35M ops/sec vs kividb at 3.07M ops/sec. Memory per key was also slightly worse than dragonfly and almost same as Redis, 177B (kividb) vs 134B (dragonfly) vs 178B (redis).

With vector ingestion times it was slower but when querying, it was faster than most alternatives at lower ef, however slower than dragonfly at high ef. Most of the technical details are mentioned here so you can check it out: https://kividb.io/benchmarks.

easiest way to try it: docker run -d -p 6380:6380 kividb/kividb

I am looking forward to building a community around this, provide better rust based tools, I am open to constructive criticism and value informed opinion. Thanks

Comments URL: https://news.ycombinator.com/item?id=50152541

Points: 47

# Comments: 20

Plex vulnerabilities being exploited in the wild to drop a cryptominer

mindracer — Mon, 19 Oct 2026 13:36:43 +0000

Article URL: http://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html

Comments URL: https://news.ycombinator.com/item?id=50152321

Points: 39

# Comments: 5

Wine Ported to OpenBSD

iamnothere — Mon, 19 Oct 2026 13:35:34 +0000

Article URL: https://marc.info/?l=openbsd-ports&m=179236125692175

Comments URL: https://news.ycombinator.com/item?id=50152307

Points: 290

# Comments: 76

Show HN: I built a task system to handle the drudgery so I could focus on tasks

dmayle — Mon, 19 Oct 2026 13:07:07 +0000

I'm a software engineer from the east coast (who has lived in Boston, NY, the bay area, UK, France), and I built a task system called 3 & Done. It's the place you trust to store everything you need to do. It accepts voice input for rapid entry, as well as text (it stores the audio locally so you can listen to jog your memory) and emails you every morning with the three most important things for you to do that day, and why, based on what you've said about the task: deadlines, urgency, sitting too long.

I've been at software engineering for about 44 years now... Grew up with it, which was unusual when I started, and I was always good about getting into the zone and doing things. The career started small, small company, then back office, the dot com startups, then smaller companies again after the bust, a non-profit, and eventually YouTube (Google at the time, but just barely) and Meta (just Facebook when I was there).

When I hit the startups, and later big tech, it was no longer enough to just be an engineer, to have drive, to be good, you had to be organized, you had to follow through, get stuff done, and that's where the task systems started. Twenty-five over the years (and yes, I've actually counted), from Moleskine notebooks with Getting Things Done, evernote (remember evernote?), bug trackers, todoist, asana, google keep, among others.

When I managed on the Facebook News Feed, I got into gantt charts (for me and my team), spreadsheets, OmniPlan... I remember apologizing to my director for being so disorganized (because I felt I was making a mess of it), and he told me that I was the most organized engineer he knew.

That was because I was doing all of the work in the background, the trimming, the sorting, the reviews, but it was just so much work. Which was why I changed from system to system. Each time it built up, and I had to spend more time looking at things I couldn't or didn't get done, when I was rushed and couldn't put time into today's review, it would pile up, and then using it was so much work that I would start taking mini-notes, just emailing myself a few things to do the next day.

That's actually the thesis of the app (but not where it started), that if I could just have a few things to do emailed to me each day, I could get it done.

This app actually started when I described my previous startup failures into a Claude web session, and it repeated back to me what I had just said. My previous failures were because I spent too much time building the stuff I needed, and not building what I was supposed to be building.

I decided that the app would email me three things to do every day (which matches best practices for attention), but that the day was always yours to decide. We won't overload you, but you can add more, if you're feeling up to it, or cut back, and we never shame and try our best not to nag (I often only finish two). If we get it wrong, you can tell us, and we'll re-rank it once a day, or you can set it manually, and if you do, we never override that choice. The web app is live, and native for both platforms is coming. In the meantime, on Android, you can use gestures to quick launch into the voice input so saving a task is only a gesture away (e.g. double-tap the back of a Pixel, double-press the power button on Motorola).

Now let's talk about the dirty parts. I used AI to help me build this. Anthropic models mostly, and the brains of the app come from Anthropic models (I like the quality, I like the privacy, absolutely no training on customer data, and the stance of the company). This app is not some one-shot wonder where I asked frontier models to build a task system and then I put it on a server to show you.

I have prompts for the various features (e.g. ranking, generating suggestions, task extractions), I have eval sets of task lists (not anyone's real tasks, but constructed from patterns in my tasks, or the tasks of testers who allowed me to fix the problems they were having), with the three I expect to come out. I store the eval outputs, and re-test whenever I add a new rule to a prompt, or whenever testing a new model version. The great thing about having this eval set is that it catches when I get it wrong. When I introspect a failed run, sometimes it's because I need to tune a prompt, but sometimes it's because I missed something in my own ranking.

I did the same thing with my infrastructure as well, so this time, instead of setting up servers, and building login systems, and managing databases, I built on Vercel (git push to serving Next.js), Neon (hosted postgres).

I started getting emails mailed to me by mid-June, but started getting usable suggestions on June 26, and I've been using it every morning since. I wanted it to be easy to get started, and easy to use, so the input handles mess (you can add multiple tasks in the same run-on sentence, and a friend who helped me test it just pasted his entire obsidian todo list in wholesale to get started).

I wanted to make sure that anyone could try it out, so I built a trial feature that uses the real in-app ranking with a list of items you provide.

If you want to try the service, there's a free 14-day trial (card required), and then it's $99/year or $9.99/month after that (plus sales tax). We warn you seven days before your card is charged and if you cancel, you keep access through the term (either the trial, or our last paid period). Online, through settings -> billing, no email, no call.

I really hope you'll try it out. If you do, please tell me if we did a good job picking out your day.

https://3anddoneapp.com/try

Comments URL: https://news.ycombinator.com/item?id=50151980

Points: 13

# Comments: 8