Beruflich habe ich für Kunden immer wieder mit ZPL (Zebra Programming Language) zu tun. Das Testen von Software, die am Ende mit echten Labeldruckern kommuniziert, ist allerdings nicht ganz trivial - vor allem dann, wenn automatisierte Tests auch den Gerätestatus berücksichtigen sollen.
Einen Zustand wie „Papier leer“ kann man an echter Hardware noch relativ problemlos provozieren. Spätestens bei Dingen wie Übertemperatur wird das aber eher schwierig.
Bisher hatte ich dafür ein Python-Script, das verschiedene Antworten und Zustände eines Druckers simulieren konnte. Das funktionierte, hatte aber einen entscheidenden Nachteil: Es hat keine Labels gerendert. Labelary als ZPL-Renderer kenne und nutze ich natürlich, aber Testdaten für jeden automatisierten Test an einen externen Dienst zu schicken, ist bei Kundendaten ein No-Go.
Die Idee eines eigenen ZPL-Emulators hatte ich deshalb schon seit über einem Jahrzehnt im Hinterkopf.
Um die aktuellen Top-KI-Modelle gibt es einen riesigen Hype. Mich hat deshalb interessiert, was eigentlich möglich ist, wenn man bewusst nicht zu den großen und vergleichsweise teuren Modellen greift.
Die Idee für ZplPrinterPro war daher gleichzeitig ein Experiment: Wie weit kommt man mit einem günstigen Open-Source-Modell, wenn man es mit eher klassischen Methoden der Softwareentwicklung kombiniert?
Also: Test Driven Development, möglichst genaue Spezifikationen und Unittests – sehr viele Unittests.
Als Inference Provider habe ich mich bewusst gegen Anthropic und OpenAI entschieden. Stattdessen kam DeepSeek V4 Flash über airouter.ch zum Einsatz.
Als Coding-Harness habe ich Oh My Pi zusammen mit den Plugins Ponytail und Superpowers verwendet. Das Modell bekam außerdem direkt den ZPL Programming Guide als Referenz. Dazu kamen einige ZPL-Testfälle, bei denen sich das gerenderte Ergebnis gegen Labelary behaupten musste.
Die KI sollte also nicht einfach nur „irgendwie einen ZPL-Renderer schreiben“, sondern hatte Spezifikation, Referenzimplementierung und vor allem Tests, an denen sie sich orientieren konnte.
Nach etwas über einer Woche hat mich das Ergebnis tatsächlich ziemlich überrascht.
Natürlich ist der Renderer nicht zu 100 Prozent identisch mit einem echten Zebra-Drucker oder Labelary. Allein durch die Verwendung anderer Fonts entsteht zwangsläufig ein gewisses Delta. Auch Implementierungsfehler und Bugs gab und gibt es, gerne könnt ihr dazu in GitHub ein Issue aufmachen.
Aber deren Anzahl hielt sich erstaunlich stark in Grenzen.
Noch interessanter fand ich dabei eigentlich etwas anderes: Das Projekt hat wieder einmal sehr schön gezeigt, wie viele Fehler sich durch konsequentes automatisiertes Testen finden lassen – unabhängig davon, ob der Code von einem Menschen oder einem KI-Modell geschrieben wurde.
Ein schönes Beispiel waren die Barcodes. Hier gab es Rendering-Probleme, die letztlich mit dem Padding zusammenhingen. Durch die vorhandenen Tests konnte das KI-Modell die Abweichungen selbstständig eingrenzen, die Ursache finden und anschließend fixen.
Und genau das ist für mich bisher die interessanteste Erkenntnis aus dem Experiment:
Vielleicht ist für KI-gestützte Softwareentwicklung nicht nur entscheidend, wie intelligent oder teuer das Modell ist. Mindestens genauso wichtig ist, wie gut wir die Umgebung bauen, in der es arbeitet.
Eine umfangreiche Spezifikation, kleine überprüfbare Schritte, TDD und eine große Menge guter Unittests sind klassische Software-Engineering-Werkzeuge. In Kombination mit aktuellen, günstigen Open-Source-Modellen scheinen sie aber erstaunlich viel zu ermöglichen.
Wer sich das Ergebnis anschauen möchte: ZplPrinterPro auf GitHub