KI-Agents 2026: Vom Coding-Buddy zum autonomen Entwickler

Tobe
Blog Veröffentlich am 04.02.26, Tobias Lorsbach

Ich weiß noch als ich Anfang 2024 auf LinkedIn von eingen massiv angegangen wurde, als ich schieb, dass 2024 das Jahr der Coding-Agents werden würde und dass wir bald alle keinen Code mehr schreiben würden. Nun, alles verzögerte sich etwas, aber 2025 war es dann spätestens soweit: Wenn du letztes Jahr dachtest, Claude oder GitHub Copilot wären „nur” Code-Assistenten, willkommen in 2026. Agents bauen jetzt komplette Apps. Mit Auth. Mit Zahlungen. Mit deploytem Backend. In 5min.

Klingt nach Hype? Ist es. Teilweise. Aber es ist auch real. Und es verändert gerade fundamental, wie Web- und Softwareentwicklung funktioniert.

Was ich in den letzten Wochen gebaut habe (fast ohne selbst Code zu schreiben)

Projekt: Screenshot-to-Mockup Generator

  • Frontend: Vue 3, TypeScript, Vite, pnpm, Tailwind 4
  • Backend: Python Flask, gehostet auf GCP
  • Was es macht: URL eingeben → Agent generiert 3 responsive Screenshots (Mobile, Tablet, Desktop) → KI erstellt daraus schöne Device-Mockups basierend auf Custom-Prompt

Timeline:

  • Tag 1: Basis-App läuft, Screenshots werden generiert, Mockups sehen gut aus
  • Tag 2–3: Frontend-Polishing, Error-Handling, erste Security-Checks
  • Woche 2: Rate-Limiting, Auth, vernünftiges Logging, Cost-Monitoring

ACHTUNG: “In einem Tag benutzbar” heißt nicht “production-ready”. Ganz im Gegenteil. Aber alles nacheinander.

Was schief ging:

  • Agent hat initialen API-Call ohne Timeout gebaut → erste Test-Rechnung: X€ für “gehackte” Requests
  • Image-Generation ohne Size-Limit → jemand probiert 8K-Screenshots → Backend crasht
  • Kein Rate-Limiting → erster Bot findet die API → 200€ Google-API-Kosten in 2 Stunden

Die harte Lektion: Agent baut ein Feature. Du musst die Konsequenzen tragen.

Was Agents 2026 wirklich können (Stand Februar)

1. MVP-Speed – aber mit Vorsicht

Best Case: 2–3 Tage für funktionierendes MVP
Reality Check: Plus 1–2 Wochen für Security, Error-Handling, Edge-Cases und… Bugfixing für Webkit

Agents sind brilliant darin, den “Happy Path” zu bauen. Alles andere? Dein Job.

Konkret bei meinem Projekt:

  • Agent baut Screenshot-Feature: 2 Stunden
  • Ich debugge Timeout-Issues bei langsamen Sites: 4 Stunden
  • Agent implementiert Retry-Logic: 30 Minuten
  • Ich teste Edge-Cases: 3 Stunden

2. Dokumentation on-the-fly – aber IMMER auch lesen!

Ja, Agents schreiben jetzt inline Comments + README + sogar ADRs. Und ja, es ist oft besser als manuell geschriebene Doku.

Aber: Diese Doku ist nur so gut wie der Code. Und wenn der Code Sicherheitslücken hat, dokumentiert der Agent die auch noch schön sauber mit. Und bitte denkt an den Kontext. Ein Bot sieht einiges nicht, was ein Mensch aber wissen muss. Lesen, korrigieren, korrigieren lassen, lesen.

Mein Workflow mit Astro Starlight für Projekt-Doku:

  1. Agent schreibt Code + inline Comments (bin kein Freund von Kommentaren tbh)
  2. Ich lese beides komplett
  3. Ich stelle Fragen: “Warum dieser Ansatz? Was sind Alternativen?”
  4. Doku geht ins Repo (wichtig für Team + zukünftiges Ich)
  5. Erst dann: Commit
  6. Ein tsx-Script in Starlight rattert die Repos des Projekts durch, crawlt die MD-Dateien und baut ein Frontend - ganz ohne KI, aber wunderschön.

Kritisch: Wenn du Code nicht verstehst, deploy ihn nicht. Punkt.

3. Die Kosten-Falle

Real-World-Beispiel:
Mein bespielhafter Mockup-Generator nutzt:

  • Google Gemini für Mockup-Generation mit Nano Banana
  • Google Cloud API für Image-Processing
  • GCP Cloud Run für Backend

Nach 3 Tagen Produktion ohne Safeguards:
Rechnung: XXX€. Für eine App, die noch keinen Cent Umsatz macht.

Nach meinem Rewrite:

  • Redis-Caching für identische URLs
  • Max 2MB Upload-Size
  • Rate-Limit: 10 Requests/Stunde/User
  • Cost-Alerts bei > 50€/Tag

Neue Rechnung: ~15€/Monat bei gleicher Nutzung.

Warum Google API?
Für Bild-basierte Apps sind die Gemini APIs unschlagbar. Bessere Erkennung, schnellere Response-Times, und die Integration mit GCP ist nahtlos. Aber: Ohne Limits kann das schnell teuer werden.

Security ist oft russisches Roulette

Agents packen gerne mal Secrets in Git. Sie vergessen CSRF-Schutz. Sie bauen SQL-Injection-Lücken ein, weil sie „dynamischen Query-Bau” als effizient sehen.

Mein Workflow jetzt:

  1. Agent baut Feature
  2. Ich lasse pnpm audit
  3. Manueller Security-Review jeder API-Route
  4. Cost-Monitoring-Alerts einrichten
  5. GitHub Actions CI mit Security-Scans
  6. Erst dann: Deploy zu Staging
  7. Nach 48h ohne Incidents: Production

KRITISCH: Niemals Code deployen, den du nicht verstehst. NEVER!

Das gilt für manuell geschriebenen, äh kopierten Code. Für AI-generierten Code gilt es doppelt.

Warum?
Weil AI-generierter Code oft “clever” ist – auf eine Art, die teuer werden kann:

  • Ineffiziente DB-Queries → hohe Cloud-Kosten
  • Fehlende Timeouts → Endlos-Loops → Rechnung explodiert
  • Keine Input-Validation → Angreifer können deine AI-APIs missbrauchen

Konkretes Beispiel:
Ein Bekannter hat einen “AI-powered Chatbot” deployed (komplett Agent-generiert). Keine Rate-Limits. Jemand hat in einer Nacht 2.400 Requests gemacht. Google-API-Rechnung: 1.200€.

Der Code war “functional”. Aber es fehlte jedes Verständnis für die Kostenstruktur.

Code-Review ist wichtiger denn je

Früher: Code-Review fängt Bugs.
Heute: Code-Review verhindert, dass dein Cloud-Bill fünfstellig wird.

Worauf ich jetzt achte:

  • Jede externe API: Timeout, Retry-Logic, Cost-Limit?
  • Jeder File-Upload: Size-Limit, Type-Validation?
  • Jede AI-Integration: Rate-Limiting, Caching, Fallback?
  • Jede DB-Query: Index vorhanden? N+1 vermieden?

Faustregel: Wenn ein Agent Code schreibt, der externe Kosten verursacht (APIs, AI, Cloud), ist manueller Review bleibt Pflicht.

Accessibility? Fast immer kaputt

Agents lieben <div onClick>. Sie vergessen aria-live. Sie bauen Focus-Traps, die keine sind.

Real-World-Beispiel aus meinem Projekt:
Agent baut Modal für Mockup-Preview. Sieht gut aus. Funktioniert mit Maus. Aber:

  • Kein Focus-Management → Tab geht durchs Background-DOM
  • ESC schließt nicht
  • Screen-Reader liest nur “Dialog, Dialog, Dialog”
  • Keine visuelle Focus-Indication

Fix: 30 Minuten manuell nachgebessert mit shadcn-vue Dialog-Component statt Custom-Modal.

Warum shadcn-vue? Accessibility ist eingebaut, TypeScript-First, und Agents können damit umgehen, wenn man sie richtig anleitet.

Welche Tools ich 2026 wirklich nutze

Mein Daily Driver:

  • VSCode mit Claude Code – Die Command-Line-Integration ist Gold wert für Refactoring ganzer Codebase
  • Claude Sonnet/Opus 4.5 via API – Für komplexe Tasks
  • OpenRouter API - Um alle möglichen neue Modelle direkt zu testen
  • Roo Code mit OpenRouter API - Wo bleibt denn sonst der Spaß?
  • Google Gemini APIs – Unschlagbar für alles mit Bildern (Nano Banana, teuer aber krass)

Warum Claude Code statt andere Tools?

  • Direkter Terminal-Zugriff → Agent kann selbst Tests ausführen
  • Kein Context-Wechsel zwischen Editor und Chat
  • Open-Source-freundlich, keine Vendor-Lock-Situation
  • Funktioniert nahtlos mit bestehenden VSCode-Extensions (nutze wenig)

Mein 202g Tech-Stack (Agent-optimiert):

Frontend:

  • Vite – Bester Bundler zur Zeit, Tschüss Webpack
  • Vue 3 – Composition API
  • Astro – Für Content-Sites, Blogs, Dokumentation
  • Tailwind 4 – Agents verstehen Utility-Classes besser als Custom CSS
  • shadcn-vue – Accessible Components out-of-the-box
  • pnpm – Schneller als npm, Monorepo-ready
  • WordPress – Nicht tot zu kriegen. Ich mag die API von Wordpress immer noch, trotz legacy PHP

Backend:

  • Python/Flask – Leichtgewichtig, schnell zu iterieren
  • WordPress (als Headless CMS) – Als REST API für Content -> TOP
  • Google Cloud Run – Auto-Scaling ohne Server-Management

Tooling:

  • Astrot – BESTER Sitebuilder
  • Astro Starlight – Projekt-Dokumentation (wichtig für Agent-Context!)
  • GitHub Actions / Bitbucket Pipelines – CI mit Security-Scans
  • MCP Server – Context-Sharing zwischen Tools (Game-changer!)
  • Skilling - Dein Agent kennt zB “BEM” für CSS nicht? Zack, einfach per (p)npm nachinstalliert.

MCP Server = Secret Weapon:

Agents können jetzt auf:

  • Figma-Designs zugreifen (MCP Figma Server)
  • Alte Projekt-Entscheidungen remembern (MCP Memory Server)
  • Bitbucket/GitHub direkt manipulieren

Beispiel: “Baue diese Figma-Component als Vue 3 mit Tailwind und den Button als Composeable mit props x,y,z” → Agent holt sich selbst die Design-Specs über MCP und baut direkt im Repo.

Konkrete Tipps für VSCode + Claude Code + MCP Setup

VSCode Extensions für Agent-Workflows:

  • Error Lens – Siehst sofort, was der Agent kaputt gemacht hat
  • Tailwind CSS IntelliSense – Autocomplete für Utility-Classes
  • GitLens – Diff-View, Cherrypicking wenn Agent 200 Files ändert (sollte er aber eigentlich nicht)

MCP Server Setup (Game-Changer!):

{
  "mcpServers": {
    "figma": {
      "command": "pnpm dlx",
      "args": ["-y", "@modelcontextprotocol/server-figma"],
      "env": {
        "FIGMA_TOKEN": "${FIGMA_TOKEN}"
      }
    },
    "memory": {
      "command": "pnpm dlx",
      "args": ["-y", "@acme/server-acme"]
    }
  }
}

Warum MCP so wichtig ist:

  • Agent hat Kontext über alte Projekt-Entscheidungen
  • Figma-Designs werden automatisch zu Code-Specs
  • Konsistenz über Projekte hinweg

Claude Code Best Practices:

  1. Context-Files nutzen:
node_modules/
dist/
.git/
*.log
.env*
  1. Explizite File-Refs:
@file:src/components/Mockup.vue - Refactor diesen Component
@file:docs/architecture.md - Dokumentiere die neue Logic hier
  1. MCP für wiederkehrende Tasks:
Agent, hole dir das Button-Design aus Figma (Component "CTA Primary")
und baue es als shadcn-vue Button in Tailwind 4

Agent kann dann automatisch Doku-Pages updaten, wenn Features sich ändern (ich mache sowas allerdings “manuell” per tsx-Script).

WordPress als Backend-Framework (unterschätzter Agent-Boost)

Warum WordPress + Headless?

  • Admin-UI ist unschlagbar (kein Custom-CMS bauen)
  • REST API out-of-the-box
  • Plugins für alles (SEO, Forms, E-Commerce)
  • Agents verstehen WP-Struktur sehr gut

Mein Setup:

WordPress (Headless) → REST API → Vite + Vue Frontend

Agent-Prompt für WP-Integration:

Nutze WordPress REST API v2.
Custom Post Type "mockup" mit:
- title, description, image_url, device_type
- PODS-Fields für Metadata

Erstelle Vue Composable useMockups() zB mit:
- fetchAll(), fetchByDevice(), create(), update()
- Error-Handling, Loading-States
- TypeScript Interfaces aus WP-Schema

Agent baut komplettes CRUD-Interface. Ich muss nur noch Security-Review machen (ok, oft scheppert es und man muss manuell finetunen, aber das hält sich in Grenzen).

Was bleibt von „normaler” Webentwicklung?

Wird ersetzt:

  • Boilerplate-Code
  • Standard-CRUD-Apps
  • Cookie-Cutter-Landingpages

Wird wichtiger denn je:

  • Security-Thinking (Agents denken nicht an Angriffe)
  • Cost-Awareness (Agents optimieren nicht für dein Budget)
  • Accessibility-Expertise (Agents bauen für “visuelle” User)
  • Systemarchitektur (Agents sehen nur einzelne Features)
  • Code-Review (du bist die letzte Verteidigungslinie)
  • MCP-Server-Orchestrierung (neues Skill!)

Besonders bei Google Cloud:

  • Quotas verstehen (Vision API hat Default-Limits)
  • Pricing-Calculator nutzen (vor Deploy!)
  • Batch-Optimierung (10 Calls = teuer, 1 Batch = günstig)

Ausblick: Wohin geht die Reise?

Wir sind gerade bei “Agents können Code”.

Mit MCP kommen wir zu “Agents verstehen deine gesamte Tool-Chain” – von Figma über GitHub bis Deployment und CI.

Mit Skilling bringen wir LLM-Agenten Skills bei, die sie noch nicht können – von Legacy Frameworks bis Cutting Edge Software auf Github und One Days mit einem npm install

Nächster Schritt (2026/27): Agents, die ganze Produkte managen – von User-Research über Design, Code, Testing bis Deployment.

Aber: Die Rolle des Entwicklers verschiebt sich von “Code schreiben” zu “System orchestrieren”. Und das braucht, auch wenn du es nicht hören willst, leider mehr Skills, nicht weniger.

Mein Fazit

Agents sind kein Ersatz für Entwickler. Sie sind ein Force-Multiplier – aber nur, wenn du weißt, was du tust.

Die gefährlichste Kombination 2026:
Agent, der Code schreibt + Entwickler, der ihn nicht versteht = teure Katastrophe

Die mächtigste Kombination 2026:
Agent + MCP Server + Entwickler mit Security/Cost/Architecture-Wissen = 10x Produktivität

Meine Regel:
Wenn ich den Code nicht in 5 Minuten einem Junior erklären kann, ist er zu komplex. Dann vereinfachen oder manuell schreiben.

Und: Alles landet in Astro Starlight Doku. Auch für Future-Me, der in 6 Monaten fragt: “WTF hab ich da gebaut?”

Das Wichtigste zum Schluss

Sollte man heute noch klassisches PRogrammieren lernen? Die Antwort lautet: JA! Unbedingt. Gerade wenn ein Agent anfängt zu zaubern, darf man nicht den Überblick verlieren, denn Agents verzapfen so einiges, was du am Ende nicht willst und was ua teuer werden kann. Lerne immer erst die Basics und dann schau dir mal an, was ein Agent daraus macht.


Hast du schon mit Agents gearbeitet? Was war dein größter WTF-Moment oder teuerster Fehler?
Nutzt du schon MCP Server? Welche?

Lerne aus meinen Fehlern – schreib’s in die Kommentare!

Kommentare

Kommentar schreiben

0 / 5000 Zeichen

* Pflichtfelder

Noch keine Kommentare. Sei der Erste!