Shipping with Robots: How AI Is Quietly Rewriting the SDLC

Why this matters this week

AI in software engineering has moved from “cool demo” to “this is affecting my sprint velocity and incident rate.”

In the last few months, across multiple orgs, we’re seeing:

• Test suites written or refactored by AI that materially reduce regression bugs.
• Codegen tools that can scaffold full features, not just autocomplete the next line.
• SDLC changes where PRs are smaller, reviews are more about design than syntax, and incident reviews now include “what did the AI suggest?”
• Non-trivial production incidents that trace back to AI-generated code: silent data corruption, missing edge cases, incorrect concurrency assumptions.

If you own a production system, this is no longer optional background noise. AI is now:

• Changing the risk profile of changes that look small.
• Exposing gaps in your tests, documentation, and architecture diagrams.
• Forcing you to think about “developer productivity” as a system that includes humans plus tools, not just LOC or story points.

This is a week-1 problem, not a year-5 strategy discussion, because:

• Your devs are already using these tools, even if you haven’t blessed them.
• Vendor defaults (telemetry, code upload, model choice) often conflict with your security and compliance expectations.
• The teams that are getting real value are doing unglamorous, boring work: tightening SDLC controls and clarifying where AI is allowed to act autonomously.

What’s actually changed (not the press release)

Ignoring vendor spin, the practical shifts for engineering teams are:

1. LLMs are now “competent juniors,” not autocomplete toys.

   • They can write small services, non-trivial tests, and migration scripts that compile and often work.
   • They still hallucinate APIs and mis-handle edge cases, especially around distributed systems, concurrency, and security.

2. Context windows are big enough to take in real artifacts.

   • You can stuff a full file or several related files, plus a failing test, into the prompt.
   • This makes AI-assisted refactors and test generation actually usable, not just per-function crutches.

3. IDE integration is good enough to stay out of your way.

   • Latency is down; suggestions arrive fast enough not to break flow.
   • This shifts the challenge from “will devs adopt?” to “how do we constrain and observe usage?”

4. Costs are non-trivial but not insane—until you scale blindly.

   • Per-developer monthly AI spend that’s comparable to a good SaaS licensing fee is normal.
   • What hurts is “chatting” with huge context windows for every minor change, or batch-processing entire repos without guardrails.

5. Security posture is uneven.

   • Some tools now support on-prem or VPC deployment and no-training modes.
   • Others still default to shipping your code to a multi-tenant service and logging aggressively.
   • Many teams don’t know which category their current tool falls into.

The net: AI is now effective enough to reshape how code is written and tested, but not reliable enough to trust unsupervised. That tension is where most SDLC changes need to happen.

How it works (simple mental model)

Use this mental model: “spec expansion + pattern retrieval + approximate synthesis.”

1. Spec expansion

   • You give: a ticket description, a few files, maybe a failing test.
   • The model tries to infer the implicit spec: coding conventions, business rules, typical patterns in the repo.
   • It’s good at this when the repo is consistent; terrible when conventions are fragmented.

2. Pattern retrieval

   • Internally, it’s doing a “nearest neighbors in training and context” move:
     • “I’ve seen similar login handlers; I’ll borrow those patterns.”
     • “This project uses repository patterns; I’ll follow that.”
   • This means you get plausible code, often using idioms from your own codebase.

3. Approximate synthesis

   • The model stitches patterns together into code or tests that look right.
   • It does not run, type-check, or prove anything.
   • It maximizes “textual plausibility,” not “semantic correctness.”

This gives a simple rule:

AI-generated code is a hypothesis, not an implementation.

Your SDLC’s job is to:
– Turn hypotheses into tested, reviewed changes.
– Make it cheap to falsify bad hypotheses (fast tests, clear contracts).
– Prevent low-friction codegen from bypassing your risk controls.

Where teams get burned (failure modes + anti-patterns)

1. AI as an unaccountable second author

Symptoms:
– PRs where 60–80% is AI-generated and the human author can’t fully explain it.
– Reduced review quality because reviewers implicitly trust “the robot must know.”

Consequences:
– Subtle logic bugs that pass happy-path tests.
– Security flaws (e.g., missing authz checks, weak input validation).

Mitigation:
– Require PR descriptions to state: “AI-assisted? Where and how?”
– Expect authors to explain non-trivial blocks in plain language during review.

---

2. Silent test rot and test overproduction

Two extremes:

a) AI generates no tests, and humans get lazier.
– “We’ll have it write tests later” becomes “we won’t.”

b) AI generates walls of brittle tests.
– Snapshot tests, mocks for everything, but no real behavior coverage.
– Tests pass but don’t protect against regressions; or they block safe refactors.

Real-world pattern:
A team let AI generate tests for a critical billing module. Code coverage went from 40% → 85%. Six weeks later, a pricing bug shipped that cost six figures. Postmortem: tests asserted current behavior (including bugs), not intended behavior; nobody had specified the invariants.

Mitigation:
– Define what “good test” means in your context: invariants > lines covered.
– Use AI to:
– Propose test cases given a spec.
– Port or refactor existing tests.
– Generate property-based tests around clearly stated invariants.
– Don’t let it define the invariants.

---

3. SDLC steps quietly bypassed

Common anti-patterns:
– AI writes infra code (Terraform, Helm) that gets applied “because it looks right.”
– Data migration scripts run in staging and then production with minimal review.

Example:
A data team used AI to write a one-off migration script. It worked in staging (small dataset), but had an O(n²) query pattern that locked tables in production. Incident lasted 90 minutes.

Mitigation:
– Treat AI-generated infra/migrations as high-risk changes:
– Mandatory second human reviewer.
– Dry-runs with metrics (query plan inspection, timing on representative data).
– Add a checklist item: “Which parts were AI-generated? Any performance or data-risk hotspots?”

---

4. Context poisoning

With larger context windows and repository indexing, models happily ingest:

• Outdated docs.
• Deprecated functions that still exist.
• Temporary hacks in feature flags.

Result:
– New code uses deprecated APIs, copies “TODO: security” patterns, or extends hacks.

Mitigation:
– Maintain machine-facing documentation:
– A high-level “architecture + invariants” doc kept current.
– Clear deprecation warnings in code comments: @deprecated DO NOT USE – see X.
– Clean up obviously-dead code; it’s now a risk multiplier, not just clutter.

---

5. Cheap code, expensive maintenance

AI accelerates “just paste more code” behavior:

• More one-off helpers.
• More configuration by code instead of by data.
• More micro-variations of the same pattern.

This inflates:
– Cognitive load for new joiners.
– Merge conflicts and refactor cost.
– Bug surface area.

Mitigation:
– Promote AI for refactors and deletions, not just additions:
– “Convert these 10 ad-hoc validators to a single schema-based validator.”
– “Inline and remove unused wrappers.”
– Track: ratio of lines removed to lines added in AI-assisted work.

Practical playbook (what to do in the next 7 days)

Assuming you’re a tech lead / manager / architect with real production responsibilities:

1. Decide your AI-in-SDLC policy, however minimal

Write a one-page, pragmatic policy and share it.

Include:

• Where AI is allowed:
  • Prototyping, test suggestion, documentation, boilerplate, non-critical scripts.
• Where AI needs extra scrutiny:
  • Security-sensitive code, auth flows, crypto, payments, data migrations, infra, PII-handling pipelines.
• Where AI is not allowed (for now):
  • Regulatory reporting logic, safety-critical calculations, formal security controls.

Clarity beats perfection. You can adjust later.

---

2. Instrument usage and costs

You can’t manage what you don’t see.

• If using vendor tools:
  • Turn on org-level usage reports.
  • Group by project/team.
• If self-hosting:
  • Log requests by user, project, and approximate token usage.

Look for:
– Outliers (one person 10x others).
– Projects with heavy AI use but flat or worsening defect rates.

---

3. Add two small but high-leverage review rules

Augment your PR template with:

1. “Did AI assist this change? If so, where?” (free-text)
2. “What behavior/invariants do the tests assert?” (not “what files are covered?”)

Train reviewers to:
– Skeptically inspect AI-heavy diffs, especially where logic is indirect or branched.
– Ask authors to walk through critical paths in plain language.

---

4. Run one targeted experiment on tests

Pick a medium-critical service (not payments, not a toy).

Do a 2–3 day spike:

• Task: “Improve regression protection for X module.”
• Let the team:
  • Use AI to propose additional test cases from existing code + requirements.
  • Add tests only where they can clearly state the invariant.
• Measure:
  • Lines of new tests.
  • New invariants captured.
  • Flaky tests introduced (if any).
  • Developer sentiment: “did this help you catch real issues?”

Decide: expand, refine, or roll back.

---

5. Create one “machine-consumable” architecture doc

In a README or architecture.md at the repo root:

• Summarize:
  • Core domains and bounded contexts.
  • Key invariants (e.g., “user balance must never be negative”).
  • Deprecations: “Do NOT use modules A, B; use C.”
• Make it concise enough to be pasted wholesale into a prompt.

This doc becomes the ground truth you (and the model) can