Apparently, everyone is writing agent skills these days. We have skills for code reviews, architecture analysis, testing, debugging, and just about everything else. Meanwhile, we're debating whether comments in source code are an anti-pattern, while writing thousands of lines of Markdown to tell agents how to write code. :) Don't get me wrong. Skills can be useful. But availability isn't execution, instructions aren't guarantees, and more configuration doesn't necessarily produce better outcomes. We had linters, compilers, scripts, and deterministic analysis tools long before we had agent skills. I wrote about the growing complexity of agent configurations, what independent research actually tells us, and why I eventually deleted all my skills and instruction files. We Had Linters Before We Had Skills menges.dev/writing/we-had-li…

While working on a new blog post, I did some refactoring of Enola itself today. With Opus 5.5 it was a weekend of work - yesterday and today, intermittently, when I was around the computer (more today considering the weather). As I am following up package metrics (beside other things) on every change, I noticed that numbers went a bit out of proportion, so today I dog fed Enola with Enola, while following the results in CI as the work was happening. And, interestingly, one of the commits was again cleaning up dead code - not necessarily not used, but one too many indirection that Enola discovered itself.

Some really nice averages, and example of how far are we with SLMs on local machines. OpenCode with enola and Qwen3.8 27b Splash running on MacBook M4 Pro Max. The job that scans enola, in the loop, every night and fills the findings. What it really does? Points agent to the folder, which is Kanban-like, where agent reads all other found/fixed/disproved tickets, picks it's own number, reads very deliberate prompt, scans the code for bugs, picks one it believes is really impactful, and then tries first to prove it, then to refute it, and only if it is as sure as it can be, it fills it in newly founded bugs with specific format. I tested both OpenCode2 and Pi, and my choice is OpenCode2 - less mess about MCP, especially since this is very local workflow, and OpenCode uses subagents as well in this case. Averages of tokens per second throughput were unthinkable just two months ago in a local setup. And this then waits for another such pass, with a different prompt, to do the fixes. Opus 5.5 comes as a final authority for reviews. After Opus says it is fine, fixes don't get merged yet: seven different scripts are ran to prove that nothing got crazy - what we used to call back at the time performance tests. Only if this proves that everything is still how it should be - or better - PRs are merged. If you didn't try enola, check it out github.com/enola-labs/enola