Show HN: Pure Effect – Reproduce production bugs on your laptop without a DB https://ift.tt/0JPUXjn

Show HN: Pure Effect – Reproduce production bugs on your laptop without a DB Hi HN, I think it's safe to say that the majority of developers don't give a second thought to writing code with I/O tangled in business logic. It's all too common to see code like: const user = findUser(email); if (!user) await saveUser(user); Now, you may ask: what's the big deal? When we write code like this, two things happen: 1. It gets harder to debug production bugs. Unless you have the exact same database and remote API services to connect to, you may fail to reproduce the bug. 2. You have to use mocks and fakes in your tests, or use test containers, which only help somewhat, and they are slow! To solve these issues, I built Pure Effect, a tiny TypeScript/JavaScript effect library. The core idea is simple: if a function performs I/O, it isn't pure. But if it returns a description of the I/O it wants to perform, it is. So instead of await findUser(email), you return a Command object that says, "I would like to call this function, and when it finishes, here's what to do next." Your business logic becomes a pure function. Same input, same output, every time. The database never gets touched until the interpreter (runEffect) runs. When I first started the library, I didn't expect just how far that one idea would stretch. Once your pipelines are just data, a lot of wonderful things become possible: - No need for mocking libraries. You walk the tree in tests and assert on its structure: assert.equal(flow.cmd.name, 'cmdFindUser'). Nothing is executed. - Wrap any effect with Retry(effect, { attempts: 3, delay: 200, backoff: 2 }). The configuration is plain data, so you can assert on it in tests. - Every command's input and output flows through the interpreter, so you get a full execution trace for free. You can write a simple timeTravel() function that replays it locally without touching any I/O. Perfect for debugging complex production bugs. - An onBeforeCommand hook sits between your business logic and the interpreter. Since it sees every intended side effect before it fires, it can be used to enforce runtime guardrails. You can quarantine destructive calls before they happen for example. - You can review AI-generated code before it runs. Since Pure Effect pipelines are plain data, you can inspect what the generated code intends to do before it touches anything. There are just six primitives: Success, Failure, Command, Ask, Retry, and Parallel, plus effectPipe and runEffect. Zero dependencies. Under 1 KB minified and gzipped. How it compares to Effect-TS Effect-TS is the full-featured option in this space and has a large ecosystem. Pure Effect offers a different tradeoff. It covers the 80% case: testable pipelines, dependency injection, retry, and OpenTelemetry hooks, all in under 1 KB with zero dependencies and no new vocabulary to learn. Effect-TS is a framework you build around. Pure Effect, on the other hand, is a pattern you drop into existing code. I've been using Pure Effect in production since December. It's at v0.8.0, not 1.0 yet, but stable enough that I wanted to put it out there and hear what people think. GitHub: https://ift.tt/QSyexEs I wrote five posts that document how Pure Effect evolved. They are tagged at https://ift.tt/TfcXLNw if you want the longer story. https://pure-effect.org June 21, 2026 at 11:06PM

Show HN: DebugBrief – turn debugging sessions into reports, no AI https://ift.tt/F3yUf2V

Show HN: DebugBrief – turn debugging sessions into reports, no AI https://ift.tt/ltmZE45 June 22, 2026 at 01:27AM

Show HN: CleverCrow: give tokens to your favorite projects https://ift.tt/F9h2m7V

Show HN: CleverCrow: give tokens to your favorite projects Howdy all. I'm Zack :wave:. I've been thinking about the problem of misguided AI pull requests and figured I'd throw a possible solution out there for feedback. Basically, CleverCrow lets supporters give tokens to a GitHub repo (or set of issues in that repo) for the maintainers to use to build/fix stuff. The fun implementation challenges have been around implementing the pooling dynamics and keeping the maintainers in charge while the backers are motivated to support their work. https://clevercrow.io June 22, 2026 at 12:36AM

Show HN: An n8n alternative where coding agents build the workflows, not humans https://ift.tt/vgkmR29

Show HN: An n8n alternative where coding agents build the workflows, not humans n8n is built for humans dragging nodes on a canvas. That breaks down at B2B scale (embedding in a product, multi-tenant scalability, etc). n8n does have an MCP server so agents can create workflows too, but it outputs raw JSON. That's fine for n8n's engine, but painful for a coding agent (or a human reviewing its output) to read, write, diff, or debug. I'm building an alternative where workflows are authored by a coding agent in [a more dev-legible format] instead of JSON blobs, and execute it at scale. https://velane.sh/ June 21, 2026 at 12:14AM

Show HN: We post-trained a model that pen tests instead of refusing https://ift.tt/MoCkSfW

Show HN: We post-trained a model that pen tests instead of refusing Anthropic and OpenAI's publicly available models are explicitly guard-railed so that they refuse offensive tasks. And their cyber-focussed models are gated for enterprises. This leaves SMEs and mid market open to major vulnerabilities. AI can be used as both an adversarial and defensive tool in the world of cyber. A worst case outcome is if only the adversaries have access. Meanwhile, most existing AI cyber tools are just wrappers. The problem is that they still have all the guardrails on from the foundation model where they will inherit its refusals. For this project we've post-trained a specific model on a decade of capture-the-flag contests. This won't be made available to anyone and everyone, but we do believe that responsible SMEs and midmarket companies also need access to these tools in order to identify key vulnerabilities in their systems; not just enterprises. We have developed two modes that run over a CLI: • Security scan: a read-only audit of your local codebase for vulnerabilities. It only reports what it can tie to a specific file and line, so you're not wading through vibes-based findings. • Pen test: an active adversarial mode that will try to break a live system in a sandboxed environment. It proves each vulnerability by running the exploit and showing the request it sent and the response your code gave back, not a confidence score. Currently gated. To show what the scan does, we pointed it at Bank of Anthos and it found an integer overflow in the transfer path: amount is an int, and amount + fee can overflow negative, so the balance check passes and you move funds you don't have. Plus the usual auth and secrets issues. (Bank of Anthos is Google's open-source bank. It's a known app and some of it is intentionally weak, which is the point: you can clone it and re-run the scan yourself instead of trusting a screenshot) How the harness works: Along with the model we built the harness to support this. The harness runs on a multi-agent swarm: an orchestrator splits the job across subagents running in parallel, each owning a slice, then synthesising one report. The CLI is a local binary (brew/curl). It reads your code locally, then sends context to our inference API over TLS tcpdump it and you'll see exactly what leaves and where. Install is free; and you can run a scan for free up to 2m tokens, then need to pay for tokens beyond this. For full disclosure this is a product part of Cosine (YC W23) Up for debate: tool safety, e.g. domain verification is one method that proves control but not necessarily permission. How would you gate a pen-test tool given that? https://ift.tt/JEgxUrb June 20, 2026 at 07:19PM

Show HN: Jumpjet – a WASM runtime for game developers https://ift.tt/NLsyDSh

Show HN: Jumpjet – a WASM runtime for game developers I built Jumpjet because I realized that engine and indie game developers are always repeating the same work: building the core infrastructure that touches the OS. Webassembly solves this in the Component Model by enabling interop between packages written in different languages. And in my opinion it's sort of the perfect fit for Jumpjet's model: providing a chassis without an engine. Jumpjet works by defining a very close mapping of WebGPU (and a few other WebIDL features) to WIT so that they can be used in any language that can target the wasm Component Model. Your game then runs as a guest application in Jumpjet's host runtime (powered by wasmtime), which shrinks final bundle size considerably versus something like Electron. Right now a bare bones game in Jumpjet is about 40mb. Right now the project is in an alpha or possibly pre-alpha state, it's not production ready. On the commercial side, I think there's an opportunity for cloud storage, game server hosting, a package manager and/or marketplace, distribution, and more. Right now you can target macOS, Windows, Linux, Android and iOS. (I haven't done any real testing on mobile so good luck.) The languages you can use will depend on their support for generating bindings from .wit files. There are a few templates available, I recommend one of the Rust ones. If you are a game developer or just like tinkering, I'd love for you to try the project out and tell me what you think! https://jumpjet.dev June 20, 2026 at 01:22AM

Show HN: Continuous Nvidia CUDA PC Sampling Profiler https://ift.tt/Jn9zL1T

Show HN: Continuous Nvidia CUDA PC Sampling Profiler Blog post about how we extended our open source profiler to include support for continuous production PC sampling. https://ift.tt/eFj7AQz June 15, 2026 at 09:19PM