Introduction
Code doesn’t just encode logic that makes features work. Even if you ignore repo history and comments, code carries the structural thinking of earlier developers: it proposes the direction of future changes and governs the long-term stability of a solution, service, or project. It evolves through trial and error over time, adapting to its environment and requirements.
Modern AIs are said to handle on the order of 75,000–110,000 lines of code at once [1]. Yet the problems known since the early days of AI-assisted coding persist. This post explores the causes of those issues and suggests how developers can progress in response.
Purpose of this piece
This essay reflects the state of AI as of 2025-08-16. It is not written to bash AI coding. It’s aimed at junior engineers—those just starting to learn or newly on the job—who will pair with AI and run into certain problems. The goal is to help you recognize the causes and point toward better approaches.
There are already countless benchmarks, but this is not about leaderboard rankings. It focuses on how we can change our structural thinking.
The “missing context” problem: AI deletes necessary code
Human memory has limits; no one can remember every line in a project. So we create units—functions, classes, modules (DLLs), services—and abstract their purposes and behaviors. While working, we keep the logic closest to the task active in our minds and leave the rest at a higher level of abstraction. That distilled structure is stored again, and repeating this cycle becomes a practical method of incremental improvement.
In contrast, today’s top coding AIs—Claude Code among them—often reach goals by repeating countless trials. Yes, there are MCP+RAG-style techniques that raise the level of contextual reference beyond brute force, but significant efficiency issues continue to be reported [2] [3]. Cursor is not free from context loss either [4], and conventional chat AIs fare worse [5] [6]. In short, they are excellent at producing partial code, but they struggle to control projects as a whole.
How our own code production triggers AI’s context loss
“Didn’t you just prompt it wrong?”
That’s the sentence you hear all the time when coding with AI. As noted, code is not merely a storage format for execution logic. There are already attempts to transmit context through code itself; a representative example is using TDD as a way to steer AI by embedding intent in tests [7]. At minimum, this is strong evidence that current AIs do read input code as a kind of context, not just the prompt.
Unfortunately, at this point AI still doesn’t readily produce code that’s easy to understand structurally. Below is code written 100% by GPT-4o, and GPT-5 likewise fails to spot the structural issues—an illustrative case:
if (g.mode === 'TURN') {
broadcastTurn(roomId);
startTurnTimer(roomId);
} else {
io.to(roomId).emit("timer:reset", { remaining: 0 });
}
See the repository for details; the tags to compare are before_refact and after_refact. The former is a simple, goal-driven style; the latter introduces explicit room-level object separation and mode-specific handlers in the game. I asked GPT-5 to add a new “Team Turn” mode against each version to compare the outcomes.
With before_refact, “Team Turn” conditionals got scattered across many places, and subsequent requirements easily broke the behavior of other modes. With after_refact, the model respected the existing inheritance structure, added a derived class, and subsequent changes didn’t so easily destabilize other modes.
(These are demonstration artifacts to show structural contrast. The after_refact code is also AI-generated and is not “ideal.” Use it only to understand how structure changes outcomes.)
Structure and context control
Ask an AI why you need a dynamic module-loading architecture and it will give a crisp answer. Ironically, unless you explicitly require a clear dynamic loading structure, you often won’t get what you wanted. Of course, we don’t and can’t command AI to the letter every time—so many structural pieces end up missing.
The most important factor is a developer’s ability to judge suitable structures for the environment and requirements. Well-structured code reduces the AI’s mistakes and prevents it from veering off into the wrong direction. With AI’s advances, even non-developers can now crank out tens of thousands of lines of low-level code per day. Going forward, developers will be evaluated by the amount and quality of high-level code they can produce.
As output grows, the unit of control must rise too: developers who used to control at the function/class level will move to modules; those at the module level will move to services; and those at the service level will gain time to think at the architectural level. Those with the knowledge to control broader and deeper scopes will be valued more highly.
Conclusion
At this moment, AI already exceeds humans in fragments, but in structure and design thinking it’s not far from a newcomer who just learned to code. It focuses on short-term goals, collapses its own output, or piles on structures that ignore original intent.
Code without structural intent is a trap for both AI and humans. This piece is an attempt to plant a seed that helps avoid those mistakes. In the end, when logic keeps changing, it’s the developer’s job to keep the project from losing its way.