AI Across the SDLC, Part 1: Seven Ways AI Breaks Your Delivery Pipeline

AI made writing code cheaper. The rest of the software delivery process did not change at the same speed.

A developer now generates a working implementation in minutes. The team still needs to understand the change, review the diff, test the behavior, scan for security issues, deploy it, and support it in production.

The bottleneck shifts from implementation to everything around it. You see it in larger review queues. More generated code needs correction. More duplicated logic reaches the codebase. Security checks find issues later. Tests look green while repeating the same wrong assumptions as the implementation.

This article looks at seven concrete failure modes emerging in AI-assisted development, from maintainability and dependency risks to review bottlenecks, weak tests, security issues, and non-reproducible CI.

For each one, we will look at the evidence, why it happens, and where to fix it in the engineering process.

1. Maintainability degrades quietly

The first problem rarely appears as an incident. Code still compiles. Tests still pass. Features still ship. The codebase simply becomes a little harder to change every week.

GitClear analyzed 623 million code changes between 2023 and 2026. Their data shows several shifts:

This pattern makes sense when you look at how coding assistants work. A model usually receives a bounded slice of the repository. Inside this context, copying an existing implementation often looks safer than introducing an abstraction across five files the model barely sees.

Locally, the solution looks reasonable. Across hundreds of changes, duplication accumulates.

Your velocity dashboard will not show this. The cost appears later, when another engineer needs to change the same behavior in six places.

What to change. Track duplication and maintainability trends alongside delivery speed. Give coding agents repository-level context where possible. Put architecture rules, naming conventions, dependency boundaries, and common abstractions into repository instructions such as AGENTS.md.

2. Hallucinated packages turn generation into a supply-chain problem

Generated code introduces another risk before it even runs: the dependency might not exist.

Research presented at USENIX Security 2025 tested 16 models across 576,000 code samples and collected 205,474 unique hallucinated package names. Rates ranged from 5.2% for commercial models to 21.7% for open-source models.

A plausible package name from a model looks legitimate enough to install. The more interesting finding was repetition. Researchers reran identical prompts ten times, and 43% of hallucinated package names appeared on every run.

This creates a predictable target. An attacker who publishes a package under a repeatedly hallucinated name gets a path from generated code to a developer machine or CI environment.

What to change. Treat dependency creation as a controlled operation. Verify package existence, publisher, age, provenance, and approved registries before installation. Generated dependency names should go through the same supply-chain controls as human-selected dependencies.

3. Secrets move in both directions

AI introduces another data path into development. Code goes from the repository to the model context. Generated output comes back into the repository.

GitGuardian sampled roughly 20,000 public repositories with Copilot enabled. More than 1,200 contained at least one secret. The reported incidence was 6.4% compared with a 4.6% baseline.

A model sometimes generates credential-shaped values inline instead of using a secret store. Developers also paste configuration, logs, tokens, connection strings, and production examples into prompts while debugging.

A few regexes for API keys aren't enough. Private keys, JWTs, connection strings, certificates, encoded blobs, and provider-specific credentials have different shapes.

What to change. Scan input before it reaches an external model or repository context. Scan generated output before commit. Tools such as gitleaks or trufflehog belong before and after the AI step, not several stages later in CI.

4. Faster coding moves the bottleneck into review

It does not increase the number of senior engineers available to understand the code.

Faros AI telemetry across 22,000 developers reports median time in PR review up 441%, PR size up 51.3%, and 31% more pull requests merging without review. This is vendor telemetry, so treat the exact numbers as directional rather than universal.

Stack Overflow's 2025 survey of 49,009 respondents shows the same problem from another angle. 66% reported frustration with AI output described as "almost right, but not quite." 45% said debugging AI-generated code took longer than writing the code themselves. Trust in AI accuracy fell to 29%, from roughly 43% the year before.

What to change. Measure PR review time, PR size, rework, and edited-after-acceptance rate alongside generated-code acceptance. Keep PRs small. AI makes producing another 500 lines cheap. That does not make reviewing 500 lines cheap.

5. Generated code needs an independent auditor

Generated code often looks convincing long before it is correct.

A peer-reviewed study of 733 AI-generated snippets found weaknesses in 29.5% of Python samples and 24.2% of JavaScript samples across 43 CWE categories. Common findings included insufficiently random values, code injection, and cross-site scripting.

Once static-analysis findings were fed back to the model, it repaired up to 55.5% of issues.

Those two findings describe a useful engineering pattern.

Do not ask the generator to prove its own output is safe. Use a deterministic tool to find the issue. Then use the model to help repair it. Then run the deterministic tool again.

The scanner owns detection. The model helps with remediation.

What to change. Build loops such as scanner-to-AI remediation-to-scanner. Static analysis, SAST, dependency scanning, secret scanning, schema validation, type checking, and tests stay authoritative.

6. AI-generated tests often repeat the same mistake

Testing has a similar circularity problem. Suppose a requirement contains an unstated assumption. The model writes the implementation based on that assumption. Then you ask the same model to generate tests from the implementation.

What does the model learn from? The implementation. So the tests encode the same assumption.

Coverage does not expose this problem. You might have 95% coverage and still be testing the wrong behavior with impressive precision.

If tests come from the implementation, they are useful regression tests. If tests come independently from requirements, API contracts, invariants, examples, and acceptance criteria, they also challenge the implementation.

What to change. Generate or write the first specification tests before implementation enters the model context. Keep implementation-derived tests separate conceptually. For high-value logic, add mutation testing to check whether the suite notices meaningful behavioral changes.

7. AI inside CI changes what reproducible means

Traditional build controls have a useful property. The same commit, configuration, and toolchain should produce the same decision.

Model output does not provide the same guarantee. Temperature zero reduces variation. It does not turn an external model into a deterministic compiler.

This becomes more than an engineering inconvenience in regulated environments.

An auditor asks a simple question:

Why did the same commit pass in March and fail in April?

If the answer is "the model returned a different judgment," you need enough evidence to reconstruct what happened.

What to change. Keep model output advisory by default. Let deterministic controls own build failure. When an AI-based control needs blocking authority, record the model version, prompt template version, retrieved context, configuration, and raw output.