As AI Writes More Code, Why We Still Need to Understand It

I used AI to build a product that helps people understand code.

But something interesting happened: as the product grew more complex, I began to understand less and less of it myself.

I started building FiboCode around July 2025. Vibe Coding was taking off at the time, and everyone was talking about using AI to help people write code and lower the cost of software development. One thought came naturally to me:

If AI can help people write code, could it also help them understand code?

The cost of writing code keeps falling, but understanding an unfamiliar project is still painful. This is especially true when facing a codebase that has existed for years, with a complex directory structure, module dependencies, historical design decisions, and all kinds of conventions. Often, simply figuring out where to begin takes a long time.

FiboCode began with that simple idea: use AI to analyze code and generate corresponding documents and relationship diagrams, then make it possible to jump among the code, documents, and diagrams.

At that point, it was only a code analysis tool.

Later, to make it easier to ask questions about the code, I added a simple Agent. To improve the code-reading experience, I integrated Monaco Editor. Once there was an editor, code navigation, symbol references, and language diagnostics seemed necessary too, so I added LSP support.

Once reading was supported, editing was the natural next step.

After FiboCode could modify code, I began thinking about how to help the Agent truly understand a project instead of judging it from only the few files currently open. Gradually, I added MCP and Skills, hoping to give AI access to the project's design conventions, architectural context, and history as well.

Later, I realized that many developers were already comfortable with Agent CLI tools such as Claude and Codex. They might not need another built-in Agent. What they might need more was an interface designed for reviewing the results of an Agent's work.

So FiboCode added a terminal and made specific improvements for Agent CLI output, allowing file references, code changes, and execution steps in the terminal to connect with the code, documents, and relationship diagrams.

In this way, a simple code analysis module grew, piece by piece, into an increasingly complex system.

I Started Forgetting the Project I Had Built

AI-assisted programming is genuinely convenient.

Although the early models were not as capable as they are today, I carefully reviewed the code they generated, often several times. I looked at how modules were divided, how data flowed, and why the architecture had been designed that way.

The project went through many refactorings during development. Some were extensive, but because I was familiar with the design details at the time, none of them ultimately broke the project.

Then the models became more capable, the speed of code generation increased, and the codebase began to grow rapidly.

I gradually noticed that I could no longer remember the design details of code I had reviewed only a week or two earlier.

At first, that frightened me a little.

This was my own project. Every feature in it had come from me, yet I could no longer remember why every module had been designed as it was or how every piece of logic worked.

Over time, I realized that this might simply be something I had to accept.

It was no longer the small project it had been at the beginning. In a sufficiently complex system, no one can remember every implementation detail. What truly matters may not be keeping every line of code in your head, but knowing where the core of the system lies, how the modules collaborate, which parts can safely be entrusted to AI, and which parts must be understood carefully.

I needed to learn how to choose.

I had to find the critical paths through the mass of code, build a broad mental picture of the system, and then give AI more precise requirements and constraints.

Seen from this perspective, FiboCode was also helping me build FiboCode.

I used AI to develop the product; the product became increasingly useful; and in turn it helped me understand and iterate on itself more quickly. That positive feedback loop was genuinely exhilarating, and it was an important reason I had kept working on it for so long.

But beyond the excitement, I often found myself asking:

What was left for me in this development process?

When I Handed More and More of My Thinking to AI

Over a long period, I gradually developed a habit.

Whenever there was a requirement, I gave it to AI first.

Whenever there was a problem, I asked AI to investigate first.

After it proposed a solution, I verified it. If the verification failed, I sent the result back and asked it to analyze and fix the issue again.

Sometimes an entire day passed while I repeatedly described requirements to AI, explained the current state of a bug, and then fed the test results back to it.

It seemed that AI was performing almost all the difficult intellectual work, while my role had been reduced to defining requirements and returning results.

During that period, I genuinely had a powerful feeling:

It seemed that I no longer had much value.

But as I kept going, I discovered that this was not quite true.

While developing with AI, I encountered many technologies I would not previously have chosen to study and saw a wide range of implementation approaches. I began deliberately looking at design and architecture before examining the concrete implementation.

For some tasks, I could quickly tell that the scope was small and that AI could complete them directly.

But when a task crossed multiple modules or affected the project's core structure, I immediately knew it was not that simple. AI might see only the current requirement without understanding why a historical design existed, and it might not know which areas the change would affect indirectly.

There was also code that I needed to understand almost completely even if AI could write it, because if something went wrong there, the consequences could be difficult to control.

I stopped insisting on understanding every implementation detail, but I became more sensitive to the system's boundaries, dependencies, risks, and changes.

Perhaps human work has not disappeared. It is simply changing.

In the past, we understood a system by implementing its code ourselves.

In the future, we may spend less effort on repetitive implementation and direct more attention toward architecture, process, constraints, verification, and long-term evolution.

Just Because AI Can Write It Does Not Mean We Can Trust It

I do not know whether AI will truly be able to replace human experts and perform all programming work in the future.

That is certainly a technical question, but I believe it is also a question of trust.

Even if AI can one day generate a highly complex system independently, that does not mean we will be willing to trust it without reservation.

When the system behaves unexpectedly, will we know why?

Will we be able to locate the error?

Will we be able to verify the fix?

Will someone else be able to take over?

If the system causes serious harm, who should be responsible?

These questions cannot be completely resolved simply by improving model accuracy from 99% to 99.9%.

For low-risk applications that are easy to replace, we can of course tolerate more of a black box. If the functionality works and development is fast enough, perhaps we do not need to care about every implementation detail.

But for foundational software such as operating systems and databases, or systems in finance, electricity, and other fields that have a major impact on society, it is difficult to accept a black box that cannot be understood, audited, or taken over.

These systems still need people to maintain them.

Those people do not necessarily need to write every line themselves, but someone must know roughly how the system works, where the critical risks are, and where to begin investigating when something goes wrong.

That is why I increasingly believe that code understanding will not disappear with the rise of AI programming.

It will simply take another form.

In the past, we needed to understand code in order to write it.

In the future, we may need to understand code in order to verify, maintain, take over, and continue evolving systems built by AI.

The Entry-Level Tasks That Are Disappearing

Code understanding has another kind of significance.

AI is reducing some entry-level roles centered on repetitive implementation and basic tasks. Even when the jobs themselves do not disappear, much of the work once assigned to newcomers is now being automated by AI first.

This is not friendly to newcomers.

The traditional path of growth for an engineer usually begins with simple tasks: fix a bug, read a small section of code, complete a small feature, and then gradually participate in more complex modules and system design.

Newcomers build their understanding of real projects, little by little, through these tasks that may appear unimportant.

But now AI may complete those foundational tasks directly.

When fewer entry points remain for training newcomers, where will the senior engineers of the future come from?

This was another reason I created FiboCode.

I am also new to the profession. The first time I faced a complex legacy codebase, I often felt completely at a loss.

There were so many files and directories. Services called one another, while types, interfaces, and configuration were scattered across different places. You knew the answer had to be somewhere in the code, but you did not know where to start, which parts mattered, or which were merely implementation details.

Often, the real difficulty was not understanding a particular line of code. It was the absence of a complete map.

I always wanted a tool that could first analyze the structure of an entire project and tell me where its core modules were, how the code was connected, and what areas a change might affect.

Then newcomers would not have to depend entirely on someone guiding them step by step, nor would they have to repeatedly feel their way through unfamiliar codebases.

Such a tool cannot replace the process of growth, but it can lower the barrier to entering a complex system.

As AI gradually cuts off the old path of growth, I hope FiboCode can reconnect a route.

Not necessarily a shortcut that skips every foundation, but something more like a map, a navigation system, and a path that helps newcomers build a mental model of the system more quickly.

Code Records Only the Present

During development, I discovered another problem.

Giving a task directly to AI and letting it explore the repository on its own can sometimes lead to incomplete thinking.

AI can see the current code, but it may not know why a module was designed in a certain way. It may also be unaware that the code is indirectly connected to other files that appear unrelated.

Code can usually tell us what a system looks like now, but it struggles to explain why the system became this way.

At first, I considered putting all of this information into code comments.

Later, I decided that was not a good fit.

Large amounts of design context, historical reasoning, and change explanations would make code files increasingly bloated and could introduce a great deal of context irrelevant to the current task for AI. Comments are suited to explaining local logic, but they cannot easily carry the full evolution of a project.

So I designed a series of Fibo Skills.

They record the project's conventions, designs, implementation process, and explanations of diffs, leaving a more complete trace of each code change.

I hope that when AI modifies code in the future, it will see not only the project's current state, but also understand what happened in the past and why certain designs were preserved.

When the history of a project's evolution becomes traceable, AI can understand the project more completely.

This also became one of the directions FiboCode gradually took:

It was originally designed to help people understand code. Later, it also began helping AI understand code better.

How FiboCode Grew Into What It Is

Looking back, FiboCode was not designed from the beginning to be what it is today.

It started as a simple code analysis module. Later came documents and relationship diagrams, an Agent, an editor, and language services. Gradually, it also gained code editing, a terminal, MCP, and Skills.

I wanted it to give Agent CLI tools a Cursor-like code review experience, while also turning the documents and relationship information produced by code analysis into context that AI could actually use.

It evolved from a simple module into a complex system, and that process of continual growth quietly echoed the way the Fibonacci sequence expands.

That is also where the name FiboCode and the snail image came from.

The snail's shell holds the mathematical beauty of the golden spiral.

It does not move very quickly, but it keeps growing forward.

FiboCode is not trying to make people write every line of code by hand again, nor is it trying to shut AI out.

Quite the opposite. It accepts that AI will write more and more code, and on that premise, it hopes to help people continue to understand, verify, maintain, and take over their own systems.

In an age when everyone is pursuing faster generation, I still hope that we can occasionally slow down.

To understand why code runs the way it does, and why a system became what it is today.

And to rediscover the joy that first drew us to programming.