Vibe Coding: Vom Prototyp zum nutzbaren Produkt

Erst das Kriterium, dann der Test

Bevor eine Datei hochgeladen wird, steht fest, was als Erfolg zählt. Sonst wird jedes Ergebnis nachträglich für gut befunden. Für md-converter.de lautete das Kriterium:

1. Eine Word-Datei mit Überschriften, Listen, Tabelle und Link wird zu Markdown, in dem diese vier Elemente als Markdown-Syntax erhalten bleiben. Umlaute bleiben Umlaute.
2. Der Download liefert eine .md-Datei mit genau dem Inhalt, der im Markdown-Tab angezeigt wird.
3. Eine Datei, die das Werkzeug nicht verarbeiten kann, darf nicht wie ein Erfolg aussehen.

Das dritte Kriterium ist das wichtigste. Prototypen funktionieren meistens mit der Datei, mit der sie gebaut wurden. Wie sie mit allem anderen umgehen, entscheidet darüber, ob man ihnen vertrauen kann.

Normalfall: Word-Datei rein, Markdown raus

Auf md-converter.de (öffnet in neuem Tab) wurde die DOCX-Datei über das Auswahlfeld geladen. Die Anzeige meldete „1 von 1 konvertiert“. Der Markdown-Tab zeigte dieses Ergebnis:

# Testdokument für md-converter.de

Dieses Dokument ist **frei erfunden** und dient nur als Testdatei. Es enthält _keine echten Daten_. Umlaute zur Kontrolle: Äpfel, Öfen, Übermaß.

## Was geprüft wird

-   Überschriften bleiben Überschriften
-   Listen bleiben Listen
-   Die Tabelle bleibt eine Tabelle
-   Der Link bleibt anklickbar

## Ablauf

1.  Datei auswählen
2.  Ergebnis prüfen
3.  Markdown herunterladen

## Beispieltabelle

| Element | Erwartung im Markdown | Beispielwert |
| --- | --- | --- |
| Überschrift | Zeile beginnt mit # | Ablauf |
| Liste | Zeile beginnt mit - | Datei auswählen |
| Tabelle | Zeilen mit | | 3 Spalten |

## Link

Die Anwendung selbst: [md-converter.de](https://md-converter.de).

Überschriften, Hervorhebungen, beide Listen, Umlaute und der Link kamen sauber an. Der Knopf „Als Markdown-Datei herunterladen“ lieferte die Datei md-converter-testdokument.md mit genau diesem Inhalt (731 Byte, Typ text/markdown).

Die letzte Tabellenzeile aber hat eine Zelle zu viel. In der Testdatei steht in der mittleren Spalte der Text „Zeilen mit |“. Markdown benutzt den senkrechten Strich als Spaltentrenner. Ohne Escape-Zeichen werden aus einer Zelle mit Strich zwei Zellen. In der Vorschau von md-converter.de stand deshalb in der dritten Spalte nichts. „3 Spalten“ fehlte. Kriterium 1 war damit für die Tabelle nicht erfüllt.

Bemerkenswert daran: Die Testdatei sollte nur prüfen, ob eine Tabelle überhaupt ankommt. Der Strich stand als Beschreibung im Beispieltext, nicht als gezielt eingebauter Sonderfall. Genau deshalb lohnt sich eine Testdatei mit realistischem Inhalt statt „Zelle 1, Zelle 2“.

Fehlerfall: ein PDF ohne Textebene

md-converter.de liest aus PDFs nur den eingebetteten Text. Das steht auch auf der Startseite. Im Abschnitt „Der passende Converter für dein Format“ heißt es dort: „Das funktioniert am besten mit textbasierten PDFs — gescannte Dokumente ohne auswählbaren Text werden nicht unterstützt.“ Die Seite PDF zu Markdown (öffnet in neuem Tab) begründet das mit der fehlenden Texterkennung. Der Fehlerfall ist also eine dokumentierte Grenze. Getestet wurde, wie die Anwendung zurückmeldet, wenn jemand trotzdem einen Scan hineinlegt.

Das PDF mit Textebene verhielt sich so, wie es die Seite PDF zu Markdown (öffnet in neuem Tab) beschreibt. Dort heißt es: „Aufzählungen bleiben Textzeilen mit ‚•‘ und werden nicht zu Markdown-Listen.“ und „Tabellen werden nicht rekonstruiert: Die Zellen einer Zeile landen hintereinander in einer Textzeile.“ Genau so kam der Text an. Ein Detail wich vom Beispiel der Seite ab: Statt „•“ begann jede Aufzählungszeile mit dem Zeichen U+F0B7 aus dem Unicode-Privatbereich, für das es keine festgelegte Darstellung gibt. Das Zeichen steckt bereits in der Textebene der Test-PDF, die LibreOffice aus der Word-Datei erzeugt hat; md-converter.de gibt es unverändert weiter. Die vollständige Ausgabe steht unten als Download. Wer das Dokument auch als Word-Datei hat, nimmt den Weg über DOCX.

Beim Scan meldete die Anwendung am Vormittag dagegen einen Erfolg. Der Markdown-Tab blieb leer, der Download-Knopf war aktiv und lieferte eine Datei mit 0 Byte. Am Ergebnis selbst gab es keinen Hinweis. Der Kasten „Hinweis zu PDFs“ direkt unter dem Konverter nennt Tabellen, Bilder und mehrspaltige Layouts, aber keine Scans. Den Satz zu gescannten Dokumenten findet nur, wer auf der Startseite weiterliest.

Das unerwartete Ergebnis reproduzieren

Ein einzelner Fehlschlag kann Zufall sein, etwa ein Zustand aus einem vorherigen Versuch. Deshalb wurde die Seite am Vormittag neu geladen und dieselbe DOCX-Datei erneut umgewandelt. Das Ergebnis war identisch: Die Zeile lautete wieder | Tabelle | Zeilen mit | | 3 Spalten |, die Vorschau zeigte wieder eine leere dritte Spalte.

Danach lohnt der Blick in den Code, um die Ursache einzugrenzen. Im Produkt-Repo baut eine eigene Regel die Markdown-Tabelle aus dem Textinhalt jeder Zelle. Der Text landet ohne Maskierung zwischen den Trennstrichen. Die GitHub-Flavored-Markdown-Spezifikation (öffnet in neuem Tab) verlangt für einen Strich innerhalb einer Zelle ein vorangestelltes \. Zellen über die Spaltenzahl der Kopfzeile hinaus werden laut Spezifikation verworfen. Genau das ist mit „3 Spalten“ passiert.

Für einen eigenen Prototyp heißt das: Reproduzieren heißt, denselben Weg mit derselben Datei erneut zu gehen und das Ergebnis Zeichen für Zeichen zu vergleichen. Erst dann wird der Fehler an einen Agenten oder an den Code übergeben, zusammen mit Datei, Schritten und erwarteter Ausgabe.

Die Korrektur getrennt prüfen

Eine Korrektur ist ein eigener Arbeitsschritt mit eigenem Nachweis. Für den Tabellenfehler wurde die Annahme vorab außerhalb des Produkts geprüft: In einer Kopie der Tabellenregel wurde der Strich in Zellen mit \ maskiert. Dieselbe Zeile ergab danach drei Zellen, die mittlere mit dem Inhalt „Zeilen mit |“.

Ohne Escape (Ausgabe am Vormittag):
  | Tabelle | Zeilen mit | | 3 Spalten |
  Parser liest 4 Zellen: "Tabelle", "Zeilen mit", "", "3 Spalten"
  Die Kopfzeile hat 3 Spalten, die vierte Zelle wird verworfen.

Mit Escape:
  | Tabelle | Zeilen mit \| | 3 Spalten |
  Parser liest 3 Zellen: "Tabelle", "Zeilen mit |", "3 Spalten"

Diese Gegenprobe lag zum Zeitpunkt des Vormittagstests außerhalb des Produkts. Im Produkt war sie da noch nicht umgesetzt. Ein sauberer Ablauf dafür sieht so aus:

1. Einen Test schreiben, der genau den beobachteten Fall abdeckt: eine Tabellenzelle mit |, erwartete Ausgabe mit \|. Der Test muss vor der Änderung fehlschlagen.
2. Die Regel ändern, nur diese. Der neue Test und alle bestehenden Tests laufen grün.
3. Die Word-Testdatei aus diesem Artikel lokal erneut umwandeln und mit der gespeicherten Word-Ausgabe vergleichen. Erwartet wird genau eine geänderte Zeile.

Für den Scan gilt dasselbe Muster. Eine mögliche Korrektur wäre ein Hinweis, sobald ein PDF keinen Text liefert. Der Test dazu: Die Scan-Datei aus diesem Artikel darf keine Erfolgsmeldung mehr erzeugen.

Beide Korrekturen bleiben getrennte Änderungen. Wer sie mit weiteren „Verbesserungen“ bündelt, weiß hinterher nicht, welche Änderung was bewirkt hat. Am Nachmittag des 10. Oktober 2026 war das öffentliche Ergebnis beider Punkte auf md-converter.de nachvollziehbar: die Word-Datei behält den senkrechten Strich in der Zelle, und die Scan-Datei erzeugt keine Erfolgsmeldung mehr.

Veröffentlichen und denselben Weg öffentlich nachprüfen

Lokal grün heißt noch nicht live korrekt. Zwischen beidem liegen Build, Deployment und Caches. Deshalb endet der Ablauf auf der öffentlichen Domain mit denselben Dateien und denselben Schritten wie oben:

1. md-converter.de in einem frischen Browserfenster öffnen.
2. Die drei Testdateien nacheinander umwandeln.
3. Markdown-Tab und Download vergleichen: für die Word-Datei und das Text-PDF mit den gespeicherten Ausgaben unten, für den Scan mit dem erwarteten Verhalten.
4. Ergebnis mit Datum, Uhrzeit und Browser festhalten, so wie im Kasten „Testumgebung“ unten.

Bei diesem Test zeigte sich noch eine Lücke: md-converter.de zeigt keine Versionsnummer. Ob die öffentliche Seite dem neuesten Stand im Repo entsprach, ließ sich am Vormittag nur indirekt prüfen. Ein Satz, der mit der letzten Änderung vom 17. September 2026 hinzukam, stand auch auf der Live-Seite. Für eine Nachprüfung nach einer Korrektur reicht das knapp. Eine sichtbare Version oder ein Build-Datum würde die Frage eindeutig beantworten. Auch am Nachmittag zeigte die Seite keine Versionsnummer. Das korrigierte Verhalten war an den drei Testdateien trotzdem direkt zu sehen.

Für den eigenen Prototyp

Der Ablauf lässt sich auf jedes kleine Produkt übertragen, nicht nur auf Konverter:

• Einen Weg wählen. Den einen Weg, für den Menschen das Produkt aufrufen, vollständig vom Einstieg bis zum Ergebnis.
• Kriterium vorher aufschreiben. Inklusive dessen, was bei falscher Eingabe passieren soll.
• Eigene Testdateien bauen. Mit realistischem Inhalt, gespeichert, damit jeder Lauf vergleichbar ist.
• Fehler reproduzieren, bevor sie behoben werden. Mit Datei, Schritten, erwarteter und tatsächlicher Ausgabe.
• Jede Korrektur einzeln prüfen. Zuerst ein Test, der fehlschlägt, dann die Änderung.
• Live nachprüfen. Mit denselben Dateien auf der öffentlichen Domain.

Muss man dafür programmieren können? Für den Test selbst nicht. Datei wählen, Ergebnis lesen und vergleichen geht ohne Code. Für die Ursache des Tabellenfehlers half es, die zuständige Regel im Code lesen und die Markdown-Spezifikation nachschlagen zu können. Diese Fähigkeit lässt sich an genau solchen Fehlern lernen.

Wer den Test selbst wiederholen will: Die Dateien stehen unten, die Anwendung ist unter md-converter.de (öffnet in neuem Tab) erreichbar. Was das Werkzeug kann und warum es so klein bleibt, steht auf der Projektseite.

Downloads

• Testdokument (Word)DOCX

  Synthetische Testdatei mit Überschriften, Listen, Tabelle und Link. Inhalt frei erfunden.

• Testdokument (PDF mit Text)PDF

  Dasselbe Dokument als PDF mit Textebene, erzeugt mit LibreOffice.

• Scan ohne TextebenePDF

  Eine Seite, die nur aus einem Bild besteht. Für den Fehlerfall.

• Ergebnis des Testlaufs (Word)Markdown

  Die am Vormittag des 10. Oktober 2026 von md-converter.de heruntergeladene Ausgabe für das Word-Testdokument, vor der Korrektur, unverändert.

• Ergebnis des Testlaufs (PDF mit Text)Markdown

  Die am Vormittag des 10. Oktober 2026 heruntergeladene Ausgabe für das Text-PDF, inhaltlich unverändert. Umbenannt, weil md-converter.de denselben Dateinamen wie beim Word-Ergebnis vergibt.

Quellen

1. md-converter.de (öffnet in neuem Tab)

   Getestete Anwendung, Vormittag und Nachprüfung am 10. Oktober 2026

2. md-converter.de: PDF zu Markdown (öffnet in neuem Tab)

   Dokumentierte Grenzen bei gescannten PDFs und Tabellen, abgerufen am 10. Oktober 2026

3. GitHub Flavored Markdown Spec: Tables (extension) (öffnet in neuem Tab)

   Strich in Zellen maskieren, überzählige Zellen werden verworfen; abgerufen am 10. Oktober 2026