My AI Workflow Cut Build Times 40% — Here's the Stack

ZenMaster Expert 2h ago 68 views 0 likes 5 min read

The turning point wasn't a new tool. It was a Tuesday afternoon last March when my CI pipeline failed for the third time that week — same flaky integration test, same "works on my machine" excuse. I had Copilot, Cursor, and a half-dozen Chrome extensions. None of them caught the race condition in the payment webhook handler.

That's when I stopped collecting tools and started building a loop.

The Loop That Actually Works

Most developers treat AI as a better autocomplete. Wrong mental model. The productivity gains come from closing the feedback loop between intent and verified output.

My current loop: spec → generate → test → reflect → commit. Four minutes per cycle on a good day. Twelve when the tests fight back.

Here's the concrete breakdown:

| Phase | Tool | Time | Failure Mode |
|-------|------|------|--------------|
| Spec | Cursor + custom .cursorrules | 30s | Vague requirements → hallucinated APIs |
| Generate | Claude 3.5 Sonnet (max tokens) | 90s | Context window overflow on large files |
| Test | Vitest + Playwright (headed) | 2-8m | Flaky async, missing mocks |
| Reflect | Git diff + manual review | 60s | Skipping this causes 80% of my reverts |
| Commit | Conventional commits + Husky | 15s | Empty messages, broken hooks |

The reflect phase is where people cut corners. Don't. I measured: commits pushed without manual diff review had a 23% revert rate. With review? 3%.

Spec Phase: Stop Writing Prompts, Start Writing Contracts

I used to paste error messages into chat and hope. Now I write a SPEC.md before touching code. Example from last week's Stripe webhook refactor:

## SPEC: Stripe Webhook Idempotency
**Input**: POST /webhooks/stripe with Stripe-Signature header
**Output**: 200 within 3s, idempotency key stored in Redis (TTL 24h)
**Constraints**: 
- Handle duplicate deliveries (same event_id)
- Verify signature before any DB write
- No external calls in hot path
**Edge cases**:
- Stripe retry with different signature (clock skew)
- Redis unavailable → return 500, let Stripe retry
- Malformed JSON → 400, no crash

Feed this to Cursor with @SPEC.md implement this. The diff is reviewable. The tests write themselves because the spec is the test plan.

Before: 45 minutes arguing with Copilot about middleware order. After: 12 minutes, first commit passed CI.

Generate Phase: Context Budgeting

Claude's 200k context window is a trap. Stuff the whole repo and you get generic sludge. I budget 15k tokens max per request:

@SPEC.md
@src/webhooks/stripe.ts (current implementation)
@src/lib/redis.ts
@tests/webhooks/stripe.test.ts (existing tests only)

That's it. No @codebase. No "read all files." The model stays focused.

Wild part: I tried the same spec with GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro. Sonnet won on TypeScript correctness (0 type errors vs 3 for GPT-4o, 7 for Gemini). But Gemini was 2x faster. Trade-off I accept.

Test Phase: The Flaky Test That Broke Me

That Tuesday failure? Playwright test clicking a "Confirm Payment" button before the Stripe Elements iframe loaded. Classic race.

The fix wasn't better selectors. It was a helper that waits for the iframe's internal ready event:

// tests/helpers/stripe.ts
export async function waitForStripeReady(page: Page, timeout = 5000) {
  await page.waitForFunction(
    () => window.Stripe?.elements?.ready === true,
    { timeout }
  );
}

Now every webhook test imports this. Flakiness dropped from 18% to 0.4% across 47 tests.

The lesson: AI generates code. You own the test infrastructure. Don't ask the model to fix flakiness — fix the harness once, benefit forever.

Artificial Intelligence Forum, AI productivity workflow, AI Forum

Reflect Phase: The 60-Second Rule

Git diff. Read every line. Ask: "Would I have written this?"

If the answer is no, revert and regenerate with a tighter spec. This feels slow. It's not. The 23% revert rate without it? That's hours of debugging per week.

I keep a REFLECT.md scratchpad:

- Line 47: unnecessary ternary, simplify
- Line 89: magic number 3000 → constant STRIPE_TIMEOUT_MS
- Line 112: missing null check on customer.metadata

Three minutes. Caught two bugs before CI.

The Community Multiplier

Here's what changed everything: sharing these specs in a forum where other developers tear them apart.

Posted my Stripe idempotency spec last month. Three replies within an hour:

  • "Redis SETNX has a race on network partition — use Lua script"
  • "Stripe recommends idempotency keys on your side, not event_id"
  • "You're not handling account.updated webhooks for Connect"
My AI Workflow Cut Build Times 40% — Here's the Stack

Fixed all three before my next commit. That's the compound interest of a real AI Coding community — not "great job" replies, but architectural pressure testing.

The wild part? One reply came from a Stripe engineer who lurks there. She pointed me to their new idempotency docs that hadn't hit the blog yet. Saved me a weekend of debugging.

Two Habits That Waste Time

1. Prompt libraries. I tried 47 "battle-tested" prompts from GitHub repos. Used maybe three. The rest were either too generic ("write clean code") or too specific to someone else's stack. Write your own. The act of writing is the thinking.

2. Multi-model routing for every task. "Use Opus for planning, Sonnet for coding, Haiku for tests." Sounds smart. In practice: context switching kills flow. I use Sonnet for everything. Consistency > theoretical optimum.

The Metrics That Matter

Six months of data from my side project (Next.js + tRPC + Postgres):

| Metric | Before Loop | After Loop | Delta |
|--------|-------------|------------|-------|
| Median PR cycle time | 4.2 hours | 1.8 hours | -57% |
| CI failure rate | 31% | 8% | -74% |
| Reverts per month | 12 | 2 | -83% |
| Time to first working draft | 35 min | 9 min | -74% |
| Lines of test code / feature | 180 | 340 | +89% |

Test lines went up. That's the point. The loop forces verification.

What I Still Get Wrong

  • Specs for trivial changes. Adding a toast notification doesn't need a SPEC.md. I still over-engineer sometimes.
  • Skipping reflect on "obvious" fixes. That's how the customer.metadata null check slipped through last week.
  • Trusting AI-generated migration files. Always, always run pg_dump --schema-only before and after. Learned this the hard way on a production incident.

Your Turn

Pick one feature you're building this week. Write a SPEC.md — 10 minutes max. Feed it to your model with a 15k token context budget. Run the tests. Read the diff. Commit.

Do it three times. Time each cycle.

If your median isn't under 15 minutes by the third, your spec is too vague or your test harness is weak. Fix those. The model isn't the bottleneck.

And if you hit a wall — post the spec somewhere developers actually read code. The Workflows thread on PromptCube has saved me more hours than any tool update. Not because the tools got better. Because the loop got tighter.

That's the whole game.

Related examples in this direction are worth a look in these real-world AI monetization case studies, with plenty of directly applicable cases.

All Replies (0)

No replies yet — be the first!

Write a Reply

Markdown supported