Adam Zachary Wasserman › Papers

Process Discipline as the Key Variable in AI-Assisted Enterprise Software Development

A Natural Experiment

Adam Zachary Wasserman, Open Honest Foundation. Preprint, 31 March 2026.

Download the PDF

Full text

The complete paper follows. It is identical to the deposited PDF; the PDF is the version of record and carries the figures at full resolution.

Adam Wasserman CTO, Buckler

March 2026

Abstract

The published research on AI-assisted software development produces contradictory findings: controlled studies report both 55.8% speedups (Peng et al. 2023) and 19% slowdowns (METR 2025) on developer tasks. Quality-focused studies consistently report negative downstream effects: 4x more duplicated code, 60% less cleanup activity (GitClear 2025, 211M lines), and 7.2% delivery stability decreases per 25% AI adoption increase (Google DORA 2024). No published study has isolated the variable that reconciles these contradictions. The study that would settle the question requires four comparison groups: AI with structured process, AI without structured process, manual coding with structured process, and manual coding without structured process. That study does not exist.

This paper presents a natural experiment that covers the two AI-assisted groups: with structured process and without. A two-person development team, using the same AI coding assistants, produced two applications under different process conditions. Under a structured software development lifecycle (SDLC) designed and controlled by the technical architect, the team built a platform in Python/FastAPI following a specified architecture, satisfying 18 enterprise dimensions that cover the criteria bank technology assessments measure, at 8-10x published elite productivity benchmarks. When organizational authority over the development process shifted from the technical architect to non-technical stakeholders prioritizing business deliverables, the same team using the same tools produced a React application satisfying 2 of 18 enterprise dimensions, with no tests, no automated quality pipelines, and no code review. The technology choice itself is part of the finding: without architectural constraints, the AI assistants defaulted to React, the framework they are most trained on, rather than the architecture specified for the project.

A second natural experiment within the same dataset reinforces the finding: a single developer’s commit history on one codebase captures both the unstructured period and the subsequent introduction of the structured SDLC, with the quality transition visible in the commit record.

The team composition and AI tools remained constant across both conditions. The technology stack diverged: the structured condition used Python/FastAPI following a specified architecture; the unstructured condition used React, the default framework AI assistants produce when given no architectural constraints. The variable that changed was who controlled the development process and what constraints that process imposed on AI-assisted code generation. The findings are consistent with DORA’s (2025) characterization of AI as an “amplifier” of existing process quality, and provide granular, project-level evidence for a thesis that has until now been supported only by aggregate survey data.

All metrics are derived from git commit history, source code analysis, and published industry benchmarks. The methodology is described in sufficient detail for replication on any comparable codebase.

Keywords: AI-assisted software development, software development lifecycle, process discipline, natural experiment, enterprise software quality, function point analysis

1. Introduction

AI coding assistants have been widely available since late 2022. The question of whether they make developers faster, slower, or simply different is not settled. The published evidence is contradictory, and the contradictions are informative.

Peng et al. (2023) conducted a randomized controlled trial with 95 developers on a simple HTTP server task and found a 55.8% speedup with GitHub Copilot. The METR study (2025) tested 16 experienced open-source developers on real tasks in real repositories and found they were 19% slower with AI tools while perceiving a 20% speedup. Anthropic’s internal study (2025-2026) reported a 67% increase in merged pull requests per engineer per day among 132 self-selected engineers.

The quality data is less ambiguous. GitClear’s analysis of 211 million changed lines across Google, Microsoft, and Meta repositories (2024-2025) found that copy-paste code increased from 8.3% to 12.3%, code churn increased from 5.5% to 7.9%, and refactoring activity collapsed from 25% to under 10% after AI adoption. Google’s DORA report (2024, 39,000+ professionals surveyed over 10 years) measured a 7.2% decrease in delivery stability for every 25% increase in AI adoption. The 2025 DORA report found a 90% AI adoption increase associated with a 9% climb in bug rates, with individual throughput up but organizational delivery metrics flat (the “stability paradox”). OX Security (2025) identified 10 critical anti-patterns in 80-100% of AI-generated code across 300+ open-source repositories.

A separate body of research documents iterative degradation when AI-generated code is fed back into AI systems. Shumailov et al. (2024, Nature 631, 755-759) demonstrated that generative models trained on their own output undergo irreversible “model collapse.” Shukla, Joshi, and Syed (2025, IEEE-ISTAS) conducted the first controlled study of iterative AI code generation and measured a 37.6% increase in critical security vulnerabilities after just 5 iterations of AI “improving” its own code. Alemohammad et al. (2024, ICLR) coined “Model Autophagy Disorder” (MAD). Dohmatob et al. (2025, ICLR) proved that even 1-in-1,000 synthetic data contamination triggers collapse. Mohamed et al. (2025, ACL) documented the same phenomenon in text, comparing it to the children’s game “broken telephone.”

No peer-reviewed study has isolated the variable that reconciles the speed and quality findings. The study that would settle the question requires four experimental arms: AI with structured process, AI without structured process, manual coding with structured process, manual coding without structured process. That study does not exist. What does exist is converging observational evidence that AI assistance is a multiplier of whatever process discipline surrounds it. DORA’s 2025 report characterizes AI as an “amplifier” of existing organizational maturity, but this finding is based on survey-level correlational data, not controlled observation.

This paper presents a natural experiment that provides project-level evidence for the amplifier thesis. A two-person team produced two applications under different process conditions. The team and the tools were constant. The process authority changed. The outcomes diverged on 16 of 18 measurable enterprise dimensions.

2. Related Work

2.1 Speed Studies

The controlled speed studies measure different things and reach different conclusions. Peng et al. (2023, arXiv:2302.06590) tested a simple, isolated task (an HTTP server) in a peer-reviewed RCT with 95 developers and found a 55.8% speedup. METR (2025) tested real-world tasks in real repositories with 16 experienced open-source developers (average 22K+ stars) and found a 19% slowdown with a perceived 20% speedup. Anthropic’s internal study (2025-2026) reported a 67% increase in merged PRs/engineer/day among 132 self-selected engineers at an AI company. The reconciliation is straightforward: AI accelerates simple, isolated tasks. On complex, real-world tasks in existing codebases, the acceleration disappears or reverses.

2.2 Quality Studies

Quality-focused studies consistently report negative downstream effects. GitClear (2024-2025, 211M lines across Google, Microsoft, and Meta) found duplicated code increased 4x, cleanup activity collapsed from 25% to under 10%, and code churn increased from 5.5% to 7.9%. Google DORA (2024) measured a 7.2% delivery stability decrease per 25% AI adoption increase. The 2025 DORA report found the “stability paradox”: individual throughput up, organizational delivery metrics flat, bug rates up 9%. Xie et al. (2025, arXiv:2510.10165) found a 19% drop in original code productivity in open-source projects after Copilot introduction. OX Security (2025) identified 10 critical anti-patterns in 80-100% of AI-generated code across 300+ repositories. Stack Overflow’s 2025 survey (65,000+ respondents) found positive AI sentiment dropped from 70%+ to 60%, with 66% citing “almost right but not quite” and 45% reporting that debugging AI code is more time-consuming.

He et al. (2025, arXiv:2511.04427) used a difference-in-differences design across 807 Cursor-adopting repositories matched against 1,380 controls and found “substantial but transient velocity gains alongside persistent increases in technical debt,” with static analysis warnings up 18% and cognitive complexity up 39%.

2.3 Generation Loss / Iterative Degradation

Shumailov et al. (2024, Nature 631, 755-759) demonstrated “model collapse”: irreversible quality degradation when generative models train on their own output. Alemohammad et al. (2024, ICLR) coined “Model Autophagy Disorder” (MAD) and showed appreciable quality loss in a handful of generations. Dohmatob et al. (2025, ICLR) proved that even 1-in-1,000 contamination triggers collapse, with larger models amplifying rather than mitigating the effect. Shukla, Joshi, and Syed (2025, IEEE-ISTAS, arXiv:2506.11022) conducted the first controlled study of iterative AI code generation: 37.6% increase in critical security vulnerabilities after 5 iterations, across 400 code samples and 40 rounds. Mohamed et al. (2025, ACL, arXiv:2502.20258) documented the same phenomenon in text.

2.4 The Process Variable Gap

No published study uses a controlled comparison controlling for process discipline as an independent variable alongside AI tool usage. DORA’s 2025 “AI Capabilities Model” identifies 7 organizational practices that moderate AI outcomes and characterizes AI as an “amplifier” of existing maturity, but this is correlational survey data. The DeputyDev longitudinal study (2025, arXiv:2509.19708, 300 engineers, 1 year) measured AI-assisted development within a structured platform but had no “unstructured” comparison arm. The CodeScene/Borg et al. RCT (2025, arXiv:2507.00788, 151 developers) controlled for AI usage but not for process discipline. He et al. (2025) compared AI-adopting vs. non-adopting repositories but did not control for whether adopting teams had structured processes.

The gap is specific: no study holds team and tools constant while varying the development process, and measures enterprise-quality outcomes. This paper addresses that gap with observational data from a natural experiment.

3. Context and Methodology

3.1 Team and Tools

The team consisted of two developers working on enterprise financial software (Canadian wealth management, regulatory compliance):

• Developer A (full-time): CTO. 205 unique active days across all repositories. Designed the structured SDLC, the architectural framework, and served as architectural reviewer for all AI-generated code.
• Developer B (half-time, 0.5 FTE): 163 unique active days. Sole contributor to one major codebase (324 commits), responsible for 88% of a critical two-month infrastructure sprint (212 of 240 commits) on another.

FTE calculation: Developer A = 205 developer-days. Developer B at half-time = 163 active days x 0.5 = ~82 FTE-days. Total: ~287 FTE-days, or ~13.7 FTE-months (at 21 working days/month).

Both developers used AI coding assistants throughout both conditions. The AI tools and team composition are the controlled variables. The programming language is not: the structured condition used Python/FastAPI following a specified architecture (Honest Code framework, HTMX for frontend); the unstructured condition used React (TypeScript/JavaScript). This divergence is itself a data point: without architectural specification, the AI assistants defaulted to React, the framework most represented in their training data.

3.2 The Independent Variable: Process Authority

The independent variable is not “structured process vs. no process” in the abstract. It is who controlled the development process.

Condition 1 (structured SDLC): The development process was designed and controlled by the technical architect (Developer A). The process comprised: - Written functional specifications before implementation - Behavioral test definitions (BDD) before code - Test-first implementation - Architectural review of AI-generated output in real time - Selective sampling and targeted questioning of generated code - Pre-commit hooks enforcing formatting, linting, template validation, and automated test execution - 13 automated quality pipelines

Condition 2 (business-directed process): Organizational authority over the development process shifted from the technical architect to non-technical stakeholders. Business priorities (demo readiness, feature delivery timelines, stakeholder presentations) determined what was built and how. The structured SDLC constraints were not applied. The same developers used the same AI tools without the specification, testing, review, and quality-gate requirements.

This shift was not a decision by the developers to skip process. It was an organizational decision imposed by stakeholders prioritizing business deliverables over technical process. This distinction matters for experimental design: it eliminates self-selection bias. The developers did not choose the unstructured condition. It was imposed on them.

3.3 The Dependent Variables

Enterprise software quality was measured across 18 dimensions that cover the criteria bank technology assessors use, derived from: SOC 2 Trust Services Criteria, NIST SP 800-53, OWASP ASVS, DORA metrics, CIS Benchmarks, and CNCF best practices. Each dimension was assessed against the minimum threshold a bank auditor or technology risk committee would apply.

The 18 dimensions span security architecture (entitlements, authentication, inter-service security), data architecture (multi-tenancy), compliance engineering (audit infrastructure), operational security (rate limiting, configuration and secrets management), performance engineering (caching), operations (notifications), DevOps (CI/CD), infrastructure (containerization), software architecture (dependency injection, pattern sophistication, architectural philosophy), governance (live documentation), process engineering (SDLC with AI safeguards), lifecycle management (tech debt management), and software development (UX/accessibility).

These dimensions were validated by reverse-mapping against three frameworks banks use during vendor assessments: the Shared Assessments SIG Questionnaire (21 risk domains, 1,936 questions), the FFIEC IT Examination Handbook (11 booklets), and OSFI B-13 Technology and Cyber Risk Management (3 domains, 17 principles). Every application-level examination area in all three frameworks maps to at least one of the 18 dimensions.

Productivity was measured in function points per FTE-month using three independent estimation methods plus a verified lower bound: 1. Lines of code backfiring using Capers Jones language-specific ratios (+/- 30% variance) 2. Feature/screen counting using IFPUG heuristics 3. Commit cadence as a consistency proxy 4. BDD scenario inventory as a verified floor (no estimation required)

3.4 The Two Natural Experiments

Experiment 1: Application A vs. Application B. Both applications target the same domain (Canadian financial services). Application A was built under Condition 1 (structured SDLC) in Python/FastAPI. Application B was built under Condition 2 (business-directed process) in React. The team and tools were constant; the technology stack diverged as a consequence of the process change.

Experiment 2: Codebase C before and after SDLC introduction. Developer B was the sole contributor to a third codebase (an identity and access management service). The early commit history shows code produced without the structured SDLC. The later commit history shows the same developer, on the same codebase, after the structured SDLC was introduced by Developer A. The quality transition is visible in the commit record: 175,881 lines of AI-generated bloat were eliminated in a single month during the transition, replaced by properly structured code with organized test suites, cryptographic authentication, and containerized deployment.

4. Results

4.1 Enterprise Dimension Comparison

Application A (structured SDLC) satisfies all 18 dimensions. Application B (business-directed process) satisfies 2 of 18.

Application B has no automated tests, no CI/CD pipelines, no code review process (all code pushed directly to default branch), no structured audit logging, no rate limiting, no container orchestration, no pre-commit quality gates, and no behavioral specifications. It has a working authentication layer (satisfying dimension 2 partially) and basic data models (satisfying dimension 4 partially).

The 16 dimensions that Application B fails are not marginal shortfalls. They are absences. There is no partial credit on a bank’s technology assessment for these controls: they either exist or the assessment fails.

4.2 Productivity Measurement

Four methods were applied to Application A’s codebase. All figures exclude JSON data files, virtual environments, and generated assets.

Industry benchmarks for comparison: Industry median 7-10 FP/dev/month (Capers Jones/SPR, 26,000+ projects; QSM/SLIM, 13,000+ projects; ISBSG, 10,000+ projects). Published elite agile benchmark: 20-26 FP/dev/month.

The conservative estimate (207 FP/FTE-month) places the team at 8-10x the published elite benchmark for manual development. The feature/screen counting method (244 FP/FTE-month), which is independent of LOC and therefore not subject to AI verbosity inflation, produces a consistent result.

4.3 BDD as Verified Floor

The BDD (Behavioral Driven Development) feature files provide a countable, machine-readable inventory of delivered functionality. Each of the 31 BDD scenarios declares a specific system behavior in plain English, verified by an automated test. At IFPUG heuristics (4-6 FP per scenario), the verified floor is 124-186 FP.

This floor covers only user-facing behavior. It excludes all infrastructure work: authentication, caching, rate limiting, CI/CD, containerization, inter-service security. These 17 below-the-waterline dimensions are real engineering effort that produces no user-facing behavior and therefore no BDD scenarios.

The verified floor of 9-14 FP/FTE-month (covering a fraction of the system) already meets or exceeds the industry median of 7-10 FP/dev/month. The gap between the floor and the total estimate is the documented infrastructure and architecture work. This provides a controlled sample against which to validate the total FP estimate: the BDD-covered portion is not estimated, and the remaining work is traceable to specific architectural components.

4.4 Cost Analysis

Developer A compensation: US$12,500/month. Developer B compensation: US$5,000/month. Combined: US$17,500/month. Over 13.7 FTE-months: approximately US$240K in direct salary costs (excluding tools, infrastructure, and overhead).

An industry-median team producing the same output (2,841 FP at the conservative estimate) would require 24 developers at US$16.8K/month fully-loaded cost (Glassdoor 2025 US senior full-stack Python developer average at 1.4x multiplier per MIT Sloan/Hadzima), totaling approximately US$5.5M over the same period.

The structured AI-assisted team produced at approximately 4% of the cost of an industry-median team while satisfying all 18 dimensions.

4.5 Code Quality Signals

4.6 The IAM Transition (Experiment 2)

Developer B’s commit history on the identity and access management codebase captures both conditions:

Before structured SDLC: Test files of 1,000-3,000 lines each generated for single database models. This matches GitClear’s industry-scale finding: AI generates volume without design.

After structured SDLC introduction: In June 2025, Developer B eliminated 175,881 lines in 9 commits:

The replacement code: properly structured database models, organized test suites, cryptographic inter-service authentication, audit trails, containerized deployment. The quality shift was caused by the introduction of the structured SDLC, not by changing the developer, the tools, or the language.

5. Analysis

5.1 Process as the Isolating Variable

The two natural experiments converge on the same finding. In Experiment 1, the same team using the same tools produced radically different enterprise-quality outcomes under different process conditions. In Experiment 2, the same developer on the same codebase produced radically different code quality before and after structured process introduction. The variable that changed in both cases was the development process.

This is consistent with DORA’s (2025) characterization of AI as an “amplifier,” but provides a mechanism that survey data cannot: the structured SDLC constrains the AI’s output through specifications, tests, architectural review, and automated quality gates. Without these constraints, the AI generates volume (lines, files, apparent features) without the enterprise characteristics (security controls, audit trails, test coverage, deployment automation) that regulated buyers require.

5.2 The Three Requirements

The data suggests three necessary conditions for productive AI-assisted enterprise development, any one of which, if absent, produces failure:

1. Structured process discipline: Specifications before code, tests before implementation, architectural review during generation, automated quality gates before commit.

2. Elite-level seniority to enforce it: The architect must recognize when AI output drifts from the specification, interrupt before drift compounds, and review through targeted questioning. These are not mechanical steps. They require the ability to recognize good architecture on sight. The METR study’s finding that experienced open-source developers were 19% slower with AI is consistent: experience with code is necessary but not sufficient. Experience with architecture, with systems thinking, with knowing what an auditor will evaluate, is the additional requirement.

3. A clean starting codebase: AI will not produce code better than the code it learns from. Shumailov et al.’s model collapse research provides the theoretical basis. Shukla et al.’s 37.6% vulnerability increase provides the empirical rate. An AI operating in a well-designed codebase absorbs its conventions and produces code that follows them. An AI operating in a poorly structured codebase absorbs those patterns and reproduces them. The starting point is the ceiling.

These three requirements are multiplicative, not additive. The Buckler data demonstrates what happens when process is removed while team and tools remain constant: the enterprise quality outcomes collapse from 18/18 to 2/18 dimensions satisfied.

5.3 The Exogenous Process Change

The process shift from Condition 1 to Condition 2 was not a developer decision. It was an organizational decision: non-technical stakeholders assumed authority over development priorities, directing the team toward business deliverables (demos, feature presentations, stakeholder requests) without the structured SDLC constraints. The developers did not choose to abandon specifications, testing, and code review. Those activities were displaced by business-directed urgency.

This distinction is methodologically significant. In most observational comparisons of development practices, self-selection bias confounds the results: teams that adopt structured processes may be more disciplined to begin with. In this case, the same team operated under both conditions, and the transition was imposed externally. The process variable was exogenous to the developers’ preferences.

6. Threats to Validity

6.1 Internal Validity

Author as subject. The author designed the structured SDLC, served as architectural reviewer, and wrote this analysis. This is a conflict of interest. The mitigation is that all metrics reported in this paper are derived from git commit history and source code analysis, not from subjective assessment. Commit counts, line additions, line deletions, file counts, and commit timestamps are objective and independently verifiable. The 18-dimension assessment uses published frameworks (SOC 2, NIST 800-53, OWASP ASVS) with stated minimum thresholds.

No randomization. This is a natural experiment, not a randomized controlled trial. The team was not randomly assigned to conditions. The mitigation is that the process change was exogenous (imposed by organizational authority, not self-selected by the developers), which reduces but does not eliminate selection bias.

Confounding variables. The two applications differ in scope and purpose, not only in process. Application A is a larger, more complex platform. It is possible that the complexity itself forced more structured development. The IAM transition (Experiment 2) partially addresses this concern: the same codebase, same scope, different process, different outcomes.

6.2 External Validity

Team size. A two-person team may not generalize to larger organizations. The structured SDLC described here relies on a single architectural reviewer with direct oversight of all generated code. This may not scale without modification.

Domain. The findings are from financial services software built for regulatory compliance. The 18-dimension framework is specific to this domain. The underlying thesis (process discipline determines AI-assisted development quality) may generalize, but the specific measurement framework does not.

Technology stack divergence. The structured condition used Python/FastAPI; the unstructured condition used React. This is a confounding variable: the quality differences could be partially attributed to the technology choice rather than the process. The mitigation is twofold. First, the technology divergence is itself a consequence of the absent process: without an architectural specification, the AI assistants defaulted to React, which is a finding about unstructured AI-assisted development, not an independent variable. Second, Experiment 2 (the IAM transition) controls for language – the same developer, same codebase, same language (Python), with only the process changing – and produces the same quality transition.

6.3 Construct Validity

Enterprise dimensions defined by the author. The 18 dimensions were derived by the author from published frameworks. The mitigation is the reverse-mapping validation: every application-level examination area in the SIG Questionnaire, FFIEC IT Examination Handbook, and OSFI B-13 maps to at least one dimension. The dimensions were not selected to favor the structured application.

Function point estimation. The LOC-to-FP backfiring method has +/- 30% variance (Capers Jones). AI-assisted code may be systematically more verbose than manual code, inflating the LOC-based estimate. The feature/screen counting method (244 FP/FTE-month) is independent of LOC and produces a consistent result. The BDD verified floor (9-14 FP/FTE-month, covering only a fraction of the system) already meets the industry median, providing a lower bound that requires no estimation.

6.4 Proprietary Codebase

The source code is proprietary and cannot be published. This limits independent verification to the methodology and the git-derived metrics. The methodology is described in sufficient detail for replication on any comparable codebase. The author invites independent audit of the git history and source code under appropriate confidentiality arrangements.

7. Discussion

7.1 Implications for the AI-Assisted Development Debate

The findings suggest that the contradictions in the AI-assisted development literature are not contradictions at all. They are measurements of different conditions. AI accelerates simple tasks (Peng et al.) and degrades complex system quality (GitClear, DORA, METR) because the studies measured different process conditions. When AI operates within a structured process with expert oversight and a clean codebase, it produces extraordinary output. When it operates without those constraints, it produces volume without quality. The tool is the same. The process is different.

This reframes the policy question from “should organizations adopt AI coding assistants?” to “under what process conditions do AI coding assistants produce enterprise-quality output?” The answer suggested by this data: structured specifications, test-first development, real-time architectural review of AI output, automated quality gates, and a codebase designed with enterprise constraints from the beginning.

7.2 Implications for Organizational Governance

The exogenous nature of the process change in this study has a specific implication: the quality collapse was caused by an organizational decision, not a technical one. When non-technical stakeholders assumed authority over development process, the enterprise quality outcomes collapsed even though the team and tools remained constant. This suggests that organizational governance of AI-assisted development is as important as the technical practices themselves. A structured SDLC that can be overridden by business urgency is not a structured SDLC.

7.3 Limitations and Future Work

This study provides evidence from a single natural experiment with a two-person team. A complete four-group comparison (AI with and without structured process, manual coding with and without structured process) remains the gold standard for establishing causation. The present data covers the two AI-assisted groups. A complete design would require a manual-coding control, which was not available in this dataset.

The function point estimates, while consistent across three independent methods and validated against a BDD-verified floor, would benefit from independent certification by a certified function point analyst.

Replication across different team sizes, domains, languages, and AI tools would strengthen the generalizability of the findings.

8. Conclusion

No published study has isolated process discipline as a controlled variable in AI-assisted software development outcomes. This paper presents a natural experiment that holds team and tools constant while varying the development process through an exogenous organizational change. The structured condition produced an application satisfying 18 enterprise dimensions covering the criteria bank technology assessments measure, at 8-10x the published elite productivity benchmark. The unstructured condition produced an application satisfying 2 of 18 dimensions, with no tests, no quality pipelines, and no code review.

The findings are consistent with DORA’s characterization of AI as an amplifier but provide granular, project-level evidence that aggregate survey data cannot. The data suggests three multiplicative requirements for productive AI-assisted enterprise development: structured process discipline, elite-level architectural oversight, and a clean starting codebase. When organizational decisions removed the first requirement while the other two remained partially available, the enterprise quality outcomes collapsed.

The contradictions in the AI-assisted development literature are resolved when process discipline is treated as the mediating variable. AI does not make developers faster or slower. It amplifies whatever process discipline – or lack thereof – surrounds the work.

References

Akeyless. (2024). State of Secrets Sprawl Report.

Alemohammad, S., et al. (2024). Self-consuming generative models go MAD. Proceedings of ICLR 2024. arXiv:2307.01850.

Anthropic. (2025-2026). How AI is transforming work at Anthropic. Internal study, 132 engineers.

Boehm, B. W. (1981). Software Engineering Economics. Prentice-Hall.

Brooks, F. P. (1975). The Mythical Man-Month. Addison-Wesley.

Capers Jones, T. (2007). Estimating Software Costs. McGraw-Hill.

CISQ. (2022). The Cost of Poor Software Quality in the US: A 2022 Report.

Dohmatob, E., et al. (2025). Strong model collapse. Proceedings of ICLR 2025. arXiv:2410.04840.

DORA/Google. (2024). 2024 State of DevOps Report.

DORA/Google. (2025). State of AI-Assisted Software Development.

GitClear. (2025). AI assistant code quality research: 211 million lines analyzed.

Glass, R. L. (2003). Facts and Fallacies of Software Engineering. Addison-Wesley.

He, J., et al. (2025). Speed at the cost of quality: Quantifying the impact of AI-assisted coding on code quality. arXiv:2511.04427.

ISBSG. International Software Benchmarking Standards Group. Repository of 10,000+ projects.

Lientz, B. P., & Swanson, E. B. (1980). Software Maintenance Management. Addison-Wesley.

McKinsey. (2012). Delivering large-scale IT projects on time, on budget, and on value.

McKinsey. (2020). Tech debt: Reclaiming tech equity.

METR. (2025). Measuring the impact of early 2025 AI models on experienced open-source developer productivity.

Mohamed, A., et al. (2025). LLM as a broken telephone: Information distortion accumulates over iterative passes. Proceedings of ACL 2025. arXiv:2502.20258.

OX Security. (2025). AI-generated code violates engineering best practices, undermining software security at scale.

Peng, S., et al. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot. arXiv:2302.06590.

Ponemon Institute/ServiceNow. (2019). Costs and consequences of gaps in vulnerability response.

QSM/SLIM. Quantitative Software Management. Database of 13,000+ projects.

Shukla, A., Joshi, H., & Syed, A. (2025). Iterative AI code generation and security vulnerability amplification. Proceedings of IEEE-ISTAS 2025. arXiv:2506.11022.

Shumailov, I., et al. (2024). AI models collapse when trained on recursively generated data. Nature, 631, 755-759.

SonarSource. (2025). State of code quality report.

Stack Overflow. (2025). Developer Survey 2025.

Stripe. (2018). The Developer Coefficient.

Xie, Y., et al. (2025). Experienced developers and AI coding assistants: A longitudinal study of open-source projects. arXiv:2510.10165.

Identifiers

• DOI (Zenodo, canonical): 10.5281/zenodo.19355460
• ORCID: 0009-0002-8865-6583
• Licence: CC BY 4.0

Cite as

Wasserman, A. Z. (2026). Process Discipline as the Key Variable in AI-Assisted Enterprise Software Development: A Natural Experiment. Open Honest Foundation. https://doi.org/10.5281/zenodo.19355460