mike210

I hated getting paged late at night when I was on-call. So around two months ago, I built an AI assistant to do on-call for me, and posted it to Reddit (https://redd.it/1jibmtc). Turns out everyone hates getting paged - 300+ devs messaged me about it!

After a ton of work, it’s now ready to use. It’s called… well… OnCall, and it’s your AI on-call assistant.

OnCall solves errors thrown from your app, using all the tools and resources you do. It looks at the stack trace and reads source code to understand the error. It sifts through logs, browses the internet, and executes shell commands. Then it codes, commits, and creates a pull request with a nice description.

The performance is surprisingly good. On my limited early testing, it solves most errors perfectly in one try, and makes progress on many it misses. Fixes are isolated on a branch, so if the fix isn’t great, just don’t merge!

It connects via SDK and is triggered automatically when your app throws an exception. When it works well, it’s a fix PR for the error that just lands in your lap around 90 seconds after the error occurs!

Here are different ways to check out OnCall, depending on how busy you are:

[15 seconds] - No login public preview dashboard: https://web.oncallapp.ai/public/demo

[2 minutes] - Video demo: https://youtu.be/OZIoCF2-Hlk

[7 minutes] - Sign up and try it: https://oncallapp.ai

Necessary disclaimers: You should definitely review the code it produces. OnCall connects to your Github and Slack at a minimum, and LLM providers (Google/Anthropic/OpenAI) process part of your code. If you can’t use ChatGPT or Cursor at your work, you probably shouldn’t use OnCall.

Looking forward to hear feedback and ideas!

The lazy architect (OpenAI’s o3). o3 is incredibly lazy at writing code, but very good at planning. Will happily read tens of files and do deep analysis, but often struggles in scenarios where it needs to edit more than one file.

The over-eager child (Claude Sonnet 3.7 Thinking). Claude Sonnet is eager to just get going, man! It’s not the most careful, and in longer strings of tool calls, may start editing something completely unrelated to what you asked it to.

Pretty balanced?(Gemini 2.5 Pro). Gemini 2.5 is a little more intelligent, and significantly faster and more reserved than Sonnet 3.7. Usually the best choice for writing code in multiple files.

I’ve found o4-mini to be incredibly slow and fairly mediocre, and GPT 4.1 useful in very situational areas. My tips:

- Use o3 to plan and/or write code in one or max two file only. If you do more, it may openly revolt and just refuse to write any longer.

- Always make sure Sonnet 3.7 is following a tightly scoped plan on a relatively small section of the product, and supervise it. If you have an easy change to make in many areas of your codebase, for example, letting Sonnet run, still supervised, is a perfect use of the model’s persona

Generally what I do:

- Medium complexity: editing one file: o3. Editing multiple files: plan with o3, write with gemini-2.5

- Simple complexity: Editing many files, very simple: plan with o3 if needed, write with claude-3.7. Editing many files, simple, needs formulaic approach: write a detailed prompt into GPT 4.1

- High complexity: plan with o3, separate into multiple chunks, write small chunks at a time with gemini-2.5 and be very careful with each section. If I'm super lazy sometimes I just YOLO all of the sections and then fix all the bugs at the end but this probably leads to code issues later down the line.

Would love to hear other people are using the different models!

Everyone hates production bugs. Users get frustrated. Engineers get paged. Development gets delayed. But what if many of those bugs could be fixed automatically?

Enter Paladin, a tool I built that automatically sends you a pull request to fix bugs shortly after they occur.

A little over a month ago, I posted my hacky but effective AI setup for fixing production bugs to Reddit (https://redd.it/1jibmtc). 300+ devs messaged me or commented wanting to try it out, so I’ve been spending the past weeks refining it into Paladin, and excited to release it today!

How it works:

Paladin hooks into your application’s error handling with an SDK, triggering a “run” when an exception is thrown. During the run, Paladin pulls your code on Github and uses LLMs to fix the error, sending you the fix as a PR over Slack in ~90 seconds. Here’s a two minute demo: https://youtu.be/0bm8nq99Nrw.

In early testing, Paladin solves over 55% of real production errors on the first try and makes useful progress on many others. It’s able to do well by supplying deep context to the LLMs: the stack trace, execution state, repo code, and more. When it works well, it allows you to fix bugs more quickly, meaning less downtime for users and saved engineering time.

Eliminating context switching has been an unexpected win for me, because I work best in long, focused stretches. When a bug hits affecting real users, I have to drop everything mid-feature to stash changes, debug, and mentally shift contexts, and then try to return. I’ve found PR reviews and tweaks to be much less disruptive.

Getting started (Free, no card required) 1. Sign up at https://app.paladin.run/signup 2. Follow instructions to connect your Github and Slack (or just email) 3. Choose and install the correct SDK into your app 4. Configure to send errors to Paladin 5. Done!

Paladin supports React, React Native, Laravel, Flutter, Django, Node, Next, Vanilla Javascript, Express, FastAPI, PHP, Vanilla Python, Nest, Vue, Android, iOS, Rails, Flask, and many more thanks to Sentry’s MIT licensed client SDKs (your errors do not go to Sentry, they are just used to capture errors). If you have a client and server, I’d start with your server.

Notes on privacy, performance, and future plans below:

Paladin will never abuse repo access for any type of training or sharing, and only pulls it for making fixes. An LLM provider (Google/Anthropic/OpenAI) processes part of your code, so if you can’t use tools like Cursor/Windsurf, you probably can’t use Paladin.

On performance, my personal set is admittedly very limited, but I think the performance makes sense to me given current bests on benchmarks like Aider Polyglot and SWE-bench Verified. I’d expect these numbers to get much better as models progress. I’d also expect Paladin to fall short where current frontier LLMs do: uncommon frameworks, libraries or languages.

In the future, I am planning on having two usage options: - Free: if you bring your own OpenRouter API key - Paid: if Paladin pays for the model costs

Really looking forward to hearing feedback and ideas!