Es gibt Neuigkeiten zu VelinScript. Und diesmal geht es nicht um eine neue Funktion, eine neue Version oder irgendeine technische Änderung, die ich nach mehreren Stunden Fehlersuche endlich zum Laufen gebracht habe.

Ich habe mich dazu entschieden, die weitere Entwicklung von VelinScript vorerst einzustellen.

Diese Entscheidung fällt mir nicht leicht. Hinter VelinScript steckt viel Entwicklungsarbeit, angefangen bei der Konzeption einer eigenen Sprache bis hin zur technischen Umsetzung und der Frage, wie sich damit strukturierte Abläufe für KI-Systeme beschreiben und verarbeiten lassen.

Trotzdem ist es an der Zeit, eine Pause einzulegen.

Ich möchte erklären, was dahintersteckt, warum ich diese Entscheidung getroffen habe und was sie für die Zukunft von VelinScript bedeutet.

VelinScript ist meine eigene Sprache für die Beschreibung und Steuerung von Abläufen im Bereich der KI-Orchestrierung.

Die Idee dahinter ist, technische Abläufe nicht ausschließlich mit herkömmlichem Anwendungscode zu definieren, sondern eine eigene Sprache zu verwenden, die auf diesen Einsatzzweck zugeschnitten ist.

Dabei geht es um mehr als eine eigene Schreibweise für Befehle. Eine Programmiersprache benötigt klare Regeln dafür, wie Anweisungen aufgebaut sind, wie sie verarbeitet werden und welche Bedeutung sie innerhalb eines Systems haben.

VelinScript verfolgt dabei einen eigenen technischen Ansatz: Der geschriebene Code wird in Rust weiterverarbeitet, indem VelinScript nach Rust kompiliert.

Warum dieser Weg?

Rust bietet eine Grundlage für die Entwicklung leistungsfähiger und systemnaher Software. Durch die Übersetzung in Rust lässt sich VelinScript mit einem bestehenden technischen Ökosystem verbinden, statt sämtliche Aufgaben einer vollständigen Laufzeitumgebung von Grund auf selbst entwickeln zu müssen.

Das bedeutet allerdings nicht, dass dadurch alle schwierigen Aufgaben automatisch erledigt sind. Ein Compiler braucht klare Regeln, eine zuverlässige Verarbeitung und nachvollziehbare Fehlermeldungen. Auch die erzeugten Ergebnisse müssen geprüft werden.

Eine eigene Sprache zu entwickeln, heißt deshalb, sich mit mehreren technischen Ebenen gleichzeitig auseinanderzusetzen.

Man entwirft die Sprache, setzt ihre Regeln um, prüft die Verarbeitung und untersucht, ob die Ergebnisse den Erwartungen entsprechen. Dazu kommen Fehlerbehandlung, Wartbarkeit, Dokumentation und die Weiterentwicklung bestehender Funktionen.

Und genau hier zeigt sich, wie viel Arbeit in einem solchen Vorhaben steckt.

Mich interessiert die Frage, wie sich technische Abläufe für KI-Systeme gezielt strukturieren und steuern lassen.

Bei einer eigenen Sprache kann ich selbst festlegen, welche Konzepte ich unterstützen möchte, wie Anweisungen aufgebaut sind und wie sich die Sprache in meine technischen Systeme einfügt.

Ich bin dadurch nicht vollständig an die Entscheidungen eines bestehenden Werkzeugs gebunden. Gleichzeitig trage ich aber auch selbst die Verantwortung für die Entwicklung, die Qualität und die langfristige Pflege.

Das ist ein wichtiger Unterschied.

Wer eine etablierte Programmiersprache nutzt, greift auf ein großes Ökosystem zurück. Es gibt Werkzeuge, Dokumentation und zahlreiche Erfahrungen aus der Praxis. Bei einer eigenen Sprache muss ein erheblicher Teil dieser Grundlage selbst entstehen.

Das ist technisch interessant, bringt aber auch einen hohen Aufwand mit sich.

Und nein, eine neue Programmiersprache entsteht leider nicht dadurch, dass man sich einen Namen ausdenkt, ein paar Schlüsselwörter festlegt und anschließend eine README-Datei mit dem Titel „Die Zukunft beginnt jetzt“ veröffentlicht.

Schön wäre es. Dann wäre dieser Beitrag allerdings deutlich kürzer.

Bei der Entwicklung von VelinScript geht es nicht allein darum, neue Funktionen hinzuzufügen.

Entscheidend ist, dass die einzelnen Bestandteile zuverlässig zusammenspielen.

Eine Sprache muss eindeutig definiert sein. Der Compiler muss die Eingaben korrekt verarbeiten. Fehler müssen sich sinnvoll erkennen und untersuchen lassen. Und technische Änderungen dürfen nicht dazu führen, dass bereits vorhandene Funktionen unbemerkt anders arbeiten.

Je größer ein solches System wird, desto wichtiger werden diese Grundlagen.

Eine neue Funktion lässt sich unter Umständen schnell implementieren. Sie dauerhaft sauber in eine bestehende Architektur einzuordnen, kann dagegen deutlich mehr Arbeit verursachen.

Deshalb gehört zu einer verantwortungsvollen Weiterentwicklung auch die Zeit für Tests, Fehlerkorrekturen und technische Überarbeitung.

Gerade bei einem selbst entwickelten System kann man nicht jede Aufgabe einfach an ein fertiges Werkzeug abgeben. Ein Teil der Arbeit besteht darin, die passenden Werkzeuge und Abläufe überhaupt erst zu entwickeln oder miteinander zu verbinden.

Das macht die Entwicklung spannend. Es macht sie aber auch aufwendig.

Der wichtigste Grund ist die Priorisierung meiner verfügbaren Entwicklungszeit.

Ich arbeite an mehreren technischen Aufgaben und muss entscheiden, welche davon ich aktuell mit den vorhandenen Ressourcen sinnvoll verfolgen kann.

VelinScript benötigt kontinuierliche Aufmerksamkeit. Die Sprache muss weiterentwickelt, getestet, dokumentiert und technisch gepflegt werden. Wenn ich diese Arbeit nicht mit der notwendigen Konsequenz fortsetzen kann, wäre es wenig sinnvoll, einfach im bisherigen Rhythmus weiterzumachen.

Deshalb setze ich die aktive Weiterentwicklung vorerst aus.

Das ist keine spontane Reaktion auf einen einzelnen Fehler und auch keine Aussage darüber, dass die technische Idee hinter VelinScript gescheitert wäre.

Ich treffe diese Entscheidung, weil ich meine Arbeit realistisch planen muss.

Meine verfügbare Zeit ist begrenzt. Auch als Entwickler kann ich nicht beliebig viele Aufgaben gleichzeitig bearbeiten und dabei erwarten, dass jedes Projekt die gleiche Aufmerksamkeit erhält.

Ich habe bisher keine Möglichkeit gefunden, zusätzliche Stunden direkt in den Tag zu kompilieren. Rust ist dabei leider keine Hilfe.

Also muss ich Prioritäten setzen.

Mir ist es lieber, eine Entwicklung offen zu pausieren, als ständig weitere Schritte anzukündigen, ohne sie zuverlässig umsetzen zu können.

Die weitere aktive Entwicklung von VelinScript wird vorerst eingestellt.

Damit pausieren zunächst die Arbeiten an zusätzlichen Funktionen, technischen Erweiterungen und weiteren geplanten Entwicklungsschritten. Auch reguläre neue Versionen stehen aktuell nicht auf meinem festen Entwicklungsplan.

Ich lege mich bewusst nicht auf einen Termin für eine mögliche Fortsetzung fest.

Ein konkreter Veröffentlichungstermin wäre nur dann sinnvoll, wenn ich die dafür erforderliche Zeit und die notwendigen Entwicklungsschritte zuverlässig einplanen könnte. Das kann ich derzeit nicht zusichern.

Die bisherige Entwicklung ist damit nicht automatisch endgültig beendet. Ich erkläre VelinScript auch nicht für gescheitert. Ich setze lediglich die aktive Arbeit aus, bis die Voraussetzungen für eine Fortsetzung wieder passen.

Wichtig ist diese Unterscheidung, denn eine Pause ist keine Zusage für einen späteren Neustart.

Ob und wann ich die Entwicklung wieder aufnehme, bleibt offen.

Die bisherige Arbeit an VelinScript bleibt die Grundlage für eine mögliche spätere Bewertung des Projekts.

Sollte ich die Entwicklung zu einem späteren Zeitpunkt wieder aufnehmen, müsste ich zunächst prüfen, welchen technischen Stand das Projekt dann hat und welche Schritte sinnvoll sind.

Dazu gehören beispielsweise die Überprüfung der bestehenden Implementierung, der Compiler-Verarbeitung, der Tests und der technischen Dokumentation.

Es wäre nicht sinnvoll, nach einer längeren Unterbrechung einfach an der letzten Stelle weiterzuschreiben, ohne vorher den tatsächlichen Zustand zu prüfen.

Software entwickelt sich weiter. Abhängigkeiten verändern sich, Anforderungen können sich verschieben und frühere technische Entscheidungen müssen mitunter neu bewertet werden.

Das gilt auch für eine eigene Sprache.

Wie bei jedem Softwareprojekt entscheidet nicht die Zahl der geschriebenen Codezeilen darüber, ob eine Entwicklung erfolgreich ist. Entscheidend ist, ob das Ergebnis technisch nachvollziehbar, zuverlässig und für den vorgesehenen Zweck sinnvoll einsetzbar ist.

Die Entwicklung einer eigenen Sprache ist ein Vorhaben, bei dem der eigentliche Programmcode nur einen Teil der Arbeit ausmacht.

Wer sich damit beschäftigt, muss sich auch um die Regeln der Sprache, die Verarbeitung des Codes, die Fehlerdiagnose und die langfristige Wartbarkeit kümmern.

Diese Aufgaben verschwinden nicht, nur weil die grundlegende Idee bereits funktioniert.

Mit jeder zusätzlichen Funktion wächst zudem der Umfang, der geprüft und dokumentiert werden muss. Änderungen müssen auf ihre Auswirkungen untersucht werden. Fehler dürfen nicht einfach von einer Stelle zur nächsten wandern.

Ich sehe die Pause deshalb auch als Anlass, meine Prioritäten neu zu ordnen.

Es bringt wenig, ein Projekt ausschließlich deshalb weiterzuführen, weil bereits viel Arbeit darin steckt. Die bisher investierte Zeit allein ist kein guter Grund, unbegrenzt weitere Zeit zu investieren.

Manchmal muss man prüfen, ob der nächste Entwicklungsschritt gerade tatsächlich der sinnvollste ist.

Das ist keine besonders spektakuläre Erkenntnis. Aber sie gehört zur Arbeit an eigener Software genauso dazu wie das Schreiben und Testen von Code.

Zum jetzigen Zeitpunkt gibt es keinen festen Plan für die Wiederaufnahme.

Ich möchte keine neue Versionsnummer ankündigen und keine Termine veröffentlichen, die nicht auf einer belastbaren Planung beruhen.

Sollte sich meine Priorisierung ändern und ich die Entwicklung wieder aufnehmen, werde ich über die nächsten Schritte informieren.

Bis dahin bleibt die Weiterentwicklung ausgesetzt.

Das bedeutet auch, dass ich keine regelmäßigen Updates verspreche. Ich möchte den tatsächlichen Entwicklungsstand kommunizieren, statt künstlich Aktivität zu erzeugen.

Für mich gehört diese Offenheit zu einem vernünftigen Umgang mit einem eigenen Softwareprojekt. Dazu gehört auch, Entscheidungen zu treffen, die nicht unbedingt die sind, die man sich zu Beginn vorgestellt hat.

Man startet ein Projekt mit einer Idee und einem Ziel. Auf dem Weg dorthin muss man aber regelmäßig prüfen, ob die geplanten Schritte noch zu den verfügbaren Ressourcen und den aktuellen Prioritäten passen.

Genau das mache ich jetzt.

VelinScript ist ein eigenständiges Entwicklungsprojekt mit dem Ziel, eine eigene Sprache für die KI-Orchestrierung bereitzustellen, deren Code nach Rust kompiliert wird.

Die Entwicklung hat technische Arbeit, Planung und kontinuierliche Pflege erfordert. Für die nächsten Schritte müsste ich weiterhin Zeit in die Implementierung, Fehlerbehebung, Tests und Dokumentation investieren.

Diese Zeit möchte ich aktuell für andere Aufgaben einsetzen.

Deshalb stelle ich die aktive Weiterentwicklung von VelinScript vorerst ein.

Das ist keine endgültige Absage an die Idee. Es ist aber auch kein Versprechen, dass es zu einem bestimmten Zeitpunkt weitergeht.

Ich halte es für sinnvoller, diese Entscheidung klar zu kommunizieren, anstatt eine Weiterentwicklung vorzutäuschen, die ich derzeit nicht konsequent verfolgen kann.

Manchmal besteht eine technische Entscheidung eben nicht darin, welchen Compiler man verwendet oder wie man eine Funktion implementiert. Manchmal besteht sie darin, vorerst keine weitere Funktion zu schreiben.

Auch das gehört zur Softwareentwicklung.

Danke an alle, die sich für VelinScript und meine Arbeit interessieren.

Sobald es konkrete Neuigkeiten zur weiteren Entwicklung gibt, werde ich darüber berichten.

Sebastian Vogel
SKYLITE.DESIGN