Diffs & Review

[firstunicorn]

I really love Kilo Code so far (I'm trying to move from Cursor), but the lack of an "Accept / Reject" workflow is almost a blocker for me. For now, as far as I understand, Kilo only has a "Reject block" button in the diff view. It's fine if there are just a few diffs in one file, but when there are a lot of diffs and a lot of files, the lack of an "Accept" button becomes cumbersome.

It would be nice if we had at least some sort of staging process (stage to commit), but a Cursor-style "Accept / Reject" workflow might be even better. I tried looking into Kilo settings, googling VS Code extensions to replicate a similar workflow, and even asked ChatGPT and Claude - no luck.

The only thing that ChatGPT mentioned was that the "GitHub Pull Requests and Issues extension" and Github Copilot have a similar style of diff-approving workflow, but I haven't verified that and I'm not sure if they can be integrated with Kilo. I attached a screenshot to show what I mean. You can read more about this here: https://docs.cursor.com/en/agent/review

Also, a lot of the time you need to accept/reject the whole file, and you can't do it in Kilo right now, at least as far as I'm aware.

Also, an even bigger blocker for me is that you need to check diffs file by file, as opposed to Cursor, where you can mass-edit files and then decide what to accept and what to reject. In Kilo, you can either auto-accept and not have the ability to see diffs or accept on a file-by-file basis.

For now, I can work around it by pushing a Github commit before any editing and then looking at the changes, but this is not ideal because sometimes I need to test some ideas and make preliminary changes and not be forced to make a commit before edits. Also, not everyone uses Git/Github.

There are a lot of AI IDEs with a similar workflow (Windsurf has it, Trae Code has it), so I'm sure that feature is pretty in demand, at least because everyone has gotten used to it.

[kevinvandijk]

Hi @firstunicorn,

To accomodate for easier vibe engineering (basically trusting the model to do the work) we enabled auto-approval by default but if you prefer a workflow where you can approve changes this is possible of course! You can disable the auto-approval for writing files to get an approval-based workflow. There are also more types of things on which you can toggle auto-approval. See the docs for more information about the possibilities :).

[firstunicorn]

Hi, @kevinvandijk, thanks for your reply. As I said before, this is not solving the issue, because if we turn off auto approval, there is another issue - we can't mass-edit files and need to approve each file manually before we go to the next one.

I'm not sure if you read my entire initial message because this is exactly what I wrote:
"...you need to check diffs file by file, as opposed to Cursor, where you can mass-edit files and then decide what to accept and what to reject. In Kilo, you can either auto-accept and not have the ability to see diffs or accept on a file-by-file basis."

In Cursor, this feature is really useful for testing ideas and being able to see where the LLM "goes" overall after your prompt.

Also, there are other things that I described earlier that Kilo is not addressing, not related to auto-approval at all.

I think all of these can be solved with some sort of shadow git system.

[firstunicorn]

Also, I found in the Documentation that "checkpoints" partly cover these things, but I still can't recreate same workflow as in Cursor...

[firstunicorn]

More specifically - "Accept / Reject" workflow - Approving part of the file or whole file.

[oxysoft]

Hi, Kilo Code is truly amazing and I love that I can try the new model Horizon Alpha, unlike Cursor's model policing ecosystem... But definitely I came here with the exact same disappointment.

The way that Cursor works, it instantly applies all the edits to the files, however the editor states are saved and diffed with the newest revision, so that you have to "keep" changes.

I have the actions Go to Next Diff File / Go to Previous Diff File mapped to ALT-LEFT / ALT-RIGHT and Accept Partial Edit mapped to ALT-ENTER. This allows me to cycle through each diff chunk across the codebase, and review and accept them at light speed.

This workflow is brillant and is the difference between simply vibe coding and being an AI-augmented engineer! This way, your brain can parse and absorb the generated code at light speed based on the coloring of the diffs. This way you are always in the loop, actually feeling as though you rendered the code out of your mind rather than simply off-loading to an agent.

Highly recommend prioritizing this, this elevates the entire workflow. I think these editor actions are actually VS Code feature too, however Cursor might be adding flavor to it with the "keep all" popup buttons floating above the editor.

[olearycrew]

Related/possible duplicate of #115

[AndreasGalster2]

I just want to comment on here and say one somewhat subjective feedback: I also highly need this (though found some workarounds for now via git, thanks people on discord server!)... I suggest to look at Cursor/Windsurf for inspiration.

While VSCode / CoPilot has this as well... I've come back to CP at least 4 times in the last 2 years since Cursor/WS initial release and every time I try to vibe code, I always get disappointed (actually infuriated tbh). As oxysoft pointed out, Cursor/Windsurf allow you to be hands-off, let it do its thing, then easily review and revise if there are issues. A (programming-skilled) product manager's dream.

The experience for applying diffs in VS Code is extremely flawed/buggy. Windsurf and Cursor nailed it, so IMO best to take inspiration from how they do it. VSCode looks like it does the same, but there are so many problems in the small details to apply all/or granularity of what you want/don't want to apply of the code changes.

[yohplala]

Hello all,
I bring my +1 on some parts of what has been discussed.
Similarly to others in the thread, I try to move away from Cursor to Kilo code because it is much more open to other models (and most notably ones from Mistral)

This said,
Whatever the models, none is able to produce optimized code.
I can, and I want to check what any of these models produces before integrating it into my code.
So an UI that allows fast and ergonomic reviews is key.

And as said by others, Cursor seemed to have its designers on the topic, and what they came with does be ergonomic.
What I like:

1- similar to Github, diff is on a single page. This is a +1 for me. It does be easier to compare lines of code when they are one on top of the other, than when they are side-by-side. Example on Github:

2- each of the modified sections has its own Accept/Reject option (as can be seen on the picture at the top).
You can review changes one by one, accept one, reject the next, modify the third to then accept it.

Reviewing still takes time, but it really gives you the control.
If there is one section you don't like, you can discard it easily, accept all the others.
At least you have not lost your time with making a prompt that the model will not have been able to understand.
You accept part of the changes and you have made progress.

It is a work around the frustration that you can know when you spend time trying to make the clearest prompt ever, and a model just produces BS, you realize you have lost time while on the opposite, you wanted to save time by using anAI coding assistant .
Such a feature makes it possible to prevent this.

[pierrecorsini]

+1 To that. "Forced" to use github copilot due to this lacking feature.

[AndreasGalster2]

Just commenting on here once more for feedback, because I remembered one thing that makes VS Code's version so unusable:

In Cursor/Windusrf, you can

1. manually still edit/overwrite anything in the diff, e. g. if it made a mistake, forgot a type, renamed something, etc that you didn't want.
2. those edits are STILL part of the approval process... you can still reject them, or approve them... it's like it's one big PR, so of course, if the overall changes get rejected, it's reasonable to also delete the changes you made within the diff
3. likewise, you can make completely brand new code changes, while the approval flow (consider it local PR) is still going on, so then this gets marked as a change (green, or red), as if the LLM made those changes, so it can also be approved/rejected again
4. most frustrating copilot issue: you CANNOT copy & paste anything from the deleted parts... if the LLM changes a lot, deletes stuff, etc... anything in "red" can't be "undone" by copying it... sometimes LLMs just make mistakes, or delete parts that they shouldn't have. maybe only 10% was wrong. An easy copy & paste would solve it, but in Copilot that is impossible. It sounds like such a small problem, but to me it's one of the most frustrating flaws of their approval workflow

[olearycrew]

Related: #115

[ItosEO]

Yes, I hope this feature can be improved.

[sleekflowleochoi]

https://marketplace.visualstudio.com/items?itemName=xyz.local-history
The plugin would keep all local history and we could compare each file changes when needed.