Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Architect mode allowing you to edit the architect's output before editor mode #3085

Open
gitkenan opened this issue Jan 31, 2025 · 7 comments

Comments

@gitkenan
Copy link

gitkenan commented Jan 31, 2025

Let's suppose I'm in architect mode and I want to fix some config stuff. I like most of the proposed changes by the architect model, but this part looks wrong to me because it shouldn't have included 'chat' - it's an old page I want to delete:

middleware.js


 <<<<<<< SEARCH
   return ['/dashboard', '/exam', '/plan'].some(prefix =>
 =======
   return ['/dashboard', '/exam', '/plan', '/chat'].some(prefix =>
 >>>>>>> REPLACE


middleware.js


 <<<<<<< SEARCH
   matcher: [
     '/api/:path*',
     '/dashboard/:path*',
     '/exam/:path*',
     '/plan/:path*'
   ]
 =======
   matcher: [
     '/api/:path*',
     '/dashboard/:path*',
     '/exam/:path*',
     '/plan/:path*',
     '/chat/:path*'
   ]
 >>>>>>> REPLACE

However, it seems my only option is to either say 'Yes (I want to send this prompt to the editor model)' in which case I'll have to manually remove this change, or 'No' and I have to waste tokens to tweak it. I think it'd be suitable to have a '(T)weak' option whereby the user can edit the output of the architect model and remove or add any parts that are missing in the prompt which will be given to the editor model, thereby allowing more user interaction and increasing the strength of this mode.

Example usage:

Tokens: 11k sent, 654 received. Cost: $0.0077 message, $0.0077 session.
Edit the files? (Y)es/(T)weak/(N)o [Yes]: T

(Aider can open a nano file here with the architect's output which can be edited, 
and the default editor can be changed to vi by configuring aider. Once saved, the 
resulting prompt is given to the editor model)

I'm a bit surprised this doesn't exist already, so forgive me if it's already an option but I've just missed it. Thanks for this awesome project to all contributors.

@V4G4X
Copy link

V4G4X commented Jan 31, 2025

While I would like this as a feature, have you considered using this?

Edit the files? (Y)es/(N)o [Yes]: N

> /code I like your plan, I just propose these changes:
1. Change 1
2. Change 2
3. Change 3

The rest of the plan looks good.

I think this should work for the most part. It will take your suggestion and get to coding.

My only complaint with this is that if you've set up separate models:
For main model (model config) and editor model (editor-model config),
then the /code command actually uses the main model (the thinker) instead of the editor model (the coder).

But if you are using the same model, then my suggestion should work for you.

@gitkenan
Copy link
Author

gitkenan commented Jan 31, 2025

While I would like this as a feature, have you considered using this?

Edit the files? (Y)es/(N)o [Yes]: N

> /code I like your plan, I just propose these changes:
1. Change 1
2. Change 2
3. Change 3

The rest of the plan looks good.

I think this should work for the most part. It will take your suggestion and get to coding.

Thanks for the response - to be honest, I wasn't aware of this option. However, I'd prefer to edit the content myself to avoid spending more tokens on something which AI may or may not get right. Since the next step is to go to the coder, there's a fair chance that this process will be a waste and I'll have to start over or manually remove the parts I didn't want. However, I'm not aware yet of how complicated this would be as a change. I'm in the middle of trying do implement it now on my fork though but since I'm new to this project's code I thought I'd raise it as an issue.

My only complaint with this is that if you've set up separate models: For main model (model config) and editor model (editor-model config), then the /code command actually uses the main model (the thinker) instead of the editor model (the coder).

But if you are using the same model, then my suggestion should work for you.

Yeah it seems a bit inefficient to do it like this but it's good to know about, thanks. Since it's best practice for individual prompts and architectural changes to be atomic, I think it's ideal that the user should be able to tweak architectural decisions manually to avoid wastage given that these tweaks should be fairly simple.

@kostrse
Copy link

kostrse commented Jan 31, 2025

Just curious, would it be functionally same if I would not use architect mode and just do the following:

  1. reset session
  2. switch to a reasoning model (e.g. R1)
  3. in the ask mode request design proposal (please give instructions what should be done to ...)
  4. switch to a coding model (e.g. Sonnet)
  5. in the code mode ask to implement that

So I could iterate with the "architect" and "editor" in any order and as many iterations as I need?

@gitkenan
Copy link
Author

gitkenan commented Jan 31, 2025

Just curious, would it be functionally same if I would not use architect mode and just do the following:

  1. reset session
  2. switch to a reasoning model (e.g. R1)
  3. in the ask mode request design proposal (please give instructions what should be done to ...)
  4. switch to a coding model (e.g. Sonnet)
  5. in the code mode ask to implement that

So I could iterate with the "architect" and "editor" in any order and as many iterations as I need?

Thanks for the question, yes it would be functionally different. In my experience AI models don't always do well with contradictory statements (the architect model's first shot will be just before your request to change it). With my feature request, the user would have the ability to manually edit the output of the prompt themselves to delete or amend any unintended proposals. I usually delete sections like 'how to test' for example and I might add a line of text to customise the result a bit further.

This would save at least some tokens and at most a lot of tokens than what you described. If the AI understood you after the first correction and all goes well, that still means there is some dead context (some wrong architectural documentation, some wrong code and your correction). That's the best case scenario.

This would also avoid the possibility of going back-and-forth with AI models, wasting tokens and then not getting the desired result, which is the worst case scenario, wasting quite a lot of tokens and causing frustration due to wasting time.

In either case, the number of wasted tokens will also multiply for every message that follows this malarky in the session.

An option for a manual tweak in the middle is a surgical way of cutting out these possibilities from the very beginning. I hope that's clear. Feel free to test out my PR if you want to give it a try, or feel free to ask any questions.

@V4G4X
Copy link

V4G4X commented Jan 31, 2025

Damn you actually made the changes? Badass

@csala
Copy link

csala commented Feb 1, 2025

Just +1ing this request.

Surgically editing the proposal before moving on would make a huge difference.

And not only in architect mode, also in coding mode! I have observed multiple times that once you say Yes and accepted the proposed changes, some unwanted things slip into the edit diffs, and at that point there is no going back.

I would rather have a workflow that is:

  • user makes a request
  • architect makes a high level proposal
  • user can either accept the proposal, or request a change, or edit the proposal themselves.
  • once the proposal is final, editor makes a code change proposal
  • user can either accept it, or request a change, or edit the code diff themselves (the replace blocks only)
  • once the user accepts, the diffs are applied

This would prevent a lot of back and forth, and also alleviate a lot of token usage when proposals cannot be immediately accepted

@csala
Copy link

csala commented Feb 10, 2025

@paul-gauthier Just bringing this up to your attention. Is what is being discussed here something that would be considered?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants