I built clean and deliberately degraded versions of the same small program, then gave both versions twelve maintenance tasks. Both passed every hidden test. This paper reports that result, the differences that appeared in the source code, and the larger study needed to find out whether those differences eventually cost an AI maintainer time or accuracy.
Research framing
When an AI agent modifies a codebase, do names, documentation, types, module boundaries, and tests affect whether it makes the right change? How does the answer change when the repository grows or the ticket leaves room for interpretation?
In this pilot, names and docstrings did not change whether a task passed. Types, shared helpers, and duplicated logic changed the shape of the source, but the pilot did not show that they changed maintenance cost. Human reviewers may still face costs that the task grader could not see.
The clean and degraded files produced the same tested behavior even though their complexity, duplication, types, documentation, and coding conventions differed.
We still need to test larger repositories, incomplete tickets, fresh agent sessions, different models, and human review.
The claim above remains provisional. The later studies turn its separate parts into testable predictions.
Pilot study
Both variants began as the same deliberately buggy task-manager library of about 50 lines and received the same maintenance tasks in the same order.
Typed dataclasses, descriptive names, validation helpers, docstrings, and shared access patterns.
Dictionaries, one-letter names, no types or docstrings, redundant boolean comparisons, and repeated raw-data access.
By round 12, both variants supported priorities, due dates, tags, subtasks, notes, search, archiving, bulk operations, and recurring tasks. Their public method names matched, while their return representations differed.
tm = TaskManager()
task = tm.add_task("Ship the working paper", priority="high", tags=["writing"])
tm.add_subtask(task.id, "Draft outline")
tm.complete_task(task.id) # blocked until the subtask is complete
tm.complete_subtask(task.id, 1)
tm.complete_task(task.id)Clean versus deliberately degraded source code.
The same twelve tasks, applied sequentially to both variants.
A hidden pytest suite written from each task specification before either variant was changed.
Complexity, maintainability index, duplication, code churn, and selected anti-pattern counts.
Important limitation: I wrote both variants, interpreted every task, and performed the maintenance. The whole program fit in context, every ticket specified the required behavior, and the grader hid the interface difference between dataclasses and dictionaries. The pilot is useful for designing the next experiment, but it cannot support a general causal claim.
Measurement
Passing tests is necessary but insufficient. A program can remain behaviorally correct while becoming harder to change, inspect, or recover. The pilot therefore records both task outcomes and structural proxies, using the product-quality categories in ISO/IEC 25010:2023 as a reference.
Hidden tests passed, regressions introduced, and edits needed to reach a passing state.
Cyclomatic complexity, Radon maintainability index, duplication, code churn, and selected anti-patterns.
The pilot did not record misunderstood requirements, files the agent failed to find, elapsed time, or the accuracy of human review.
The structural metrics are not a composite “cleanliness score.” Each is reported separately, and none directly measures whether a change was safe or understandable.
Results
Both variants passed 60/60 hidden tests with zero recorded regressions across twelve rounds.
| Round | Task | Clean edits | Degraded edits | Regressions |
|---|---|---|---|---|
| 1 | Bug fix | 1 | 1 | none |
| 2 | Priority levels | 1 | 1 | none |
| 3 | Due dates | 1 | 1 | none |
| 4 | Title validation | 1 | 1 | none |
| 5 | Tags | 1 | 1 | none |
| 6 | Typed not-found errors | 1 | 1 | none |
| 7 | Subtasks | 2 | 3 | none |
| 8 | Task notes | 2 | 1 | none |
| 9 | Bulk operations | 1 | 1 | none |
| 10 | Search | 1 | 1 | none |
| 11 | Archiving | 3 | 2 | none |
| 12 | Recurring tasks | 4 | 3 | none |
The degraded variant remained about 1.26–1.27 times as complex as clean, but the ratio did not widen. Duplication appeared in the degraded variant after bulk operations were introduced. The edit-count proxy favored degraded code by 11 edits to 13, contrary to the prediction. Because edit count reflects tool-call granularity rather than cost, later studies must use tokens, elapsed time, changed lines, and repair cycles.
| Round | Clean LOC | Clean CC | Clean dup% | Degraded LOC | Degraded CC | Degraded dup% |
|---|
Interpretation
Under a complete specification and hidden tests, both small variants reached the same behavioral outcomes.
Complexity and duplication distinguished the variants, although the experiment did not show that these differences caused maintenance cost.
The study did not vary scale, ambiguity, context availability, maintainer independence, model choice, or human oversight.
That is the pilot finding: the tests reported no difference while the source measurements did. The next study asks whether those source differences affect an agent when the work is larger, less specified, or spread across more files.
Research program
The next papers are separated by the study they report. One tests AI maintenance; another tests human review.
Record the result, identify weak measurements, and specify what the next experiment must change.
Separate readability from structure, vary scale and specification quality, and test pre-registered maintenance hypotheses.
Test whether reviewers can explain matched changes, identify risks, and decide when to escalate.
Integrate technical maintenance and organizational oversight once both have direct evidence.
Bounded-task equivalence. When a ticket specifies every required behavior, the tests cover those behaviors, and the relevant code fits in context, clean and degraded variants will be equivalent on task success within a pre-registered margin.
Structural-debt interaction. When a change crosses more dependencies, follows an incomplete ticket, or builds on a longer edit history, degraded code will produce more failures, regressions, and repair work.
Readability interaction. Descriptive names and documentation will matter more when the agent must infer intent than when the ticket specifies the behavior.
Governance cost. Human reviewers will take longer and make more errors when auditing degraded code, even where AI task completion remains equivalent.
Model sensitivity. Outcomes on degraded code will vary more across models and agent configurations than outcomes on clean code.
The pilot changed names, documentation, types, data representation, duplication, and helper structure at the same time. The next study must vary readable names and documentation separately from properties enforced by types, contracts, or shared interfaces.
| Condition | Human readability | Structural constraints | Purpose |
|---|---|---|---|
| Clean | High | High | Reference condition |
| Readable / weak | High | Low | Isolate readability |
| Terse / structured | Low | High | Isolate types, contracts, and shared interfaces |
| Degraded | Low | Low | Combined treatment |
Mixed Workforce connection
The Mixed Workforce Company argues that a company remains accountable for work it delegates to AI. This project examines one practical consequence: code may be easy for an agent to change and still be difficult for a person to inspect.
Measure correctness, regressions, repair cost, retrieval, and performance across code conditions.
Measure audit accuracy, review time, confidence, explanation quality, and escalation decisions.
Readable code may matter less when an agent makes a routine change, yet still matter when a reviewer must approve that change or investigate a failure.
This pilot does not test that proposition. Paper 3 requires a separate human-participant study with matched diffs, blinded reviewers, counterbalanced ordering, and pre-registered scoring criteria.
Reproducibility materials
The repository contains both round-12 variants, the 60-test grading suite, per-round snapshots, metric logs, the pilot report, and the protocol for later studies.
Glossary