Sprache zum Denken mit KI: warum deine Tastatur das falsche Werkzeug ist

Ich hielt Sprache früher für eine Barrierefreiheits-Schnittstelle oder ein Komfort-Feature. Ich habe meine Meinung geändert, nachdem ich täglich KI-Tools nutze. Die Tastatur ist hervorragend für Präzision, aber sie ist ein schlechtes Instrument zum Denken mit KI, weil sie die Idee zu früh durch einen schmalen Kanal zwingt.

Der Tastatur-Engpass

Ein schneller Tipper schafft maximal rund 70 Wörter pro Minute. Gesprochene Sprache liegt im Gespräch oft eher bei 150 Wörtern pro Minute, und innere Gedanken können schneller laufen als beides. Die genauen Zahlen sind weniger entscheidend als die Form: Die Tastatur zwingt dich, das Denken in polierte Fragmente zu serialisieren, bevor die Idee reif ist.

Das ist der Tastatur-Engpass. Es ist nicht so, dass Tippen in absoluter Hinsicht langsam wäre. Es ist so, dass Tippen dich drängt, schon während des Formulierens zu redigieren. Bei KI entfernt diese frühe Komprimierung oft die nützliche Ambiguität: die Einschränkung, die Alternative, das, bei dem du unsicher bist, das Modell aber berücksichtigen lassen willst.

Am stärksten merke ich es, wenn ich müde bin. Spät am Tag werden meine getippten Prompts kürzer, und das Modell wird entsprechend weniger nützlich. Diktiere ich am selben Abend dieselbe Absicht in dasselbe Tool, kommt eine bessere Antwort heraus, weil die gesprochene Version noch den Kontext trägt, den ich mit der Hand wegredigiert hätte. Die Tastatur bremst mich nicht nur; sie macht mich nach einer bestimmten Uhrzeit zu einem schlechteren Mitstreiter des Modells.

KI verändert die Form des Prompts

Mit einem LLM zu arbeiten ist näher daran, einen Mitstreiter zu briefen, als einen Befehl zu erteilen. Die besten Prompts enthalten oft Kontext, Motiv, Einschränkungen, Beispiele und Unsicherheit. Sprach-Prompts funktionieren bei KI-Tools besser, wenn das Problem noch unscharf ist, weil du den umgebenden Kontext aussprechen kannst, ohne anzuhalten, um ihn elegant zu machen.

Genau deshalb ist Sprache zum Denken wichtig. Du kannst sagen: „Ich glaube, der Bug liegt im Cache-Key, bin mir aber nicht sicher, ob die User-Locale Teil davon ist; prüf zuerst diesen Pfad und sag mir, ob ich falsch liege." Getippt wird daraus oft „check cache bug". Der kürzere Prompt verliert den Gedanken.

Die Form eines Prompts ist heute Teil der Arbeit, nicht eine Vorrede dazu. Behandle den Prompt als das Artefakt, das du produzierst, und Sprache wird zum natürlichen Autorenwerkzeug: Sie bewahrt die Struktur, in der du das Problem tatsächlich verstehst, inklusive der Teile, bei denen du unsicher bist. Ein Modell, das die halbfertige Form bekommt, liefert oft eine bessere Antwort als ein Modell, das einen selbstsicheren, aber unvollständigen Befehl bekommt.

Drei Momente, die mich umgestimmt haben

Der erste war eine Debugging-Sitzung. Ich tippte einen kurzen Prompt in einen Agenten und bat ihn, eine Regression zu prüfen. Er ging den falschen Weg. Dann diktierte ich die unordentliche Version: was sich verändert hatte, was ich vermutete, woran ich zweifelte und was meine Theorie widerlegen würde. Der Agent fand das Problem schneller, weil ich ihm endlich die Form meiner Unsicherheit gegeben hatte.

Der zweite war Schreiben. Ich tippte einen knackigen Absatz über unseren Model-Stack, und er klang korrekt, aber tot. Ich sprach dieselbe Idee beim Auf- und Abgehen aus, einschließlich der Frustration, die uns zu der Architektur geführt hatte. Die diktierte Version hatte das eigentliche Argument. Ich habe sie trotzdem überarbeitet, aber aus einem lebendigen Entwurf statt einer sterilen Gliederung.

Der dritte war eine lange, unangenehme Kundenantwort. Der Kunde hatte eine Frage gestellt, auf die es keine saubere Antwort gab; die ehrliche Antwort enthielt Abwägungen und eine kleine Entschuldigung. Getippt durchlief meine Antwort sechs Überarbeitungen und blieb steif. Diktiert war der erste Take wärmer, direkter und brauchte nur eine Korrektur an einem einzigen Wort. Ich schickte diese Version, und das Gespräch ging weiter. Ich vertraue getippten Antworten nicht mehr, wenn die Nachricht auch nur einen Hauch Ton braucht.

Wie ich Sprache heute nutze

Ich nutze Sprache für das erste Nachdenken, nicht für endgültige Präzision. Ich diktiere das unordentliche Briefing in Claude Code, Cursor, Obsidian oder eine schlichte Markdown-Datei. Danach wechsle ich für exakte Bearbeitungen zur Tastatur. Diese Trennung hält jedes Werkzeug in seiner Spur: Sprache für Kontext, Tastatur für die Operation.

• Vor dem Coden: Ich diktiere die Änderung, das Risiko und den Testpfad. Die diktierte Version bringt meist ein Risiko ans Licht, das ich beim Tippen übersprungen hätte.
• Vor dem Schreiben: Ich spreche das Argument laut aus, bevor ich gliedere. Wenn ich das Argument nicht in zwei Minuten sagen kann, weiß ich noch nicht, was ich denke.
• Vor Meetings: Ich diktiere die Entscheidung, die ich aus dem Gespräch brauche. Mit einer benannten Entscheidung in ein Meeting zu gehen, verändert das Gespräch.
• Nach Misserfolgen: Ich diktiere, was mich überrascht hat, bevor die Erinnerung verblasst. Am nächsten Morgen ist die Lektion weg, wenn sie nicht festgehalten wurde.

Als externen Bezug zu Sprechgeschwindigkeit und Diktiermustern sind die Spracherkennungs-Artikel der Nielsen Norman Group und Referenzen zu Wörtern pro Minute nützliche Ausgangspunkte.

Die Einwände, die ich immer wieder höre

„Ich arbeite in geteilten Räumen." Fair, und das ist eine echte Einschränkung. Meine Antwort lautet: Schon zehn ruhige Minuten am Tag, in denen die harten Prompts diktiert werden, sind nützlicher als ein ganzer Tag getippter Prompts. Sprache muss den Workflow nicht dominieren, um ihn zu verändern.

„Ich kann beim Tippen denken." Manche Menschen können das tatsächlich. Der Test ist nicht, ob du durch Tippen Text produzieren kannst; sondern ob der Text, den du tippst, dieselbe Form hat wie der Gedanke, den du gesprochen hättest. Bei den meisten von uns, mich eingeschlossen, ist die getippte Version durchgängig weniger vollständig.

„Ich klinge weitschweifig, wenn ich diktiere." Die erste Woche ist mühsam. Die zweite ist deutlich besser. Die Fähigkeit, die hier gelernt wird, ist nicht das Sprechen; es ist, einen gesprochenen Gedanken in etwas zu formen, mit dem ein Leser (oder ein Modell) arbeiten kann. Sie kommt schneller zurück als erwartet, weil jeder sie schon einmal genutzt hat — eben im Gespräch.

Wo Loqua hineinpasst

Wir haben Loqua geschrieben, weil ich Sprache zum Denken wollte, ohne die Aufräumarbeit eines rohen Transkripts in Kauf zu nehmen. Es entfernt Fehlstarts, behält technische Begriffe und formatiert die Ausgabe für die App, in der ich gerade bin. Der weiche Pitch lautet: Nutze Loqua, wenn die Idee zu groß oder zu zerbrechlich ist, um sie zuerst durch die Tastatur zu pressen.

Für die praktische Variante dieses Arguments siehe unseren Voice-First-Arbeitstag. Dieser Beitrag zeigt, wann Sprache funktioniert, wann sie scheitert und wann ich trotzdem zur Tastatur greife. Dieser Artikel hier behandelt das Warum; der andere das Wie.