mulmboy

It's not guesswork. I find it interesting to read comments like the one you're replying to as they echo my own thinking that I've arrived at through my own independent experiences. I'm mindful of confirmation bias though. I've also flagged the submission, as I do for all similar obvious slop articles.

People are usually surprised to hear that polars can be slower for fairly pedestrian operations, especially with smaller datasets. For example take a 5000 x 3 dataframe of float64 and sort by one column and you'll find polars takes about 2.5x as long. If you set POLARS_MAX_THREADS to 1 then it's faster. Though this all depends on the machine. Polars tends to shine with larger datasets or where it can heavily take advantage of query planning.

Don't skip your profiling

Yes I think his stance works well for established contributors who have a reputation. For infrequent contributors, with no rep, it's a large liability to try to figure out if their plausible-at-a-glance work is actually slop. Such a liability with uncertain ROI hence the sentiment in OSS frequently banning or at least heavily policing AI usage

What I'm trying to get at is if a PR comes in that looks decent at a glance, well in the past that was a strong signal and now it's not. But you can fall back on the relationship you have with the author. Trust , reputation. In OSS often you have no relationship with the author (of course ex established contributors or people who have well established public reputation). Whereas in a typical workplace you will quickly establish a relationship with those you work with

A good middle ground is to have a large PR open for reference, and then split sections of it out into separate PRs. This way you get nice reviewable chunks while also having the broader context.

This is similar to stacked PRs except that it's much easier to tweak things as you split them out without rebase shenanigans although of course if you tweak too much it kind of defeats the point of the whole thing.

A nice thing about this is that you can put the large PR up while it's still very draft for conceptual review (socialisatuon etc etc) while you work on splitting out and polishing parts of it.

Yes this. As an author I see it as my responsibility to socialise my work early and get buy in from reviewers.

The more I think about PR review, which I've been doing a lot lately thanks to AI, the more I see it as social in nature. Built on trust and reputation. It's no wonder OSS is tending to ban AI contributions - they don't have trust and reputation to fall back on as a heuristic.

I went to build an open source app from GitHub and was pretty surprised that it requires Xcode and that Xcode can't really be installed without an apple id. I do not want to make one and I certainly will not sign my computer into one.

I did end up somehow installing Xcode via some shady download and was on my way. But the whole ordeal left a very sour taste.

Very difficult to take seriously when the entire site appears to be AI-written.

There's a cluster of issues like comments like "use a set instead of ..." after changing something which will just confuse people in the future. Or comments referring to irrelevant details of the planning/implementation process.

It's as though the machine can't separate the chat and planning docs from the code itself and so they meld into each other. As though it can't fully grasp that the code will outlive the current session by years.

Anyway I find a checklist approach works well to sort this out. I don't consider looking at machine generated code until after a checklist covering all this sort of stuff has been applied. My checklist approach currently has about 50 items which I have the machine apply by splitting it up across about 20 subagents. Pretty silly but it seriously improves the first-pass quality vs only a few subagents. I find this checklist can effectively eliminate words like "genuine" and "landed" from the code too. Eliminates vague and made up terminology. Makes it less nauseating

There are a few hints in the doc around this

> Importantly, we find that when used in an interactive, synchronous, “hands-on-keyboard” pattern, the benefits of the model were less clear. When used in this fashion, some users perceived Mythos Preview as too slow and did not realize as much value. Autonomous, long-running agent harnesses better elicited the model’s coding capabilities. (p201)

^^ From the surrounding context, this could just be because the model tends to do a lot of work in the background which naturally takes time.

> Terminal-Bench 2.0 timeouts get quite restrictive at times, especially with thinking models, which risks hiding real capabilities jumps behind seemingly uncorrelated confounders like sampling speed. Moreover, some Terminal-Bench 2.0 tasks have ambiguities and limited resource specs that don’t properly allow agents to explore the full solution space — both being currently addressed by the maintainers in the 2.1 update. To exclusively measure agentic coding capabilities net of the confounders, we also ran Terminal-Bench with the latest 2.1 fixes available on GitHub, while increasing the timeout limits to 4 hours (roughly four times the 2.0 baseline). This brought the mean reward to 92.1%. (p188)

> ...Mythos Preview represents only a modest accuracy improvement over our best Claude Opus 4.6 score (86.9% vs. 83.7%). However, the model achieves this score with a considerably smaller token footprint: the best Mythos Preview result uses 4.9× fewer tokens per task than Opus 4.6 (226k vs. 1.11M tokens per task). (p191)

What I'm saying is that a corporate or professional environment can make people communicate in weird ways due to various incentives. Reading into people's communication is an important skill in these kinds of environments, and looking superficially at their words can be misleading.

People more often say that to save face by implying the issue you identified would be reasonable for the author to miss because it's subtle or tricky or whatever. It's often a proxy for embarrassment

Because it's a good heuristic for a functional and resilient team. People don't usually means it literally, more like "if I disappeared it should be pretty painless for the team to continue along for a month or so and to find and onboard a replacement".

LLMs aren't like you or me. They can comprehend large quantities of code quickly and piece things together easily from scattered fragments. so go to reference etc become much less important. Of course though things change as the number of usages of a symbol becomes large but in most cases the LLM can just make perfect sense of things via grep.

To provide it access to refactoring as a tool also risks confusing it via too many tools.

It's the same reason that waffling for a few minutes via speech to text with tangents and corrections and chaos is just about as good as a carefully written prompt for coding agents.

I'm well ware that they can be sycophantic, and I structure things to avoid that like asking "what do you think of this problem" and seeing the idea fall out rather than providing anything that would suggest it. In one of these two cases it took an idea that I had inkling of, fleshed it out, and expanded it to be much better than I had.

And I'm not bragging. I'm expressing awe, and humility that I am finding a machine can match me on things that I find quite difficult. Maybe those things aren't so difficult after all.

By steering I mean more steering to flesh out the context of the problem and to find relevant code and perform domain-specific research. Not steering toward a specific solution.