yevyevyev
We built Jolt to solve a fundamental problem with AI coding tools - they struggle with larger, real-world codebases and cannot accurately determine the context files for your prompt.
Jolt's public beta is live today, and we'd love your feedback. You can use Jolt on the web or in any VSCode-based IDE. Our free tier will let you work on codebases up to ~100K lines.
We developed a novel way for Jolt to understand large codebases and automatically determine context files. Our approach scales to multi-million line codebases - the largest codebase using us in production is over 8M lines.
Jolt is optimized for codebase understanding rather than response speed. That said, using Jolt is significantly faster than other tools when you include the time spent selecting context files.
Manually selecting context files is a non-starter when you're working on larger codebases or unfamiliar code. It's a broken product experience. Most AI coding tools rely on some flavor of vector-embedding RAG to determine the files related to your prompt. The reality is that vector-embedding search is not effective on code, and there is a sharp drop in efficacy as codebase size increases.
Here's what folks are using Jolt for: - Writing code, tests, and refactoring - Onboarding developers - Brainstorming a feature's implementation - Asking questions about OSS repos - Writing documentation, including mermaid charts - Contributing across the stack
Thanks for reading, and let us know what you think.
N64 Rendering Hacks and Optimizations
Implementing DDSketch with Redis and a Lua Script for Fast Quantiles
Test feedback - during our TestGen flow, the user provides feedback on the sequence and contents of the API requests. And at the end of the flow, our users can manually edit the resulting JS code for additional customization.
Effort to create a load test - You can go from a Swagger or HAR file to a function load test, written in JS, in a few minutes. There is no learning curve, assuming you have basic knowledge of JavaScript. Maintenance is typically minimal.
CLI - we are launching our CLI shortly, where users can start tests from command line as you describe. It'll work similarly to Jest or other unit test frameworks, where the test scripts will live in our user's codebase.
The use of AI - we use AI to generate realistic-looking synthetic data, which can be challenging with strings. The AI matches each field to the most relevant faker-js function. We need the content of the string to look like something the target application would receive in production. And with HAR files, we use AI to help filter out irrelevant requests such as analytics.
I hope that was helpful, and I'm happy to go into more detail.
Our TestGen feature generates realistic-looking data, such as dates, names, addresses, URLs, etc, automatically based on the field names, examples, and other API spec metadata. It does this automatically, without human intervention. The output is JavaScript, so if further customization is needed, such as using a response value of an API call in a subsequent request, you can do that.
With our TestGen feature, the AI looks at example requests in a HAR file or Swagger examples, or it can solely rely on the name of the property. From there, it automatically generates the correct type and format of data - e.g., if a field is named "address," it generates a value that looks like an address and is formatted in the same way as examples. It wouldn't be practical to cover every potential edge case and scenario without AI.
Show HN: Auto-generate load tests/synthetic test data from OpenAPI spec/HAR file
https://docs.multiple.dev/how-it-works/ai-test-gen
Hey HN,We just shipped a new AI-powered feature... BUT the "AI" piece is largely in the background. Instead of relying on a chatbot, we've integrated AI (with strict input & output guardrails) into a workflow to handle two specific tasks that would be difficult for traditional programming:1. Identifying the most relevant base URL from HAR files, since it would be tedious to cover every edge...
Email API Delivery Time Benchmarks
One major update included with the CLI is a code repo integration - you can have your load test scripts in your codebase and track results to commits.
Accounts on the free tier won't be able to create much of an attack. We perform customer verification on accounts with higher concurrent virtual user limits.
We closely monitor potential abuse and will adjust our verification strategy as needed. Thanks for the question.
> What's the warm-up time on tests?
Tests usually take 20-40 seconds to spin up. Tests with over 10k virtual may take up to 60 seconds to start.
> Any maximums on concurrent users this can simulate?
The free tier supports up to 50 virtual users. Paid tiers can go up to 50k virtual user
Show HN: Multiple – Load test any API with JavaScript and NPM packages
Hey HN,I wanted a better load testing solution – so I built one with my team at Multiple. We just opened early access and would love to get your feedback.We created Multiple to solve three challenges with existing tools:1. Limited scripting capabilities. XML or GUI-based scripting can only test basic scenarios. Existing code-based tools struggle with auth, generating synthetic data, and testing...
Ask HN: Load Testing APIs
What's everyone's philosophy and approach to load testing these days? Do you do it/when? And what tools/services do you use?