DavidAusRR on Discord

[Juice10]

From Discord

I've had unexpectedly great success using Kilo to prototype a mobile music app for iOS and Android.

I've utilized a mix of opus 4 and sonnet 3.7, have memory-bank configured and a local github repo.

The expensive bit, for me, is how this virtual team behaves like the cartoon dog that sees a Squirrel!

Console debugging messages are added to the code by the team. The app is built and launched on a device from Kilo and the debug agent watches the console message stream by, usually when the app crashes or I kill it.

The console log for a run is long and the Kilo team isn't processing it fully and rarely asks about my actions on the device. It just makes huge and often incorrect assumptions. Then without taking a breath or asking for my input - it proceeds to jump into a refactor or extra logging messages, or setting up library bypass code. The project has been pulled into many rabbit holes of Kilo's creation, burning context space and credits and creating a signficant amount of frustration for this user.

Most painful of all is how it over-complicates things involving buffers, queues, delegates, messaging, timers. It makes decisions based on limited knowledge about user actions, changes code and documentation, and plows right into the next build without involving the human. Rarely asks for the library header files it needs (yet it has them but can't find) and makes assumptions that get expensive.

I've cut through the endless iterative loops and pointless thrashing by providing clear examples in native Objective-C that I wrote a dozen years ago. That really works well but there doesn't seem to be a place to store such code and documentation for Kilo to access. I'm tempted to put these in memory-bank.

So what should I be considering to help improve my success with Kilo?

[Juice10]

@kevinvandijk there is lots of great feedback here, could you go in and see what actionable changes we can make to Kilo Code to help with this?