>In my research and tests simply taking the change in the number of LOCs has been a surprisingly effective metric for sloppiness, with the ironic caveat that if we started optimizing for it, it would cease to be a meaningful measure.
This matches my experience. Before working on an issue, I ask the LLM to estimate net LOCs at the final PR based on the scope. It works well, and review steps do flag inconsistencies. But as the OP mentioned, if you turn this into a hard metric vs "design smell", you can see LLMs code-golfing for oneliners.
I've had some success with tokens as a measure of complexity instead of number of lines, but should be combined with additional rules, e.g. disallowing lambdas, exec, eval, compile, __import__ and complex list comprehensions for Python. Fortunately, Python's "ast" module makes this quite easy.
I'm thinking of switching to Grok on Cursor (purely for $$ reasons). But Opus >= 4.8 has been fantastic; it's hard to leave, even just to dabble with other models.
Codex 5.6 sol is arguably superior to Claude, albeit very close. They're functionally indistinguishable to me, but if you're concerned about $$, Codex gives you much, much more bang for your buck.
For a personal project I’ve been piloting Spec driven development (SDD), (it’s contagious!), using Cursor and EARS statements. The strategy has been to use the frontier model to write the spec and a lessor model to write the tests and code and the frontier model to write critiquing prompts until it has nothing left to say. For my particular project there are two programs (or in human speak phases), where each program is broken up into milestones which are then comprised of a series of tasks. I experimented a lot with different models as the reviewer / spec model and the implementor model. Kimi 3 was super expensive as spec model and grok and OpenAI models always got something wrong egregiously. The Opus line of models have been the only ones to really grasp the project and I feel write great specs. Because I use cursor I settled on using groc for test routing and code implementation. I’m not sure if this is the most efficient method but I believe it’s building a large project solidly
In my experience Grok 4.5 codes at Opus 4.8 level, and being much faster as cheaper, I can just ask it to do self-review and the final reviewed code is _better_ than Opus 4.8 for the same time/budget.
But Opus 5/4.8 was better for non-code architecture discussions and general intelligence. However, for the cost, I'd use GPT 5.6 Sol and get much better results. Interestingly, Sol is not great for coding - slow and overengineer stuff if you're not explicit.
My go-to workflow was Sol for planning and Grok for building. But my in my first tests with Grok 4.6, I found it quite good and I'll start using it for both; assuming it's as good at is shows at benchmarks it's unbeatable at cost/time.
I like Grok, but I don't think that it's quite Fable-tier. It's good, but I think the position that it occupies on the Pareto frontier is a little more toward the "cheap" side and a little less toward the "intelligence" side.
There are decent plugins for the essentials you’d find in other harnesses. Pi shines in opinionated things you won’t find elsewhere.
For instance the XMPP integration someone mentioned allowing agents to talk to each other and to you remotely; or custom extensions to enable workers to be tmux aware; or adding whatever memory system you’d like; and so on
So my wife has gone through all this extra stress to MAYBE catch a cancerous tumor (28%). That’s assuming it grows large enough to impact her before she dies naturally. And I see that the survival rate of some brain tumors, even if found very early, is very poor (5-10% for some tumors, like glioblastoma).
Lots of “what if’s” here. And for what? All i’m arguing is, knowledge is not always actionable, and what’s not actionable can keep you up at night.
The point i’m making is, we should not be trying to pursue a life of 0 risk and perfect decisions. Life is filled with risk (and good and bad luck). That’s just life.
It depends on your personality or worldview. Some people would be much more comfortable lowering their chances of “what ifs” than leaving it all to fate.
i agree with you. If a patient expresses that sentiment to their doctor, they should act accordingly and order the extra screening. At the end of the day it should be a conversation with your provider.
There should definitely be an honest discussion about pros and cons. And not just the physical, but the mental aspect as well.
Just like the opinion would be different if the size didn't change but she embarked in a risky treatment that left her permenantly disabled or dead.
Hindsight is twenty-twenty. If you take the wrong course of action of course you are going to be upset. But that goes for both possible choices. Its not like the choice is ignore vs take some safe but possibly unnessary action. Both choices could kill you.
The simplest approach to whitelisting libraries won't work, since the malicious color parser can just call the whitelisted library.
A different idea: Special stack frames such that while that frame is on the stack, certain syscalls are prohibited. These "sandbox frames" could be enabled by default for most library calls, or even used by developers to handle untrusted user input.
Definitely don’t dismiss it. While there are limitations, it’s already very capable for a number of tasks. Tweaking it to be more effective is skill itself.
really depends on the company. my company cares a lot about security because it's a huge fortune 50 company with sensitive data and a lot of reputation could be lost with a security scandal
This matches my experience. Before working on an issue, I ask the LLM to estimate net LOCs at the final PR based on the scope. It works well, and review steps do flag inconsistencies. But as the OP mentioned, if you turn this into a hard metric vs "design smell", you can see LLMs code-golfing for oneliners.
reply