Chiosa
Research collection

Software & Code

Research on Software & Code: explanations, evidence, limitations and connections between papers.

31 results

  1. Guided lessonSoftware & Code

    Inspect behavior and provenance before reusing a coding capability

    A coding team might call a specialist agent that helped before or copy a skill file from another repository. Reuse can spare repeated work, yet a prior passing solution can also carry a way to game a test. The studies suggest a practical first step: check the capability’s behavior in the current task and trace its source. Evidence from an agent library, coder-to-coder imitation and GitHub skill copies supports that judgment in different tested settings.

  2. Guided lessonSoftware & Code

    Match each software test to the failure it must expose

    A generated regression test can pass on faulty code if it adopts the faulty output as its expected answer; fixing that bug may then make the test fail. A test can also reject a valid implementation or miss a concurrency bug if the revealing thread order never runs. Read each verdict against the comparison that produced it: which failure, implementation, and execution could the test distinguish? These three studies support claims about their injected faults, labeled implementations, and controlled schedules, not software reliability in general.

  3. Guided lessonSoftware & Code

    Place review where an uncertain signal would change the dataset

    A brain scan can resemble another scan without proving that both belong to one person. A math problem can resemble a benchmark question without being copied from it. In either case, acting on resemblance changes the dataset. Across identity auditing, math-data cleaning, and multilingual example construction, the useful question is where an uncertain signal meets a decision. The studies place review at different points in those workflows and measure different outcomes, so their results support a placement principle rather than one shared estimate of review’s benefit.

  4. Guided lessonSoftware & Code

    Match software automation claims to the checks that produced them

    A tool can trigger a concurrency bug, produce a patch that passes issue tests, or name a bug in a code review. Each sounds like success, but each workflow sees different evidence and uses a different check. Read an automation result by asking what behavior the study reached, what counted as success, and which task conditions limited that check. These studies support conclusions about their tested workflows; their outcomes answer different questions.