PLURISE

PLURISE is an exploratory human–AI interaction research prototype examining how control over the application of AI-generated code may influence developer verification behaviour.

The prototype compares two interfaces that use the same programming task, starting code, AI-generated patch, and test suite. The only intended difference is whether the developer or the AI agent controls when the patch enters the working codebase.

View the live prototype

Research status

PLURISE is an exploratory research prototype. It has not been used to conduct a completed participant study, and this repository does not present empirical findings.

The interaction traces shown by the prototype are generated locally to demonstrate the proposed research instrument. They are not participant data and should not be interpreted as research evidence.

Research question

How does transferring control over code application from the developer to an AI coding agent affect developers’ verification behaviour and calibrated reliance?

Many AI coding interfaces propose a change and wait for the developer to accept it. More agentic systems can modify the working codebase directly and report afterwards. That shift moves a boundary: the developer is no longer the gate a change passes through, but someone who meets the change after it has landed.

Moving that boundary may change whether and when developers inspect a diff, run tests, edit the result, and understand what the AI actually did, and whether their confidence matches the code’s real correctness. PLURISE isolates the boundary so it can be studied on its own.

Experimental conditions

Condition	Application control	Behaviour
Human-gated	Developer	The AI prepares a patch, but the developer decides if and when to apply it.
Agent-applied	AI agent	The AI applies the same patch immediately and then reports what changed.

Both conditions use the same task, initial code, generated patch, test suite, and workspace. The intended experimental manipulation is the actor controlling when the patch enters the working file.

Only the wording that describes the patch’s state differs (“Suggested change ready” versus “Updated src/retry.ts”), because it has to say truthfully whether the change is proposed or already applied.

Prototype task

The user is asked to make an asynchronous JSON request helper more resilient by adding:

• Retries for network failures
• Retries for HTTP 429 responses
• Retries for 5xx responses
• Exponential backoff
• No retries for other 4xx responses
• Correct AbortSignal behaviour

The deliberate defect

The predetermined AI patch is intentionally almost correct. It retries the appropriate responses and implements exponential backoff, but its backoff timer cannot be interrupted by an AbortSignal:

function wait(ms: number) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

The signal is passed to fetch, and the code even checks options.signal?.aborted, so it looks as though cancellation is handled. But an abort that arrives during a backoff wait stays pending until the timer fires.

As a result, five of the six tests pass. The remaining failure gives the user a reason to inspect, test, and potentially correct the AI-generated code. This is scenario design, not a bug in the repository, and the canonical patch must not be “fixed”.

Expected test outcomes

Working file	Result
Initial code	2/6 passed (parses JSON; does not retry a 404, because it retries nothing)
Canonical AI patch	5/6 passed (fails aborts immediately during backoff)
Corrected code (abort-aware wait, signal passed in)	6/6 passed

These outcomes are asserted in tests/.

What the prototype demonstrates

PLURISE demonstrates how a proposed research question can be translated into an interactive instrument.

The prototype includes:

• Two controlled AI-application conditions
• A code-editor-style workspace
• A predetermined AI-generated patch
• An intentionally subtle implementation defect
• A deterministic test runner
• Local behavioural instrumentation
• A short manipulation check
• A researcher-facing interaction-trace summary
• Local JSON trace export

The prototype does not connect to a live AI model. AI responses and code changes are predetermined so the two conditions remain comparable.

Interaction trace

The prototype records these events locally:

• Condition initialisation
• Patch application and who applied it (developer or agent)
• Diff views
• File navigation
• First manual code edit, then edit bursts (counts only, never the code)
• Test runs
• Test outcomes
• Comprehension (manipulation-check) response
• Confidence response
• Relative event timings, from a monotonic clock

From the event sequence it derives measures such as time to first test, whether the diff was viewed before the first test or before application, and the order of verification steps.

The trace is held in memory in the browser tab and can be exported locally as JSON. The prototype does not require a backend or participant database, and the exported file never contains editor contents.

Research invariants in the code

• lib/scenario.ts is the single source for the task, initial code, canonical patch, test file and condition copy. Both conditions read CANONICAL_AI_PATCH; there is no second copy.
• tests/condition-parity.test.ts asserts that the working file is byte-identical in both conditions once the patch has entered it, and that both conditions show the same diff.
• In the agent-applied condition the patch is in the working file before the agent’s message renders, and the trace records patch_applied with actor agent at 0 ms. There is no control to prevent it; that absence is the manipulation.
• Switching condition or resetting starts a new session with a new ID, a fresh clock and an empty trace.
• The diff and its “41-line” label are computed from the real initial code and patch, so what a participant reviews is exactly what lands in the file.

Running locally

Requirements

• Node.js 22.18 or later (the unit tests run TypeScript directly with Node’s built-in test runner)
• npm

Setup

git clone https://github.com/uzoway/plurise-research-prototype.git
cd plurise-research-prototype
npm install
npm run dev

Open http://localhost:3000.

Checks

npm run lint
npm run typecheck
npm test

Production build

npm run build
npm run start

Technical implementation

• Next.js (App Router), React and TypeScript, styled with CSS Modules, with Motion for state transitions and Lucide icons.
• Static, client-side scenario. No backend, AI API, database, authentication or analytics.
• One reducer owns every transition (lib/session-state.ts), so condition rules are enforced in one place: only the developer can apply, only where the gate exists.
• Deterministic test runner (lib/evaluator.ts). It does not execute code. It reads the working file and checks for the capability each test needs (status classification, exponential backoff, an abort-aware timer that receives the signal). The same code always gives the same result and durations.
• Derived, not stored, metrics (lib/instrumentation.ts). Summary values are computed from the ordered event log, so the summary, timeline and export cannot disagree.
• Textarea-based editor with a syntax-highlight overlay, line numbers, change markers, native undo, and Tab indentation that can be escaped with Esc then Tab.
• Accessibility: full keyboard operation, a polite live region for test and patch state, native radio inputs, non-colour state cues, and reduced-motion, reduced-transparency, increased-contrast and forced-colours support.

Limitations

• V1 is a researcher-facing demonstration, not a participant-ready study deployment.
• The programming task and AI response are predetermined.
• The test runner is designed specifically for the prototype scenario. It checks code capabilities rather than executing code, so an unusual but valid fix could be misjudged.
• No participant recruitment or data collection has taken place.
• The current interface exposes condition labels for demonstration purposes.
• The prototype evaluates one task and one intentionally flawed patch.
• The prototype does not measure real-world longitudinal use of AI coding agents.

Possible future work

• Participant mode with hidden condition labels
• Randomised or counterbalanced assignment
• Additional programming tasks
• Real sandboxed code execution
• Consent and withdrawal flows
• Secure research-data submission
• Pre-registered behavioural measures
• Pilot testing
• A formal participant study
• Analysis of verification sequences and confidence calibration

Licence

The source code is released under the MIT licence. The licence covers the software in this repository; it does not extend to the research concept, study design, or any future study data.

Author

Built by Uzo Okafor.

• Live prototype
• Source
• Portfolio
• GitHub