cjalmeida

You can use structured outputs and validate them against a schema today. I do agree making it a hard constraint instead of best practice for developers closes a whole class of bugs.

Fine tuning small models is not novel. The novelty is large model generalization without fine tuning, at small models cost/latency.

The OP acknowledged they needed to fine tune their model to the training data of the task vs. zero-shot Jev

>Zero-shot vs. Fine-tuning: Out-of-the-box base models score ~0.35 on the typed-decisions benchmark (near random). The 0.766 score is achieved by fine-tuning on the benchmark's train split. Treat Laya as a fast foundation model to specialize, not as an omniscient zero-shot oracle.

This should be way up in the article. Fine tuning is a pain, requiring it for good results put Laya in a whole different category vs Jev

> Tokens are really expensive when we have a LLM

Expensive compared to what? Vs. human writing proofs they're definitely not.

> The context window becomes flooded with proof work

Context management is more art than science, but proofs are unusually good at compactation. Once proved, you can just keep the lemmas, you know,like humans do.

>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.

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.

Fable-like intelligence, beats GPT-5.6-Sol on most benchmarks, cheaper than Kimi K3 on API and quite generous usage on Cursor subscription.

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

One could argue the death toll of WW I and WW II would not be possible without large scale manufacturing of firearms and explosives.

I believe you’d have a very different opinion if the size did change and she had the opportunity to treat it at a very early stage.

It was too complex. Just making system calls require white listing libraries goes a long way of preventing a whole class of exploits.

There’s no reason a color parser, or a date library should require network or file system access.

You know life expectancy in Portugal is higher than in California, right?

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.

100% agree. This is a low quality post both setting unrealistic expectations for a dynamic language and at times straight up making false claims.

Suggesting OOP as a solution is probably the most laughable “solution” though. What does this have to do with error handling and union type inference?

You’d be surprised by the amount of companies handling critical infrastructure that are OK with using PyPI directly