Diese Dev-Tool-Tipps von 2024 bremsen dich heute

Seit 2024 können Coding-Assistenten aus einer knappen Anweisung brauchbare Änderungen erzeugen. Für Juniors mit ein oder zwei Jahren Erfahrung ist deshalb ein alter Rat riskant geworden: Richte zuerst möglichst viele Produktivitätstools ein, dann wirst du schneller. Ich halte das Gegenteil für sinnvoll. Dein Werkzeugkasten sollte zuerst zeigen, ob eine Änderung korrekt, begrenzt und auslieferbar ist – gerade wenn du allein für einen Auftrag arbeitest.

Der schnellere Code-Entwurf hat die alte Tool-Empfehlung entwertet

„Such dir eine IDE, einen Task-Manager und ein paar Erweiterungen“ war als Einstieg plausibel, solange das Schreiben des ersten Entwurfs viel Zeit beanspruchte. Heute kann ein Assistent diese Phase verkürzen, ohne dir die Verantwortung für das Ergebnis abzunehmen: Er kennt weder die stillen Absprachen mit deinem Auftraggeber noch sämtliche Annahmen im bestehenden Code. GitHub stellte seinen Copilot Coding Agent 2025 als Werkzeug vor, das aus Issues Änderungen und Pull Requests vorbereitet. Damit verschiebt sich die nützliche Frage von „Wie tippe ich schneller?“ zu „Woran erkenne ich, dass dieser Pull Request die richtige Änderung enthält?“

Das betrifft nicht nur ausdrücklich beauftragte Agenten. GitHub Copilot in Visual Studio Code und Cursor können Änderungen über mehrere Dateien vorschlagen; dadurch wird es leichter, eine plausibel wirkende Anpassung zu übernehmen, deren Nebenwirkungen du noch nicht gesehen hast. Ein grüner TypeScript-Check beweist beispielsweise nur, dass die geprüften Typbeziehungen stimmen. Er beweist nicht, dass eine Rechnung richtig gerundet wird oder ein bestehender API-Client dieselbe Antwort wie zuvor erhält.

Ich würde deshalb nicht mit der Suche nach dem „einen perfekten KI-Editor“ anfangen: Ein Editorwechsel kostet Einarbeitung, während ein fehlender Test für eine Geschäftsregel auch im neuen Editor fehlt. Behalte zunächst die Umgebung, in der du Git-Diffs sicher lesen und Tests ausführen kannst. Die Grenze für KI-Vorschläge sollte eine nachvollziehbare Änderung sein, nicht die Länge des generierten Codes.

Für einen konkreten Auftrag heißt das: Schreibe vor dem Prompt einen beobachtbaren Satz auf, etwa „Ein bereits bezahlter Auftrag darf beim erneuten Webhook-Aufruf keine zweite Rechnung erzeugen.“ Lass dir anschließend nicht nur Implementierung, sondern auch einen Test für den zweiten Aufruf vorschlagen. Prüfe selbst, ob der Test vor der Änderung scheitert und danach besteht; sonst könnte er lediglich den neuen Code bestätigen, statt den ursprünglichen Fehler nachzuweisen. HTTP-Statuscodes und die Semantik des verwendeten Webhook-Protokolls gehören dabei zur Prüfung, weil ein wiederholter Request kein exotischer KI-Sonderfall ist.

Ein kleiner Pflichtpfad schlägt die nächste Sammlung von Erweiterungen

Dein lokaler Standardpfad sollte auf einem frisch ausgecheckten Repository ausführbar sein. Für ein Node.js-Projekt sind Node.js 22, npm ci, ein Testskript und ein lesbarer Git-Diff ein brauchbarer Ausgangspunkt: npm ci installiert anhand der Lockdatei und verändert sie nicht stillschweigend wie ein normaler Installationslauf. TypeScript 5.x, ESLint 9 mit Flat Config und Vitest können zusätzliche Fehler finden, ersetzen aber keinen Test der fachlichen Erwartung, weil sie unterschiedliche Fragen beantworten.

Der folgende GitHub-Actions-Workflow ist für ein Repository mit package-lock.json und einem funktionierenden npm test-Skript gedacht. Lege ihn als .github/workflows/verify.yml ab; die Berechtigung gilt nur für das Lesen des Repository-Inhalts.

name: Verify
on: [pull_request]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: npm
      - run: npm ci && npm test

Das ist absichtlich kein Qualitätszertifikat. Die Pipeline prüft zunächst nur, ob eine saubere Installation und die vorhandenen Tests auf einem fremden Rechner gelingen; gerade dieser Unterschied zu „läuft bei mir“ macht sie für einen kleinen Auftrag wertvoll. Für einen Dienst mit echter Datenhaltung würde ich zusätzlich einen Integrationstest mit einer Wegwerf-Datenbank einrichten, weil ein gemocktes Repository weder Migrationen noch Transaktionsfehler entdeckt. Für eine reine statische Seite kann derselbe Aufwand dagegen unverhältnismäßig sein, weil dort keine Datenbankgrenze existiert.

Als einstellbaren Startwert würde ich eine Prüfung anstreben, die in höchstens 10 Minuten Rückmeldung liefert; dauert sie länger, miss zuerst Installation und Testlauf getrennt, statt blind Tests zu streichen. Erfasse außerdem bei den nächsten 20 Pull Requests als eigene Messreihe, welcher Fehler erst nach dem Merge auffällt und ob ein vorhandener Test ihn hätte erkennen können. Das ist aussagekräftiger als die Zahl installierter Erweiterungen, weil du damit eine konkrete Lücke in deinem Pflichtpfad findest.

Eine weitere alte Empfehlung lautet, für jede Qualitätsfrage sofort ein weiteres SaaS-Dashboard hinzuzufügen. Ich würde stattdessen zunächst GitHub Actions, Dependabot und die bereits vorhandenen Testreports ausschöpfen: Ihre Hinweise liegen nahe am Pull Request, wo du ohnehin die Änderung beurteilst. Ein neues Dashboard lohnt sich erst, wenn es eine Entscheidung ermöglicht, die du aus Diff, CI-Ausgabe und Fehlerprotokoll tatsächlich nicht treffen kannst.

Bei KI-Editoren kostet Kontextwechsel oft mehr als die Lizenz

Visual Studio Code mit GitHub Copilot gegen Cursor: VS Code mit Copilot gewinnt für dich, wenn dein Projekt bereits auf VS-Code-Einstellungen, Extensions und GitHub-Pull-Requests beruht, weil du ohne Editorumzug weiterarbeiten kannst. Sein Preis besteht aus der Copilot-Lizenz, gegebenenfalls kostenpflichtiger Nutzung und der Zeit, die du für das Prüfen seiner Vorschläge brauchst. Cursor gewinnt, wenn du häufig zusammenhängende Änderungen über viele Dateien entwirfst und seine Arbeitsweise dir dabei nach einer Probephase tatsächlich weniger Handarbeit abverlangt. Sein Preis besteht ebenfalls aus einem Abo beziehungsweise nutzungsabhängigen Grenzen, zusätzlich aber aus Umstellung und möglicher Abweichung von der Umgebung deiner Auftraggeber. Prüfe die aktuellen Tarifseiten vor einer Entscheidung, weil Preise und enthaltene Kontingente geändert werden können.

Vergleiche die beiden nicht anhand einer Demo, in der ein neues Projekt entsteht. Nimm eine echte, überschaubare Änderung mit bestehenden Tests: etwa die Anpassung eines Validierungsfehlers, dessen Text sowohl in einer API-Antwort als auch in einem Playwright-Test auftaucht. Stoppe die Zeit vom ersten Lesen des Issues bis zum grünen Pull Request, einschließlich Prompt-Korrekturen, Testreparaturen und Review. Als Rechenbeispiel, nicht als erhobener Marktpreis, würden 25 Euro monatliche Mehrkosten erst dann wirtschaftlich, wenn die eingesparte und tatsächlich nutzbare Arbeitszeit für dich mehr wert ist. Bei einem angenommenen internen Wert von 50 Euro pro Stunde wären das 30 Minuten im Monat; die Rechnung berücksichtigt noch keine Datenschutz- oder Vertragsvorgaben.

Der Titel 5 Tool-Fehler die Solo-Freelancer richtig Geld kosten lenkt den Blick zu Recht auf Ausgaben; ich würde einen KI-Editor inzwischen jedoch erst nach einem Vergleich vollständiger Änderungen bewerten, weil die Lizenz allein nichts über Nacharbeit verrät. Der Beitrag Projektpraxis: Tools fuer effiziente Softwareentwicklung behandelt Werkzeuge im Projektkontext; für deinen nächsten Auftrag würde ich die Auswahl noch enger an die überprüfbare Änderung binden, weil du als Junior die zusätzliche Komplexität selbst tragen musst.

Ein Tool kann in der Probe schneller wirken und trotzdem die schlechtere Wahl sein. Wenn du nach einem umfangreichen Vorschlag eine unbekannte Bibliothek, eine geänderte Lockdatei und drei neue Abstraktionen erklären musst, gehört diese Review-Zeit zur Messung. Halte deshalb auch fest, wie oft du einen Vorschlag vollständig zurücksetzt. Ein abgebrochener Versuch ist keine verlorene Erkenntnis: Er zeigt dir, welche Aufgabenbeschreibung oder Projektgrenze dem Assistenten gefehlt hat.

Der Diff ist erst fertig, wenn Herkunft und Zugriff geklärt sind

In den vergangenen zwei Jahren hat sich die Versuchung verstärkt, einem Assistenten für eine bessere Antwort möglichst viel Repository-Kontext zu geben. Mehr Kontext kann einen Vorschlag passender machen, erhöht aber bei privaten Projekten die Menge an Code, Konfiguration und möglicherweise Kundendaten, die ein Dienst verarbeitet. Prüfe daher vor dem Hochladen die Vereinbarung mit dem Auftraggeber und die Einstellungen des konkreten Produkts; eine pauschale Aussage wie „KI darf unseren Code sehen“ ist zu grob, weil Anbieter und Betriebsarten unterschiedliche Bedingungen haben.

Beginne mit einem kleinen Ausschnitt: betroffene Funktion, zugehöriger Test, relevante Fehlermeldung. Entferne Tokens und personenbezogene Testdaten, bevor du sie in einen Chat kopierst. Nutze für Secrets Umgebungsvariablen oder den Secret-Store deiner CI statt einer Datei im Repository; ein späteres Löschen aus dem letzten Commit entfernt ein zuvor eingechecktes Secret nicht aus der Git-Historie. Für Dependencies hilft npm audit --audit-level=high als Hinweis auf bekannte Meldungen, nicht als Freigabestempel, weil der Befehl weder deine konkrete Erreichbarkeit einer Schwachstelle noch ungemeldete Fehler beurteilt. Dependabot-Pull-Requests solltest du aus demselben Grund mit Tests und einem Blick auf Changelog und Lockdatei prüfen.

Auch ein automatisch bestandener Test sagt wenig über die Herkunft eines unerwarteten Paketwechsels. Vergleiche bei jedem KI-generierten Pull Request die geänderten Abhängigkeiten mit dem eigentlichen Auftrag. OpenSSF Scorecard kann Hinweise zur Praxis eines Open-Source-Projekts liefern, und SLSA v1.0 beschreibt Anforderungen an die Herkunft von Builds; beide nehmen dir die Entscheidung über eine konkrete Dependency nicht ab, weil ihre Signale andere Fragen als „Brauchen wir dieses Paket hier?“ beantworten.

Setze für den eigenen Review eine anpassbare Warnschwelle von 200 geänderten Zeilen pro fachlicher Änderung, nicht als starre Ablehnungsregel. Überschreitet ein Diff sie wegen generierter Dateien oder einer begründeten Migration, markiere das ausdrücklich und prüfe diese Teile getrennt. Überschreitet er sie wegen beiläufiger Umbenennungen, teile ihn auf: Ein kleiner Diff ist nicht automatisch korrekt, aber du kannst seine Absicht leichter gegen Issue, Tests und Rechnung des Auftraggebers halten.

Dein nächster Auftrag braucht zuerst eine prüfbare Änderung

Nimm beim nächsten Ticket vor dem ersten KI-Prompt eine bestehende Fehlermeldung oder Geschäftsregel und formuliere einen Test, der den gewünschten Zustand sichtbar macht. Führe ihn auf deinem Rechner aus, richte dann den kleinen CI-Pfad ein und öffne erst danach den Assistenten. Wenn der fertige Diff eine neue Dependency oder ungefragte Umstrukturierung enthält, frage nach deren Zweck – oder entferne sie vor dem Pull Request.