Journal

Persönliche Notizen, Gedanken und Artikel über Technik, Arbeit und Ideen.

2026-04-16•Yevhen Kim

techaiAI-Assisted Developmentpipeline

Warum Ihre Deployment-Pipeline zu Ihrem Wettbewerbsvorteil wird

KI macht wirklich schneller. 41% des Codes 2025 kam von KI-Tools. Teams, die sie nutzen, mergen 98% mehr Pull Requests als vor einem Jahr. Das ist gemessen, das passiert jetzt.

Aber das ist der Knackpunkt: Wenn Code-Generierung schneller wird, fließt das nicht gleichmäßig durch Ihr System. Der Druck konzentriert sich auf das langsamste Element. Für die meisten Teams: Code Review.

Ein Team, das seine Metriken verfolgt: PR-Volumen +98%. Zeit pro Review gleich geblieben. Ein Senior Engineer überprüft KI-Code genauso lange wie menschlichen Code. Rechnung kaputt. Sie haben doppelt so viele PRs, die gleiche Anzahl Menschen, und Code Review stoppt jetzt das Shipping.

Der Druck geht weiter. Mehr Code in Production = mehr testen. Größere Angriffsfläche. Veracode hat gemessen: 45% des KI-Codes führt OWASP-Lücken ein. CodeRabbit zeigt: KI-Code schlägt 1,7x häufiger fehl. Wenn Ihre Tests das fangen, perfekt – Sie haben Zeit zu reparieren. Sonst macht es Fehler in Produktion.

Das ist es, was DORA 2025 sagt: KI ist ein Multiplikator. Keine Egalisierung. Verstärkt das, was Sie ohnehin haben. Starke Teams mit echtem Testing und schnellem Deployment werden stärker. Teams mit schwacher Infrastruktur scheitern deutlich sichtbar.

Warum die Konkurrenz das jetzt macht

Die Tech Leads, mit denen ich rede, sehen KI-Tools gleich: Produktivitätswerkzeug. Lizenzen verteilen, Engineers schreiben schneller, mehr Code raus. Schnelligkeitsproblem gelöst.

Falsch. Das Problem ist nicht gelöst. Nur woanders hin verschoben.

Die Teams, die wirklich schneller liefern, haben nicht die besten KI-Modelle. Sie haben einen CI, der unter zehn Minuten läuft. Der deployt ohne Theater. Der überwacht und erwischt Fehler. Das sind die Teams, die in das investiert haben, das alle dachten, wäre längst erledigt: Test-Infrastruktur, sichere Deployments, Observability.

Als Code noch der Engpass war, konnten Sie Testing optional haben. Manuelles Deployment war okay. Code Review holte die Fehler, weil Code selten und kostbar war. Jetzt ist Code überall. Alles, das früher optional war, ist jetzt kritisch.

Der Wettbewerbsvorteil sitzt nicht im Tool. In der Infrastruktur, die das alles tatsächlich aushält.

Was Sie tun können

Schauen Sie sich Ihre Pipeline an. Nicht theoretisch. Zahlen. Wie lange läuft die Test-Suite? Wie sieht's beim Security Scanning aus? Wie viele Bugs erwischen Sie, bevor sie in Produktion gehen?

Dann: Was bricht, wenn Code-Volumen sich verdoppelt?

Ist es Code Review – hören Sie auf zu denken, dass Senior Engineers einfach mehr überprüfen. Parallelisieren, automatisieren, lassen Sie Menschen die Architektur machen. Ist es Testing – Ihre Test-Suite war zu dünn und ist es immer noch. Sie brauchen parallele Tests, bessere Metriken, andere Strategien. Mehr Integration, weniger Unit Tests einigen Stellen.

Ist es Deployment – schneller und sicherer machen, damit Sie das öfter können.

Kann sein, Sie stellen anders ein. Infrastruktur-Engineers statt mehr Entwickler. Sie investieren in Tools, die keine Features haben, nur validieren, testen, deployen.

Und Sie könnten entscheiden, dass nicht all das Tempo wert ist. Team kann Code schreiben, aber nicht sicher deployen? Der Code im Branch hilft niemandem.

Die Teams, die ich kenne und die gerade mit KI gewinnen? Feiern nicht Code-Geschwindigkeit. Besessen von Deployment-Geschwindigkeit. Haben verstanden: Wenn Input schneller wird, wird alles danach sichtbar. Reparieren statt akzeptieren.

Das ist der Vorteil. Nicht das bessere Modell. Infrastruktur, die funktioniert.

Quellen

2026-04-14•Yevhen Kim

techaiAI-Assisted Development

KI in der Entwicklung ist kein Zusatz mehr — sie wird zur Basisschicht

Ein paar Jahre lang war KI in der Entwicklung schnell beschrieben: Code vervollständigen, Boilerplate vorschlagen, ein paar Minuten im Editor sparen, gelegentlich ein brauchbarer Hinweis.

Diese Phase ist vorbei.

Im Jahr 2026 ist die wichtigste Veränderung nicht, dass KI schneller Code schreibt. Sie hört nicht mehr beim Schreiben auf. Sie arbeitet heute durch den gesamten Weg einer Änderung: Kontext sammeln, einen Plan vorschlagen, Code bearbeiten, Änderungen prüfen, Sicherheits- und Qualitätsrisiken markieren, Korrekturen empfehlen, die Arbeit an den automatisierten Veröffentlichungsprozess übergeben.

Sobald KI auf mehreren Etappen einer Änderung beteiligt ist, ist sie kein Komfortwerkzeug mehr. Sie wird Teil davon, wie das Team tatsächlich arbeitet.

GitHub hat das Ende 2025 sichtbar gemacht, als es KI, Agenten und typisierte Sprachen als Kräfte beschrieb,

die die größten Verschiebungen in der Softwareentwicklung seit mehr als einem Jahrzehnt antreiben.

Was dort zählt, ist nicht die Formulierung. Es ist, was dahintersteht: Der Markt behandelt KI nicht mehr als Nebentool. Sie wird zunehmend als Teil der Engineering-Grundlage gesehen.

Zur selben Zeit änderte sich auch Copilots Code-Review-System. Weg vom Modell, bei dem KI nur Kommentare hinterlässt, hin zu einer Kombination aus LLM-Analyse, Tool Calls und regelbasierten Prüfungen, die konsistente Ergebnisse liefern. GitHub beschreibt es als

Erkennung von Problemen durch ein großes Sprachmodell, den Aufruf externer Werkzeuge und konsistente regelbasierte Prüfungen durch Werkzeuge wie ESLint und CodeQL.

KI schlägt keinen Text mehr vor. Sie arbeitet mit den Werkzeugen zusammen, die Teams ohnehin zur Code-Inspektion nutzen.

Dasselbe gilt für den Copilot Cloud Agent, der ein Repository untersuchen, einen Umsetzungsplan erstellen, Änderungen in einem separaten Branch vornehmen und zur Review vorbereiten kann. GitHub nennt ihn

einen autonomen und asynchronen Agenten für die Softwareentwicklung.

KI wartet also nicht mehr im Editor auf den nächsten Befehl. Sie kann eine klar abgegrenzte Aufgabe übernehmen, mehrere Schritte durchlaufen und das Ergebnis in den normalen Review-Prozess zurückgeben. Das ist der eigentliche Inhalt von "agentischen Workflows" — kein neues Label für altes Autocomplete, sondern der Übergang von einer einzelnen Reaktion zur mehrstufigen Beteiligung.

Wenn das passiert, verändern sich auch die Fragen, die Teams stellen müssen.

"Sollten wir KI nutzen?" hat aufgehört, interessant zu sein. In 2026 ist auch "Welches Modell bevorzugen wir?" schon die falsche Ebene. Die nützlichere Frage ist, wie gut KI in Code-Review, Tests, Release-Vorbereitung, Sicherheit und Qualitätskontrolle eingebunden ist.

Denn sobald KI den ganzen Weg vom Entwurf zur fertigen Änderung mitgeht, optimiert man nicht mehr für Geschwindigkeit. Man optimiert für Kontrolle.

Ohne Kontrolle beschleunigt KI nur das Rauschen.

Eine mittelmäßige Anforderung wird schneller zur sauber verpackten Änderung. Eine fragile Architekturentscheidung landet früher im System. Eine schwache Annahme hält länger durch, weil Prototypen billig geworden sind. Ein Review-Prozess, der schon vorher Dinge übersehen hat, übersieht sie nun schneller.

Deshalb beschreiben die stärksten aktuellen Untersuchungen KI nicht als etwas, das Engineering automatisch reif macht. DORA hat es 2025 auf ein Wort gebracht:

ein Verstärker.

KI stärkt gute Systeme und vergrößert Probleme in schwachen. Teams mit echter Lieferdisziplin, soliden Tests und klaren Standards bekommen mehr heraus. Teams mit schwachen Grundlagen bekommen nicht mehr Reife — sie bekommen schnellere Instabilität.

Die praktischen Folgen sind konkret.

Code-Review wird zu einem gemischten System: KI markiert Auffälligkeiten, regelbasierte Checks bestätigen oder verwerfen sie, Menschen entscheiden, was wirklich riskant ist. Die Aufgabe verschiebt sich vom Querlesen zum Managen von Signal und Eskalation. CI/CD kann sich nicht mehr auf "Build starten" beschränken — wenn KI Änderungen erzeugen, korrigieren und weiterreichen darf, muss die Pipeline Absichten prüfen, Verhalten testen und die Fehler erkennen, die ein Modell überzeugend übersehen kann. Repo-Qualität wird dabei zum echten Eingabeparameter: Je besser Dokumentation, Architekturgrenzen und Tests innerhalb eines Projekts, desto weniger Chaos entsteht, wenn KI autonom arbeitet.

Auch das Bild des starken Entwicklers ändert sich. Die besten stehen heute nicht nur hervor, weil sie schneller liefern, sondern weil sie besser wissen, was sie an KI übergeben, was sie einschränken, was sie von Hand prüfen, und wo ihre eigene Aufmerksamkeit scharf bleiben muss — unabhängig davon, was das Modell vorschlägt.

GitHub hat die Richtung klar beschrieben:

Copilot war früher ein Werkzeug zur Autovervollständigung. Heute ist es ein vollwertiger KI-Assistent, der mehrstufige Arbeitsabläufe ausführen kann.

Wenn KI am System teilnimmt statt nur im Editor zu assistieren, brauchen Teams ein anderes Niveau an Disziplin: klare Regeln im Repository, starke automatisierte Tests, einen verlässlichen Review-Prozess vor dem Merge, Sicherheits-Tools im Lieferpfad, dokumentierte Architekturgrenzen, explizite Vorgaben dafür, was KI autonom tun darf und was nicht.

Ob KI in die Softwareentwicklung gehört, ist keine offene Frage mehr.

Offen ist, ob Teams sie als losen Trick für Geschwindigkeit behandeln oder als etwas, das denselben Anspruch erfordert wie jeder andere kritische Teil des Prozesses. KI in der Entwicklung ist kein Zusatz mehr. Sie ist auf dem Weg, Grundlage zu werden. Die Teams, die dabei gut abschneiden, werden nicht die sein, die am meisten Code erzeugen — sondern die, die wissen, was um diese Erzeugung herum gebaut werden muss.

Quellen

2026-04-13•Yevhen Kim

techcreativity

Kreativität in der Softwareentwicklung hat nichts mit Inspiration zu tun, sondern mit der Qualität von Entscheidungen

Über Kreativität in der Softwareentwicklung wird oft zu vage gesprochen. Inspiration. Ungewöhnliche Ideen. Die Fähigkeit, „außerhalb der Box” zu denken. Für technische Arbeit sagt das wenig aus.

Entscheidend ist nicht, ob eine Lösung originell aussieht, sondern ob sie stärker ist: präziser in Bezug auf die Aufgabe, stabiler in der Weiterentwicklung des Systems, leichter zu warten. In der Technik beweist Neuheit für sich genommen nichts. Sie zählt nur dann, wenn sie das Ergebnis verbessert.

Darum beginnt Kreativität nicht mit der Antwort, sondern mit der Art, wie das Problem definiert wird. Ein starker Engineer sucht nicht einfach innerhalb eines vorgegebenen Rahmens nach einer Lösung — zuerst prüft er, ob der Rahmen selbst überhaupt stimmt. Forschung zum Problem Framing zeigt, dass erfahrene Praktiker Probleme eher hinterfragen und neu rahmen, während weniger erfahrene sie häufiger so lösen, wie sie ursprünglich formuliert wurden. In der Softwareentwicklung ist genau das oft der entscheidende Unterschied. Viele teure Lösungen entstehen, weil zu früh die falsche Frage gestellt wurde.

Schwache Kreativität fixiert sich auf die erste verständliche Version der Aufgabe und arbeitet dann innerhalb zufälliger Grenzen mit großem Einsatz weiter. Starke Kreativität macht zuerst etwas anderes: Sie prüft, ob das Team überhaupt auf der richtigen Ebene arbeitet. Vielleicht muss das Problem nicht mit mehr Komplexität gelöst werden. Vielleicht muss es neu formuliert werden. Vielleicht ist der beste Schritt, die Quelle der Komplexität ganz zu entfernen, statt den bestehenden Ansatz zu verbessern.

Reale Systeme existieren unter Druck: Zeit, Kosten, Rückwärtskompatibilität, Legacy-Architektur, operatives Risiko. Kreativität ist keine Flucht vor diesen Einschränkungen. Sie ist die Fähigkeit, besser mit ihnen zu arbeiten als andere. Einschränkungen sind nicht der Gegner einer starken Lösung — sie sind das Material, aus dem sie geformt wird.

Und Kreativität in der Entwicklung ist untrennbar mit Zielkonflikten verbunden. Es gibt kein reales System, in dem man gleichzeitig maximale Flexibilität, minimale Kosten, perfekte Einfachheit und null Wartungsrisiko bekommt. Ein reifer Ansatz versucht nicht, Zielkonflikte zu vermeiden — er geht präziser mit ihnen um. Forschung zu Design-Trade-offs zeigt, dass starke Praktiker nicht nur die am wenigsten schlechte Option in einem festen Lösungsraum wählen. Sie verändern oft den Lösungsraum selbst — definieren das Problem so um, dass ein Teil des ursprünglichen Konflikts verschwindet.

Eine der stärksten Formen von Kreativität in der Entwicklung ist Vereinfachung: eine Schicht entfernen statt eine hinzuzufügen, eine enge und präzise Lösung heute wählen statt standardmäßig „universell für die Zukunft” zu bauen, eine Form wählen, die den realen Betrieb überlebt, statt auf Folien zu beeindrucken.

Schwache Kreativität produziert Komplexität. Sie mag Konstruktionen, die klug aussehen. Starke Kreativität produziert Klarheit — reduziert unnötige Entitäten, Abhängigkeiten und Ausnahmen. Das Ziel ist nicht, mit der Konstruktion zu beeindrucken. Das Ziel ist, die Qualität des Systems zu verbessern.

In einer guten Engineering-Umgebung wirkt Kreativität selten romantisch. Sie ist kein Geistesblitz am Whiteboard. Sie ist eine Folge präziser Schritte: die Frage neu stellen, bemerken, wo das Team sich zu früh auf die erste Option festgelegt hat, eine elegante, aber teure Architektur ablehnen, einen Zielkonflikt wählen, der im Betrieb gut altert.

Kreativität ist auch keine rein individuelle Eigenschaft. Forschung zu IS-Entwicklungsteams zeigt, dass sie aus dem Zusammenspiel von Menschen, Struktur und Aufgabe entsteht — nicht aus dem Kopf eines „brillanten Einzelnen”, der allein arbeitet. Teams können das Framing hinterfragen und Annahmen überarbeiten — oder sie können es nicht. Das hängt vom Umfeld ab. Selbst ein starker Engineer verliert Spielraum in einem System, das nur die schnelle Umsetzung der zuerst akzeptierten Idee belohnt.

Mit der Verbreitung generativer KI wird das deutlicher. Routine-Implementierung wird billiger — und damit rückt menschliches Urteilsvermögen stärker in den Mittelpunkt. Neuere Forschung zur KI in der Softwareentwicklung hält fest: Programmieren ist nicht dasselbe wie Software Engineering, und menschliches Urteil und Anpassungsfähigkeit bleiben zentral. Wenn ein erster Entwurf schnell entsteht, wird die Wahl der richtigen Richtung wichtiger, nicht nebensächlicher. Schnellerer Code bedeutet auch: Die Rechnung für eine falsche Idee kommt schneller.

Eine schwache Idee wird nicht mehr nur langsam umgesetzt. Sie kann jetzt schnell über Services, Workflows und Schnittstellen ausgerollt werden. Eine falsche Architekturannahme vervielfacht sich mit derselben Beschleunigung, die Lieferung produktiv aussehen lässt. Ein schlechtes Problemverständnis kann rasch in große Mengen überzeugend wirkenden Codes übersetzt werden. KI reduziert die Bedeutung von Kreativität nicht. Sie macht die Anforderungen an sie höher.

Kreativität in der Softwareentwicklung ist keine dekorative Eigenschaft und kein angenehmer Bonus neben der „eigentlichen” Ingenieursarbeit. Sie ist Teil reifen technischen Urteils. Sie zeigt sich darin, wie jemand das Problem definiert, mit Einschränkungen arbeitet, Zielkonflikte behandelt und eine interessante Idee von einer wirklich starken Lösung unterscheidet.

In diesem Sinn hat Kreativität nichts mit Inspiration zu tun.

Sie hat mit der Qualität von Entscheidungen zu tun.

Mit der Fähigkeit, den stärkeren Weg zu erkennen, bevor das System Zeit hat, um den schwächeren herumzuwachsen.

Quellen

2026-04-12•Yevhen Kim

techaisecurity

Im Zeitalter von AI muss Sicherheit über den gesamten Weg von der Idee bis zum Release eingebaut werden

Noch vor Kurzem bedeutete AI in der Entwicklung vor allem eines: Geschwindigkeit. Eine Funktion schneller schreiben. Eine Testversion schneller bauen. Eine Aufgabe schneller abschließen.

Das reicht nicht mehr.

Was heute zählt, ist eine andere Frage: Wie sicher ist das, was dabei entsteht — und wie gut geschützt ist der gesamte Weg, den Code, Bibliotheken und externe Komponenten nehmen, bevor sie im Produkt landen.

Das Problem ist längst nicht mehr theoretisch

Das Risiko ist real.

Veracode hat Codebeispiele getestet, die mit AI-Hilfe entstanden sind, und festgestellt: 45 % bestanden die Sicherheitsprüfungen nicht und enthielten gefährliche Schwachstellen. Noch beunruhigender: Neuere und größere Modelle verbesserten diese Zahl nicht. (veracode.com)

Das stellt die Frage anders.

Code, der mit AI-Hilfe entstand, lässt sich nicht mehr nur nach zwei Kriterien beurteilen: Funktioniert er — und wie schnell wurde er geschrieben? Es gibt ein drittes:

Bringt er ein Risiko ins System, das das Team zu spät erkennt.

Warum „bessere AI” das nicht löst

Die Versuchung ist verständlich: Die nächste Modellgeneration wird klüger sein und automatisch sicherer schreiben. In der Praxis funktioniert das nicht so.

AI beurteilt Systeme nicht wie ein erfahrener Ingenieur. Sie trägt keine Verantwortung für das Produkt, spürt nicht, was ein Fehler im Betrieb kostet, und haftet nicht für die Folgen. Sie liefert die statistisch wahrscheinlichste Variante — nicht die vorsichtigste.

Bessere Modelle bedeuten also noch keine höhere Sicherheit. Die Daten von Veracode belegen das direkt. (veracode.com)

AI kann das Schreiben von Code beschleunigen. Sie hebt aber nicht die Notwendigkeit von Skepsis, Prüfung und Sicherheitsdisziplin auf.

Warum die Sicherheitsfrage über den Code hinausgeht

In einem echten Produkt besteht eine Änderung fast nie nur aus neuem Code. Mit ihr kommen Bibliotheken, externe Abhängigkeiten, Skripte, Build-Werkzeuge, automatisierte Prüfungen, Container, Fremddienste — alles, was der Code passiert, bevor er in Produktion geht.

Die Frage ist also nicht nur, ob der Code sicher ist. Sondern ob der gesamte Auslieferungsweg es ist.

OWASP macht das explizit: Software durchläuft eine ganze Kette aus Erstellung, Build, Test und Auslieferung, und Fehler können überall auf diesem Weg entstehen, nicht nur im Code selbst. (owasp.org) (owasp.org)

Für AI macht das drei Dinge besonders relevant.

1. AI bringt Änderungen schneller ins Projekt

Wer schneller schreibt, holt Bibliotheken und Fremdkomponenten schneller ins Projekt. Und alles, was darin steckt. Wer dabei nicht mitbekommt, was da wirklich landet, verliert schnell den Überblick.

2. Sieht fertig aus. Ist es nicht.

Ein schneller Blick auf den Code sagt kaum etwas. Die Datenverarbeitung kann schlampig sein, Berechtigungen zu weit gefasst, die Validierungslogik nur für den Normalfall ausgelegt. Das fällt im Diff nicht auf. Wird genehmigt.

3. Auch die AI-Schicht selbst gehört zur Risikozone

Sobald ein Team AI in die Entwicklung einbaut, weitet sich die Risikozone über den Code hinaus aus. Dazu gehören Modelle, Plugins, Agenten, automatisierte Prüfungen, externe Integrationen — der gesamte Prozess, über den AI beeinflusst, was ausgeliefert wird.

Das Risiko liegt nicht nur darin, was AI geschrieben hat. Sondern darin, wie AI in den Weg von der Idee zum Release eingebaut ist.

Ein „kluger Kommentar” reicht nicht

2025 hat GitHub explizit geschrieben, dass Copilot Code Review jetzt LLM-Analyse, externe Tool-Aufrufe und regelbasierte Prüfungen über ESLint und CodeQL kombiniert. (github.blog)

Das ist kein Zufall. Einer der wichtigsten Akteure in diesem Bereich setzt nicht darauf, dass AI den Code liest und das reicht.

Das heißt: statische Analyse, Abhängigkeitsprüfungen und jemand, der den Diff vor der Genehmigung wirklich liest.

Ein AI-Kommentar reicht nicht aus, auch wenn er überzeugend klingt.

Was das für Websites und Webanwendungen bedeutet

Jedes Ergebnis, das AI geliefert hat, muss denselben vollständigen Sicherheitsweg durchlaufen wie Code, den ein Mensch geschrieben hat.

Nicht vereinfacht. Nicht „das ist ja nur ein Entwurf”. Nicht „das prüfen wir später”. Denselben Weg.

Das bedeutet mindestens Folgendes.

Sicherheit muss von Anfang an eingebaut sein

Sicherheit, die erst am Ende dazukommt, ist keine Sicherheit — sie ist eine Prüfung, die regelmäßig übersprungen wird. OWASP ist klar: Sicherheit muss durch den gesamten Entwicklungsprozess laufen, von Design bis Release. (owasp.org)

Für AI-Code ist das direkt: Wenn Sicherheit nicht im Prozess steckt, bringt die Geschwindigkeit von AI Risiken nur schneller in Produktion.

Automatische Prüfungen sind keine Option

Statische Analyse, Linter, Abhängigkeitsprüfungen und technische Filter sind keine Extras — sie sind der Mindeststandard. Deshalb baut GitHub Code Review um Werkzeuge wie CodeQL und ESLint, statt auf AI allein zu setzen. (github.blog)

Externe Komponenten müssen geprüft werden

Abhängigkeiten sind eine der wichtigsten Angriffsflächen bei Webanwendungen. OWASP empfiehlt: Komponentenverzeichnis pflegen, Regeln für Abhängigkeiten setzen, Herkunft von Artefakten prüfen, Build-Prozess kontrollieren. (owasp.org)

Menschliche Prüfung bleibt notwendig

AI kann auffällige Stellen markieren. Aber die fachliche Einschätzung kann nicht an eine Maschine abgegeben werden — besonders nicht bei Zugriffsrechten, Eingabeverarbeitung, externen Integrationen, Nutzerdaten oder Verhalten in Ausnahmesituationen.

Der gefährlichste Fehler: Sicherheit als etwas behandeln, das später dazukommt

In 2026 ist das keine Naivität mehr. Es ist eine schlechte Wette.

DORA beschreibt AI in seinem Bericht als Verstärker: Sie stärkt starke Systeme und macht die Schwachstellen schwacher sichtbarer. Die Teams, die wirklich profitieren, sind nicht die, die AI am schnellsten eingeführt haben — sondern die, die sie in ein Engineering-System mit Prüfungen, Tests und Verantwortlichkeit eingebettet haben. (dora.dev)

AI senkt die Anforderungen an Sicherheit nicht. Sie erhöht den Preis dafür, sie zu ignorieren.

Was Reife in 2026 bedeutet

Code, der mit AI-Hilfe entstand, gilt nicht standardmäßig als sicher. Er bekommt dieselbe kritische Prüfung wie jeder andere Code — vielleicht mehr.

Kein AI-Ergebnis umgeht die üblichen Prüfschritte: Sicherheit im Prozess, automatische Analyse, Abhängigkeitsprüfungen, Tests, menschliche Prüfung.

Risiken werden breit betrachtet — nicht nur im Code, sondern auch in Bibliotheken, Werkzeugen, Automatisierung, externen Integrationen und der AI-Schicht selbst.

Geschwindigkeit und Sicherheit werden getrennt bewertet. Wenn AI eine Änderung beschleunigt hat, heißt das nicht, dass sie sicherer geworden ist.

Sicherheit ist Teil des Auslieferungssystems, keine Abschlusskontrolle kurz vor dem Release.

Fazit

AI hat nicht nur die Produktivität beschleunigt — sie hat auch die Rate beschleunigt, mit der schwache Entscheidungen, gefährliche Muster und riskante Abhängigkeiten ins Produkt gelangen. Codesicherheit und Supply-Chain-Sicherheit können deshalb nicht am Rand des Entwicklungsprozesses bleiben.

In 2026 das als Problem anderer zu behandeln — des Security-Teams, der nächsten Modellgeneration, des nächsten Sprints — ist nur eine andere Form, es nicht anzugehen.

Es ist eine Grundbedingung, um auf diesem Niveau zu arbeiten.

Quellen

2026-04-11•Yevhen Kim

techai

KI macht Entwickler nicht kleiner. Sie legt nur offen, worauf es wirklich ankommt.

Es gibt dieses einfache Argument, das man gerade dauernd hört: Wenn KI Code schreiben kann, dann wird der Entwickler automatisch weniger wichtig. Klingt schlüssig. Ist aber nur dann schlüssig, wenn man den Job auf Tippen reduziert. Und genau das war bei Softwareentwicklung noch nie die ganze Wahrheit.

Code schreiben ist ein Teil der Arbeit. Klar. Aber eben nicht der Kern von allem.

Der eigentliche Wert steckt meistens woanders: das Problem richtig verstehen, fehlenden Kontext bemerken, zwischen zwei mittelmäßigen Optionen die weniger schlechte wählen, Unsinn früh erkennen, bevor er sich im System festfrisst. Genau da trennt sich gute Entwicklung von bloßer Produktion. Und genau da hilft KI nicht einfach "anstelle des Menschen". Sie verschiebt nur, wo man genau hinschauen muss.

Eine Microsoft-Studie mit 860 Entwicklern passt ganz gut dazu. Die Aussage ist im Grunde simpel: Nur ein relativ kleiner Teil des Arbeitstags geht überhaupt fürs eigentliche Schreiben von Code drauf, obwohl viele KI-Tools fast nur dafür gebaut wirken. Das allein müsste einem schon zu denken geben.

Wenn also ausgerechnet dieser Teil schneller oder billiger wird, dann heißt das nicht, dass der Entwickler kleiner wird. Es heißt nur, dass die bequemen Teile kleiner werden.

Und ehrlich: Viel davon wird niemand vermissen. Boilerplate, Testgerüste, Routineumbauten, all das Zeug, das man macht, aber nicht liebt. Wenn KI das beschleunigt, gut. Der Punkt ist nur: Die schwierigen Teile verschwinden nicht. Sie treten eher deutlicher hervor.

Was jetzt stärker zählt, ist Richtung. Nicht bloß Output.

Was jetzt stärker zählt, ist Urteilsvermögen. Nicht bloß Geschwindigkeit.

Was jetzt stärker zählt, ist die Fähigkeit zu merken, dass ein Vorschlag zwar ordentlich aussieht, aber inhaltlich trotzdem schief ist.

Genau deshalb finde ich die aktuelle Debatte oft etwas schräg. Viele reden so, als ob schneller erzeugter Code automatisch denselben Wert hätte wie gute technische Entscheidungen. Hat er nicht. Ein Modell kann dir in Sekunden einen brauchbar aussehenden Ausschnitt liefern. Es kann dir genauso schnell etwas hinstellen, das auf den ersten Blick vernünftig wirkt und dir später die Architektur aufweicht.

Das ist ja das Tückische daran: KI produziert oft Dinge, die plausibel aussehen. Und Plausibilität wird im Alltag leicht mit Qualität verwechselt.

Deshalb steigen die Anforderungen an Entwickler eher, als dass sie sinken.

Kontext wird wichtiger. Wer den besseren Kontext liefert, bekommt meist auch die besseren Ergebnisse.

Prüfen wird wichtiger. Schneller Output macht Nachdenken nicht optional.

Architektur wird wichtiger. Wenn Implementierung billiger wird, werden Fehler auf Systemebene teurer.

Und auch der Prozess wird wichtiger. Wenn Teams mit Tools wie Copilot schneller durch Teile der Umsetzung gehen, dann darf Review nicht lockerer werden, sondern eher strenger. Sonst verteilt man denselben Mist wie früher, nur effizienter.

Ich glaube deshalb schon länger nicht mehr an die alte Idee, ein guter Entwickler sei vor allem jemand, der besonders viel Code besonders schnell von Hand produzieren kann. Das war vorher schon ein schwaches Modell. Jetzt wirkt es einfach nur noch alt.

Die eigentliche Frage ist heute nicht mehr, ob KI Code schreiben kann. Natürlich kann sie das. Die wichtigere Frage ist: Wer kann mit dieser Geschwindigkeit umgehen, ohne unsauber zu werden? Wer kann Aufgaben sinnvoll delegieren, ohne dabei das Denken mit abzugeben? Wer schützt noch die Form des Systems, wenn alles drumherum schneller wird?

Genau dort wird der gute Entwickler gebraucht.

Nicht weniger als vorher. Eher mehr.

Nur anders. Strenger. Mit weniger Ausreden.

Quellen

2026-04-10•Yevhen Kim

techcode

Warum es heute nicht mehr reicht, einfach nur gut Code zu schreiben

Guter Code bleibt wichtig.

Saubere Umsetzung. Technische Disziplin. Urteilsvermögen. Sorgfältige Arbeit an produktiven Systemen. Die Fähigkeit, keine künftigen Probleme einzubauen. Das alles bleibt notwendig.

Aber guter Code allein reicht nicht mehr.

Ein Team kann ein Feature schnell, sauber und technisch elegant liefern. Trotzdem löst es das falsche Problem. Es baut über. Es lenkt Aufwand falsch oder erzeugt ein System, das auf der Umsetzungsebene beeindruckend aussieht, auf der Ebene des Ergebnisses aber schwach ist.

Deshalb haben sich die Anforderungen verschoben.

Der Markt belohnt nicht mehr nur den mit dem saubersten Code. Er belohnt zunehmend den Ingenieur, der einem Team hilft, bessere Entscheidungen zu treffen: wo vereinfacht werden sollte, wo das Briefing infrage gehört, wo die Architektur geschützt werden muss, wo Scope gekürzt werden sollte, und wo ein technisch schöner Weg einfach zu teuer ist.

Das ist die echte Veränderung.

Breiter Kontext galt lange als zusätzliche Stärke. Ein Ingenieur, der das Produkt verstand, Kompromisse früh erkannte und starke Fragen stellte—das war ein Plus.

Das ist jetzt eine normale Erwartung.

Moderne Software lebt nicht isoliert. Eine Entscheidung hier beeinflusst die Kosten künftiger Änderungen, Teamgeschwindigkeit, Belastbarkeit, Support-Aufwand und Nutzererfahrung. In dieser Umgebung ist guter Code nötig. Aber er erklärt nicht mehr allein, was einen starken Ingenieur ausmacht.

Starke Ingenieure werden immer noch nach ihrer Umsetzungsqualität beurteilt. Aber eben auch nach Wirkung, Urteilsvermögen und Entscheidungsqualität unter Grenzen. Sehen sie, wenn ein Problem schlecht gerahmt ist? Erkennen sie, wenn ein Feature mehr Komplexität als Wert erzeugt? Verstehen sie, wenn ein Team Aktivität statt Nutzen optimiert? Können sie vereinfachen, ohne das System zu schwächen? Können sie widersprechen, bevor teure Dynamik zur Roadmap wird?

Hier zeigt sich Engineering-Reife. Manchmal in der Architektur, manchmal in der Fähigkeit, eine Schicht zu entfernen statt eine neue hinzuzufügen, manchmal darin, eine elegante Lösung abzulehnen, weil die Wartungskosten zu hoch wären. Und manchmal darin, zu sehen, dass das eigentliche Problem gar nicht in der Umsetzung liegt, sondern in der Definition der Aufgabe.

Das war früher das Unterscheidungsmerkmal. Heute wird es zur Grunderwartung.

KI macht das sichtbarer. Wenn Routinetätigkeiten automatisiert werden, sinkt der relative Wert des mechanischen Codierens. Er verschwindet nicht, aber als Wettbewerbsvorteil wird er kleiner.

Wertvoller wird das, was sich schwerer automatisieren lässt: Kontext verstehen, eine Aufgabe richtig rahmen, die richtigen Grenzen wählen, Wichtiges von Nebensächlichem trennen, und unter Unsicherheit reife Kompromisse treffen.

Die Forschung zeigt genau dorthin. Eine Microsoft-Studie aus 2026 zeigt, dass Entwickler nur etwa ein Zehntel ihres Tages tatsächlich Code schreiben. Die meisten KI-Werkzeuge konzentrieren sich aber auf genau diese zehn Prozent. Eine andere Studie zu GenAI zeigt die größten Gewinne in Design, Implementierung, Testing und Dokumentation. Gleichzeitig verlagert sich die Wertschöpfung zu Spezifikationsqualität, architektonischem Denken und Oversight. Je schneller also die Mechanik wird, desto offensichtlicher wird, wer wirklich urteilen kann.

KI beschleunigt nicht nur gute Arbeit. Sie beschleunigt auch schwache Entscheidungen. Eine schlechte Anforderung wird jetzt schneller zu einer glatt wirkenden Umsetzung. Eine flache Feature-Idee kann länger überleben, weil Prototyping billig ist. Ein Team kann Bewegung mit Fortschritt verwechseln, weil Output schnell erscheint und überzeugend aussieht.

KI verringert also nicht die Rolle des starken Ingenieurs. Sie legt offen, was diese Rolle schon immer enthalten musste.

Nicht nur gut Code schreiben. Verstehen, was gebaut werden sollte. Erkennen, was gestrichen werden sollte. Sehen, wo Komplexität nicht gerechtfertigt ist. Und technische Tiefe mit echten Ergebnissen verbinden.

Deshalb sollten Produktdenken, Kreativität und der Umgang mit Unsicherheit nicht mehr als externe Elemente betrachtet werden. Sie sind Teil von Engineering-Arbeit. Nicht statt technischer Tiefe, sondern zusammen mit ihr.

Guter Code bleibt Pflicht. Aber allein beantwortet er nicht mehr die Frage nach professionellem Wert. Immer mehr hängt davon ab, über die eigene unmittelbare Umsetzung hinauszusehen: zu verstehen, was wirklich zählt, wo ein Kompromiss nötig ist, wo das Briefing infrage gehört und wo weniger Komplexität die stärkere Entscheidung ist.

Ein wirklich starker Ingenieur verbindet Umsetzungsqualität mit Produktverständnis, technische Tiefe mit praktischer Wirkung und professionelle Sicherheit mit reifen Entscheidungen.

Was einen Ingenieur früher deutlich abhob, wird zunehmend zur Grunderwartung.

Quellen

2025-11-02•Yevhen Kim

techai

Vom Aufgabenausführer zum Mitgestalter des Produkts

Lange funktionierte Softwareentwicklung nach einem einfachen Muster: Das Produktteam formuliert die Aufgabe, das Engineering setzt sie um.

Dieses Modell war nie falsch. Geschwindigkeit, technische Tiefe, Zuverlässigkeit und saubere Umsetzung bleiben wichtig. Daran hat sich nichts geändert.

Geändert hat sich etwas anderes: Als vollständige Beschreibung dessen, wo Engineering heute Wert schafft, reicht dieses Modell nicht mehr aus.

Dieser Wandel ist nicht in jeder Firma gleich weit. Es gibt weiterhin Organisationen, in denen Ingenieure vor allem Anforderungen erhalten und umsetzen. Aber in Startups, stärkeren Produktteams und KI-geprägten Umfeldern ist die Marktbewegung klar: Vom Engineering wird immer häufiger erwartet, nicht nur am Wie mitzuwirken, sondern auch daran, ob die gewählte Richtung überhaupt trägt.

Zu oft hängt der Erfolg nicht nur davon ab, wie gut eine Lösung gebaut ist, sondern davon, ob die gewählte Richtung überhaupt stimmt. Der teuerste Fehler entsteht immer häufiger nicht im Code. Er entsteht früher — in schwacher Produktlogik, in oberflächlichem Marktverständnis, in überschätztem Nutzerwert oder in einer groben Unterschätzung der Kosten von Komplexität.

Genau deshalb wird ein starker Ingenieur heute nicht nur bei der Umsetzung wertvoll. Er wird wertvoll schon früher — dort, wo ein Team den eingeschlagenen Kurs noch infrage stellen kann.

In Startups war das schon immer sichtbarer. Dort ist der Abstand zwischen Idee, Produkt und Umsetzung kürzer. Ingenieure sind oft näher an der eigentlichen Grundlage der Entscheidung: an der Hypothese, am Nutzwert, an den Marktgrenzen. An dem Punkt, an dem eine Funktion entweder real hilft oder nur in einem Pitch überzeugend klingt.

In solchen Umfeldern wird sehr schnell klar: Gute Umsetzung rettet keinen schwachen Ausgangsgedanken.

Ein technisch starkes Produkt kann trotzdem am Markt vorbeigehen. Nicht weil das Team schwach ist. Nicht weil die Entwicklung schlecht war. Manchmal waren die Annahmen über Nutzer, Timing, Nachfrage oder Produktwert von Anfang an falsch. Das wird erst sichtbar, wenn sich das Team bereits auf Roadmap und Ziele festgelegt hat.

Sobald Ziele fixiert sind, fließen Tickets und Liefergeschwindigkeit wird zum zentralen Maßstab. Dann verwandelt sich Entwicklung leicht in hochwertige Ausführung eines fragwürdigen Kurses.

Genau hier verändert sich die Rolle des Ingenieurs.

Der Unterschied zwischen einem Aufgabenausführer und einem Mitgestalter des Produkts ist nicht rhetorisch. Er ist praktisch.

Ein Aufgabenausführer bekommt eine Formulierung und konzentriert sich auf die Umsetzung.

Ein Mitgestalter des Produkts schaut eine Ebene früher hin: Welches Problem lösen wir eigentlich? Warum genau diesen Weg und keinen anderen? Für wen ist das relevant? Was kostet diese Entscheidung über die Zeit? Erzeugen wir Komplexität dort, wo der reale Wert zu klein ist, um sie zu rechtfertigen?

Das ist kein Ersatz für Produktmanagement. Es ist Teil reifer Engineering-Arbeit.

Ein starker Ingenieur bringt nicht nur technische Optionen ein, sondern auch deren Folgen. Er sieht, wo eine scheinbar vernünftige Funktion langfristige Reibung erzeugt. Er erkennt, wann eine Roadmap auf Annahmen aufbaut, die noch gar nicht belastbar genug sind. Er merkt, wenn ein Team die Liefergeschwindigkeit um eine schwache Prämisse herum optimiert.

Anders gesagt: Er hilft nicht nur dabei, etwas richtig zu bauen. Er hilft dabei, zu vermeiden, dass das Falsche mit großer Disziplin gebaut wird.

Moderne Produktarbeit bewegt sich immer stärker in genau diese Richtung. Produktentwicklung wird funktionsübergreifender, stärker von Discovery geprägt und abhängiger von schnellen Lernschleifen zwischen Kundenbedarf, Geschäftsentscheidungen und technischen Grenzen.

In so einem Umfeld ist Engineering nicht bloß nachgelagerter Empfänger von Anforderungen. Es ist eine der Funktionen, die mitprägen, welche Anforderungen überhaupt berechtigt sind.

Gerade jetzt ist das besonders wichtig, weil KI die Kosten mechanischer Umsetzung zusammendrückt.

Prototypen lassen sich schneller zusammenbauen. Abläufe können früher getestet werden. Erste Implementierungen entstehen schneller. Dokumentation, Boilerplate und routinemäßige Umwandlungen kosten weniger Aufwand als früher. Diese Geschwindigkeit ist nützlich — aber sie verändert die Ökonomie schlechter Entscheidungen.

Wenn Produktion billiger wird, skaliert schwache Produktlogik schneller. Wenn Prototyping leichter wird, überleben flache Ideen länger, als sie sollten — sofern niemand sie herausfordert. Wenn Teams schneller werden, steigt auch der Preis, in die falsche Richtung schneller zu laufen.

KI macht den Ingenieur für Produktdenken also nicht weniger relevant. Sie macht diesen Beitrag schwerer zu übersehen.

Wenn routinemäßige Umsetzung billiger wird, verschiebt sich der Wert hin zu Urteilsvermögen. Das Problem richtig zu verstehen. Grenzen zu sehen, bevor sie zu Fehlern werden. Signal von bloßer Bewegung zu unterscheiden. Einen starken Kompromiss zu wählen. Zu erkennen, wann scheinbarer Fortschritt in Wahrheit nur beschleunigte Verschwendung ist.

Genau deshalb wird das alte Bild vom Entwickler als hochqualifiziertem Empfänger von Aufgaben zu klein.

Es ist nicht so, dass Umsetzung weniger zählt. Es ist so, dass Umsetzung allein nicht mehr genug erklärt.

In vielen Teams wird heute vom Ingenieur erwartet, an der Formung der Lösung mitzuwirken — nicht als politischer Machtanspruch und nicht als künstliche Rollenausweitung, sondern als professionelle Antwort darauf, wie Produktentwicklung unter Geschwindigkeit, Unsicherheit und permanenter Iteration tatsächlich funktioniert.

Dieser Wandel ist kein modisches Statusupgrade. Er ist eine strukturelle Folge moderner Softwarearbeit.

Je komplexer Produkte werden, je schneller Lieferzyklen werden und je billiger mechanische Umsetzung wird, desto wertvoller wird der Ingenieur, der nicht nur den Code, sondern auch die Entscheidung hinter dem Code stärker machen kann.

So sieht Rollenmaturität heute aus:

nicht nur gut bauen, sondern dem Team helfen, das Richtige präziser zu bauen.

Quellen