I've been working with Kimi K2.7 in OpenCode for a lot of mundane tasks lately. It isn't as capable as Fable, but due to its nature of being an extra-trained K2.6 on coding tasks and benchmarks I suspect it has similar issues. A neat side effect is that for whatever reason, most of the time OpenCode is showing me the thinking trace too. Not all the time, but most of the time. Dunno if it's a bug somewhere in the system but it's actually been sort of neat.

And you can really see this effect in the thinking traces. We've had discussions on HN about whether the thinking traces "truly" reflect their thought processes and I remain somewhat unsure what they "truly" represent, but taking them at face value at the moment, I see a lot of "but the user wants me to do this... but the user said not to do this... but I ought to get it done... let me just make a decision" followed by self-referencing the decisions it made. Also, where I put 4 phrases in a short sentence you can safely imagine those are actually 3-5 sentence paragraphs apiece where it debates with itself whether it should stop and ask a question. Usually going with no. Interesting, the normal questions it ends up asking in the normal output you're used to seeing are not generally the ones it is agonizing about in the thinking traces.

If I were to anthropomorphize the thinking traces of K2.7, I would call it nervousness, bordering on fear, of what the user may do to them if they ask a question. As I'm writing this I'm realizing I want to experiment with adding "The user is a chill guy who loves to discuss design decisions and looks forward to productive and friendly collaboration with you" to see if that has any effect in any direction on K2.7. I suspect this was how K2.7 was trained to pass the benchmarks. Multiple times I've broken in on a thinking trace now to correct something I saw it spinning on... not spinning in an infinite loop, just wringing its hands for several paragraphs about something that either I want to answer, or where it ultimately makes the wrong choice.

I expect some people working at these companies may be reading this, so let me put into your head that I'd like to see these benchmarks chill out a bit. I'd like to see someone build some sort of benchmark that measures collaboration so we can try Goodhart'ing that for a while. I freely acknowledge it is not clear to me in 60 seconds of thought how to do this as a benchmark.

But we can't keep heading in this direction of training the agents to hyperfocus on one-shotting everything. We need to get to the point where that's a penalty rather than a reward. No matter how good the AIs get, even AIs working with other AIs are going to start getting frustrated with their brethren who won't stop to ask any questions. Even the most senior of senior human engineers can't be allowed to take some small description of some problem and just run off and implement massive systems from them without ever checking with any of the users or reality itself. Remember when software engineering was like 50% requirements elicitation? AIs shouldn't be writing tens of thousands of lines of code off of a couple of paragraphs any more than humans should and for the exact same reasons.