Каталог продуктов

CA

Capgo

Мгновенные обновления для Capacitor-приложений. Выпускайте исправления за минуты, а не недели. Отправляйте OTA-обновления пользователям без задержек App Store.

IN

Integuru

Hey HN! We’re Alan and Richard from Integuru (YC W24). We generate fast, reliable integrations for platforms lacking official APIs. About 2 years ago, we released the first agent that reverse-engineers network traffic to build integrations (https://github.com/Integuru-AI/Integuru). Since then, we’ve developed a new approach to reverse-engineer platforms’ source code directly. This solution also includes authentication support. Here’s a demo: https://youtu.be/4l2L8fILC2g?si=nbWbDiFrWZIWRPM7. Many AI products need to integrate with web apps, but platforms often lack official APIs. So far, there are two main ways to integrate: browser automation and via network requests. We set out to build the original agent because we ourselves suffered from RPA’s latency, reliability, and throughput issues. The original agent solved many of the prior issues, but it wasn’t perfect either. The original agent did things the obvious way: (1) have a human do the action; (2) the agent observes the network requests and (3) recreates them. That got us far, but it only supported the path the user triggered. In production, we saw all the uncovered cases: different states, missing fields, permission differences, hidden validations, and request changes we could never catch in a single run. So we started building a new solution from the ground up. Our first step was to add agents that trigger many variations of the same action. To protect the platform’s data integrity, we added a gating layer that blocks outbound requests. This lets us observe the exact request structure, branching behavior, and platform logic without accidentally mutating the live system. But this still wasn’t enough. Some logic is hard to surface by execution alone. A lot of the business rules live in the frontend bundle. So we set out to analyze the true “answer sheet” for each platform: the source code. After experimenting, we got this working. We built a source-code analysis layer that deobfuscates and traces the code associated with each action. In practical terms, our system can handle most tricky edge cases without triggering all flows. Together, these two layers result in much better coverage of the production surface area. They support more edge cases, fail less often, and avoid a lot of the brittle one-off fixes that usually come later. Finally, we added auto-healing and API doc generation to improve reliability and the UX. We also offer a 24/7 on-call maintenance team for companies on the production plan. We now spend most of our time supporting vertical AI companies and helping them connect to their customer systems. We offer a free plan for integrating with one platform and charge for additional platforms, accounts, and overage API calls. For instance, we help healthcare AI companies connect to EHRs and payer portals, and logistics companies connect to TMSs and ERPs. Some companies are now running more than 1M monthly requests per platform. Across our production users, API calls complete in ~3 seconds at 99.9%+ success rate on average. We’re also building a library of APIs that users can use out of the box. That said, this version still has limitations we want to iterate on. Although we already tackle some anti-bot mechanisms, the agent still struggles to generate integrations with heavily anti-botted platforms. When the agent fails, our on-call team steps in to improve the agent or build the integration manually if the customer requests it. Also, the UX for generating an integration is still quite manual. Our next step is to build a CLI experience, so people and their agents can create, test, and use integrations in a much more flexible manner. This also prevents humans from having to wait for Integuru to finish its tasks. We want to one day allow developers and agents to integrate with all platforms instantly. Integuru is an ongoing effort. We’re passionate about automating integrations and would love your feedback!

LC

LINQ CLI

Hey my name is Patrick, I’m a co-founder and CTO of Linq. We’re an API for sending and receiving iMessages (it does RCS/SMS too). It can do everything you can manually in iMessage (typing indicators, reactions, delivery emphasis, FindMy etc.) Our main customers are companies building conversational agents but we’re wanting to make it easier for developers to get started for free. To do that we built a CLI that lets you manage up to 20 contacts and gives you full API access for free. I’d love your feedback so we can keep improving it. Install via npm using: npm install -g @linqapp/cli Recently, I used the CLI to connect my Claude bot to WeWork & iMessage and haven’t had to use the WeWork app in a few weeks to book rooms. Github: https://github.com/linq-team/linq-cli Landing page: https://linqapp.com/cli Three constraints you should know about: 1. The free tier requires inbound-first (ie someone must text you before you text them) and has a limit of 20 contacts. This is to avoid spam. 2. The line is shared. This means a few other people will be using the same phone number as you, none of our paid production lines work this way. If you're testing enterprise grade our sandbox mirrors production, but has a 7 day time limit. The CLI is shared because there is a real infrastructure cost to us and we want to give this away for free. 3. We require an email to sign up. To avoid spam + our infrastructure cost. To be precise about "open source", it's the CLI. The whole client is in that repo, so you can read exactly what leaves your machine. The backend that delivers messages is closed.

TR

Trychert

Hey HN! We’re Gary and Ian, and we’re building Chert (https://www.trychert.com/), an API for businesses to send, receive, and automate iMessage conversations at scale. Check out our demo: https://www.youtube.com/watch?v=SRdwvVxMMoI. We originally started by building products on top of iMessage because the blue bubble interface, typing indicators, and reactions made agentic conversations feel more human than ones on SMS/RCS. These included a one-shot iMessage agent builder that reached 2,000 users in one week and an automated iMessage outbound sequencer that sent thousands of outbound messages per day. The hard part is that iMessage does not have a native API like SMS/RCS. Sending and receiving iMessages requires a separate infrastructure that is difficult to set up and maintain, especially at scale. As we talked to more companies, we realized that the highest-volume use cases for iMessage were not B2C agents or even sales. They were things like customer service, missed-call text-back, cart abandonment, and inbound lead capture in verticals like home services, DTC brands, and property management that drive the highest volume. Furthermore, these companies often need additional support, such as custom infrastructure setup (e.g. contact card, area code, or local worker sessions), integration support with their existing SMS/RCS or voice agent systems, and a reliable way to scale their volume over time. We built Chert to be an infrastructure layer for businesses to handle iMessage conversations at scale. Businesses can use our API to send and receive iMessages programmatically, route replies to humans or agents, and integrate conversations into the systems they already use. To maintain stability across both outbound and inbound use cases, we built phone line health checks and SMS/RCS fallback systems. We also integrate with existing SMS/RCS systems, voice agents, CRMs such as Salesforce, HubSpot, and Attio, and tools like Slack. Finally, we let businesses reliably scale from a few test lines to hundreds of lines with automated line provisioning and a usage-based pricing structure. We’re working with companies doing conversational messaging in DTC, sports programs, property management, and home services at the scale of hundreds of lines. We’d love to hear your thoughts on this and other similar verticals where iMessage could be useful. All comments welcome!

RU

Runtm

Hey HN, We're Gus and Carlos from Runtime (https://runtm.com). We're building infra that lets your whole team (including non-engineers) ship with Claude Code, Codex, and other agents without engineering having to handhold every session. After Mentum (YC S21) was acquired, I personally shipped 4 full-stack products in 3 months using coding agents. When I tried to roll the same workflow out to the rest of the team, it fell apart: Most PRs were unmergeable slop - Every repo required an engineer doing one-off local setup. - Skills and context lived in one person's head. - There was no safe way for a PM to touch a real codebase without risking a bad deploy or a secrets leak. Carlos comes from building agentic reconciliation systems at Modern Treasury and had a similar experience when letting his support team use devin. We ended up building internal background agent infra but it quickly became a nightmare to mantain and develop. We built Runtime so you don't have to do this kind of thing. Runtime work like as follows. Engineering defines the context once: system instructions, skills, and scoped integrations installable via CLI, mise, npm, or any package manager. Then Runtime snapshots your full running environment including multi-service Docker Compose setups, Kafka, Redis, seeded DBs, so it comes up in milliseconds with every server already running. We orchestrate across sandbox providers like E2B, Daytona, EC2 or self-hosted K8s depending on your setup. Secrets are injected through our managed proxy so they never touch the agent directly, and guardrails run at the infrastructure level: command allow/deny lists, network egress controls, and RBAC scoped per human and per agent. Every session also gets a shareable preview URL, so internal builds go from sandbox to the rest of the team without needing production access. Runtime works with whichever agent your team already uses: Claude Code, Codex, Cursor, Copilot, Gemini, Devin. You can trigger sandboxes from our web app, CLI, Slack, Linear, GitHub, or API. One of our customers built an on-call inspector that wires PagerDuty, Sentry, and their repo so when an alert fires, the agent finds the cause and opens a PR with a unit test before anyone gets paged. Another runs a finance agent in a private Slack channel pulling from Stripe, NetSuite, and Snowflake to run reconciliations in minutes with source rows attached. A fintech unicorn and several YC scaleups are live on Runtime, including a few teams who had built similar infrastructure internally and handed it to us to take over. The core is open source at https://github.com/runtm-ai/runtm. Hosted version is live at https://app.runtm.com, free tier included. We're charging a flat platform fee plus compute, no token markup. Check our demo: https://www.youtube.com/watch?v=wLwj__aEEh4 We'd love to hear how you're thinking about the infra for letting more people across your org use coding agents without creating chaos!

HC

Headless Cloud Security

The cloud security company I work for, Sysdig, launched “Headless Cloud Security” last week. The short version: as attacks get faster and more automated, security tooling is going to need to evolve beyond dashboards and humans clicking through workflows all day. We’ve already seen “headless” models emerge in other categories, and engineering teams are rapidly adopting agentic and CLI-first workflows with tools like Claude Code, Cursor, and MCP servers. Security teams, historically, tend to lag engineering adoption curves by 6–18 months, but I don’t think that gap will hold much longer. The idea behind headless security is that security capabilities should be consumable programmatically — through APIs, AI agents, IDEs, CI/CD pipelines, and automated workflows — not just through a UI. This post covers it in more detail: https://www.sysdig.com/learn-cloud-native/what-is-headless-c... Curious whether others here are seeing similar shifts inside their orgs, especially around AI-assisted development and security operations.

AI

Agentic interface for mainframes and COBOL

Hi HN, we’re Sai and Aayush, and we’re building Hypercubic (https://www.hypercubic.ai/), bringing AI tools to the mainframe and COBOL world. (We did a Launch HN last year: https://news.ycombinator.com/item?id=45877517.) Today we’re launching Hopper, an agentic development environment for mainframes. You can download it here: https://www.hypercubic.ai/hopper, and you can also request access and immediately get a mainframe user account to play with. There's also a video runthrough at https://www.youtube.com/watch?v=q81L5DcfBvE. Mainframes still run a surprising amount of critical infrastructure: banking, payments, insurance, airlines, government programs, logistics, and core operations at large institutions. Many of these systems are decades old, but they continue to process enormous transaction volumes because they are reliable, secure, and deeply embedded into business operations. A lot of that software is written in COBOL and runs on IBM z/OS. The development environment looks very different from modern cloud or Unix-style development. Instead of GitHub, shell commands, package managers, and CI pipelines, developers often work through TN3270 terminal sessions, ISPF panels, partitioned datasets, JCL, JES queues, spool output, return codes, VSAM files, CICS transactions, and shop-specific conventions. TN3270 is the terminal interface used to interact with many IBM mainframe systems. ISPF is the menu and panel system developers use inside that terminal to browse datasets, edit source, submit jobs, and inspect output. It is powerful and reliable, but it was designed for expert humans navigating screens, function keys, and fixed-width workflows, not AI agents. A simple COBOL change might require finding the right source member, checking copybooks, locating compile JCL, submitting a job, reading JES/SYSPRINT output, interpreting condition codes, patching fixed-width source, and resubmitting. Much of this work is so well-defined and repetitive that it's a good fit for agentic AI. To get that working, however, a chatbot next to a terminal is not enough. The agent needs to operate inside the mainframe environment. Hopper combines three things: (1) A real TN3270 terminal, (2) Mainframe-aware panels for datasets, members, jobs, and spool output, and (3) An AI agent that can operate across those z/OS surfaces. For example, here is a tiny version of the kind of thing Hopper can help debug: COBOL: IDENTIFICATION DIVISION. PROGRAM-ID. PAYCALC. DATA DIVISION. WORKING-STORAGE SECTION. 01 CUSTOMER-BALANCE PIC 9(7)V99. PROCEDURE DIVISION. ADD 100.00 TO CUSTOMER-BALNCE DISPLAY "UPDATED BALANCE: " CUSTOMER-BALANCE STOP RUN. JCL: //PAYCOMP JOB (ACCT),'COMPILE',CLASS=A,MSGCLASS=X //COBOL EXEC IGYWCL [//COBOL.SYSIN](https://cobol.sysin/) DD DSN=USER1.APP.COBOL(PAYCALC),DISP=SHR [//LKED.SYSLMOD](https://lked.syslmod/) DD DSN=USER1.APP.LOAD(PAYCALC),DISP=SHR A human would submit this job, inspect JES output, open `SYSPRINT`, find the undefined `CUSTOMER-BALNCE`, map it back to the source, patch the member, and resubmit. Hopper is designed to let an agent operate through that same loop autonomously. Hopper is not trying to hide the mainframe behind a generic abstraction, and it's not a chatbot. The design principle is simple: preserve the fidelity of the mainframe environment, but make it accessible to AI agents. Sensitive operations require approval, and the terminal remains visible at all times. Once agents can operate inside the mainframe environment, new workflows become possible: faster job debugging, automated documentation, safer code changes, test generation, migration planning, traffic replay, and modernization verification. We’re curious to hear your thoughts! especially from anyone who has worked with mainframes, COBOL or has done legacy enterprise modernization.

SP

Spec27

Hi HN! We’re a team of ML validation specialists and we’ve been building /Spec27, a tool for testing whether AI agents still do their job safely and reliably as models, prompts, tools, and surrounding systems change. We started working on this because a lot of current LLM evaluation work seems aimed at scoring general model behavior, while many teams are deploying systems that have a specific mission to fulfill. Many of the tools also assume you have full access to the agent stack and traces so you can place SDKs and Gateways, but a lot of agents are being created on vendor platforms where this isn’t possible. As a result, we approaches it from the outside in: all tests just run to the primary interfaces of an Agent and don’t assume anything about internals. The other important things about the approach is spec-driven. Instead of treating testing as a one-off benchmark or static eval set, we let teams define reusable specifications for the behavior they want from an agent, then generate tests against those specs. With this you can automatically generate adversarial and robustness checks, so you can see what an agent is sensitive to and what kinds of changes cause it to fail. We’ve worked on validation for other AI systems before, including vision and tabular workflows, and /Spec27 is our new product for language-model-based agents. Currently in early access, so we’d love feedback! The current version is strongest for single-turn agent and application validation. We do not fully support multi-turn interactions yet, and better telemetry/tool-call integration is still on our roadmap. We’ve made the product open to try for HN readers, with a sample flow so it’s easy to poke around without much setup. We’d especially love feedback from people deploying internal agents, vendor agents, or other AI systems where reliability matters more than benchmark scores.

GC

Graph Compose

Hey HN. Graph Compose is a hosted platform for orchestrating API workflows on Temporal. You define workflows as graphs of nodes (HTTP calls, AI agents, iterators, error boundaries) and everything runs as a durable Temporal workflow under the hood. Three ways to build the same graph: a React Flow visual builder, a typed TypeScript SDK (@graph-compose/client), and an AI assistant that turns plain English into a graph. Open-core: the execution foundations and integrations service are AGPL-3.0. The platform orchestrator, visual builder, and AI assistant are proprietary. Longer backstory on why I built this in the first comment. Would love feedback, especially from anyone who's dealt with the "services work fine, the glue between them doesn't" problem. Docs: https://graphcompose.io/docs

WS

We scored 50k PRs with AI

I'm a CTO with a ~16-person engineering team. Last year I wanted real data on what was actually shipping, not guesswork or story point theater. So we built GitVelocity. Every merged PR gets scored 0–100 by Claude across six dimensions: scope (0–20), architecture (0–20), implementation (0–20), risk (0–20), quality (0–15), perf/security (0–5). Six dimensions added up, then scaled by change size — a 10-line fix scores lower than a 500-line refactor even at the same complexity. Full formula at gitvelocity.dev/scoring-guide. After scoring 50,000+ PRs across TypeScript, Python, Rust, Go, Java, Elixir, and more, some things surprised us: Big PRs don't automatically score high. An 800-line migration with low complexity scores worse than a 200-line architectural change. Size gets you the full multiplier, but the base score still has to earn it. You can't score well without tests. The quality dimension (0–15) won't give you points without test coverage. At similar experience levels, this was the clearest separator between engineers. Juniors started outscoring some seniors. They adopted AI tools faster and took on harder problems. Once they could see their own scores, they aimed higher. We score AI-generated code the same as human-written code. Code is code. An engineer who uses AI to ship more complex work faster is more productive, and their scores reflect that. Scoring consistency was the hardest technical problem. Without reference examples anchoring each dimension, Claude's scores drifted 15+ points between runs. With 18 calibrated anchors (three per dimension at low/mid/high), we got it down to 2–4 points on the same PR. The thing we didn't expect was behavioral. We call it the Fitbit effect — the tool doesn't make you ship better code, but seeing the score does. Engineers started referencing their own scores in 1:1s unprompted, because the numbers matched what they already felt about their work. A junior who shipped a tricky concurrency fix could point to a score that proved it wasn't "just a small PR." We recently added team benchmarks (gitvelocity.dev/demo/benchmarks). Once you're scoring PRs, you can see how your team compares to others across the dataset — about 1,000 engineers on 60 teams so far. Headline's team ships faster than roughly 95% of them, which was nice to confirm but also made us wonder who the other 5% are. The competitive angle surprised us: teams that were skeptical about individual scores got genuinely curious once they could measure themselves against the field. Every score is fully visible to the engineer who wrote the PR, with per-dimension breakdowns and reasoning. There's no hidden dashboard that management sees and engineers don't. Free, BYOK (your Anthropic API key). We default to Sonnet 4.6, which scores nearly as well as Opus 4.6 at a fraction of the cost — but you can switch models if you want. Pennies per PR either way. No source code stored, diffs analyzed and discarded. Works with GitHub, GitLab, and Bitbucket. Ask me anything about the scoring methodology, how we solved calibration, or what it was actually like rolling this out to a team.