Dein erstes KI-Tool braucht einen kleinen, klaren Auftrag.

Nimm eine Aufgabe, die du selbst beurteilen kannst.

Stell dir vor, du erstellst Angebote für deine Dienstleistungen. Du schätzt die Stunden, setzt einen Stundensatz an und rechnest einen Puffer dazu. Bisher machst du das in einer Tabelle. Ein kleines Tool könnte diese Rechnung übersichtlicher machen.

Die erste Version muss dafür weder deine Kunden verwalten noch Rechnungen schreiben. Sie braucht drei Eingaben und eine nachvollziehbare Ausgabe. Du kennst die Rechnung bereits. Genau das hilft dir beim Bauen: Du kannst erkennen, ob das Werkzeug etwas Sinnvolles tut. Die KI unterstützt hier die Entwicklung. Der fertige Rechner selbst braucht für diese feste Rechenregel kein KI-Modell.

Such dir für den Einstieg eine solche Aufgabe. Wenn du das erwartete Ergebnis an einem einfachen Beispiel auf Papier bestimmen kannst, hast du später einen Maßstab für die Umsetzung. Du musst der erzeugten Oberfläche dann nicht einfach vertrauen.

Schreib auf, was hinein- und herauskommen soll.

„Baue mir eine Angebots-App“ lässt viele Entscheidungen offen. Welche Angaben sind Pflicht? Ist der Preis netto oder brutto? Soll das Ergebnis gespeichert werden? Geht sofort eine E-Mail an den Kunden?

Für unseren Rechner legen wir fest: Stunden mal Stundensatz, darauf der prozentuale Puffer. Ausgegeben wird ein Nettobetrag. Die Angaben bleiben nur für die aktuelle Nutzung im Browser. Kundenkonten, Speicherung und Versand gehören zunächst nicht dazu.

Damit wird aus der Idee ein Auftrag, über den du entscheiden kannst. Du beschreibst das gewünschte Verhalten und seine Grenzen. Wie das Werkzeug intern aufgebaut wird, ist der nächste Schritt.

Lege die richtige Antwort fest, bevor du testest.

Nimm 24 Projektstunden, 95 Euro pro Stunde und zehn Prozent Puffer. Zuerst ergeben 24 mal 95 genau 2.280 Euro. Der Puffer beträgt 228 Euro. Der Rechner muss also 2.508 Euro netto anzeigen. Dieses Beispiel kannst du unabhängig von der KI nachrechnen.

Prüfe danach Situationen, in denen die Oberfläche leicht eine falsche Sicherheit vermittelt. Ein leeres Feld ist nicht dasselbe wie eine bewusste Null. Negative Stunden ergeben für dieses Angebot keinen Sinn. Und ein Dezimalkomma sollte nicht unbemerkt zu einer anderen Zahl werden.

Schreib zu jedem Test auf, welches Verhalten du erwartest. Wenn ein Ergebnis nicht passt, beschreibe der KI die Eingabe, die tatsächliche Ausgabe und die gewünschte Reaktion. „Bei leerem Stundensatz erscheint ein Preis; stattdessen soll eine Fehlermeldung kommen“ ist eine brauchbare Rückmeldung.

• Stimmt das Ergebnis für einen vollständig ausgefüllten Normalfall?
• Werden fehlende Angaben als fehlend erkannt?
• Werden negative Werte verständlich zurückgewiesen?
• Ist die Eingabe mit deutschem Dezimalkomma eindeutig geregelt?
• Stehen Währung, Puffer und Nettobetrag verständlich am Ergebnis?

Ändere eine Sache und prüfe sie erneut.

Vielleicht möchtest du als Nächstes zwischen zwei Stundensätzen wechseln. Ergänze diese Auswahl, teste beide Varianten und rechne das Ausgangsbeispiel noch einmal nach. So merkst du, ob eine neue Funktion etwas verändert hat, das vorher schon funktioniert hat.

Speichere einen funktionierenden Stand, bevor du die nächste größere Änderung beginnst. In der Softwareentwicklung heißt dieses Prinzip Versionsverwaltung. Für den Einstieg zählt vor allem, dass du zu einem bekannten Stand zurückkehren kannst und weißt, was seitdem verändert wurde.

Auch eine hübschere Gestaltung ist eine Änderung. Wenn du Eingabefelder neu anordnest oder Beschriftungen verkürzt, prüfe erneut, ob jemand den Rechner ohne deine Erklärung bedienen kann. Gute Gestaltung hilft beim Verstehen der Aufgabe.

Ein Prototyp ist der Anfang des Werkzeugs.

Für diesen Übungsrechner brauchst du keine echten Namen, E-Mail-Adressen oder Kundendokumente. Fiktive Zahlen reichen, um die Berechnung und Bedienung zu prüfen. Halte den ersten Versuch bewusst bei diesen Daten.

Mit einer späteren Speicherfunktion kommen neue Fragen hinzu: Wo liegen die Angaben? Wer darf sie sehen? Wie werden sie gelöscht? Ein Login oder eine angebundene Datenbank beantwortet diese Fragen noch nicht. Vor dem Einsatz im Alltag müssen die konkrete Anwendung, die gewählten Dienste und die rechtlichen Anforderungen geprüft werden.

Das ist eine andere Aufgabe als das erste Rechenergebnis. Im Workshop bauen wir deshalb einen begrenzten Prototyp und halten die offenen Schritte ausdrücklich fest. Du sollst verstehen, was du bereits beurteilen kannst und wo du weitere Prüfung brauchst.

Diese Arbeitsweise kannst du mitnehmen.

Für einen KI-Assistenten sieht die Ausgabe anders aus als für einen Rechner. Bei einem Workflow kommen Übergaben zwischen mehreren Schritten hinzu. Die Fragen bleiben nützlich: Welche Aufgabe soll gelöst werden? Welche Angaben werden gebraucht? Woran erkenne ich einen Fehler? Wer gibt das Ergebnis frei?

Bei neuen KI-Werkzeugen interessieren mich deshalb diese Punkte: Wie gut lässt sich der Auftrag eingrenzen? Kann ich Änderungen nachvollziehen? Welche Daten werden verarbeitet? Und wie überprüfe ich das Ergebnis? An solchen Fragen lässt sich der Nutzen einer neuen Funktion besser einordnen als an einer überzeugenden Demo.

Was künftige Werkzeuge genau können werden, lässt sich nicht sicher vorhersagen. Ein klarer Auftrag und ein eigener Maßstab für das Ergebnis helfen dir aber dabei, neue Möglichkeiten selbst zu bewerten. Für heute genügt ein erster kleiner Rechner, der eine Aufgabe nachvollziehbar löst.