Empfehlungen für agentisches Coding

 (lucumr.pocoo.org)
18 Punkte von GN⁺ 2025-06-14 | 2 Kommentare | Auf WhatsApp teilen
  • Weitergabe praktischer Anwendungsfälle für agentisches Coding
  • Verwendet hauptsächlich das Claude-Code-Sonnet-Modell und bevorzugt es, ganze Aufgaben an die KI zu delegieren, statt sie in die IDE zu integrieren
  • Go wird besonders für neue Backend-Projekte empfohlen, dank seiner agentenfreundlichen Struktur und der Stabilität des Ökosystems
  • Geschwindigkeit und Einfachheit sind der Kern des agentischen Codings; Test-Cache und ein einfaches Tooling sind wichtig
  • Code sollte einfach und parallelisierbar aufgebaut sein; um die Leistung von Agenten zu maximieren, ist die Wahl des richtigen Zeitpunkts für Refactoring entscheidend

Preface

  • In letzter Zeit ist die Zahl der Entwickler stark gestiegen, die ihre Erfahrungen mit agentischem Coding teilen
  • Ich nutze derzeit das Claude-Code-Sonnet-Modell im Max-Tarif ($100/Monat)
  • Die Bedeutung der IDE hat abgenommen; stattdessen nutze ich wieder Vim und arbeite in einem Ablauf, bei dem ich Claude Aufgaben übergebe und nur die Ergebnisse prüfe
  • Da das Innovationstempo sehr hoch ist und die Inhalte dieses Beitrags schnell veralten können, liegt der Fokus auf Konzepten mit längerer Haltbarkeit

The Basics

  • Der Befehl claude --dangerously-skip-permissions wird als Alias claude-yolo gesetzt, um alle Berechtigungsbeschränkungen zu entfernen
    • Das lässt sich sicher verwalten, indem die Dev-Umgebung per Docker isoliert wird
  • Da Claude die meisten grundlegenden Tools gut beherrscht, wird MCP (Multi Capability Protocol) nur in speziellen Fällen verwendet
    • Beispiel: Browser-Automatisierung über playwright-mcp
  • Selbst gebaute Tools bestehen aus gewöhnlichen Skripten; dabei wird die Tool-Landschaft möglichst einfach gehalten

Choice Of Language

  • Nach Experimenten mit agentischem Coding in verschiedenen Sprachen ist Go für neue Backend-Projekte am idealsten
    • Context-System: Bietet eine klar durch den gesamten Code fließende Datenstruktur und macht explizite Übergaben für Agenten einfach
    • Test-Cache: Im Vergleich zu anderen Sprachen wie Rust sind Testausführung und Caching einfacher, wodurch der Code-Test-Loop des Agenten effizienter wird
    • Einfachheit: Die Einfachheit von Go selbst wirkt sich auch für Agenten vorteilhaft aus
    • Strukturelle Interfaces: Wenn die Methoden eines Typs passen, wird er als Interface erkannt, was ein LLM leicht verarbeiten kann
    • Geringe Änderungsrate im Ökosystem: Langlebige Versionen und explizite Änderungen helfen, die automatische Erzeugung veralteten Codes zu reduzieren
  • Python verursacht viele Probleme
    • Fixtures, Async-Verarbeitung und langsame Ausführung verringern die Effizienz im agentischen Loop
  • Im Frontend: Tailwind + React + Tanstack Query/Router + Vite
    • Das $-Zeichen in Dateinamen von Tanstack Router verwirrt Agenten und verursacht Probleme

Tools, Tools, Tools

  • Maßstäbe für Tools sind folgende
    • schnell sein
    • hilfreiche Fehlermeldungen liefern
    • auch dann stabil funktionieren, wenn ein LLM sie falsch benutzt
    • beobachtbar und leicht zu debuggen sein
  • Befehle wie make dev, make tail-log usw. werden auf Makefile-Basis bereitgestellt
    • Zur Vermeidung doppelter Laufzustände wird eine geforkte Version von shoreman zur PID-Verwaltung genutzt
    • Logs werden sowohl auf stdout als auch in Dateien geschrieben, damit Agenten Informationen direkt aus den Logs extrahieren können
  • Beispiel: Auch E-Mail-Bestätigungslinks werden in Logs geschrieben, sodass der E-Mail-Bestätigungsprozess per Browser-Automatisierung durchführbar ist

It's All About Speed

  • Die größte Ineffizienz beim agentischen Coding sind Inferenzkosten und ineffiziente Tool-Nutzung
  • Schnelle Antwortzeiten von Tools sind der Schlüssel zur Produktivität
  • Wenn Agenten selbst temporäre Werkzeuge erstellen und verwenden, verbessern schnelle Ausführungs- und Kompilierzeiten die Arbeitseffizienz erheblich
  • In langsamen Umgebungen sind Alternativen wie dynamisches Laden von Modulen vorteilhaft, etwa Dateiüberwachung und automatische Ausführung für Sentry
  • Logs sollten kompakt und klar gehalten werden, um Token-Verbrauch und Geschwindigkeit zu optimieren; hilfreich ist bei Bedarf eine Schnittstelle, über die das LLM den Log-Level anpassen kann
  • Wichtig ist, schon bei der Code-Erzeugung so zu entwerfen, dass aussagekräftige Logs und Observability entstehen

Stability and Copy/Paste

  • Die Stabilität des Ökosystems ist für Wiederverwendbarkeit von Code und zur Vermeidung von Verwirrung bei Agenten sehr wichtig
    • Empfohlen werden Sprachen und Frameworks mit geringer Veränderung und guter Vorhersehbarkeit wie Go und Flask
  • Vorsicht bei automatischen Bibliotheks-Upgrades; Kommentare oder Code-Flüsse, die Agenten hinterlassen haben, können dadurch beschädigt werden
  • Wenn möglich, wird eine Strategie aus selbst geschriebenem Code und minimalen Abhängigkeiten empfohlen

Write Simple Code

  • Agenten kommen mit einfachem und explizitem Code besser zurecht
  • Empfohlene Richtlinien
    • Bevorzugt werden Funktionen mit beschreibenden, langen Funktionsnamen; eher Funktionen als Klassen
    • Vererbung und komplexe Tricks vermeiden
    • Reines SQL wird empfohlen; Agenten sind in SQL stark, und Logs lassen sich leichter vergleichen und nachverfolgen
    • Klare Berechtigungsprüfungen sollten im Code intuitiv sichtbar sein, nicht in separate Dateien oder Konfigurationen ausgelagert

Make It Parallelizable

  • Die Verarbeitungsgeschwindigkeit einzelner Agenten ist nicht hoch, aber durch Parallelisierung lässt sich die Gesamteffizienz steigern
    • Beispiel: Kopien von Checkouts auf Basis des Dateisystems
    • Es muss über Methoden zur Trennung gemeinsam genutzter Ressourcen wie Redis oder DB nachgedacht werden
    • Beispiel-Tool: Docker-basierte Sitzungstrennung mit container-use
  • CI-basierte Parallelisierung und Werkzeuge wie der Background Agent von Cursor sind ebenfalls beachtenswert

Learn To Refactor

  • Beim agentischen Ansatz ist Refactoring zum richtigen Zeitpunkt wichtig
    • Wenn die Komplexität steigt, können Agenten den Code nicht mehr sauber handhaben
    • Beispiel: Bevor Tailwind-Klassen über 50 Dateien verstreut sind, sollten sie in eine Komponentenbibliothek überführt werden
  • Sowohl zu frühes als auch zu spätes Refactoring ist ineffizient; daher sollte die strukturelle Verbesserung zum passenden Zeitpunkt angestoßen werden

What Next?

  • Agentisches Coding entwickelt sich schnell weiter; die Kernprinzipien sind „Einfachheit, Stabilität, Sichtbarkeit und Parallelität“
    • Auch wenn sich Tools und Methodiken ändern, bleiben diese Prinzipien gültig
  • Ziel ist nicht nur höhere Produktivität, sondern auch bessere Code-Qualität
  • Die Qualität des von Agenten geschriebenen Codes hat sich im Vergleich zu vor einigen Monaten deutlich verbessert
  • Flexibel auf Veränderungen reagieren und die Coding-Erfahrung erweitern

Verwandte Beiträge

2 Kommentare

 
helloppfm 2025-06-16

Ich frage bisher mit KI auch nur nach einfachem Testcode oder ein paar Beispielen, aber inzwischen gibt es immer mehr Leute, die sie insgesamt einsetzen wollen.

Vielleicht ist es noch etwas verfrüht, aber in ein paar Jahren wird das wohl selbstverständlich sein.
 
GN⁺ 2025-06-14
Hacker-News-Kommentare

  • Ich nutze in VS Code Nightlys sowohl Copilot als auch Claude Sonnet 4 und erlebe damit Agentic Coding. Selbst wenn die Hälfte meines Tages aus Meetings besteht, würde man das meinem git-Verlauf nicht ansehen – so stark ist der Produktivitätsgewinn. Inzwischen denke ich weniger über Details der Implementierung nach, sondern eher darüber, ob die Änderungen korrekt funktionieren, ob ich diesen Code verstehen kann, wie man die Struktur verbessern sollte, um ihn besser verständlich zu machen, und was ich zusätzlich in die AI-Konventions-Markdown-Datei schreiben kann, um Missverständnisse des Agenten zu reduzieren. Gestern Abend habe ich dem Agenten eine Datei mit 38 mypy-Fehlern überlassen, bin 15 Minuten mit meiner Familie sprechen gegangen, und als ich zurückkam, hatte der Agent die Änderungen und die Gründe dafür zusammengefasst. Über eine der Änderungen habe ich noch diskutiert, am Ende aber entschieden, dass der Agent recht hatte. Der mypy-Check lief ebenfalls erfolgreich durch. Ich versuche inzwischen auch meinem Team das wirkliche Potenzial dieser Technik zu vermitteln, aber es gibt weiterhin skeptische Stimmen und Leute, die dagegenhalten, weil AI nicht perfekt ist. Aber um einen Freund zu zitieren: „Heute ist der schlechteste Tag, den du und diese Technik jemals haben werdet“ – und genau das ist für mich der Beweis, dass hier echte Innovation stattfindet

    • Type-Checker-Fehler sind eigentlich der Teil des Entwicklungsalltags, für den man am wenigsten Zeit aufwenden sollte. Deshalb frage ich mich, warum das bei dir so viel Zeit gefressen hat. Ich glaube, alle Diskussionen über AI-Nutzung wären viel wirksamer, wenn wir gemeinsam sehen könnten, wofür jede Person sie tatsächlich einsetzt – so wie in dem Cloudflare-Post

    • Ich persönlich vertraue dem Agenten bei Rust-Code mehr als bei Python. Bei Python ist die statische Analyse bei weitem nicht auf dem Niveau von clippy oder rust-analyzer, deshalb muss ich jeden Codepfad immer selbst durchtesten

    • Du sagst, man würde deinem git-Verlauf nicht ansehen, dass die Hälfte deines Tages aus Meetings besteht – wenn ich dein Arbeitgeber wäre, würde ich dann bald genau dieses Output-Niveau dauerhaft erwarten

    • Mich würde dein Workflow interessieren. Ich habe Claude Code zum Experimentieren in privaten Projekten verwendet und auch Copilot im Agent-Modus von VS Code mit allem Möglichen gemischt ausprobiert, von Sonnet 3.5 und 3.7 bis 04-mini im Firmenkonto. Ich habe es in einem großen Go-Projekt eingesetzt, und abgesehen von Tests waren die Ergebnisse katastrophal. Ich habe mich gefragt, ob ich das Tool falsch benutze, und deshalb alle „aktuellen Best Practices“ ausprobiert: wechselnde Kontexte, wechselnde Modelle, Regeln definieren, Prompts verbessern – aber nichts davon hat geholfen

    • Du meintest, man könne in der AI-Konventions-Markdown-Datei mehr ergänzen, um Fehler des Agenten zu reduzieren. Mich würde interessieren, ob das eine Datei ist, die du bei jeder Aufgabe als Kontext mitgibst, oder ob das eine offizielle Konvention von VS Code Copilot Agent ist. Und ich würde gern wissen, ob du dich bei der Struktur der Dokumentation an etwas orientiert hast oder ob das ein Artefakt ist, das du im Lauf der Zeit selbst verbessert hast, basierend auf wiederkehrenden Fehlern der AI

  • Es ist wirklich ermutigend, dass die meisten Techniken, die Agentic Coding effizient machen, auch menschliches Programmieren effizienter machen. Früher gab es die Sorge, AI-verstehbarer Code würde zu einer „großen Schlammpfütze“ führen, aber in der Praxis scheint eher das Gegenteil der Fall zu sein. Klarer Code ist für AI-Produktivität sogar noch wichtiger geworden, und dadurch werden Produktivitätsunterschiede plötzlich messbar. Man kann inzwischen numerisch zeigen, wie gut Claude in einer bestimmten Codebasis arbeitet, sodass Diskussionen darüber, ob Code gut strukturiert ist, keine bloßen Meinungsverschiedenheiten mehr sind, sondern auf objektiver Grundlage geführt werden können

    • Die Sorge, dass Code zu einer „Schlammpfütze“ wird, begleitet Programmierung eigentlich schon immer (siehe Vorträge von Rich Hickey). Menschen entscheiden sich oft für „jetzt ist es bequem“, nur um morgen mit riesigen technischen Schulden dazustehen. Durch LLMs wird es auch noch leichter, sinnlosen Boilerplate in Massen zu produzieren. Wenn der Schmerz geringer wird, verschwindet vielleicht sogar der Impuls, überhaupt etwas zu verbessern

    • Ich wollte auch unbedingt den Punkt festhalten: „Die Sorge, dass wir Code schreiben, den nur AI versteht, mag heute noch unbegründet sein – aber wer weiß, wie es künftig aussieht“

    • Das fühle ich sehr. Gute Fehlermeldungen, schnelle Tools, ein stabiles Ökosystem, einfacher Code ohne „Magie“, intuitive SQLs – genau das ist die Entwicklungsumgebung, von der ich immer geträumt habe. Agenten arbeiten so schnell, dass selbst kleine Verzögerungen plötzlich spürbar werden, und ich glaube, dass solche Techniken dadurch das gesamte Entwicklungserlebnis anheben können

  • Ich höre öfter, dass man durch Agenten ganz natürlich in Richtung Go und Tailwind geschoben wird. Weil dafür so viele Trainingsdaten existieren, kann AI damit gut umgehen. Deshalb frage ich mich, ob in einer Zukunft, in der alle solche Tools nutzen, neue Sprachen, Frameworks oder Bibliotheken nicht schwerer entstehen können. Es könnte schwieriger werden, mit bestehenden Lösungen zu konkurrieren, und vielleicht verschwinden sogar menschliche Communities wie StackOverflow

    • Ich teile die Sorge nicht, dass es überhaupt keine neuen Sprachen oder Frameworks mehr geben wird. LLMs sind extrem stark im Übersetzen, und selbst ohne Trainingsdaten können sie sich ungewöhnliche, aber klar strukturierte Frameworks direkt aus der Codebasis erschließen. Ich habe selbst erlebt, dass ein LLM mit meinem idiosynkratischen C#-Framework – etwas, das niemand sonst je gesehen hat – sehr gut zurechtkam. Natürlich lassen sich besondere Eigenschaften wie Rust-Lifetimes nicht sofort perfekt übertragen, aber etwas Einfaches wie Go wird sehr schnell adaptiert. Vielleicht müssen wir künftig neue Sprachen von vornherein mit Blick auf LLM-Kompatibilität entwerfen – also in Design, Tooling und Dokumentation

    • Das ist eine wirklich wichtige Frage. Anders formuliert: Wenn das Internet mit LLM-generierten Daten überflutet wird, schrumpft der Anteil hochwertiger Trainingsdaten, und LLM-freundliche Entwickler könnten sich stärker zu älteren Technologien mit „weniger Strahlung“ hingezogen fühlen, etwa JS/React. Vielleicht wird JavaScript/React künftig zum COBOL der Zukunft – nur ohne teure Berater, weil LLMs die Wartung übernehmen können. Wenn man dem AI-Hype ausweichen will, könnten neue Sprachen, insbesondere eigentümliche Sprachen wie Lisp+DSL, die ein LLM nicht sofort versteht, bis zum AGI-Zeitalter sogar relativ sicher sein

    • Der traditionelle Zyklus von Software-Stacks sieht in etwa so aus: (1) Ein bestehender Stack wächst in alle Nischen hinein und wird immer komplexer, während Experten überall unnötige „Architecture“ hineinbauen. (2) Dadurch erscheint ein neuer, einfacher Stack, der den aktuellen Trend viel klarer und leichter löst, und wird populär. (3) Mit der Zeit wird auch dieser neue Stack schwerfällig und landet wieder bei denselben Problemen. Ich denke nicht, dass AI-Coding diesen Zyklus so leicht durchbrechen wird, weil sich auch der Kontextumfang schnell weiterentwickelt

    • Die Behauptung, man werde in Go und Tailwind gedrängt, spiegelt in Wahrheit stark die persönlichen Vorlieben des Autors wider. Nur weil Sonnet Probleme mit der cargo test-CLI hatte, heißt das nicht, dass Rust, cargo oder gar AI insgesamt das Problem sind. Bei PHP-Tests kann Junie den built-in runner zwar ebenfalls schlecht bedienen, aber wenn ich ihm ein bin/test-php-Skript gebe, nutzt es das problemlos. Es hilft zwar, Anforderungen explizit in Richtlinien zu schreiben, aber es ist eher eine Eigenheit, dass solche Systeme an mitgelieferten Standardwerkzeugen festhalten. Und was die Stack-Overflow-Erfahrung angeht: Mein AI-Assistent hat den Vorteil, dass er Fragen nicht als Duplikat schließt. Die Kuratierungsversuche von SO waren zwar gut gemeint, haben aber tatsächlich viele Nutzer vertrieben

    • Gestern habe ich Claude (in Zed) wieder einfach ein neues Elixir-Phoenix-Projekt aufsetzen lassen, nur auf Basis von Anforderungen, und das lief problemlos. Für CSS wurde Tailwind verwendet, aber das liegt wohl eher daran, dass Phoenix das standardmäßig selbst einrichtet. Ich kann der Behauptung nicht zustimmen, AI würde einen in Richtung Go drängen. Wenn man ohne viel Kontext fragt, kommen eher massenhaft Python-Vorschläge, und selbst mit Elixir, dessen Community kleiner ist, habe ich gute Erfahrungen gemacht

  • Ich habe etwa eine Woche lang mit Claude Code Sonnet 4.0 an Rust-Code experimentiert, und die Ergebnisse blieben unter den Erwartungen – zumal es über Bedrock auch noch teuer ist. Es verbringt viel Zeit mit der anfänglichen Planung, schafft dann aber in der Praxis oft nur die Hälfte. Ich frage mich, ob ich etwas übersehe

    • Mir geht es fast genauso. In Cursor Edit/Agent-Modus bekomme ich die gewünschten Änderungen oft fast in einem Durchlauf und bin dadurch extrem effizient, aber in der CLI-Umgebung ist es viel zu umständlich. Mich würde interessieren, ob du Claude Code eher 10–15 Minuten am Stück arbeiten lässt und dann nur den Diff prüfst, oder ob du auch das Code Review wirklich gründlich machst

    • Ich habe exakt dieselbe Erfahrung gemacht. Ich habe sogar aktiv nach sinnvollen Einsatzfällen gesucht, damit es funktioniert, aber trotzdem tat es das nicht, was mich wirklich irritiert hat

    • Es sollte sich nicht teuer anfühlen. Der Pro-Plan kostet 20 Dollar im Monat, Max liegt bei 100–200 Dollar und ist damit immer noch günstiger, als es per API zu nutzen und über 1.000 Dollar im Monat auszugeben

  • Ich finde es ziemlich erfreulich, dass Container-Nutzung erwähnt wurde. Ich arbeite an dagger/container-use mit, und im Team sind auch ehemalige Docker-Leute sowie der Docker-Gründer. Ich glaube, parallele Agenten werden ein großer Wendepunkt sein, sobald man sie zuverlässig einsetzen kann. Bis es so weit ist, ist ein containerisiertes Entwicklungsumfeld sehr hilfreich, wenn man während der Agent arbeitet etwas anderes tun will oder Sorge hat, dass er versehentlich an den falschen Stellen Änderungen vornimmt. Das Thema Container-Nutzung steht zwar noch am Anfang, entwickelt sich aber extrem schnell, und aktuell arbeiten wir besonders an Stabilität, weniger Git-Konflikten und besserer Interaktion zwischen Mensch und Agent

  • Meine Gedanken zur Sprachauswahl sind diese: 1) Java ist dank des riesigen Umfangs und des langen Datensatzes, auf den LLMs zurückgreifen können, am umfassendsten vertreten – nicht unbedingt am genauesten. 2) Vor allem sollte man die Sprache verwenden, die man selbst am besten beherrscht, damit man Fehlannahmen, Fehler und Halluzinationen des LLM schnell erkennt

    • Die Aussage, Java habe den größten und ältesten klaren Datensatz, klingt für mich wie ein Ratschlag, der nur gilt, wenn das LLM keine Werkzeuge nutzen kann, um APIs, Dokumentation oder 3rd-party-Quellcode nachzuschlagen. Wenn die Tools automatisch herausfinden können, was verwendet werden soll, ist die konkrete Sprache am Ende weniger wichtig – der Agent muss nur den Quellcode lesen können. Aber dem zweiten Punkt stimme ich voll zu: Am Ende ist sorgfältige menschliche Prüfung unverzichtbar, und in einer Sprache, die man kennt, fällt die Beurteilung von Fehlern leichter

    • Warum sollte gerade Java den größten Datensatz haben? Gibt es unter den Open-Source-Projekten am meisten Java – vielleicht wegen der gesamten Apache-Suite? Oder liegt es daran, dass Dokumentation für Java-Open-Source-Bibliotheken besonders reichhaltig ist?

    • Ich dachte immer, der größte Datensatz sei Python-Code. Wenn nichts anderes gesagt wird, empfehlen LLMs meistens zuerst Python

  • Zur Behauptung, Gos context-System – also das explizite Weiterreichen von Daten entlang des Ausführungspfads – mache AI-Agenten einfacher, kam die Kritik: „Außer Tracing-Daten sollte man überhaupt keine Daten in context.Context stecken; das ist in der Praxis keine gute Konvention“

    • Stimme ich zu. In chromedp (dem Chrome-Headless-Driver für Go) ist context.Context der erste Parameter, aber man muss einen speziellen Context aus einer Factory verwenden, nicht einfach context.Background(). Für Timeouts nutzt man separat context.WithTimeout, und am Ende wird das fast wie ein void*-Pointer benutzt

    • Ich bin zwar kein Go-Experte, aber in der Praxis sehe ich viele Bibliotheken, die Dinge wie Datenbankverbindungen, Konfiguration, Rate-Limiter oder Cache-Backends in den Context packen, deshalb wirkt das für mich im Moment nicht besonders problematisch

  • „Code so einfach schreiben, dass AI ihn versteht“ war nicht der Innovationspunkt, den ich mir erhofft hatte. Mich würde interessieren, wie das mit meinem früheren Text über ugly code kollidiert

    • Diese Art, einfachen und klaren Code zu schreiben, hilft in Teamarbeit eigentlich fast immer. Es gibt Momente, in denen man sich extrem tief hineindenken oder kreativ programmieren muss, aber das sind Ausnahmen und sollten eng an den Business-Wert gekoppelt sein. Für den Großteil des Codes gilt: „Die offensichtliche Lösung ist die richtige.“ Entwickler sind nicht langsam, weil sie tippen, sondern wegen der Menge an „Konzepten“, die sie gleichzeitig im Kopf halten müssen. Also: keine überengineerten Interfaces, Abstraktionen hinauszögern, Copy-and-paste und einfache Komposition zulassen, Patterns einfach so umsetzen wie in der offiziellen Dokumentation, nie versuchen, besonders clever zu sein. Der Kern ist: Code nicht hübsch, sondern klar und einfach strukturieren – die wirklich schwierige Aufgabe ist nicht der Code selbst, sondern das „Produkt“

  • Wie der Autor zum Thema Claude Code schrieb, gibt es tatsächlich verschiedene Alternativen wie OpenCode, goose, Codex, Devin, Cursor background agent usw. Jemand fragte nach Open-Source- plus lokalem-LLM-Lösungen, die Claude Code ähnlich sind

    • Im Moment gibt es nicht wirklich eine Open-Source- plus lokales-LLM-Lösung, die ich klar empfehlen würde. Aber OpenCode von SST entwickelt sich UX-seitig sehr schnell, und sobald bessere lokale Modelle erscheinen, lässt sich das vermutlich leicht darauf anwenden. Das größte Problem ist derzeit, dass es kaum gute Modelle mit wirklich starkem „Tool Use“ gibt. Dass Sonnet so verblüffend gut ist, liegt an spezialisiertem Training für Tool Use. Gemini ist davon noch weit entfernt. Ich denke, das ist letztlich ein Problem, das sich löst, sobald bessere Modelle auftauchen

    • Aider ist fast dort angekommen, ist aber absichtlich nicht vollständig agentisch. Automatisches Ausführen von Tests und statischer Analyse, automatisches Beheben von Fehlern – all das geht bereits, und auch projektweite Spezifikationen auf Basis von To-do-Listen lassen sich bearbeiten. Im Moment gibt es noch ein hartkodiertes Limit von drei Reflexionsdurchläufen, aber das kann man mit ein wenig Hacking beliebig erhöhen, und sobald Self-Prompting dazukommt, ist es praktisch ein vollautomatischer Agent

    • Ich glaube, meine App, die bald erscheint, wird ebenfalls eine gute Alternative sein. Ein einzelner Dateidownload, keine Installation nötig, nutzbar auf Mac, Windows, Linux und Docker. Sie kann alle Modelle verwenden, die mit der OpenAI API kompatibel sind – auch selbst gehostete –, ist browserbasiert und ähnlich komfortabel wie Claude Code, und man kann damit auch eine befehlsbasierte Konsolen-App bauen. Zusätzlich lässt sich ein eigenes Terminal öffnen und an Services anbinden. Im Moment ist sie noch in einer geschlossenen Alpha-Phase, aber wer sie ausprobieren will, kann mir per E-Mail schreiben

    • Fast täglich erscheinen neue Alternativen oder neue Versuche, deshalb glaube ich, dass wir bald eine wirklich passende Option sehen werden. Zum Beispiel wurde app.build gerade erst vom Neon-Team (jetzt bei Databricks) gestartet und wirkt ziemlich vielversprechend

    • Das Neovim-Plugin CodeCompanion entwickelt sich zuletzt ebenfalls stärker in eine agentische Richtung. Es unterstützt bereits Auto-Submit-Loops, integrierte Tools und MCP-Integration. Es ist zwar kein eigenständiges CLI-Tool, hat aber den großen Vorteil, dass man sofort in einer vollständigen Editor-Umgebung arbeitet – besonders attraktiv, wenn man gern hackt, anpasst oder leichte Editoren bevorzugt

  • 100–200 Dollar im Monat sind für eine noch nicht ausreichend verifizierte AI zum Coden viel zu teuer. Meine persönlichen Erfahrungen waren nicht besonders überzeugend, und dazu kommen noch ethische Kontroversen, was die Einstiegshürde weiter erhöht

    • Claude Code kann man entweder mit API-Key nutzen oder über ein Pro-Abo für 20 Dollar im Monat

    • Ich würde empfehlen, Aider mit API-Abrechnung auszuprobieren. Über die Steuerung der Kontextgröße (/clear, /add, /drop) kann man den Kontext auf etwa 25K begrenzen. Man kann das gewünschte Modell frei wählen, etwa Sonnet 4 oder Gemini 2.5 Pro. Einfache Skripte lassen sich oft für unter 1 Dollar fertigstellen, und selbst bei sehr großen Tools bin ich inklusive Prompts, Code und rund 100 Tests unter 6 Dollar geblieben. Wenn man sich an AI-gestütztes Coden gewöhnt hat, kann man danach zu Claude Code wechseln – leistungsfähiger, aber wenn man es nicht häufig nutzt, auch eher teuer

    • Mit einem Monatsabo für 20 Dollar kann man ein paar kleinere Projekte gut ausprobieren und dann einschätzen, ob sich ein 100-Dollar-Plan lohnt. Oder man wartet noch ein paar Monate und orientiert sich an den Erfahrungsberichten anderer aus dem Praxiseinsatz