--- title: "KI-nativer SDLC für Banken: KI-Agenten bis zur Produktion | S-PRO" url: https://s-pro.io/de/ai-native-sdlc lang: de description: "S-PRO liefert Banksoftware mit Claude-Agenten über den SDLC: Stories, Architektur, paralleler Build, Review und agentische QA mit menschlicher Freigabe." updated: 2026-11-04T20:35:18+00:00 source: S-PRO (https://s-pro.io) --- # Wie wir *bankfähige* Software mit KI-Agenten über den gesamten SDLC liefern. **Getestet.** Produktionsreifer Code, der Ihnen ruhige Nächte beschert. Versprechen 1 · Geschwindigkeit ### Schneller liefern, mit denselben Kontrollen. **Bankentaugliche Software**, ordentlich getestet, bereit für das Release-Review, sobald sie die Quality Gates besteht. Der Release-Rhythmus folgt dem Prozess des Kunden und der Reife des Produkts. Versprechen 2 · Entfesselte Kreativität ### Ihr Team denkt. Die Maschine setzt um. Implementierung und **Agent QA** sind automatisiert. Die Energie Ihres Teams verlagert sich auf Ideenfindung und Time-to-Market, nicht auf hierarchische Ausführung. ### Wartbarer Code Konventionen durchgesetzt. Hauseigene Skills. Lebende Dokumentation. Das zweite Jahr bremst nicht aus. ### Architektonisch, nicht improvisiert Module zuerst, Code danach. Senior-Engineers definieren Grenzen, bevor die KI eine Zeile schreibt. ### Getestet, mit Nachweis Jedes AC auf einem echten Browser verifiziert. 47-Szenario-Regression. Fehlgeschlagen = gesperrt. ### Senior-Teams, kein KI-Geschwafel Jede Zeile wird von einem Engineer überprüft, der fintech-taugliche Systeme bereits geliefert hat. Posteingang · hi@s-pro.io Heute · 09:42 Von **John Weber** An hi@s-pro.io ### Abonnement & Zahlungen für die Plattform benötigt Hallo S-PRO Team, Kurze Anfrage. Ich möchte **Abonnement und Zahlungen** zu meiner Plattform hinzufügen. Die Nutzerzahl wächst und wir müssen bis Q3 mit der Abrechnung beginnen. Wie schnell können Sie das umsetzen? Mit freundlichen Grüssen, John CEO · FinCo Antwort · von S-PRO Heute · 10:11 Von **Sarah Müller** · Product Owner An john@finco.ch ### Re: Abonnement & Zahlungen für die Plattform benötigt Hallo John, Wir liefern das **nächste Woche**. Mit freundlichen Grüssen, Sarah Product Owner · S-PRO So geht's Oder häufige Fragen lesen Scrollen, um zu sehen, was als Nächstes passiert Der Ablauf ## Wie sieht der KI-gestützte SDLC Schritt für Schritt aus? Sieben Schritte führen vom Business Case zum getesteten Feature. Claude bereitet vor, entwirft und prüft; Engineers prüfen die Ergebnisse, mit Vier-Augen-Review der Merge Requests und Security-Checkliste. 1. **Business Case in Stories übersetzen.** Epics und Stories entstehen in Jira, auf Basis früherer Projekte und der Confluence-Dokumentation. 2. **Agentisches Prototyping.** Claude baut aus den Stories einen funktionierenden Prototyp für frühes Feedback. 3. **Architektur erstellen.** Claude liest die tokenisierte Figma-Designebene und schreibt die Architektur nach Confluence. 4. **Architektur finalisieren.** Erkenntnisse aus dem Prototyp und die Architektur werden zu einem abgestimmten Zieldesign zusammengeführt. 5. **Feature umsetzen.** Backend und Frontend entstehen in parallelen Wellen, mit einem gestapelten Merge Request pro Welle. 6. **Code-Review.** Jeder Merge Request wird beim Öffnen gegen die Projektstandards geprüft, mit Vier-Augen-Review und Security-Checkliste. 7. **Agentische QA.** KI testet jedes Feature in einem echten Browser, legt Bugs in Jira an und berichtet mit Screenshots. Der Ablauf besteht aus Claude-Skills, die über MCP Werkzeuge des Teams lesen oder beschreiben: Jira und Confluence, eine Wissensdatenbank früherer Projekte, die IDE, GitHub Actions für die CI/CD-Pipeline und Playwright im echten Browser für die QA. Das Werkzeugset richtet sich nach dem finalen Tech-Stack des Kunden. 01 Phase 01 · Spezifikation & Design ## Konzentrieren Sie sich auf Ihr Business. Wir kümmern uns um das Produkt. Erfahrene Product Owner, Business Analysten und Engineers leiten den Aufbau, gestützt auf bewährte CI/CD-Prozesse, battle-tested Infrastruktur-Templates und KI, die dort eingesetzt wird, wo sie wirklich hilft. Bereits am ersten Tag sind Spec, Story-Tree und finale Wireframes in Ihren Tools. Sie bleiben nah an Ihren Kunden; wir liefern die Software. 1Kundenanfrage + Beratung ### Nicht „Was wollen Sie?" Sondern: Das funktioniert. Wir beginnen nicht mit einem 40-seitigen Aufnahmeformular. Der Wunsch des Kunden trifft ein; unser erfahrener Product Owner und BA antworten mit einer konkreten Form, abgeleitet aus jedem vergleichbaren Service, den wir bisher geliefert haben. Empfehlungen, kein Verhör. JW John Weber · CEO, FinCo · Kunde „Ich möchte **Abonnement und Zahlungen** zu meiner Plattform hinzufügen." Beratung · S-PRO Product Owner + BA Abgeleitet aus **17 ähnlichen Abonnement & Zahlungs-Engagements** Für einen Service wie Ihren empfehlen wir: - ✓**3 Plan-Stufen** mit monatlichem/jährlichem Umschalter und einem hervorgehobenen Plan. - ✓**14-tägige Testphase**, keine Karte im Voraus. Zahlung wird an Tag 12 erhoben. - ✓**Stripe-gehosteter Checkout** für PCI SAQ-A Umfang. (Adyen wenn Sie SEPA / iDEAL benötigen.) - ✓**Dunning-Sequenz**: 3 Wiederholungen über 7 Tage, E-Mail bei jedem Schritt, dann Downgrade. - ✓**MwSt.** pro Jurisdiktion (CH, EU, US) auf Rechnung. Mehrwährungs-Anzeige. - ✓**Admin-Override**, 30-Tage-Rückerstattung, vollständiges Audit-Log. **Abgeleitet aus** unserer Wissensdatenbank vergangener Engagements 2Wissensdatenbank → Features ### Gleiche Quelle, aufgeteilt in einen Feature-Baum. Die obigen Empfehlungen wurden nicht erfunden. Sie stammen aus unserem privaten RAG-Index aller gelieferten Projekte: Confluence-Specs, Jira-Tickets, GitLab-Verlauf, Retrospektiven. Derselbe Index zerlegt das Epic in einen sauberen Feature-Baum, jedes Feature bereit für Stories. Confluence Specs Vergangene Anforderungen 412 Jira Tickets Stories, AC, Defekte 8.4k GitLab Verlauf Code & Review-Muster 126 repos Retrospektiven Lessons Learned 47 **S-PRO Wissensdatenbank** Live · Privat & projektbezogen isoliert Epic: Abonnement & Zahlungen 8 Features · bereit für Stories F-01Plan-Auswahl F-02Testphasen-AktivierungPAY-101 ist hier F-03Zahlungserhebung (Stripe-gehostet) F-04Dunning & Wiederholungssequenz F-05MwSt.-Berechnung F-06Mehrwährungs-Anzeige F-07Admin-Override & Rückerstattung F-08Audit-Protokollierung 3Das Ergebnis: eine vollständige User Story ### Die Spec kommt in einer Form, die Sie in fünf Minuten prüfen können. Aus dem BA-Gespräch entworfen und im RAG-Kontext verankert. Abnahmekriterien sind überprüfbar. Edge Cases, die uns früher Probleme bereitet haben, sind bereits enthalten. Sie geben grünes Licht oder senden sie mit einem Kommentar zurück. PAY-101 Story Epic: Abonnement & Zahlungen Feature: F-02 Testphasen-Aktivierung P1 Bereit fürs Design ### Plan abonnieren und kostenpflichtige Testphase starten User Story **Als** registrierter Nutzer auf der Plattform, **möchte ich** einen Abonnementplan auswählen und eine 14-tägige kostenlose Testphase starten, ohne vorab Zahlungsdetails eingeben zu müssen, **damit** ich die kostenpflichtigen Funktionen risikofrei bewerten kann, bevor ich mich entscheide. Abnahmekriterien - ✓ Nutzer sieht drei Pläne (Starter, Pro, Business) mit Preisen in der Nutzerwährung, monatlichem/jährlichem Umschalter und einem hervorgehobenen Plan. - ✓ Die Auswahl eines Plans startet sofort eine Testphase; Zahlungsdetails werden an Tag 12 über eine Stripe-gehostete Seite erhoben (PCI SAQ-A Umfang). - ✓ Schlägt die Zahlung beim ersten Versuch fehl, läuft das Dunning 7 Tage (3 Wiederholungen), bevor der Zugang herabgestuft wird. Nutzer wird bei jedem Schritt per E-Mail benachrichtigt. - ✓ MwSt. nach Jurisdiktion (CH, EU, US) berechnet und auf Rechnung angezeigt; Rechnungen im Confluence-verknüpften Archiv-Bucket gespeichert. - ✓ Admin kann Plan überschreiben, Testphase verlängern oder innerhalb von 30 Tagen aus dem Back-Office erstatten (audit-protokolliert). Verknüpft: 3 vorherige Epics RAG-Kontext: 18 Dokumente Entwurf durch Claude · Überprüft durch BA 4UI/UX-Ideenfindung, am Marktbesten validiert ### Erstklassige Flows, nicht von Grund auf erfunden. Unser Designer ideiert mit Claude unter Verwendung des bestehenden Figma-Design-Systems des Projekts und vergleicht anschliessend mit realen Flows aus Mobbin (Airbnb, Duolingo, Stripe, Netflix). Das Ergebnis: Abonnement- und Checkout-Flows, die sich zum Produkt zugehörig anfühlen und Muster befolgen, die Nutzer bereits kennen. Co-Pilot #### Claude Erstellt Erstversionen von Layouts, Mikrotexten und Komponentenvarianten und wendet dabei automatisch die bestehenden Design-Tokens des Projekts an. M Validierung #### Mobbin Echte Flows aus erfolgreichen Apps: Stripe Checkout, Netflix Plan-Wechsler, Spotify Upgrade. Wir vergleichen unsere mit deren, bevor wir liefern. Quelle der Wahrheit #### Figma Unser vorgefertigtes Design-System. Dieselben Tokens, Komponenten und Primitive, auf denen der Rest des Produkts aufgebaut ist, damit neue Screens dazugehören. 5Wireframes & dokumentierter Übergabe ### Spec, Design und Tickets – direkt in Ihren Tools. Die Lieferobjekte leben in keinem KI-Tool. Sie landen dort, wo Ihr Team bereits arbeitet: Confluence für die Spec, Jira für den Backlog, Figma für die UI. Engineering kann morgen starten. Abonnieren · Plan-Auswahl Starter $0/mo Pro $29/mo Business $99/mo Abrechnungszyklus · Monatlich | Jährlich (–20%) Zahlungsanbieter · Stripe (gehostet) MwSt. · Automatisch nach Region berechnet 14-tägige kostenlose Testphase starten Confluence · Epic-Spec Geschäftskontext, BA Fragen & Antworten, Entscheidungen, RAG-Referenzen. Lebendes Dokument. Jira · Epic + 14 Stories Story-Tree mit Abnahmekriterien, Schätzungen und Priorisierung. Backlog-bereit. Figma · Wireframes & finales Design Plan-Auswahl, Checkout, Erfolg, Abrechnungs-Backoffice. Alles auf dem Design-System. 02 Phase 02 · Entwicklung ## Tickets landen in der IDE. Engineers liefern. Die Arbeit wechselt nicht in ein anderes Tool. Sie kommt dorthin, wo der Engineer bereits ist. Claude lädt das Ticket und die Confluence-Spec über MCP in die IDE, die Arbeit teilt sich in Backend- und Frontend-Tracks auf, und unsere hauseigenen Claude-Skills übernehmen die Muster, die wir schon hundertfach geliefert haben. 1Claude liest zuerst FinCos Regelwerk ### KI, die Ihre Codebasis respektiert. Bevor Claude eine Zeile Zahlungscode schreibt, lädt es FinCos Projektvertrag: Dateistruktur, Namenskonventionen, Änderungsumfang für diesen Sprint, was ausser Reichweite liegt. Der SubscriptionController, der im PR landet, fühlt sich an wie FinCos bestehende Services. Gleiche Muster, gleiche Grenzen, gleiche Sprache. Keine Zufalls-Refactorings. Keine Konventionsverstösse. Kein „KI macht KI-Dinge." claude · finco-platform Projektvertrag ›Projektregelwerk für finco-platform laden ✓claude.mdProjektkonventionen & Dateistruktur ✓docsarchitecture.md, code-style.md ✓eslintHausregeln & Projektüberschreibungen ✓scopeDieser Sprint: Abonnement & Zahlungen ✓no-goauth-service, payments-legacy (ausserhalb des Umfangs) → Arbeitet nach FinCos Regeln, nicht den Standardwerten. 2Das Ticket kommt zur IDE ### Claude MCP bringt alles rein. Der Engineer wechselt keine Tabs. Claude lädt PAY-101 aus Jira, die Spec aus Confluence und die relevantesten früheren Implementierungen aus unserer RAG-Wissensbasis – alles in Sekunden in den Editor. claude · payments-service MCP verbunden ›PAY-101 mit Spec und Vorarbeiten laden ✓jiraTicket geladen PAY-101 — Plan abonnieren ✓confluenceSpec geladen Abonnement & Zahlungen / Discovery ✓rag3 frühere Implementierungen referenziert ✓skills13 Haus-Skills für diesen Stack verfügbar → Kontext geladen. Bereit zur Implementierung. 3Ein Epic, zwei Tracks ### Backend und Frontend parallel. Der gleiche geladene Kontext verteilt sich auf zwei Engineers. Jeder erhält den für seinen Stack relevanten Arbeitsanteil plus einen kuratierten Satz hauseigener Claude-Skills, die über Jahre von S-PRO-Projekten verfeinert wurden. PAY-101 Plan abonnieren und kostenpflichtige Testphase starten Backend-Track #### Abonnement- & Abrechnungs-Services Der Senior-Backend-Engineer entwirft zunächst die Modularchitektur (Services, Adapter, Worker), dann implementiert er innerhalb dieser Module mithilfe hauseigener Claude-Skills. Frontend-Track #### Plan-Auswahl & Checkout-UI Designs kommen über MCP aus Figma. Die Aufgabe des Engineers: generierte Komponenten validieren, mit der API verbinden und Barrierefreiheit & Zustände behandeln. 4Backend: Architektur zuerst ### Module vor Code. Der Senior-Backend-Engineer entwirft zunächst die Modulgrenzen: was ein Service ist, was ein Worker, was ein Adapter. Sobald die Architektur überprüft ist, generieren hauseigene Claude-Skills den Boilerplate innerhalb des Vertrags jedes Moduls. payments-service · Modularchitektur API · Controller SubscribeController Service SubscriptionService Service PlanService Adapter StripeAdapter Worker WebhookHandler Worker DunningWorker Repository SubscriptionRepository Repository InvoiceRepository Service VATCalculator Backend POST /subscriptions Vertrag automatisch synchronisiert Frontend useSubscription() ### Backend liefert einen Endpunkt. Frontend Claude sieht ihn in derselben Stunde. Sobald der SubscriptionController `POST /subscriptions` und `POST /subscriptions/:id/cancel` bereitstellt, synchronisiert sich der API-Vertrag automatisch in das Frontend-Repo. Wenn der Frontend-Engineer das nächste Mal Claude öffnet, sind die neuen Endpunkte bereits im Kontext. Kein veralteter Postman-Collection. Kein Slack-Ping zu Fragen zum Request-Body. Frontend verbindet sich mit der API in derselben Stunde, in der Backend sie liefert. 5Frontend: Figma MCP zu Komponente ### Designs fliessen in Code, werden nicht neu gebaut. Der Figma-Frame ist die Quelle der Wahrheit. Ein Figma-MCP-Server liest das Design, und hauseigene Claude-Skills generieren eine React-Komponente mit unseren bestehenden Design-Tokens. Aufgabe des Engineers: validieren, mit der API verbinden und liefern. Figma · Plan-Auswahl Figma MCP React · PlanSelector.tsx export const PlanSelector = ({ plans, onSelect }) => { const [billing, setBilling] = useState('monthly'); return ( {plans.map(p => ( ))} ); }; CI/CD · Qualitätsgates · jeder PR Grün · Merge-Gate bestanden Lint & Format ESLint · Prettier Bestanden Typprüfung TypeScript strict Bestanden Unit-Tests Abdeckungsschwelle 85% 87% Build Backend + Frontend Bestanden Sicherheitsscan Dependabot · gitleaks Bestanden Smoke-Tests 10 kritische Szenarien 10/10 **Grün = Merge.** Rot = bleibt offen. Das Gate ist für jeden Engineer, jeden PR, jedes Projekt gleich. 03 Phase 03 · Infrastruktur ## Vom Feature zur Cloud-Topologie, mit einem Prompt. Der payments-service braucht mehr als Code. Er braucht eine Datenbank, eine Queue, Secrets, einen Webhook-Endpunkt, Observability und einen Ort zum Laufen. Claude entwirft den Infrastructure-as-Code aus Mustern, die wir zuvor auf AWS, Azure und GCP eingesetzt haben, und generiert Terraform, Pulumi oder CDK wie erforderlich. Der Engineer überprüft, härtet ab und wendet an. 1Cloud-Topologie kartieren ### Ressourcen zuerst, Code danach. Aus früheren Abonnement & Zahlungs-Deployments schlägt Claude den Ressourcen-Satz vor: Edge, Compute, Daten, Secrets, Observability, Integrationen. Der Engineer kürzt, was für diesen Client nicht benötigt wird (kein Redis, wenn die bestehende App bereits einen hat) und ergänzt Spezifisches. payments-service · Cloud-Topologie · AWS Beispiel (wir liefern auch auf Azure / GCP) Edge Route 53 + CloudFront Edge ALB / API Gateway Integration Stripe Webhook-Endpunkt Compute · ECS payments-service Compute · ECS webhook-handler Compute · CronJob dunning-worker Daten · RDS subscriptions-db Daten · ElastiCache sessions-redis Secrets Secrets Manager Observability CloudWatch · Logs & Metriken Observability X-Ray · Traces Observability PagerDuty Alerts 2Claude entwirft das IaC ### Terraform für die Cloud, Helm für den Cluster. Gleiche Vorgehensweise wie beim Backend-Code: hauseigene Claude-Skills generieren Terraform-Module und Helm-Values als Erstversion. Der Engineer liest jede Zeile, härtet IAM- und Netzwerkregeln ab und wendet an. Nichts ist autonom, aber es geht schnell. Terraform · payments.tf # Abonnement & Zahlungs-Stack module "payments_db" { source = "./modules/rds-postgres" name = "subscriptions" instance_class = "db.t4g.small" multi_az = var.env == "prod" } module "payments_service" { source = "./modules/ecs-service" name = "payments-service" cpu = 512 memory = 1024 desired_count = var.env == "prod" ? 3 : 1 secrets = [ "stripe/secret_key", "stripe/webhook_secret", ] } module "webhook_endpoint" { source = "./modules/stripe-webhook" events = [ "invoice.payment_failed", "customer.subscription.updated", ] } Helm · values.yaml replicaCount: {{ .Values.env.replicas }} image: repository: payments-service tag: {{ .Chart.AppVersion }} resources: requests: cpu: 200m memory: 512Mi limits: cpu: 500m memory: 1Gi autoscaling: enabled: true minReplicas: 2 maxReplicas: 10 targetCPU: 70 env: - name: DATABASE_URL valueFrom: secretKeyRef: payments-db 3Eine Vorlage, drei Umgebungen ### Von Dev bis Prod mit derselben Quelle der Wahrheit. Dieselben Terraform- und Helm-Module werden auf Dev, Staging und Produktion angewendet. Unterschiede sind umgebungsspezifische Variablen (Instanzgrössen, Replikat-Anzahl, Aufbewahrungsfenster), keine manuell bearbeiteten Überschreibungen. Abweichungen werden nächtlich geprüft. #### Entwicklung Synchronisiert Letzter Applyvor 12 Min. Ressourcen42 Replikate1 Datenbankt4g.micro #### Staging Synchronisiert Letzter Applyvor 2 Std. Ressourcen42 Replikate2 Datenbankt4g.small #### Produktion Synchronisiert Letzter ApplyGestern Ressourcen42 Replikate3 · Multi-AZ Datenbankt4g.small + RR 04 Phase 04 · Agent QA ## QA ohne den Engpass. Unser **Agent QA** zieht QA-bereite Tickets aus Jira, entwirft Testszenarien aus den Abnahmekriterien, und Playwright MCP klickt diese auf echten Browsern durch. Dieselben Szenarien laufen als nächtliche Regression. Das Ergebnis ist ein Testbericht mit Nachweis, kein grünes Häkchen aus einer Black Box. 1QA-Bereites abrufen ### Claude listet die bereiten Tickets zuerst auf. QA jagt keine Tickets. Claude liest Jira und gruppiert alles nach Status – was Dev als bereit meldet, was in Arbeit ist, was blockiert ist – damit der Tester das gesamte Paket auf einmal sieht. claude · payments-qa Jira MCP ›Was ist beim Abonnement & Zahlungs-Epic für QA bereit? Bereit / QA-Review5von Dev-Seite erledigt, wartet auf QA PAY-101Plan abonnieren und kostenpflichtige Testphase starten PAY-103Plan-Upgrade & Downgrade-Flow PAY-104Stripe-Webhook-Handling bei fehlgeschlagener Zahlung PAY-105Dunning-E-Mails für Wiederholungssequenz PAY-108Admin: Rückerstattung innerhalb von 30 Tagen aus dem Back-Office In Bearbeitung2wird noch implementiert PAY-109Steuerrechnungs-PDF-Generierung PAY-110Mehrwährungs-Anzeige auf Plan-Auswahl Blockiert1 PAY-112SEPA via Adyen *(wartet auf Produktionszugangsdaten)* → 5 Tickets bereit zum Testen. Szenarien aus Abnahmekriterien werden entworfen… 2Szenarien aus AC geschrieben, in einfachem Deutsch ### Keine fragilen Selektoren. Keine Page Objects. Für jedes Abnahmekriterium entwirft Claude ein nummeriertes Szenario, das jeder Tester (oder jeder Client-Stakeholder) lesen kann. Der QA-Engineer überprüft, bearbeitet und übergibt es an Playwright MCP zum Ausführen. Abnahmekriterium PAY-101 · AC-002 Klar formuliertes Testszenario Entwurf durch Claude · Ausführung durch Playwright MCP 1. Als Testnutzer `alice@finco.ch` anmelden (kein aktives Abonnement). 2. Zu `/pricing` navigieren. 3. **Testphase starten** auf der **Pro**-Plan-Karte klicken. 4. Überprüfen, ob die Seite zu `/dashboard/pro` weiterleitet. 5. Überprüfen, ob das Testphasen-Banner **„14 Tage verbleibend"** anzeigt. 6. Überprüfen, ob **keine Zahlungsseite beim ersten Einstieg angezeigt wird**. 7. Uhr um 11 Tage vorrücken via `scheduler.advance(11d)`. 8. Überprüfen, ob der Nutzer die **Zahlungsmethode-hinzufügen**-E-Mail erhält. 9. Überprüfen, ob `/billing` den **„Zahlungsmethode hinzufügen"**-CTA anzeigt. 3Claude klickt sich durch, auf einem echten Browser ### Playwright MCP führt das Szenario aus. Claude steuert Chromium Schritt für Schritt, liest das Live-DOM (nicht nur Pixel), macht Screenshots bei Fehlern und führt nach Korrekturen erneut aus. Dieselben Szenarien laufen nächtlich als vollständige Regression – alles, was fehlschlägt, erhält einen Bericht, der vor dem Standup im Team-Slack wartet. Playwright · PAY-101 · AC-002 wird ausgeführt Läuft - ✓Angemeldet als `alice@finco.ch` - ✓Zu `/pricing` navigiert - ✓**Testphase starten** auf Pro-Plan-Karte geklickt - ✓Weitergeleitet zu `/dashboard/pro` - ▶Testphasen-Banner zeigt **14 Tage verbleibend** wird überprüft… - ○Keine Zahlungsseite beim ersten Einstieg überprüfen - ○Uhr vorrücken `scheduler.advance(11d)` - ○Zahlungsmethode-hinzufügen-E-Mail gesendet überprüfen https://app.finco.ch/dashboard/pro 🎉 14 Tage verbleibend auf Ihrer Pro-Testphase **Nächtliche Regression** · alle 47 Szenarien · Fehlschläge landen vor dem Standup in Slack 4Kunde und Admin, parallel ### Zwei Rollen, ein Regressionsdurchlauf. PAY-101 hat zwei Rollen im Spiel: den Kunden, der einen Plan abonniert, und den Admin im Back-Office, der Pläne überschreibt, Testphasen verlängert und Abbuchungen erstattet. Beide Flows laufen parallel in einem einzigen Browserfenster mit pro Tab isolierten Cookies, Sessions und Storage. Ein Regressionsdurchlauf bestätigt, dass der Kunde abonniert hat, der Admin den Audit-Log-Eintrag gesehen hat und die Überschreibung angewendet wurde – mit null Querverunreinigung zwischen den Sessions. https://app.finco.ch/dashboard/pro CUSTOMER 🎉 14 Tage verbleibend auf Pro-Testphase https://admin.finco.ch/users/alice ADMIN ✓ Audit-Log: Testphase verlängert (Admin: ops@finco.ch) **Beide Sessions verifiziert** · Cookies, Sessions, Storage pro Tab isoliert · null Querverunreinigung 5Testbericht mit Nachweis ### Ein abgezeichneter Bericht, kein grünes Häkchen. Jeder QA-Durchlauf erzeugt einen Bericht, den Sie auditieren können: welches AC geprüft wurde, mit welchen Schritten, mit welchem Ergebnis. Fehlschläge enthalten den genauen Reproduktionspfad und ein Ein-Klick-**Bug kopieren**, das direkt in Jira eingefügt werden kann. ### Testbericht: PAY-101 · Plan abonnieren **Datum:** 2026-05-07 · **Umgebung:** finco-dev (https://app.dev.finco.ch) · **Branch:** feat/PAY-101-subscribe-trial **Tester:** Claude AI (Senior QA) · **Browser:** Chromium (Playwright MCP) · **Suite:** 47 Szenarien · gelaufen in 4m 12s #### Zusammenfassung 5 Gesamt AC 4 Bestanden 1 Fehlgeschlagen 0 Blockiert 80% Bestehensrate 1 Bugs gefunden #### Testabdeckungsmatrix | Bereich | AC | Bestanden | Fehlgeschlagen | Blockiert | Abdeckung | | --- | --- | --- | --- | --- | --- | | Plan-Auswahl & Preisgestaltung | AC-001 | 1 | 0 | 0 | 100% | | Testphase ohne Zahlung starten | AC-002 | 1 | 0 | 0 | 100% | | Dunning bei fehlgeschlagener Zahlung | AC-003 | 0 | 1 | 0 | 0% | | MwSt.-Berechnung nach Jurisdiktion | AC-004 | 1 | 0 | 0 | 100% | | Admin-Override & Rückerstattung | AC-005 | 1 | 0 | 0 | 100% | | Gesamt | 5 | 4 | 1 | 0 | 80% | #### Fehlgeschlagen (1 / 5) AC-003 FEHLSCHLAG Dunning-E-Mail wird beim zweiten Versuch ausgelöst, nicht beim ersten **Aus AC:** „Schlägt die Zahlung beim ersten Versuch fehl, läuft das Dunning 7 Tage (3 Wiederholungen), bevor der Zugang herabgestuft wird. Nutzer wird bei jedem Schritt per E-Mail benachrichtigt." Durchgeführte Schritte 1. Abonnement mit Stripe-Fehlschlag-Testkarte `4000 0000 0000 0341` einrichten 2. Ersten Abbuchungsversuch um **09:00** via Webhook-Simulator ausgelöst 3. Auf ersten Wiederholungsversuch um **09:15** gewartet 4. **FEHLSCHLAG —** Keine Dunning-E-Mail bis zum 2. Versuch um **09:30** erhalten 5. Erwartet: E-Mail nach erstem Fehlschlag. Tatsächlich: erst nach zweitem. ### 47 Szenarien, ein Knopf, *jeder im Team*. Sobald PAY-101s 47 Szenarien bestehen, sind sie im Testmanagement-System des Projekts registriert: versionskontrolliert, getaggt, mit Abnahmekriterien verknüpft. Wenn morgen PAY-102 geliefert wird, läuft dieselbe Suite als Gate. In sechs Monaten, wenn FinCo einen neuen QA einarbeitet, führt dieser QA am ersten Tag die gestrige Regression aus. Claude kann die Suite ebenfalls ausführen, kein Mensch erforderlich für „ist der Abonnement-Flow noch grün?" Regression ist keine Person. Es ist ein Knopf. 05 Phase 05 · Deployment & Betrieb ## Release Candidate, Retrospektive, Wissenskreislauf geschlossen. PAY-101 endet nicht mit „gemerged". Der Release wird ausgeliefert, das System beobachtet, das Team lernt, und das nächste Epic beginnt mit dem, was wir gerade gelernt haben, bereits eingebaut. 1Release Notes, aus gemergter Arbeit entworfen ### PRs lesen. Notes schreiben. Abzeichnen. Claude liest die PAY-101-PRs und die verlinkten Jira-Tickets und entwirft dann Release Notes im Hausformat von FinCo: kundenorientiertes Changelog, internes API-Diff, Migrationsnotes für das Plattform-Team. Engineering zeichnet ab; nichts wird zweimal von Hand getippt. v2.14.0 · 2026-05-07 Epic: Abonnement & Zahlungen ### Release Notes · PAY-101 wird geliefert Kundenorientiertes Changelog - NEU14-tägige kostenlose Testphase auf Pro- und Business-Plänen, keine Karte im Voraus. - NEUStripe-gehostete Zahlungserhebung an Tag 12 der Testphase. - VERBMehrwährungs-Anzeige auf dem Plan-Wähler (CHF, EUR, USD). Internes API - +`POST /api/v1/subscriptions` - +`POST /api/v1/subscriptions/:id/cancel` - ~`GET /api/v1/billing/invoices` gibt jetzt MwSt. zurück. Migrationsnotes - ENVNeu: `STRIPE_API_KEY`, `STRIPE_WEBHOOK_SECRET` im Secrets Manager. - SQLMigration `2026_05_07_subscriptions_init.sql` angewendet. 2Runbooks für die neuen Fehlermodi ### Von SRE geprüft, bevor der erste Vorfall eintritt. Stripe-Webhook stockt. Dunning-Queue überlastet. VAT-API rate-limitiert. Fehlgeschlagene Rechnungsgenerierung. Jedes Szenario erhält ein aus dem Architekturdiagramm generiertes Runbook: Wiederherstellungspfad, On-Call-Eskalation, Rollback-Auslöser. Stripe-Webhook stockt Wiederherstellung · Eskalation · Rollback Runbook bereit Dunning-Queue überlastet Runbook bereit VAT-API rate-limitiert Runbook bereit Fehlgeschlagene Rechnungsgenerierung Runbook bereit 3Observierbares Rollout, zuerst Canary ### Hinter einem Flag, auf einem Slice des Traffics. PAY-101 wird hinter einem Feature-Flag ausgeliefert, per Canary auf einen Slice von FinCos Traffic begrenzt. Metriken zu Abonnement-Erfolg, Dunning-Auslöser und MwSt.-Berechnung sind vor dem Deploy eingebunden. Anomalie-Schwellenwerte werden in den ersten zwei Wochen echter Nutzung kalibriert. Canary · PAY-101 · Produktion 25%des Traffics Abonnement-Erfolg 99.2% Dunning-Auslöserate 0.3% MwSt.-Berechnungslatenz · p95 84ms 4Retro, die sich aufbaut ### PAY-102 startet mit PAY-101s Lessons already geladen. Was funktioniert hat, was gerutscht ist, was uns überrascht hat. Erfasst und zurück in die Wissensdatenbank indexiert. Das nächste Epic auf diesem Produkt (oder einem vergleichbaren) startet automatisch klüger. Funktioniert - Figma MCP hat 3 Entwicklungstage bei der Plan-Auswahl gespart. - RAG-Kontext bei AC-002 hat den Trial-Edge-Bug vor dem Merge gefunden. - Haus-`stripe-checkout`-Skill: null Nacharbeit. Gerutscht - Dunning-E-Mail-Timing (AC-003): in QA abgefangen, nicht im Unit-Test. - Adyen-Zugangsdaten blockierten PAY-112 um 3 Tage. Überrascht - MwSt. für CH war einfacher als erwartet (Einheitssatz). - Mehrwährungs-Anzeige war am ersten Tag fertig. In die S-PRO Wissensdatenbank indexiert · PAY-102 startet klüger 5Zwei Wochen nach Release: das erste Audit ### Jahr-Zwei-Projekte verlangsamen sich nicht. Sie beschleunigen sich. Zwei Wochen nach der Lieferung von PAY-101 führt Claude das erste geplante Tech-Audit des neuen Codes durch: Architekturabweichungen, ungenutzte Exports, tote Branches in der Dunning-Logik, zurückgefallene Dependencies. Von hier an läuft das Audit alle zwei Wochen über die gesamte Codebasis. Tech-Audit · geplant 2026-05-21 Gesund ### PAY-101 · 14 Tage nach Release - 0 Architekturabweichungen vom Regelwerk OK - 2 ungenutzte Exports in `subscription.service.ts` Niedrig - 1 toter Branch in der Dunning-Wiederholungslogik Niedrig - 3 veraltete Dependencies: `stripe`, `zod`, `pg` Mittel **Nächster Sprint:** 4 priorisierte Korrekturen, vor der Sprint-Planung in Confluence eingestellt. In drei Monaten fühlt sich PAY-101 noch an wie am Tag der Lieferung. Eigene Produkte ## Wo setzen wir Claude Code bereits in der Entwicklung ein? - **Finka.** Das Team nutzt Claude Code in der Entwicklung der [Finka-Plattform für den digitalen Handel mit Metallkonzentraten](https://s-pro.io/casestudy/finkametals-platform-for-digital-metals-concentrate-trading). Die Entwicklung wurde beschleunigt; einen Prozentwert nennen wir nicht. - **Muuvr.** Das Team nutzt Claude Code mit Figma MCP, um Screens aus vorhandenen Komponenten zusammenzusetzen und mobile Funktionen zu entwickeln. Laut Schätzung des Teams: Der Zyklus zur Validierung von Interface-Ideen ist etwa 50% kürzer, die Entwicklungsproduktivität 30–40% höher. Die Muuvr-Werte sind Schätzungen des Teams, keine gemessenen Benchmarks. Unser Team umfasst Claude-zertifizierte Engineers und Architekten. Häufige Fragen ## Was wir gefragt werden. Echte Fragen von echten Interessenten, direkt beantwortet. KI-Coding-Assistenten sind zwar unglaubliche Werkzeuge, aber keine Zauberstäbe für komplexe Software. Wenn Sie über einen einfachen Prototyp hinausgehen, stossen KI-Tools schnell an **Kontextgrenzen**, haben Mühe mit komplexen Integrationen und verlieren den Überblick bei Dutzenden gleichzeitiger Tickets. Wir bringen das Engineering-Mindset mit, das nötig ist, um Kontextfenster, Token-Optimierung und Systemarchitektur zu managen, damit Ihr Projekt tatsächlich die Ziellinie überquert. **Ja, es ist sicher.** Wir verwenden Enterprise-Grade-Umgebungen und strenge Data-Governance-Richtlinien. Wir stellen sicher, dass Ihr geistiges Eigentum vollständig Ihnen gehört und vollständig isoliert bleibt. **Absolut.** Unsere KI-SDLC-Methodik ist vollständig *modell-agnostisch*. Wenn Ihr Compliance-Team den Einsatz von Tools wie Claude oder OpenAI einschränkt, können wir Ihre Entwicklung über sichere, genehmigte Enterprise-Foundries oder private Cloud-Umgebungen wie **AWS Bedrock** oder **MS Foundry** leiten. **Nein.** Es gibt einen gewaltigen Unterschied zwischen schnellem „KI-Geschwafel" und unserer bankentauglichen Methodik. Wir lassen KI nicht unkontrolliert Code schreiben; wir setzen KI ein, um *die Workflows von Senior-Engineers zu verbessern*. Jede Codezeile durchläuft rigoroses **Agent QA** und automatisiertes Testing (wie Playwright), um sicherzustellen, dass die Architektur solide, skalierbar und wartbar ist. Unkontrollierte KI-Entwicklung kann durch schlechte *„Tokenomics"* schnell kostspielig werden. Unsere Architekten strukturieren Prompts und Kontext-Sharing, um den Token-Verbrauch stark zu optimieren. Wir wissen genau, wie man die Technologie effizient einsetzt, damit Ihr Projekt im Budget bleibt, ohne Abstriche bei der Qualität zu machen. Die KI-Landschaft ändert sich schnell, daher überprüfen wir unseren Prozess laufend. Wir benchmarken, testen und integrieren kontinuierlich die neuesten State-of-the-Art-Modelle und Tools in unsere Pipeline. Unsere Landingpage spiegelt unseren aktuellen Stack wider, und wir **aktualisieren unsere Methodik transparent alle paar Monate**, damit Sie stets den bestmöglichen Wettbewerbsvorteil erhalten. **Überhaupt nicht.** Unser Ansatz automatisiert die mühsamen Ausführungs- und Validierungsphasen, was unsere Senior-Engineers und Product Owner befreit, als *echte Berater* zu agieren. Indem wir die KI das Schwergewicht der Code-Generierung übernehmen lassen, konzentrieren sich unsere Engineers vollständig auf Ihre Geschäftslogik, kreative Problemlösung und darauf, dass das Produkt Ihrer Vision perfekt entspricht. KI-Agenten übernehmen Spezifikationsentwürfe, Boilerplate, Testgenerierung und Dokumentation, sodass Engineers mehr Zeit für Review und Design haben. Die Lieferzeit hängt vom Umfang ab und wird nach der Discovery geschätzt. Review und Tests bleiben bestehen, sodass Produkte Ihre Nutzer früher erreichen, ohne die Quality Gates aufzugeben. Sieben Schritte: Business Case in Jira-Stories übersetzen, agentischen Prototyp bauen, Architektur aus der Figma-Designebene erstellen, finalisieren, Backend und Frontend in parallelen Wellen umsetzen, jeden Merge Request gegen Projektstandards prüfen und agentische QA im echten Browser durchführen. Merge Requests erhalten ein Vier-Augen-Review und eine Security-Checkliste. Teams, die es einsetzen, berichten von Gewinnen. Bei Muuvr schätzt das Team den Zyklus zur Validierung von Interface-Ideen auf etwa 50% kürzer und die Entwicklungsproduktivität auf 30–40% höher; das sind Schätzungen des Teams. Bei Finka beschleunigte Claude Code die Entwicklung; einen Prozentwert nennen wir nicht. Link in die Zwischenablage kopiert Sprache - [EN](https://s-pro.io/ai-native-sdlc) - [DE](https://s-pro.io/de/ai-native-sdlc) - [FR](https://s-pro.io/fr/) [In Kontakt treten](https://s-pro.io/de/kontakt)