Vibe Coding: Seit Monaten schreibe ich keine Zeile Code mehr. So orchestriere ich KI-Agenten rund um die Uhr

Vibe Coding im Entwickler-Alltag: Seit Monaten schreibe ich keine Zeile Code mehr selbst. Stattdessen halte ich KI-Agenten dauerhaft am Laufen, mit Loops, Hotspot am Handy und Laptop im Auto, im Garten und beim Spazieren.

Ich tippe seit Monaten keinen produktiven Code mehr. Keine Funktion, kein Refactor, kein CSS-Fix, den ich selbst geschrieben hätte. Was ich stattdessen den ganzen Tag mache: Agenten starten, füttern, stoppen, neu anstoßen, parallel laufen lassen, und das System, das sie steuert, immer ein bisschen schärfer machen.

Klingt erstmal nach Marketing-Geschwätz, ist aber mein Alltag als Softwareentwickler im Jahr 2026. Und der sieht merkwürdiger aus, als ich ihn mir vor zwei Jahren vorgestellt hätte. Ich schleppe dauernd einen Laptop mit mir herum. Am Handy läuft fast immer ein Hotspot. Der Rechner liegt im Auto, steht im Garten, kommt mit auf den Spaziergang. Nicht, weil ich unbedingt überall arbeiten will. Die Agenten sollen einfach nicht einschlafen.

In diesem Artikel geht es darum, was Vibe Coding in der Praxis ist, wie das Orchestrieren von KI-Agenten den Job des Entwicklers verändert hat, was Agent Loops sind, wie du sie baust, und warum AI-first Development plötzlich nach Hardware, Akkus und Mobilfunk klingt.

Was ist Vibe Coding?

Vibe Coding ist Softwareentwicklung, bei der du die Absicht vorgibst und ein Coding-Agent den Code schreibt. Du beschreibst das Ziel, die Constraints, den Stil. Der Agent liest das Repo, ändert Dateien, führt Tests aus, committet. Du steuerst nur, ob die Richtung stimmt.

Der Begriff ist 2025 durch Andrej Karpathy bekannt geworden: Du hängst dich in den Flow, du „vibest“ mit dem Modell, du hörst auf, jedes Semikolon selbst zu setzen. Viele haben das als Spielerei abgetan. Bei mir ist es die normale Arbeitsweise geworden, und zwar im Produktionsbetrieb, nicht in irgendeiner Demo.

Vibe Coding ist auch nicht „ChatGPT, schreib mir eine Funktion“. Das ist Pair Programming mit Copy-Paste. Richtiges agentic coding heißt: Der Agent hat Werkzeuge. Er kann Dateien lesen und schreiben, Terminal-Befehle ausführen, Browser öffnen, Subagents starten, Loops setzen, CI prüfen. Du sitzt nicht mehr dauernd an der Tastatur. Du dirigierst, was passiert.

Drei Stufen, die ich selbst durchlaufen habe:

1. Autocomplete: Tab, Copilot, ein paar Zeilen Vorsprung. Du schreibst noch fast alles selbst.
2. Chat-Coding: Du klebst Fehler in einen Chat, holst Patches zurück, fügst sie ein. Am Diff bist du immer noch selbst dran.
3. Agent Orchestration: Du gibst ein Ziel, der Agent arbeitet Minuten oder Stunden. Du reviewst Ergebnisse, keine Tastenanschläge.

Ab Stufe 3 wird „ich programmiere“ eine ungenaue Beschreibung. Ich orchestriere KI-Agenten. Der Code entsteht trotzdem, nur nicht mehr unter meinen Fingern.

Seit Monaten keine Zeile Code mehr selbst geschrieben

Ich meine das wörtlich, also nicht „fast keine“ und nicht „nur noch die kniffligen Stellen“. Seit Monaten habe ich in produktiven Repos keine Zeile persönlich getippt. Auch keinen Hotfix um 23 Uhr, den ich „schnell selbst mache, weil’s schneller geht“. Genau das geht nämlich nicht mehr schneller.

Der Agent kennt das Repo besser als mein Kurzzeitgedächtnis. Er liest die Tests, die benachbarten Module, die letzten Commits, die Rules, die Skills. Wenn ich selbst anfange zu tippen, bin ich der langsamste Teil der Pipeline. Und ich mache Inkonsistenzen: andere Formatierung, vergessene Edge Cases, ein Fix ohne Test.

Was ich noch tue, und das ist inzwischen der eigentliche Job:

• Ziele formulieren, die ein Agent nicht erraten kann
• Prioritäten setzen, wenn drei Agenten gleichzeitig fertig werden wollen
• Nein sagen, wenn die Lösung technisch elegant und strategisch falsch ist
• Constraints nachschärfen: „kein Scope Creep“, „kein neuer Dependency“, „idempotent“
• Ergebnisse prüfen: Diff, Tests, Live-Seite, SEO, Sicherheit
• Das System verbessern, das die Agenten steuert

Das ist KI-Entwicklung als Alltag, kein Experiment mehr. Es fühlt sich an wie Lead-Entwicklung ohne Junior, der auf eine Review wartet. Der Junior arbeitet sofort, auch nachts, auch während ich mit dem Hund um den Block gehe, solange der Laptop Strom hat und das Handy einen Hotspot offen hält.

Die psychologische Falle: Du fühlst dich untätig, weil du nicht tippst. Produktivität war jahrelang „Zeilen, Commits, Flow-State an der IDE“. Jetzt sind es klare Aufträge, laufende Loops, saubere Handoffs. Wer das nicht umdeutet, öffnet abends die IDE „nur kurz selbst“ und zerstört den Flow, den der Agent gerade aufgebaut hat.

Der Always-On-Alltag: Laptop im Auto, Hotspot am Handy, Agent im Garten

Was in den LinkedIn-Posts über AI Coding Workflows meist fehlt: Die Agenten brauchen eine Session. Eine Session braucht einen Rechner. Ein Rechner braucht Strom, Netz, und dass niemand den Deckel zumacht, als wäre das noch 2019.

Deshalb schleppe ich den Laptop praktisch immer mit. Nicht als Statussymbol, sondern als Laufzeitumgebung. Der Rechner ist weniger „mein Arbeitsgerät“ als ein kleiner Server, den ich mit mir herumtrage, weil die Agenten sonst sterben.

Warum der Agent stirbt, wenn der Laptop einschläft

Ein Coding-Agent in Cursor (oder einem vergleichbaren Agent-IDE-Setup) lebt in einer Session. Terminals laufen. Watcher laufen. Loops warten auf ein Wake-Signal. Sobald der Mac schläft, ist das weg: kein Shell-Tick, kein CI-Check, kein „mach weiter, wenn die Pipeline grün ist“.

Deshalb ist mein Setup ziemlich unromantisch:

• Deckel oft offen oder so konfiguriert, dass Schlafen nicht sofort alles killt
• Netz immer da: WLAN zu Hause, unterwegs fast immer Hotspot am Handy
• Strom immer im Blick: Powerbank, Autoladegerät, Gartensteckdose, Kabelchaos
• Laptop im Auto: nicht zum Arbeiten auf dem Beifahrersitz, sondern damit die Session zwischen zwei Terminen nicht abreißt
• Laptop im Garten: Agent läuft, ich bin draußen, schaue alle paar Minuten auf den Diff statt auf eine leere Datei
• Laptop beim Spazieren: klingt lächerlich, bis du merkst, dass ein 40-Minuten-Loop genau dann fertig wird, wenn du sonst „kurz offline“ gewesen wärst

Ich laufe also mit einem Rucksack herum, in dem ein Rechner Agenten am Leben hält. So sieht always-on AI coding agents in echt aus. Wer Vibe Coding nur als „chillen und prompten“ verkauft, hat entweder kurze Sessions oder lässt den Ops-Teil weg.

Hotspot als Produktionsinfrastruktur

Der Hotspot ist kein Notnagel mehr. Er gehört zum Entwicklungs-Stack. Ohne Netz kein Modell, kein Tool-Call, kein Browser-Check, kein Deploy-Status. Der Flaschenhals ist selten „kann der Agent das?“. Meistens ist es: Hat das Ding gerade 4G, oder ist die Session in einem Funkloch erstickt?

Was ich daraus gelernt habe:

• Hotspot vorher an, nicht erst wenn der Agent hängt
• Akku am Handy ist plötzlich genauso projektkritisch wie der Laptop-Akku
• Kurze Funklöcher sind okay, lange nicht. Loops, die auf Events warten, verpassen sonst den Tick
• Öffentliches WLAN ist für Agent-Sessions mit Repo-Zugang ein schlechtes Geschäft. Ein Hotspot ist kontrollierbarer

Das ist der Satz, den ich nicht erwartet hätte, als ich Softwareentwickler geworden bin: Mein Job hängt daran, dass am Handy ein Hotspot offen ist, damit ein Agent im Garten weiterrefactored.

Was Agent Loops sind und warum ohne sie nichts dauerhaft läuft

Ein Chat ist linear: Du schreibst, der Agent antwortet, fertig. Ein Agent Loop ist ein Wecker für die Session. Nach einem Intervall oder einem Ereignis wacht der Agent wieder auf und arbeitet denselben Auftrag (oder eine Variante) erneut ab.

Ohne Loop bleibt Vibe Coding ein Gespräch. Mit Loop wird daraus ein Prozess. Der Unterschied ist ungefähr der zwischen „ich schaue nach, ob das Deploy durch ist“ und „ein Watcher sagt Bescheid, und der Agent handelt“.

Loops sind die Mechanik hinter KI-Agenten dauerhaft am Laufen halten. Keine Magie, sondern ein Timer, ein Sentinel in der Shell und ein Prompt, der beim Tick wieder ausgeführt wird.

Drei Loop-Typen, die ich wirklich nutze

Typ	Weckt wann	Wofür
Fester Loop	alle 2 / 5 / 15 Minuten	CI pollen, Todos abarbeiten, Agent nicht einschlafen lassen
Dynamischer Loop	Agent wählt das nächste Delay selbst	lange Aufgaben, bei denen starres Polling Verschwendung ist
Event-Loop / Watcher	Datei ändert sich, Pipeline wird grün, Log-Zeile erscheint	Deploy-Checks, Test-Läufe, „mach weiter wenn X fertig ist“

Der feste Loop ist der Einstieg. Der Event-Loop bringt den eigentlichen Gewinn. Dynamisch wird es, wenn der Agent selbst einschätzen kann: In 30 Sekunden lohnt sich das nicht, in 8 Minuten schon.

Wichtig: Ein Loop ist kein zweiter Entwickler. Er ist ein Herzschlag. Wenn der Prompt schlecht ist, bekommst du alle fünf Minuten denselben schlechten Herzschlag. Deshalb kommt nach „Loop bauen“ immer „Prompt härten“.

So baust du Agent Loops (Schritt für Schritt)

Das folgende Setup ist das, womit ich in Cursor arbeite. Das Prinzip gilt auch für andere Agent-IDEs: eine Shell, die im Hintergrund tickt, eine Ausgabe, die den Agenten weckt, und ein Prompt, der sagt, was als Nächstes zu tun ist.

Schritt 1: Mach den Agenten arbeitsfähig, bevor du einen Loop setzt

Ein Loop auf einem blinden Agenten multipliziert Blindheit. Vor dem ersten Loop braucht er:

• Repo-Kontext: Rules, README, wie Tests laufen, was „fertig“ heißt
• Ein klares Done-Kriterium. Nicht „mach SEO“, sondern zum Beispiel „Meta 140-160 Zeichen, FAQ mit h3, interne Links gesetzt“
• Erlaubnis, selbst zu handeln: Dateien ändern, Tests starten, nicht nach jeder Zeile fragen
• Grenzen: keine Secrets committen, kein Force-Push, kein Scope außerhalb des Auftrags

Wenn du das nicht festlegst, orchestriert der Loop Chaos. Vibe Coding ohne Constraints ist nur schnellerer Murks.

Schritt 2: Den ersten festen Loop bauen

Ein fester Loop ist eine Endlosschleife in der Shell, die nach einem Sleep eine eindeutige Zeile ausgibt. Der Agent lauscht auf genau diese Zeile und führt dann den Prompt aus.

while true; do
  sleep 300
  echo 'AGENT_LOOP_TICK_review {"prompt":"Prüfe git status, offene Todos und CI. Arbeite den nächsten klaren Schritt ab. Nicht den Scope erweitern."}'
done

Was daran wichtig ist:

• Eindeutiger Sentinel: AGENT_LOOP_TICK_review darf sonst nirgendwo in Logs vorkommen
• Prompt im Payload: Der Tick allein weckt, der JSON-Prompt sagt, was zu tun ist
• Sofort einmal ausführen: nicht fünf Minuten auf den ersten Herzschlag warten
• Ein Loop pro Zweck: nicht denselben Tick für SEO, Tests und Blogposts missbrauchen

In der Praxis sage ich dem Agenten etwas in der Art: „Loop alle 5 Minuten: offenen Auftrag weiterführen, bis die Checkliste grün ist. Dann stoppen und mir sagen, dass du fertig bist.“

Schritt 3: Von Polling auf Events umsteigen

Fünf-Minuten-Polling ist okay, bis du merkst, dass der Agent die Hälfte der Ticks mit „noch nichts Neues“ verbringt. Dann kommt der Watcher:

# Fallback-Herzschlag, falls kein Event kommt
sleep 600
echo 'AGENT_LOOP_WAKE_ci {"prompt":"CI-Status prüfen. Bei Grün nächsten Schritt, bei Rot Fehler eingrenzen und fixen."}'

Zusätzlich ein Watcher, der nur feuert, wenn sich etwas Relevantes ändert: ein Log wird grün, eine Pipeline ist durch, eine Datei existiert. Der Agent wacht dann auf, weil es sich lohnt, nicht weil die Uhr das so will.

Das ist der Übergang von „KI dauernd nervös machen“ zu „KI dann wecken, wenn Arbeit da ist“. Genau das meint Agent Loops bauen in einem erwachsenen Workflow.

Schritt 4: Mehrere Agenten parallel orchestrieren

Ein Agent ist ein Mitarbeiter. Mehrere Agenten sind ein Team, und Teams brauchen Schnittstellen, sonst überschreiben sie sich die Dateien.

Mein grobes Muster:

• Ein Owner-Agent in der Hauptsession: priorisiert, reviewed, startet Loops
• Subagents für isolierte Jobs: „finde alle internen Links“, „erkläre warum der Test rot ist“, „untersuche nur dieses Modul“
• Keine zwei Schreiber auf derselben Datei. Parallelisieren nach Datei, nach Sprache (DE/EN), nach Schicht (Recherche vs. Patch)
• Handoff schriftlich: Was ist erledigt, was ist offen, welcher Befehl als Nächstes

Orchestrieren heißt hier wörtlich: wer spielt wann welches Instrument. Nicht möglichst viele Modelle gleichzeitig auf denselben Diff hetzen.

Schritt 5: Den Loop wieder stoppen

Ein vergessener Loop ist teuer und dumm. Er verbrennt Tokens, weckt den Agenten in der Nacht und macht „nur noch schnell“-Änderungen an einem fertigen Artikel.

Stop-Regel, die ich Agenten mitgebe:

• Stoppen, wenn die Checkliste erfüllt ist
• Stoppen, wenn du dreimal hintereinander nichts Sinnvolles tun konntest
• Stoppen, wenn der Mensch „stop“ sagt. Dann PID killen und keinen neuen Heartbeat setzen
• Danach kurz sagen: Loop tot, warum, was der letzte sinnvolle Stand war

Schritt 6: Den Loop zur Gewohnheit machen, nicht zum Ritual

Am Anfang fühlte sich jeder Loop wie ein Experiment an. Heute ist es Standard: Auftrag geben, Loop arm, Laptop nicht zuklappen, Hotspot an, weggehen. Wiederkommen, Diff lesen, nachschärfen oder mergen.

Das ist der Kern von als Entwickler keinen Code mehr schreiben, sondern Agenten orchestrieren. Der Loop ist die Schicht zwischen dir und der Tastatur.

Das Orchester: Subagents, Rules, Skills und Hooks

Loops halten den Agenten wach. Das Orchester sorgt dafür, dass er beim Aufwachen nicht jedes Mal bei null anfängt. Ohne dieses Orchester ist Vibe Coding ein talentierter Praktikant mit Amnesie.

Rules: das Betriebssystem des Agenten

Rules sind dauerhafte Anweisungen. Sie stehen nicht im Chat, sondern in Dateien, die jede Session mitliest. Bei mir stehen da Dinge wie: nur committen wenn ich es will, keine Secrets, Meta-Descriptions zwischen 140 und 160 Zeichen, interne Links setzen, nicht den Scope aufblasen.

Je besser die Rules, desto weniger muss ich im Prompt denselben Sermon halten. Das ist der Hebel, den die meisten unterschätzen. Sie kaufen ein besseres Modell. Ich schärfe die Rules.

Skills: wiederholbare Playbooks

Ein Skill ist eine Anleitung für eine wiederkehrende Aufgabe: Artikel publishen, SEO-Audit, PR splitten, Loop setzen. Der Agent liest das Skill und führt es aus, statt jedes Mal zu raten, wie „wir das hier so machen“.

Wenn ich merke, dass ich denselben Ablauf zum dritten Mal erkläre, wird daraus ein Skill. Das ist Optimierung im eigentlichen Sinn: nicht der Agent wird smarter, das System wird enger.

Subagents: Isolation statt Kontext-Matsch

Die Hauptsession ist teuer. Sie trägt den ganzen Tag mit. Ein Subagent bekommt einen engen Auftrag, erledigt ihn, kommt mit einem Bericht zurück. Recherche, Dateisuche, „warum ist dieser Test rot“: das gehört nicht alles in denselben Context-Window-Brei.

Ohne Subagents orchestrierst du nicht. Du überlädst einen Chat, bis er halluziniert, dass eine Datei existiert, die er vor drei Stunden gelesen hat.

Hooks: Automatik an den Kanten

Hooks greifen vor oder nach Tool-Calls: Shell prüfen, nach einem Edit formatieren, nach einem Subagent den nächsten Schritt anstoßen. Das ist die Schicht, in der aus „Agent, denk dran“ ein System wird, das sich selbst erinnert.

Gemeinsam ergeben Rules, Skills, Subagents, Hooks und Loops das, was ich meinen AI coding workflow nenne. Der Chat ist nur noch die Oberfläche. Darunter läuft ein kleines Betriebssystem für Arbeit.

Wer tiefer in eine eigene, bleibende KI statt nur in Chat-Sessions gehen will: Das habe ich parallel mit OpenClaw als persönlichem KI-Assistenten aufgesetzt, mit Gedächtnis, Tools und wiederkehrenden Prozessen, nicht nur einer IDE-Session.

Ein Arbeitstag ohne selbst geschriebenen Code

Kein idealisierter Deep-Work-Kalender, sondern ein realer Tag, an dem die Agenten die Tastatur haben.

Morgen: Laptop auf, Hotspot prüfen falls ich nicht zu Hause bin, offene Sessions scannen. Was hat der Nacht-Loop (oder der Loop vom späten Abend) hinterlassen? Diffs lesen, nicht schreiben. Ein Agent hat einen Artikelentwurf, einer hat Tests grün gemacht, einer ist in einer Sackgasse und braucht eine Entscheidung, keine weitere Autonomie.

Vormittag: Zwei, drei Aufträge klar formulieren. Nicht „mach die Seite besser“, sondern: „Interne Links auf diese URL vereinheitlichen, Ankertext = Zielkeyword, idempotent, danach Live prüfen.“ Loop auf 5 Minuten. Zweiter Agent parallel an einem anderen Repo. Ich gehe in den Garten. Der Laptop bleibt offen.

Mittag: Auto, Termin, Hotspot. Der Rechner auf der Rückbank oder im Rucksack. Ich schaue nicht dauernd hin, sondern wenn ein Loop-Zyklus sinnvoll fertig sein könnte. Wenn die Session tot ist, war der Hotspot weg. Das ist der neue „Build ist fehlgeschlagen“, nur dümmer.

Nachmittag: Review. Das ist jetzt die eigentliche Handarbeit: Ist die Lösung die, die ich wollte? Hat der Agent den Scope aufgeblasen? Sind DE und EN wirklich übersetzt oder nur gespiegelt? Geht die Live-Seite? Dann nächster Auftrag, nächster Loop.

Spaziergang: Ja, wirklich. Nicht wegen Instagram, sondern weil 25 Minuten Laufen ungefähr die Zeit sind, in der ein Agent eine Checkliste durchziehen kann, wenn das Ding Netz hat. Ich komme zurück, lese das Ergebnis, schärfe nach oder bereite das Mergen vor.

Der Tag hat wenig Flow-State im klassischen Sinn. Kein „vier Stunden in einer Funktion verschwinden“. Stattdessen viele kurze Dirigier-Momente und lange Phasen, in denen Maschinen arbeiten, während ich Mensch bin, oder zumindest nicht an der Tastatur klebe.

Wer so arbeitet, braucht andere Tugenden als Tippschnelligkeit: Klarheit, Geduld bis der Loop tickt, die Disziplin nicht selbst reinzupfuschen, und ein System, das festhält, was „gut“ heißt, wenn du nicht mehr jede Zeile siehst. Dafür hilft mir weiterhin systematisches Debug-Thinking, nicht für den Code, den ich nicht schreibe, sondern für die Aufträge, die ich formuliere.

Qualitätssicherung, obwohl du den Code nicht selbst schreibst

Das häufigste Gegenargument: „Wenn du nichts selbst tippst, merkst du nicht, wenn es falsch ist.“ Stimmt, wenn Review heißt „einmal drüberlesen und hoffen“.

Mein Gegenmodell ist kein Blindvertrauen, sondern eine andere Prüfschicht:

• Diff zuerst. Nicht den Chat, den Diff. Was wurde wirklich geändert?
• Tests vom Agenten, nicht als Deko. Rot ist ein Auftrag, keine Entschuldigung.
• Live prüfen, wo es eine Live-Seite gibt. HTML im Repo ist nicht die Wahrheit im Browser.
• Idempotenz. Skripte und Content-Patches müssen zweimal laufen dürfen, ohne Schaden.
• Kleine PRs. Ein Agent, der 40 Dateien anfasst, hat den Scope verloren. Dann splitten, nicht „passt schon“.
• Definition of Done im Prompt. Wenn sie nicht drinsteht, erfindet der Agent eine, die ihm gefällt.

Ich habe dadurch nicht weniger Verantwortung. Ich habe weniger Tastatur und mehr Urteil. Das Urteil ist der Job, der bleibt, wenn Vibe Coding den Rest auffrisst.

Manchmal ist das Ergebnis besser als das, was ich selbst geschrieben hätte, weil der Agent die Nachbarmodule liest, die ich aus Gewohnheit ignoriert hätte. Manchmal ist es selbstbewusst falsch. Deshalb bleibt Review nicht optional. Es wird zur Hauptkompetenz.

Das System immer weiter optimieren, nicht den einzelnen Prompt

Ein einzelner genialer Prompt ist ein Trick. Ein System, das durchschnittliche Prompts in gute Arbeit verwandelt, ist der Job.

Was ich laufend nachschärfe:

1. Aufträge kleiner schneiden. „Ganzen Cluster SEO“ verliert gegen „eine Seite, ein Keyword, ein Skript“.
2. Checklisten statt Stimmung. Agenten können Listen abarbeiten. Stimmung nicht.
3. Feedback in Rules überführen. Jeder Fehler, den ich dreimal korrigiere, gehört in eine Rule.
4. Parallelisieren, wo Dateien sich nicht beißen. Sequentiell, wo sie sich beißen.
5. Loops kürzer oder event-basiert machen, sobald ich das Muster kenne.
6. Messen, was ankommt: Artikel live, Tests grün, Indexierung. Nicht Tokens verbraucht.

Das ist Agent Orchestration optimieren als Handwerk. Es fühlt sich an wie Plattform-Engineering für eine Person. Du baust die Fabrik, in der du früher selbst an der Werkbank standest.

Die Meta-Schleife, die alles zusammenhält: Agent arbeitet, ich sehe den Fehler, ich verbessere nicht nur den Output, sondern die Anweisung, die den Fehler zugelassen hat. Wer nur den Output flickt, bleibt in Stufe 2 kleben. Wer die Anweisung flickt, braucht irgendwann keine Zeile mehr selbst.

Für Inhalte, die ranken sollen, bleibt trotzdem Handwerk: Struktur, Keywords, interne Links, FAQ. Das habe ich als Developer ohnehin gelernt, siehe Technical Blogging für Entwickler. Der Unterschied: Den Rohbau schreibt der Agent. Die SEO-Constraints gebe ich vor. Den Feinschliff orchestriere ich, bis die Checkliste grün ist.

Was dieser Alltag kostet: Geld, Akku, Aufmerksamkeit, Burnout

Always-on Agenten sind kein Lifestyle-Hack ohne Rechnung.

Geld und Tokens

Ein Agent, der fünf Stunden in einem Loop „nur mal schauen“ darf, ist ein teurer Wachhund. Feste Loops ohne Stop-Kriterium sind die einfachste Art, Geld zu verbrennen. Event-basiert arbeiten, fertig stoppen, nicht aus Nervosität drei Modelle parallel auf denselben Bug hetzen.

Akku, Hitze, Mobilfunk

Laptop im Rucksack unter Last wird heiß. Hotspot zieht Handy-Akku leer. Unterwegs bist du plötzlich Sysadmin deiner eigenen Taschen-Infrastruktur. Das ist echter Ops-Aufwand, den Job-Beschreibungen noch nicht enthalten: Softwareentwickler (m/w/d), plus Powerbank-Management.

Immer erreichbar für die eigene Maschine

Der Laptop im Auto, im Garten, beim Spazieren: das ist Produktivität und eine Falle. Du trainierst dich darauf, nie offline zu sein, weil „der Agent ja noch läuft“. Dasselbe Muster wie Slack-Ping, nur dass du den Ping selbst gebaut hast.

Ich halte das für den gefährlichsten Teil. Nicht die KI selbst, sondern die Unfähigkeit, eine Session sterben zu lassen. Wenn der Loop zur Identität wird, bist du nicht mehr Orchestrator. Du bist Bereitschaftsdienst für eine Maschine, die kein Feierabend-Konzept hat.

Wenn das nach Daueranspannung klingt, ist es das manchmal. Dann helfen dieselben Basics wie bei jeder Überlastung. Das ist verwandt mit dem, was ich im Burnout-Leitfaden und unter Burnout Soforthilfe beschreibe. Vibe Coding ersetzt keine Pause. Es macht Pausen nur leichter zu ignorieren, weil „es ja von allein weiterläuft“.

Qualitätsdrift und Verantwortungsdiffusion

Wenn niemand mehr den Code tippt, fühlt sich Verantwortung weicher an. Ist aber härter: Du hast den Agenten losgeschickt. Der Diff geht unter deinem Namen raus. „Der Agent hat das so gemacht“ ist keine Produktionsausrede.

So startest du, ohne dein Leben umzukrempeln

Du brauchst nicht morgen den Laptop im Garten. Du brauchst einen Auftrag, den ein Agent zu Ende führen kann, während du Kaffee holst.

1. Nimm eine Aufgabe mit klarem Done. Test schreiben, Link vereinheitlichen, Bug mit Repro. Nicht „Architektur überdenken“.
2. Schreib Constraints. Was darf er nicht? Welche Dateien? Welcher Test muss grün sein?
3. Lass ihn allein arbeiten. Nicht jede Datei live kommentieren. Das ist Chat-Coding, kein Agent.
4. Setz einen kurzen Loop (5 Minuten) mit Stop-Kriterium.
5. Review den Diff, nicht das Geschwätz.
6. Pack den Fehler in eine Rule oder ein Skill, nicht nur in den nächsten Prompt.
7. Erst dann: länger laufen lassen, Hotspot, zweiter Agent, Garten. Infrastruktur folgt der Gewohnheit, nicht umgekehrt.

Wenn du in Zwei-Wochen-Zyklen denkst, passt das gut zu einem Sprint-Rhythmus. Ich nutze denselben Schnitt fürs Leben in Agile Life Sprints: kleiner Auftrag, Review, Retro, System anpassen. Agent Orchestration ist dasselbe, nur mit Modellen statt mit To-do-Listen.

Häufig gestellte Fragen

Was ist Vibe Coding konkret im Entwickler-Alltag?

Vibe Coding heißt: Du vorgibst Ziel und Constraints, ein KI-Coding-Agent schreibt und ändert den Code. Im Alltag bedeutet das weniger Tippen und mehr Orchestrieren: Loops, Review, parallele Agenten, statt selbst Zeile für Zeile zu bauen.

Kann man als Entwickler wirklich keine Zeile Code mehr selbst schreiben?

Ja, für produktive Arbeit. Seit Monaten tippe ich in Repos nichts mehr selbst. Voraussetzung: Der Agent hat Tools, Tests, Rules und ein klares Done-Kriterium. Ohne Review und ohne Stop-Regeln wird daraus nur schnellerer Ausschuss.

Was sind Agent Loops und wie baut man sie?

Ein Agent Loop weckt die Session nach Zeit oder Event und führt denselben Auftrag erneut aus. Praktisch: eine Shell-Schleife mit Sleep, einem eindeutigen Sentinel und einem Prompt-Payload. Feste Intervalle zum Einstieg, Watcher auf CI oder Dateien sobald Polling Verschwendung ist.

Warum Laptop und Handy-Hotspot, nur damit der Agent läuft?

Weil die Session stirbt, wenn der Rechner schläft oder das Netz weg ist. Loops, Terminals und Watcher brauchen Laufzeit. Deshalb ist der Laptop im Auto, im Garten oder im Rucksack keine Marotte, sondern Infrastruktur für always-on Coding-Agenten.

Wie orchestriert man mehrere KI-Agenten, ohne Chaos?

Ein Owner-Agent priorisiert, Subagents bekommen isolierte Jobs, niemals zwei Schreiber auf derselben Datei. Handoffs schriftlich: erledigt, offen, nächster Befehl. Parallel nach Schnittstelle schneiden, nicht nach Bauchgefühl möglichst viele Modelle starten.

Ist Vibe Coding dasselbe wie ChatGPT-Code kopieren?

Nein. Copy-Paste aus einem Chat ist Stufe 2. Vibe Coding im engen Sinn ist agentic: Der Agent liest das Repo, ändert Dateien, läuft Tests, hält Loops am Leben. Du steuerst den Prozess und fügst nicht Snippets in die IDE.

Wie sichert man Qualität, wenn man den Code nicht selbst tippt?

Diff-first Review, automatisierte Tests, Live-Checks, kleine PRs, Definition of Done im Prompt. Verantwortung bleibt beim Menschen, der den Agenten losgeschickt hat. „Das Modell wollte das so“ zählt in Produktion nicht.

Was ist der größte Fehler beim Einstieg in Agent Orchestration?

Zu große Aufträge ohne Stop-Kriterium, dazu ein Loop der nie endet. Zweiter Fehler: selbst in denselben Diff zu tippen, während der Agent arbeitet. Dritter: Infrastruktur (Hotspot, Akku) ignorieren und sich wundern, warum der Agent „einfach aufhört“.

Fazit

KI-Entwicklung hat meinen Alltag nicht nur ein bisschen effizienter gemacht. Sie hat die Tätigkeitsbeschreibung ersetzt. Ich schreibe keinen Code mehr mit den Händen. Ich halte Agenten am Laufen, baue Loops, schärfe Rules, verteile Subagents, review Diffs. Und dafür trage ich einen Laptop durch den Garten, das Auto und den Spaziergang, mit Hotspot am Handy, als wäre das der neue Compiler.

So sieht Vibe Coding bei mir aus. Es funktioniert und es liefert. Es frisst Akku, Tokens und die Illusion, Feierabend sei, wenn die IDE zu ist. Die IDE ist nie zu. Die Session soll ja weiterlaufen.

Wenn du eines mitnimmst: Hör auf, bessere Zeilen schreiben zu wollen. Bau ein System, das bessere Zeilen schreibt, während du entscheidest, welche Zeilen überhaupt existieren dürfen. Dann bist du nicht arbeitslos als Entwickler. Du bist beschäftigt als Orchestrator, und der Laptop im Rucksack ist nur das sichtbare Symptom.

Weitere Ressourcen

• OpenClaw: eigene KI statt nur Chat-Sessions
• Technical Blogging für Entwickler: Struktur, die auch Agenten brauchen
• Debug-Thinking: Probleme in klare Schritte schneiden
• Agile Life Sprints: in Zyklen steuern, nicht in Dauerfeuer
• Burnout-Leitfaden, wenn Always-On nach Überlastung kippt