Hören Sie auf, einen generischen KI-Assistenten für alles zu verwenden. Richten Sie 5 spezialisierte Agenten ein, um eine vollständige API zu erstellen: Der Backend-Architekt entwirft das System, der Datenbank-Optimierer überprüft das Schema, der Frontend-Entwickler erstellt den Client, der Code-Reviewer prüft die Sicherheit und der Reality Checker validiert vor dem Versand.
Sie müssen schnell eine API erstellen. Die Versuchung: eine einzige KI alles machen zu lassen. Sie wird die Datenbank entwerfen, die Endpunkte schreiben, das Frontend erstellen, den Code überprüfen und das Ergebnis testen.
Das passiert dann: der Datenbank fehlen Indizes, die Endpunkte weisen Sicherheitslücken auf, das Frontend ignoriert Fehlerzustände und das Testen besteht aus einem „sieht gut aus für mich“.
Spezialisierte Agenten beheben dies. Jeder Agent kennt seinen Bereich. Jeder Agent hat Checklisten. Jeder Agent liefert spezifische Ergebnisse. Der Backend-Architekt denkt über Skalierbarkeit nach. Der Datenbank-Optimierer entdeckt fehlende Indizes. Der Code-Reviewer findet Schwachstellen. Der Reality Checker verlangt Beweise.
In diesem Tutorial richten Sie 5 Agenten aus der Agency-Sammlung ein und führen einen vollständigen API-Erstellungsworkflow aus. Sie integrieren Apidog für API-Tests und Dokumentation, um sicherzustellen, dass Ihre Endpunkte vor der Bereitstellung anhand von OpenAPI-Spezifikationen validiert werden.
Die 5 Agenten, die Sie verwenden werden
| Agent | Abteilung | Verantwortlichkeit |
|---|---|---|
| Backend-Architekt | Entwicklung | API-Design, Datenbankschema, Authentifizierung |
| Datenbank-Optimierer | Entwicklung | Indexempfehlungen, Abfrageoptimierung |
| Frontend-Entwickler | Entwicklung | React-Komponenten, API-Client, Zustandsverwaltung |
| Code-Reviewer | Entwicklung | Sicherheitsprüfung, Typsicherheit, Fehlerbehandlung |
| Reality Checker | Tests | Evidenzbasierte Validierung, Screenshot-Nachweis |
Installieren Sie die Agenten:
# Klonen Sie das Agency-Repository
git clone https://github.com/msitarzewski/agency-agents.git
cd agency-agents
# Kopieren Sie Agenten nach Claude Code
cp engineering/engineering-backend-architect.md ~/.claude/agents/
cp engineering/engineering-database-optimizer.md ~/.claude/agents/
cp engineering/engineering-frontend-developer.md ~/.claude/agents/
cp engineering/engineering-code-reviewer.md ~/.claude/agents/
cp testing/testing-reality-checker.md ~/.claude/agents/
Schritt 1: Der Backend-Architekt entwirft das System
Starten Sie eine neue Claude Code-Sitzung:
Backend-Architekt-Modus aktivieren.
Entwerfen Sie eine REST-API für eine E-Commerce-Plattform mit:
- Benutzerauthentifizierung (JWT mit Refresh-Tokens)
- Produktkatalog mit Kategorien und Filterung
- Warenkorbverwaltung
- Auftragsabwicklung mit Statusverfolgung
- Integration von Zahlungs-Webhooks
Ausgabe:
1. OpenAPI 3.0 Spezifikation
2. PostgreSQL-Datenbankschema mit Beziehungen
3. Projektordnerstruktur (Express.js + TypeScript)
4. Authentifizierungsflussdiagramm
Erwartete Ergebnisse:
Der Backend-Architekt wird ausgeben:
OpenAPI-Spezifikation (teilweise):
openapi: 3.0.0
info:
title: E-commerce API
version: 1.0.0
paths:
/auth/login:
post:
summary: User login
requestBody:
content:
application/json:
schema:
type: object
properties:
email: { type: string, format: email }
password: { type: string, minLength: 8 }
responses:
'200':
description: JWT tokens
content:
application/json:
schema:
type: object
properties:
accessToken: { type: string }
refreshToken: { type: string }
Datenbankschema:
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email VARCHAR(255) UNIQUE NOT NULL,
password_hash VARCHAR(255) NOT NULL,
created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);
CREATE TABLE products (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
name VARCHAR(255) NOT NULL,
description TEXT,
price DECIMAL(10, 2) NOT NULL CHECK (price >= 0),
category_id UUID REFERENCES categories(id),
inventory_count INTEGER DEFAULT 0,
created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID REFERENCES users(id),
total_amount DECIMAL(10, 2) NOT NULL,
status VARCHAR(50) DEFAULT 'pending',
created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);
Ordnerstruktur:
src/
├── controllers/
│ ├── auth.controller.ts
│ ├── products.controller.ts
│ └── orders.controller.ts
├── middleware/
│ ├── auth.middleware.ts
│ └── validation.middleware.ts
├── routes/
│ ├── auth.routes.ts
│ ├── products.routes.ts
│ └── orders.routes.ts
├── services/
│ ├── auth.service.ts
│ ├── products.service.ts
│ └── orders.service.ts
├── models/
│ ├── User.ts
│ ├── Product.ts
│ └── Order.ts
└── index.ts
Speichern Sie die Ausgabe. Sie übergeben sie an den nächsten Agenten.
Schritt 2: Der Datenbank-Optimierer überprüft das Schema
Öffnen Sie eine neue Sitzung:
Datenbank-Optimierer-Modus aktivieren.
Überprüfen Sie dieses PostgreSQL-Schema für eine E-Commerce-API:
[Fügen Sie das Schema aus Schritt 1 ein]
Prüfen auf:
1. Fehlende Indizes für Fremdschlüssel und häufig abgefragte Spalten
2. Abfrageleistung bei der Produktsuche (Name, Kategorie, Preisspanne)
3. Geeignete Constraints für Datenintegrität
4. Fehlende Tabellen für gängige E-Commerce-Funktionen (Bewertungen, Wunschlisten)
5. Soft-Delete-Muster für Audit-Trails
Geben Sie spezifische ALTER TABLE-Anweisungen und neue Tabellendefinitionen aus.
Erwartete Ergebnisse:
Indexempfehlungen:
-- Indizes für Fremdschlüssel hinzufügen
CREATE INDEX idx_products_category_id ON products(category_id);
CREATE INDEX idx_orders_user_id ON orders(user_id);
-- Index für Produktsuche hinzufügen
CREATE INDEX idx_products_name_search ON products USING gin(to_tsvector('english', name));
CREATE INDEX idx_products_price ON products(price) WHERE inventory_count > 0;
-- Zusammengesetzten Index für Kategoriefilterung hinzufügen
CREATE INDEX idx_products_category_price ON products(category_id, price);
Fehlende Tabellen:
CREATE TABLE reviews (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
product_id UUID REFERENCES products(id),
user_id UUID REFERENCES users(id),
rating INTEGER CHECK (rating >= 1 AND rating <= 5),
comment TEXT,
created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
UNIQUE(product_id, user_id)
);
CREATE TABLE cart_items (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID REFERENCES users(id),
product_id UUID REFERENCES products(id),
quantity INTEGER DEFAULT 1 CHECK (quantity > 0),
created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
UNIQUE(user_id, product_id)
);
Hinzuzufügende Constraints:
-- E-Mail-Formatvalidierung
ALTER TABLE users ADD CONSTRAINT chk_email_format
CHECK (email ~* '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$');
-- Soft-Delete-Spalte
ALTER TABLE products ADD COLUMN deleted_at TIMESTAMP WITH TIME ZONE NULL;
CREATE INDEX idx_products_deleted_at ON products(deleted_at) WHERE deleted_at IS NULL;
Wenden Sie diese Empfehlungen auf Ihr Schema an.
Schritt 3: Der Frontend-Entwickler erstellt den Client
Öffnen Sie eine neue Sitzung:
Frontend-Entwickler-Modus aktivieren.
Erstellen Sie ein React-Dashboard für diese E-Commerce-API:
[Fügen Sie die OpenAPI-Spezifikation aus Schritt 1 ein]
Anforderungen:
- TypeScript mit Strict Mode
- React Query für die Server-Zustandsverwaltung
- Produktliste mit Filtern (Kategorie, Preisspanne, Suche)
- Warenkorb mit Echtzeit-Updates
- Bestellverlauf mit Statusverfolgung
- Korrekte Fehlerbehandlung und Ladezustände
- Responsives Design (mobil, Tablet, Desktop)
Ausgabe:
1. Projekt-Setup (Vite + React + TypeScript)
2. API-Client mit React Query Hooks
3. Kernkomponenten (ProductList, ProductCard, Cart, OrderHistory)
4. Fehlergrenze (Error Boundary) und Lade-Skelette
Erwartete Ergebnisse:
API-Client:
// src/lib/api-client.ts
import { QueryClient, useQuery, useMutation } from '@tanstack/react-query';
const API_BASE = 'http://localhost:3000/api';
async function fetcher<T>(endpoint: string, options?: RequestInit): Promise<T> {
const response = await fetch(`${API_BASE}${endpoint}`, {
...options,
headers: {
'Content-Type': 'application/json',
...options?.headers,
},
});
if (!response.ok) {
const error = await response.json();
throw new Error(error.message || 'Request failed');
}
return response.json();
}
export function useProducts(filters?: ProductFilters) {
const params = new URLSearchParams(filters as Record<string, string>);
return useQuery({
queryKey: ['products', filters],
queryFn: () => fetcher<Product[]>(`/products?${params}`),
});
}
export function useAddToCart() {
return useMutation({
mutationFn: (item: CartItem) =>
fetcher<CartItem>('/cart', {
method: 'POST',
body: JSON.stringify(item),
}),
});
}
Produktlistenkomponente:
// src/components/ProductList.tsx
import { useProducts } from '@/lib/api-client';
import { ProductCard } from './ProductCard';
import { FilterSidebar } from './FilterSidebar';
import { Skeleton } from './ui/skeleton';
export function ProductList() {
const [filters, setFilters] = useState<ProductFilters>({});
const { data: products, isLoading, error } = useProducts(filters);
if (error) {
return <Alert variant="destructive">{error.message}</Alert>;
}
return (
<div className="flex gap-4">
<FilterSidebar filters={filters} onFilterChange={setFilters} />
<div className="flex-1 grid grid-cols-1 md:grid-cols-3 gap-4">
{isLoading ? (
Array.from({ length: 6 }).map((_, i) => (
<Skeleton key={i} className="h-64" />
))
) : products?.length === 0 ? (
<EmptyState message="No products found" />
) : (
products?.map(product => (
<ProductCard key={product.id} product={product} />
))
)}
</div>
</div>
);
}
Fehlergrenze:
// src/components/ErrorBoundary.tsx
export class ErrorBoundary extends React.Component<
{ children: React.ReactNode },
{ hasError: boolean; error: Error | null }
> {
constructor(props: { children: React.ReactNode }) {
super(props);
this.state = { hasError: false, error: null };
}
static getDerivedStateFromError(error: Error) {
return { hasError: true, error };
}
render() {
if (this.state.hasError) {
return (
<div className="p-4 bg-red-50 border border-red-200 rounded">
<h2 className="text-lg font-semibold text-red-800">Something went wrong</h2>
<p className="text-red-600">{this.state.error?.message}</p>
<Button onClick={() => window.location.reload()} className="mt-2">
Reload
</Button>
</div>
);
}
return this.props.children;
}
}
Schritt 4: Der Code-Reviewer prüft alles
Öffnen Sie eine neue Sitzung:
Code-Reviewer-Modus aktivieren.
Überprüfen Sie diese Codebasis auf:
1. Sicherheitslücken:
- SQL-Injection-Risiken
- XSS-Schwachstellen
- CSRF-Schutz
- Möglichkeiten zur Umgehung der Authentifizierung
2. TypeScript Strict Mode Konformität:
- Keine impliziten 'any'-Typen
- Korrekte Typdefinitionen
- Null-/Undefined-Behandlung
3. Lücken in der Fehlerbehandlung:
- Unbehandelte Promise-Rejections
- Fehlende try/catch-Blöcke
- Stille Fehler
[Fügen Sie den Code aus den Schritten 1-3 ein]
Geben Sie einen Bericht mit Schweregraden (Kritisch, Hoch, Mittel, Niedrig) und spezifischen Korrekturen aus.
Erwartete Ergebnisse:
Sicherheitsbericht:
## Kritische Probleme
### 1. SQL-Injection bei der Produktsuche
**Ort:** `src/controllers/products.controller.ts:24`
**Problem:** Benutzereingabe direkt in SQL-Abfrage verkettet
```typescript
// ANFÄLLIG
const query = `SELECT * FROM products WHERE name LIKE '%${search}%'`;
Behebung: Parametrisierte Abfragen verwenden
const query = 'SELECT * FROM products WHERE name LIKE $1';
await db.query(query, [`%${search}%`]);
Hohe Probleme
2. Fehlender CSRF-Schutz
Ort: src/index.tsProblem: Keine CSRF-Middleware für zustandsändernde Operationen Behebung: csurf-Middleware hinzufügen
import csrf from 'csurf';
app.use(csrf({ cookie: true }));
Mittelschwere Probleme
3. Impliziter 'any'-Typ in API-Antwort
Ort: src/lib/api-client.ts:8Problem: Generischer any-Typ für die Fetcher-Funktion Behebung: Korrekte Typspezifikationen hinzufügen
async function fetcher<T extends Record<string, unknown>>(
endpoint: string,
options?: RequestInit
): Promise<T> { ... }
**Typsicherheitsbericht:**
```markdown
## TypeScript-Verletzungen
1. `products.controller.ts:45` - Fehlende Rückgabetyp-Annotation
2. `auth.middleware.ts:12` - Impliziter 'any'-Typ im Catch-Block
3. `orders.service.ts:78` - Objekt möglicherweise undefiniert
Führen Sie `tsc --noEmit` aus, um die vollständige Liste zu sehen. Beheben Sie dies vor der Bereitstellung.
Wenden Sie die Korrekturen an, bevor Sie fortfahren.
Schritt 5: Der Reality Checker validiert vor dem Versand
Öffnen Sie eine neue Sitzung:
Reality-Checker-Modus aktivieren.
Diese E-Commerce-API ist bereit für die Produktionsvalidierung.
Führen Sie Ihren obligatorischen Reality-Check-Prozess aus:
1. Überprüfen Sie, ob Dateien existieren
2. Vergleichen Sie beanspruchte Funktionen mit dem tatsächlichen Code
3. Fordern Sie Screenshot-Beweise von Playwright-Tests an
4. Überprüfen Sie test-results.json auf Leistungskennzahlen
Projekt-URL: http://localhost:3000
Testergebnisse: ./public/qa-screenshots/test-results.json
Ausgabe: BESTANDEN oder ÜBERARBEITUNG NÖTIG mit spezifischen blockierenden Problemen.
Erwartete Ergebnisse:
Reality-Check-Befehle:
# 1. Überprüfen Sie, ob Dateien existieren
ls -la src/controllers/ src/services/ src/routes/
ls -la src/components/ src/lib/
# 2. Vergleichen Sie beanspruchte Funktionen
grep -r "jwt\|jsonwebtoken" . --include="*.ts" || echo "KEIN JWT GEFUNDEN"
grep -r "bcrypt\|argon2" . --include="*.ts" || echo "KEIN PASSWORD-HASHING GEFUNDEN"
grep -r "rateLimit\|express-rate-limit" . --include="*.ts" || echo "KEIN RATE LIMITING GEFUNDEN"
# 3. Führen Sie die Playwright-Screenshot-Erfassung aus
npx playwright test --config=qa-playwright.config.ts --grep "@screenshot"
# 4. Überprüfen Sie die Testergebnisse
cat public/qa-screenshots/test-results.json
Validierungsbericht:
## Reality-Check-Ergebnisse
### Dateiverifizierung: BESTANDEN
- Alle Controller-Dateien vorhanden
- Alle Komponenten-Dateien vorhanden
### Feature-Verifizierung: ÜBERARBEITUNG NÖTIG
- JWT-Authentifizierung: GEFUNDEN
- Password-Hashing: GEFUNDEN
- Rate Limiting: NICHT GEFUNDEN (blockierend)
### Screenshot-Beweis: ÜBERARBEITUNG NÖTIG
- Desktop-Layout: BESTANDEN
- Tablet-Layout: BESTANDEN
- Mobiles Layout: FEHLGESCHLAGEN (Produktgitter bei 375px kaputt)
### Leistungsmetriken: ÜBERARBEITUNG NÖTIG
- Durchschnittliche Ladezeit: 2,3s (Ziel: <1s)
- Konsolenfehler: 3 (Ziel: 0)
- Fehlgeschlagene Netzwerkanfragen: 1 (Ziel: 0)
## Endgültiger Status: ÜBERARBEITUNG NÖTIG
### Blockierende Probleme:
1. Rate Limiting nicht implementiert
2. Mobiles Layout in der Produktliste kaputt
3. 3 Konsolenfehler zu beheben
4. Ladezeit überschreitet das 1s-Ziel
### Nicht-Blockierend:
- Lade-Skelette zum Bestellverlauf hinzufügen
- Fehlermeldungen verbessern
Beheben Sie die blockierenden Probleme und führen Sie den Reality Checker erneut aus.
Workflow-Zusammenfassung
┌─────────────────────────────────────────────────────────────────┐
│ Backend-Architekt │
│ → OpenAPI-Spezifikation, Datenbankschema, Ordnerstruktur │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ Datenbank-Optimierer │
│ → Indexempfehlungen, fehlende Tabellen, Constraints │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ Frontend-Entwickler │
│ → React-Komponenten, API-Client, Fehlerbehandlung │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ Code-Reviewer │
│ → Sicherheitsprüfung, Typsicherheit, Lücken in der Fehlerbehandlung │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ Reality Checker │
│ → Evidenzbasierte Validierung, Screenshot-Nachweis, BESTANDEN/FEHLGESCHLAGEN │
└─────────────────────────────────────────────────────────────────┘
Parallele Agenten-Ausführung (Fortgeschritten)
Führen Sie Agenten parallel aus, um die Gesamtzeit zu reduzieren:
# Terminal 1: Backend-Architekt
claude "Backend-Architekt aktivieren. E-Commerce-API entwerfen..."
# Terminal 2: Datenbank-Optimierer (auf Schema-Ausgabe warten)
claude "Datenbank-Optimierer aktivieren. Dieses Schema überprüfen..."
# Terminal 3: Frontend-Entwickler (auf API-Spezifikation warten)
claude "Frontend-Entwickler aktivieren. React-Dashboard erstellen..."
# Terminal 4: Code-Reviewer (auf Code warten)
claude "Code-Reviewer aktivieren. Diese Codebasis überprüfen..."
# Alle Terminals: Reality Checker (abschließende Validierung)
claude "Reality Checker aktivieren. Obligatorische Prüfungen ausführen..."
Mit paralleler Ausführung können Sie den Workflow in 2-4 Stunden statt in 6-8 Stunden abschließen.
Was Sie erstellt haben
| Ergebnis | Agent | Ausgabe |
|---|---|---|
| API-Design | Backend-Architekt | OpenAPI-Spezifikation, Datenbankschema, Ordnerstruktur |
| Schema-Optimierung | Datenbank-Optimierer | Indexempfehlungen, zusätzliche Tabellen, Constraints |
| Frontend | Frontend-Entwickler | React-Komponenten, API-Client, Fehlergrenzen |
| Sicherheitsprüfung | Code-Reviewer | Schwachstellenbericht, Typsicherheitskorrekturen |
| Abschließende Validierung | Reality Checker | Screenshot-Beweis, BESTANDEN/FEHLGESCHLAGEN-Zertifizierung |
Nächste Schritte
Bereitstellen der API:
- Produktions-PostgreSQL mit Connection Pooling einrichten
- Umgebungsvariablen für Geheimnisse konfigurieren
- Health-Check-Endpunkte hinzufügen
- Monitoring einrichten (Prometheus, Grafana)
Workflow erweitern:
- Performance-Benchmarker-Agenten für Lasttests hinzufügen
- Technical-Writer-Agenten für Dokumentation hinzufügen
- DevOps-Automator-Agenten für CI/CD-Pipeline hinzufügen
Muster wiederverwenden:
- Prompts als Vorlagen speichern
- Ein Workflow-Skript erstellen, das Agenten-Sitzungen verkettet
- Mit Ihrem Team teilen
Fünf spezialisierte Agenten. Eine komplette API. Keine generischen Ratschläge.
Das ist die Stärke der Spezialisierung. Jeder Agent kennt seinen Bereich. Jeder Agent hat Checklisten. Jeder Agent liefert spezifische Ergebnisse.
Sie sind dran: Wählen Sie ein Projekt, aktivieren Sie die Agenten und liefern Sie schneller aus.
Wichtige Erkenntnisse
- Spezialisierte Agenten übertreffen generische Assistenten — Jeder Agent verfügt über Fachwissen, Checklisten und spezifische Ergebnisse
- Sequenzieller Workflow sichert Qualität — Backend-Architekt entwirft, Datenbank-Optimierer überprüft, Frontend-Entwickler erstellt, Code-Reviewer prüft, Reality Checker validiert
- Evidenzbasierte Genehmigung verhindert Fehler — Der Reality Checker erfordert Screenshot-Beweise, Grep-Ergebnisse und Leistungsmetriken vor der BESTANDEN-Zertifizierung
- Parallele Ausführung reduziert die Gesamtzeit — Führen Sie 4 Terminals gleichzeitig aus, um in 2-4 Stunden statt in 6-8 Stunden fertig zu werden
- Prompts als Vorlagen speichern — Verwenden Sie dieselben Agenten-Aktivierungen für konsistente Ergebnisse über Projekte hinweg
FAQ
Was sind KI-Agenten für Entwickler?KI-Agenten sind spezialisierte KI-Assistenten mit Fachwissen. Im Gegensatz zu generischen Chatbots verfügen Agenten wie der Backend-Architekt oder der Code-Reviewer über spezifische Checklisten und liefern konsistente Ergebnisse.
Wie installiere ich Agenten von The Agency?Klonen Sie das Repository unter github.com/msitarzewski/agency-agents, kopieren Sie dann .md-Dateien nach ~/.claude/agents/ für Claude Code oder verwenden Sie das Installationsskript für andere Tools.
Was ist der Reality Checker Agent?Der Reality Checker ist ein evidenzbasierter QA-Agent, der die Freigabe von Arbeiten ohne Nachweis verweigert. Er erfordert Screenshots, Grep-Ergebnisse und Leistungsmetriken, bevor er die BESTANDEN-Zertifizierung erteilt.
Kann ich mehrere Agenten parallel ausführen?Ja. Öffnen Sie mehrere Terminals und aktivieren Sie in jedem verschiedene Agenten. Übergeben Sie Ergebnisse, indem Sie die Ausgabe kopieren oder den MCP-Speicher für automatische Übergaben nutzen.
Wie übergebe ich Kontext zwischen Agenten?Kopieren Sie die Ausgabe eines Agenten und fügen Sie sie als Eingabe für den nächsten ein. Für automatische Übergaben verwenden Sie den MCP-Speicher, um Ergebnisse zu speichern, die der nächste Agent abrufen kann.
Was ist, wenn ein Agent „ÜBERARBEITUNG NÖTIG“ meldet?Beheben Sie die vom Agenten identifizierten blockierenden Probleme und führen Sie den Agenten dann erneut aus. Der Reality Checker listet spezifisch auf, was behoben werden muss, bevor die BESTANDEN-Zertifizierung erteilt wird.
Benötige ich alle 5 Agenten für jedes Projekt?Nein. Beginnen Sie mit dem Backend-Architekten und dem Code-Reviewer für API-Projekte. Fügen Sie den Datenbank-Optimierer für komplexe Schemata, den Frontend-Entwickler für UI-Arbeiten und den Reality Checker vor dem Versand hinzu.
