lx: Ein Vibe-Coding-Tool unter vollständiger Kontrolle des Entwicklers

Einleitung

Hallo. Ich bin ein Student mit Interesse an Informatik. Dieses Mal habe ich ein Programm namens lx entwickelt und möchte zum ersten Mal auf GeekNews posten, das ich bisher nur gelesen habe.

In letzter Zeit ist Vibe Coding angesagt, bei dem man einer KI Anweisungen in natürlicher Sprache gibt und sie den Code von selbst schreibt.
Ich habe Angst vor dieser Art von Vibe Coding.
Es ist nicht einfach nur die Angst vor dem Arbeitsplatzverlust, sondern das Gefühl eines Verlusts des Programmierens, weil uns „die Freude am Schreiben von Code (Wrangling code)“ (Quelle: Kent Beck - Augmented Coding: Beyond the Vibes) und „die Kontrolle des Entwicklers“ genommen werden.

Manche sagen, dieser Wandel sei eine natürliche Evolution der Programmierung, von Lochkarten über Maschinensprache und Assemblersprache bis hin zu C. Aber ich halte diesen Vergleich für falsch.
Frühere Abstraktionen waren ein Prozess, dem Entwickler „einen besseren Hammer“ in die Hand zu geben.
Die Werkzeuge wurden immer besser, aber derjenige, der den Hammer schwang, war weiterhin der Mensch, und das Ergebnis stand vollständig unter der Kontrolle des Entwicklers.
Doch das heutige AI Coding ist anders.
Jetzt schwingt der Roboter den Hammer an unserer Stelle, und dem Entwickler bleibt nur noch, zuzusehen oder bestenfalls zu versuchen, den Roboter ein wenig zu überreden.
Wenn wir den Hammer nicht selbst schwingen können, dann ist das meiner Meinung nach keine Programmierung mehr.
Denn es steht nicht vollständig unter unserer Kontrolle.

Deshalb habe ich lx entwickelt.
lx ist ein Werkzeug, das dem Roboter den Hammer wegnimmt und ihn dem Entwickler wieder in die Hand gibt.
lx ermöglicht es, AI als ein Werkzeug zu behandeln, das sich konsequent kontrollieren lässt.

Hauptteil

lx folgt der Philosophie: „Die Schnittstelle ist menschlich, die Logik ist AI.“
Der Entwickler definiert Ein- und Ausgaben einer Funktion sowie deren Aufgabe und schließt damit einen „Vertrag“, während die AI nur die interne Implementierung dieser Funktion übernimmt.

Dieser Ansatz gewährleistet Kontinuität in der Entwicklung.
In dem Moment, in dem die Ein- und Ausgaben einer Funktion festgelegt sind, gilt die betreffende Logik bereits als fertiggestellt.
Programmierer können sofort die übergeordnete Logik schreiben, ohne sich in Implementierungsdetails zu verlieren, und so den Entwicklungsfluss ohne Unterbrechung aufrechterhalten.

Außerdem ist lx kein einfacher Textaustausch. Mit dem Paket github.com/tree-sitter/go-tree-sitter wird der Quellcode auf Basis des AST (Abstract Syntax Tree) geparst. Dadurch werden anderer Code, Kommentare und Einrückungen in der Datei nicht verunreinigt, und nur die Logik im angegebenen Scope wird sicher ersetzt.

Grundlegende Verwendung

Die grundlegende Form der Verwendung von lx sieht wie folgt aus.

package main  
  
import (  
	"fmt"  
  
	lx "github.com/chebread/lxgo"  
)  
  
func main() {  
	var year string = "2025-01-02"  
    // Der Entwickler kontrolliert den Funktionsaufruf und den Ablauf.  
	result1 := LX_GetYear(year)  
  
	var age = 30  
	result2 := LX_GetAge(age)  
  
	fmt.Println(result1, result2)  
}  
  
func LX_GetYear(year string) (result string) {  
	// Prompt, der an die AI übergeben wird  
	lx.Generate("yyyy-dd-mm 형식을 한국식 날짜로 변환")  
	return  
}  
  
func LX_GetAge(year int) (result string) {  
	// Falls es lästig ist, je nach Programmiersprache eine separate lx-Bibliothek zu installieren, wird auch die folgende Form mit einem lx()-Kommentar-Marker unterstützt.  
    // lx("한국식 나이를 만 나이로 변환")  
	return  
}  

Im obigen Code ist die Funktion LX_GetYear der vom Entwickler definierte Vertrag.
Wenn das Tool lx ausgeführt wird, erkennt es lx.Generate(...) oder den Marker // lx(...), sendet den Prompt an das LLM und überschreibt den Funktionsrumpf mit tatsächlich funktionierendem Code.

Dabei wird Token-Optimierung angewendet. Statt die gesamte Datei zu senden, werden nur die Signatur der betreffenden Funktion und der Prompt an das LLM übermittelt, was Kosten senkt und die Sicherheit erhöht.

2. Kontrolle des Entwicklers

Die Logik innerhalb einer lx-Funktion wird zwar von der AI geschrieben, aber derjenige, der diese Funktion verwendet, sollte der Entwickler sein.
Wenn jedoch benutzerdefinierte Logik innerhalb einer lx-Funktion gemischt wird, wird sie ignoriert. Daher lässt sich die Kontrolle wie unten über eine Wrapper-Funktion ausüben.

package test  
  
import (  
	"fmt"  
	lx "github.com/chebread/lxgo"  
)  
  
func main() {  
	var year string = "2025-01-02"  
	result1 := ParseYear(year) // Aufruf der Wrapper-Funktion  
  
	fmt.Println(result1)  
}  
  
// Geschäftslogik unter Kontrolle des Entwicklers  
func ParseYear(year string) string {  
    // AI-generierte Logik wie ein Bauteil verwenden  
	res := LX_GetYear(year)  
    
    // Zusätzliche Verarbeitung des Ergebnisses bleibt Aufgabe des Entwicklers  
	foo := fmt.Sprintf("Heute ist %v!", res)  
	return foo  
}  
  
func LX_GetYear(year string) (result string) {  
	lx.Generate("yyyy-dd-mm 형식을 한국식 날짜로 변환")  
	return  
}  

3. Sichere Abhängigkeitsverwaltung und Transparenz

lx orientiert sich am Single-Responsibility-Prinzip (SRP).
Es erzeugt nur Code und baut oder führt das Programm nicht aus.
Wenn der von der AI erzeugte Code außerdem externe Bibliotheken benötigt, installiert lx keine Pakete eigenmächtig.

1. Code: Am Anfang des generierten Codes wird ein Kommentar // lx-dep: ... angegeben

2. Output: Bericht der erforderlichen Installationen über die CLI-Standardausgabe

Stattdessen meldet es dies dem Entwickler auf diese zwei Arten.
Der Entwickler kann dies prüfen und selbst entscheiden, ob die Abhängigkeiten installiert werden sollen.

4. Konfiguration

Um lx zu verwenden, ist eine LLM-Konfiguration erforderlich. Dazu erstellt man lx-config.yaml im Home-Verzeichnis (~/) oder im Projekt-Root (./). Wenn an beiden Orten eine Datei vorhanden ist, wird die lokale Konfigurationsdatei bevorzugt angewendet, sodass sich die lx-Konfiguration für jedes Projekt unterschiedlich verwalten lässt.

# lx-config.yaml  
provider: "gemini"  
api_key: "foo"  
model: "bar"  

5. Installation und Ausführung

Mac-Nutzer können die Installation über Homebrew durchführen, andere Betriebssysteme können ein Binary aus lx GitHub Releases herunterladen und installieren.

brew tap chebread/lx  
brew install lx  

Nach der Installation wird beim Ausführen des Befehls lx im Projektpfad echter Code erzeugt.
lx verfügt über eine Smart-Generation-Funktion: Für Funktionen, für die bereits Code erzeugt wurde, wird das LLM nicht erneut aufgerufen. Daher kann der lx-Befehl ohne Sorge wiederholt ausgeführt werden.

Hinweis: lx verwendet für die Formatierung des erzeugten Codes sprachspezifische Tools (Go: goimports, Python: ruff, JS: prettier). Diese Tools müssen im Voraus installiert sein.

6. Lizenz

lx wird unter der AGPL-3.0 License veröffentlicht.
Damit soll lx zum Open-Source-Ökosystem beitragen und zugleich verhindern, dass dieses Tool proprietär vereinnahmt wird.

Fazit

Software ist ein Kristallisationsprodukt, das durch die unermüdlichen Bemühungen der Menschen gewoben wurde. Auch im AI-Zeitalter sollten Programmierer weiterhin die Eigentümer ihres Codes bleiben.
lx überlässt der AI „langweilige Implementierungen“ wie lästige reguläre Ausdrücke oder Daten-Parsing, sorgt aber dafür, dass Struktur und Ablauf des Programms vollständig im Besitz des Menschen bleiben.
Ich empfehle dieses Tool Entwicklern, die die Freude am Schreiben von Code (Wrangling code) und die Kontrolle nicht verlieren möchten!

[moderator]

Gemäß den Betriebsrichtlinien wurde ein unangemessener Kommentar gelöscht, und die Nutzung des entsprechenden Kontos wurde eingeschränkt.

[callakrsos]

Auch das heutige Coden orientiert sich letztlich an menschlichen Maßstäben.
In Zukunft wird wahrscheinlich nicht mehr in ineffizienten, auf Menschen zugeschnittenen Sprachen entwickelt, sondern in anderen Formen.
Genießen wir also die vielen Frameworks, die auf menschliche Maßstäbe ausgerichtet sind, solange es sie noch gibt.

[galadbran]

Es ist sehr interessant, dass das ein Ansatz ist, der dem aktuellen Trend völlig entgegengesetzt ist, nach dem man den Code am besten gar nicht ansehen sollte, um es richtig zu machen.
Je nach Wahl könnte man es wohl auch einfach mit dem Gefühl nutzen, den Bereich, den die AI anfassen darf, klar festzulegen.
Es könnte auch ganz gut sein, so etwas als Skill für Coding-Agenten zu bauen, oder?

[chebread]

Ich werde es aktiv prüfen. Wenn Sie interessiert sind, freue ich mich über viele PRs!

[narubrown]

Scheint ein interessantes Projekt zu sein!

Man schreibt wohl eine Ix-Spezifikation -> ersetzt mit dem Ix Tool die lx-Funktionen durch echte Funktionen -> und kompiliert dann mit Go.
Wenn in einem Projekt eine Sprachebene entsteht, die lx verwendet,
könnte man die mit dem LLM geschriebene Schicht trennen, sodass die spätere Wartung vermutlich auch bequemer wird.

Scheint ein interessanter Versuch mit einem LLM zu sein!

[chebread]

Vielen Dank. lx unterstützt auch andere Programmiersprachen als Go, daher freuen wir uns über häufige Nutzung und Ihr Feedback!

[iknowca]

Das Ziel ist interessant, aber im gesamten Haupttext ist der für KI typische Stil sehr deutlich spürbar,
deshalb fällt es mir schwer, ihm zu vertrauen.

[chebread]

Das ist ein guter Hinweis. Da ich noch in der Oberstufe bin und nicht viel Zeit habe, habe ich beim Schreiben KI genutzt, wodurch der Text offenbar deutlich an Zuverlässigkeit eingebüßt hat. Ich bitte um Ihr Verständnis, auch wenn das vielleicht etwas unbequem ist.

[wegaia]

Wow, es ist wirklich beeindruckend, dass ein Highschool-Schüler sich so etwas ausgedacht hat.
Mit mehr Erfahrung wird er wahrscheinlich noch Beeindruckenderes schaffen.

[siabard]

Wenn ich es richtig verstehe, bedeutet das, dass der Code, der lx.Generate aufruft, durch vom LLM geschriebenen Code ersetzt wird, sobald auf der Kommandozeile ein Befehl ausgeführt wird, oder?
Ich finde die Idee gut, dass der aufrufende Teil eine Art Typeinschränkung sein kann. Mich würde auch interessieren, ob Sie eine Methode in Betracht ziehen, bei der der lx-Befehl in Editoren usw. automatisch ausgeführt wird und den Implementierungscode ersetzt. (Außerdem wäre es schön, wenn es eine Möglichkeit gäbe, den generierten Code neu zu erzeugen, falls er einem nicht gefällt.)
Ich habe mir das Projekt mit Interesse angesehen.

[chebread]

Der Code, der lx.Generate aufruft, wird also vermutlich so geändert, dass er in den von der LLM geschriebenen Code umgewandelt wird, wenn man in der Kommandozeile einen Befehl ausführt? -> Ja, genau so ist es!

Ich finde die Idee gut, dass der aufrufende Teil eine Art Typbeschränkung sein kann. Mich würde auch interessieren, ob Sie eine Variante in Betracht ziehen, bei der der lx-Befehl in Editoren automatisch ausgeführt wird und so den Implementierungscode ersetzt. -> Das ist wirklich eine großartige Idee. Wir werden sie aktiv als Anregung aufgreifen.

Außerdem wäre es gut, wenn es eine Möglichkeit gäbe, den erzeugten Code neu zu generieren, wenn man mit dem Ergebnis nicht zufrieden ist. -> Da die Philosophie des Projekts KI unter der Kontrolle des Entwicklers ist, haben wir es so entworfen, dass bei Bedarf an einer Neugenerierung der lx-Marker erneut erstellt wird.

[maneuling]

Am Niveau des Kommentars, den jemand krampfhaft hinterlässt, nachdem er gesehen hat, dass das von einem jungen Oberstufenschüler gemacht wurde, kann man das Intelligenzniveau schon gut erkennen.

Schauen Sie in den Spiegel und lassen Sie sich behandeln.

killdong | vor 9 Monaten | parent | on: Ich nutze ZIP-Bomben, um meinen Server zu schützen (idiallo.com)
Ich finde, wer auch im Internet keine Verantwortung für seine Ausscheidungen übernimmt, sollte von der Internetnutzung ausgeschlossen werden. Räumen Sie also bitte auf, was Sie ausgeschieden haben.