Programmieren wird billiger. Softwareentwicklung nicht.
Vor Kurzem ist mir eine Preistabelle über den Weg gelaufen, die kursierte, die Art, die geteilt wird, weil sie witzig und ein bisschen zu treffend ist. Sie hat Entwickler-Optionen wie eine Speisekarte verglichen:
- Katze auf der Tastatur $5/Stunde
- Vibe-Coder $20/Stunde
- Softwareentwickler $100/Stunde
Das ist offensichtlich ein Witz. Aber solche Witze funktionieren meistens, weil eine echte Beobachtung darin steckt, und diese hier ist es wert, für eine Minute ernst genommen zu werden.
KI hat das Schreiben von Code drastisch billiger und schneller gemacht. Dieser Teil stimmt, und das ist eine gute Sache. Was ich nicht für wahr halte, ist die daraus folgende Implikation: dass Softwareentwicklung selbst weniger wertvoll geworden ist, oder dass die 100-$-Spalte jetzt überteuerte Nostalgie ist.
Ich sage gleich vorweg, wo ich stehe, weil das wichtig dafür ist, wie du den Rest liest. Ich nutze KI-Coding-Tools ständig. Sie haben mich bei fast allem, was ich tue, schneller gemacht. Das ist keine „früher haben wir noch in Assembler programmiert"-Beschwerde. Es ist ein spezifischerer Punkt: Code zu generieren und ein System zu entwickeln sind nicht dieselbe Fähigkeit, und KI beseitigt nicht die Notwendigkeit des Urteilsvermögens, das die beiden trennt.
Worin KI tatsächlich gut ist
Bitte ein KI-Tool, einen Produktfilter, ein Checkout-Validierungsskript oder eine Liquid-Section mit einem Countdown-Timer zu schreiben, und es wird wahrscheinlich in unter einer Minute solide Arbeit leisten. Für einen Prototyp, eine einfache Funktion oder ein einmaliges internes Tool ist das wirklich großartig. Vor ein paar Jahren bedeuteten viele dieser Aufgaben noch, den Großteil der Implementierung manuell zu schreiben und zu debuggen. Jetzt kommst du oft in einer Kaffeepause zu einer soliden ersten Version. Ich werde nicht so tun, als wäre das etwas anderes als eine echte Verbesserung.
Aber Syntax zu schreiben war nie der schwierige Teil dieses Jobs. Es fühlte sich beim Lernen so an, weil es damals echten Aufwand bedeutete, überhaupt irgendetwas zum Laufen zu bringen. Wenn man das eine Weile macht, merkt man, dass die eigentliche Schwierigkeit die ganze Zeit woanders lag: zu verstehen, was das System tun muss, wie es mit allem um es herum interagiert, was passiert, wenn ein Kunde etwas tut, das man nicht erwartet hat, und was sechs Monate später kaputtgeht, wenn jemand anderes den Code anfasst.
KI ist sehr gut darin, etwas zu produzieren, das korrekt aussieht. Sie ist deutlich weniger zuverlässig darin, zu wissen, ob es für dein spezifisches System, deine spezifischen Daten und deine spezifischen Grenzfälle korrekt ist. Sie wird selbstbewusst eine Rabattberechnung schreiben, die für eine Währung subtil falsch ist, oder einen Webhook-Handler, der annimmt, dass eine Bestellung immer nur eine Erfüllung hat. Der Code läuft. Er sieht in einem Code-Review sogar vernünftig aus, wenn niemand genau hinschaut. Das ist der gefährliche Teil.
Wo sich das in Shopify-Projekten zeigt
Hier verbringe ich die meiste Zeit, also lass es mich konkret statt abstrakt machen.
KI kann dir eine Liquid-Section, eine JavaScript-Interaktion auf einer Produktseite, einen API-Call zur Bestandssynchronisierung oder eine einfache Shopify-App-Funktion schreiben, alles schnell und alles einigermaßen gut. Wenn das das ganze Projekt ist, brauchst du wirklich nicht viel mehr als das.
Aber die meiste echte Shopify-Arbeit ist kein isoliertes Einzelstück. Es ist Shopify Markets, das parallel mit mehreren Währungen und Sprachen läuft. Es ist Checkout-Anpassung innerhalb der Grenzen dessen, was Shopify tatsächlich zu berühren erlaubt. Es ist Bestandssynchronisierung, die korrekt über ein System hinweg funktioniert, das auch von Metafeldern, ein paar Drittanbieter-Apps, einer eigenen API und etwas Legacy-Logik abhängt, die niemand vollständig dokumentiert hat. Es sind Webhooks, die sich korrekt verhalten müssen, wenn sie in falscher Reihenfolge ankommen, doppelt, oder gar nicht. Es sind Kundendaten, die über fünf Systeme hinweg konsistent bleiben müssen, die nie dafür konzipiert wurden, miteinander zu sprechen.
Nichts davon ist ein Code-Generierungsproblem. Es ist ein „wie interagieren all diese Teile tatsächlich miteinander, und was ist das korrekte Verhalten, wenn sie kollidieren"-Problem. KI kann helfen, jedes einzelne Teil dieses Puzzles zu schreiben, und mit genug Kontext kann sie auch helfen, über das ganze Puzzle nachzudenken. Aber jemand muss diesen Kontext trotzdem liefern, seine Annahmen hinterfragen, die Plattform- und Geschäftsbeschränkungen verstehen, die Kompromisse eingehen und entscheiden, welche Lösung tatsächlich sicher genug für den Produktivbetrieb ist.
Der Teil, bei dem man immer noch jemand Verantwortlichen braucht
Es gibt eine Version des Preisarguments, die lautet: warum 100 $/Stunde zahlen, wenn es jemand mit KI für 20 $/Stunde machen kann?
Ich glaube nicht, dass die ehrliche Antwort lautet: „weil teure Entwickler automatisch besser sind." Viele teure Entwickler sind es nicht. Die ehrliche Antwort ist, dass der Stundensatz ein schlechter Näherungswert für die Kosten ist. Die realen Kosten liegen näher an so etwas wie: Satz × Zeit × Fehler × zukünftige Wartung. Ein günstigerer Build kann durchaus insgesamt die billigere Option sein, besonders bei einem Prototyp, einem internen Tool, einem Experiment oder etwas wirklich risikoarmem. Ich würde niemandem sagen, keinen Landingpage-Test oder ein schnelles internes Dashboard zu vibe-coden. Das ist oft genau die richtige Entscheidung.
Teuer wird es, wenn eine schnelle, plausibel aussehende Lösung mit Geschäftslogik, die niemand vollständig geprüft hat, in Produktion geht, und der Fehler drei Monate später als Preisfehler, ein kaputter Checkout-Grenzfall oder ein Datensynchronisierungsproblem auftaucht, das still und leise eine Woche lang Bestellungen beschädigt hat. An diesem Punkt hat der 20-$-Build kein Geld gespart. Er hat die Kosten nur verschoben und größer gemacht, und jetzt muss jemand ein System verstehen, das er nicht gut genug gebaut hat, um es unter Druck zu reparieren.
Das ist wirklich der Unterschied, den ich ziehen würde, und es ist nicht „hat KI das geschrieben." Es ist eher: versteht jemand dieses System gut genug, um dafür verantwortlich zu sein? Eine Codebasis, die zu neunzig Prozent KI-generiert ist, kann trotzdem gut entwickelt sein, wenn jemand Erfahrenes den Ansatz entworfen, das Ergebnis geprüft, die Grenzfälle getestet, die Kompromisse verstanden hat und bereit ist, im Produktivbetrieb dafür geradezustehen. Umgekehrt gilt genauso. Code, der komplett von Hand geschrieben wurde, ganz ohne KI-Beteiligung, kann trotzdem schlecht entwickelt sein, wenn niemand diese Arbeit geleistet hat. Das Werkzeug, mit dem der Code entstanden ist, war nie wirklich der Punkt.
Ein Junior-Entwickler mit KI kann oft beeindruckend schnell eine funktionierende erste Version produzieren. Geschwindigkeit bis zur ersten funktionierenden Version ist nicht dasselbe wie Geschwindigkeit bis zu etwas, worauf man sicher ein Unternehmen betreiben kann. Der Wert eines Senior-Entwicklers ging selten darum, schneller zu tippen als alle anderen. Es geht meistens darum, von vornherein nicht das Falsche zu bauen, ein Problem in den Anforderungen zu bemerken, bevor es ein Problem im Produktivbetrieb wird, und die einfachere von zwei Lösungen statt der beeindruckenderen zu wählen. Zwei Stunden dieser Art des Denkens haben Projekte, an denen ich gearbeitet habe, vor zehn oder zwanzig Stunden Bauen in die falsche Richtung bewahrt. KI kann bei diesem Denken auch helfen. Aber sie beseitigt nicht die Notwendigkeit, dass jemand die Entscheidung trifft und die Verantwortung für das Ergebnis übernimmt.
Wo das die Dinge zurücklässt
Ich glaube nicht, dass die Antwort darin besteht, KI-unterstützter Entwicklung misstrauisch gegenüberzustehen, und ich wäre ein Heuchler, wenn ich das behaupten würde, da ich sie jeden Tag nutze. Entwickler, die sich weigern, diese Tools anzufassen, werden schlicht zurückfallen. Aber Entwickler, die sich auf KI-Output verlassen, ohne zu verstehen, was er produziert hat, bauen still und leise Risiko in ihre Systeme ein, und dieses Risiko zeigt sich nicht am ersten Tag.
Die stärkste Kombination, die ich gesehen habe, ist nicht „KI statt Entwicklungserfahrung." Es ist Entwicklungserfahrung mit KI als Hebel: jemand, der bereits weiß, wie eine gute Lösung aussieht, der KI nutzt, um schneller dorthin zu kommen, und der genug weiß, um es zu bemerken, wenn die generierte Antwort falsch ist.
KI macht Entwickler schneller. Sie beseitigt nicht die Notwendigkeit, zu wissen, was man tut, und für alles, was ein echtes Unternehmen betreibt, ist dieser Teil überhaupt nicht billiger geworden.