When AI does the work but the team doesn’t: practical fixes for dependency-driven technical debt

Dependency on AI assistance creates concrete technical, security and compliance harms. A sociotechnical approach treats these as design failures and gives practical steps—provenance, validation, training and governance—to prevent accumulated debt.

Why dependency is more than a feeling

When developers begin to trust AI suggestions without tracing them back to concepts or evidence, the effects are not merely personal: they show up as defects, security holes, and maintenance costs. The original article framed this as a sociotechnical failure: the tool is doing work, but the social system hasn’t updated practices, responsibilities and training to match that capability. That gap produces a particular kind of harm — quiet, incremental and expensive to reverse.

What actually breaks — concrete failure modes

  • Subtle logical errors accumulate. AI outputs can be plausible but incorrect; if humans no longer know the underlying concepts, they won’t spot those errors and the codebase becomes technical debt.
  • Loss of provenance means weak audits. Without provenance or clear authorship, it’s hard to show why a decision was made, who validated it, or how to remediate it for compliance.
  • Security and maintainability regress. Accepting outputs wholesale increases attack surface and hides assumptions (credential handling, input validation, edge cases) that later become costly to fix.
  • Organisational responsibility blurs. Tool-driven outputs shift work but not roles; the social accountability that once sat with an author or reviewer can evaporate.

A sociotechnical lens: why this is a design problem

Literature on dependency and care work reminds us that “dependency” is not a neutral label — it is contested and negotiated in practice. In other domains, researchers have observed that dependency carries negative connotations and requires practical responses from teams who do the caring and maintenance work (see research on dependency in support work). Translating that to software: the presence of an AI assistant changes who does what, but teams often don’t deliberately redesign roles, training or validation practices to match.1

Practical guidance: design the social system around the tool

Below are concrete, practitioner-friendly steps you can introduce this week or iterate into your development lifecycle.

  • Provenance by default. Require clear annotation of AI-suggested code: where it came from, relevant prompts, and why it was accepted or modified. Put this into commit messages or PR templates so it becomes part of the audit trail.
  • Gate with tests and property checks. Don’t accept suggestions without automated tests that exercise the assumptions. Use unit, integration and property-based tests to catch semantic slips that appear correct at first glance.
  • Enforce human review responsibilities. Make the reviewer role explicit: what conceptual checks are expected, who signs off for security-sensitive changes, and when to escalate. Don’t let “the model said so” become a review argument.
  • Classify risk and set different rules. Not all AI outputs are equal. Establish simple tiers (eg: documentation snippets, UI copy, core business logic, auth/security) and apply stricter validation for higher-risk tiers.
  • Rotate learning and apprenticeship. Use pair programming, rotation and mentoring so that junior staff are exposed to concepts rather than only watching suggestions appear. That prevents skills atrophy and spreads institutional knowledge.
  • Instrument and monitor. Track metrics that matter: post-deploy defects correlated to AI-suggested commits, mean time to remediation, and the volume of AI-originated code in critical modules. Data helps you see whether dependency is growing.
  • Design the tool-channel interface. Prefer tools that provide confidence scores, citations or traceable context. If you run an internal model, add logging of prompts and responses for later inspection.
  • Adopt a blame-free learning culture. Shame and avoidance can hide problems. Research on shame-sensitive practice emphasises that punitive responses make people withdraw; instead, encourage reporting, postmortems and guided skill development so errors become learning moments, not cover-ups.4

Leadership and governance

Governance is not about policing everyone; it is about defining stewardship. Set clear policies for when AI outputs are allowed without additional scrutiny and when they must be reworked. Assign ownership for compliance, security and maintainability audits. Make training explicit — pride in craftsmanship can be supported via career-development paths that reward deep understanding, not only throughput.

Quick checklist to reduce dependency-driven harm

  • Require AI provenance in PRs.
  • Enforce test coverage for accepted suggestions.
  • Classify modules by risk and apply stricter rules where needed.
  • Rotate and pair more to preserve tacit knowledge.
  • Measure AI-originated defects and act on trends.
  • Create non-punitive learning rituals for mistakes.

Expanded from

This post expands on a point from Copilot or autopilot? When AI assistance becomes dependency — and whether that matters.

Sources