Harness Engineering: How Kuaishou E-commerce Reshapes R&D with AI Pipelines

In 2026, Kuaishou E-commerce's Merchant & Operations Enablement Center recognized that individual AI tool adoption (170% code volume increase) failed to translate into organizational delivery speedups. Their B&M systems serve 6+ user roles across 20+ intertwined business domains with hundreds of services, making single-point tooling insufficient.

Core Problems Identified

Requirements-side analysis cost: Complex B&M demands require multiple reviews (MRD, PRD, technical, TC), yet gaps and omissions persist.

Delivery-side coordination cost: A single demand spans merchant onboarding, shop management, transaction fulfillment, funds, customer service, settlement — involving product, frontend, backend, test roles. Sequential handoffs turn 5 person-days of work into 10+ calendar days due to waiting.

New-member onboarding curve: 5+ years of accumulated domain knowledge and frequent rule changes make ramp-up slow and knowledge transfer expensive.

Target State & Design Principles

The team built a full-lifecycle automated delivery pipeline with four principles:

Full lifecycle: Not point tools, but end-to-end from knowledge construction → requirements → execution → test/release.

Engineered workflow: AI embedded in controllable, auditable, reusable workflows (Harness Engineering) so most demands only need clarification before auto-execution.

Cloud + Edge collaboration (Agent Swarm): Cloud orchestrates (structures requirements, dispatches tasks, coordinates multi-agent); edge executes.

End-to-end linkage: Deep partnership with product on conversational PRD generation and structured requirements; unified frontend/backend/test flow with traceability; domain knowledge base feeds PRD, spec, TC generation.

Adversarial Pipeline Design: open-door / close-door

Each pipeline stage is a "room." pandoraFlow-delivery tries to open doors (push artifacts forward); pandoraFlow-review tries to close doors (only passes fully-validated artifacts). All intermediate artifacts stored via filesystem + Git. Every phase follows plan → execute → verify with immediate validation and rollback on failure.

Phase-by-Phase Transformation

3.1 Requirements: Product-Ops-Dev Collaboration Upgrade

Before: PMs manually mapped cross-domain logic; PRD completeness relied on individual experience; multi-round reviews (MRD, PRD, visual); historical docs scattered; devs frequently bounced back for clarifications.

Now: Requirements workbench backed by domain knowledge base (historical PRDs, industry materials, business rules, domain concepts). PMs converse with agent to clarify; platform auto-generates PRD + structured requirements (EARS/BDD) → one-click flow to dev. Shift from "multi-round review + manual alignment" to "knowledge-base-driven generation + prototype confirmation + team-binding one-click flow."

3.2 Spec: Delivery Mode Upgrade

Before: PRD→tech design fully manual. Devs hunted upstream/downstream interface docs, judged impact scope manually (high cost in intertwined domains). Design quality varied wildly; tech reviews triggered rework. Tribal knowledge lost.

Now: Domain knowledge base initialized once by domain owners: extracts system APIs, data structures, business call chains from existing code; pulls business rules, functional boundaries, architectural decisions from historical PRDs/designs; integrates functional entry points and key logic per domain. AI auto-parses upstream/downstream interfaces, uses code call graphs to pinpoint change points, derives interface dependencies and impact scope, one-click generates proposal.md + design.md + tasks.md (structured requirements trio). Spec phase becomes "knowledge-base-driven → auto-generate → review-gated flow."

3.3 Dev: Coding Phase

Before: 5+ years legacy, mixed coding styles, domain-specific rules and debt. Devs manually read existing code to locate change points, assess ripple effects. High risk of missed/duplicate/conflicting changes even for experienced devs.

Now: tasks.md from Spec contains auto-derived change points and impact scope. Devs consume tasks sequentially. Domain knowledge base constrains AI context: auto-identifies business rule boundaries, judges new/adjust logic, spots config conflicts/omissions. Test-driven development: every function verified. New hires onboard faster via knowledge base.

3.4 Test: Testing Phase

Before: Manual test case writing, manual data prep. Coverage depended on tester's requirement understanding; gaps in edge cases. Data dependencies across domains made full-link construction laborious. Bug cycles: test → dev fix → re-test → long cycles, high coordination wait.

Now: "Skill generate → execute → auto-close-loop." Structured requirements (BDD/EARS) + impact scope → auto-generate cases covering happy path, exceptions, boundaries. Domain knowledge base → auto-construct test data respecting cross-domain dependencies. Change-point analysis → multi-end precise regression, high-coverage boundary cases, AI full-path exploration and jump-link verification. Bugs auto-recorded/located; test report drives fix loop until zero bugs.

3.5 Oncall: Daily Production Operations

Before: Oncall manually pulled logs, filtered keywords, traced traceIds, analyzed line-by-line against code. Multi-service issues required cross-domain sync — high wait time.

Now: Skill ingests log sources; runtime logs + trace context auto-fed to LLM for multi-service correlation and root-cause analysis in-context. Agent combines code call graph + domain knowledge to define minimal impact scope, produces evidence-backed fix plan (logs → root cause → impact → minimal diff). Auto-deploys to test env, re-fetches logs to verify fix. Entire "alert → locate → minimal fix → verify" loop in one context.

Organizational Evolution

Referencing The Mythical Man-Month : adding people increases communication overhead geometrically; new members lack context. "Shift-left" failed historically due to high investment/low ROI — essentially responsibility transfer without automation. AI changes both:

Adding AI agents ≠ adding people: agents get context losslessly from code, no geometric communication overhead.

Shift-left becomes viable: AI extracts context/knowledge from existing code + incremental PRD/Spec, creating shared understandable context framework at low cost for new members and cross-role alignment.

Team transitions from functional silos to "super-individual" model:

R&D Mode

Before: Ops, product, dev, test — multiple roles, heavy reviews (MRD, PRD, tech, TC, code review), frontend+backend+multi-domain devs, full-cycle FE/BE integration and upstream/downstream joint debugging.

Now: Two roles deliver full lifecycle — PM and Delivery Owner (full-stack).

Two people discuss + converse with AI → structured requirements.

Delivery Owner post-meeting: AI generates tech design, TC, plan; reviews output.

AI auto-codes, integrates, tests (currently human-gated on intermediate artifacts; future: fully autonomous overnight).

PM accepts.

Domain Owner Role

Before: High complexity, tech debt, mixed styles; responsible for stability, perf, maintainability. Enforced constraints via architecture docs, tech reviews, code reviews.

Now: Before enabling AI coding in domain, Domain Owner initializes: extracts context/knowledge from code+PRDs; mines APIs, data structures, business flows; guides AI to generate structured Spec knowledge base per templates; configures workload, constraints, validation rules.

Requirements Shift-Left

Before: PM schedules meetings → MRD review → PRD review → visual review → any issue or new point triggers full re-cycle.

Now: Delivery Owner focuses on user flow, product value, customer experience.

Zeta PM workbench: rapid prototype → "what you see is what you get" confirmation + auto-PRD → moves acceptance (previously post-release) to far left.

Domain knowledge surfaces history, impact details → PM and Delivery Owner escape detail weeds, focus on value/experience.

Quality Shift-Left

Before: Test-left failed due to high cost/heavy process, not wrong direction.

Now: AI makes coverage analysis light, test writing fast, execution auto — shifts test into dev phase. Delivery Owner uses AI for auto-testing; test-left accelerates overall dev. AI case gen + auto data prep + auto execution → test phase moves into dev; AI bug localization + auto-fix loop until clean → true auto-delivery.

Role Consolidation

Before: Skill depth defined functions — FE guards FE, BE guards BE, design guards design.

Now:

PM + Interaction Designer + DA → unified: business comms → demo confirmation → business intent → UI.

FE + BE + Test → unified: covers FE dev, data structures, state machines, APIs, HA/reliability — from business model to system stability.

Two Major Pitfalls

Pitfall 1: Don't Build Heavy Platforms; Build Standards & Processes

Early effort spent building a custom platform failed: devs resisted habit change; industry tools evolve faster than internal builds; root causes — devs love reinventing wheels (now cheaper), and horizontal teams need platforms for organizational legitimacy.

Solution: No platform, but standards + minimal tooling for observability. Two core actions:

Enforce forward-push / backward-acceptance flow via two skills ( delivery, review) linking all nodes; domain owners choose tools (openSpace, superPower suite) at init.

Mandate collection of all pipeline timing/automation data (requirements, design, FE, BE, integration, test, wait-dev, wait-test…) → management pressure to maximize automation per stage.

Pitfall 2: Harness Is Easy to Assemble; Domain Practice Is Hard

Adopting industry skills or forking them is trivial. But if humans still drive tools/process, human-human collaboration cost/friction persists. Two remedies:

Build domain automation observability: measure manual interventions per delivery link; make this a KPI.

Domain owners (who know business) must review knowledge bases and SOPs, customize workflows themselves.

Peer Checklist (Anti-Patterns)

Don't spend massive effort building platforms; set standards and leverage open-source for tooling.

Domain knowledge accumulation is critical. Three pillars of R&D efficiency: "Foundation Model + Harness + Domain Knowledge." Foundation models belong to global top-3; harness belongs to open-source; only domain knowledge is yours. Build knowledge graph (processes, rules, entities) from all historical code + PRDs + designs.

Core metric for org efficiency: AI automation rate — how much work AI takes over, how many human interventions. All complex actions must complete before delivery starts; coding, unit test, test, release must reach near-full automation. Management enforcement is mandatory.

Closing: Dual-Flywheel of Tool Efficiency & Org Efficiency

Tooling: Focus on full-lifecycle auto-delivery capability for real org speedup. Local tool swaps give local speed but no systemic leap. Without true automation, no "exponential org efficiency."

Org Structure: Cultivate full-stack super-individuals; reduce horizontal functions so business units gain closed-loop capability.

Vertical: Requirements-left, test-left → process-driven → full-stack super-individual delivery. Develop better Domain Owners: "Tech Expert" → "Domain Expert," focus shifts from implementation details to user flow, product value, customer experience.

Horizontal: Enterprise info-flow inefficiency and cross-dept drain stem from org design, responsibility boundaries, department positioning, business stage. AI amplifies individual capability. Two viable paths: reduce horizontal functions (algo, middle-platform, efficiency, test, FE) → reorganize into capital, distribution, ops-platform business units → Amoeba management — more feasible in AI era.

Exponential efficiency gains come when tech revolution forces org restructuring; without structural change, org efficiency stalls. Therefore, org efficiency must be viewed through "tooling + structure" together.