Uruchom swoje CI lokalnie. Napraw awarie z pomocą AI. Stitch czyta Twoją istniejącą konfigurację CI, uruchamia zadania na Twojej maszynie w kilka sekund i przekazuje awarie agentowi AI, który je naprawia. Bez kluczy API, bez plików konfiguracyjnych.
Stitch runs your CI config — but on your machine, before you push. When it finds a failure, it hands the context to Claude and applies the patch. No broken PR opened.
Od konfiguracji do zielonego CI, Stitch uruchamia całą pętlę na twojej maszynie bez opuszczania terminala.
Uruchom stitch run claude. Stitch parsuje twój .gitlab-ci.yml lub workflow GitHub Actions, klasyfikuje joby i automatycznie pomija joby infrastrukturalne.
Joby działają lokalnie z timeoutami i izolacją. Wyniki pojawiają się w TUI na żywo ze śledzeniem postępu. Sekundy, nie minuty.
Nieudane joby trafiają do twojego agenta AI (Claude Code lub Codex). Agent bada, edytuje pliki, a Stitch uruchamia ponownie, aby zweryfikować. Do 3 prób przed eskalacją do ciebie.
No intermediate server. Stitch runs in your shell, reads your file tree, and writes patches on top. Shut it down and nothing lingers.
Uses the Claude Code credentials you already have. We do not ask for tokens, we do not store anything.
Every patch lands in an isolated commit. git reset takes you back exactly where you were.
Whatever you would see in your cloud CI, you see in your terminal. Same jobs, same containers, same result — without the wait cycle.
Stitch wychwytuje to, co umknęło podczas przeglądu kodu — błędy lintowania, niezgodności typów, zepsute testy — i naprawia je, zanim w ogóle to zauważysz.
Korzysta z Twojego istniejącego .gitlab-ci.yml lub GitHub Actions. Bez konfiguracji, bez przepisywania, bez dodatkowego YAML-a.
Uruchamia zadania na Twojej maszynie w kilka sekund. Bez czekania na zdalne runnery ani kolejki potoków.
Podłącz Claude Code lub OpenAI Codex. Korzysta z Twojej subskrypcji. Żadnych kluczy API do pilnowania.
Przejrzysty interfejs terminalowy z postępem na żywo, statusem zadań i aktywnością driverów w trakcie pracy Stitcha.
Ciągła walidacja w trakcie pisania kodu. Zadania są uruchamiane ponownie automatycznie po zmianie plików.
Automatycznie klasyfikuje i pomija zadania deploy, publish i infra. Lokalnie uruchamia tylko to, co istotne.
Gdy poprawki przechodzą, Stitch sam commituje i wypycha zmiany. Ty zostajesz w przepływie.
GitLab CI i GitHub Actions, również self-hosted. Czyta Twoją istniejącą konfigurację bez zmian.
Wszystko inne na tej stronie to to, co Stitch robi. Nagrania poniżej pokazują, jak Stitch wygląda w akcji. Uchwycone z prawdziwego terminala, bez edycji.
Jedna komenda. Stitch parsuje twoją konfigurację CI, uruchamia joby weryfikacyjne lokalnie, przekazuje błędy do Claude Code lub Codex i weryfikuje poprawkę. Wszystko leci w jednym oknie terminala.
Stitch zapisuje każdy bieg na repo. Widzisz od razu, które joby przechodzą same, które potrzebowały agenta, a które zostały eskalowane. Bez dashboardu, bez konta. Po prostu plik na twojej maszynie.
Stitch dostarczany jest z umiejętnością Claude Code. Zainstaluj raz, a Claude uruchamia Stitch automatycznie w czterech momentach, w których popsuty kod zwykle się prześlizguje. Bez flag, komend i promptów.
Wpisujesz "commit and push" w Claude Code.
Uruchamia Stitch lokalnie w kilka sekund, TUI leci na żywo.
Zielono, push leci. Czerwono, Claude najpierw naprawia, potem pushuje.
Poproś Claude o push, commit lub otwarcie PR. Stitch odpala się pierwszy. Jeśli coś padnie, commit zostaje na twojej maszynie.
Feature gotowy, bug naprawiony, refactor wdrożony. Claude uruchamia Stitch jako ostatni krok przed ogłoszeniem, że praca skończona.
Jeśli element TodoWrite dotyka kodu, który pipeline by sprawdził, Claude uruchamia Stitch przed odhaczeniem pozycji.
Gdy przełączasz się na inną zmianę, Claude sprawdza poprzednią, żeby nie zostawić niczego popsutego.
Jeden symlink. Claude Code wykryje ją sam i odpala się na wzmianki w języku naturalnym jak "zwaliduj to" lub "napraw pipeline". Wciąż możesz ją wywołać wprost przez /stitch.
$ ln -s "$(pwd)/skills/stitch" ~/.claude/skills/stitch
$ ln -s "$(npm root -g)/stitch-agent/skills/stitch" ~/.claude/skills/stitch
Większość asystentów CI chce, żebyś przyjął ich chmurę, ich monorepo albo ich SDK. Stitch czyta to, co już masz, i działa na maszynie, którą już masz.
| Możliwość | Stitch | Gitar | Nx Cloud | Dagger + AI |
|---|---|---|---|---|
| Używa twojej istniejącej konfiguracji CI | ✓ | ✕ | ✕ | ✕ |
| Uruchamia joby lokalnie | ✓ | Tylko chmura | Tylko chmura | Kontenery |
| Wymienialny agent AI | Dowolny agent CLI | Tylko wbudowany | Tylko wbudowany | Tylko wbudowany |
| Wymaga nowej infrastruktury | Żadna | Konto SaaS | Monorepo Nx | Dagger SDK |
| Natywna integracja z Claude Code | Dostarczany z umiejętnością | ✕ | ✕ | ✕ |
| Cena | Za darmo | Od $20/użytkownika/mies. | Plan Nx Cloud | Za darmo (OSS) |
Stitch czyta konfigurację CI, którą już masz, i uruchamia te same zadania lokalnie. Żadnych zmian w potoku, żadnych dodatkowych usług, żadnego nowego YAML-a do utrzymywania.
# Run every CI job locally $ stitch run claude # Only the jobs you care about $ stitch run claude --jobs lint,test # See what would run, without running it $ stitch run claude --dry-run # Re-run automatically on every file change $ stitch run claude --watch --jobs lint,test
# Your existing CI config. Stitch reads it, # no jobs to add, no changes to make. lint: image: node:20 script: - bun install - bun run lint test: image: node:20 script: - bun install - bun test typecheck: image: node:20 script: - bun install - bun run typecheck
Stitch działa wewnątrz twojego repo z twardymi limitami czasu, zakresu i tego co może opuścić twoją maszynę. Nic nie dzieje się za twoimi plecami.
Każdy job działa z konfigurowalnym timeoutem. Rozpędzone komendy są zabijane przez SIGKILL, nigdy nie zostawiane.
Joby deploy, publish i release są klasyfikowane jako infra i automatycznie pomijane. Tylko joby weryfikacyjne działają lokalnie.
Auto-commit i push odpalają się tylko jeśli branch był czysty przed startem Stitch. Twoja niescommitowana praca jest nietykalna.
Nieudane joby próbują ponownie do max_attempts (domyślnie 3). Potem Stitch eskaluje do ciebie zamiast palić tokeny.
Joby, logi i poprawki działają na twojej maszynie. Bez chmury, bez telemetrii, bez webhooków chyba że je skonfigurujesz.
languages: [typescript, python] linter: eslint test_runner: vitest package_manager: pnpm max_attempts: 3 conventions: - "Always use explicit return types on public functions." - "Never downgrade dependency versions." auto_fix: [lint, format, simple_types, config_ci] escalate: [logic_errors, breaking_changes, dependency_conflicts] notify: channels: - type: slack webhook_url: https://hooks.slack.com/...
Stitch reads your existing CI config (GitHub Actions or GitLab CI), runs the verify jobs locally on your machine, and hands any failure to your AI agent (Claude Code or Codex) to fix. When the fix passes locally, Stitch commits and pushes. No remote runner needed for the verify loop.
Nx Cloud, Gitar, and Dagger ask you to adopt their cloud, monorepo, or SDK. Stitch reads the CI config you already have and runs on the machine you already own. There is no SaaS account, no DSL, and the AI agent is whatever CLI you already use.
No. Stitch uses the Claude Code or Codex credentials you already have on your machine. There is nothing extra to manage and nothing extra to bill.
GitHub Actions and GitLab CI today, including self-hosted GitLab. Stitch parses the existing config and only runs verify-class jobs locally; deploy and publish jobs are skipped automatically.
Yes. Stitch is open source under the MIT license, distributed on npm as stitch-agent. The only cost is whatever you already pay for your AI agent (Claude Code or Codex).
No. Stitch runs locally. Your code stays on your machine. Your AI agent talks to its own API directly using your existing credentials, exactly the way it does when you run it manually. Stitch has no telemetry and no webhooks unless you configure them.
Yes. The agent layer is pluggable. Codex CLI works today; any CLI agent that takes a task description and returns code patches can be wired in. Claude Code is the default because we built the integration first, not because it is locked in.