brian_meek

Detections.ai | Full-Stack Engineer, Detection Platform | REMOTE (US & Canada) | Full-time

Detections.ai is building the platform for teams to create, test, organize, share, and improve detections.

We’re hiring a full-stack/product engineer with hands-on detection experience—writing or tuning detections, building SOC tooling, or integrating SIEM/EDR platforms.

You’ll own product features end to end across React interfaces, backend services, APIs, data models, search, integrations, and asynchronous workflows.

LLMs are a core product capability, not a bolt-on chatbot. Our assistant orchestrates domain tools and agents to analyze threat intelligence, search detection libraries, identify coverage gaps, create and translate detections, and ground recommendations in connected SIEM telemetry. We care about accuracy, evals, observability, hostile-input safety, and practitioner UX.

Stack: TypeScript, React, Next.js, NestJS, Python, AWS, OpenSearch, and Valkey/Redis.

Expected annual base salary: US$150,000–$225,000, or the Canadian-dollar equivalent, plus equity. The exact offer will depend on experience and role scope.

We’re looking for strong production web-app experience, end-to-end product ownership, and familiarity with some combination of Sigma, KQL, SPL, YARA, SIEM, EDR, or MITRE ATT&CK. We’re a small, experienced, remote team working directly with customers and security practitioners.

Apply: Email [email protected] with “HN Full-Stack Engineer” in the subject and a short note about your detection-engineering experience.

Nice. i'm curious, did you consider using Quiche and the sans IO support it has and building the NIO layer to support that? QUIC has a lot of interesting edge cases including window management, and Quiche encapsulates a lot of that for you.

Thanks for looking, and yes, I can rename it. Will do today. Also, thanks for the excellent protocol. In this entire "effort", I only found one ambiguity in it (and reported it in your repo). Everything about it was well defined and succinct. The pipelining is really useful.

OP here, and yes, the chained operations are excellent. Having built this, and now using it some pet projects, that is the part I'm finding valuable.

OP here. :-) (feel like I should put an emoji here). My focus as I "built" this was getting to a correct implementation, and putting in place guards and context to achieve that. As I moved through the process I added more and more ways to eval progress toward that. An area I didn't invest any of my effort in was commit messages, and some of them caused me to spit take as I saw them go by. I think this is something that can definitely be improved, and this conversation is fuel for thought on how to do this.

Thank you. Along the way in doing this I spent most of my effort in providing guard rails to eliminate or reduce slop. My goal was something I can use in other pet projects and maintain. I'm satisfied with the outcome, and appreciate you noticing it wasn't just yolo vibe coding.

OP here. I frankly stopped trying to add evals for the "ready for production" happiness Claude is trained to produce. I agree, not ready for production. I did though put a intention and effort into guarding against slop in implementation and tests. Sure I can still find it, but I believe the current state is solid enough to build on, and I will be doing so for some pet projects. I'll let you know what I find when using it in anger.

That is was boring is what appealed to me. That is was also thought through with rigor was the other part. I wanted something to use in some pet projects, in rust, so having an implementation of the "wrangling" code I could reuse was value to me. Learning how to put guardrails on sing an LLM productively was another.

I'm happy to make the name available to later implementations with committed resources, and I definitely welcome contributions to this implementation if you find it useful. This week I'm going to try building a for pet projects on it and will likely make some changes to improve this.