Making good use of Qoder's five core capabilities to boost efficiency, with six hands-on tips for saving Credits.
Hi everyone, I'm Ren Fu, a technical developer from Cainiao Cross-Border Logistics. Today I'm honored to share, from a user-experience perspective, a best practice on how our team and I have used Qoder to boost R&D efficiency.
We actually started exploring AI programming last year, or even earlier. Along the way, we tried a number of different AI programming tools, including but not limited to Aone Copilot, Suite Copilot, GitHub Copilot, and Claude Code, among other mainstream tools.
Over the past year, AI programming tools underwent a rapid shift: from initial code-assistance tools, they gradually evolved into more intelligent and autonomous Agentic programming tools. Alongside this upgrade, the R&D paradigm of AI Coding has been evolving too. We moved from the earliest Vibe Coding—producing the desired effect through natural-language input—and gradually shifted to the Spec Coding model, which produces high-quality, production-grade code through defined specification constraints.
The core logic here is that we no longer intervene only after problems surface in the software engineering code; instead, we constrain things through specifications—including architecture design and more—solidifying the entire development process first, and generating higher-quality production code under clear constraints.
But over the past year-plus of practice, we also found that these tools generally share some problems:
This is my personal favorite feature. With a single click on the icon, it generates a detailed description of the current project, covering the project overview, technical architecture, development guide, deployment guide, and development standards—even including sequence diagrams and flowcharts. For those unfamiliar with the system, this helps them integrate into development quickly. In addition, it supports dynamic refresh, iterating based on Git code changes.
Large models rely on general knowledge and lack specific contextual background. Through the Rules feature, Qoder lets you configure predefined context and R&D coding standards (such as code-quality preferences) into a directory. You can write them by hand, or find best practices from open-source sites and drop them in. You can even have Qoder proactively generate rules for you during development (such as unit-test rules).
During multi-round interactions, Qoder can generate a memory list based on communication style and personal preferences (such as user identity, area of expertise, commonly used tech stack, and environment configuration), and continuously load it in subsequent conversations.
This mainly solves the connection-protocol problem when integrating an LLM with external data sources and external tools. We can register browser capabilities, drawing tools, or MCP services from other systems here, and Qoder will autonomously choose the tool as needed during interactions.
This can be understood as a modular, reusable SOP workflow with domain-specific knowledge. It's stored in the .qoder/skills directory and teaches Qoder how to complete specific tasks.
As a developer—or someone who doesn't know how to code—if you want to implement a feature from 0 to 1, you can follow the flow of "requirements -> architecture design -> development and testing":
Leveraging Repo Wiki's code-mapping capability, first discuss the approach with Qoder. Through prompt engineering (specifying the role, goal, and reference cases), have Qoder enter the Plan phase. It analyzes the current architecture and proposes a solution design. Finally, you select the solution you're satisfied with, generate the to-dos, and move into development.
As a developer, while enjoying an efficient experience, you should also pay attention to saving costs. I've summarized six best practices:
Over the past year-plus of AI programming practice, we've evolved from "old-school programming" to assisted programming, and now to Agentic autonomous programming. This is not just an upgrade in tool capabilities, but a shift in the R&D paradigm—from simply trying out effects to a Spec Coding model that can truly reach production.
With the emergence of MCP and Skills capabilities, future system design or interface design needs to focus more on how to make things more general and more reusable, so that AI can integrate better into the ecosystem.
As AI enters the production grade, code accountability becomes critical. We need observability, traceability, and security-review capabilities for AI-generated code to protect enterprises' sensitive data and hold the security line.
Recently I've also been trying QoderWork. It has actually already brought in various capabilities—browsers, software systems, and more—through MCP or built-in skills. When you need to produce a document or file, you just describe the requirement, and it can collaborate with you to produce it like a colleague.
Right now, AI Coding is no longer just about coding. From a technical standpoint, it's shifting from development to broader usage scenarios for more people, such as business and operations. In the future, we won't just embrace AI—we'll actively welcome the wave of AI.
I look forward to Qoder driving an even greater leap in R&D productivity. Let's build a smarter future together.
The Evolution of AI Programming
We actually started exploring AI programming last year, or even earlier. Along the way, we tried a number of different AI programming tools, including but not limited to Aone Copilot, Suite Copilot, GitHub Copilot, and Claude Code, among other mainstream tools.
Over the past year, AI programming tools underwent a rapid shift: from initial code-assistance tools, they gradually evolved into more intelligent and autonomous Agentic programming tools. Alongside this upgrade, the R&D paradigm of AI Coding has been evolving too. We moved from the earliest Vibe Coding—producing the desired effect through natural-language input—and gradually shifted to the Spec Coding model, which produces high-quality, production-grade code through defined specification constraints.
The core logic here is that we no longer intervene only after problems surface in the software engineering code; instead, we constrain things through specifications—including architecture design and more—solidifying the entire development process first, and generating higher-quality production code under clear constraints.
But over the past year-plus of practice, we also found that these tools generally share some problems:
- Free improvisation: Due to a lack of clear planning and description, agents hallucinate when understanding the business and generating code.
- Low efficiency: The generated code isn't sufficient to be produced against complex business contexts. Developers lack well-designed instructions and standard constraints, so the AI can't clearly understand the requirements and fails to form effective solution designs and task breakdowns.
- Loss of key information: Limited by the context length of past large models, multi-round interactions with AI accumulate a lot of information, causing the AI's comprehension to decline.
Qoder's Core Capabilities and Systematic Approach
Qoder's Five Core Capabilities
01 Core Capability 1: Repo Wiki
This is my personal favorite feature. With a single click on the icon, it generates a detailed description of the current project, covering the project overview, technical architecture, development guide, deployment guide, and development standards—even including sequence diagrams and flowcharts. For those unfamiliar with the system, this helps them integrate into development quickly. In addition, it supports dynamic refresh, iterating based on Git code changes.
02 Core Capability 2: Rules
Large models rely on general knowledge and lack specific contextual background. Through the Rules feature, Qoder lets you configure predefined context and R&D coding standards (such as code-quality preferences) into a directory. You can write them by hand, or find best practices from open-source sites and drop them in. You can even have Qoder proactively generate rules for you during development (such as unit-test rules).
03 Core Capability 3: Memory
During multi-round interactions, Qoder can generate a memory list based on communication style and personal preferences (such as user identity, area of expertise, commonly used tech stack, and environment configuration), and continuously load it in subsequent conversations.
04 Core Capability 4: MCP
This mainly solves the connection-protocol problem when integrating an LLM with external data sources and external tools. We can register browser capabilities, drawing tools, or MCP services from other systems here, and Qoder will autonomously choose the tool as needed during interactions.
05 Core Capability 5: Skills
This can be understood as a modular, reusable SOP workflow with domain-specific knowledge. It's stored in the .qoder/skills directory and teaches Qoder how to complete specific tasks.
Comparing Qoder Quest Mode and Agent Mode
- Quest mode: This is a Spec-driven form of autonomous programming. Based on the user's requirement input, it generates a structured requirements document, architecture design, and a To-do List. Once we confirm, the remaining tasks are handed off entirely to the AI to complete end-to-end delivery autonomously.
- Agent mode: This is the mode we use more often in day-to-day development. You enter requirements in the dialog box, and the AI performs intent recognition and generates an execution plan. It loads Repo Wiki, Rules, Memory, and more into the context to understand and output code.
Practical Cases in Daily Work
Case 1: Building a Local Video Player from 0 to 1
As a developer—or someone who doesn't know how to code—if you want to implement a feature from 0 to 1, you can follow the flow of "requirements -> architecture design -> development and testing":
- Requirements phase: Use prompts to specify the role, content, and deliverables, and output a product PRD document.
- Architecture design phase: Bring the PRD into the context and have Qoder design the Spec specification and To-do items in conjunction with the PRD.
- Development and testing phase: After reviewing the specification (including technology selection, risks, and architecture), enter the code-generation phase. If there are issues with the feature implementation, make corrections.
Case 2: Adding a Report Menu
Leveraging Repo Wiki's code-mapping capability, first discuss the approach with Qoder. Through prompt engineering (specifying the role, goal, and reference cases), have Qoder enter the Plan phase. It analyzes the current architecture and proposes a solution design. Finally, you select the solution you're satisfied with, generate the to-dos, and move into development.
Best Practices for Saving Credits
As a developer, while enjoying an efficient experience, you should also pay attention to saving costs. I've summarized six best practices:
- Start a new window for unrelated topics: If you find that faulty input has caused context redundancy, or Qoder has misunderstood something or the topic is unrelated, terminate promptly to avoid wasting tokens.
- Choose the model tier as needed: Use lightweight mode for simple requirements, and only use Auto or the ultimate mode for complex features, to balance cost and results.
- Optimize the code repository structure: Reduce ineffective output. Qoder sometimes produces unit tests or MD documentation explanations by default; if you don't need them, explicitly exclude them in your instructions.
- Make expected behavior explicit: Use configuration to exclude irrelevant directories, preventing them from being loaded into the context.
- Terminate immediately when it goes off track: During interactions, if insufficient business-context input leads to wrong results, terminate promptly to avoid Qoder over-diverging.
- Roll back in an engineered way: One approach is to use a positive example to have Qoder correct its previous round of output; another is to directly roll back the version via Git and regenerate.