[Convex] Improve syntax and tools for AI coding assistant integration

Time for a periodic @convex roadmap update! We’ve been consolidating recently on a smaller set of features that we want to execute on fast and get out very soon. I’ll break these down into three broad categories. 1. Be more open, be more helpful Convex is a new way of doing things! This can be scary to some folks. We want to reduce barriers to Convex adoption, get more people on the platform, and also address any concerns about billing. 1.1. Self-hostable Convex Convex is already open source but it’s currently not clear how to run OSS Convex in the cloud, it only writes to local sqlite, it doesn’t include the dashboard etc. Some folks are using this already (thank you!) but we want to put something much better out there. Late next week we’ll launch a proper self-hostable OSS Convex release that includes the dashboard and runs out of the box with some existing cloud compute/db providers, plus eventually you should be able to run this wherever supports a docker container and postgres/mysql. 1.2 Local dev Some of you are already using this but we’re slowly releasing a version of `npx convex dev` that runs an entirely local backend on your computer, plus the ability to still have a cloud dev deployment if you want that. This means you can build your Convex app on a plane and you can also mess around with stuff without worrying about usage charges. Technically this is “done” but we’re doing a slow roll-out to catch various issues that happen with different client OSes etc. 1.3 Trustworthy billing No one likes getting hit with an unexpectedly high bill because they accidentally wrote a scheduled job that runs in a tight loop. We’re launching spend limits soon which let you put a hard cap on your usage. We’re also going to put a pricing calculator on the website; it’s a bit of a conspicuous gap currently. 2. Good for people, good for robots Most developers are transitioning to leveraging AI-coding assistants heavily in their dev workflow. I think we have a real credible claim that the clean abstractions in Convex make it not only ergonomic for human developers, but also the ideal target for LLM-based development. 2.1 AI evals We’ve been developing a set of “evals” or experiments that test Convex on a variety of coding challenges and full stack app descriptions. We’re using these to improve Convex itself, improve our prompts to these models, but also to run comparative benchmarks that show that building on Convex most-reliably produces correct output with concise code. There’s some early work in our evals repo: https://t.co/Kgdf8gBKyL 2.2 Prompts and guides The “knowledge cutoff” in LLMs means that they don’t always know the state of the art of all platforms and don’t know everything about Convex. Fortunately we have an ever-improving set of prompts that allow apps like Cursor to produce excellent Convex code. We’re continuing to improve our prompts as we run more evals but if you’re using an AI coding tool you should be using rules like these: https://t.co/DikhVzrZ4h 2.3 Syntax improvements We’ll talk more about this later but there are some basic things that LLMs trip up on, like filters, our index syntax, map-style joins, etc. These are known gaps but there’s even more motivation to fix these now. We’re also working on better tools for integration with AI development platforms. 3. A better core experience We’ve been spending so much time building new features that it seems time to improve the core day-to-day developer experience on Convex. This includes a whole bunch of projects including: * Increasing function execution limits, parallelism, various size limits. * Move all backends to our new high-scale infrastructure. * Cut down on latency for calls to a Convex component. * Add support for custom domains that completely remove .convex.cloud from your app. * Speeding up backups. * Surface better insights and lint rules. * Better caching and product changes for a snappier client experience. What we’re not doing We still haven't shipped our object sync engine for local-first workloads. This is on hold for a bit as we iterate on the developer experience. The DX ended up feeling too complex with server-side resolvers like GraphQL and we want to spend more time getting this right. While the object sync engine marinates, we'll keep on working on improving client-side latency and caching for our regular old sync protocol. I’d love for us to be working on built-in support for slow queries that run against a snapshot and allow you to run an occasional inefficient query as needed by your application. The desire to run more analytics-style queries is a very common request. I’d also love to prioritize some more work around bundling, separate compilation units, speeding up code sync time, and guidelines for managing large codebases in Convex. This will be high priority once we get through the projects above. Drop me a reply with comments, requests, or questions!