Ohne Informatikstudium mit KI programmieren — ein ehrlicher Praxistest

Die Testfrage ist schnell gestellt und schwerer zu beantworten, als es zunächst klingt: Kann eine Person ohne klassische Softwareentwicklungs-Ausbildung mit Unterstützung künstlicher Intelligenz praxistaugliche Web-Anwendungen entwickeln? Nicht als Prototyp, nicht als Demo für ein Wochenende — sondern als Werkzeug, das danach wirklich im Alltag läuft.

Ich beantworte sie nicht theoretisch, sondern an dem, was bei mir in den letzten Monaten tatsächlich entstanden ist: PromptPilot, ein PLU-Trainer, eine Inventur-App, mehrere Luca-Lernprojekte, interne Filialwerkzeuge — und, am ausführlichsten dokumentiert, SHORT&BIO, mein eigener Ersatz für einen gekauften Kurzlink-Dienst. Ganz unterschiedliche Aufgaben, ein gemeinsames Werkzeug.

Die Praxisbeispiele im Überblick

Zur Einordnung, bevor es ins Detail geht, kurz, worum es bei jedem Projekt geht:

• PromptPilot — mein erstes großes Projekt und eigentlich das Herzstück: ein Übersetzer von der Idee zum Prompt. Man beschreibt in eigenen Worten, was man erreichen will, PromptPilot formt daraus einen Prompt, der bei einer KI tatsächlich brauchbare Ergebnisse liefert — besonders gedacht für KI-Bildgenerierung.
• PLU-Trainer — ein Quiz für Mitarbeiter, um die an der Kasse gebrauchten PLU-Nummern für Obst und Gemüse einzuüben, mit Karteikarten und eigener PLU-Liste zum Nachschlagen.
• Inventur-App — Bestandszählung per Bluetooth-Scanner statt Papierliste, getrennte Zugänge für Filiale und Verwaltung, läuft produktiv im Tagesgeschäft.
• Luca-Lernprojekte — ein Lernspiel für meinen Sohn samt eigenem Player, das nachts von allein weiterwächst: aktuell 20 erzählte und 134 KI-generierte Welten.
• Interne Filialwerkzeuge — kleinere Helfer für wiederkehrende Aufgaben im Arbeitsalltag.
• SHORT&BIO — Kurzlinks, Bio-Seiten und QR-Codes als selbst gebauter Ersatz für ein gekauftes Skript, das mir zu aufgebläht und zu altbacken war.
• vanheek.biz — diese Website selbst, samt einem internen „Cockpit“, das den Stand aller meiner Projekte an einer Stelle zusammenfasst.

Am gründlichsten auswerten kann ich SHORT&BIO und diese Website hier, vanheek.biz, selbst — bei beiden wurde von Anfang an mitgeschrieben, was passiert ist, inklusive der Stellen, an denen es nicht auf Anhieb geklappt hat. Die anderen Projekte fließen mit ein, aber ohne erfundene Zahlen dazu — was ich nicht belegen kann, schreibe ich nicht als Fakt hin.

Fallbeispiel: SHORT&BIO

SHORT&BIO ist kein einzelner Auftrag gewesen, sondern eine Folge von klar abgegrenzten Ausbaustufen — im Projekt „Bausteine“ genannt: erst das Fundament, dann Bio-Seiten mit fünf Farbschemata, eine App-artige Startseite, eine Verwaltung mit eigener Befehlspalette, eine installierbare PWA, Registrierung auf Einladung, danach ein kompletter Plugin-Baukasten mit eigener API. Am Ende stehen unter anderem:

• 560 automatisierte Einheitentests,
• 1.548 Durchlauftests gegen einen echten laufenden Server,
• 21 Migrationstests für Datenbankänderungen,
• ein Lexikon-Baustein an anderer Stelle mit über 350 eigenständig verfassten Begriffserklärungen als Beleg dafür, wie viel Inhalt sich mit KI-Unterstützung in vertretbarer Zeit seriös erarbeiten lässt.

Alle Zahlen sind kein Zufallsprodukt — sie stammen aus echten Testläufen, die vor jeder Auslieferung laufen mussten, und aus einer externen Abnahmeprüfung, die den Live-Server von außen gegenprüft.

Zweites Fallbeispiel: diese Website und das Cockpit dahinter

Auch vanheek.biz, die Seite, auf der du gerade liest, ist kein gekauftes Baukasten-Thema, sondern mit denselben Mitteln entstanden wie SHORT&BIO: eigene Python-Skripte bauen die Seiten aus Markdown-Dateien und Vorlagen, dieselbe Sonnenstand-Technik steuert Tag und Nacht, und auch das Lexikon, in dem sich Fachbegriffe aus diesem Artikel nachschlagen lassen, ist so ein selbst gebauter Baustein — über 350 Begriffe, Suche und Kategorie-Filter komplett im Browser, ohne eigenen Server.

Der eigentliche Beleg für „mitgeschrieben“ ist aber ein internes Werkzeug: das Cockpit. Es liest die Status-Datei jedes einzelnen Projekts ein — jede davon hält in festem Format fest, woran zuletzt gearbeitet wurde, was als Nächstes ansteht und ob ein Projekt lebt, ruht oder nur eine Idee ist — und baut daraus eine einzige Übersicht. Stand 12. September 2026 fasst das Cockpit auf diese Weise 11 Projekte und 25 offene Ideen zusammen. Ohne diese laufende Mitschrift ließe sich der Satz „das ist alles dokumentiert“ nicht halten — mit ihr lässt sich für jedes einzelne Projekt jederzeit nachschlagen, was wirklich passiert ist, statt sich auf die Erinnerung zu verlassen.

Was ich untersucht habe

Entwicklungszeit

Eine geführte Zeiterfassung gibt es nicht, nur den Kalender: SHORT&BIO entstand vom 1. bis 9. September 2026, neun Kalendertage von der ersten Entscheidung bis zu dem Stand, den dieser Artikel beschreibt. Die Arbeit lief in konzentrierten Schüben: An einem einzigen Tag, dem 4. September, entstand allein der komplette „zweite Umbau“ mit App-artiger Startseite, eigener Verwaltung und installierbarer PWA. Dazwischen lief die KI-Unterstützung auch eigenständig weiter, während ich unterwegs oder bei der Arbeit war, und ich habe das Ergebnis erst danach gegengeprüft. Eine seriöse Stundenzahl kann ich daraus nicht ableiten; würde ich eine nennen, wäre sie erfunden, und genau solche Zahlen will dieser Test nicht liefern. Realistisch lässt sich aber sagen: Ohne KI-Unterstützung hätte allein der Funktionsumfang, der am Ende live steht — Plugin-Baukasten, eigene API, Zwei-Faktor- Authentifizierung, eine PWA, über zweitausend automatisierte Tests —, für eine einzelne Person nebenberuflich eher Monate als Tage gebraucht.

Was sich aber unabhängig von der genauen Stundenzahl sagen lässt: Die Zeit verschiebt sich. Weniger Zeit geht für das Nachschlagen von Syntax drauf, mehr Zeit für das genaue Beschreiben, was eigentlich gebraucht wird — und für das Nachprüfen, ob das Ergebnis das auch wirklich tut.

Notwendige Vorkenntnisse

Bei null fing ich nicht an, aber auch nicht dort, wo man es für diese Projekte vermuten würde. Einfaches HTML kannte ich, etwas PHP und den Umgang mit APIs auch — aus einer ganz anderen Zeit: Vor rund fünfzehn Jahren habe ich automatisierte Preisvergleichsseiten und Schnäppchen-Blogs selbst gehostet, damals aber vor allem mit WordPress und fertigen Skripten von CodeCanyon zusammengesteckt, nicht selbst von Grund auf entwickelt. Zwischen diesem Startpunkt und dem, was jetzt entsteht — eigene Migrationsverwaltung, eine echte Testsuite, eine selbst gehärtete Sicherheitsrichtlinie — liegt ein fundamentaler Unterschied: fertige Bausteine zusammenzustecken ist etwas anderes, als zu verstehen, warum ein System so und nicht anders aufgebaut sein muss. Genau diese Lücke schließt die KI-Unterstützung nicht von selbst — sie macht es nur möglich, sie in vertretbarer Zeit selbst zu schließen. Unabhängig vom konkreten Startpunkt zeigt sich an allen Projekten dasselbe Muster: Nicht Syntaxwissen war der Engpass, sondern die Fähigkeit, eine Anforderung präzise zu formulieren und ein Ergebnis kritisch zu prüfen, statt es einfach zu übernehmen.

Technische Probleme

Die interessanteren Fehler sind nicht die, die sofort auffallen, sondern die, die erst bei genauer Prüfung sichtbar werden. Ein Beispiel aus SHORT&BIO: Der erste Bildschirm der Startseite hing an einer Einblendanimation, die erst startete, wenn ein nachgeladenes Skript fertig war. Auf einer schnellen Verbindung sah das nach einem sanften Effekt aus — auf einer gedrosselten Verbindung blieb der Bildschirm bis zu drei Sekunden komplett leer. Gefunden habe ich das nicht durch Zusehen, sondern durch eine gezielte Messung mit gedrosselter Verbindung, weil sich Aussagen über das Aussehen einer Seite grundsätzlich nicht aus dem Code ableiten lassen — nur durch echtes Ansehen, in hell und in dunkel.

Qualität des Endprodukts

Messbar an dem, was tatsächlich lief: eine externe Prüfung gegen den echten Server bestand am Ende 59 von 59 bzw. später 65 von 65 Einzelprüfungen — Cookie-Freiheit, Sicherheitskopfzeilen, korrekte Fehlercodes, funktionierende neue Funktionen, alles unabhängig von außen abgeklopft, nicht nur behauptet.

Tatsächlicher Nutzen

Der Nutzen zeigt sich am ehesten darin, was ersetzt wurde: ein gekauftes, aufgeblähtes Skript durch einen schlankeren, schnelleren eigenen Dienst; eine externe Kurzlink-Subdomain, die inzwischen vollständig abgeschaltet ist, weil der Eigenbau sie überflüssig gemacht hat. Der PLU-Trainer ersetzt dagegen kein anderes Werkzeug, sondern schafft eines, das es vorher gar nicht gab: Ein Quiz, mit dem Mitarbeiter die an der Kasse gebrauchten PLU-Nummern für Obst und Gemüse gezielt einüben — Frage, Antwort, sofortige Auswertung, dazu Karteikarten und eine Liste zum Nachschlagen. Der Nutzen ist damit unmittelbar messbar dort, wo er zählt: weniger Suchen an der Kasse, weniger Rückfragen, schnellere Abläufe im laufenden Betrieb.

Grenzen der KI-Unterstützung

Hier wird es am ehrlichsten unangenehm, und genau das gehört in einen Praxistest hinein, nicht nur die Erfolgsgeschichte. KI kann unglaublich viel beschleunigen — sie ersetzt aber nicht das Verständnis für Anforderungen, Tests und Fehlerkontrolle. Ohne dieses Verständnis produziert man mit beeindruckender Geschwindigkeit Softwarefehler. Fortschritt, im schlechten Sinn.

Konkret bei SHORT&BIO: Ein im Hintergrund arbeitender KI-Auftrag hatte einen großen Ausbauschritt fertiggestellt und sogar erfolgreich ausgeliefert — aber ohne das irgendwo zu vermerken. Erst eine unabhängige Nachprüfung (Prüfsummen-Abgleich zwischen lokalem und Live-Stand, ein gezielter Testaufruf gegen den echten Server) hat das bestätigt. Die Lehre daraus, die ich seitdem konsequent anwende: Eine Erledigt-Meldung ist erst dann etwas wert, wenn sie sich von außen nachprüfen lässt — ein `git status`, ein echter Aufruf gegen den Live-Server, ein Blick auf den tatsächlichen Bildschirm statt auf das, was der Code angeblich erzeugt.

Weitere Grenzen, die sich über alle Projekte hinweg wiederholt haben:

• Vorschläge klingen oft überzeugend, auch wenn sie es inhaltlich nicht sind — Nachprüfen ist keine Option, sondern Pflicht.
• Rechtliche und sicherheitsrelevante Texte (Impressum, Datenschutz, Umgang mit Zugangsdaten) verlangen besondere Sorgfalt und eigene Kontrolle, nicht blindes Vertrauen.
• Ohne eine klare Testsuite bleibt jede noch so schnelle Änderung ein Blindflug — die Tests sind kein Beiwerk, sie sind die eigentliche Absicherung.
• Design und Ton eines Projekts entstehen nicht von allein; ohne eine klare eigene Vorstellung, wie etwas wirken soll, entsteht schnell etwas Beliebiges.

Fazit

Die Testfrage lässt sich mit Ja beantworten — mit einer wichtigen Einschränkung. Ohne klassische Softwareentwicklungs-Ausbildung entstehen mit KI-Unterstützung praxistaugliche Web-Anwendungen, aber nicht von selbst und nicht ohne eigene Kontrolle. Die KI übernimmt das Schreiben von Code in großem Umfang; sie übernimmt nicht das Formulieren einer Anforderung, das Erkennen, wenn ein Ergebnis nur so aussieht, als würde es funktionieren, und die Verantwortung für das, was am Ende live geht. Genau diese drei Dinge — präzise Anforderungen, Testbereitschaft, Fehlerkontrolle — bleiben Handarbeit. Wer sie mitbringt oder sich aneignet, kommt mit KI erstaunlich weit ohne Studium. Wer sie überspringt, produziert schnell Software, die schnell wieder Probleme macht.