Dealing with fairly complex features #2914
|
Hi, we observe that on large / complex features everything went's smoothely until the implementation starts. In the middle of the run, the LLMs start to halluzinate and loosing completely track + ignoring the plan / tasks / .. . We observe that everything goes south, when or closely before the compaction is triggered. We understand that the context window running full is most likely the issue. But what's the best strategy here? How do you approach these issues? |
Replies: 2 comments 4 replies
|
Great question — context window exhaustion during implementation is a known challenge for any coding agent session The Option 1: Limit how many tasks run per invocationInstead of letting implement run through all tasks at once, tell it to stop early: /implement only execute tasks 1-10, then stop and report progressor scope by phase: /implement only execute the Setup phase, then stopSince completed tasks are marked Option 2: Instruct the agent to use sub-agentsIf your coding agent supports sub-agents (e.g., Copilot CLI, VS Code Copilot), you can instruct implement to delegate individual tasks: /implement delegate each parallel [P] task to a sub-agentEach sub-agent gets a focused context (one task + relevant plan excerpts) rather than the full feature context, so compaction never triggers. Option 3: Combine bothFor very large features: /implement execute only the Core phase, delegate [P] tasks to sub-agentsWhich approach to choose
The "spec of specs" idea you mentioned maps to that third row — breaking the feature into independently spec'd sub-features, each with their own plan/tasks/implement cycle. That's a valid approach for truly massive features, but for most cases limiting task scope per run is the simplest fix. |
|
Could we add this gem of knowledge to the documentation? I assume addressing context exhaustion is a topic for many users, and worth a dedicated section / part of the documentation. |
|
Can you please file an issue for this and refer to this discussion? Thanks! |
|
@mnriem Feedback from our side about the specs of specs, we've implemented with that approach now multiple bigger features and it works as expected. the intended result of the initial specification is a road map, which maps to indiviual chunks of work, either building up on each other, or decomposition in paralelizable work streams. What we realized is, that the roadmap should be referenced by the sub-specs to ensure focus and boundaries are clear to follow up specification runs. |
|
Great to hear. You want to help draft documentation documenting the approach in more detail? |
|
Sure thing. I've created an issue (#3423) for that. |
Great question — context window exhaustion during implementation is a known challenge for any coding agent session
The
implementcommand accepts free-form user input that the agent is required to honor before proceeding. This means you can scope each run without any tooling changes.Option 1: Limit how many tasks run per invocation
Instead of letting implement run through all tasks at once, tell it to stop early:
or scope by phase:
Since completed tasks are marked
[X]intasks.md, the next/implementinvocation picks up where you left off. This keeps each run well within co…