"Last year, with the help of AI, we built an internal tool to manage orders ourselves. We were thrilled at the time. But six months later, when we try to make minor adjustments, the internals are so convoluted that even the person who created it can no longer follow it." This was a consultation we recently received from the executive of a small-to-medium enterprise.
Generative AI has ushered in an era where tools that once required external outsourcing can now be built internally. That in itself is wonderful. The issue arrives six months later. The code runs, but no one can touch it to make fixes. No one knows where bugs originate. This state of "we built it, but we cannot maintain or evolve it" is the fastest-growing issue we are asked to consult on. In this article, we explain why code largely written by AI rots, and what custom development partners rebuild when taking over.
What rots is always the "added extras"
What we experience firsthand in the field is that when AI-generated code deteriorates, what breaks is inevitably the unnecessary code that was added on. An article summarizing this topic based on six months of operational experience recently gained attention among engineers, and the rotten code patterns highlighted there closely match what we see when taking over projects in custom development.
- Vast amounts of zero-value comments that simply rephrase the code in Japanese
- Premature abstractions used in only two places, making the code harder to follow later on
- Single functions ballooning to hundreds of lines, leaving everyone clueless about what is happening where
- Errors getting swallowed silently, returning incorrect results without raising alarms when problems arise
What these have in common is that they were unnecessary for running the application, but the AI politely added them anyway. Conversely, what remained effective after six months were the parts where humans maintained ownership of specifications and tests rather than the raw implementation. This provides a clue on how to handle AI-generated code properly.
Why it rots: AI takes the shortest path to satisfy "it works right now"
The AI is not at fault. AI fulfills the immediate requirement of "making this feature work right now" with astonishing precision. However, maintainability six months down the road and ease of extensibility when business requirements change are not included in that immediate prompt.
Consequently, if prompted, AI will gladly abstract code, add verbose comments, and swallow errors for the time being to create a working format via the shortest path. Each choice comes from helpful intent, but without a human to exercise judgment and filter them out, that goodwill accumulates into technical debt. The decision-making framework for adopting AI refactoring suggestions is covered in our article on AI refactoring decisions, while reviewing and managing code generated at scale by AI is detailed in our article on AI agent code management.
Drawing the line between in-house and custom development: Build in-house, but evaluate maintaining long-term
What clients want to know most here is probably: "Does this mean we should outsource everything to professionals again?" In most cases, the answer is no.
Being able to build in-house with AI is a powerful asset that you do not need to abandon. The line should be drawn by treating "building" and "retaining long-term" as separate considerations. Building and testing small operational tools quickly on your own is well-suited for internal teams. On the other hand, systems that support core operations, cannot afford downtime, and must be maintained over the long run require an engineering structure capable of sustaining specifications, tests, and maintenance architecture. Rather than carrying that solely in-house, a practical approach is to engage custom development partners not merely as builders, but as rehabilitators and ongoing advisors. The prior decision of when to convert Excel and GAS workflows into formal systems is discussed in our article on when to systemize Excel and GAS operations. This article takes that a step further, addressing what comes after you have already accumulated AI-written code. For a management perspective on assessing technical debt as business risk, please also see our article on evaluating technical debt when commissioning projects.
Case study: A company that asked for a rewrite quote but resolved it with a rebuild
Here is a specific example (company name withheld). A company came to us for a quote to rewrite their AI-built inventory management tool from scratch after it became unmanageable within six months.
Looking at the code, the functionality itself matched their business requirements. What had rotted were the aforementioned added extras: excessive abstractions and swallowed error handling. Rather than proposing a full rewrite, we first analyzed what the tool was supposed to do and documented its specifications, established tests around fragile areas, and systematically refactored only the decayed parts. Both cost and timeline were kept drastically lower than a full rewrite, preserving the assets built in-house. What worked was not writing brand-new code, but reclaiming what the tool does in human language.
What clients can prepare before handing over a project
Finally, there is something you can do even before reaching out for consultation. Even for tools built with AI, document in simple terms what the tool is intended to do, and what outputs it should return for given inputs. Having just this dramatically accelerates the initial recovery speed for a custom development partner. Conversely, if this context is lost, the partner must start by inferring specifications from running code, which consumes the most time.
If your AI-built internal tools have become impossible to modify after six months, you cannot tell whether to rewrite or rebuild them, or you are unsure where in-house development should end and outsourcing should begin, please feel free to reach out through GleamHub's development, AI, and automation consultation. From interpreting existing tool specifications to rehabilitating decayed components and designing division of roles between internal teams and custom development, we will partner with you within a reasonable scope.
Sources
- Checking in after 6 months of running code 80% written by AI: 3 things that worked and 3 things that rotted - Zenn
- 5 things that actually rotted in AI-written code: Anti-patterns found after 6 months in production and how to fix them - Qiita
- Why development slowed down even though code can be written faster: Facing "comprehension debt" in the AI era - Zenn
