As LLM agents proliferate, prompt injection detection is critical but current solutions require ML models, API calls, or GPU inference. A developer on HN built a Go library using deterministic normalization (10 stages) that detects injections via pattern matching after normalizing evasion techniques like homoglyphs, leet speak, and zero-width characters. Zero regex, zero API calls, single dependency. The ClamAV model for prompt security.

builder note

The ClamAV analogy is exactly right. The scan loop is trivial. The value is the definition database. Invest in building the largest, most actively maintained prompt injection signature database and release it as a community resource. The library itself is the distribution mechanism for the signatures. Port to Rust and TypeScript for maximum adoption. The business model is enterprise signature feeds with faster update cycles.

landscape (4 existing solutions)

Prompt injection detection splits into ML-based solutions (accurate but heavy, requiring GPU or API calls) and pattern-based solutions (fast but brittle regex). The deterministic normalization approach is a third path: normalize evasion techniques to canonical form, then match against a community-maintained signature database. This gives ClamAV-like deployability (embed anywhere, no ML dependencies) with expanding coverage via definition updates.

go-promptguard Go library using perplexity-based detection with character bigram analysis. Catches unnatural text patterns but relies on statistical methods that can false-positive on legitimate non-English text or technical content.
Vigil LLM Python-based composable scanner stack (vector similarity, YARA, transformer classifier). Powerful but Python-only and requires ML model inference. Not embeddable in Go/Rust services without FFI overhead.
Microsoft Prompt Shields Cloud API for prompt injection detection. But requires API calls to Microsoft's servers, adding latency and data privacy concerns. Not suitable for offline or high-throughput scanning.
Augustus (Praetorian) Pentesting tool with 210+ vulnerability probes. But designed for red teaming (attacking), not for runtime defense (blocking). Different use case.
sources (2)
hn https://news.ycombinator.com/item?id=47230384 "Think ClamAV: the scan loop is trivial, the definitions are the product" 2026-03-01
other https://github.com/hazyhaar/pkg/tree/main/injection "zero regex, no API calls, no ML in the loop" 2026-03-01
securityLLMprompt-injectionAI-agentsopen-source

Infinite Canvas SQL Query and Data Exploration Tool

dev tool real project • single request

Data exploration is trapped in linear notebook interfaces (Jupyter) or tabbed query editors (DBeaver). Developers and analysts want to lay out multiple queries, results, and visualizations on a spatial canvas where they can see relationships between data explorations simultaneously. A builder on HN shipped Kavla using DuckDB Wasm with this exact metaphor, validating the UX concept.

builder note

The infinite canvas for SQL is a better spatial metaphor than notebooks for exploration. But the killer feature isn't the canvas itself. It's the ability to pipe one query's results into another visually. Think: drag a connection from query A's output to query B's input. That's the moment data exploration goes from sequential to parallel. Start with DuckDB for local files, then add Postgres/MySQL connections.

landscape (4 existing solutions)

Linear query interfaces (notebooks, tabbed editors) force sequential exploration. The infinite canvas metaphor lets analysts see the full investigation landscape at once: query A's results feeding into query B, a chart next to the raw data it summarizes, a schema diagram beside the query that uses it. Kavla and Count.co prove the concept works. The gap is a polished, multi-database canvas tool that works locally and connects to production databases.

Kavla First mover with the infinite canvas SQL concept using DuckDB Wasm. Local-first and free. But very early stage, single developer, and focused on DuckDB. No support for connecting to live databases (Postgres, MySQL).
Count.co Canvas-based data exploration with SQL notebooks. Closest to the concept but commercial SaaS with team pricing. Not local-first. Requires data warehouse connection.
BigQuery Data Canvas Google's take on visual data exploration. But locked to BigQuery. Not a general-purpose tool. Enterprise-only feature.
Observable Reactive notebook environment with JavaScript. Powerful but steep learning curve. Not SQL-first. Designed for data visualization, not database exploration.
sources (1)
hn https://news.ycombinator.com/item?id=46937696 "We need to alt+tab so much. What if we just put it all on a canvas?" 2026-02-01
data-explorationSQLdeveloper-toolsvisualizationinfinite-canvas

Every database GUI treats querying as a single-player experience. Teams share queries via Slack, lose context across tools, and have no audit trail of who ran what against production. A builder on HN is shipping DB Pro Studio to address this exact gap: shared query workspaces, audit logging, and real-time collaboration. PopSQL pioneered this but its execution is limited.

builder note

The audit logging angle is the enterprise wedge. SOC 2 and GDPR require knowing who queried what data and when. Most teams solve this with VPN logs and prayer. Build a database proxy that logs every query with user attribution, then wrap a nice collaborative UI around it. The collaboration features get you adopted. The compliance features get you bought.

landscape (4 existing solutions)

Database clients bifurcate into powerful-but-solo tools (DBeaver, Beekeeper) and collaborative-but-limited tools (PopSQL). Nobody has combined broad database support, modern UI, real-time team collaboration, and production query audit logging in one tool. The compliance angle (who ran what query against prod, when) is underserved but increasingly required.

PopSQL Pioneered collaborative SQL editing with shared queries and version history. But limited database support, clunky performance on large result sets, and pricing ($14/user/mo) adds up for teams.
DBeaver Most feature-rich free client supporting 80+ databases. But Enterprise Edition required for collaboration features. Team sharing is an afterthought, not a core design principle.
Bytebase Excellent for database CI/CD and schema changes with team workflows. But focused on schema management, not ad-hoc query collaboration. Different use case.
Beekeeper Studio Beautiful, modern UI with great UX. Open source. But purely single-player. No shared queries, no audit logging, no team features.
sources (1)
hn https://news.ycombinator.com/item?id=46937696 "Databases are a team activity, but every DB tool treats them as single-player" 2026-02-01
databasecollaborationdeveloper-toolsSQLteam-productivity

LLM-Powered Intelligent Test Suite Selector for CI Pipelines

dev tool real project •• multiple requests

CI pipelines run full test suites on every commit even when only a small fraction of tests are affected by the change. Developers wait 10-30 minutes for results when 90% of the tests are irrelevant. An HN user specifically requested an LLM that analyzes code changes and proposes relevant test suites with flakiness estimates. Datadog's Test Impact Analysis exists but is enterprise-priced and locked to their platform.

builder note

Coverage-based test selection is old tech. The LLM advantage is semantic understanding: it can read a diff, understand the behavioral change, and predict which tests exercise that behavior even without coverage data. Ship as a GitHub Action that comments on PRs with 'suggested test subset' and confidence scores. Start with a single language (Python or TypeScript) and prove the accuracy before going multi-language.

landscape (3 existing solutions)

Test Impact Analysis is a known concept (coverage-based test selection) but existing implementations are either enterprise-locked (Datadog), ML-dependent requiring months of training data (Launchable), or too simplistic (file-level Git detection). Nobody has shipped an LLM-powered test selector that uses semantic code understanding rather than coverage maps. An LLM can read a diff and understand which behaviors changed, which is fundamentally different from tracking which lines executed.

Datadog Test Impact Analysis Production-ready test selection based on code coverage mapping. But requires Datadog subscription and full CI Visibility integration. Enterprise pricing puts it out of reach for small teams.
Launchable ML-powered test selection that predicts which tests are likely to fail. But commercial SaaS with limited free tier. Requires historical test data to build prediction models.
Jest --changedSince Built-in Git-based test filtering for JavaScript. But limited to file-level detection. Can't determine that a change to a utility function only affects 3 of 50 test files that import it.
sources (2)
hn https://news.ycombinator.com/item?id=46345827 "have LLM analyze changes and propose the set of test suites that is relevant" 2025-12-28
other https://dev.to/barecheck/is-cicd-stifling-innovation-reclaim... "slow pipelines cause developers to start batching pushes" 2026-02-01
CI-CDtestingLLMdeveloper-experienceautomation

Local-First Secrets Manager for the AI Agent Era

dev tool weekend hack •• multiple requests

AI coding agents (Cursor, Claude Code, Copilot) can read .env files, and 12.8 million secrets leaked in public GitHub commits in 2023 alone. Developers need secrets management that works seamlessly in local dev while keeping credentials invisible to AI assistants. Existing tools (Vault, Doppler, Infisical) solve team sync but don't address the AI agent attack surface. A developer on DEV built a local-first secret manager specifically because they don't trust AI agents with .env files.

builder note

The technical approach is simple: use OS-level file permissions, named pipes, or environment variable injection at process start (not filesystem) to keep secrets out of files that AI agents can read. The marketing angle is what sells it: 'Your AI coding assistant can read your .env file. This tool makes sure it can't.' Ship a CLI that wraps any command (like doppler run) and ensure the secrets never touch the filesystem.

landscape (4 existing solutions)

Secrets management tools solve team sync and production deployment but none specifically addresses the AI coding assistant threat model: an LLM reading your .env file and potentially including credentials in its context window or generated code. 1Password's FIFO pipe approach is the closest technical solution but it's buried in an enterprise product. The gap is a lightweight, local-only tool that makes secrets available to your app but invisible to AI agents.

Infisical Most popular open-source secrets manager (12.7K GitHub stars). End-to-end encrypted. But requires running a server and doesn't specifically address AI agent context window leakage.
Doppler Fastest developer onboarding with 'doppler run' injection. But cloud-first architecture means secrets transit through Doppler's servers. No local-only mode.
1Password Environments Uses UNIX named pipes (FIFO) so no plaintext on disk. Closest to solving the AI agent problem. But requires 1Password subscription and doesn't integrate with AI coding tools specifically.
HashiCorp Vault Industry standard for complex infrastructure. But massive operational overhead for local dev use. Not designed for individual developer workflows or AI agent isolation.
sources (3)
other https://dev.to/jaeone/i-built-a-local-first-secret-manager-b... "I don't trust AI agents with my .env files" 2026-03-10
other https://jonmagic.com/posts/stop-putting-secrets-in-dotenv-fi... "Stop putting secrets in .env files" 2026-01-20
other https://blog.gitguardian.com/top-secrets-management-tools-fo... "12.8 million new secrets detected in public GitHub commits" 2026-02-01
securitysecrets-managementAI-agentslocal-developmentprivacy

LLM Prompt Regression Testing Tool for CI/CD Pipelines

dev tool real project •• multiple requests

Teams shipping LLM features are testing them less rigorously than login forms. A prompt tweak that fixes one issue silently breaks another, and broken prompts return HTTP 200 while content goes subtly wrong. Promptfoo leads but just got acquired by OpenAI (March 2026), creating uncertainty. DeepEval and LangWatch exist but CI/CD integration is still awkward. Developers need prompt testing that feels like unit testing.

builder note

Promptfoo's acquisition by OpenAI is your opening. Build the vendor-neutral, MIT-licensed alternative. The key insight: most teams don't need 50 evaluation metrics. They need 3 things: does the output match expected format, does it contain the right entities, and did quality regress from the last version. Ship a YAML config, a CLI command, and a GitHub Action. Nothing else.

landscape (4 existing solutions)

LLM evaluation tools are maturing fast but they're designed for ML teams running dedicated eval suites, not for product engineers who added one LLM feature to their otherwise traditional app. Promptfoo's OpenAI acquisition creates a vacuum for an independent, lightweight prompt regression tool. The gap is 'pytest for prompts': define expected behaviors, run against prompt changes, fail the PR if quality drops.

Promptfoo Best CLI tool for prompt evaluation with CI/CD integration. But acquired by OpenAI in March 2026, creating vendor lock-in concerns. Open-source future uncertain. Red teaming features may overshadow simple regression testing.
DeepEval Open-source LLM evaluation framework with CI/CD unit testing support. Comprehensive metrics library. But setup is Python-heavy and configuration is verbose for simple regression checks.
Braintrust Strong evaluation platform with dataset management and A/B testing. But commercial SaaS with pricing that doesn't suit small teams shipping a few LLM features alongside traditional code.
LangWatch Full LLM observability platform. But observability is different from testing. Teams need something that blocks bad prompts in PRs, not just monitors them in production.
sources (2)
other https://dev.to/pockit_tools/llm-evaluation-and-testing-how-t... "broken prompts returning HTTP 200 while content becomes subtly wrong" 2026-03-01
other https://www.traceloop.com/blog/automated-prompt-regression-t... "a simple wording change can dramatically alter performance" 2026-02-15
LLMtestingCI-CDprompt-engineeringdeveloper-tools

Datadog's $3.4B in 2025 revenue is built on unpredictable per-GB, per-host, per-metric pricing that routinely shocks teams with $130K/month bills. Mid-size teams (50 engineers) pay $180K-$480K annually. Open-source alternatives exist (SigNoz, Grafana stack) but require significant DevOps expertise to self-host. The gap is a managed observability platform with predictable pricing that doesn't require a dedicated platform team.

builder note

Don't try to match Datadog feature-for-feature. The wedge is pricing transparency. Ship a flat-rate observability product for teams of 10-50 engineers: $X/month, unlimited logs, unlimited metrics, no surprises. OpenTelemetry is your data collection layer. ClickHouse is your storage. The moat isn't technology, it's the pricing model. Every team that gets a surprise Datadog bill is a potential customer.

landscape (4 existing solutions)

The observability market has a clear cost crisis: Datadog's usage-based model punishes growth, and teams paying to store logs they can't afford to search is absurd. OpenTelemetry standardized data collection but the visualization and storage layer remains vendor-locked. Self-hosted options (SigNoz, Grafana stack) are powerful but require platform engineering expertise most small teams lack. The gap is a zero-ops managed platform with flat-rate pricing.

SigNoz Best open-source Datadog alternative with 24K GitHub stars. OpenTelemetry native. But self-hosting requires ClickHouse expertise and ongoing maintenance. Cloud pricing ($0.30/GB logs) can still be unpredictable at scale.
Grafana + Loki + Tempo + Mimir Most flexible composable stack. But running 4 separate systems creates operational overhead that defeats the purpose of simplifying observability. Requires a dedicated platform engineer to maintain.
OneUptime Free self-hosted with unified monitoring, logs, traces, status pages, and incidents. Predictable tier pricing. But less mature APM and distributed tracing compared to SigNoz or Datadog.
Better Stack Most complete managed alternative with predictable pricing. But not self-hostable. Smaller team than Datadog means fewer integrations and slower feature development.
sources (3)
other https://oneuptime.com/blog/post/2026-03-26-the-3-billion-obs... "surprise bills hitting $130,000 per month" 2026-03-26
other https://www.parseable.com/blog/datadog-log-management-cost "Datadog bill shock has its own meme in DevOps circles" 2026-02-01
other https://oneuptime.com/blog/post/2026-02-28-true-cost-of-obse... "true cost of observability tool sprawl" 2026-02-28
observabilitydevopsmonitoringlogginginfrastructure

53-67% of AI-generated code contains security vulnerabilities, and CVEs from AI-generated code jumped from 6 in January to 35 in March 2026. Traditional SAST tools miss logic-layer bugs that are unique to AI code patterns: backwards auth middleware, missing ownership checks, exposed API keys. Eight scanners now exist but none covers all three security layers (source, config, runtime) in one tool.

builder note

The accelerating CVE count (6 to 35 in 3 months) means this market is growing faster than the tools. Don't build another generic SAST. Build a scanner that understands AI-specific patterns: the backwards conditional, the missing ownership check, the hardcoded API key that looks like a placeholder. Train on real vibe-coded repos, not traditional vulnerability databases. The business model is a GitHub Action that blocks PRs.

landscape (4 existing solutions)

The vibe coding security space exploded from zero to eight tools in under a year, but they're all partial. URL-only scanners miss source bugs. Source-only scanners miss runtime exploitability. The critical gap is a tool that combines static analysis, configuration auditing, AND runtime behavior testing in one pipeline, specifically tuned for AI code anti-patterns rather than traditional vulnerability databases.

Aikido Security Comprehensive platform with 150+ secret patterns but enterprise-priced. Overkill for solo vibe coders shipping weekend projects. No free tier that covers meaningful scanning.
VibeCheck Inline browser scanner that flags issues in real-time. Code never leaves your laptop. But only catches surface-level issues. Can't detect logic bugs like missing auth checks or IDOR vulnerabilities.
AquilaX Vibe Scanner Runs on every commit with CI integration. But focused on known vulnerability patterns. Misses novel AI-specific anti-patterns that traditional databases don't cover.
Lovable Built-in Scanner Runs 4 automated checks before publish. But only works within the Lovable platform. Not portable to Cursor, Claude Code, or other AI coding environments.
sources (3)
other https://dev.to/solobillions/i-tested-every-vibe-coding-secur... "67% contained at least one critical vulnerability" 2026-03-15
other https://vibeappscanner.com/vibe-coding-security "35 new CVEs in March 2026 from AI-generated code" 2026-03-20
other https://www.wits.ac.za/news/latest-news/opinion/2026/2026-03... "hidden risks behind AI-generated code" 2026-03-01
securityAI-codingvibe-codingvulnerability-scanningdeveloper-tools

Local CI Environment Simulator That Matches Remote Runners

dev tool real project •• multiple requests

Developers burn hours on commit-push-wait-fail loops because CI pipelines can't be tested locally. The frustration is universal: you can't reproduce CI failures on your machine because the environments differ. Act (for GitHub Actions) is widely adopted but can't fully simulate GitHub's runners. Dagger abstracts CI into code but requires rewriting pipelines. Someone on HN explicitly said they'd pay for this.

builder note

The NixCI blog post nails the architecture: make CI a local-first script that also runs remotely, not the other way around. The trap is trying to perfectly emulate GitHub/GitLab runners. Instead, invert the model: define CI in portable scripts, then have thin adapters that run them on any CI platform. Dagger has the right idea but the wrong adoption path (rewrite everything). Ship a tool that wraps existing YAML workflows into locally-runnable containers.

landscape (3 existing solutions)

Local CI execution is a solved problem in theory (run the same containers locally) but broken in practice because CI platforms bake services, caching, and secrets into their hosted infrastructure that can't be replicated in a Docker container. The gap is a tool that creates a high-fidelity local replica of CI runner environments without requiring pipeline rewrites.

Act (nektos/act) Runs GitHub Actions locally via Docker but doesn't fully simulate hosted runner services, caching, or artifacts. Some Actions fail because act uses container images that differ from GitHub's VMs.
Dagger Solves local/remote parity by writing pipelines in real languages (Go, Python, TS). But requires rewriting existing YAML pipelines from scratch. Adoption cost is high for teams with mature CI setups.
gitlab-runner exec GitLab's local runner has significant limitations: doesn't support artifacts, dependencies, or most CI features. Widely considered frustrating and incomplete.
sources (2)
hn https://news.ycombinator.com/item?id=46345827 "Solve this and I would pay for it" 2025-12-28
other https://blog.nix-ci.com/post/2026-03-09_ci-should-fail-on-yo... "CI should fail on your machine first" 2026-03-09
CI-CDdeveloper-experiencedevopslocal-developmenttesting

Postman's March 2026 price hike ($19/mo Pro) and forced cloud sync are driving a mass exodus. Developers want a fast, offline-first API client that opens instantly, stores requests locally, supports .http files, and never requires an account. Multiple builders are shipping Rust/Tauri alternatives, but no single tool has captured the full Postman refugee audience yet.

builder note

Don't try to out-feature Postman. The winning move is radical simplicity: instant startup, .http file native, zero accounts. The Postman refugees aren't looking for a better Postman. They want their requests in a plain text file they can grep and commit. Kvile's approach of building on Tauri with Monaco editor is the right architecture.

landscape (4 existing solutions)

The Postman alternative space is fragmenting rapidly with 5+ credible contenders, but none has consolidated the market. Bruno leads in adoption but runs on Electron. Yaak and Kvile are technically superior (Tauri/Rust) but smaller. The winner will be whoever nails import-from-Postman, team collection sharing via Git, and cross-platform consistency first.

Bruno Electron-based so uses ~2x the memory of Tauri alternatives. Missing pre/post-run scripts. Git-friendly collections are great but import from Postman requires manual work for complex setups.
Yaak Built by Insomnia's creator with Tauri/Rust. Covers REST, GraphQL, gRPC, WebSocket. But still young with limited plugin ecosystem and smaller community than Bruno.
Kvile Rust/Tauri, sub-second startup, Monaco editor, .http file native. But very early stage with a single developer. No team sharing features at all.
Hoppscotch Browser-based and fast but lacks offline-first desktop experience. Self-hosted option requires infrastructure. No native .http file support.
sources (4)
other https://tildes.net/~tech/1qyk/is_there_a_postman_alternative... "alot more bloatware added to the program" 2026-02-15
hn https://news.ycombinator.com/item?id=46345827 "Unbloated easy to use postman" 2025-12-28
hn https://news.ycombinator.com/item?id=46937696 "Think Postman without the bloat and login walls" 2026-02-01
developer-toolsAPI-testingprivacyoffline-firstrust