How We Ship Production-Grade Features with Agentic AI Now

A developer documented building a Stripe direct-charges payment module for a WordPress/Dokan multi-vendor marketplace using agentic AI coding tools, logging each step with timestamps. AI agents produced nearly all the code — ten vertical slices landed as ten commits in 55 minutes with PHPUnit tests — but the project still took roughly two working days to reach a QA-ready pull request out of a 12-day budget, with most time spent on intent-shaping, a 45-question requirements grilling, and review. The developer's rule of one question per message, then wait, was credited with preventing a spec nobody actually agreed to.

Every week someone tells me AI makes developers ten times faster. Last week I built a payment module for a client's marketplace with AI agents doing most of the typing, and I kept a log of every step with timestamps. This post is that log, tidied up a little. The short version: the agents wrote almost all of the code, and they wrote it fast. Getting to a QA-ready pull request still took about two working days, and the whole project is budgeted at 12, because most of the work in a feature like this isn't typing code. The client runs a multi-vendor marketplace on WordPress with Dokan. They wanted Stripe direct charges : If you've built payments before, you know this is where bugs cost real money. A webhook arrives before the page redirect. A refund lands while a payout is going out. Stripe fills a field a few seconds after you read it. None of that shows up in a demo, and all of it shows up in production. | | Step | Tool / model | Rough time | |---|---|---|---| | 1 | Shape the intent | Chat, back and forth | ~3 h | | 2 | Grill the requirements | /grill-me , Fable 5.1 | 2.5 h+ 45 questions | | 3 | Spike the unknowns | Agent against Stripe test mode | ~1 h | | 4 | Spec and tickets on GitHub | /to-spec , /to-tickets | ~10 min | | 5 | Implement, test, run it live | /to-implement , Opus 5.5 | 3 h+ | | 6 | Review and fix in a loop | /code-review | 1 h+ | | 7 | Open the PR | /pr | minutes | | 8 | Re-run unit and e2e tests | Agent | minutes | | 9 | Manual test cases, manual testing | Agent writes, I test | ~1–2 h | | 10 | Real-browser walkthrough and video | Claude in Chrome, Playwright | a few hours | | 11 | QA, fixes, merge, release | QA team, then me | ongoing | Most of the skills I used come from Matt Pocock's skills collection for Claude Code. I'll go through each step and what actually happened in it. Before any agent touched code, I spent about three hours going back and forth to get the intent clear. What does "direct charge" mean for this client? Who pays the Stripe fee? What happens to a vendor's held money if they disconnect Stripe? This part didn't get faster with AI. It's the conversation you'd have with a product owner anyway. The AI helped me ask better questions, but I still had to understand the answers. Next I ran /grill-me on Fable 5.1. The skill interviews you about your plan, one question per message, and offers its recommended answer every time. I had to answer 45 questions , and it took more than two and a half hours of focused work. It was slow because I refused to accept a recommendation I didn't understand. You can't nod along on payment questions. A few of the decisions it forced: I set one rule for the agent early on: one question per message, then wait . When it batched five questions together, I skimmed, and skimming is how you end up with a spec nobody actually agreed to. Grilling was the most valuable step in the whole process, and also the most tiring. Every decision made here is one the coding agent never has to guess at. A few questions couldn't be answered by thinking about them, so the agent ran a spike against Stripe test mode. Two things it established: balance transaction.net what the vendor actually receives after fees is filled The first finding came back later. More on that below. /to-spec turned the grilling log into a spec and opened it as a GitHub issue. /to-tickets split it into ten vertical slices , each its own sub-issue labelled ready-for-agent : This took about ten minutes, and it only took ten minutes because the grilling had already done the hard part. I switched to Opus 5.5 and ran /to-implement on the tickets. The ten slices landed as ten commits in 55 minutes . Each one came with PHPUnit tests. Code generation is now the fast part. The rest of the three hours went into everything after the code compiles: payment intent.succeeded webhook both tried to complete the same order. Every unit test passed, because no unit test runs two requests at once. The fix was to read the completion flags from the order meta table under a lock. That last habit is underrated. An agent that tells you what it didn't do is much more useful than one that says "done". /code-review runs two reviewers in parallel. One checks the diff against the repo's coding standards; the other checks it against the spec. Each reports separately, so code that follows every rule but builds the wrong thing can't hide behind the clean report. The first round found real problems. A dispute note was written after a payout had already gone out. A default hold length was wrong. One request checked the webhook signature twice. I had the agent fix the findings and ran the review again until it came back clean. The second review caught my favourite bug of the project, and it came straight from the spike: a hold that started before Stripe had reported the net amount sent the vendor an email saying their held payout was $0.00 . A Playwright run against real Stripe then confirmed it: the webhook had arrived before the net. Now the hold is announced only once its amount is known. We also added Playwright tests for the money paths : checkout to hold to release, an admin refund, and a dispute, all against real Stripe test mode with real webhooks. /pr wrote the pull request body: what changed, why, how it was tested, and what's still open. The PR ended up at 37 commits across 90 files . The agent writes a better PR description than most of us do at 7 pm. Once the PR was up, I had the agent run the PHPUnit and e2e suites again. Then I had it write manual test cases , only the ones that really need a human, and I went through them myself. I don't delegate this step. The agent writes good test cases, but I'm the one who tells the client "this works", so I need to have seen it work. This is a newer habit, and it has paid for itself already. The agent drives a real Chrome window through the feature vendor onboarding, checkout, a declined card, hold, release, refund, dispute and builds a page of screenshots with a short note under each. For bigger features it also records the run with Playwright, edits it into a captioned video with HyperFrames, and adds a voiceover with ElevenLabs. The browser run found four bugs that 136 PHPUnit tests and three Playwright specs had missed: All four were fixed in one commit, with tests, and checked again in the browser against a new order. I packaged both workflows as Claude Code plugins, browser-walkthrough and feature-video , in my plugins repo https://github.com/aminurislamarnob/claude-plugins , so the next feature gets them for free. The PR is now with our QA team for a final round of automated and manual testing. Whatever they find gets fixed, then we merge and release to the client's site. The PR has 37 commits across 90 files and about 13,400 lines of code, tests, spec and docs, tracked in 13 GitHub issues an epic, the spec, ten slices and a known-gaps list . It's covered by 136 PHPUnit tests and 3 Playwright money-path specs . Six bugs were found after the unit tests were green: the race condition, the $0.00 email and four from the browser run. The build and review sessions used about 625M tokens , roughly $306 at API list prices. 98% of that is cache reads, because a long agent session re-reads its whole context on every response. A subscription bills differently, and the later browser and video sessions aren't included. Not quite 10x, but the gain is real. The coding got about 5–6x faster. The whole project is budgeted at 12 days. AI development and testing take 3 of them; by hand, that part would take us roughly 15–18 days. That's where the 5–6x comes from, though it's an estimate, since nobody built this feature twice. Grilling, final QA, bug fixing, UAT and go-live take 8 days with or without AI, so the project lands at 12 days instead of about 25. Those 8 days should stay. That's where you find out whether the thing is correct, and for payments, correct is the whole job. If anything, AI moved my time around. I spend much less of it typing and much more of it deciding and verifying. The big change isn't one feature going faster. It's working on several features at once . Before, I had to understand every line as I wrote it, so one feature took all my attention. Now, while the agent implements feature A in one git worktree, I can grill feature B in another. The agent doesn't need me watching while it codes; it needs me at the start intent, grilling and the end review, testing . Those are the parts that need a human, and they fit around each other. That's the real use case I see for AI in day-to-day development: running multiple features in parallel across worktrees, with the developer acting as the person who decides and verifies. net finding from the spike turned into a real bug two steps later. I'll write separately about the agentic SDLC as a whole. For now, these are my own observations from one real feature, not benchmarks.