KI hat den Start und die Ausführung von Engineering-Arbeit deutlich beschleunigt. Doch Software endet nicht beim ersten Entwurf, dort beginnt meist die eigentliche Arbeit.
Ich nutze KI jeden Tag und würde nicht darauf verzichten wollen.
Das ist wohl der einfachste Einstieg. KI hat mich schneller gemacht, mir geholfen, schneller zu lernen, und ganze Bereiche des Engineerings zugänglicher wirken lassen als früher. Sie hat verändert, wie ich Arbeit beginne, wie ich Kontext finde, wie ich Code schreibe, wie ich teste und wie ich mich durch Teile des Stacks bewege, die sich einst fremd anfühlten.
Bei Webflow denken wir viel darüber nach, wo KI in den Engineering-Workflow passt. Nicht nur als Code-Generator und nicht als Abkürzung am Urteilsvermögen vorbei, sondern als Weg, Menschen mit mehr Kontext und weniger Reibung durch echte Produktarbeit zu helfen.
Diese Unterscheidung ist mir wichtig, weil es bei den nützlichsten KI-Workflows selten nur darum geht, schneller Code zu schreiben. Es geht darum, den Assistenten mit dem richtigen Kontext, den richtigen Systemen und den richtigen Randbedingungen zu verbinden, damit die Arbeit näher an der Realität beginnt.
Aber KI hat Engineering nicht auf magische Weise einfach gemacht.
Die nervige Arbeit ist nicht verschwunden. In manchen Fällen hat sie nur das Outfit gewechselt und ist mit besserem Lebenslauf zurückgekommen.
Für mich ist die größte Verschiebung diese:
KI hat das Beginnen und Ausführen von Arbeit deutlich beschleunigt.
Der langsamere Teil ist alles, was danach kommt: die Ausgabe prüfen, die Annahmen verstehen, PRs klein genug halten, um sie reviewen zu können, Dinge in der richtigen Reihenfolge mergen und sicherstellen, dass ich den Code auch zwei Wochen später noch erklären kann.
Genau dort liegt der eigentliche Zielkonflikt.
Vor dem ersten Entwurf
Bevor KI Teil meines Arbeitsalltags wurde, bestand ein Großteil des Engineerings aus Kontextsuche.
Ein normaler Tag begann an vertrauten Orten. Slack. Jira. Zugewiesene Aufgaben. Confluence. Interne Dokumentation. Tool-Dokumentation. Framework-Dokumentation. Dann, je nachdem, wie schnell die Dinge aus dem Ruder liefen, Google, Stack Overflow, Reddit, GitHub Issues und schließlich ein:e Kolleg:in, dem oder der das Gleiche vielleicht schon begegnet war.
Manchmal wurde daraus Pair Programming. Manchmal eine Debugging-Session. Manchmal zwei Stunden Herumprobieren, die ich später als „Untersuchung“ bezeichnete, was technisch stimmt und emotional großzügig ist.
Das galt besonders früher in meiner Karriere, als ich mich hauptsächlich auf Frontend-Engineering konzentrierte. Der Wechsel vom Frontend in Backend, Datenbanken und Full-Stack-Arbeit kostete echte Zeit. Ich musste neue Systeme, neue Frameworks, neue Fehlermodi und neue Arten von Kontext lernen.
React veränderte sich. Tooling veränderte sich. Bibliotheken veränderten sich. NPM-Pakete ließen sich aus Gründen nicht installieren, die sich persönlich anfühlten.
Ein großer Teil der Arbeit war nicht nur Code schreiben. Es war, genug Kontext zu bekommen, um den richtigen Code zu schreiben.
Und manchmal war der langsamste Teil der Aufgabe alles, was vor der ersten echten Codezeile passierte.
Die Geschwindigkeit des Anfangens
KI hat diesen ersten Schritt dramatisch verändert.
Heute kann ich mit MCP und verbundenen Tools relevanten Kontext viel schneller bekommen. Statt manuell zwischen Slack, Confluence, Jira, internen Dokus, Web-Dokumentation und der Codebasis hin- und herzuspringen, kann ich die KI bitten, diese Informationen zusammenzutragen und zu synthetisieren.
Deshalb ist MCP auch über den Anwendungsfall „KI schreibt Code“ hinaus interessant. MCP gibt Assistenten einen strukturierteren Weg, mit den Tools und Systemen zu arbeiten, in denen die echte Arbeit ohnehin stattfindet. Zum Beispiel unterstützt Webflows Developer-Plattform MCP, damit Agenten aus Tools wie Claude, Cursor, Postman oder anderen MCP-kompatiblen Clients mit Webflow-Workflows arbeiten können.
Für mich ist das eine viel nützlichere Version von KI als ein leeres Chatfenster. Es ist nicht einfach ein Assistent, der von außen rät. Es ist ein Assistent, der näher am tatsächlichen Workflow arbeiten kann, mit klarerem Kontext und relevanteren Aktionen.
Wenn ich ein neues Feature beginne, kann ich nach dem Kontext rund um das Ticket fragen, nach verwandten Gesprächen, ähnlichen Implementierungen, relevanten Dateien, früheren Entscheidungen und den Randbedingungen, die ich kennen sollte, bevor ich den Code anfasse.
Das nimmt mir nicht das Nachdenken ab.
Es nimmt mir einen Großteil der manuellen Suche ab, bevor das Nachdenken beginnen kann.
Dieser Unterschied zählt. Im Engineering gibt es viel unsichtbare Zeit, die nicht genau Coding, aber auch nicht genau Planung ist. Es ist die Zeit, in der man versucht zu verstehen, was bereits passiert ist, was jemand in einem Ticket meinte, warum ein System auf eine bestimmte Weise funktioniert oder ob das, was man gleich bauen will, unter anderem Namen schon existiert.
KI ist sehr gut darin, diese Reibung zu verringern.
Sie kann lange Threads zusammenfassen. Sie kann unbekannte Codepfade erklären. Sie kann Ansätze vergleichen. Sie kann helfen, verstreuten Kontext in eine erste brauchbare Karte zu verwandeln.
Die Karte muss ich trotzdem prüfen. Aber zumindest beginne ich nicht in der Wildnis mit einem Jira-Ticket und einem Traum.
Wenn die Ausführung leichter wird
Die nächste große Verschiebung ist die Ausführung.
KI hat es viel leichter gemacht, von „Ich habe keine Ahnung, wo ich anfangen soll“ zu „Ich habe einen funktionierenden ersten Entwurf“ zu kommen.
Dieser erste Entwurf kann eine Feature-Implementierung sein, ein Test, eine Datenbankabfrage, ein Skript, eine Migration, ein Splunk-Dashboard oder eine AWS-bezogene Änderung. Er kann Frontend, Backend, Infrastruktur, Observability oder eine unbequeme Kombination aus allem sein, weil Software Humor hat.
Das hat verändert, welche Arbeit ich übernehmen kann.
Full-Stack-Arbeit wirkt zugänglicher. Infrastrukturarbeit wirkt weniger einschüchternd. Migrationen lassen sich leichter durchdenken. Dashboards, Abfragen und unbekannte Systeme fühlen sich nicht mehr wie Mauern an, die ich erklimmen muss, bevor ich vorankomme.
KI verleiht einem nicht magisch Expertise. Aber sie kann die Distanz zwischen Blockiertsein und Nützlichsein verkürzen.
Das war für mich besonders wertvoll als jemand, der im Frontend angefangen hat und in breitere Full-Stack-Arbeit hineingewachsen ist. Früher bedeutete der Einstieg in einen neuen Bereich oft, lange nur das Vokabular des Problems zu lernen. Jetzt kann ich früher bessere Fragen stellen. Ich bekomme schneller Beispiele. Ich kann eine erste Version generieren, sie prüfen, hinterfragen und daraus lernen.
Die Lernkurve ist noch da.
KI macht sie nur weniger einsam.
Testen ist ein gutes Beispiel. Ich möchte nicht, dass dieser Artikel zum Liebesbrief ans Testen wird, denn das wäre verdächtig. Aber KI hat Tests schneller schreibbar und leichter debuggbar gemacht. Sie kann Mocks erzeugen, Fälle vorschlagen, an die ich nicht gedacht hätte, bestehende Tests aktualisieren und beim Durchdenken von Fehlschlägen helfen.
Ich muss weiterhin sicherstellen, dass die Tests aussagekräftig sind. Eine bestandene Test-Suite ist nur nützlich, wenn sie das richtige Verhalten testet. Aber KI hat die Mechanik beschleunigt, was mir mehr Raum gibt, über Abdeckung nachzudenken, statt einen halben Nachmittag mit der Form eines Mock-Objekts zu kämpfen.
Ein kleiner Sieg, aber ein echter.
Nach dem ersten Entwurf
Das Problem ist, dass Software-Engineering nicht beim ersten Entwurf endet.
Dort beginnen meist die interessanten Probleme, die leise hinter einer bestandenen Test-Suite und einem sehr selbstsicheren Assistenten warten.
Hier beginnt KI, mich auszubremsen.
Eine generierte Lösung kann korrekt aussehen. Sie kann kompilieren. Sie kann Tests bestehen. Sie kann sogar sauber geschrieben sein. Doch das heißt nicht automatisch, dass sie die richtige Lösung für die Codebasis, das Produkt oder das Team ist.
Das Modell trifft möglicherweise Annahmen. Es übersieht vielleicht eine Randbedingung. Es wählt womöglich ein Muster, das isoliert vernünftig aussieht, aber nicht dazu passt, wie das System tatsächlich funktioniert. Es löst vielleicht ein größeres Problem als das, das ich hatte. Es führt womöglich eine Abstraktion ein, die heute elegant wirkt und bis Donnerstag unnötig ist.
Vor KI floss ein Großteil meiner Zeit in die Erstellung der ersten Version: suchen, lesen, fragen, ausprobieren, debuggen, neu schreiben.
Jetzt kann KI diese erste Version dramatisch verdichten.
Aber dann muss ich sie verifizieren.
Ich muss den generierten Code lesen, wie ich die Arbeit eines anderen reviewen würde. Ich muss verstehen, warum er bestimmte Entscheidungen getroffen hat. Ich muss die Randfälle prüfen. Ich muss sicherstellen, dass die Tests nicht nur bestehen, sondern nützlich sind. Ich muss bestätigen, dass die Implementierung zur bestehenden Architektur passt. Ich muss unnötige Änderungen entfernen.
Ich muss fragen, ob das die kleinste vernünftige Lösung ist oder ob der Assistent die Küche umbauen wollte, weil ich ihn gebeten habe, eine Glühbirne zu wechseln.
Diese Review-Arbeit zählt.
Wenn ich sie überspringe, spart KI mir keine Zeit. Sie erzeugt künftige Arbeit mit besserer Formatierung.
Der neue Engpass
KI verschiebt Zeit von der Erstellung zur Verifikation.
Das kann ein guter Tausch sein. In vielen Fällen ist er es. Ich bewerte lieber länger eine Lösung, als auf eine leere Seite zu starren oder sechs Tabs zu durchsuchen, um mich zu erinnern, welches GitHub-Issue zu meiner Fehlermeldung passte.
Aber Verifikation ist trotzdem Arbeit.
Sie erfordert Urteilsvermögen, Kontext und Disziplin. Sie erfordert zu wissen, wie „gut“ aussieht. Sie erfordert, das System gut genug zu verstehen, um zu entscheiden, ob die generierte Lösung dorthin gehört.
Der am schnellsten generierte Code ist nicht immer der Code, der sich am schnellsten verantworten lässt.
Das ist für mich eine der wichtigsten Lektionen geworden. Wenn ich den Code nicht erklären kann, gehört er mir nicht wirklich. Wenn ich den Zielkonflikt nicht verteidigen kann, sollte ich ihn nicht ausliefern. Wenn ich ihn später nicht debuggen kann, hat KI mir keine Zeit gespart. Sie hat Zeit aus der Zukunft geliehen, und mein zukünftiges Ich ist von dieser Vereinbarung selten beeindruckt.
Das ist der Teil des KI-gestützten Engineerings, der weniger glamourös wirkt als die Demos.
Die Demo endet, wenn der Code erscheint.
Die Arbeit geht weiter, wenn ihn jemand warten muss.
Zu viel anfangen
Es gibt einen weiteren Engpass, den ich nicht erwartet hatte: Work in Progress.
KI macht es leichter, Arbeit zu beginnen. Viel leichter. Ich kann eine Idee erkunden, eine erste Implementierung generieren, Tests erstellen und einen PR schneller öffnen als früher.
Das ist mächtig.
Aber Arbeit zu beginnen ist nicht dasselbe, wie sie abzuschließen.
Wenn das Erzeugen von Arbeit billiger wird, wird es leichter, zu viel davon zu erzeugen. Plötzlich gibt es mehr Branches, mehr PRs, mehr Review-Anfragen und mehr Änderungen, die von anderen Änderungen abhängen. Manche PRs müssen in einer bestimmten Reihenfolge landen. Manche brauchen Kontext, der in einem anderen Branch lebt. Manche sind für sich klein genug, doch zusammen bilden sie eine Warteschlange, die das Team noch prüfen, verstehen und mergen muss.
Der Engpass verschiebt sich von „Kann ich das bauen?“ zu „Können wir das sicher aufnehmen?“
KI kann die individuelle Ausführung beschleunigen, aber Software wird weiterhin durch Teams ausgeliefert.
Das heißt, Koordination zählt weiterhin. Review zählt weiterhin. Reihenfolge zählt weiterhin. Kleine PRs zählen weiterhin. Tatsächlich zählen sie jetzt vielleicht sogar mehr, weil die Kosten, zu viel Arbeit zu erzeugen, gesunken sind.
Das ist einer der seltsameren Effekte von KI. Sie kann mich produktiver fühlen lassen und zugleich mehr unfertige Arbeit um mich herum erzeugen.
Mehr Bewegung ist nicht immer mehr Fortschritt.
Manchmal bedeutet Fortschritt kleinere PRs, klarere Reihenfolge, weniger parallele Branches und genug Disziplin, das zu Ende zu bringen, was ich schon begonnen habe, bevor ich die KI bitte, mir bei drei weiteren zu helfen.
Was sich tatsächlich verändert hat
KI spart mir Zeit, wenn sie mir hilft, Kontext zu finden, Informationen zu synthetisieren, ein Gerüst für eine Lösung zu bauen oder die erste Version der Arbeit auszuführen.
Das ist auch die Version von KI, die sich am stärksten an dem orientiert, worauf wir bei Webflow hinarbeiten: KI, die mit echten Workflows, echten Produktoberflächen und echten Publishing-Systemen verbunden ist. Der Wert liegt nicht nur darin, dass ein Assistent schnell etwas generieren kann. Der Wert liegt darin, dass er Menschen helfen kann, mit weniger manuellem Aufwand von Kontext über Kreation bis zum Ausliefern zu kommen und dabei Raum für menschliches Urteilsvermögen und Verantwortung zu lassen.
Sie bremst mich aus, wenn der schwierige Teil nicht mehr das Erzeugen von Code ist, sondern das Verifizieren, Sequenzieren, Reviewen und Verantworten.
Dieser Tausch lohnt sich.
Mit KI bin ich viel schneller als ohne. Ich kann in mehr Bereichen des Stacks arbeiten. Ich komme schneller aus Blockaden heraus. Ich kann Dinge bauen, für die ich früher deutlich länger gebraucht hätte. Ich verbringe weniger Zeit mit der Jagd nach Kontext und mehr mit Entscheidungen.
Aber KI hat die schwierigen Teile des Engineerings nicht beseitigt.
Sie hat sie verschoben.
Die Arbeit dreht sich weniger darum, von einer leeren Seite zu starten, und mehr darum zu wissen, wie „gut“ aussieht. Weniger darum, jedes Stück Kontext manuell zusammenzusetzen, und mehr darum zu validieren, ob das zusammengesetzte Bild stimmt. Weniger darum, jede Zeile selbst zu tippen, und mehr darum, jede Zeile zu verantworten, die man ausliefert.
Das ist die Version von KI im Engineering, die sich für mich echt anfühlt.
Keine Magie. Kein Ersatz. Keine Abkürzung am Urteilsvermögen vorbei.
Ein sehr schneller Assistent, der mir viel Zeit spart, solange ich nicht vergesse, dass ich weiterhin der Engineer bin, der für das Ergebnis verantwortlich ist.
