Responsible AI-Assisted Development: Maintaining Code Quality with LLM Tools

Mathematical Mediocrity

LLMs predict the next token based on probability distributions from training data, producing outputs that reflect the most statistically likely patterns rather than optimal designs. This causes them to generate code that looks like the statistical average of what they have seen, gravitating toward common approaches rather than elegant or maintainable solutions (Atomic Object, 2025).[4]

Training Data Quality

The sheer volume of average and mediocre code in training data dominates the signal, creating a regression toward the mean. For every well-designed class following SOLID principles, there are hundreds of examples violating them (Atomic Object, 2025).[4]

The Innovation Gap

AI tools cannot innovate beyond their training data. They manipulate statistical patterns but lack genuine understanding or the ability to challenge fundamental assumptions. True innovation requires questioning existing approaches and imagining entirely new solutions: an LLM trained only on pre-OOP code could never have invented object-oriented programming because it would only reproduce existing patterns. This explains why AI cannot recognize when conventional approaches are flawed and lacks genuine understanding of design patterns (Atomic Object, 2025).[4]

SOLID Principle Violations

Research shows LLMs consistently generate code that violates SOLID principles:

• Single Responsibility Principle (SRP): AI tools frequently generate classes that handle multiple unrelated responsibilities (Pehlivan et al., 2025).[3]

• Dependency Inversion Principle (DIP): AI consistently creates concrete dependencies instead of relying on abstractions, with some models achieving only 10.8% accuracy in detecting DIP violations (Pehlivan et al., 2025).[3] A 240-example benchmark across CodeLlama, DeepSeekCoder, QwenCoder, and GPT-4o Mini shows prompt strategy drives large swings in accuracy, with even top models still struggling on DIP.[3]

• Open/Closed & Extensibility: AI-generated code often violates the Open/Closed Principle by creating rigid structures that are hard to extend without modification. Developers must actively refactor AI output to ensure code can be extended without modifying existing logic.[2]

• Refactoring Discipline: brgr.one stresses scheduling refactors of AI-generated classes to split overloaded responsibilities, replace concrete dependencies with abstractions, and add tests that enforce interface segregation before merging.[2]

Procedural vs. Functional Programming

In my experience, AI tools tend to generate more procedural-style code rather than functional programming approaches. Functional programming, with its emphasis on immutability and pure functions, requires explicit guidance and refactoring.

Work in Small Increments

Generate small, focused code segments and pause after each one for a quick review. This prevents technical debt from accumulating by catching obvious issues, such as oversized classes, long methods, or poor testability, before they become integrated into the codebase. A 2025 review reveals LLM code generation gaps in ethics and maintainability, emphasizing essential human oversight as AI often overlooks architectural maintainability constraints.[9]

Demand Testability

Explicitly instruct AI that all generated code must be testable. This drives better design decisions by forcing the use of dependency injection and avoiding hardcoded dependencies or static method calls. ScienceDirect 2025 found verifying correctness remains challenging as unit tests alone often miss subtle logic errors.[10]

Enforce SOLID Principles and Cohesion

AI will not automatically produce SOLID-compliant code. You must actively enforce these principles to maintain low coupling and high cohesion.

• Replace direct dependencies with abstractions (interfaces).

• Use dependency injection patterns consistently.

• Break up monolithic classes into focused, cohesive units.

• Verify that classes depend only on abstractions, not concrete implementations.

Prefer Functional Programming Patterns

Explicitly request functional approaches. Use immutable data structures, favor pure functions, and employ LINQ and functional pipelines.

Keep Methods Small and Focused

Break AI-generated "God methods" into focused, single-purpose functions, aiming for methods under 10-15 lines.

Development Workflow

1. Generate: Use AI for initial code generation.

2. Review: Immediately examine the output for design issues.

3. Refactor: Transform the code to meet quality standards.

4. Test: Verify functionality and structural properties.

5. Iterate: Repeat in small increments.

6. Govern Usage: MIT Sloan recommends explicit guardrails for when AI code is safe (greenfield/low-risk) versus when to avoid or slow-roll adoption (legacy-heavy/brownfield, junior-heavy teams), to prevent compounding technical debt.[1]

What AI Tools Excel At

• Generating boilerplate code and standard CRUD operations.

• Implementing well-understood algorithms.

• Explaining common programming concepts.

• Producing competent "average" solutions quickly for typical cases: useful for boilerplate but insufficient for novel architectures or breakthrough designs.[4]

What Requires Human Judgment

• Designing system architecture and component boundaries.

• Solving novel problems requiring innovative approaches.

• Evaluating tradeoffs between design alternatives.

Effective Prompting Strategies

Research shows that different prompting strategies improve output quality (Pehlivan et al., 2025):[3] deliberate ensemble prompts excel at OCP detection while hint-based example prompts improve DIP accuracy, underscoring the need to match prompt style to the design smell you are targeting.[3]

Guardrails for Trust and Transparency

• Only 24% of DORA 2024 respondents trust AI-generated code “a lot,” and many report limited transparency on how AI is applied in their toolchains; make trust and explainability explicit acceptance criteria when adopting AI in delivery pipelines.[7]

• AI usage is rising across IDEs and internal web tools, but half of teams still avoid automated AI steps in their CI/CD; pilot with clear rollback plans before expanding automation surfaces.[7]

• Direct prompts work well for SRP and ISP.

• Example-based prompts significantly improve detection of LSP and DIP violations.