JUNIE: The Customer Proxy in Our Development Workflow

Most software teams still treat the customer as someone who arrives at the end.

The product manager writes the story. The engineer builds the feature. The reviewer checks the code. CI checks the tests. Maybe QA runs a path. Maybe someone updates the docs. Then, somewhere downstream, the customer discovers whether the thing actually does what the pull request claimed.

That was already a weak arrangement. AI-assisted development makes it untenable.

When code arrives faster than review can absorb it, the old question - is this code acceptable? - is too small. A pull request can be tidy, tested, typed, and still fail the only test that matters: can a customer see, use, understand, and trust the claimed improvement?

That is why we are building JUNIE.

JUNIE is our customer proxy inside the development workflow. She sits in the pull request and asks the question a downstream customer would ask if they had the time, access, and technical confidence to interrogate the work before it shipped:

Does this PR prove, from the customer’s point of view, that the claimed user-facing improvement is real?

Not “does the code look nice?”

Not “did CI pass?”

Not “can the author explain what they intended?”

Prove it. As a user would encounter it. With evidence a customer could reasonably trust.

The customer is not represented in code review

Code review is not useless. It catches real issues. It transfers context. It stops some bad ideas before they calcify. I am not arguing for less review.

I am arguing that code review is structurally inward-facing.

Reviewers inspect implementation choices: naming, boundaries, tests, security, architecture, maintainability. Good reviewers also ask whether the work matches the ticket. But even then, the frame is usually internal. The reviewer asks whether the code appears to implement the team’s intent.

The customer asks a different question.

Can I do the thing you said I can now do? If I read the docs, do they tell the truth? If I follow the workflow, does it actually work? If something fails, does it fail in a way I can understand? If this is a demo, would I trust the company more after seeing it, or less?

Those are not secondary questions. They are the product.

The uncomfortable part is that a great deal of modern delivery evidence is evidence for the team, not for the customer. A green test suite tells the team that certain assertions held under certain conditions. It does not tell the customer that the workflow they care about is coherent. A screenshot tells the team that a screen rendered once. It does not prove the docs, API, permissions, error states, and happy path hang together.

We have confused internal confidence with customer proof.

AI makes the gap wider

AI-assisted development does not merely speed up coding. It changes the failure mode.

A human team writing slowly tends to have informal continuity. The same people remember why the feature exists, what the demo is supposed to show, which customer pain started the work, and where the awkward edge cases live. That memory is imperfect, but it is present.

An AI-assisted workflow produces much more surface area with much less inherited memory. A feature branch can accumulate code, docs, tests, fixtures, screenshots, and migration notes at a pace that looks productive right up until someone asks: what exactly are we proving here?

The AI can write a plausible test for the code it just wrote. It can update a doc in the house style. It can produce a PR description that sounds coherent. None of that proves the customer claim is true.

This is the point at which teams reach for more automation. More tests. More linting. More static analysis. More required checks.

Useful, but insufficient.

The missing layer is not another machine asking whether the code conforms to the codebase. The missing layer is a machine, guided by human standards, asking whether the work is honest from the customer’s side of the glass.

That is JUNIE’s job.

JUNIE is not another linter

JUNIE’s default posture is not “review the code.”

Her default posture is “verify the claim.”

If the PR says a customer can now complete a workflow, JUNIE wants the workflow. If the PR says the API returns a new field, JUNIE wants the contract and a real call. If the PR says the docs explain a setup path, JUNIE reads the docs as a user and follows them as far as she can. If the PR says a demo is ready, JUNIE behaves like an evaluator watching that demo with a sceptical eyebrow.

Code matters to her when it affects customer trust: demo reliability, security, data safety, comprehensibility, maintainability of the experience, or honesty of the claim. She is not there to argue about an implementation style because it offends her aesthetic sense.

This distinction matters because most automated reviewers drift into nitpicking. They find something easy to observe and mistake it for something important. The customer does not care whether the internal helper has the name the agent preferred. The customer cares whether the feature they were promised survives contact with reality.

So JUNIE starts with a claim matrix.

What does the PR say the user can now do, see, understand, or trust? Where is that claim made - PR body, linked issue, docs, product note, screenshot, demo script? How would a real user encounter it? What observable outcome would prove it? What edge or failure behaviour would a customer reasonably care about?

Only then does she decide what evidence is worth collecting.

And because she can operate a computer, the evidence is not theoretical.

JUNIE can log in. She can click through the product. She can fill in forms, follow onboarding paths, run the demo, call the API, inspect the response, and then read the logs to check whether the thing she did was recorded the way the product claims it is recorded. She can compare the customer-visible surface with the operational trace behind it.

That is a different class of reviewer. Not a static analyser. Not a documentation checker. Not a unit-test counter. A customer proxy who can use the product, observe the system, and ask whether the two agree.

Passing tests is not enough

This is the part that will annoy some engineers, so let me be precise.

Automated tests are important. They make verification repeatable. They protect known contracts. They let us move faster without pretending memory is a process.

But tests are not customer proof.

A test can prove that a function returned the expected object. It cannot, by itself, prove that the product claim was meaningful. It cannot prove that the user found the right affordance, understood the docs, had the right permission, saw the right error, or completed the workflow that the sales call implied.

For JUNIE, the strongest evidence comes from the surface the customer actually touches:

Browser verification for user-facing interfaces.
API calls for customer-visible contracts.
CLI or operational workflows when the customer surface is a command or process.
Documentation checks where the docs are part of the experience.
Logs, screenshots, traces, and command output that explain what happened.
Code inspection, when it helps diagnose or contextualise what the surface showed.

That ordering is deliberate.

If a PR claims a user-facing improvement and JUNIE cannot verify it through a user-facing path, the correct answer may be HOLD even when the tests pass. Not because tests do not matter, but because the wrong thing has been proven.

This is the sentence I want teams to sit with:

A pull request can be technically correct and still be evidentially dishonest.

Not malicious. Not incompetent. Just unproved in the place where proof matters.

Quality belongs upstream

There is a lazy version of this idea where JUNIE becomes late-stage QA theatre.

The author finishes the work. JUNIE arrives at the end. She runs some checks, posts a verdict, annoys everyone, and becomes one more gate to manage.

That is not the ambition.

JUNIE is deliberately on probation in v1. Her verdicts are advisory. She has to earn authority by being useful. The real value is not catching defects late; it is changing what authors make explicit early.

In draft PRs, JUNIE should not behave like a merge reviewer. She should behave like a coach:

What is the customer-facing claim?
What does good look like from the user’s point of view?
Which docs, browser flows, API calls, screenshots, logs, or walkthroughs will prove it?
Which claims have no user-style verification route?
What edge case would embarrass us if a customer found it first?

That work bends the branch while it is still soft.

The best JUNIE outcome is a PR that never needs a dramatic review comment because the author already shaped the work around a proof path. The customer claim was clear. The demo route existed. The docs told the truth. The verification evidence was gathered as the work formed, not scraped together after the fact.

That is what “building quality in” means when AI is writing large parts of the implementation. It is not a slogan about craftsmanship. It is a workflow design problem.

The verdicts are simple on purpose

When a PR is ready for delivery review, JUNIE uses three advisory verdicts:

PASS means the PR is shippable for its stated customer-facing scope.

HOLD means the work may be valuable, but the proof is incomplete. Missing docs, missing demo path, missing walkthrough evidence, unverified claim, unclear failure behaviour. The work might be close. The customer case is not.

BLOCK means the work is misleading, unsafe, unreproducible, or contradicts the customer story.

The distinction between HOLD and BLOCK is important. Most teams overuse the moral force of blocking language. Not every proof gap is a crisis. Sometimes the answer is simply: this might be right, but we have not earned the right to say so yet.

That posture keeps JUNIE useful rather than theatrical.

Her output should include praise when it is earned, criticism when the evidence supports it, and specific recommendations. “Add tests” is usually too vague. “The PR claims the onboarding flow works for a new workspace, but the verification only covers an existing seeded workspace; run the new-workspace path and capture the first failure state” is useful.

Useful criticism names the customer risk.

She needs a memory, not a personality cult

There is a temptation, when building agents, to spend too much time on persona.

Give the agent a name. Give it a voice. Give it a cute backstory. Watch the team start discussing the mascot instead of the work.

JUNIE has a name because roles need handles. She does not need theatre. She needs memory.

Every time JUNIE acts, she should write down what happened: the PR, the claim, the evidence accepted, the evidence rejected, the verdict, the recommendation, the author response, the outcome. Did the PR merge? Did the author change the docs? Did the walkthrough improve? Did JUNIE overstate risk? Did she miss something a customer later found?

That journal is not bureaucracy. It is how an advisory agent earns or loses trust.

If JUNIE keeps finding real customer-proof gaps early, her authority should increase. If she creates noise, blocks useful work, misunderstands context, or mistakes internal neatness for customer value, her standards should be changed. Not by letting her rewrite herself because someone left a comment, but by curating feedback into better prompts, rubrics, and checks.

The agent may prepare her own performance review. She does not promote herself.

There is a second benefit, and it may be the more interesting one. JUNIE becomes a competent customer before you have customers.

She is not the whole market. She is not a substitute for discovery, design research, support tickets, sales calls, or the first painful month of real usage. But she is a persistent, technically literate, increasingly capable customer-shaped presence in the workflow. She remembers what she tried last time. She remembers where the docs misled her. She remembers which happy path worked only because the seed data was perfect. She remembers which log line proved the thing happened and which one left the team guessing.

Over time, that memory becomes a mirror. You can watch what kind of customer JUNIE is becoming and ask the awkward question: Damn, is that the customer we expected?

If she keeps misunderstanding the product, maybe she is wrong. Or maybe the product is teaching customers to misunderstand it. If she keeps caring about evidence the team thought was secondary, maybe she is being fussy. Or maybe the team has been optimising for internal elegance while the customer is looking for trust.

What this changes for the team

The immediate change is small.

Pull requests need to make a customer claim explicit. Not every PR has one. Refactors, internal chores, dependency updates, and infrastructure work may be mostly internal. Fine. Then say that. Do not invent a customer story where none exists.

But when a PR does claim customer-facing value, the author owes the workflow a proof path.

That changes the PR from a bundle of changes into a case:

Here is what the customer can now do.
Here is where we say that.
Here is how JUNIE, or a human, can verify it.
Here is what passed.
Here is what we did not verify.
Here is why the remaining risk is acceptable.

This is not heavyweight process. It is the minimum honesty required when AI-assisted teams can generate convincing artefacts faster than humans can judge them.

The point is not to slow delivery down. The point is to stop mistaking velocity for progress.

The broader pattern

JUNIE is one example of a wider shift I think is coming.

AI-assisted teams need more than coding agents. They need role agents that represent missing organisational perspectives at the point work is created. Security is one. Architecture is one. Cost is one. Operations is one. The customer is the one we have underrepresented the most, because we keep pretending the customer appears later.

Later is too late.

By the time a customer discovers the workflow does not match the claim, the team has already spent the credibility. By the time a demo fails in front of an evaluator, the explanation sounds like an excuse. By the time the docs are found to be aspirational, the product has taught the user not to trust the next page either.

JUNIE exists to bring that downstream judgement upstream.

She is not a replacement for product management, QA, design review, or engineering judgement. She is a forcing function for evidence. She asks the question that should have been asked before the code was written and keeps asking it until the answer is observable.

Does the work prove the customer claim?

If yes, ship it.

If not, do not decorate uncertainty as done.

That is the standard we are trying to build into our workflow.

Steve Chambers writes about coherence infrastructure for AI-assisted development. Viewyonder builds practical GenAI systems and the operating disciplines that keep them honest. If your team is shipping faster than it can prove what changed, get in touch.