DEV Community

Pablo
Pablo

Posted on • Originally published at shipd.dev

I Built an AI That Opens Pull Requests to Fix Your Production Bugs

#ai #devops #javascript #productivity

You're at dinner. Your phone buzzes. Production error. Again.

You could finish your meal like a normal human, or you could spend the next hour debugging a null pointer exception because some API changed their response format.

What if there was a third option?

The Problem with Error Monitoring

Every error monitoring tool works the same way:

  1. Error happens
  2. You get alerted
  3. You stop what you're doing
  4. You debug for 30 minutes (or 3 hours)
  5. You deploy a fix
  6. Repeat

The alert is the easy part. The fix is the hard part. And yet, every tool stops at step 2.

What if the Tool Just... Fixed It?

That's what I built with Shipd.

Here's what happens when your app crashes:

  1. SDK catches the error with full context (stack trace, request, environment)
  2. AI clones your repo and reads the source code
  3. AI identifies the root cause
  4. AI writes a minimal, targeted fix
  5. AI opens a pull request on GitHub
  6. You review and merge

From error to pull request in ~30 seconds. No debugging. No context switching. Just code review.

How It Actually Works

1. The SDK 

// That's it. One line.
import { Shipd } from '@shipd/sdk';
Shipd.init({ apiKey: process.env.SHIPD_API_KEY });
Enter fullscreen mode Exit fullscreen mode

The SDK captures uncaught exceptions with:

  • Full stack trace
  • Request/response data
  • Environment variables (filtered)
  • Framework context (Next.js, Express, etc.)

2. The AI Pipeline

When an error comes in, the AI:

  1. Clones your repo (via GitHub App permissions)
  2. Reads relevant files based on the stack trace
  3. Understands the architecture (framework, patterns, style)
  4. Identifies root cause (not just the symptom)
  5. Writes a fix that's minimal and safe
  6. Opens a PR with explanation

The fix isn't a hack. It's what you would have written — just faster.

3. The Pull Request

Every PR includes:

  • Clear description of the bug
  • Explanation of the fix
  • The minimal code change
  • Link to the original error

You review it like any other PR. Approve, request changes, or close.

Real Example

Here's an actual fix Shipd generated:

Error:

TypeError: Cannot read property 'email' of undefined
    at getUserEmail (/app/lib/auth.js:42:25)
Enter fullscreen mode Exit fullscreen mode

Fix PR:

// lib/auth.js
export function getUserEmail(user) {
-  return user.email;
+  return user?.email ?? null;
}
Enter fullscreen mode Exit fullscreen mode

PR Description:

The getUserEmail function assumes user is always defined, but it can be undefined when called before authentication completes. Added optional chaining and nullish coalescing to handle this edge case.

That's it. A one-line fix that would have taken 20 minutes to debug, understand, and test.

Why Pull Requests?

I could have made Shipd auto-deploy fixes. Some people asked for that.

But here's the thing: you should always review code before it hits production.

Pull requests are the right abstraction because:

  • You maintain full control
  • You can reject bad fixes
  • You learn from the AI's solutions
  • Your git history stays clean
  • Your team can review too

Shipd is a junior developer who never sleeps and never complains about debugging. You're still the senior who approves the code.

Try It Free

Shipd has a free tier: 5 fixes per month, 1 repo. No credit card.

Install takes 5 minutes. Merge one PR and you're live.

Stop debugging at dinner. Let the AI handle it.

Building Shipd in public. Follow the journey on Twitter or join our Discord.

Top comments (0)