Fair, the important distinction is agent-agnostic rather than open-source. There are other risks to using a closed source editor but those are mostly orthogonal to this discussion.
I was surprised people were so willing to jump to closed source IDEs just for access to coding agents. The trade-off you pay for tight integration between the IDE and the coding agent is lock-in because the barrier to switching IDEs is nontrivial.
Your coding environment stands a lower chance of disruption when you use an open source IDE with a CLI agent. Yes it's slightly annoying to separate the agent from the IDE but the benefit is that it's much easier to switch between Claude Code, Codex, Gemini CLI (now antigravity CLI), etc which means you can more easily benefit from pricing and coding performance differences which seem to change monthly.
Stealthily degrade the model or stealthily constrain the model with a tighter harness? These coding tools like Claude Code were created to overcome the shortcomings of last year's models. Models have gotten better but the harnesses have not been rebuilt from scratch to reflect improved planning and tool use inherent to newer models.
I do wonder how much all the engineering put into these coding tools may actually in some cases degrade coding performance relative to simpler instructions and terminal access. Not to mention that the monthly subscription pricing structure incentivizes building the harness to reduce token use. How much of that token efficiency is to the benefit of the user? Someone needs to be doing research comparing e.g. Claude Code vs generic code assist via API access with some minimal tooling and instructions.
For what it's worth, early statins were originally cleared based only on the evidence that they lower cholesterol without longer term studies showing a reduction in mortality. Of course there is now plenty of evidence showing statins improve overall endpoints.
Nor is that inequality an oddity at all. If you were to think NaN should equal NaN, that thought would probably stem from the belief that NaN is a singular entity which is a misunderstanding of its purpose. NaN rather signifies a specific number that is not representable as a floating point. Two specific numbers that cannot be represented are not necessarily equal because they may have resulted from different calculations!
I'll add that, if I recall correctly, in R, the statement NaN == NaN evaluates to NA which basicall means "it is not known whether these numbers equal each other" which is a more reasonable result than False.
I'd argue the opposite is true for anyone who has studied statistics which is largely built on Instrumentalism (think George Box: 'All models are wrong, but some are useful') and Popperian falsification (Null Hypothesis testing). We are absolutely taught to treat models as predictive tools rather than metaphysical truths.
> Three physicians independently assigned gold-standard triage levels based on cited clinical guidelines and clinical expertise, with high inter-rater agreement
I don't understand this reasoning. Randomizing people to AI vs standard of care is expensive and risky. Checking whether the AI can pass hypothetical scenarios seems like a perfectly reasonable approach to researching the safety of these models before running a clinical trial.
> R is perhaps the closest, because it has data.frame as a 'first class citizen', but most people don't seem to use it, and use e.g. tibbles from dplyr instead.
Everyone in R uses data.frame because tibble (and data.table) inherits from data.frame. This means that "first class" (base R) functions work directly on tibble/data.table. It also makes it trivial to convert between tibble, data.table, and data.frames.
Gptel has been working great for me. I'd be interested in checking this out but I only have so much time to set up and test new tools. What features would make it worthwhile to switch from gptel?