Six months with Qoder across 12+ projects — I stopped writing code and started directing AI.
I'm E Jian (鄂建), a senior developer at Fuiou Payment. Running Qoder across a dozen projects for over six months, my entire workflow transformed — from writing code line by line to setting direction, feeding context, and validating results.
The shift didn't happen overnight. Like most teams, we went through the full arc: install the tool → think it's decent → hit a wall of pitfalls → eventually forge a methodology. Today I'll break down that journey.
This is the first iron rule we discovered. Sounds obvious, but most teams stumble right here.
"There's a bug in this code, fix it for me." — That's the most common prompt I've seen, and the most useless one. If you said that to the colleague sitting next to you, they wouldn't know what you meant either — let alone an AI.
The right approach: tell the AI
I built a habit: never type complex requirements directly in the chat box. The box is too narrow — after a hundred words you can't see the full picture, and your train of thought breaks with it.
My approach: open a notepad first, organize the full requirement description with placeholders, then paste the whole thing into Qoder and @ relevant files at the end. Structured input looks like this:
Three lines. Not a 200-word essay leaving the AI to guess what matters.
The strategy is clear: skeleton first, details later. Give the goal and constraints in round one; after AI outputs, add targeted refinements. Converge within three rounds. Qoder also has a "Prompt Enhancement" button in the lower right — click it after writing and AI optimizes your expression structure. Poor input quality guarantees poor output quality.
Here's a method I frequently use in exploratory projects — ask the AI to assume the project has already failed, then answer: When did things first go wrong? Which key decision went off track? Which risk should have been identified earliest but was overlooked?
I also add: "Explain it in a way that a retired farmer growing vegetables would understand."
The AI doesn't know your technical level, but it knows what level "a farmer growing vegetables" is. The output becomes as plain as possible — no smokescreen of jargon.
The real purpose of this prompt is to force AI into an end-state perspective to surface risks early. In one e-commerce project, this method helped us identify a performance bottleneck in high-concurrency scenarios ahead of time. We introduced an async queue design and avoided a post-launch crash.
The most frequent pitfall in our early days was "context pollution." The typical path: Round 1 — AI proposes a flawed fix for a NullPointerException. Round 2 — you continue building on the flawed approach. Round 3 — you point out the problem. Round 4 — AI loops back to the Round 1 assumption. Dead loop.
We distilled one hard rule: If the same issue hasn't converged after 3 iterations, start a new chat window immediately. Don't mourn the previous conversation — a clean context costs ten times less than repeatedly correcting a polluted one.
Same principle: don't @ seven or eight files at once. One file runs 600–1000 lines; seven or eight fills over 10,000 lines, maxing out a 200K context window. Once compression kicks in, AI drifts. Give only the necessary context per conversation; never mix unrelated topics.
After a while, we found that matching different tasks to different models and modes makes a dramatic difference:
Architecture design → Ultimate model. Bug fixes → Performance model. Daily coding → Auto. As for coding modes: Editor = you drive, AI navigates; Quest = you name the destination, AI confirms then plans the route; Expert Panel = you've hired a dev squad.
But consumption differences are real: Quest and Expert Panel cost roughly 8× what Editor does. Don't casually fire up Expert Panel for routine coding — you can burn through 2,000 Credits in a day or two.
Once the fundamentals were solid, the bottleneck shifted. It was no longer "how to talk to AI" but "how to let AI work autonomously within my project environment."
MCP (Model Context Protocol) is the key to breaking AI beyond local file boundaries. Without it, AI can only read what you @. With it, AI can search the web, query databases, operate browsers, and call external systems.
But the configuration principle is less is more: keep it under 8. Each MCP's tool descriptions are loaded in full into the context — too many and you blow it up. Enable and disable based on actual need.
Previously, debugging a bug meant manually copying table schemas, pasting them to AI, getting a solution, then manually adjusting. Shuttling data back and forth ate up most of the time.
Now, just @ the database connection directly in the IDE chat. AI reads the schema and generates Entity, Repository, and Controller — field names, types, and constraints all correctly mapped.
More critically for troubleshooting — AI reads code logic while simultaneously querying the database to verify data, directly determining whether it's a code issue or a data issue. No more acting as the middleman shuttling information; it queries and judges on its own.
Traditional flow: SSH into server → manually check logs → copy content → switch to AI → describe the problem → AI guesses an answer → go back to server to verify. A minor issue could eat one or two hours.
Now AI connects directly to the server, reads logs and configs in real time, and delivers targeted solutions in one step.
Of course, security principles are non-negotiable — least-privilege accounts, manual confirmation for high-risk commands, caution in production environments, and complete operation logging.
I compare Hooks to aspects in Java — before-advice and after-advice.
Why do we need them? Real pitfalls our team has hit: accidentally pasted
We currently have over a dozen projects running on Qoder, and rules configuration is paramount. Different projects call for different strategies:
New projects directly reuse general rule templates (java.md, code.md, etc.). Iterative projects first generate a RepoWiki, letting AI summarize a draft based on existing code style, then manually review and fine-tune. Multi-subproject repos place an AGENTS.md at root as a navigation map.
The configuration principle boils down to one line: Too many rules equals no rules. Keep each file under 200 lines. Start with core rules, continuously update based on conversation feedback, and boldly delete when redundant.
Memory records user preferences, tech stack, naming conventions, and historical pitfalls. Management uses a lazy-loading strategy — load on demand, never send everything every conversation. Keep global memories limited in quantity and periodically clean out outdated content.
The core value is the compounding effect: the longer you use it, the better AI understands your project, and the lower the probability of repeating the same mistakes.
Once fundamentals and environment configuration were both in place, the real inflection point arrived.
We adopted the OpenSpec (Spec-Driven Development) workflow — a four-step closed loop: Explore → Proposal Design → Implement → Archive. It's more stable than Plan mode: proposals persist in the project repo, so starting a new window or picking up the next day loses nothing.
A real example. I type "Help me develop an order refund feature":
Exploration phase — AI automatically searches the project structure, scans existing tables and interfaces, and maps out the current business state. Clarification phase — AI proactively asks: What's the refund scenario? Who can initiate? When is it allowed? Is approval required? Proposal phase — outputs three documents: a change proposal, a design doc, and a development task doc, all detailed down to field level. Execution phase — breaks it into 23 fine-grained tasks, generates refund entity classes, Mappers, DTOs, five endpoints, and one new table in roughly 2 minutes, modifying 24 files. Archive phase — once confirmed, archive it; next time a new window opens, AI automatically checks for unarchived tasks and continues.
This is why task decomposition matters so much — high-level direction is where mistakes happen, but broken down to field level, AI executes with precision.
After six months, we distilled one counterintuitive pattern: The leaner the context, the fewer Credits consumed, and the more accurate AI's output.
This translates into several key actions: AGENTS.md stays under 100 lines (too long and AI actually stops following it); rules are categorized under
After half a year, my biggest takeaway: the developer's role is undergoing a fundamental shift.
We're no longer "the people who write code" — we're "the people who set direction, control quality, and make judgments." AI is responsible for doing things fast; human thinking is responsible for doing things right.
If I had to give a few pieces of advice to teams just starting with AI Coding: don't rush into complex configurations — master context management first; don't be afraid to start a new chat window; keep rules few and sharp, not abundant; commit frequently rather than in bulk — validate immediately after writing, and push to Git if it passes.
Tools will keep getting more powerful, but the methodology for mastering them won't go out of date.
This article is based on the online talk "Qoder AI Best Practices" by E Jian (鄂建), Senior Developer at Fuiou Payment.
The First Insight: AI Output Quality = Your Context Quality
This is the first iron rule we discovered. Sounds obvious, but most teams stumble right here.
"There's a bug in this code, fix it for me." — That's the most common prompt I've seen, and the most useless one. If you said that to the colleague sitting next to you, they wouldn't know what you meant either — let alone an AI.
The right approach: tell the AI @OrderService.java line 156 throws a NullPointerException, triggered when order status is null. Exact location, symptom, relevant files — all three are non-negotiable.
This insight sounds simple, but embedding it into team habits took us considerable time.
Phase One: Building the Fundamentals
From "Typing Off the Cuff" to "Structured Input"
I built a habit: never type complex requirements directly in the chat box. The box is too narrow — after a hundred words you can't see the full picture, and your train of thought breaks with it.
My approach: open a notepad first, organize the full requirement description with placeholders, then paste the whole thing into Qoder and @ relevant files at the end. Structured input looks like this:
A Prompt Trick: Making AI "Post-Mortem" Your Project
Here's a method I frequently use in exploratory projects — ask the AI to assume the project has already failed, then answer: When did things first go wrong? Which key decision went off track? Which risk should have been identified earliest but was overlooked?
I also add: "Explain it in a way that a retired farmer growing vegetables would understand."
The AI doesn't know your technical level, but it knows what level "a farmer growing vegetables" is. The output becomes as plain as possible — no smokescreen of jargon.
The real purpose of this prompt is to force AI into an end-state perspective to surface risks early. In one e-commerce project, this method helped us identify a performance bottleneck in high-concurrency scenarios ahead of time. We introduced an async queue design and avoided a post-launch crash.
Context Pollution: Tuition We Paid
The most frequent pitfall in our early days was "context pollution." The typical path: Round 1 — AI proposes a flawed fix for a NullPointerException. Round 2 — you continue building on the flawed approach. Round 3 — you point out the problem. Round 4 — AI loops back to the Round 1 assumption. Dead loop.
We distilled one hard rule: If the same issue hasn't converged after 3 iterations, start a new chat window immediately. Don't mourn the previous conversation — a clean context costs ten times less than repeatedly correcting a polluted one.
Same principle: don't @ seven or eight files at once. One file runs 600–1000 lines; seven or eight fills over 10,000 lines, maxing out a 200K context window. Once compression kicks in, AI drifts. Give only the necessary context per conversation; never mix unrelated topics.
Models and Modes: Stronger Isn't Always Better
After a while, we found that matching different tasks to different models and modes makes a dramatic difference:
Architecture design → Ultimate model. Bug fixes → Performance model. Daily coding → Auto. As for coding modes: Editor = you drive, AI navigates; Quest = you name the destination, AI confirms then plans the route; Expert Panel = you've hired a dev squad.
But consumption differences are real: Quest and Expert Panel cost roughly 8× what Editor does. Don't casually fire up Expert Panel for routine coding — you can burn through 2,000 Credits in a day or two.
Phase Two: From "Knowing How to Use It" to "Configuring the Environment"
Once the fundamentals were solid, the bottleneck shifted. It was no longer "how to talk to AI" but "how to let AI work autonomously within my project environment."
Giving AI External Capabilities: MCP
MCP (Model Context Protocol) is the key to breaking AI beyond local file boundaries. Without it, AI can only read what you @. With it, AI can search the web, query databases, operate browsers, and call external systems.
But the configuration principle is less is more: keep it under 8. Each MCP's tool descriptions are loaded in full into the context — too many and you blow it up. Enable and disable based on actual need.
Direct Database Connection: AI Queries and Validates on Its Own
Previously, debugging a bug meant manually copying table schemas, pasting them to AI, getting a solution, then manually adjusting. Shuttling data back and forth ate up most of the time.
Now, just @ the database connection directly in the IDE chat. AI reads the schema and generates Entity, Repository, and Controller — field names, types, and constraints all correctly mapped.
More critically for troubleshooting — AI reads code logic while simultaneously querying the database to verify data, directly determining whether it's a code issue or a data issue. No more acting as the middleman shuttling information; it queries and judges on its own.
SSH Remote Debugging: From Constant Back-and-Forth to One Shot
Traditional flow: SSH into server → manually check logs → copy content → switch to AI → describe the problem → AI guesses an answer → go back to server to verify. A minor issue could eat one or two hours.
Now AI connects directly to the server, reads logs and configs in real time, and delivers targeted solutions in one step.
Of course, security principles are non-negotiable — least-privilege accounts, manual confirmation for high-risk commands, caution in production environments, and complete operation logging.
Hooks: Managing AI with Aspect-Oriented Thinking
I compare Hooks to aspects in Java — before-advice and after-advice.
Why do we need them? Real pitfalls our team has hit: accidentally pasted access_key=AKIA... into a prompt and sent it to the model without thinking; AI wanted to execute rm -rf /data/, we clicked confirm, and several GB of data vanished; AI said "done," but running tests revealed nothing but compile errors.
Hooks solve three problems: intercept sensitive information before submission, automatically run compilation verification after execution, and persist changes to external systems after response. Configuration is committed to Git — the entire team shares the same safety net.
Rules Configuration: Lessons from a Dozen Projects
We currently have over a dozen projects running on Qoder, and rules configuration is paramount. Different projects call for different strategies:
New projects directly reuse general rule templates (java.md, code.md, etc.). Iterative projects first generate a RepoWiki, letting AI summarize a draft based on existing code style, then manually review and fine-tune. Multi-subproject repos place an AGENTS.md at root as a navigation map.
The configuration principle boils down to one line: Too many rules equals no rules. Keep each file under 200 lines. Start with core rules, continuously update based on conversation feedback, and boldly delete when redundant.
Memory System: Making AI Understand You Better Over Time
Memory records user preferences, tech stack, naming conventions, and historical pitfalls. Management uses a lazy-loading strategy — load on demand, never send everything every conversation. Keep global memories limited in quantity and periodically clean out outdated content.
The core value is the compounding effect: the longer you use it, the better AI understands your project, and the lower the probability of repeating the same mistakes.
Phase Three: Landing a Refund Feature in 2 Minutes
Once fundamentals and environment configuration were both in place, the real inflection point arrived.
We adopted the OpenSpec (Spec-Driven Development) workflow — a four-step closed loop: Explore → Proposal Design → Implement → Archive. It's more stable than Plan mode: proposals persist in the project repo, so starting a new window or picking up the next day loses nothing.
A real example. I type "Help me develop an order refund feature":
Exploration phase — AI automatically searches the project structure, scans existing tables and interfaces, and maps out the current business state. Clarification phase — AI proactively asks: What's the refund scenario? Who can initiate? When is it allowed? Is approval required? Proposal phase — outputs three documents: a change proposal, a design doc, and a development task doc, all detailed down to field level. Execution phase — breaks it into 23 fine-grained tasks, generates refund entity classes, Mappers, DTOs, five endpoints, and one new table in roughly 2 minutes, modifying 24 files. Archive phase — once confirmed, archive it; next time a new window opens, AI automatically checks for unarchived tasks and continues.
This is why task decomposition matters so much — high-level direction is where mistakes happen, but broken down to field level, AI executes with precision.
The Core Logic of Saving Credits
After six months, we distilled one counterintuitive pattern: The leaner the context, the fewer Credits consumed, and the more accurate AI's output.
This translates into several key actions: AGENTS.md stays under 100 lines (too long and AI actually stops following it); rules are categorized under .qoder/rules and loaded on demand rather than always active; generated RepoWiki must be manually trimmed — delete unused deployment plans; add .qoderignore to exclude build artifacts; require AI output summaries to stay under 100 words — we never read those long recaps anyway.
One more often-overlooked tip: use the LLM provider's official web interface for non-coding Q&A — it's free, unlimited, and sometimes faster. Save your Credits for coding tasks that genuinely require project context.
Final Thoughts
After half a year, my biggest takeaway: the developer's role is undergoing a fundamental shift.
We're no longer "the people who write code" — we're "the people who set direction, control quality, and make judgments." AI is responsible for doing things fast; human thinking is responsible for doing things right.
If I had to give a few pieces of advice to teams just starting with AI Coding: don't rush into complex configurations — master context management first; don't be afraid to start a new chat window; keep rules few and sharp, not abundant; commit frequently rather than in bulk — validate immediately after writing, and push to Git if it passes.
Tools will keep getting more powerful, but the methodology for mastering them won't go out of date.
This article is based on the online talk "Qoder AI Best Practices" by E Jian (鄂建), Senior Developer at Fuiou Payment.