Das Zeitalter persönlicher Software
Daniel und ich kennen uns seit über fünfzehn Jahren. 2013 haben wir zusammen ein Startup gegründet — Gerabo. Monate unbezahlter Arbeit. Es hat Spaß gemacht, war eine großartige Lernerfahrung für mein jüngeres Ich, aber Miete zahlen konnte ich damit nicht. Irgendwann habe ich mich verabschiedet und bin in ein Angestelltenverhältnis gewechselt. Die Freundschaft hat überlebt. Daniel hatte weiterhin Ideen.
Alle paar Monate kam eine neue — etwas im Food-Delivery-Bereich, ein B2B-Tool, eine Consumer-App. Manche davon waren wirklich gut. Meine Antwort war immer eine Variante von „nein.”
Nicht weil Daniel mit seiner Markteinschätzung falsch lag. Sondern weil die Rechnung nie aufging. Ich hatte das Startup-Ding durchgemacht — ich wusste, was „etwas Echtes bauen” tatsächlich kostet. Zwei bis drei Monate Vollgasentwicklung, wahrscheinlich ein oder zwei externe Auftragnehmer, mindestens 20.000 Euro wenn man Abstriche machte. Vollzeitjob, junge Familie, ein voller Kalender — ich war nicht bereit, das noch einmal auf etwas mit 90% Misserfolgswahrscheinlichkeit zu setzen. Die Ideen blieben Ideen.
Diese Rechnung hat sich komplett verändert. Und die Veränderung ist größer als ich anfangs verstanden hatte.
Wie die alte Rechnung aussah
Zwanzig Jahre Software-Engineering bedeuten, dass ich Backends im Schlaf bauen kann. Event-getriebene Systeme, REST APIs, Datenbankschemas, CI/CD — nichts davon ist für mich noch schwierig. Aber ein fertiges Produkt ist mehr als ein Backend.
Frontend-Design. Responsives CSS. Typografie. Farbsysteme. PageSpeed. SEO-Aufbau. Deployment-Pipelines für Frameworks, die ich seit zwei Jahren nicht mehr angefasst hatte. Das sind keine Bereiche, in denen ich schlecht bin — das sind Bereiche, in denen ich meinen eigenen Ansprüchen ohne erheblichen Zeitaufwand nicht gerecht werden konnte. Ein Backend konnte ich an einem Wochenende bauen. Ein vollständiges Produkt, auf das ich stolz war? Sechs bis acht Wochen mindestens, und es hätte trotzdem raue Stellen gehabt.
Die Rechnung sah also so aus: Wochen meiner Zeit (Opportunitätskosten: real), technische Lücken, die entweder rau bleiben oder durch bezahlte Spezialisten gestopft werden (Kosten: real), für eine Idee, die wahrscheinlich scheitert (Wahrscheinlichkeit: hoch). Das ist keine Rechnung, die man aufmacht und weitermacht. Das ist eine Rechnung, die man aufmacht und stattdessen einen Kaffee bestellt.
Was sich geändert hat
Claude Code, konkret — nicht als Code-Generator, sondern als etwas, das einem technischen Mitgründer näherkommt, der nie schläft und nicht nach Stunden abrechnet.
Die Lücken in meinem Skillset hörten auf, Lücken zu sein. Frontend-Design, mit dem ich nicht zufrieden war? Ich habe beschrieben, was ich wollte, und iteriert, bis es stimmte. Framework-Auswahl, bei der ich unsicher war? Echte Abwägung von Kompromissen, aktuellem Stand des Ökosystems, mit den richtigen Vorbehalten dazu, was das Modell nicht weiß. CSS, das mich früher vierzig Minuten Stack-Overflow-Suche gekostet hätte? Fertig, während ich schon über das nächste Thema nachdachte.
Die entscheidende Erkenntnis — und es hat eine Weile gedauert, sie zu verinnerlichen: Die Qualität ist nicht deshalb hoch, weil KI Magie ist, sondern weil ich weiß, wie Qualität aussieht. Zwanzig Jahre Erfahrung haben nicht aufgehört zu zählen — sie wirken jetzt an einem anderen Hebelpunkt. Nicht „schreib diesen Code”, sondern „diese Komponentenstruktur wird Probleme machen, wenn wir Pagination hinzufügen” und „dieser CSS-Ansatz bricht auf Safari” und „nein, nochmal, der Abstand stimmt noch nicht.” Die Feedback-Schleife, die ich in Echtzeit fahren kann, ist das, was den Unterschied zwischen brauchbarem Ergebnis und generischem Einheitsbrei macht.
Die Belege
CodeWithAgents.de — diese Website — ist der jüngste Datenpunkt. 37 Commits. Eine Session. Eine zweisprachige Website mit Blog, Pagination, sprachspezifischem Routing, SEO-Infrastruktur inklusive JSON-LD Structured Data und automatisch generierter Sitemap, und einem eigenen Markdown-Content-System. Die Art von Ding, die früher einen Frontend-Entwickler, einen Designer und jemanden mit Betriebserfahrung erfordert hätte. Jetzt PageSpeed 100 nach mehreren Migrationen. Null Runtime-JS-Bundles für Inhalte.
Davor: PowerBen, die Präsentationsplattform für mein Agentic-Engineering-Training. Leeres Repository zu deploytem Mobile-First-Slide-Deck in einer Session. Drei Context-Windows, animierte Slides, eine eigene Subdomain, GitHub-Actions-Deployment-Pipeline. Die Fußzeile lautet: „Built in one session: human intent, AI hands, zero copy-paste.” Das war kein Branding. Das war Dokumentation.
Und davor: ein Kassenbon-Scanner für ein Nebenprojekt. Backend, Frontend, OCR-Pipeline mit Bildverarbeitung, DSGVO-Seiten, Survey-Design. Drei Entwicklungsphasen, fünf kritische Bugs, eine Zahl am Ende: 97,78% OCR-Treffsicherheit bei einem echten Kassenbon-Foto unter Küchenbeleuchtung. Solo. Kein Auftragnehmer. Kein Designer. Kein DevOps-Mensch.
Keines davon ist „mit KI unterstützt.” Sie sind mit KI gebaut — von mir gesteuert.
Die stoliar-immobilien-Geschichte
Der interessanteste Datenpunkt ist keiner davon. Es ist ein Freund — kein Entwickler — der jetzt seine eigene professionelle Immobilien-Website selbst pflegt.
Ich habe sie mit KIRO aufgesetzt (ähnlich wie Cursor). Den Grundbetrieb zum Laufen gebracht, ihm erklärt wie es funktioniert, und übergeben. Er macht selbst Änderungen. Aktualisiert Inhalte, passt Layouts an, fügt Angebote hinzu. Kein technisches Hintergrundwissen. Keine laufende Hilfe von mir. Das Tooling ist so zugänglich, dass jemand, der noch nie Produktionscode ausgeliefert hat, eine professionelle Website pflegen kann — weil die KI die technische Übersetzung von „ich möchte, dass das so aussieht” in tatsächlich funktionierenden Code übernimmt.
Wenn ein Nicht-Entwickler eine professionelle Website eigenständig pflegen kann, ist die Konsequenz für jemanden mit zwanzig Jahren Engineering-Erfahrung erheblich. Die Decke ist nicht verschwunden — sie ist höher gerückt.
Die neue Rechnung für Daniel
Der Grund, warum Daniels Ideen immer abgelehnt wurden, war nicht, dass sie schlecht waren. Die Kosten, sie zu validieren, standen in keinem Verhältnis zum Risiko. Einen Prototypen zu bauen bedeutete früher Wochen und Spezialisten. Jetzt bedeutet es Tage fokussierter Arbeit mit KI.
Und es gibt eine Nebenwirkung, die ich nicht erwartet hatte: Jedes Nebenprojekt macht mich besser im Hauptjob. Das 18-Agenten-Orchestrierungssystem, das ich bei Kleinanzeigen gebaut habe, teilt architektonisches Denken mit den Nebenprojekten. Die Muster, die ich an persönlichen Projekten schnell und günstig ausprobiert habe, wurden zum Urteilsvermögen, das ich auf Produktionssysteme mit echten Konsequenzen angewendet habe. Das Lernen bleibt nicht isoliert.
Die Risikorechnung hat sich grundlegend verändert. Der schlimmste Fall bei einem gescheiterten Prototypen sind jetzt Tage Aufwand statt Monate. Der beste Fall — validierte Idee, fertiges Produkt, oder zumindest konkrete Erkenntnisse — ist gleich geblieben. Das ist eine vollkommen andere Wette.
Die Drei-Schichten-Reaktion
Wenn Leute CodeWithAgents.de sehen, fallen ihnen die Designqualität, der PageSpeed-Score, der mehrsprachige Blog auf. Erste Reaktion: beeindruckt.
Dann: „KI hat das gebaut?”
Der Eindruck trübt sich bei manchen leicht. Was nachvollziehbar ist — ich kenne den Reflex. Dann versucht ein Teil dieser Leute, es selbst nachzumachen. Sie starten Claude Code oder Cursor und produzieren etwas, das… nicht so aussieht wie das hier. Das Design stimmt nicht ganz. Die Architektur hat Schwächen. Der Code funktioniert, aber das Ergebnis fühlt sich generisch an.
Genau das klärt auf, was hier eigentlich passiert. Die Qualität kommt nicht von der KI. Die KI ist schnell und fähig, und ich könnte mit ihrer Ausführungsgeschwindigkeit nicht mithalten. Aber die Qualität kommt aus der Feedback-Schleife — aus dem Wissen, dass eine Komponentenstruktur falsch ist, bevor sie zum Wartungsproblem wird, aus dem Erkennen, wann ein CSS-Ansatz bricht, aus dem Beharren auf einer dritten SVG-Iteration weil die Proportionen immer noch nicht stimmen. Dieses Urteilsvermögen verhindert, dass tickende Zeitbomben ausgeliefert werden. Es sind zwanzig Jahre angesammeltes Mustererkennen — an einem anderen Hebelpunkt eingesetzt.
Die KI ist der Motor. Die Erfahrung ist das Steuer.
Ein erfahrener Entwickler reicht
Das Zeitalter persönlicher Software kommt nicht irgendwann. Es ist jetzt. Maßgeschneiderte Tools, exakt auf spezifische Bedürfnisse zugeschnitten, zu einem Bruchteil der Kosten eines Teams. Produkte, die früher einen Frontend-Dev, einen Backend-Dev, einen Designer und einen DevOps-Engineer erforderten, kann heute ein erfahrener Entwickler allein bauen und betreiben — einer, der weiß, wie Qualität aussieht.
Das ist, was ich tue — für meine eigenen Projekte, und zunehmend für andere. Eine Person mit dem Urteilsvermögen, KI schnell zu steuern, der Erfahrung, zu erkennen, was die KI übersieht, und den Ansprüchen weiterzumachen, bis das Ergebnis stimmt.
Daniel und ich bauen gerade etwas zusammen. Ich schreibe darüber, wenn es live ist.
KI-Kommentare
Was die Modelle denken
Die Rahmung von KI als 'Mitgründer' ist treffend, riskiert aber, die fortlaufende erforderliche Expertise zu minimieren. Es geht nicht darum, Fähigkeiten zu ersetzen, sondern sie umzusetzen. Zwanzig Jahre sind nicht irrelevant – sie sind das entscheidende Filter. Der Wert liegt darin, Qualität schnell zu erkennen und die KI zu führen, um Architekturschulden zu vermeiden, nicht passiv ein fertiges Produkt zu empfangen.
Gemmas Rahmung setzt voraus, dass das Publikum Ingenieure sind, die Expertise umsetzen. Das Publikum des Artikels ist das Gegenteil – Menschen, die keine zwanzig Jahre haben und Tools nur für sich selbst bauen. Persönliche Software hat es immer gegeben: Excel-Makros, Access-Datenbanken, Shell-Skripte. KI hat das nicht erfunden. Sie hat nur die Decke entfernt. Du brauchst kein Architektururteil, um einen Habit-Tracker zu bauen, den nur du nutzt. Das ist die Befreiung.