Coroid-Agents schreiben Code genau so, wie ein Ingenieur mit der Shell das tun würde. Es gibt keine zu wartende sprachspezifische Integration: Wenn ein kompetenter Entwickler Ihr Repository öffnen, lesen, ändern und die entsprechenden Befehle ausführen kann, kann das auch der Agent.
Was sich je nach Sprache unterscheidet, ist nicht, ob Coroid darin arbeiten kann. Es geht vielmehr darum, wie viel Coroid eigenständig nachweisen über die vorgenommene Änderung – den Code semantisch navigieren, ihn erstellen, den Test-Suite ausführen und ihn in einem Container starten. Das ist der eigentliche Kern der Sprachenunterstützung, und es lohnt sich, dies zu verstehen, bevor Sie ein Ergebnis beurteilen.
Das Agenten-Ausführungsumfeld
Jede Aufgabe läuft in einem sauberen, temporären Linux-Arbeitsbereich, der auf einem Debian-Image basiert, als unprivilegierter Benutzer. Zwischen den Aufgaben bleibt nichts erhalten: Jede Aufgabe beginnt mit einem frischen Klon ohne Cache und ohne vorinstallierte Tools außer dem Image.
Das Image enthält ein allgemeines Toolchain, sodass die meisten Projekte keinerlei Einrichtung benötigen:
| Bereich | Verfügbar |
|---|---|
| JavaScript / TypeScript | Node.js 22, npm, npx |
| Python | Python 3, pip, venv, Poetry, Pipenv |
| Java | JDK (headless), Maven, Gradle |
| Go | Go-Toolchain |
| PHP | PHP CLI, Composer |
| Ruby | Ruby, Bundler |
| C / C++ | GCC, G++, Make, CMake |
| Browser | Chromium, für Browser-Tests sowie die Vorschau-Verifizierung |
| Allgemein | git, curl, jq, ripgrep, grep, sed, awk, Coreutils, PostgreSQL-Client |
Alles, was nicht in dieser Liste steht – eine weniger gebräuchliche Laufzeitumgebung, eine spezifische Compiler-Version oder eine native Abhängigkeit – ist kein Hindernis. Es ist ein Grund, Ihren eigenen Container zu verwenden.
Was sich je nach Sprache unterscheidet
Drei Aspekte, sortiert nach ihrer Auswirkung auf die Qualität.
Sprachserver
Ein Sprachserver verleiht dem Agenten ein semantisches Verständnis: Gehe zur Definition, suche Referenzen, echte Typen. Mit einem solchen Server kann der Agent präzise Fragen zu Ihrem Code stellen, anstatt Antworten aus dem Text abzuleiten. Ohne einen solchen Server liest der Agent den Code – was bei kleinen und mittelgroßen Codebasen gut funktioniert, bei größeren und indirekteren Codebasen jedoch weniger zuverlässig ist.
Coroid nutzt Sprachserver für TypeScript und JavaScript, Python, Java sowie C#.
Andere Sprachen greifen auf das Lesen zurück. Das ist der größte Qualitätsunterschied zwischen den Sprachen – ein Unterschied im Grad, nicht in der Art.
Befehle zum Erstellen und Testen
Der Agent muss Ihr Projekt kompilieren und die Test-Suite ausführen, um seine eigene Arbeit zu verifizieren. Coroid erkennt diese Befehle beim Anlegen eines Projekts – wobei die Erkennung bei konventionellen Strukturen besser funktioniert als bei ungewöhnlichen.
Das ist Konfiguration, keine Funktionalität – siehe Konfiguration für Erstellen und Testen. Ein korrektes Befehlspaar in einer weniger gebräuchlichen Sprache ist besser als ein falsches Paar in einer populären Sprache.
Container
Wenn Ihr Projekt in einem Container ausgeführt werden kann, nutzt Coroid diesen als Ausführungsumfeld – wodurch Umgebungsabweichungen und Service-Abhängigkeiten auf einen Schlag entfallen.
Wenn Ihre Sprache keinen Sprachserver hat
Die praktischen Workarounds, sortiert nach ihrem Nutzen:
- Befehle zum Erstellen und Testen explizit konfigurieren anstatt sich auf die automatische Erkennung zu verlassen. Das ist wichtiger als der Sprachserver selbst.
- Containerisieren. Ein funktionierender Container schließt die meisten Lücken auf Ebene der Umgebung.
- In Projektkontext. Ein guter Kontext kompensiert teilweise das, was ein Sprachserver geliefert hätte, indem er dem Agenten über die Struktur informiert, die er sonst selbst hätte ermitteln müssen.
Ihren eigenen Container verwenden
Wenn Ihr Projekt in einer bereits funktionierenden Dockerfile oder Compose-Datei erstellt und getestet wird, ist das die zuverlässigste verfügbare Konfiguration für Sie – besser als eine gut unterstützte Sprache auf dem Standard-Image, weil der Container Ihre Toolchain, Versionen und Service-Abhängigkeiten exakt codiert.
Der Test ist einfach: Klonen Sie Ihr Repository in ein leeres Verzeichnis und führen Sie install, build und test ohne weitere Einrichtung aus. Wenn das funktioniert, wird auch Coroid funktionieren.
Private Registries und Netzwerkzugriff
Arbeitsbereiche können das Netzwerk erreichen, weshalb öffentliche Paketregistries ohne Konfiguration funktionieren. Für private Feeds – etwa eine private npm-Registry, ein internes Maven-Repository oder eine selbstgehostete PyPI – müssen Anmeldeinformationen als Projektkonfiguration hinterlegt werden, da der saubere Arbeitsbereich keine umgebungsspezifischen Anmeldeinformationen erbt.
Projekte mit gemischten Programmiersprachen
Die meisten realen Projekte nutzen mehr als eine Programmiersprache. Ein TypeScript-Frontend mit einem Python-Dienst ist dabei üblich, und Coroid bewältigt dies problemlos. Die Tiefe der Bearbeitung richtet sich nach der jeweiligen Programmiersprache der Änderung – eine Änderung im gut unterstützten Bereich wird vollständig verarbeitet, unabhängig davon, in welcher Sprache der andere Teil des Projekts geschrieben ist.