Hey HN! We are Sam, Alex and Ben from Patchwork Technologies (<a href="https://getpatchwork.io">https://getpatchwork.io</a>). Patchwork automatically adds actionable structured logs to your code. Big picture: we are building a next generation logging and observability platform which gives engineers the rich debugging context they need.<p>There’s a demo video (<a href="https://youtu.be/ObIepiXfVx0" rel="nofollow">https://youtu.be/ObIepiXfVx0</a>), as well as a demo^ instance with some results for you to explore at <a href="https://hackernews.getpatchwork.io">https://hackernews.getpatchwork.io</a> (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,
<a href="https://github.com/elastic/cloud-on-k8s">https://github.com/elastic/cloud-on-k8s</a> and our awesome friends at Glasskube (<a href="https://github.com/glasskube/glasskube">https://github.com/glasskube/glasskube</a>). We welcome suggestions of other OSS Go repositories that you would like to see added!<p>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 – <i>Error: Failed to do task.</i> Datadog made metrics easy; we are creating that moment for logs.<p>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?<p>Refactoring the logs in existing code bases today is a manual slog. Even finding the existing logging and <i>printf</i> 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.<p>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.<p>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: <a href="https://discord.gg/fkVTgX5s" rel="nofollow">https://discord.gg/fkVTgX5s</a>.<p>^If you'd like to enrol additional repos and run analysis on them, there's a magic link step.