Philip Bontrager retweeted
"opus-5.5 is a coding superintelligence on par with world class experts and bad code is a user's skill issue at this point" is an increasingly popular take being echoed around. so, what are we still doing here?
i've been coding through various robotics ML projects for the past ~3 years. everything ranging from throwaway r&d codebases during early conceptualization to stable and optimized codebases during later productionization. i'm by admittedly by no means a "world class expert" in coding, and since gpt-4 was released just as i was getting interned in what is my first full-time engineering job, i've consistently leveraged the capabilities of these models and evolved alongside them every step of the way from the humble days of gpt-4 to the undeniably cracked opus-5.5 and on.
now the interesting question that comes to mind is that since i was born too late to independently develop deep practical expertise in any engineering subfield that i can then capitalize on to confidently supervise and steer those models, what do i even contribute to any of my AI-assisted projects? am i really just a middle-manager between upstream management and downstream coding agents? well, i don't think so, or at least not yet.
while modern agents definitely don't lack engineering know-how and a versatile technical skillset, i've always found, and do continue to find, that they do lack the kinds of natural commonsense that we humans take for granted. models remain unbelievably shortsighted, inefficient, and autistically oblivious to various unverbalized expectations around outcomes. despite superhuman coding skills, even the legendary opus-5.5 finds it impossible to hold back from diving head-on into unsustainably hacky solutions, paranoid defensive coding patterns, confused design choices with utter disregard to obvious long-term trade-offs, and above all, painfully bad taste decisions around high-level project directions. i am yet to take my hands off the steering wheel and not find myself frustratingly interrupting to re-steer soon after.
the thing about this particular set of cognitive blindspots and shortcomings that i find especially unique is how orthogonal they seem to be relative to all other predictable improvements in capability. since the early days of gpt-4, i don't find it to be the case that models have improved much on minimalism-by-default, on reframing problems instead of stubbornly hacking through them, or on effectively leveraging theory of mind to satisfy general expectations in regards to writing style be it code, documentation, or anything involving external readers. the degree to which i find myself putting in constant effort to verbalize obvious human intuitions into explicit and persistent notes and skills to auto-steer agents away from their alien (not the intelligent kind) basins leaves me disillusioned with their independent judgement to this day.
i think our reward functions are incentivizing the wrong priorities when attempting long-running agentic work. i think our modeling algorithms are failing to reliably internalize fundamental human biases, such as the deep desire for efficiency in all aspects of life (aka "working smarter, not harder"). i think the capacity to generate beautiful original ideas and reason about next steps at a high level remains largely underoptimized across the current frontier. i think we don't yet have AGI in the sense that we can expect from it the basic level of sane, well-calibrated intuitions we'd expect from a competent junior engineer, let alone a senior domain expert, despite obviously superhuman technical knowledge and skills.
tl;dr: don't leave the driver's seat just yet. impressive lane assist and auto-parking is where we're currently at.
the coding agent haters are getting dunning-kruger'd so hard right now
do you really think that your engineering ability is better than the models at this point?
it is very very likely that fable is better than you in every branch of software
it has been trained on all the code of the internet, it knows almost every trick in the book, all the design patterns of every domain, every single low-level detail, every bit-twiddling hack, it's read every single blog post from every cracked engineer that ever existed
do you really think you can beat it? do you really think you can be more creative than it?
unless you are 99th percentile expert in some niche domain of software, it simply is not possible. sorry.
With models getting larger, it's gotten much more difficult to interactively work with them. I made a distributed Jupyter extension that allows instantiating and interacting with distributed models.
Similar to torchrun, it launches parallel ipython kernels behind a single notebook, executing each cell in parallel in each kernel. It also plugs into the debugger allowing you to switch between ranks you are debugging.
To use it together with Jupyter's MCP, install and run Jupyter lab.
github.com/pbontrager/jupyte…
In previous technological revolutions, the eventual winners were companies who disproportionately benefited from a key input becoming cheap. Cheap coal, cheap steel, cheap oil, cheap electronics, cheap internet. Which companies today most benefit from token pricing going to zero?
The LLM mode definition is written in PyTorch, a symbolic program. These models have been neural symbolic all along 🤯
Philip Bontrager retweeted
The low hanging fruit on harness engineering is insane.
Ontop of that, there's an interesting area of science/engineering on how to best study the effect of harnesses, from post training through eval/inference. Will be a fairly impactful area (in cost savings per performance)
The open question that I think makes this take controversial, is whether decentralizing investment dollars across many companies vs a small handful is good for innovation. In open source software, development is shared. So we benefit from having many eyes on the same thing.
Person says the truth and gets crucified for it 🤷♂️
100% logical that open models are deaccelerationist. They'll squeeze everyone's R&D budget and are a good way to slow things. That's another great reason to support open-weight models
(It's crazy how many bad takes and attacks have been written on these observations)
Since model development is so tightly coupled with compute, we haven’t been able to decentralize model creation yet. So the big question is whether open weights development is subject to the same feedback loops that accelerate innovation, as open source software development.
I feel strongly that this will still hold true, that the free flow of ideas across different groups of people will accelerate innovation instead of slowing it down. If you look at open science as an example, it has a lot of the same structural challenges open LLM development; but benefits from having many participants all trying different ideas.
What this piece says about pure intelligence and its limits in the real world align strongly with my own intuitions. The world is combinatorially complex, which means the only way to understand it is to interact with it which is inherently slow. In my own experience, making changes to any sufficiently complex system has many basically impossible to predict outcomes.
geohot.github.io/blog/jekyll…
Models don’t simply “average out” they’re training data, they learn to match the entire distribution it was trained on. This means the model can be steered towards any part of this distribution. This is what fine tuning does, it updates the model to produce the part of the distribution you want; say as a star developer. And this is before you get to RL which allows the model to discover capabilities outside of the human data.
The best smart router is currently Fable ultracode
We desperately need a smart model router.
1. We’re seeing a model explosion: GPT-5.6, Grok 4.5, Muse Spark 1.1, GLM-5.2, and Fable 5 all launched within the past month.
2. Even for a single model family like GPT-5.6, there're 3 (Sol, Terra, Luna) and 5 reasoning-effort levels.
That is far too many decisions for users to make manually.
The best model should be selected automatically based on the task, latency, quality, and cost.
Work like this is interesting, but ultimately the issue with linear attention is the fact that you can’t know what you need to remember before reading to the full prompt. You need some kind of mechanism where you read the prompt twice.
I think developer tools like Claude Code and Codex and really provided a blueprint for how a consumer assistant should be architected. Server hosted intelligent model with a local harness that has access to local tools and context. This would allow Apple to lean into their local compute advantages while not being tied to any one model provider.
To me it feels like they’re prematurely optimizing for edge models before just making sure that the product is good given the best models. They’re also baking in very high switching costs by having their own custom models before proving they can build SOTA models.
local models from Apple Siri AI are a 3B dense and a 20B total ~1-4B active (adaptive compute!)
for the MoE they use early routing decision to decide once per prompt which experts will be activated for the full model depth.
it seems that the early routing also decides the number of active parameters the model is going to allocate, but no information if it's doing layer selection or expert selection
for the AFM Server they train/serve it with PT (parallel track) parallelism and not EP. you can see PT as an extension of TP but instead of syncing multiple times per layer you do it once every few layers (so this is not exact computation anymore)
this is overall quite similar to previous generation, so i'm wondering what the gemini licensing was about, probably data?
Apple also still has an advantage in their app developer ecosystem. They can define an API for how regular apps can share context to AI assistants and get much better ecosystem adoption of these APIs than their competitors. If they make these even partially available to third party assistants like ChatGPT, they can guarantee AI apps are always best on iOS. It would be the same playbook for why the best way photo and image processing apps were always on iOS.