In der Welt der Softwareentwicklung verschiebt sich der Fokus gerade dramatisch. Wir schreiben nicht mehr nur Code; wir schreiben Spezifikationen, die Agenten dazu bringen, Code zu schreiben. Willkommen im Zeitalter des Agentic Engineering.

Bei CNEXT nutzen wir VS Code in Kombination mit spezialisierten AI-Agenten, um komplexe Enterprise-Lösungen in Rekordzeit zu bauen. Der Schlüssel zum Erfolg? Spec-Driven Development (SDD).

Was ist Spec-Driven Development?

Traditionell war eine Spezifikation ein staubiges PDF, das niemand gelesen hat. Im Agentic Engineering ist die Spezifikation die Single Source of Truth für die KI. Wenn die Spec stimmt, stimmt das Ergebnis.

Der SDD-Workflow in VS Code:

1. 1Kontext definieren: Erstellen einer zentralen Wissensbasis (z. B. eine replit.md oder .cursorrules), die Architektur-Entscheidungen, Tech-Stack und Coding-Guidelines enthält.
2. 2Task-Spezifikation: Bevor eine Zeile Code angefasst wird, beschreiben wir das "Was" und "Warum".
3. 3Iteratives Prototyping: Der Agent baut, wir reviewen die Spec, nicht nur den Code.

Warum VS Code das perfekte Habitat für Agenten ist

VS Code ist durch seine Extension-Architektur prädestiniert für agentische Workflows. Tools wie Cursor, GitHub Copilot oder Replit Agent (via Remote-Integration) greifen direkt auf das Filesystem zu, verstehen die Projektstruktur und können Befehle im Terminal ausführen.

Die Vorteile für Schweizer Teams:

• Höhere Qualität: Weniger "Trial and Error", da der Agent klare Leitplanken hat.
• Wissenssicherung: Die Architektur-Entscheidungen liegen in Textform vor und können von neuen Teammitgliedern (und Agenten) sofort erfasst werden.
• Effizienz: Komplexe Refactorings, die früher Tage dauerten, werden zu Minuten-Aufgaben.

Best Practices für Ihre Spec

Damit Agenten in VS Code Höchstleistungen erbringen, müssen Specs drei Kriterien erfüllen:

Full Sample: SharePoint Weather Web Part Spec

Hier ist ein konkretes, produktionsreifes Beispiel für eine Spezifikation, die wir für einen Agenten in VS Code nutzen, um ein vollständiges SPFx Web Part zu bauen — inklusive Architecture Decision Records, Service-Layer-Design, Fehlerbehandlung, Caching-Strategie und Deployment-Konfiguration.

1. Context & Tech Stack

• Framework: SPFx v1.19 (SharePoint Framework)
• Library: React 18, Fluent UI v9, CSS Modules
• API: OpenWeatherMap API (Current Weather + 5-Day Forecast)
• Target: SharePoint Online / Microsoft Teams (Personal Tab + Full-Width)
• Auth: Azure AD App Registration mit Scope user.read für standortbasierte Personalisierung
• Caching: localStorage mit TTL (15 Min. für Current, 60 Min. für Forecast)
• Monitoring: Application Insights Telemetry via @microsoft/applicationinsights-web

2. Architecture Decision Records (ADR)

3. Functional Requirements

Must Have (P0):

• Anzeige des aktuellen Wetters für einen konfigurierbaren Standort (Stadt oder Koordinaten)
• 5-Tage-Forecast mit 3-Stunden-Intervallen als horizontale Scroll-Karten
• Property Pane: apiKey (Password-Feld), location (Text mit Autocomplete), unit (Toggle: Celsius/Fahrenheit), showForecast (Toggle), refreshInterval (Dropdown: 15/30/60 Min.)
• Fehlerbehandlung mit verständlichen Meldungen und Retry-Button
• Responsives Layout: Full-Width, 1/2, 1/3 Spalten-Support
• Barrierefreiheit: WCAG 2.1 AA, Tastaturnavigation, Screen Reader-Support

Should Have (P1):

• Standort-Erkennung via Browser Geolocation API (mit Fallback auf IP-basiert)
• Wetter-Alerts und Warnungen (OpenWeatherMap One Call API)
• Hintergrundfarbe adaptiert sich an Wetterlage (Sonnig = warm, Regen = kühl)
• Dark Mode-Support via SharePoint Theme Detection

Nice to Have (P2):

• Mini-Widget-Modus für schmale Spalten (nur Icon + Temperatur)
• Mehrsprachigkeit über SharePoint Language Pack (this.context.pageContext.cultureInfo)

4. Technical Specs

Service Layer: ``` interface IWeatherService { getCurrentWeather(location: string, unit: Unit): Promise<WeatherData>; getForecast(location: string, unit: Unit): Promise<ForecastData>; searchLocations(query: string): Promise<LocationResult[]>; getAlerts(lat: number, lon: number): Promise<WeatherAlert[]>; }

interface WeatherData { temp: number; feelsLike: number; humidity: number; windSpeed: number; windDirection: number; condition: WeatherCondition; icon: string; sunrise: Date; sunset: Date; location: { city: string; country: string; lat: number; lon: number }; lastUpdated: Date; }

type WeatherCondition = | "clear" | "clouds" | "rain" | "drizzle" | "thunderstorm" | "snow" | "mist" | "fog"; ```

Caching-Strategie: ``` class WeatherCache { private readonly CURRENT_TTL = 15 60 1000; // 15 Minuten private readonly FORECAST_TTL = 60 60 1000; // 60 Minuten

get(key: string): CachedData | null { const raw = localStorage.getItem('spfx-weather-' + key); if (!raw) return null; const parsed = JSON.parse(raw); if (Date.now() - parsed.timestamp > parsed.ttl) { localStorage.removeItem('spfx-weather-' + key); return null; } return parsed.data; } } ```

Error Handling:

• HTTP 401: «API-Key ungültig. Bitte prüfen Sie den Key in den Web Part-Einstellungen.»
• HTTP 404: «Standort nicht gefunden. Versuchen Sie es mit einer anderen Stadt.»
• HTTP 429: «API-Limit erreicht. Nächste Aktualisierung in [countdown].»
• Network Error: Zeige letzte gecachte Daten mit Hinweis «Offline — Daten von [timestamp]»
• Timeout (>5s): Abbruch mit Retry-Button

5. Implementation Details

Component-Architektur: `` WeatherWebPart (SPFx Entry) ├── WeatherProvider (Context + Service Injection) │ ├── ErrorBoundary │ │ ├── CurrentWeather (Hauptanzeige) │ │ │ ├── WeatherIcon (Animierte SVG-Icons) │ │ │ ├── TemperatureDisplay │ │ │ └── WeatherDetails (Wind, Humidity, etc.) │ │ ├── ForecastStrip (Horizontale Scroll-Karten) │ │ │ └── ForecastCard (3h-Intervall) │ │ └── AlertBanner (Wetterwarnungen) │ └── LoadingState / ErrorState / EmptyState └── PropertyPane (Konfiguration) ``

Hooks:

• useWeather(location, unit): Haupthook mit Loading/Error/Data State, Auto-Refresh via setInterval, Cache-Integration
• useGeolocation(): Browser Geolocation mit Permission-Handling
• useThemeDetection(): SharePoint Theme für adaptive Farben
• useResponsiveLayout(): Web Part-Breite erkennen für Mini/Standard/Full-Modus

6. Testing Strategy

7. Deployment

# Build & Package
gulp bundle --ship
gulp package-solution --ship

# Deployment via PnP PowerShell
Connect-PnPOnline -Url "https://tenant.sharepoint.com/sites/appcatalog"
Add-PnPApp -Path "./sharepoint/solution/weather-webpart.sppkg" -Overwrite

Fazit: Design for Less Complexity

Unser Motto bei CNEXT lautet: Design for less complexity, design for less overhead. Spec-Driven Development ist kein zusätzlicher Aufwand — es ist die Methode, um Overhead zu eliminieren. Wer heute lernt, Agenten präzise zu steuern, wird morgen die effizientesten Lösungen am Markt bauen.

Open Source & GitHub

Wir glauben an Open Source. Viele unserer Basis-Komponenten und Agentic-Leitfäden finden Sie auf unserem GitHub:

CNEXT GitHub Repository

Hinweis: Interne Enterprise-Blueprints sind exklusiv für unsere Kunden zugänglich.

Möchten Sie Ihr Team auf Agentic Engineering umstellen? Wir zeigen Ihnen, wie Sie VS Code und AI Agents optimal in Ihre Workflows integrieren.