Coding-agent research is tightening control over generation and verification

Quality control is getting embedded into coding-agent workflows as explicit artifacts. GROUNDING.md treats domain rules as first-class input with higher priority than project instructions, and asks the agent to refuse invalid requests with a cited rule. In static analysis, the best-performing setup also limits free-form generation: a typed JSON intermediate beat direct CPGQL writing and a tool-using agent loop. Both papers make the same practical point. Agent help improves when the model handles interpretation, while hard constraints and deterministic code handle validity.

Testing work in this period targets behavior that ordinary coverage misses. TestGeneralizer starts from one real test, infers the underlying scenario pattern, and expands it into more executable cases; it reports large gains over EvoSuite, gpt-o4-mini, and ChatTester, plus 16 merged tests in a field study. CAT adds call-chain and dependency context to Java test generation and reports better line and branch coverage than PANTA on Defects4J and newer GitHub projects. PrismaDV applies the same idea to data systems by reading downstream task code and dataset profiles together, then generating task-aware data checks with margin gains above 20 F1 points on one benchmark and above 26 on another.

Another strong thread is runtime verification inferred from existing tests. FlyCatcher turns tests into project-specific runtime checkers, using static analysis plus LLM synthesis to track shadow state and catch silent semantic failures during execution. On 400 tests from four Java systems, it inferred 334 checkers, with 300 judged correct, and detected 5.2x more mutants than T2C. This keeps validation active after code generation and after the test suite finishes, which makes it useful for failures that do not crash the program.

A smaller design thread asks what humans need when agents act through software on their behalf. The HX article argues for steerability, auditability, and intervention points as the main design requirements, and gives a concrete example where an agent should expose a 78% confidence level to the user. The piece is conceptual and has no benchmark, so it does not carry the same weight as the papers above. It is still a useful lens for reading the rest of the period: many of the stronger papers add constraints, inspection points, or recovery loops around model output.