The editFiles function in src/server/code/editFiles.ts contains the core code creation loop that JACoB uses to write code. Currently we have a process where JACoB creates a plan for the issue (as a string), along with a list of files to create or update. This works fine for the Figma -> Code scenario where we are usually creating a single, smaller file. However, for more complex issues, JACoB can run into problems where it tries to edit too many files at once and exceeds the 4K token output limit from GPT-4.
A better approach is to modify the plan output to be an array of steps, with each step representing a unique file that needs to be updated/created, along with a set of changes to be made and exit criteria. We can then loop through each step and use the existing code creation path to edit/create one file at a time to avoid the context window blowout issue.
This task involves a bit of research as we may also need to implement a more complex RAG-like approach to identifying the existing files that need to be updated, along with identifying existing files that are similar to the file that is being created/edited to ensure the code follows the correct patterns and practices for the code base.
[ ] Refactor prompts to output array of single-file steps with changes and exit criteria
[ ] Implement loop to process steps individually
[ ] Review the bug fix loop to address this same issue (i.e. don't pass multiple files to a single LLM call when looking for errors)
The
editFilesfunction insrc/server/code/editFiles.tscontains the core code creation loop that JACoB uses to write code. Currently we have a process where JACoB creates a plan for the issue (as a string), along with a list of files to create or update. This works fine for the Figma -> Code scenario where we are usually creating a single, smaller file. However, for more complex issues, JACoB can run into problems where it tries to edit too many files at once and exceeds the 4K token output limit from GPT-4.A better approach is to modify the plan output to be an array of steps, with each step representing a unique file that needs to be updated/created, along with a set of changes to be made and exit criteria. We can then loop through each step and use the existing code creation path to edit/create one file at a time to avoid the context window blowout issue.
This task involves a bit of research as we may also need to implement a more complex RAG-like approach to identifying the existing files that need to be updated, along with identifying existing files that are similar to the file that is being created/edited to ensure the code follows the correct patterns and practices for the code base.
bug fixloop to address this same issue (i.e. don't pass multiple files to a single LLM call when looking for errors)