{"id":70887,"date":"2026-10-15T08:06:21","date_gmt":"2026-10-15T06:06:21","guid":{"rendered":"https:\/\/www.cubeserv.com\/?p=70887"},"modified":"2026-10-15T13:05:51","modified_gmt":"2026-10-15T11:05:51","slug":"agentic-engineering-teil-2-der-neue-arbeitsalltag-wenn-ai-agenten-das-programmieren-uebernehmen","status":"publish","type":"post","link":"https:\/\/www.cubeserv.com\/de\/agentic-engineering-teil-2-der-neue-arbeitsalltag-wenn-ai-agenten-das-programmieren-uebernehmen\/","title":{"rendered":"Agentic Engineering Teil 2: Der neue Arbeitsalltag, wenn AI-Agenten das Programmieren \u00fcbernehmen"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Bild wurde mit Hilfe von AI generiert<\/em><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Was passiert, wenn die AI \u00fcber Nacht arbeitet?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Die Szene, mit der Teil 1 unserer Blogserie<\/a> begann, ist schnell erz\u00e4hlt: Ein Agent arbeitet \u00fcber Nacht an einer Aufgabe. Am n\u00e4chsten Morgen meldet er \u201efertig\u201c, eine \u00c4nderung wartet auf Freigabe. Auf den ersten Blick scheint die Arbeit erledigt.<\/p>

Was dabei leicht aus dem Blick ger\u00e4t: Jemand musste vorher das Ziel beschreiben und die Grenzen festlegen. Nun muss jemand pr\u00fcfen, ob die \u00c4nderung fachlich richtig ist, zum bestehenden System passt und die Anforderungen erf\u00fcllt. Die Meldung \u201efertig\u201c ersetzt diese Pr\u00fcfung nicht.<\/strong><\/p>

Genau darum geht es in diesem Teil: wie sich der Arbeitsalltag von Entwicklern ver\u00e4ndert, wenn Agenten die Umsetzung \u00fcbernehmen.<\/strong> Auftr\u00e4ge formulieren, Pl\u00e4ne beurteilen, R\u00fcckfragen kl\u00e4ren und Ergebnisse pr\u00fcfen – all das wird wichtiger. Der Agent \u00fcbernimmt mehr Arbeit, die Verantwortung bleibt beim Entwicklerteam.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Die eigentliche Arbeit beginnt vor dem Code<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Um zu verstehen, wo Agenten entlasten k\u00f6nnen, lohnt sich ein Blick auf die gesamte Entwicklungsarbeit: das Problem verstehen, L\u00f6sungswege suchen, Ans\u00e4tze bewerten, ausprobieren, Code schreiben, testen und Fehler beheben. Das Schreiben des Codes ist nur ein Teil davon.<\/strong><\/p>\n

Eine Antwort auf Stack Overflow oder ein Beispiel aus der Dokumentation ist noch keine passende L\u00f6sung. Entscheidend ist, ob der Ansatz die Anforderungen erf\u00fcllt, zum bestehenden System passt und sich langfristig warten l\u00e4sst. Auch eine bew\u00e4hrte Vorgehensweise eignet sich nicht automatisch f\u00fcr jedes Projekt.<\/p>\n

Erst beim Ausprobieren zeigt sich, ob eine Idee tr\u00e4gt. Daf\u00fcr m\u00fcssen Entwickler einen Ansatz aufbauen, ausf\u00fchren und das Ergebnis pr\u00fcfen. Manches funktioniert technisch, l\u00f6st aber nicht das eigentliche Problem. Dazu kommt die Fehlersuche: Manchmal ist die Ursache in wenigen Minuten gefunden, manchmal dauert schon das Eingrenzen mehrere Stunden.<\/p>\n

Stellt sich dabei heraus, dass der gesamte L\u00f6sungsansatz nicht tr\u00e4gt, beginnt die Suche erneut. Eine Alternative muss gefunden, bewertet und erprobt werden. Der verworfene Versuch liefert zwar Erkenntnisse, hat aber Zeit gekostet. Im fertigen Code ist dieser Aufwand kaum sichtbar.<\/p>\n

Genau beim Suchen, Ausprobieren und Pr\u00fcfen k\u00f6nnen AI-Agenten entlasten.<\/strong> Sie k\u00f6nnen L\u00f6sungswege recherchieren, Varianten umsetzen, Tests ausf\u00fchren und anhand der Ergebnisse nachbessern. Der Entwickler muss dadurch nicht jeden Versuch selbst aufbauen. Er muss aber weiterhin beurteilen, ob die vorgeschlagene L\u00f6sung tats\u00e4chlich zum eigenen System passt.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Dieselbe Arbeit, andere Handgriffe<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Wer regelm\u00e4\u00dfig mit AI-Agenten arbeitet, setzt im Entwicklungsalltag andere Schwerpunkte. Ein Arbeitstag kann damit beginnen, die Ergebnisse eines n\u00e4chtlichen Agentenlaufs zu pr\u00fcfen. Dazu kommen neue Auftr\u00e4ge und die Abstimmung von Pl\u00e4nen und R\u00fcckfragen w\u00e4hrend der Umsetzung. Statt jede \u00c4nderung selbst zu schreiben, liest der Entwickler den entstandenen Code, bewertet Testergebnisse und steuert nach, wenn etwas nicht passt.<\/p>\n

Suchen, Bewerten und Ausprobieren – all das erledigt sich dadurch nicht. Der Agent \u00fcbernimmt einen Teil dieser Arbeit, der Entwickler hinterfragt die Ergebnisse. Entscheidend ist nicht nur, ob eine L\u00f6sung funktioniert, sondern ob ihre Annahmen stimmen und sie zum bestehenden System passt.<\/strong> Daf\u00fcr bleibt technisches Verst\u00e4ndnis unverzichtbar. Ob diese Arbeitsteilung tats\u00e4chlich Zeit spart, h\u00e4ngt auch davon ab, wie viel Anleitung, Pr\u00fcfung und Nacharbeit n\u00f6tig bleibt.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Bild wurde mit Hilfe von AI generiert<\/em><\/p>\n

Auch Andrej Karpathy betont, dass Entwickler die Grundlagen ihrer Systeme weiterhin verstehen m\u00fcssen. Er unterscheidet drei Ans\u00e4tze: Verhalten durch klassischen Code festlegen (Software 1.0<\/strong>), durch das Training neuronaler Netze erlernen lassen (Software 2.0<\/strong>) und Sprachmodelle \u00fcber Prompts und Kontext steuern (Software 3.0<\/strong>). Diese Ans\u00e4tze erg\u00e4nzen sich, statt einander vollst\u00e4ndig zu ersetzen. F\u00fcr die Arbeit mit Coding-Agenten hei\u00dft das: Entwickler m\u00fcssen nicht jedes Detail einer Schnittstelle auswendig kennen. Sie m\u00fcssen aber erkennen k\u00f6nnen, welche Annahmen hinter einer L\u00f6sung stehen und welche Folgen eine \u00c4nderung f\u00fcr das System hat<\/strong> (vgl. Andrej Karpathy, 2026<\/a>).<\/p>\n

Die Aufgaben bleiben \u00e4hnlich, ihre Gewichtung ver\u00e4ndert sich:<\/p>\n<\/colgroup>
<\/th>

Klassische Entwicklung<\/p><\/th>

Agentengest\u00fctzte Entwicklung<\/p><\/th><\/tr>

Schwerpunkt der Arbeit<\/p><\/td>

L\u00f6sungen selbst implementieren und pr\u00fcfen<\/p><\/td>

Aufgaben strukturieren, Umsetzung delegieren und pr\u00fcfen<\/p><\/td><\/tr>

Technisches K\u00f6nnen<\/p><\/td>

Systeme verstehen und L\u00f6sungen umsetzen<\/p><\/td>

Systeme verstehen und Agentenergebnisse beurteilen<\/p><\/td><\/tr>

Qualit\u00e4tssicherung<\/p><\/td>

Tests, Code-Review und funktionale Pr\u00fcfung<\/p><\/td>

Dieselben Ma\u00dfst\u00e4be, zus\u00e4tzlich Annahmen und \u00c4nderungen des Agenten hinterfragen<\/p><\/td><\/tr><\/tbody><\/table>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Wenn \u201efertig\" nicht gleich fertig ist<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Wenn ein Agent wiederholt lauff\u00e4higen Code und gr\u00fcne Tests liefert, w\u00e4chst das Vertrauen. Das kann dazu verleiten, \u00c4nderungen schneller zu \u00fcbernehmen und weniger genau hinzusehen. Doch ein bestandener Test best\u00e4tigt nur das, was er tats\u00e4chlich pr\u00fcft.<\/strong> Ob die L\u00f6sung auf den richtigen Annahmen beruht, ist damit noch nicht gekl\u00e4rt.<\/p>\n

Andrej Karpathy beschreibt das am Beispiel seiner Anwendung MenuGen: Ein Agent wollte ein gekauftes Guthaben anhand der E-Mail-Adresse beim Zahlungsanbieter Stripe dem passenden Google-Konto zuordnen. Der Ansatz wirkte plausibel. Nutzer k\u00f6nnen f\u00fcr die Zahlung allerdings eine andere E-Mail-Adresse verwenden als f\u00fcr die Anmeldung. Dann erreicht das Guthaben m\u00f6glicherweise nicht das richtige Konto. Die Zuordnung braucht deshalb eine stabile Nutzer-ID, die den Kauf eindeutig mit dem Nutzerkonto verbindet (vgl. Andrej Karpathy, 2026<\/a>).<\/p>\n

Der Fehler lag im Entwurf, nicht in der Syntax.<\/strong> Ein Test mit identischen E-Mail-Adressen f\u00fcr Zahlung und Anmeldung w\u00fcrde den problematischen Fall nicht abdecken. Daf\u00fcr m\u00fcsste gezielt mit unterschiedlichen Adressen gepr\u00fcft werden. Welche F\u00e4lle wichtig sind, ergibt sich aus den Anforderungen und Regeln des Produkts, nicht allein aus dem erzeugten Code. Der Agent kann Tests schreiben und ausf\u00fchren. Das Entwicklerteam bleibt daf\u00fcr verantwortlich, ihre Aussagekraft zu beurteilen und das Ergebnis zu pr\u00fcfen.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

So f\u00fchrt man einen Agenten<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Wirksame Kontrolle bedeutet nicht, jeden Schritt des Agenten zu begleiten. Entscheidend ist, vor der Umsetzung die Richtung abzustimmen, bei Problemen einzugreifen und anschlie\u00dfend das Ergebnis zu pr\u00fcfen. Daf\u00fcr hilft ein Ablauf aus vier Phasen: Explore, Plan, Implement und Review<\/strong>, also Verstehen, Planen, Umsetzen und Pr\u00fcfen. Auch Anthropic empfiehlt, Erkundung und Planung von der Umsetzung zu trennen und dem Agenten M\u00f6glichkeiten zur Ergebnispr\u00fcfung zu geben (vgl. Anthropic, o. J.<\/a>).<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Erst verstehen. Dann bauen<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Zun\u00e4chst untersucht der Agent den Code, die Schnittstellen und die vorhandenen Tests, die f\u00fcr seine Aufgabe relevant sind. Welche Funktionen gibt es bereits? Welche Regeln gelten? Wo w\u00fcrde die \u00c4nderung eingreifen? Am Anwendungscode wird dabei noch nichts ver\u00e4ndert. Ziel ist nicht, das gesamte Projekt einzulesen, sondern die Aufgabe im bestehenden System zu verstehen.<\/strong> Fehlen entscheidende Informationen, sollte der Agent nachfragen, statt die L\u00fccken stillschweigend mit Annahmen zu f\u00fcllen.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Der Plan gibt die Richtung vor<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Lassen Sie den Agenten vor gr\u00f6\u00dferen \u00c4nderungen erkl\u00e4ren, wie er vorgehen will. Ein Auftrag kann lauten:<\/p>\n

Erkl\u00e4re mir deinen L\u00f6sungsansatz, welche Dateien du \u00e4ndern m\u00f6chtest und wie du das Ergebnis pr\u00fcfen wirst. Benenne offene Fragen. Noch nichts umsetzen.<\/p><\/blockquote>\n

Ein gepr\u00fcfter Plan hilft, eine falsche Richtung zu erkennen, bevor daraus umfangreiche \u00c4nderungen entstehen.<\/strong> Entscheidend ist, dass der Plan verst\u00e4ndlich macht, was ge\u00e4ndert werden soll und warum.<\/p>\n

Claude Code unterst\u00fctzt diese Trennung mit dem Plan Mode<\/strong>. In der Terminaloberfl\u00e4che wechseln Sie mit Shift+Tab durch die verf\u00fcgbaren Modi, bis er angezeigt wird. Der Agent kann dann den Code untersuchen und einen Umsetzungsplan erstellen, ohne den Anwendungscode zu ver\u00e4ndern (vgl. Anthropic, o. J.<\/a>).<\/p>\n

Auch Boris Cherny, der Claude Code entwickelt hat, beschreibt diesen Ablauf: Er beginnt die meisten seiner Sessions im Plan Mode, stimmt den Plan mit dem Agenten ab und wechselt erst danach zur Umsetzung (vgl. Boris Cherny, 2026<\/a>).<\/p>\n

Bei der Pr\u00fcfung helfen drei Fragen: Hat der Agent das Ziel richtig verstanden? Sind die \u00c4nderungen auf das Notwendige begrenzt? Pr\u00fcfen die vorgesehenen Tests die Anforderungen? Unbegr\u00fcndet viele \u00c4nderungen, fehlende Pr\u00fcfschritte oder unklare Annahmen sind Gr\u00fcnde, den Plan zun\u00e4chst \u00fcberarbeiten zu lassen.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Den Agenten arbeiten lassen<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Nach der Freigabe setzt der Agent den Plan innerhalb des vereinbarten Rahmens um. Er liest bei Bedarf weiteren Code, nimmt \u00c4nderungen vor und f\u00fchrt Pr\u00fcfungen aus. Schl\u00e4gt ein Test fehl, wertet er die R\u00fcckmeldung aus, korrigiert seine L\u00f6sung und pr\u00fcft erneut. Dieses Umsetzen, Pr\u00fcfen und Korrigieren bildet die interne R\u00fcckschleife des Agenten.<\/strong><\/p>\n

Nicht jeder Durchlauf braucht einen menschlichen Eingriff. Der Auftrag sollte deshalb nicht nebenbei durch immer neue W\u00fcnsche ver\u00e4ndert werden. Fehlt eine fachliche Entscheidung, weicht der Agent deutlich vom Plan ab oder wiederholt er erfolglose Versuche, ist eine Unterbrechung sinnvoll. Dann werden Ursache und weiteres Vorgehen gekl\u00e4rt. \u00c4ndern sich Ziel oder Umfang der Aufgabe, muss auch der Plan angepasst werden.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Das Ergebnis pr\u00fcfen<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Nach dem Lauf braucht das Ergebnis drei getrennte Pr\u00fcfungen:<\/p>\n