Skip to main content
Parslee Labs

Engineering briefs

Your CI cannot ask whether the merge was a good idea

Design briefs on systems we actually run, published in full. Internal names, file references and vendor specifics are stripped — the patterns are the point, and none of them require Parslee tooling to adopt.

These are not research papers. They argue from operating experience rather than from an evaluation, and they carry no benchmark. The StateBench papers are over here.

The briefs

Published in full, free, no gate

Each brief states its own scope limit. Counter-examples are more useful to us than agreement — the closing page says how to send one.

Design briefRev 1.021 pages · 864 KB PDF · ~30 min

Two Contracts for Autonomous Code Change (PDF, 21 pages, opens in a new tab)

On post-merge review, machine-authored fixes, and the engineering discipline of refusing to believe yourself

Matt Liotta · Parslee Labs

A closed loop writes code, merges it, then reads its own merges back. Two roles decide whether that is safe: one is not allowed to believe what it is told, the other is not allowed to trust itself.

How it opens

Somewhere in your pipeline there is probably a machine that writes code, or one that reviews it, or one that will do both by the end of the year. The interesting engineering is not in getting the model to produce a patch — that part is nearly free now. It is in everything you build around it so that a patch can be trusted, and so that when it can't be, the system says so out loud instead of quietly shipping.

What is inside

  1. Part One

    The question CI cannot ask

    Why a suite written by the author inherits the author's blind spots, and why the trigger is a merge event rather than a person.

  2. Part Two

    The Observer — the contract about epistemics

    Read the outcome before the narrative, and never let step two revise step one. Six mechanisms, each a consequence of that contract.

  3. Part Three

    The Improver — the contract about authority

    Every capability listed next to the fence around it. Refusal as a first-class outcome, and an oracle the improver cannot edit.

  4. Part Four

    The interlock, and the closing loop

    The thing the Improver cannot check about itself is exactly what the Observer reads. If you read nothing else, read this.

  5. Part Five

    The transferable list

    Fourteen principles, and three to start on this week. None require our stack.

  • post-merge code review
  • autonomous code change
  • LLM-as-judge self-preference
  • reward hacking
  • agent sandboxing
  • AI code review

ScopeThis describes two roles of a four-role subsystem, as they were built and operated at Rev 1.0. It is a design brief, not an evaluation: there is no benchmark here and no claim that these contracts outperform an alternative. Internal names, file references and vendor specifics are stripped by design — nothing in it requires Parslee tooling to adopt.

Cited work

  • Sharma et al. Towards Understanding Sycophancy in Language Models · ICLR 2024
  • Panickssery et al. LLM Evaluators Recognize and Favor Their Own Generations · NeurIPS 2024
  • Smith et al. Is the Cure Worse Than the Disease? Overfitting in Automated Program Repair · ESEC/FSE 2015
  • Baker et al. Monitoring Reasoning Models for Misbehavior and the Risks of Promoting Obfuscation · 2025
Cite this brief: Two Contracts for Autonomous Code Change
@techreport{parslee-two-contracts-autonomous-code-change,
  title       = {Two Contracts for Autonomous Code Change},
  author      = {Matt Liotta},
  year        = {2026},
  month       = {August},
  institution = {Parslee Labs},
  type        = {Engineering Design Brief},
  note        = {Rev 1.0},
  url         = {https://parslee.ai/briefs/two-contracts-autonomous-code-change.pdf}
}

The research behind the product is on the papers hub: five free PDFs on AI agent memory and state correctness, including the audit that withdrew a claim from our own published work.

Read the papers