Show HN: I scanned every YC Spring 2026 startup for what AI crawlers see
3 by apswin | 0 comments on Hacker News.
Used 'potatometer.com' to scan and analyze all All 197 YC Spring 2026 startups on their SEO / GEO / AEO technical setup. I scanned the URL each startup lists in YC's directory. Most are readable by AI crawlers. Most don't tell a crawler what they are. Read more in the blog above.
Hack Nux
Watch the number of websites being hacked today, one by one on a page, increasing in real time.
New ask Hacker News story: Tell HN: I never bought anything from clicking on a paid ad
Tell HN: I never bought anything from clicking on a paid ad
6 by julienreszka | 2 comments on Hacker News.
I really wonder who clicks ads
6 by julienreszka | 2 comments on Hacker News.
I really wonder who clicks ads
New ask Hacker News story: Norrin – Git/ diff control in Claude Code
Norrin – Git/ diff control in Claude Code
3 by gagewoodard | 1 comments on Hacker News.
You can now control diff inline, track files, and reject/ accept as you like in Claude Code. With this new tool you get Cursor-like control over your claude code agents making your code cleaner, you never get lost in changes, and can reduce your PR review time by more than half. https://norrin.dev
3 by gagewoodard | 1 comments on Hacker News.
You can now control diff inline, track files, and reject/ accept as you like in Claude Code. With this new tool you get Cursor-like control over your claude code agents making your code cleaner, you never get lost in changes, and can reduce your PR review time by more than half. https://norrin.dev
New Show Hacker News story: Show HN: Pure Effect – Reproduce production bugs on your laptop without a DB
Show HN: Pure Effect – Reproduce production bugs on your laptop without a DB
2 by tie-in | 0 comments on Hacker News.
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/srbQNdI I wrote five posts that document how Pure Effect evolved. They are tagged at https://ift.tt/0d6lu4H if you want the longer story.
2 by tie-in | 0 comments on Hacker News.
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/srbQNdI I wrote five posts that document how Pure Effect evolved. They are tagged at https://ift.tt/0d6lu4H if you want the longer story.