Redundancy and maintainability of the AI-generated code

Maintainability and redundancy of unmanaged AI generation can suffer over time.

This article was written in September 2026, and can become outdated

Introduction

AI introduced a revolution to software development, changing the way that we (developers) write code. Although most people can agree over this statement, the further I personally go, the more prone I’m to tell that most of this code fails on the matter of maintainability, redundancy and design at the repository or class level scope of work. This implies that most of the code produced by the AI falls in the bigger picture and causes loss of details.

Real example

The below chart shows the syvat.io application’s activity storing, assisted coding left more-unassisted than it should be.

At the first glance everything looks in-place, but the more we look, the more problems start to appear from the graph perspective. Redundant check if the current state is longer than 3 sec - this part can be removed completely as it increases code complexity without explanation. The database reads - even if we retrieved current activity and state and stored it in memory, the next call with the same activity repeats the cycle, so there is no difference between new state and existing state.

Checking the code doesn’t provide any improvement in this case. Parts of the poller code are stored in functions related to data access. State manager logic is scattered between multiple files (data access, poller logic, even sidecar communication). These examples are the tip of the iceberg that already failed the very first letter of SOLID principles.

SOLID

Not going into other letters of this principle, currently generated code fails the Single responsibility. The data access, poller, state managing and sidecar implementation shows typical example of high coupling. High coupling will make potential implementation of a new feature or fixing longer (it means we’re paying in time for every change made there), or more expensive (if we calculate in tokens for a AI). This also shows low cohesion, which unnecessarily increases cognitive work to navigate through logic scattered between multiple files (again, time). I don’t want to sound like an eager clean-code follower, but it’s not a small helper function(s) for a new functionality that will be refactored soon, as business agrees on a common stable vision.

Refactor

Before modifying any logic, the code must be sorted to the right files to lower a cognitive load when navigating. Then I would rather go and try to simplify paths, rename variables and functions before proceeding. Lastly, introducing DTOs and splitting logic will be required to sort-out the rest.
Skipping sorting out and standardizing will [increase mental workload, and decrease performance]

Models

Something that should be clarified earlier, current code was written using frontier models - not old GPT 4, Qwen 2, Claude 3 and so on… This code is being generated by newest models like Opus (4.8, 5), GPT (5.5, 5.6 Sol), causing to suspect that for each improvement on the matter of problem-solving on math-benchmarks (Frontier Math: Tiers 1-4), every one of them fails on the matter of bigger picture (Frontier Math: Open Problems (1/18 solved - 26/08/2026)).

Summary

Even if AI brought a revolution to software development and increased the performance, unmanaged and not fully planned code generation can increase pricing (if AI), and/or amount of work (cognitive and time) to avoid losing details and introducing more bugs.