Mini Project 11: Agentic Software Delivery Pipeline

Tests That Mirror the Code's Blind Spots

The obvious way to build an agentic dev pipeline is a straight line: an agent writes code, then an agent writes tests for that code. It looks like it works — tests pass, green checkmark, ship it. The problem shows up the first time the code has a subtle bug: a test written against the code tends to encode the same wrong assumption the code made, because both came from the same misreading of the requirement. Green tests, wrong behavior, nobody catches it until production.

This project's real design decision is the fix for exactly that: the Test Agent writes its tests against the acceptance criteria, independently of the Developer Agent's implementation — so a bug in the code and a matching blind spot in the tests aren't the same mistake made twice. Four agents, a real human-in-the-loop clarification step, and a genuine review-and-rework loop — the most complete multi-agent showcase in this roadmap.

Setup

// build.gradle
dependencies {
    implementation 'org.springframework.ai:spring-ai-ollama-spring-boot-starter'
    implementation 'dev.langchain4j:langchain4j-spring-boot-starter'  // parallelBuilder, loopBuilder
    implementation 'org.springframework.boot:spring-boot-starter-web'
}

This project draws on human-in-the-loop patterns and loop-with-exit-condition orchestration from this roadmap's agentic-patterns guide, parallel agent execution (LangChain4j's parallelBuilder, contrasted with hand-rolled CompletableFuture fan-out), and tool calling against a Git hosting API — all four are prerequisites this project composes rather than reintroduces.

1. Requirements Agent: Refining Ambiguity With a Human in the Loop

A raw SRS document is rarely unambiguous enough to code against directly. The Requirements Agent's job is turning it into a structured, unambiguous spec — and explicitly stopping to ask when it can't:

public record RefinedSpec(
    String feature,
    List<String> acceptanceCriteria,
    List<String> outOfScope,
    List<String> openQuestions
) {}

public RefinedSpec refine(String rawSrs) {
    RefinedSpec draft = requirementsAgent.refine(rawSrs);
 
    if (!draft.openQuestions().isEmpty()) {
        List<String> answers = humanClarificationService.askAndWait(draft.openQuestions());
        return requirementsAgent.incorporateAnswers(draft, answers);
    }
    return draft;
}

2. Developer and Test Agents: Parallel, From the Same Spec, Independently

This is the section that matters most. Both agents receive the same RefinedSpec — but the Test Agent never sees the Developer Agent's code, only the acceptance criteria:

interface DeveloperAgent {
    @SystemMessage("Implement the feature described by the given acceptance criteria. Return complete, compilable code.")
    CodeArtifact implement(RefinedSpec spec);
}
 
interface TestAgent {
    @SystemMessage("""
        Write end-to-end tests that verify EACH acceptance criterion independently.
        You have NOT seen any implementation — write tests against the criteria as
        specified, not against assumed implementation details.
        """)
    TestArtifact writeTests(RefinedSpec spec);
}

UntypedAgent devAndTestInParallel = AgenticServices.parallelBuilder()
    .subAgents(developerAgent, testAgent)
    .outputName("implementation")
    .build();

parallelBuilder() runs both agents concurrently since neither depends on the other's output — a straightforward efficiency win here, and the same LangChain4j primitive this roadmap's agentic-patterns guide contrasts against a hand-rolled CompletableFuture.allOf(...) fan-out. Reach for the hand-rolled version when you need finer control over partial-failure handling than the builder exposes; parallelBuilder() otherwise.

3. Review Agent: Evaluate Together, Loop on Failure

The Review Agent sees both artifacts together — code and tests — and makes the approve-or-rework call:

public record ReviewResult(
    boolean approved,
    List<String> feedback,
    boolean testsRunClean
) {}

interface ReviewAgent {
    @SystemMessage("""
        Evaluate whether the code satisfies the acceptance criteria and whether the
        tests genuinely exercise those criteria (not just that tests exist). Run the
        tests if possible and report pass/fail. Approve only if both the implementation
        is correct AND the tests would catch a regression.
        """)
    ReviewResult review(RefinedSpec spec, CodeArtifact code, TestArtifact tests);
}

UntypedAgent reviewLoop = AgenticServices.loopBuilder()
    .subAgents(devAndTestInParallel, reviewAgent)
    .exitCondition(agenticScope -> {
        ReviewResult result = (ReviewResult) agenticScope.readState("reviewResult");
        return result.approved();
    })
    .maxIterations(4) // don't loop forever on a spec the agents can't satisfy
    .build();

On rejection, the Review Agent's feedback flows back to the Developer Agent's next iteration — loopBuilder() is Embabel's replanning idea and this roadmap's agentic-patterns "loop with exit condition" pattern, expressed as a LangChain4j builder rather than hand-written. maxIterations(4) is the same reasoning as every bounded-retry decision elsewhere in this phase: an unbounded loop against a spec the agents genuinely can't satisfy is a cost and latency risk, not a robustness feature.

4. Opening the Pull Request

An approved iteration is the only path that reaches this tool call — everything before it is gated behind the review loop's exit condition:

@Component
public class GitHostingTool {
 
    @Tool(description = "Open a pull request with the given branch, title, description, and file changes")
    public PullRequestResult openPullRequest(String branch, String title, String description, List<FileChange> changes) {
        return gitHostingApi.createPullRequest(branch, title, description, changes);
    }
}

public PullRequestResult deliverFeature(String rawSrs) {
    RefinedSpec spec = refine(rawSrs); // section 1
    Map<String, Object> result = reviewLoop.invoke(Map.of("spec", spec)); // sections 2-3
 
    ReviewResult finalReview = (ReviewResult) result.get("reviewResult");
    if (!finalReview.approved()) {
        return escalateToHuman(spec, result); // hit maxIterations without approval
    }
 
    CodeArtifact code = (CodeArtifact) result.get("code");
    TestArtifact tests = (TestArtifact) result.get("tests");
    return gitTool.openPullRequest(
        branchNameFor(spec),
        spec.feature(),
        buildPrDescription(spec, finalReview),
        combineChanges(code, tests)
    );
}

Putting It Together

The full pipeline: Requirements Agent refines the SRS with a human clarification step for anything ambiguous → Developer and Test Agents work in parallel from that same refined spec, the Test Agent genuinely blind to the implementation → Review Agent evaluates both together and either approves (opening a real pull request) or sends specific feedback back into another Developer/Test iteration, bounded to 4 attempts before escalating to a human. Every agent boundary in this pipeline exists to prevent one specific failure mode — guessed requirements, tests that mirror code's blind spots, an unreviewed merge — not as agent-count theater.

What's Next

This is the last project in this phase and the most complete multi-agent showcase in the roadmap. Mini Project 4 (GitHub PR Triage Agent over MCP) is the natural companion — once this pipeline's Review Agent opens a pull request, that project's triage agent is one of the things that would evaluate it in a real team's actual review queue.