Ideas Lab

Real problems people complain about online, pulled every morning and scored out of 100. Build, validate, or skip. How scoring works

Ideas
4,820
BUILD
702
Sources
8
Last sync
14h ago
752 ideas
AI

adamsreview – better multi-agent PR reviews for Claude Code

I built adamsreview, a Claude Code plugin that runs deeper, multi-stage PR reviews using parallel sub-agents, validation passes, persistent JSON state, and optional ensemble review via Codex CLI and PR bot comments.On my own PRs, it has been catching dramatically more real bugs than Claude’s built-in /review, /ultrareview, CodeRabbit, Greptile, and Codex’s built-in review, while producing fewer false positives.adamsreview is six Claude Code slash commands packaged as a plugin: review, codex-review, add, promote, walkthrough, and fix. I modeled it after the built-in /review command and extended it meaningfully.You can clear context between review stages because state is stored in JSON artifacts on disk, with built-in scripts for keeping it updated.The walkthrough command uses Claude’s AskUserQuestion feature to walk you through uncertain findings or items needing human review one by one. Then, the fix command dispatches per-fix-group agents and re-reviews the work with Opus, reverting any regressions before committing survivors.It runs against your regular Claude Code subscription (Max plan recommended), unlike /ultrareview, which charges against your Extra Usage pool.I would love feedback from Claude Code users, pro devs, and anyone with strong opinions about AI code reviews.Repo: https://github.com/adamjgmiller/adamsreviewInstall: /plugin marketplace add adamjgmiller/adamsreview, /plugin install adamsreview@adamsreview

Hacker News5mo agoToolAI

72FL score
0Sign in to vote

OpenGravity – A zero-install, BYOK vanilla JS clone of Antigravity

Hi. I’m a high school student studying for my GCSEs. I was using Google Antigravity heavily for my side projects, but I kept hitting the usage limits, and getting random "agent terminated" errors. So I decided to try build my own version of the IDE. I love the UI, so I copied it as accurately as possible, and then hooked up some logic into it, including the INCREDIBLY finicky webcontainer api.I tried to keep it super lightweight, no build steps, or dependencies, and now that its open source, I'm hoping people can build things on top of it that arent possible with closed source tools, like complex custom agent workflows.Some screenshots: - https://github.com/ab-613/OpenGravity/blob/main/examples/scr... - https://github.com/ab-613/OpenGravity/blob/main/examples/htm...What it's made from:- Pure Vanilla JS: no react, vue, or build step. Built entirely in plain HTML/CSS/JS to keep it super lightweight.- WebContainer API and xterm.js: Instead of faking a terminal, I (after much pain) hooked up the WebContainer API so the AI agent has a real, in browser linux environment to run shell commands, install dependencies, and edit local files.- BYOK (Bring Your Own Key): API key ALWAYS stays in localStorage.Whats currently happening:- It works, but it's an alpha. The AI can proactively start projects going properly and edit files, but because I built this over a few days before my exams, a lot of the UI dropdowns and buttons are currently just hardcoded placeholders.- I’m open sourcing it early because I think the foundation of a Vanilla JS + WebContainer IDE is really strong, and I'd love to see where the community takes it while I'm doing my exams.- Live demo: https://opengravity.pages.dev (Zoom out to 80% if not full screen. It will prompt for a gemini api key on load). Start by uploading a folder, then you can fiddle with the terminal and agen

Hacker News5mo agoToolAI

72FL score
0Sign in to vote

Mochi.js: bun-native high-fidelity browser automation library

Hi HN,I’m sharing mochi.js (https://github.com/0xchasercat/mochi), a Bun-native, raw-CDP browser automation framework. It's designed to make programmatic browser use more effective by focusing on consistency and measured parity with regular traffic, purely from the JS layer, against stock Chromium.The most common forms of browser automation focus heavily on client-side line by line probes, which are mostly cosmetic. This makes people feel better but it doesn't have much relevance to actual WAF or anti-automation defences.Mochi.js focuses on what actually matters, allowing you to get past captchas, WAF's and most defence mechanisms. In fact, in some cases it actually outperforms chromium forks simply by virtue of not having to lie.The foundation is built on a probe manifest based on analyzing several WAF's and trying to cover most of the ground that matters, and from there building upwards while ensuring every decision is backed by data. Solves turnstile/interstitial automatically, single digit fpjs suspect score, very good client-side results, though browserscan and a few others are known limitations that are fundamentally conflicting with what WAF's probe for.I'll be here if anyone wants to discuss the details, check out the docs and github. It's completely free and open source, MIT, strictly no relationship to any proprietary products whatsoever. No affiliation to patched chromium forks, or SaaS.But I also want to talk about why I built this, because the current paradigm of "bot detection" is fundamentally broken.Traditionally they would probably try to label my repository a malicious tool, or at best, a grey hat one.Let's take Turnstile for example, If you attach a debugger to see what data they are extracting from your hardware, their script intentionally self-destructs. When they try to extract your data—acting as a guest on your silicon, using your electricity, without asking, the indu

Hacker News5mo agoToolAI

35FL score
0Sign in to vote

GETadb.com – every GET request creates a DB

Hey HN! We made GETadb.com, so it's easier to get agents to build you full stack apps. You don't need to give them any credentials. Just by loading a GET request, they get access to a database, a sync engine, and abstractions for auth, presence, and streams.To see what the agent sees, you can load https://getadb.com/newThere's two fun things about how it's implemented:1. If you curl the home page, it the agent content rather than human content. We do this by detecting the 'Sec-Fetch-Mode' header. It's not perfect, but gets the job done for Claude Code et al.2. For an agent to spin up an app, they make _two_ fethes. (1) getadb.com/guide tells them to generate a uuid, and fetch (2) getadb.com/provision/<uuid>. We did this, because just about half of the popular web-based app builders cache URLs globally, even if you return no-store headers. To get around this we just instruct the agent to generate unique URLsYou may wonder: Why GET requests, rather than POST requests? It's because then you can build in surprising places. For example, we get meta.ai to build an app inside the artifact preview: https://artifacts.meta.ai/share/a/b80c7412-c3af-4088-b430-78efdfe8ea2dUnder the hood, this is possible because the whole infra is mult-tenant from ground up. We already announced how that works on HN, but if you're curious here's the essay for it: https://www.instantdb.com/essays/architecture

Hacker News5mo agoToolAI

72FL score
0Sign in to vote

Airbyte Agents – context for agents across multiple data sources

I’m Michel, co-founder and CEO of Airbyte (https://airbyte.com/). We’ve spent the last six years building data connectors. Today we're launching Airbyte Agents (https://docs.airbyte.com/ai-agents/), a unified data layer for agents to discover information and take action across operational systems.Here’s a quick walkthrough: https://www.youtube.com/watch?v=ZosDytyf1fgAs agents move into real workflows, they need access to more tools (e.g. Slack, Salesforce, Linear). That means a ton of API plumbing: authentication, pagination, filters, handling schema, and matching entities across systems.Most MCPs don’t fix this. They’re thin wrappers over APIs, so agents inherit their weak primitives and still get it wrong most of the time, especially when working across tools.An even deeper issue is that APIs assume you already know what to query (think endpoints, Object IDs, fields), whereas agents usually start one step earlier: they need first to discover what matters before they can even start reasoning.So we built Airbyte Agents to be a context layer between your Agents and all of your data. The core of this is something we call Context Store: a data index optimized for agentic search, populated by our replication connectors. All that work on data connectors the last six years comes in handy here!This gives agents a structured way to discover data, while still allowing them to read and write directly to the upstream system when needed.What got us working on this was an insane trace from an agent we were migrating to our new SDK. It was supposed to answer "which customers are at risk of leaving this quarter?" The trace had 47 steps. Most were API calls. The agent first had to find a bunch of accounts, then map them to the right customers, then look for tickets, bla bla... and when the Agent finally responded, the answer sounded ok, but was wrong. Not only that, it was excruciatingly slow. So we had to do somethin

Hacker News5mo agoToolAI

78FL score
0Sign in to vote

Browser-based light pollution simulator using real photometric data

Hi HN — author here. iesna.eu is a browser-based ecosystem for working with photometric data: parsing standard luminaire files (LDT/EULUMDAT, IES LM-63, Oxytech, ATLA-S001), running design calculations against EN 13201 / ANSI/IES RP-8 / CJJ 45 / IES-IDA MLO, and (the part I most want to show off here) rendering real urban scenes in Bevy with the photometric data driving actual streetlight behavior, including sky-glow contribution. The Skyglow Analysis demo loads a real LDT file into a Bevy scene (Khronos Bistro test asset). The luminaire's intensity distribution drives the streetlight rendering directly — no fudging — and the sky-glow grade updates live as you adjust the uplight percentage. Swap to a full-cutoff fixture and the sky goes from F (Severe) back to A (Excellent). You can see the difference on the buildings as well as in the sky. Stack: Rust core (eulumdat-rs and friends, ~20 crates handling photometric formats), Bevy for the 3D rendering, WASM for browser deployment. No backend; everything runs client-side. About a thousand lines of new code on top of the existing photometric library to make the Bevy integration work. Things I'd love feedback on:The atmospheric scattering model is currently single-scattering Rayleigh+Mie. Is that defensible for the use case, or should I move toward multi-scattering? The Bistro test scene works well visually but isn't a controlled environment. Anyone know of a public urban geometry asset that's more typical of real road-lighting evaluation? The CJJ 45 implementation (China's national road lighting standard) is the only one I've had to reverse-engineer from translated PDFs. If anyone has primary-source experience with it, I'd value a sanity check.Open-source on GitHub (eulumdat-rs and the related crates). Crates.io: eulumdat

Hacker News6mo agoToolAI

72FL score
0Sign in to vote

Filling PDF forms with AI using client-side tool calling

Hey HN!I built SimplePDF Copilot: an AI assistant that can interact with the PDF editor. It fills fields, answers questions, focuses on a specific field, adds fields, deletes pages, and so on.It's built on top of SimplePDF that I started 7 years ago, pioneering privacy-respecting client-side pdf editing, now used monthly by 200k+ people.As for the privacy model: the PDF itself never leaves the browser. Parsing, rendering, and field detection all run client-side.The text the model needs (and your messages) goes to whatever LLM you point at. By default that's our demo proxy (DeepSeek V4 Flash, rate-capped), but you can BYOK and point it at any cloud provider, or go fully local (I've been testing with LM Studio).Unlike the existing "Chat with PDF" tools that only retrieve the text/OCR layer, Copilot can act on the PDF: filling fields, adding fields (detected client-side using CommonForms by Joe Barrow [1], jbarrow on HN with some post-processing heuristics I added on top), focusing on fields, deleting pages, and so on.I built this because SimplePDF is mostly used by healthcare customers where document privacy is paramount, and I wanted an AI experience that didn't require shipping PII to a third party. Stack is pretty standard:- Tanstack Start- AI SDK from Vercel- Tailwind (I personally prefer CSS modules, I'm old-school but the goal since I open source it, I figured that Tailwind would be a better fit)The more interesting part is the client-side tool calling: events are passed back and forth via iframe postMessage.If you're not familiar with "tool calling" and "client-side tool calling", a quick primer:Tool calling is what LLMs use to take actions. When Claude runs grep or ls, or hits an MCP server, those are tool calls.Client-side tool calling means the intent to call a tool comes from the LLM, but the execution happens in the browser.That matters for: speed, you can't go faster than client-to-clie

Hacker News6mo agoToolAI

72FL score
0Sign in to vote