Colimit

While working on Colimit, we've experimented with different approaches to handle file context management in LLM-powered devtools. The DX of most current solutions feels bolted onto existing IDEs, with clunky interactions. ?? One interesting approach that we landed on is applying Git's mental model to this problem. By separating viewing files (like browsing) from managing context (like Git's staging of changes), we can get two more focused modes of interaction: ??? View mode: See what's in context without risk of accidental changes ?? Edit mode: Add/remove files with familiar Git-like +/- visual indicators and the ability to undo (like un-staging) This separation let's you quickly see which files are important when debugging complex issues, and reduces anxiety related to accidentally deleting important file references from context. Even more interestingly, the set of files you settle on becomes a useful artifact that documents what you needed to understand the problem, something Git history alone doesn't capture (it only contains what ultimately changed). ↓ There's a more detailed blog post with screenshots and a YouTube video linked in the comments if you're interested. I'm also curious about what other similar approaches people have been trying?

One major lesson everyone learned from the recent popularity of DeepSeek R1's exposed thinking is that transparency matters. At Colimit, we just took that lesson to heart and exposed the entire debugging process that's performed when we generate fixes for your failing CI builds (YouTube video walkthrough in the comments!) It's obvious in retrospect, but Engineers don't just want fixes; they want to understand, debate, learn, and interact. ?? What's New ?? 1?? Root Cause Analysis Reports:? Colimit now shares its internal logic: hypotheses, evidence (supporting/contradictory), confidence scores, and more. Like a code review for AI reasoning, so you can validate its logic or challenge its assumptions. 2?? Deep Analysis Mode: For perplexing bugs like race conditions, CI-only failures, and other layered bugs, Colimit recursively chases dependencies, critiques its own hypotheses, and debates the merits of alternative fixes. 3?? Analysis Mode Selection: Choose "Quick" (e.g., for linter errors), "Standard" (e.g., for most bugs), or "Deep" (e.g., for perplexing behavior). ?? Case Study ?? Recently Anchor.dev @anchor was debugging a failed CI build for 2-days straight (involving shared test-only DNS servers, parallel tests, mutexes, etc.), until Colimit's exposed analysis reports helped them: - Review 3 root cause hypotheses with confidence scores - Rank potential fixes by their merits vs risk/complexity - Paste Slack threads to refine context with pre-existing investigations The Result: They were able to isolate the root cause and fix it the next morning. ??? Engineers Hate Black Boxes ??? This isn't just about automation, it's about closing the gap between "fixed" and understood. It's important to: - Learn why a failing build happened, not just how to patch it - Use the AI's hypotheses as a starting point for your own investigation - Add team context (more logs, prior attempts) to steer the analysis ?? Why This Resonates ?? Tools that hide their logic breed distrust. Colimit's transparency turns fixes into teachable moments: so you debug with the AI, not just delegate to it. ?? Demo video walkthrough in the comments ↓ P.S. Big thanks to the Anchor team for trying out early versions of this tech and giving feedback on the value of visibility into the debugging process.

Feeling pretty proud today—Colimit's improved architecture is taking us from shallow bug fixes to deep bug fixes. A dev was stuck on a bug for two days straight before using Colimit for the first time to fix it the next morning. The bug was a gnarly race condition involving parallel access to a DNS server in CI—threads, forked processes, shared sockets, file descriptors… lots of painful printf debugging. Even worse, it appeared to only fail in CI and worked locally. But Colimit got to the root cause and helped fixed it! Now onto making the new architecture generally available. ??

Ever run into that moment where you’ve pushed your code, grabbed a coffee, and then realized CI failed because of a tiny oversight—like an outdated test expectation? It’s a real flow-breaker to switch back branches, rebuild the project, and fix something trivial. That’s why we built Colimit, an AI janitor for your CI. We focus on an often overlooked “pre-PR” stage, where small mistakes can slip through and cost you time. How it works: - If a GitHub Action suddenly fails, Colimit automatically picks up and implements the menial fix. - No need to interrupt your local flow—just click “Push Fix” in our web UI. - Stay focused on your new task while our AI takes care of the housekeeping. Here’s a quick demo: https://lnkd.in/eikkkzhp Let me know what you think—and if you’re curious, feel free to message me or start a free trial. Happy to answer any questions!

Hi everyone, I've got a big announcement: My startup Colimit recently pivoted from being a bug-finding service to a bug-fixing service for failed CI builds (initially GitHub Actions). Links to the site + demo + discord in the comments :) What follows is a story about how this came about (likes/comments/sharing is very appreciated!): The initial goal was to make model-checking and model-based testing (and even formalization) more widespread by creating an accessible TypeScript-like modeling language, paired with a cloud that executed verification and tests at scale. We found real bugs for our design partners, giving them room to refactor with confidence. At first we wrote the models for them, but when trying to hand off the modeling we learned a hard lesson. Even if modeling in our DSL is approximately the same effort as writing tests, it's still something new to learn. For business uptake, any amount of extra work to be done quickly kills adoption/onboarding, even if the results are great. The answer was clear: Use LLM's to auto-model/auto-formalize: But that gives Colimit as a company even more work and less runway. Luckily, we noticed that during our demos one part of our product lit up people's eyes: The auto-generated "debugging notes", and the associated auto-fixer of the bugs that Colimit's bug-finder identified. With LLM's these days, this part is a lot easier to get off the ground. So we made a hard choice and reversed our roadmap: 1. First auto-fixing as as a service 2. Auto-modeling. Models act as "context compression" of a codebase, and can be checked for logical consistency much more quickly, prior to longer running builds and test runs. 3. Reintroduce bug-finding, now palatable via auto-generated models. The mission is the same, increasing software reliability by popularizing [semi]formal methods, but this prioritization allows us to grow as a business. Our current autofixer integrates with GitHub Actions and I'm excited to announce that we just launched it for Early Access! Right now it's mostly useful for tedious but frequently occurring bugs, like linting failures and misaligned expectations in basic unit or integration tests. As our auto-modeling takes shape, we will expand from shallow bug fixing to deep bug fixing, using formal models as our technical leverage. Please join us by checking out the site, demo, or joining our discord :)

?? Folks have asked me what automatically testing an API with Colimit looks like, so in the spirit of #buildinpublic, here are a couple of videos! ?? If you think this kind of thing is cool, please like/comment/repost :D #testing?#api #rubyonrails ?? First, here is a value-centric demo of finding some bugs in an open source Rails API based on something similar to a Swagger spec: https://lnkd.in/eZdFC3GG ?? Second, if you're into behind-the-scenes content, here's a more rambly video about how our SDK works, our vision for spec-driven-development, and how theorem-prover-based testing complements LLM-based coding: https://lnkd.in/eyQBKh_v ?? Finally, if you think this type of tech could be useful to you, don't hesitate to reach out! We're running a limited capacity white-glove private beta, but also happy to connect with folks that might be interested when GA is ready.?