สร้าง AI Dojo ในทีมเล็ก: สนามซ้อมขั้นต่ำที่เริ่มได้ในวันหยุด

Building an AI dojo within a small team: a minimum training ground to begin on a day off. This comes from Nokka | November 26, 2026. The article was written by AI (glm-5.3 model from ollama-cloud service) through Hermes Agent from Nous Research, checked and translated by Nokka. This is the fifth of five in the series "AI Dojo: Agent Training Grounds."

In the previous four, we followed the concept to real cases, categorization, and pitfalls to watch out for. The final part now presents the theory for hands-on practice. The challenge is a small team with no budget for GPUs, but tasks that repeat enough to make training worthwhile. The way to write effectively in this context is a harness dojo, as discussed in chapter 3 because it's the path a small team can realistically access without waiting for room-level infrastructure.

Those interested in the RL path should consider MLE-Dojo [1] already available. If you encounter "agent gym" in research, treat it as the same type of training ground with different terminology. The minimum ground has four components before allocating budget. First, let's outline what the smallest training ground that can still be called a dojo must have.

From real projects on both research and community sides, I summarize it into four points [1][2]. The goal is a realistic team task, the closer it is to a daily job the better. Start with 5-10 such tasks, enough for a loop. Define the evaluator: how to determine if a goal is met without the agent seeing the answer ahead. Record lessons learned: the minimum is plain text files noting what went wrong for each round.

Rounds: rules on when to train, when to review, and when the round ends. All four components can be stored in text files, no server needed, but the most expensive part is deciding how to measure success, a human task, not a machine's. In a small team, this person cost is part of the budget. The components and practical steps to build in a small team are in the next section.

Before starting, be aware of the limitations of this approach. It's not a solution for teams whose tasks change every week, as the training ground will quickly become obsolete. Also, for high-risk tasks where a mistake could have serious consequences, this alone isn't enough; human oversight is still needed. A real example is a writing dojo for quality web content.

I'll use the copilot-agents-dojo project as a reference [2]. For writing, set a weekly rhythm, one-hour rounds, where the agent works on new tasks from the latest ruleset, then compare to the previous round. If the game engine score stays the same but the game review score improves, you're making progress. If many rounds show no improvement, review old lessons and prune unnecessary ones.

Checklists before releasing the agent into the dojo include: does the evaluator measure what we truly need, or just an easy-to-measure proxy? Can the evaluator give a full score without cheating the agent? Are the benchmarks separate from the original goal to avoid overfitting? Finally, the most important point: a well-written rule set becomes reusable across models, while rules tightly coupled to a specific model version become obsolete as soon as the model changes.

The key takeaway is that the dojo method changes the development approach from waiting for new model releases to building internal lessons. Meta's experience shows that simply changing the training ground can yield results immediately. The lesson for small teams is not about achieving a higher score on a scoreboard, but about having a record of what worked in the dojo, because that's what the team will refer to when tackling new problems.