Research idea

Executable Validation Layers

Day · 2026-04-12 · Software Intelligence

The concrete work is moving into tool boundaries and executable checks. A durable write surface for MCP-style coding agents looks ready for direct productization. In security analysis, execution evidence before repair looks like a practical change to AppSec workflows, with clear gains in false-repair reduction. In Java verification and testing, generated counterexample tests look useful as a filter for noisy inferred specifications.

3 ideas

Durable MCP file-write boundary for coding agents

Coding agents need a hardened write tool before they need more autonomy. The clearest build here is an MCP file-write server that exposes atomic writes, chunked resume, typed error payloads, and scratch storage as first-class operations. Resilient Write reports that this layer cut write attempts from 6 to 2 in a replayed failure case, reduced recovery time from 10.0 seconds to 2.0 seconds, lowered estimated data-loss probability to 0.1%, and raised self-correction to 65%.

The user is any team running edit-test-commit loops through an agent and seeing silent write failures, repeated retries, or lost drafts when a session drops. The immediate product surface is narrow: safe_write, append_chunk, finalize_chunks, persist_draft, and handoff_state with typed JSON errors that tell the agent whether to retry, redact, split content, or stop. A cheap validation check is to replay known bad cases such as blocked payload patterns, oversized file outputs, and interrupted sessions, then measure repeated calls, time to recovery, and whether the agent preserves the draft without human cleanup.

Execution-gated vulnerability repair workflow

Security repair pipelines can add an execution gate before patch generation. Verify Before You Fix shows a practical workflow: detect a suspicious case, generate an exploit hypothesis and test harness in a sandbox, require execution evidence, then allow the repair model to act. In the reported pipeline, this removed 61.24% of false positives, avoided 73.13% of unnecessary repairs, and resolved 69.74% of vulnerabilities end to end.

This fits teams that already run SAST or model-based triage and are spending review time on patches for issues that were never exploitable. The concrete build is a verifier service that accepts a finding plus repository snapshot, creates a containerized reproduction attempt, records execution traces, and returns a typed verdict for the patching stage. The first deployment target is internal AppSec tooling for Java, Python, and C++ repositories where repair throughput matters more than maximum detector recall. A cheap check is to sample recent findings, run the verifier before patch generation, and compare human review time, false repair rate, and reopened tickets.

Counterexample JUnit generation for specification inference review

Dynamic specification inference can use generated counterexample tests as a review filter. The practical build is a Java toolchain step that takes inferred postconditions from SpecFuzzer or Daikon-style systems, asks an LLM for executable JUnit counterexamples for doubtful assertions, compiles those tests, and reruns inference on the expanded suite. On 43 Java methods, the reported method removed 1,877 invalid assertions with GPT-5.1 and improved precision to 74.17% without recall loss; DeepSeek-R1 removed 2,173 invalid assertions.

The first users are teams that maintain contract-heavy Java libraries, verification tooling, or test-generation workflows and are blocked by noisy inferred assertions. The main operational value is lower manual review volume before those assertions feed documentation, regression checks, or repair systems. A cheap check is to run the loop on a small set of methods with known weak test coverage and count how many inferred postconditions disappear after compiling and adding the generated counterexamples.