Tusk

Tusk

Tusk AI, Inc. · Coding · Produktivität

Tusk ist ein KI-Testagent, der bei jedem Pull Request Unit- und API-Tests schreibt und ausführt und gefundene Fehler meldet. Tusk AI, Inc. hat das Produkt am 10. Juni 2026 eingestellt.

Vorschau der Oberfläche von Tusk

Über Tusk

What Is Tusk

Tusk startete 2024 im Y-Combinator-Jahrgang W24 mit einem engen Versprechen. Man gab dem Agenten die Fehlerberichte der Kunden und bekam einen Pull Request zurück. In kleinen Entwicklungsteams geht für eine Korrektur von zehn Zeilen oft ein ganzer Nachmittag drauf, und genau diese Tickets sollte Tusk vom Tisch nehmen.

Bis 2026 war daraus ein KI-Testagent geworden. Er erzeugte Unit- und API-Tests für jeden Pull Request, führte sie selbst aus und wiederholte den Lauf, bis sie durchgingen. Tests sind der Teil eines Releases, für den niemand Zeit hat, und Tusk verkaufte sich als der Kollege, der das ohne Aufforderung erledigt.

Wer heute bewertet, was übrig geblieben ist, sollte die Grenzen kennen. Tusk brauchte ein GitHub-Repository, eine vorhandene Testsuite und die Geduld, den Agenten einen fehlschlagenden Test mehrfach wiederholen zu lassen. Die Zahlen zum Aufspüren von Randfällen stammten aus eigenen Benchmarks, nicht aus einer unabhängigen Prüfung.

Die entscheidende Grenze ist ein Datum. Tusk AI, Inc. teilte am 11. Juni 2026 mit, dass das Produkt einen Tag zuvor abgeschaltet wurde. Die GitHub App verschwand aus den Kundenorganisationen, Nutzer von Tusk Drift mussten das SDK entfernen und den CI-Workflow löschen, der Support lief danach noch einen Monat. Das Unternehmen verwies für Testautomatisierung und Codereview auf Devin von Cognition.

Getting Started

  1. Ein Tusk-Konto anlegen und die GitHub App in den Repositories installieren, die der Agent lesen und ändern durfte.
  2. Die CLI im Wurzelverzeichnis jedes Service installieren, wofür ein Befehl reichte, und die Ersteinrichtung starten, damit Tusk Ihre Testmuster indexierte.
  3. Wie gewohnt einen Pull Request öffnen. Tusk stellte die erzeugten Tests als Kommentar ein, führte sie in Ihrer CI aus und besserte nach, was scheiterte.
  4. Diese Tests wie jeden anderen Code prüfen. Laut Unternehmen landeten rund 69 Prozent der erzeugten Tests in gemergten Pull Requests.

Produktinformationen

Ein kurzer Überblick über Preise, unterstützte Plattformen und die Leistung von Tusk.

Kostenloser TarifJa
Bezahlte Tarife$0 - $50 per active dev/mo
PlattformWeb, CLI, GitHub App, CI/CD pipelines
EntwicklerTusk AI, Inc.
KategorieCoding · Produktivität
VeröffentlichungsdatumFeb 2024
Zuletzt aktualisiertJun 2026
Website-Besuche5.3K
Globales Website-Ranking3.6M
API-VerfügbarkeitJa

Am besten für

Die Nutzer, Aufgaben und Szenarien, für die dieses Tool am besten passt.

Nutzer

  • Kleine Entwicklungsteams ohne eigene QA-Stelle
  • Gründer, die weiterhin Code reviewen
  • Backend- und Plattform-Entwickler

Aufgaben

  • Die Testabdeckung vor einem Launch erhöhen
  • Regressionen in Pull Requests erkennen
  • Verträge externer APIs überwachen

Szenarien

  • Eine gewachsene Codebasis mit wenig Abdeckung und ohne Budget für einen Neuschrieb
  • Ein Team, das mehrmals täglich in drei oder vier Repositories deployt
  • Vergleich von Werkzeugen, die es nicht mehr gibt

Wichtigste Funktionen

Unit-Tests für jeden Pull Request

Tusk las den Diff, holte Kontext aus Ihren vorhandenen Tests und schlug Unit-Tests als Kommentar am Pull Request vor. Der Agent führte aus, was er schrieb, und wiederholte fehlschlagende Tests, sodass lauffähiger Code zurückkam und kein Vorschlag. Für Teams, die Tests als lästige Pflicht sahen, lag der ganze Wert darin, funktionierende Tests zu bekommen, ohne den Editor zu öffnen.

API-Tests aus echtem Traffic

Tusk Drift zeichnete echten Traffic auf Ihren Endpunkten auf und machte daraus API-Tests. Statt Mocks zu schreiben, bekam man Tests aus dem, was der Service tatsächlich empfing. Das half bei der Überwachung von API-Verträgen, wo eine still geänderte Antwort Aufrufer bricht, von denen man erst bei einer Beschwerde hört.

CoverBot füllt die Abdeckung nach Plan

CoverBot arbeitete wie Dependabot, nur enthielten seine Pull Requests Unit-Tests statt Versionssprüngen. Man richtete ihn auf ein Repository, wählte täglich oder wöchentlich und ließ ihn laufen. Tusk nannte 30 Prozent mehr Abdeckung in einem Monat, eine Hausnummer, die als Richtung taugt und nicht als Zusage.

Suiten, die sich selbst pflegen

Tests veralten, wenn sich Geschäftslogik verschiebt. Tusk aktualisierte scheiternde Suiten bei jedem Commit, damit sie zum aktuellen Verhalten passten. Das ist zugleich bequem und riskant, denn ein Test, der sich zum Bestehen umschreibt, kann sich auch über einen echten Fehler hinwegschreiben.

Kontext aus Jira, Linear und Ihren eigenen Tests

Tusk zog fachlichen Kontext aus Jira- und Linear-Tickets und Codemuster aus den Tests, die Ihr Team bereits geschrieben hatte. Erzeugte Tests folgten Ihren Namens- und Fixture-Konventionen, statt einen neuen Stil zu erfinden. Wer generische KI-Generatoren probiert hatte, nannte meist diesen Unterschied zuerst.

Codereview und Fehlerbehebung

Der ursprüngliche Agent verschwand nie ganz. Tusk reviewte weiter Pull Requests und konnte einen gemeldeten Fehler bis zum Fix verfolgen. Für den Review galt dieselbe Einschränkung wie für die Tests: alles Erzeugte braucht vor dem Merge einen menschlichen Blick.

Vor- und Nachteile

Vorteile

  • Die Tests kamen bereits ausgeführt an, was das übliche Hin und Her mit KI-Copiloten spart.
  • Der KI-Testgenerator hing in der CI, sodass die Abdeckung ohne eigenen Sprint wuchs.
  • Die Anbindungen an GitHub, Jira und Linear hielten den Kontext in den Werkzeugen, die das Team ohnehin nutzte.
  • Der Preis pro aktivem Entwickler ohne Mindestzahl an Lizenzen machte den Test in einem Repository günstig.

Nachteile

  • Das Produkt ist weg. Repositories verloren die GitHub App, und Drift-Nutzer mussten SDK-Code aus ihren Services entfernen.
  • Die Benchmarks kamen vom Anbieter, die Aussage zu Randfällen, die andere Agenten übersehen, wurde nie von außen geprüft.
  • Das beste Ergebnis setzte eine vorhandene Suite und eine Plattform voraus. Außerhalb von GitHub oder ganz ohne Tests fiel der Nutzen deutlich kleiner aus.
  • KI-Review braucht weiterhin einen Menschen, und ein bestandener Test beweist nicht, dass der Code stimmt.

Häufige Fragen

Tusk erzeugte Unit- und API-Tests für Pull Requests, reviewte Code und behob von Kunden gemeldete Fehler. Teams nutzten es, um die Testabdeckung zu erhöhen und Regressionen vor dem Deployment zu finden.