Using Qoder's Repo Wiki and Skills to turn a legacy project from "afraid to touch" into self-iterating.
Hi everyone! I'm Yue Yangbo, a backend development engineer. I'm glad to have the chance to explore with you: "How to use Vibe Coding for programming on legacy projects."
Qoder's Repo Wiki helps us quickly understand the project architecture, map out the call relationships, and generate detailed documentation. At the same time, it can also help the team onboard new colleagues.
In the past, onboarding a new colleague involved a fairly heavy mentoring process, and that process consumed time on both sides. Typically, I would first walk them through the project, give an overall introduction, and help them build a basic understanding; then they would read the code and docs on their own. Even that wasn't enough—afterward they would repeatedly come back to me to communicate, confirm, and ask questions. Only after several rounds could they reach a relatively deep understanding of the project.
After using Repo Wiki, this changed. Because the system had already organized the project into fairly complete documentation, a new colleague no longer starts by finding a person—they start by "asking the project" in Ask mode. Most questions are actually resolved at this stage, covering roughly 80%. By the time they come to talk to me, they bring the remaining 20%—the more critical, more targeted questions. This way, the learning path shifts from "person mentoring person" to "self-service first, then deep discussion." New colleagues get up to speed faster, and the time both sides invest drops noticeably.
Even though I had gained some understanding of the project, the problem of writing code wasn't solved by that alone. At first, my approach was very direct—I asked the AI to implement specific features.
The AI could quickly output large amounts of code snippets, but when actually run, quite a few bugs and deviations showed up. So I kept adding clarifications, describing and correcting the problem a second, third, or even more times.
However, things didn't move toward what I expected—instead they gradually spun out of control: the code became messier with repeated changes, and the logic got harder and harder to keep in check. In the end, I even reached a state of "not daring to change it anymore."
I looked at the problem from a different angle: if I treated the AI as a colleague, could they really do the job well given descriptions like these? Today's AI is already very capable—in a sense, it can indeed be treated as a "newly onboarded colleague." But the question is: faced with vague, fragmented, and constantly changing descriptions, can it really understand accurately?
Thinking this through, I gradually realized the problem might not lie entirely with the AI, but comes back to ourselves: is the information we provide clear, specific, and executable enough? Based on this insight, I began a new round of attempts.
I began to adjust the way I expressed myself—no longer just saying "what feature to build," but trying my best to explain the details clearly and specifically.
If you simply throw out a huge feature, the AI's understanding of the requirement often diverges from ours. So I started adding more constraints and background information, and even began with very small tasks, such as "add a field to a PO" or "write a simple calculation utility class."
What I want to emphasize more is this: this isn't just about completing tasks—it's about building a communication mechanism with the AI. Just like when a new colleague joins, you need to gradually learn how they work. Through these small, concrete features, I slowly figured out its "habits," while it also adapted to the way I express things. The smaller and finer the requirements are broken down, the more precise the communication, and the more controllable the final result.
Once, during an interaction with the AI, I noticed a detail: when I gave it an implementation approach, it didn't blindly follow along—instead it would point out "this approach might not be ideal," and even offer better suggestions.
I began to reflect: perhaps the issue wasn't about "making it do the work," but about "how to align with it." So I gradually shifted from "commanding" to "asking proactively." Instead of directly telling it to write code, I first describe my requirement and design ideas, for example: "I have a requirement like this, and here's my design—could you check whether it's reasonable?"
This change brought two clear benefits: on one hand, the AI can better understand your thinking and context; on the other, it can fill in details and approaches you hadn't considered. After this, I adjusted my workflow accordingly: first complete alignment through questions, then move into writing code.
Through continued use, I gradually found that if you keep piling new requirements into the same conversation without controlling context length, the AI's understanding easily drifts. Especially when the context gets very long (for example, approaching 200K), information starts to get mixed up, key points get diluted, and the AI's "judgment" clearly declines.
From practice, I lean toward keeping the context within a relatively controllable range—roughly 20%–30%—where the overall results are more stable. When the requirements themselves are many and messy, my approach is to actively break them down: split one big requirement into several small ones and handle them in separate conversation rounds. This not only effectively controls context length but also makes each step's result clearer and more controllable.
This one is actually a lesson learned after getting burned. The previous rounds of coding and review had gone smoothly, but in one later case where the description wasn't clear enough, the AI mistakenly modified code I had already adjusted. The earlier results were overwritten, and nearly a full day of work was wasted.
This made me realize that once the code is usable and has passed review, you should commit immediately. That way, even if later changes go wrong, you can quickly roll back to a stable version and avoid the waste of redoing work.
The methods above can already support us in developing most basic features. But with them comes a new problem: the code the AI generates often doesn't fully match our code style or the company's business conventions.
To address this, I tried solving it through Skills. I call this system the "Skill Universe"—here, the AI is no longer just an assistant tool, but more like an "avatar" of you. It not only understands your requirements but also gradually reuses your habits, conventions, and standards.
By building different Skills, we can distill code style, common logic, and even business constraints, so that when the AI generates code, it naturally fits the way we work—rather than starting alignment from scratch every time.
It's actually not complicated. We can directly describe our requirements in Ask mode, and at the same time tell Qoder our existing method designs, code style, and agreed-upon rules, letting it generate based on that information.
In actual use, if you find the generated result doesn't match expectations, there's no need to keep correcting it in the conversation—instead, go back to the Skill file itself and adjust the descriptions and rules within it. It's worth emphasizing that this isn't achieved in one go; it's a process of continuous optimization and ongoing iteration.
Here's a more practical example. In day-to-day business development, we've often already distilled some fixed conventions, such as: a unified exception-handling utility class, a specific way of building queries, and so on. Without constraints, during Vibe Coding the AI can generate code that "looks correct" but very likely doesn't conform to our business conventions. At that point, we can split and categorize these conventions and distill them into different Skills, used to constrain and guide the AI's generation behavior.
Next, let's look at a concrete hands-on case to see how this approach plays out in practice.
In an experiment based on a Spring Boot backend project, I focused on two pain points:
After a series of attempts, I gradually distilled a relatively stable development workflow:
Starting from requirement breakdown, I first align the requirement in Ask mode, then move into Agent mode to implement the code; afterward I do a code review, and once confirmed correct, commit promptly.
The overall flow can be summarized as: Requirement breakdown → Align in Ask mode → Modify code in Agent mode → Code review → Commit promptly.
Most people, when first encountering Vibe Coding, go through a stage where "the results aren't ideal." But the question is: can we, like large models, keep iterating on ourselves?
I've summarized a simple self-optimization mechanism:
When the result is a success, distill the effective methods, organize them into a personal knowledge base, and form reusable experience;
When the result isn't ideal, do a root-cause analysis to find the source of the problem. Looking further, the problems roughly fall into two categories:
My answer is: not necessarily.
Writing code is only part of our work, not all of it. Qoder's capabilities go far beyond that—it can also be used to write scripts, polish hit articles, and even brainstorm video scripts.
When you open up the boundaries of how you use it, you'll find it's not just a "code-writing tool," but more like a partner that can participate in thinking and collaborate on creation.
Based on this idea, I made an even more interesting attempt—letting Qoder "define itself."
I had it write lyrics, come up with a name, design a cyberpunk-style character, and even create storyboard prompts for an MV. These pieces were gradually strung together, and finally, guided by Qoder's "brain," I completed a full MV—"I Am Qoder."
One last thing I want to say to everyone: let's start using it first, then gradually grow stronger.
01 Legacy Project Problems and the Breakthrough
- A huge codebase: Our legacy project may have tens of thousands, hundreds of thousands, or even millions of lines of code—an enormous scale.
- Highly complex historical logic: Because it's a legacy project, staff turnover and requirement changes have been very frequent.
- Very high cost to understand: For a newcomer, understanding, learning, and improving the project can take days or even weeks.
Repo Wiki: Turning AI into a Mentoring "Senior"
Qoder's Repo Wiki helps us quickly understand the project architecture, map out the call relationships, and generate detailed documentation. At the same time, it can also help the team onboard new colleagues.
In the past, onboarding a new colleague involved a fairly heavy mentoring process, and that process consumed time on both sides. Typically, I would first walk them through the project, give an overall introduction, and help them build a basic understanding; then they would read the code and docs on their own. Even that wasn't enough—afterward they would repeatedly come back to me to communicate, confirm, and ask questions. Only after several rounds could they reach a relatively deep understanding of the project.
After using Repo Wiki, this changed. Because the system had already organized the project into fairly complete documentation, a new colleague no longer starts by finding a person—they start by "asking the project" in Ask mode. Most questions are actually resolved at this stage, covering roughly 80%. By the time they come to talk to me, they bring the remaining 20%—the more critical, more targeted questions. This way, the learning path shifts from "person mentoring person" to "self-service first, then deep discussion." New colleagues get up to speed faster, and the time both sides invest drops noticeably.
02 Pitfalls and Attempts
Even though I had gained some understanding of the project, the problem of writing code wasn't solved by that alone. At first, my approach was very direct—I asked the AI to implement specific features.
The AI could quickly output large amounts of code snippets, but when actually run, quite a few bugs and deviations showed up. So I kept adding clarifications, describing and correcting the problem a second, third, or even more times.
However, things didn't move toward what I expected—instead they gradually spun out of control: the code became messier with repeated changes, and the logic got harder and harder to keep in check. In the end, I even reached a state of "not daring to change it anymore."
I looked at the problem from a different angle: if I treated the AI as a colleague, could they really do the job well given descriptions like these? Today's AI is already very capable—in a sense, it can indeed be treated as a "newly onboarded colleague." But the question is: faced with vague, fragmented, and constantly changing descriptions, can it really understand accurately?
Thinking this through, I gradually realized the problem might not lie entirely with the AI, but comes back to ourselves: is the information we provide clear, specific, and executable enough? Based on this insight, I began a new round of attempts.
Attempt 1: Make Requirements Concrete
I began to adjust the way I expressed myself—no longer just saying "what feature to build," but trying my best to explain the details clearly and specifically.
If you simply throw out a huge feature, the AI's understanding of the requirement often diverges from ours. So I started adding more constraints and background information, and even began with very small tasks, such as "add a field to a PO" or "write a simple calculation utility class."
What I want to emphasize more is this: this isn't just about completing tasks—it's about building a communication mechanism with the AI. Just like when a new colleague joins, you need to gradually learn how they work. Through these small, concrete features, I slowly figured out its "habits," while it also adapted to the way I express things. The smaller and finer the requirements are broken down, the more precise the communication, and the more controllable the final result.
Attempt 2: Ask Proactively—Align First, Then Write
Once, during an interaction with the AI, I noticed a detail: when I gave it an implementation approach, it didn't blindly follow along—instead it would point out "this approach might not be ideal," and even offer better suggestions.
I began to reflect: perhaps the issue wasn't about "making it do the work," but about "how to align with it." So I gradually shifted from "commanding" to "asking proactively." Instead of directly telling it to write code, I first describe my requirement and design ideas, for example: "I have a requirement like this, and here's my design—could you check whether it's reasonable?"
This change brought two clear benefits: on one hand, the AI can better understand your thinking and context; on the other, it can fill in details and approaches you hadn't considered. After this, I adjusted my workflow accordingly: first complete alignment through questions, then move into writing code.
Attempt 3: Control the Context Length
Through continued use, I gradually found that if you keep piling new requirements into the same conversation without controlling context length, the AI's understanding easily drifts. Especially when the context gets very long (for example, approaching 200K), information starts to get mixed up, key points get diluted, and the AI's "judgment" clearly declines.
From practice, I lean toward keeping the context within a relatively controllable range—roughly 20%–30%—where the overall results are more stable. When the requirements themselves are many and messy, my approach is to actively break them down: split one big requirement into several small ones and handle them in separate conversation rounds. This not only effectively controls context length but also makes each step's result clearer and more controllable.
Attempt 4: The Minimal-Commit Principle
This one is actually a lesson learned after getting burned. The previous rounds of coding and review had gone smoothly, but in one later case where the description wasn't clear enough, the AI mistakenly modified code I had already adjusted. The earlier results were overwritten, and nearly a full day of work was wasted.
This made me realize that once the code is usable and has passed review, you should commit immediately. That way, even if later changes go wrong, you can quickly roll back to a stable version and avoid the waste of redoing work.
03 The Skill Universe: Let AI Reuse Your "Habits"
The methods above can already support us in developing most basic features. But with them comes a new problem: the code the AI generates often doesn't fully match our code style or the company's business conventions.
To address this, I tried solving it through Skills. I call this system the "Skill Universe"—here, the AI is no longer just an assistant tool, but more like an "avatar" of you. It not only understands your requirements but also gradually reuses your habits, conventions, and standards.
By building different Skills, we can distill code style, common logic, and even business constraints, so that when the AI generates code, it naturally fits the way we work—rather than starting alignment from scratch every time.
How to Build a Skill (Method and Practice)
It's actually not complicated. We can directly describe our requirements in Ask mode, and at the same time tell Qoder our existing method designs, code style, and agreed-upon rules, letting it generate based on that information.
In actual use, if you find the generated result doesn't match expectations, there's no need to keep correcting it in the conversation—instead, go back to the Skill file itself and adjust the descriptions and rules within it. It's worth emphasizing that this isn't achieved in one go; it's a process of continuous optimization and ongoing iteration.
Here's a more practical example. In day-to-day business development, we've often already distilled some fixed conventions, such as: a unified exception-handling utility class, a specific way of building queries, and so on. Without constraints, during Vibe Coding the AI can generate code that "looks correct" but very likely doesn't conform to our business conventions. At that point, we can split and categorize these conventions and distill them into different Skills, used to constrain and guide the AI's generation behavior.
Next, let's look at a concrete hands-on case to see how this approach plays out in practice.
In an experiment based on a Spring Boot backend project, I focused on two pain points:
- Exception handling: Our business definitely has its own exception utility classes.
- Query encapsulation: JPA has multiple query approaches (interface methods, native SQL, criteria building, etc.). If you let the AI write it on its own, it will use various practices that don't necessarily conform to the project's conventions.
- Without Skills: The AI wrote native SQL using JPA-defined methods and didn't use our custom Error methods. The logic was fine, but it didn't meet expectations.
- With Skills: I had pre-built a "Query Skill" and an "Exception Skill." When generating code again, both the dynamic query building and exception throwing automatically used our own business utility classes.
04 My Workflow and Self-Optimization Mechanism
After a series of attempts, I gradually distilled a relatively stable development workflow:
Starting from requirement breakdown, I first align the requirement in Ask mode, then move into Agent mode to implement the code; afterward I do a code review, and once confirmed correct, commit promptly.
The overall flow can be summarized as: Requirement breakdown → Align in Ask mode → Modify code in Agent mode → Code review → Commit promptly.
Most people, when first encountering Vibe Coding, go through a stage where "the results aren't ideal." But the question is: can we, like large models, keep iterating on ourselves?
I've summarized a simple self-optimization mechanism:
When the result is a success, distill the effective methods, organize them into a personal knowledge base, and form reusable experience;When the result isn't ideal, do a root-cause analysis to find the source of the problem. Looking further, the problems roughly fall into two categories:
- Uncontrollable factors: such as the limits of the model's capabilities. In this case, consider adjusting the model or switching tools in time;
- Controllable factors: such as prompts that aren't clear enough, flaws in the business logic itself, code structure that needs refactoring, or not being proficient enough with the tool (for example, not clearly distinguishing between Ask mode and Agent mode).