Skip to content
1DevTeam R&D Program #1

Architectural reasoning scope and corrective PR cascades

1DevTeam's first formal R&D program studies architectural reasoning scope and corrective PR cascades in AI-assisted software development. The study examines whether mismatches between the scope applied to a software change and its actual architectural blast radius predict subsequent corrective work.

Formal study title

Architectural Reasoning Scope and Corrective PR Cascades in AI-Assisted Software Development: A Longitudinal and Prospective Study of Ajenda AI

Primary research question

Does mismatch between the reasoning or change scope applied to a software modification and the actual architectural blast radius of that modification predict subsequent corrective pull-request cascades?

Scientific boundary

This study is an empirical investigation, not a product-validation exercise. Graph-assisted development, invariant-centered repair, Grafted Plus, and Grafted First are not assumed to be superior in advance.

Positive, negative, null, and contradictory results remain valid research outcomes. Product objectives do not determine scientific conclusions, and preliminary observations remain revisable until the evidence supports a stronger classification.

Study epochs

Preserving the intervention boundary

The periods before, during, and after graph introduction remain distinct development conditions. Earlier work is not retroactively described as an immature form of graph assistance.

  1. 01

    Pre-Graph

    The architectural graph did not yet exist. Development relied on repository inspection, testing, traces, PR review, manual architectural reconstruction, and the existing PRIDE development discipline.

  2. 02

    Graph Construction

    The architecture graph and associated CI capabilities were introduced and expanded, including semantic overlays, blast-radius analysis, invariant mapping, proof selection, and governance controls.

  3. 03

    Graph-Assisted Development

    Graph-derived architectural state, impact analysis, proof selection, completeness checks, and increasingly fine-grained decision ownership became available during active development.

Measurement

What the study measures

The objective is to distinguish successful local modification from system-level repair quality and subsequent corrective propagation.

  • 01Reasoning scope and change scope applied to the repair.
  • 02Architectural blast radius, including changed files, runtime surfaces, dependencies, invariants, and affected proof.
  • 03Corrective PR propagation and whether later work repairs an introduced defect, exposes a latent defect, or extends an incomplete repair.
  • 04Repair-unit type and the ownership layer at which the change is applied.
  • 05Local proof versus system-level proof and the residual state intentionally left unresolved.
  • 06Graph state and expected versus observed graph-state movement after repair.
  • 07Test coverage, CI maturity, codebase maturity, model and tool capability, PR size, defect class, and related confounders.
  • 08Where failures are detected: later corrective work, pre-merge proof, graph governance, or semantic enforcement.

Applied R&D relationship

Grafted Plus and Grafted First

The study can inform Grafted Plus and Grafted First, but those systems remain development outputs rather than evidence of the study's conclusion. Research may support their current design assumptions, narrow them, contradict them, or expose different mechanisms entirely.

Existing systems
Applied R&D output · in development

Grafted Plus

Grafted Plus is intended to reconstruct and expose the architecture of an existing software system so an external language model can reason over system structure, ownership, dependencies, invariants, and change impact with less repeated architectural reconstruction. Its capabilities and comparative value remain subjects of active development and research.

Existing system → reconstruct architectural state → expose ownership, dependencies, invariants, blast radius, and proof relationships → reason across the system.

Project-origin architecture
Applied R&D output · in development

Grafted First

Grafted First is intended to model the architecture of a software system before implementation begins. The objective is to represent contracts, nodes, models, ownership, dependencies, state, boundaries, and system interactions in a form that can be reasoned over before the first implementation decisions are committed to code. Its relationship to implementation quality remains a research and development question rather than an established conclusion.

Intended system → explicitly model the architectural problem → reason across the complete design → build against that model.

Intended future relationship

Grafted First → intended architecture → implementation → Grafted Plus → reconstructed architecture → drift analysis

This remains a development hypothesis, not a completed research finding.

Research operating policy

Controls on interpretation

Scientific conclusions remain independent

The study is an empirical investigation, not a product-validation exercise. Positive, negative, null, and contradictory results remain valid research outcomes, and product objectives do not determine scientific conclusions.

Preserve the graph intervention boundary

The pre-graph period is coded as graph absent. Graph construction and graph-assisted development are separate epochs so the intervention is not retroactively projected onto earlier work.

Triangulate material findings

Material findings are evaluated across chronology, PR context, human directives, assistant-generated operational prompts, repository architecture, changed-file scope, CI and proof behavior, corrective relationships, graph state, and relevant confounders.

Separate instruction origin

Human directives and assistant-generated operational prompts are treated as distinct sources when evaluating whether workflow changes came from instruction differences or from a different reasoning environment.

Control competing explanations

CI maturity, model and tooling changes, codebase maturity, test coverage, repair-unit type, PR size, and defect class are treated as competing explanations rather than being silently attributed to graph assistance.

Current research status

Observations remain distinct from findings

Preliminary observations can be revised, contradicted, or rejected as additional evidence and causal coding are completed.

Preliminary qualitative note

Human directive style does not appear to explain the whole shift

Terse, verification-oriented human directives appear in both graph-absent and graph-assisted cases. The full prompt corpus is not yet quantitatively coded, so this remains a covariate under measurement rather than a frozen finding.

Observed workflow difference

Persistent architectural state changes the reasoning substrate

Before the graph existed, system structure had to be reconstructed repeatedly from code, tests, traces, and prior context. Graph-assisted work can expose nodes, edges, authority relationships, blast radius, invariants, and proof obligations as persistent machine-readable state.

Observed measurement capability

Repairs can be evaluated against residual system state

A green test suite is not the only available finish signal. A targeted repair can also be compared with expected graph-state movement, preservation of unrelated residual findings, and post-merge recertification.

Exploratory hypothesis

Graph assistance may move some failures earlier

One hypothesis under investigation is that graph-governed workflows may shift some failures from later corrective PRs into earlier semantic detection, proof selection, or governance review. This is distinct from claiming that graph assistance reduces failures overall.

Confounder control

Process discipline and CI improvement predate the graph

PRIDE-style requirements for complete reasoning predate the graph, while CI and proof infrastructure also matured over time. Neither can be credited to graph assistance without separate evidence.