First, I'm sorry for the long post, but I'm taking this opportunity to state my issue plainly in the hopes it might make a difference.
Full file rollback is a great step, as is diff approval. Telling the agent to re-plan the updates to a single file that got rolled back due to an implementation error takes longer to get right than manually rewriting the file. And, the approval system requires me to sit in front of it and monitor everything it does, every step of the way, in real time. Worse, I have yet to successfully convert on any task using this workflow unless I jump in and rewrite the file that was rolled back manually, or provide corrections. This goes for my personal account as well as the shop account.
And I'm not the only one. There are 12 other developers in this shop facing the exact same issues and experiencing the exact same problems.
If I have to babysit my AI and give up my ability to work in parallel, the value of an agentic programming assistant (provided by 5.x) is completely removed.
We all work on one project, and the project is built incrementally, and intentionally. The new sub-agent system seems to be optimizing for writing an entire codebase instead of implementing a single feature at a time. I appreciate wanting to support vibe coders in this way, but that's not why my shop was using kilo. It feels like 7.x dropped support for one group of developers in order to add support for the vibe code crowd. (I'm not throwing shade at the vibe coding crowd btw! I'm just saying there are other developers out here doing work using kilo)
Nothing has been more disruptive at my company than kilo's move from 5.x to 7.x, and since management believes legacy will be sunset soon, We don't have any other options, we're about to have a 3-day meeting to redevelop every single one of our workflows to adopt Claude Code.
Kilo has been the absolute best VS code plugin for me, because it fits naturally within the existing workflows of my team, and me personally. The CLI tool was excellent, but it never met those needs. The reliance on GitHub in order to enable cloud dev tools is not anything my local-dev shop will ever use (We're an on-premise outfit for various, unchangable reasons)
I know that adding new features is important to maintain market relevance, and I know that supporting the fastest growing segment of potential users is important for financial security. But, I don't think the full impact of certain choices was necessarily understood.
Heya! Thanks for taking the time to respond so extensively. I'm afraid I don't fully understand why you are running into this though; we use kilo ourselves to build incrementally, what exactly are you missing in the new extension to enable you to do so? The approval system is quite granular, so you can allowlist whatever you find ok, I definitely don't sit there approving every step!
What is the biggest difference for you between 5 and 7 which hinders your workflow, and why?
FWIW, we never switched for features as such, but because we thought the opencode core was more future proof, all the work we did the last few months was basically porting features.
Btw: we of course do intend to sunset 5.x at some point, and it isn't getting functional updates, but we do keep giving it model updates for now, as a we care for the customers who downgraded for now, and if you're missing anything in 5.x please let us know.
I appreciate your efforts but I prefer the old Kilo by far. I'm going to stick with 5.11.0 for as long as I can. The new one feels more oriented towards "vibe coders" than actual programmers.
Thanks Tevesio. We are working to improve the ability to tightly manage what the agent is doing in 7.x, but we aren't all the way there just yet. We've shipped side-by-side diffs (which can be expanded to full diff views) when being asked to approve edits, as well as added the context header back if you prefer (it can be dismissed). We plan to continue to make this better based on feedback, we have a tracking issue going here: https://github.com/Kilo-Org/kilocode/issues/8415
bring back the architect mode 😔
First, I'm sorry for the long post, but I'm taking this opportunity to state my issue plainly in the hopes it might make a difference.
Full file rollback is a great step, as is diff approval. Telling the agent to re-plan the updates to a single file that got rolled back due to an implementation error takes longer to get right than manually rewriting the file. And, the approval system requires me to sit in front of it and monitor everything it does, every step of the way, in real time. Worse, I have yet to successfully convert on any task using this workflow unless I jump in and rewrite the file that was rolled back manually, or provide corrections. This goes for my personal account as well as the shop account.
And I'm not the only one. There are 12 other developers in this shop facing the exact same issues and experiencing the exact same problems.
If I have to babysit my AI and give up my ability to work in parallel, the value of an agentic programming assistant (provided by 5.x) is completely removed.
We all work on one project, and the project is built incrementally, and intentionally. The new sub-agent system seems to be optimizing for writing an entire codebase instead of implementing a single feature at a time. I appreciate wanting to support vibe coders in this way, but that's not why my shop was using kilo. It feels like 7.x dropped support for one group of developers in order to add support for the vibe code crowd. (I'm not throwing shade at the vibe coding crowd btw! I'm just saying there are other developers out here doing work using kilo)
Nothing has been more disruptive at my company than kilo's move from 5.x to 7.x, and since management believes legacy will be sunset soon, We don't have any other options, we're about to have a 3-day meeting to redevelop every single one of our workflows to adopt Claude Code.
Kilo has been the absolute best VS code plugin for me, because it fits naturally within the existing workflows of my team, and me personally. The CLI tool was excellent, but it never met those needs. The reliance on GitHub in order to enable cloud dev tools is not anything my local-dev shop will ever use (We're an on-premise outfit for various, unchangable reasons)
I know that adding new features is important to maintain market relevance, and I know that supporting the fastest growing segment of potential users is important for financial security. But, I don't think the full impact of certain choices was necessarily understood.
Heya! Thanks for taking the time to respond so extensively. I'm afraid I don't fully understand why you are running into this though; we use kilo ourselves to build incrementally, what exactly are you missing in the new extension to enable you to do so? The approval system is quite granular, so you can allowlist whatever you find ok, I definitely don't sit there approving every step!
What is the biggest difference for you between 5 and 7 which hinders your workflow, and why?
FWIW, we never switched for features as such, but because we thought the opencode core was more future proof, all the work we did the last few months was basically porting features.
Btw: we of course do intend to sunset 5.x at some point, and it isn't getting functional updates, but we do keep giving it model updates for now, as a we care for the customers who downgraded for now, and if you're missing anything in 5.x please let us know.
I appreciate your efforts but I prefer the old Kilo by far. I'm going to stick with 5.11.0 for as long as I can. The new one feels more oriented towards "vibe coders" than actual programmers.
Thanks Tevesio. We are working to improve the ability to tightly manage what the agent is doing in 7.x, but we aren't all the way there just yet. We've shipped side-by-side diffs (which can be expanded to full diff views) when being asked to approve edits, as well as added the context header back if you prefer (it can be dismissed). We plan to continue to make this better based on feedback, we have a tracking issue going here: https://github.com/Kilo-Org/kilocode/issues/8415