idea_world_labDEV JOURNAL
Wednesday, June 17, 2026

2026-06-17 SWE-agent trajectory keyword memo

Core conclusion

When creating a Godot 4 coding model, a small Q&A dataset is likely insufficient. The problem currently being considered is not a simple instruction dataset issue, but rather a software engineering agent learning problem that involves reading repository‑level long contexts and proceeding through file navigation, judgment, modification, verification, and patch generation.

In summary, the name of the current direction is close to the following.

Long-context repository-level software engineering agent training

Or it can be seen more briefly with the following keyword.

SWE-agent trajectory training

If we substitute it with Godot, the goal is not just a simple Godot Q&A model, but something closer to the following.

# Creating a SWE-agent trajectory dataset for Godot

Why Small Q&A Is Not Enough

The original concerns were as follows.

"Make a map"
-> Read project
-> Find related files
-> Check assets
-> Determine Godot 4 syntax/API
-> Modify code
-> Run/Test/Validate
-> Create patch

This flow does not end with a single question -> answer. A real coding agent must explore multiple files, make intermediate judgments, apply fixes, and perform verification. Therefore, instead of a dataset that only retains the final answer code, it may be more appropriate to create training data from the agent’s trajectory and patches left while solving the problem.

Priority to Explore

1. SWE-smith
2. nebius/SWE-agent-trajectories
3. CoderForge-Preview
4. ACC
5. aiXcoder CoLT
6. RepoBench / CrossCodeEval / RepoCoder
7. godot-dodo / wallstoneai dataset

Case Memo

SWE-agent trajectories

SWE-agent-trajectories is a dataset of agent behavior logs that view a GitHub issue, explore repository files, open required files, edit, test, and create the final patch.

Key keywords:

  • agent trajectory
  • GitHub issue solving
  • file exploration
  • patch generation
  • software engineering agent training

Godot side response:

"Make a map for me"
-> Explore Godot project structure
-> Check related scene/script/resource
-> Modify
-> Run or verify screenshot
-> Create patch

SWE-smith

SWE-smith is a toolkit that transforms a GitHub repository into an environment for training software engineering agents. In description, it can convert an arbitrary GitHub repository into a SWE-gym format, and create file localization, program repair, and SWE-bench style tasks.

Godot side support:

Godot repo
- Create task for modifying map/scene/script
- Create Godot agent trajectory
- Train Godot patch model

SWE-Gym

SWE-Gym is an example that bundles a codebase, executable runtime environment, unit tests, and natural language tasks to train a SWE agent and verifier.

Godot side response:

Godot project
+ Executable Godot version
+ scene/test/screenshot verification
+ natural language task
+ Edit trajectory
+ patch

The important point is that it does not only learn code or only learn natural‑language questions, but it also bundles the execution environment and verification together.

CoderForge-Preview

CoderForge-Preview is an example that creates long‑context SFT data based on agent trajectories. It is noteworthy that it used a maximum 128K‑token long‑context trajectory.

This example serves as evidence for the following question.

Isn't a large context unnecessary for repository-level tasks?

Actual coding agent training also includes a flow that uses long‑context trajectories.

ACC

ACC: Compiling Agent Trajectories for Long-Context Training is an approach that compiles agent trajectories into a long‑context QA format. Converting multi‑turn tool calls, observations, file contents, and search results into long‑context training data is the key.

This case is linked to the following question.

Is it enough to train only on the final answer code?  
Or should the file navigation and decision-making process also be retained as training data?

RepoBench / CrossCodeEval / RepoCoder

This series deals with repository-level code understanding and completion problems.

Core concerns:

  • It is difficult to capture real project complexity with only a single-file benchmark.
  • Useful information is scattered across multiple files.
  • Code completion that requires cross-file context must be evaluated.
  • A retrieval-generation pipeline is needed.

Godot side response:

It is difficult to modify the map by looking at only one file.  
We need to look at the scene, script, resource, project settings, and asset paths together.

aiXcoder CoLT

aiXcoder-7B-v2 and CoLT address the issue where the model can ignore useful information even when given a long context.

Important question:

Is it okay to put a large context?
-> No.
Even if you put a large context, you need to train/validate whether the model actually reads and utilizes it.

Godot side has information related to Godot 4 even within a long context, so the model can answer using Python-like patterns or the Godot 3 API. Therefore, it may be necessary to train the model to utilize long-context directly, or to design data that more strongly anchors the Godot 4 context.

godot-dodo / wallstoneai dataset

Direct examples from the Godot side include godot-dodo and wallstoneai/godot-gdscript-dataset.

These two are closer to a GDScript raw code or repo text dataset. They are meaningful as a starting point for Godot‑specific training, but they are far from the ultimate goal of an agent trajectory dataset.

Compared with the current goal, it can be summarized as follows.

Existing Godot dataset:
GDScript raw code / repo text

Required Godot dataset:
Godot repo context
+ user task
+ file exploration
+ patch
+ verification
+ long-context trajectory

The connection to the questions organized in the June 14 retrospective is as follows.

Can we fit the entire project context and the retrieved official documentation snippets into the model input context at once?
-> long-context repo-level coding problem
# Should the exploration and judgment process be recorded as data?
-> trajectory training problem
Even if given a long context, will the model use the Godot 4 context correctly?
-> long-context utilization / CoLT problem