🛠️ All DevTools

[Other] Show HN: Fate, a new data framework for React and tRPC, inspired by Relay

[API/SDK] Show HN: Durable Streams – Kafka-style semantics for client streaming over HTTP Hey, I&#x27;m a co-founder at ElectricSQL. Durable Streams is the delivery protocol underneath our Postgres sync engine—we&#x27;ve been refining it in production for 18 months.<p>The core idea: streams get their own URL and use opaque, monotonic offsets. Clients persist the last offset they processed and resume with &quot;give me everything after X.&quot; No server-side session state, CDN-cacheable, plain HTTP.<p>We kept seeing teams reinvent this for AI token streaming and real-time apps, so we&#x27;re standardizing it as a standalone protocol.<p>The repo has a reference Node.js server and TypeScript client. Would love to see implementations in other languages—there&#x27;s a conformance test suite to validate compatibility.<p>Happy to dig into the design tradeoffs—why plain HTTP over WebSockets, etc.

[Other] Show HN: Detail, a Bug Finder Hi HN, tl;dr we built a bug finder that&#x27;s working really well, especially for app backends. Try it out and send us your thoughts!<p>Long story below.<p>--------------------------<p>We originally set out to work on technical debt. We had all seen codebases with a lot of debt, so we had personal grudges about the problem, and AI seemed to be making it a lot worse.<p>Tech debt also seemed like a great problem for AI because: 1) a small portion of the work is thinky and strategic, and then the bulk of the execution is pretty mechanical, and 2) when you&#x27;re solving technical debt, you&#x27;re usually trying to preserve existing behavior, just change the implementation. That means you can treat it as a closed-loop problem if you figure out good ways to detect unintended behavior changes due to a code change. And we know how to do that – that&#x27;s what tests are for!<p>So we started with writing tests. Tests create the guardrails that make future code changes safer. Our thinking was: if we can test well enough, we can automate a lot of other tech debt work at very high quality.<p>We built an agent that could write thousands of new tests for a typical codebase, most &quot;merge-quality&quot;. Some early users merged hundreds of PRs generated this way, but intuitively the tool always felt &quot;good but not great&quot;. We used it sporadically ourselves, and it usually felt like a chore.<p>Around this point we realized: while we had set out to write good tests, we had built a system that, with a few tweaks, might be very good at finding bugs. When we tested it out on some friends&#x27; codebases, we discovered that almost every repo has tons of bugs lurking in it that we were able to flag. Serious bugs, interesting enough that people dropped what they were doing to fix them. Sitting right there in peoples codebases, already merged, running in prod.<p>We also found a lot of vulns, even in mature codebases, and sometimes even right after someone had gotten a pentest.<p>Under the hood: - We check out a codebase and figure out how to build it for local dev and exercise it with tests. - We take snapshots of the built local dev state. (We use Runloop for this and are big fans.) - We spin up hundreds of copies of the local dev environment to exercise the codebase in thousands of ways and flag behaviors that seem wrong. - We pick the most salient, scary examples and deliver them as linear tickets, github issues, or emails.<p>In practice, it&#x27;s working pretty well. We&#x27;ve been able to find bugs in everything from compilers to trading platforms (even in rust code), but the sweet spot is app backends.<p>Our approach trades compute for quality. Our codebase scans take hours, far beyond what would be practical for a code review bot. But the result is that we can make more judicious use of engineers’ attention, and we think that’s going to be the most important variable.<p>Longer term, we think compute is cheap, engineer attention is expensive. Wielded properly, the newest models can execute complicated changes, even in large codebases. That means the limiting reagent in building software is human attention. It still takes time and focus for an engineer to ingest information, e.g. existing code, organizational context, and product requirements. These are all necessary before an engineer can articulate what they want in precise terms and do a competent job reviewing the resulting diff.<p>For now we&#x27;re finding bugs, but the techniques we&#x27;re developing extend to a lot of other background, semi-proactive work to improve codebases.<p>Try it out and tell us what you think. Free first scan, no credit card required: <a href="https:&#x2F;&#x2F;detail.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;detail.dev&#x2F;</a><p>We&#x27;re also scanning on OSS repos, if you have any requests. The system is pretty high signal-to-noise, but we don&#x27;t want to risk annoying maintainers by automatically opening issues, so if you request a scan for an OSS repo the results will go to you personally. <a href="https:&#x2F;&#x2F;detail.dev&#x2F;oss" rel="nofollow">https:&#x2F;&#x2F;detail.dev&#x2F;oss</a>

[IDE/Editor] Show HN: I got tired of switching AI tools, so I built an IDE with 11 of them Each AI has strengths - Claude reasons well, Gemini handles long context, Codex integrates with GitHub. But switching between them means losing context.<p>Built HiveTechs: one workspace where Claude Code, Gemini CLI, Codex, DROID, and 7 others run in integrated terminals with shared memory.<p>Also added consensus validation - 3 AIs analyze independently, 4th synthesizes.<p>Real IDE with Monaco editor, Git, PTY terminals. Not a wrapper.<p>Looking for feedback: hivetechs.io

[Other] Mistral Releases Devstral 2 (72.2% SWE-Bench Verified) and Vibe CLI

[API/SDK] Fate: A modern data client for React and tRPC

[API/SDK] A SaaS platform that lets you create and host APIs instantly What you get • AI-assisted API code generation • Self-managed APIs with infrastructure fully configured • Scales automatically (deploy anywhere later if you want) • Admin UI for Product, Dev, and Platform/Ops teams • Clean-code templates using the Command pattern • Robust CLI to bootstrap features fast • SDKs for Web & Mobile • Monitoring, logs, metrics, auth, and versioning built-in

[API/SDK] The Documentation Layer for AI Agents (RAG in 1 Click) Developer Tools, Artificial Intelligence, API Stop scraping docs. CodeContext API gives your AI agents instant access to up-to-date documentation for 1000+ libraries (React, LangChain, Next.js). Prevent hallucinations and save 90% on tokens with optimized JSON responses.

[Other] Remove context rot + improve code search Introducing WarpGrep, a fast context subagent that improves coding agent performance. WarpGrep speeds up coding tasks 40% and reduces context rot by 70% on long horizon tasks by treating context retrieval as its own RL trained system. Inspired by Cognition’s SWE-Grep - we’re opening access to Claude Code, Codex, OpenCode or any coding agent via MCP (or through our SDK)

[Testing] Testing Co-Pilot for Backend Engineers Never manually write, or and maintain backend tests again! Kerno automates integration testing end-to-end inside your IDE. It understands your codebase, generates meaningful tests, spins up test environments, executes tests, and delivers instant audit reports to catch issues early, validate changes before committing your code. Use Kerno to: → Catch breaking changes at source → Augment current Code-Gen loops with test data → Audit AI generated code in real-time → Increase test coverage

[Other] Show HN: DataKit, your all in browser data studio is open source now Hey HN! I&#x27;m open-sourcing DataKit today.<p>GitHub: <a href="https:&#x2F;&#x2F;github.com&#x2F;datakitpage&#x2F;datakit" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;datakitpage&#x2F;datakit</a> Live demo: <a href="https:&#x2F;&#x2F;datakit.page" rel="nofollow">https:&#x2F;&#x2F;datakit.page</a><p>DataKit is a browser-based data analysis platform that processes multi-gigabyte files (CSV, Parquet, JSON, Excel) entirely client-side using DuckDB-WASM. Your data never leaves your browser.<p>What it does: • Process large files (tested up to 20GB) without any server • Full SQL interface powered by DuckDB compiled to WebAssembly • Python notebooks via Pyodide for data science workflows • Connect to remote sources (PostgreSQL, MotherDuck, S3) with optional proxy • AI assistant that only sees column schemas, not actual data<p>I was done with having to choose between cloud tools and heavy local installations. I wanted something that just works in a browser tab but has real power.<p>It&#x27;s AGPL licensed with commercial licenses available for enterprises.<p>I&#x27;ve been building this solo as a side project for the past few months. Would love your feedback on: - Performance bottlenecks you encounter - Features you&#x27;d need for your workflows - The architecture decisions (all client-side vs hybrid)

[Database] Show HN: DuckDB for Kafka Stream Processing Hello Everyone! We built SQLFlow as a lightweight stream processing engine.<p>We leverage DuckDB as the stream processing engine, which gives SQLFlow the ability to process 10&#x27;s of thousands of messages a second using ~250MiB of memory!<p>DuckDB also supports a rich ecosystem of sinks and connectors!<p><a href="https:&#x2F;&#x2F;sql-flow.com&#x2F;docs&#x2F;category&#x2F;tutorials&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sql-flow.com&#x2F;docs&#x2F;category&#x2F;tutorials&#x2F;</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;turbolytics&#x2F;sql-flow" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;turbolytics&#x2F;sql-flow</a><p>We were tired of running JVM&#x27;s for simple stream processing, and also of bespoke one off stream processors<p>I would love your feedback, criticisms and&#x2F;or experiences!<p>Thank you

[Other] Show HN: Diesel-guard – Lint Diesel migrations for unsafe PostgreSQL patterns

[Other] AMD GPU Debugger

[Database] Show HN: LinkedQL – Live Queries over Postgres, MySQL, MariaDB LinkedQL is a new SQL client that supports live queries over any Postgres, MySQL, and MariaDB database. You get result sets that self-update differentially as rows change in your database – via inserts, updates, deletes. Works with no extra tooling&#x2F;ORM layer or GraphQL servers. You opt into live mode simply with a flag: client.query(&#x27;SELECT ...&#x27;, { live: true }). More at: <a href="https:&#x2F;&#x2F;linked-ql.netlify.app&#x2F;capabilities&#x2F;live-queries" rel="nofollow">https:&#x2F;&#x2F;linked-ql.netlify.app&#x2F;capabilities&#x2F;live-queries</a><p>LinkedQL is written in JavaScript and runs in both client and server environments.<p>GitHub + docs: <a href="https:&#x2F;&#x2F;github.com&#x2F;linked-db&#x2F;linked-ql" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;linked-db&#x2F;linked-ql</a><p>Demo examples included.<p>I’d love feedback: • Anything confusing? • Anything seems useful or dangerous? • Anything else that&#x27;d make you consider LinkedQL for production?<p>Thanks for taking a look — happy to answer any questions.

[Other] Show HN: I wrote a book – Debugging TypeScript Applications (in beta)

[Other] An open-source vibe coding platform that helps you build your own vibe-coding platform, built entirely on Cloudflare stack

[Other] Presentation Slides for Developers

[DevOps] Show HN: Dograh – an OSS Vapi alternative to quickly build and test voice agents Hi HN, I have been building voice agents for sometime now. I was earlier automating parts of visa processing, and we needed real-time, multilingual voice calling.<p>I assumed the hard work was just wiring LiveKit&#x2F;Pipecat + STT&#x2F;TTS + an LLM. It wasn’t.<p>Even with solid OSS (Pipecat&#x2F;LiveKit), we still had to do a lot of plumbing- variable extraction, tracing, testing etc and any workflow changes required constant redeploys.<p>We eventually realized we’d spent more time building infrastructure than building the actual agents. Everything felt custom. We hit every possible pain with Pipecat and VAPI style systems.<p>So we built Dograh - a fully open-source voice agent framework that includes all the boring, painful pieces by default.<p>What’s different:<p>- Pipecat-based engine, but forked - custom event model, and concurrency fixes<p>- One-click start template generated by an LLM Agent for a quick get start template for any use case<p>- Drag-and-drop visual agent builder for quick iteration (the thing we wished existed earlier)<p>- Variable extraction layer (name&#x2F;order&#x2F;date&#x2F;etc.) baked into the LLM loop<p>- Built in Telephony integration (Twilio&#x2F; Vonage&#x2F; Vobiz&#x2F; Cloudonix)<p>- Multilingual support end-to-end<p>- Select any LLM TTS STT (add their credits, if any)<p>- AI-to-AI call testing: automatically stress-test an agent before shipping (still a work in progress- so patchy as of now)<p>- Fully Open Source<p>It&#x27;s built and maintained by YC alumni &#x2F; exit founders who got tired of rebuilding the same plumbing.<p>Why we open-sourced it: We kept feeling that the space was drifting toward closed SaaS abstractions (VAPI, Retell). Those are good for demos, but once you need data controls, privacy or self&#x2F;offline deployment, you end up stuck. We wanted a stack where you can see every part, fork it, self-host it, and patch it as needed.<p>Try it:<p>- Repo: <a href="https:&#x2F;&#x2F;github.com&#x2F;dograh-hq&#x2F;dograh" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dograh-hq&#x2F;dograh</a><p>This spins up a basic multilingual agent with everything pre-wired.<p>Who this is for:<p>- If you are looking for self hosting a Vapi like platform for Data Privacy etc.<p>- Anyone trying to build production-grade voice agents without reinventing audio plumbing.<p>- If you’ve tried to glue STT→LLM→TTS manually, you probably know the exact pain this is built for<p>Happy to answer technical questions, show the architecture, or hear how we can improve the product.

[Other] GitHub Actions Has a Package Manager, and It Might Be the Worst