1
kinda obsessed with branching. Git for everything.
threds.dev
For our Launch HN (Aug), we set up a demo instance with pre-baked results. We wanted to go further to allow HN readers to give the product a proper test drive. https://open.invaria.io includes some pre-analysed OSS (Go, TS and Python) repos (no sign-in required). It also allows users to enroll additional OSS repos (limited to Go for now) that they’d like to see analysed (magic link sign-in required for this to allow us to manage state). The demo focuses on batch analysis of existing repos, providing an overview of instrumentation health, line-level code improvements with rationale, and related GH pull request examples (in practice these are usually bundles of many changes). A quick video here to help you find your way: https://youtu.be/IM9EFl4gwVs. Any questions, please email us at founders@invaria.io.
Since our last post, we’ve been iterating with our first customer/design partner in order to drive up the quality and consistency of outputs. We’re hitting 85% change acceptance rate with our customer on their main Go repo (1m+ LoC, 1000s of logging statements). Logs are their main telemetry source for debugging, and they want structured logs as standard. Yielding consistent results from LLMs is hard (no news there), and that’s been a big focus for us since our Launch HN. Breaking down prompts, refining the context we fetch from the syntax tree, and providing examples is where we have focused efforts.
We’re building Invaria because getting high quality telemetry from applications is still time-consuming and hard. We discuss it here in more detail: https://www.invaria.io/post/your-telemetry-is-garbage. OpenTelemetry has helped bridge the gap, but the event data that comes from auto-instrumented tracing, e.g. at the API level, is not enough for the typical (imperfect) application. It’s usually necessary to manually add further span and attributes, and to clean up any logging that’s burned into spans.
We’re starting with logging statements as the simplest form of event-level telemetry. Invaria can upgrade existing logging statements, and instrument key events with new statements. The demo instance demonstrates ‘batch mode’ on legacy code, and we are beta testing a CI-time integration right now. The goal is to automate instrumentation at the CI step, so that developers can focus on the creative engineering work.
Once again, your honest feedback would mean a lot to us. We have a lot of conviction that observability needs a shake up and that better outcomes require higher data quality. We’d love to hear what you think works and doesn’t work in our current approaches, and whether Invaria solves a problem for you.
A note on the name change: we really like the name Patchwork, but there are several other software companies/products with similar names. It caused some confusion during launches. We like invariant, a word borrowed from the control theory domain. We thought making high quality telemetry a constant was a nice mission statement.
There’s a demo video (https://youtu.be/ObIepiXfVx0), as well as a demo^ instance with some results for you to explore at https://hackernews.getpatchwork.io (no sign-in required!) The demo shows the analysis and improvement (against a style guide) of existing logs. It’s set up for two OSS repositories, https://github.com/elastic/cloud-on-k8s and our awesome friends at Glasskube (https://github.com/glasskube/glasskube). We welcome suggestions of other OSS Go repositories that you would like to see added!
Why we are building this: At our previous company, we relied heavily on actionable, context-rich structured logs. They were the unsexy but critical tool for managing complex software at scale. When they’re implemented well, they allow you to understand the application state when things break. Structured logs are easier to search and run analytics on. The trouble is that they are time-consuming to implement properly – if you’re reading this, you know it’s a chore. We all know it’s usually an SRE (like Alex) that finds out at 2 am that logs were added as an afterthought. Unstructured and spammy – Error: Failed to do task. Datadog made metrics easy; we are creating that moment for logs.
We've grappled with some tough technical challenges to build our product. First, identifying log statements in codebases where logger symbols are inconsistently named or output directly to stdout/stderr. We solved this with SCIP, indexing symbol references at compile time. Next, we needed to provide the LLM with method context and variable types to ensure we accurately understand what the code is doing. This is achieved using tree-sitter for parsing and SCIP for repo navigation. Finally, we addressed the critical need to reason whether specific data can/should be logged before bringing this all together in an improved logging statement. We’re staring down the next challenge – where should logging statements go in new code?
Refactoring the logs in existing code bases today is a manual slog. Even finding the existing logging and printf statements is tricky at scale. It’s possible to rely on Copilot in VS Code or Cursor to help construct logs as you write new code. However, there are many more reasoning steps required than these tools are designed to do. They are general purpose, zero-shot machines.
Our first goal is to reliably improve existing logging statements (as in the demo). In the next couple of weeks we aim to prove-out adding logs to new applications. Structured logs provide downstream benefits when it comes to storage and query time – our final goal is to build a storage layer that exploits this.
Your honest feedback would mean a lot to us. We have a lot of conviction that observability needs a shake up, and that going back and getting the basics right is valuable. We’d love to hear what you think works and doesn’t work in current approaches, and whether Patchwork solves a problem for you. Chat with us on Discord: https://discord.gg/fkVTgX5s.
^If you'd like to enrol additional repos and run analysis on them, there's a magic link step.