Boosting Cross-Stack Development with Harness-Loop: AI-Powered Full-Stack Delivery

Summary

The Street‑Ranking feature requires changes across backend services, middleware transmission, and client libraries, involving multiple projects, heterogeneous tech stacks, and differing build, test, and release cycles. Traditional manual coordination leads to long research cycles, fragmented alignment, and a lack of systematic impact‑scope judgment and risk control.

Why Full-Stack Development Needs Harness

Full‑stack work must first answer "where to change" because a seemingly simple style addition can affect protocol generation, configuration transmission, field conversion, and page rendering. Missing any link breaks the whole chain. AI can search keywords but cannot infer the true impact without a structured workspace that defines project relationships, required changes, verification‑only projects, and those to skip.

Unlike ordinary CI/CD that only verifies buildability, harness-loop provides a broader, cross‑project view: it determines which projects must change, which only need verification, and which are irrelevant, then drives a verification evidence chain to decide completion.

Overall Architecture of Harness-Loop

Harness-loop acts as an engineering workbench for full‑stack demands, consisting of four layers:

Input & Context Layer: Consumes requirement documents, communication notes, existing workspaces, knowledge base, previous execution state, and verification reports.

Workspace Harness: Describes project boundaries, roles, tech‑stack types, deployment channels, verification profiles, link graphs, adapters, forbidden actions, and historical pitfalls, giving AI a clear action boundary.

Coordinator: Breaks the requirement into a global plan, per‑project tasks, and topology batches, then schedules plan agents and project agents, handling checkpoints, resumes, risk status, and cross‑project ordering.

External Provider: Supplies evidence from knowledge bases, automated acceptance tests, project‑management systems, deployment platforms, code reviews, and log services. AI consumes these reports to decide whether to continue, enter acceptance, record a block, or hand over to human decision.

The architecture emphasizes memory write‑back: after each demand, the chain records impact‑scope decisions, skip reasons, verification conclusions, platform blocks, and cross‑project pitfalls into memory and the team knowledge base for future reuse.

Closed‑Loop Sub‑Iteration and Memory‑Use Iteration

Each sub‑iteration follows five steps:

Read Current State: AI loads the promise, project context, historical experience, previous verification report, and checkpoint instead of guessing from chat memory.

Determine Next Action: Based on state, AI may continue implementation, trigger verification, supplement the plan, wait for block removal, or hand over to human decision.

Execute or Verify: In implementation, AI assigns tasks to project agents; completed code undergoes lint verification before moving to automated testing. In verification, AI invokes the project's declared verification method or external platform.

Consume Report: AI distinguishes pass/fail, code failures, specification gaps, environment blocks, manual reviews, and acceptable warnings, preventing mis‑classification of platform issues as code bugs.

Update State: After each round, AI updates tasks, risk records, block reasons, and resume points, enabling continuation from the new state.

Two iteration types exist: the closed‑loop sub‑iteration resolves the current demand, while the memory‑use iteration records artifacts (spec bundles, pitfalls, verification conclusions) into memory for advisory reuse in future demands.

Overall Working Method: Where to Change, How to Change, How to Verify

The process is split into four steps:

Identify Where to Change: Input is the requirement description and existing project context; output is impact‑scope judgment. AI combines project relationships, code search, historical experience, and semantics to classify projects as must‑change, verify‑only, or skip.

Design How to Change: After impact determination, AI generates a global plan and per‑project implementation instructions, covering cross‑project protocols, boundaries, and specific files, methods, tasks, and verification methods.

Implement Tasks: Post‑review, AI executes task‑level changes across repositories, handling multiple languages, configurations, and tests, reducing research time, smoothing syntax differences, and surfacing protocol integration issues early.

Verify and Consolidate: Verification includes local checks, deployment status, automated tests, manual acceptance, and risk archiving, all feeding into a unified evidence model. AI may orchestrate verification and consume reports but cannot replace external validation conclusions.

Practical Practice on the Street‑Ranking Feature

Background: The iteration needed a new template style and scoring page capability for specific business types, affecting backend services, middleware transmission, client libraries, and downstream page consumption.

Goal: Demonstrate that AI can (1) correctly identify the full impact scope, (2) decompose the requirement into executable per‑project tasks, and (3) retain products, risks, and skip reasons for review and retrospection.

6.1 Where to Change: Converging Multiple Candidate Projects

Workspace contains many candidate projects; harness-loop first narrows the impact scope. Core implementation projects are backend services (enumeration, protocol, recall, config), middleware transmission (copy, whitelist, data model, scoring info), and client public library (card style, tags, request metadata, sidebar, multi‑dimensional scoring page). Other projects like data layer or landing‑page engineering are downstream and skipped for this round, making the skip an explicit decision rather than an omission.

6.2 How to Change: Decomposing into Reviewable, Executable Tasks

After impact convergence, AI splits the requirement into acceptance criteria and tasks, producing dozens of tasks, multiple implementation batches, and recalling several historical experiences. Tasks are ordered based on project relationships: backend services and client library can proceed in parallel, while middleware waits for stable upstream protocols.

6.3 How to Verify: Differentiated Verification per Project

Different projects require different verification strategies: backend services use compile, unit tests, deployment, and automated checks; public libraries focus on type safety, build compatibility; client projects need platform builds, entry validation, real‑device checks, or manual review. Harness-loop lets each project declare its verification method while sharing a common evidence model.

6.4 Most Valuable Pitfalls

Treating the link graph as the change range leads AI to modify unrelated projects.

Applying a uniform verification process across heterogeneous projects causes failures (e.g., front‑end bundles cannot follow back‑end build steps).

Using historical experience as a definitive conclusion; it should guide but not replace current acceptance criteria.

Benefits

Global‑view design: Plans capture cross‑project protocols, upstream/downstream dependencies, and skip reasons, yielding a full‑chain perspective.

Faster implementation: Service developers avoid learning each stack’s syntax; AI handles multi‑repo modifications, saving time on research and cross‑stack coding.

More controllable risk: Clear artifacts show which projects change, which validations run, and why, preventing reliance on informal chat memory.

Conclusion

Harness-loop provides a structured engineering shell for AI, enabling systematic impact‑scope determination, cross‑repo task orchestration, differentiated verification, and experience memory. In the Street‑Ranking case, it reduced the development cycle, improved risk traceability, and produced reusable artifacts for future demands, demonstrating a scalable approach to full‑stack, cross‑technology development.