Code ist alles, was du brauchst: Warum Code-Generierung MCP überlegen sein könnte

Code ist alles, was du brauchst: Warum Code-Generierung MCP überlegen sein könnte

Die Verwendung von Model-Control-Programmen (MCP) zur Automatisierung von Aufgaben erfreut sich wachsender Beliebtheit. Allerdings gibt es Argumente dafür, dass die direkte Code-Generierung durch Large Language Models (LLMs) in vielen Fällen überlegen sein könnte. MCPs leiden demnach unter zwei Hauptproblemen:

1. Ein Großteil der Komposition erfolgt durch Inferenz.
2. Sie benötigen zu viel Kontext. MCPs benötigen umfangreiche Vorab-Informationen und jede Werkzeug-Invocation verbraucht noch mehr Kontext.

Es stellt sich also die Frage: Ist MCP wirklich die Zukunft, oder gibt es bessere Alternativen?

Die Grenzen von MCP

Die Grenzen von MCP werden besonders im Bereich des "agentischen Codings" deutlich. Obwohl MCP für allgemeine Code-Generierung weniger relevant sein mag, da Modelle hier bereits sehr gut sind, wird oft angenommen, dass sie für Endanwender-Anwendungen, wie z.B. die Automatisierung domänenspezifischer Aufgaben, sinnvoll sein könnten. Die Realität sieht jedoch anders aus.

Aktuelle Ansätze zur Erhöhung der Anzahl verwendeter Tools beinhalten in der Regel eine Filterschicht. Dabei werden alle Werkzeuge an ein LLM übergeben, welches diese dann basierend auf der anstehenden Aufgabe filtert. Bislang gibt es jedoch keine wesentlich besseren Vorschläge. Es lässt sich argumentieren, dass die aktuelle Form von MCP immer umständlicher sein wird als das Schreiben von Code, vor allem aufgrund der starken Abhängigkeit von Inferenz.

Ersetze dich selbst durch ein Shell-Skript

In der Softwareentwicklung ist Code das Mittel der Wahl, um Probleme zu lösen. Viele Aufgaben, die manuell erledigt werden, lassen sich durch Software automatisieren. Die Herausforderung besteht darin, jemanden zu finden, der diese Software schreibt. LLMs bieten hier eine vielversprechende Alternative.

Anstatt sich selbst durch ein Shell-Skript zu ersetzen, könnte man sich durch ein LLM ersetzen. Allerdings gibt es hierbei Probleme wie Kosten, Geschwindigkeit und allgemeine Zuverlässigkeit, die gelöst werden müssen, bevor man überhaupt über Tool-Nutzung oder MCP nachdenken kann.

Der Schlüssel zur Automatisierung liegt darin, sich wiederholende Aufgaben zu automatisieren. Für diese Wiederholungen ist die Verwendung von Code oft die beste Wahl. Wenn man die Maschine anweist, Inferenz zu nutzen, erfordert dies eine Validierung, die fast so lange dauern kann wie die ursprüngliche Aufgabe. Es ist besser, wenn das LLM den Python-Code für eine Berechnung schreibt, anstatt die Berechnung selbst durchzuführen. Auf diese Weise kann man die Formel überprüfen und sich darauf verlassen, dass Python korrekt rechnet. Die Code-Generierung ermöglicht es, den Prozess selbst zu verifizieren und zu validieren, anstatt nur darauf zu hoffen, dass das LLM korrekt inferiert.

LLM zu Code zu LLM

Ein Beispiel für diesen Ansatz ist die Konvertierung eines Blogs von reStructuredText zu Markdown. Anstatt das LLM die Konvertierung direkt durchführen zu lassen, wurde es verwendet, um Code zu generieren, der die Konvertierung durchführt. Der Prozess umfasste:

1. Das LLM transformierte den reStructuredText in Markdown, indem es den Abstract Syntax Tree (AST) verwendete. So wurde das reStructuredText zuerst in ein AST geparst und dann in ein Markdown-AST konvertiert.
2. Das LLM schrieb ein Skript, das das alte mit dem neuen HTML vergleicht und Unterschiede nach einer Bereinigung findet.
3. Das LLM erstellte ein drittes Skript zur Analyse der Unterschiede.

Dieser Prozess wurde in einer Schleife ausgeführt, bis die Unterschiede gering waren. Der Vorteil dieses Ansatzes ist, dass man den Prozess überprüfen und validieren kann. Ein weiteres LLM kann den vom ersten LLM geschriebenen Code analysieren, was das Vertrauen in das Ergebnis erhöht. Die Kosten für die Inferenz skalieren mit der Anzahl der Iterationsschritte und der Stichprobengröße, aber nicht mit der Anzahl der zu konvertierenden Dokumente.

Dieser Transformationsprozess beinhaltet also menschliche Eingaben, die Erzeugung von Code, ein LLM als "Richter" und iterative Schritte. Dieser Ansatz lässt sich auch auf andere Aufgaben übertragen.

Beispielsweise könnte man Playwright durch einen Code-Ansatz ersetzen, indem man das LLM ein Playwright-Python-Skript schreiben lässt, das die Aufgabe ohne Inferenz ausführt. Dieser Ansatz ist oft schneller und liefert korrekte Ergebnisse, da er den Code versteht.

Wohin führt das?

Es bleibt abzuwarten, wohin diese Entwicklung führt. MCP ist zwar in bestimmten Fällen nützlich, wirkt aber in seiner jetzigen Form wie eine Sackgasse, die sich nicht für die Automatisierung im großen Maßstab eignet, da sie zu stark auf Inferenz basiert.

Es stellt sich die Frage, ob es möglich ist, eine bessere Abstraktion für die Stärken von MCP und Code-Generierung zu finden. Dazu wären möglicherweise bessere Sandboxes und die Entwicklung von APIs erforderlich, die es einem Agenten ermöglichen, Inferenz zu nutzen. Das Ziel sollte sein, so viel wie möglich in generiertem Code zu erledigen und dann die Fähigkeiten von LLMs zur Bewertung der Ergebnisse zu nutzen.

Es wäre auch interessant, Code so zu generieren, dass ein LLM einem Nicht-Programmierer in verständlicher Sprache erklären kann, was das Skript tut. Dies könnte die Nutzung dieser Abläufe für Benutzer ermöglichen, die keine Entwickler sind.

Die Ermutigung geht dahin, MCP zu umgehen und die Möglichkeiten der Code-Generierung zu erforschen. LLMs können viel mehr leisten, wenn sie die Möglichkeit haben, Code zu schreiben.

Die Kommentare sind geschlossen.