Deterministische Gates vs. agentische Schritte
Deterministische Gates sind nicht verhandelbar: PHPUnit, PHPStan, Composer Audit, Diff-Limits, Secret-Scans, Lizenz-Checks. Sie laufen bei jedem Commit und bei jedem Agent-Run – ohne LLM-Interpretation. Grün bedeutet grün, rot stoppt die Pipeline.
Agentische Schritte ergänzen dort, wo klassische Tools an Grenzen stoßen: PR-Beschreibungen aus Diffs generieren, Testlücken identifizieren, Migrations-Risiken in natürlicher Sprache erklären, oder Code-Review-Hinweise vorsortieren. Diese Schritte sind advisory – sie blockieren nicht das Deployment, außer sie finden explizite Policy-Verletzungen.
Die goldene Regel bei Agenticode: Niemals einen agentischen Schritt als einzigen Quality-Gate. Der Agent in der Pipeline darf vorschlagen, aber PHPUnit entscheidet.
name: Agentic CI
on: [push, pull_request]
jobs:
deterministic-gates:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: shivammathur/setup-php@v2
with: { php-version: '8.3' }
- run: composer install --no-interaction
- run: composer phpstan
- run: vendor/bin/phpunit
- run: composer audit
- run: ./scripts/check-diff-limit.sh 400
agent-advisory:
needs: deterministic-gates
runs-on: ubuntu-latest
steps:
- run: php bin/agent-pr-summary.php > pr-summary.md
- run: php bin/agent-test-gap-hint.php > test-gaps.md
continue-on-error: true
Agent-Schritte in der Pipeline implementieren
Agentische CI-Schritte laufen headless: PHP-Skripte rufen LLM-APIs mit festen Prompts und strukturiertem Output auf. Input ist der Git-Diff, PHPStan-Report, Coverage-XML – kein ganzer Repo-Kontext. Output ist JSON oder Markdown, versioniert als Pipeline-Artefakt.
Prompts für CI sind strenger als für IDE-Agents: niedrigere Temperatur, festes Output-Schema, Timeout und Token-Limits. Bei Parse-Fehlern schlägt der Schritt fehl – aber blockiert nicht das Deployment, wenn er als advisory markiert ist.
Für Deployment-Gates nutzen wir Agents nur mit Fallback: z.B. Changelog-Generierung aus Conventional Commits – wenn der Agent scheitert, greift ein Template. Produktions-Deploys hängen nie an LLM-Verfügbarkeit.
<?php
declare(strict_types=1);
// bin/agent-pr-summary.php – headless CI-Agent
$diff = shell_exec('git diff origin/main...HEAD') ?: '';
$phpstan = file_get_contents('build/phpstan.json') ?: '{}';
$payload = json_encode([
'diff' => mb_substr($diff, 0, 50000),
'phpstan_errors' => json_decode($phpstan, true)['files'] ?? [],
'schema' => [
'summary' => 'string',
'risk_level' => 'low|medium|high',
'suggested_reviewers' => ['string'],
],
], JSON_THROW_ON_ERROR);
// API-Call mit festem System-Prompt und temperature=0
$response = callLlmApi($payload);
$parsed = json_decode($response, true, 512, JSON_THROW_ON_ERROR);
file_put_contents('pr-summary.md', "# Agent Advisory\n\n{$parsed['summary']}\n");
exit($parsed['risk_level'] === 'high' ? 1 : 0); // advisory: exit 1 = warning only
Deployment und Observability
Agentische Entwicklung ändert Deployment-Frequenz: mehr kleine Diffs, häufigere Releases. Pipelines brauchen Feature Flags, Canary-Deploys und schnelle Rollbacks. Agenticode integriert deploy_status-Tools via MCP, damit Post-Deploy-Agent-Loops Smoke-Tests automatisch ausführen.
Observability schließt den Kreis: Jeder Deploy korreliert mit Agent-Run-Metadaten (trace_id, Policy-Version, Loop-Iterationen). Bei Incidents wissen Sie, welcher Agent-Run welchen Code produziert hat – essenziell für Audit und Debugging.
Kunden in Köln erhalten von uns nicht nur YAML-Dateien, sondern Runbooks: Was tun, wenn PHPStan nach einem Agent-Run rot ist? Wann Human-Review erzwingen? Wie Agent-Policies in der Pipeline versionieren? Das macht agentische CI/CD betriebssicher.
#!/usr/bin/env bash
# post-deploy-agent-smoke.sh
set -euo pipefail
TRACE_ID="${AGENTIC_TRACE_ID:-unknown}"
DEPLOY_URL="${DEPLOY_URL:?}"
curl -sf "$DEPLOY_URL/health" | jq -e '.status == "ok"'
curl -sf "$DEPLOY_URL/api/v1/version" | jq -e '.commit != ""'
php bin/log-agentic-event.php \
--event=deploy_verified \
--trace_id="$TRACE_ID" \
--url="$DEPLOY_URL"
echo "Deploy $TRACE_ID verified."