A demonstration of the agentic engineering method we've shipped: PayoutKit, a hardened Stripe Connect module, extracted from a working production marketplace codebase (PickNDeal) using the method as a code-surgery instrument. Agents read the source repo, identify the reusable Stripe Connect surface, sanitise it, regenerate it into a clean standalone repository, all under a human review loop with audit trail of every decision.
The setup
PickNDeal had shipped a full Stripe Connect integration: destination charges with on-top platform fees, KYC onboarding via hosted Stripe Express, multi-supplier payouts, saved cards, business invoicing for Danish buyers, webhook handlers with idempotency. Working in production, hardened by real edge cases over months. The Stripe Connect surface alone was worth lifting out: a reusable module that could ship as a starter for the next system, extend a sibling product in the portfolio, or live as a standalone service.
The traditional path: spend 4 to 6 weekends manually carving out a clean repo, sanitising business logic, regenerating tests, refactoring cross-references. Easy to procrastinate forever.
The agentic path we took instead
A focused extraction sprint. The agentic engineering method applied as code surgery. Four explicit phases:
1. Map the extraction surface
The first agent run was diagnostic only: read PickNDeal's codebase, identify every file that touches Stripe Connect, classify each as “extract / sanitise / drop”. Output: a structured manifest of about 40 files, with notes on which Danish-specific bits (CVR validation, faktura translation strings) needed swapping for generic equivalents and which marketplace-specific bits (supplier model, group-order RFQ flow) had to be dropped entirely.
The audit trail of this run became the spec for the next one. Human review at this stage caught two accidental classifications (“sanitise” for files that should have been “drop”); re-ran with corrections.
2. Generate the clean repo
Second agent run: take the manifest, produce the new repo. Generic Express/Custom account onboarding flows. Two-role demo (vendor + buyer) to show the Stripe Connect mechanics without leaking the marketplace context. RoleSwitchPrompt component for the role-mismatch UX. Webhook handlers with the same idempotency patterns we'd hardened in production. All as a fresh git history, no PickNDeal commits leaking through, with human-style commit messages describing what each commit does.
3. End-to-end Stripe TEST verification
Run the new module through the full Stripe Connect flow in test mode against the real Stripe API. Express account create → hosted onboarding redirect → destination charge with on-top fee ($50 + $5 = $55) → webhooks fire (account.updated, payment_intent.succeeded) → order auto-flips to paid → saved methods CRUD all work. The agent generated the test plan from the method's “reproduce in production-shape, not toy-shape” rule; we executed it together, found and fixed two issues with destination-charge metadata.
4. Deploy the extracted module
The extracted module deploys with the same build-then-swap pattern that runs the source codebase: build to a temp directory, atomically swap, the running process keeps serving the old build the entire time, health-check the new build before commit, rollback automatically if it fails. The deploy pattern was extracted into the rule library from PickNDeal's pre-launch shakedown, and the new module inherits it for free. Live at payoutkit.dev at the end of the extraction sprint.
What the method delivered
- A hardened Stripe Connect module (codebase + tests + demo + documentation) lifted out of a running production system in one focused extraction sprint
- Zero leaked Danish strings, zero leaked PickNDeal references in the new repo
- End-to-end production-shape verification (real Stripe API in test mode, not mocked fixtures)
- Audit trail of every agent decision, reviewable file-by-file
- Shared maintenance: any production fix in PickNDeal's Stripe Connect code is a candidate fix for PayoutKit, and vice versa
Why this matters for your build
Most engineering teams have one or two systems where the underlying patterns could be reusable: an internal SDK that could be lifted out of a monolith, a workflow framework that has matured past its original use case and deserves to be reused across products, a hardened integration layer that the team next door rebuilds from scratch every quarter, a microservice candidate sitting inside a larger application waiting for someone to find the energy for the extraction. The traditional path of months of careful manual extraction is why it never happens. The agentic engineering method reduces it to a focused extraction sprint, with audit trail, with the same rigour as your production code.
What carries from PayoutKit to your situation: the extraction workflow (map → generate → verify → deploy), the human-review gates on each phase, the production-shape verification rule. The compounding return is bigger than the time saved on the first extraction. Every pattern you lift out cleanly is a pattern that doesn't need to be rewritten next time. Your portfolio extends itself from what's already working in production rather than from scratch.
PayoutKit is a single reference for the extraction method in the journal. The full technical walkthrough is in the blog post.
Want this applied to your codebase?
We extract modules, libraries, and internal platforms from existing production code with the same method. Discovery conversation first; pricing scoped per engagement.