I love seeing this verbalized. We are pretty much at the point that increased model capability will only have utility to folks that are willing to let go of even more understanding of whatever the model is producing.
The best models can/will produce a year's worth of output that would take several days to weeks to properly understand in the span of an afternoon.
For everyone that still wants to feel like they own the end result, just use the lesser models with less ambitious tasks.
Caveat: I think this mainly applies to coding. I would still like the best models possible to be working on e.g. new drug research to cure our various ailments.
In particular, footnote eight:
> This is not a claim about the future. Perhaps almost all or perhaps even all of the software skills I have will become irrelevant in the near future. But we're not there yet. At the moment, programming skills seem higher leverage than ever before.
> There's something a bit funny about the current moment, where it seems like having the skills that models are replacing makes one much more effective than people who are trying to use models without having those skills. I like Max Bittker's framing that models are very good at counterfeiting and the level of expertise it takes to distinguish a counterfeit from the real thing has been increasing as models improve.
As well as this section fairly at the start:
> As far as I can tell, these problems are problems because people are implicitly carrying around a pre-agentic cost model. Ten years ago, the kind of person who implemented a new compiler because their compiler was slow was the kind of person who started programming a new 3d game engine when they wanted to make an indie game, i.e., the kind of person who never ships anything. Most productive programmers I know still have an aversion to this kind of thing, even though it is now actually reasonable to implement this kind of thing now.
Of course, at the moment everything’s still a bit very much difficult to tell, but “productivity”, at least in applicable areas of work, might really come down to who can let go of the most understanding the easiest? Incredibly thought-provoking stuff.
This is Bainbridge's 1982 paper Ironies of Automation restated.
https://en.wikipedia.org/wiki/Ironies_of_Automation
https://ckrybus.com/static/papers/Bainbridge_1983_Automatica...
> This paper suggests that the increased interest in human factors among engineers reflects the irony that the more advanced a control system is, so the more crucial may be the contribution of the human operator
Makes sense.
Which makes those interfaces the most critical parts of the system.
Model produced code compiles the same as human produced code. My kids would call this “copium”.
Then there is these other programmers who built their own operating systems even though their OS professors are claiming publicly their design sucks, who built a local database from scratch in C because his use case did not need the client/server stuff but just all the other relational goodies, or who built video streaming/transcoding software from scratch just because they have ideas and then the world changes around their ambitions.
I think it is not enough to be ambitious or have the technical ability if you want to build something for others to use. You definitely need deep commitment but also perseverance in the face of social adversity. I think this is what saddens people with automation of the technical aspects of programming. It leaves the more psychological aspects as challenges which are not easy to face all the time.
Great point. Coding used to be a natural forcing function for prioritization of features. When coding is basically “free” you have to do the harder job of saying no to things, deciding exactly what to build, etc…
I would say, yes!
Yes, if its less and good. Yes.
> perseverance in the face of social adversity
Sometimes you're Fabrice Bellard, sometimes you're Terry Davis. That is, for almost any idea you'll find random detractors, but some ideas really are generally useful and some are completely nuts. One of the negative externalities of AI is that bystanders are confronted with a lot more cases where they have to work out which one this thing is.
I can certainly say every skill I have is because I sat there for hours grinding low level tasks to get something new. Will people still have that motivation?? We might be entering the tech dark ages
That is, genuinely, crazy talk. That is what addicts would say.
But it is intellectual-washed to sound like the most reasonable thing to say.
It is not. And there is nothing thought-provoking about the mere act of doing heroin.
There might be something in the system and mechanics that lead to people getting the idea to do that, though.
___
We can engage with these ideas and there might be some merit to them, but not with this frame. This frame will (not hyperbole) kill us all.
People will die due to (poorly-engineered) systems understood by no one, failing in completely incoherent and unexpected ways - and those people may be you or your loved ones.
I, well, agree. Of course the statement is nuts, especially so once you consider issues like vendor lock-in, the oncoming atrophy of one’s own skills, etc. But if you define “productivity” as short- to medium-term results only, is it really that inaccurate?
The problem is that it still uses the and benefits of the legitimacy of the word of "productivity" there. Meaning that it is harmful to us to put it that way.
Maybe it’d be interesting to see what could be achieved responsibly by motivated people with models in a world without “feature pressure”/competitive stress (which’d include e.g. no security race and infinite attackers and exploits to keep up with)?
I’ll probably have to think about it some more, but a) I think I’m inclined to take my statement above back, in that I/we should definitely still aim for understanding, even if it’s not the most “productive” thing to do, and b) I don’t know what’s a “realist” way forward, i.e. not completely denying LLMs are capable tools and never using them, but still understanding what comes out when you do use them. Seems rather difficult to balance the way the current iteration of tools is designed to be used.
People demonstrably said the same thing about the inventions of... Writing! and Mechanical/Digital Calculators! Yet here we are!
Time is a flat circle!
I suppose it depends on the “applicable areas of work” but I would argue the opposite. As in all things, when you level the playing field, in order to stand out you have to know the rules to understand how to break them.
Imagine a fully autonomous Ad agency that creates unique ad campaigns for companies. And have it controlled by someone who “let go of the most understanding.” For instance, maybe a business minded person with excellent technical skills, but doesn’t know how to copy-write and has no visual design training.
Even with the strides in AI advancement, this is an impossibility and I’d argue it won’t happen within the next five years even. You need human agency, and you need human workers who are experts in their field.
While this iteration of technology certainly _feels_ different, it seems like for now we're still coming down to "it's useful to know how to build a car, but when you need to put food on the table, know how to fix it and make it do what you need it to do".
not caring about the output ~ more output
… which may or may not be useful in the long term, but definitely does help a shorter-term “productivity” measure.
On the other hand though, there’s a pretty damning example against my case here: Say a manager of individual contributors – which is what the situation of an individual with sufficiently smart models and tooling may almost boil down to – didn’t directly care about the output anymore. We’d most likely call that being unhinged/unproductive, too…
It was late at night and I primarily wanted to link the somewhat relevant article, maybe I should have left everyone to reach their own conclusions instead of adding some poorly-worded unfinished thoughts. :x
I cannot see it being a good thing to "let go" of understanding. If you don't understanding anything, then why would anyone keep you around? An example hypothetical situation is, if I have a colleague that outputs a bunch of productive things, but they don't understand it, and I do, then of what use are they? I have LLMs too and also have the understanding.
It isn't clear to me why people are so comfortable with letting go of understanding. And it's a bit bizarre because it always seems to be framed as "you're going to get left behind if you care about understanding". I also never hear or read anyone who has any real and deep experience say these things.
To your point about becoming redundant without understanding, not understanding things will be a problem when an issue arises and the other person isnt able to handle it the right way. However, if llm can address the issue, does the fact that they did not understand the details really matter? From the perspective of a person who gets to decide who gets fired, would they fire someone who is productive but sometimes introduces bugs that they quickly address or would they fire someone who is comparatively slow but rarely introduces bugs? The answer probably depends on the domain, and how costly a bug can be. For most of us, the work is not so critical that you cannot afford bugs. So, productivity wins.
If you are suggesting humans before LLMs rarely introduced bugs, you probably haven’t got the latest models to review your old code. It’s shocking how many bugs we had before but couldn’t see!
You're smart, and you know what can go wrong, so you use models slowly, and you check their work. Your bet is that it will make a bad mistake.
Your coworker is reckless, they don't know or care what can go wrong, so they use models quickly. Their bet is that the model won't make a bad mistake.
If the model doesn't make a bad mistake, your coworker is creating more value to your employer, and your employer doesn't really care if you understand the code. They just want something that works.
Over the last year, it sure seems like models are making less mistakes, so the expectations on the bets are changing too.
For instance: we have calculators. We’ve had them for decades in their “current” form more or less. They are readily accessible and far more reliable than LLM’s - if you a problem 1000 times it’ll be right 1000 times, the rare bug or glitch notwithstanding. But we still teach people basic arithmetic. We teach times tables. We didn’t just offload basic math.
I agree we don’t need to know assembly to use a computer but there is a balance here and companies do not care about a balance.
For software engineering I don't know the right balance.
I've used the "we mostly stopped caring about machine code generated by a compiler; maybe we should stop caring about LLM-generated code as well?" analogy myself.
But even I have to admit there's two big holes in that analogy: if I use a compiler to turn C into machine code... (a) compiler bugs are orders of magnitude rarer than LLM-generated bugs (b) my C code remains the source of truth, or at least source of intent. Whereas with LLM-generated vibecode, there's no source of truth, just an ever-evolving mudball. I (kinda?) like the ideas of "documentation as source of truth" and/or "tests as source of truth" ideas, but I don't think we're nearly at the point of viability.
TL;DR yeah I think actual understanding of what LLMs produce is gonna be important for the forseeable future
Like humans, LLMs get into a place where fixing one thing breaks three others. They compensate partially with insanely big test suites, but now fixing one thing breaks three others, and 57 different specs, half of which also need to be updated.
I think roughly three outcomes are possible.
1. LLMs get fast/good/cheap enough that this just doesn't matter. Your 50M LOC monolith is a mess? Yeah, it still takes more effort for the LLM -- but this just means it costs 5 additional seconds and $0.03 instead of $0.02 to ship a new feature.
2. Stepping away from the "code as source of truth" paradigm. What if specs/docs were the vetted source of truth, and we just regenerate the whole 50M LOC monolith every time somebody makes a change, just like we rebuild binaries from C today whenever there's a change? (This probably requires some of the LLM advances from #1. Also, at this point, perhaps we should just skip the intermediate language and generate ASM -- what purpose is human readable source code serving at that point?)
3. Status quo as I see it -- human engineers overseeing projects, both guiding AI and being accelerated by it.
I think #2 is probably the... most ideal future? Though, of course, if we switch to that paradigm, the source-of-truth docs will have to be very thorough and structured, and will probably resemble a programming language of sorts themselves, except describing intents instead of operations.
You see cashiers summing groceries? Salary calculations on paper? Tax, inventory, accounting, you name it? Nobody does any of it by hand.
We most definitely offloaded basic math.
I imagine you and most of your peers can calculate a tip or at least approximate it without pulling out their phones yes?
How many of your friends and extended family can write hello-world or fizzbuzz in any programming language at all? Should they be allowed to vibe code apps for themselves? If they get good at vibe coding, should an employer be allowed to pay them for it?
To resolve this we should aim for a new intermediate format that is more high level than source code, the generated code is too monotonic to properly review manually. Something like requirements -> detailed specs for llm -> code -> assembly . Then let one agent implement the specs and have another review it. If we stay at the current abstraction level, humans become the major bottleneck.
It really does feel like people have embraced rolling around in the cognitive version of those Wall-E chairs.
Understanding architecture, robustness, the “crumple zones” of a system? I’m all for it.
Taking three days to “understand” how postgres transactions work under the hood for your generic SaaS? Uh..
I have seen a lot(!) of the last type of “understanding” and it’s infuriating. The same types will often not understand the business, its stakeholders, the architectural constraints beyond the technical, etc. Understanding takes many forms.
You do have to keep a sense of when it did the wrong thing and how that was a valid interpretation of what you asked and how to better specify what you want. But that's how it really just shows you the gaps in your own understanding of a problem.
Also I think there's huge differences to the kinds of tasks and workloads people are throwing at it, leading to wildly different perspectives, but everyone's talking about the same "Fable".
This right here. Humans are really prone to over indexing on a handful of personal experiences vs a representative sample. And once someone has formed an opinion, confirmation bias helps cement it, despite evidence to the contrary. Reality is probably somewhere in the middle.
They don’t keep you around, of course. The better these models become, the worse the human job markets get, I’d predict.
I too love to downvote and edit instead of admitting that I'm talking and acting in a way where nobody would want to be my coworker anyways. Where exactly are you demonstrating that you're doing anything to justify being kept around if that's such a big concern for you?
Is it just me or is this analogy completely missing the point of why we care about detecting counterfeits in the first place? Poor craftsmanship of all things is not really the reason counterfeiting is illegal!
I mean, the answer is obvious: the Luddites were right, these tools (not just LLMs but private property, copyright, and capitalist mechanisms) are only tolerated to exist so long as they serve the needs of Capital, but the hypocrisy still frustrates me.
Great thought. Question is, can those who do the tolerating (in the interest of capital) even effectively prohibit/prevent access after a certain point, especially now that the cat is not just underway, but well out of the bag?
Assuming the current trajectory of a yearly factor of 10–100 in size/cost reduction [0] holds up, won’t the technology just become cheap enough to be functionally available to everyone?
Thinking about just the domain of the stock market only: getting a "win" on it means getting a leg up on everyone else participating. Best example I can think of of a pure zero sum intelligence contest. Programming UIs might have a point where you just can't get smarter at it, but in an intelligence contest like a stock market, I don't think there's a ceiling.
In "Accelerando" this was covered by the invention of "Economics 2.0." AI agents also got into a lot of lawfare in that book.
The most rigorous "private property advocates" don't recognize intellectual property as a legitimate form of property in the first place: private property is a natural phenomenon that emerges as a solution to the problem of physical things being inherently exclusive in possession and use, and IP is a creation of positive law meant to artificially apply the methods for solving that problem to another, unrelated question that isn't part of the same problem domain.
> I mean, the answer is obvious: the Luddites were right, these tools (not just LLMs but private property, copyright, and capitalist mechanisms) are only tolerated to exist so long as they serve the needs of Capital, but the hypocrisy still frustrates me.
Abstract concepts don't have "needs", and no one is currently in a position to tolerate or not tolerate anything -- no one in particular is actually in control over anyone else's activities. The cat's out of the bag, and no one has any capacity to put it back in.
Maggie Appleton suggests some ways that AI models could do a better job of communicating about artifacts to people in https://maggieappleton.com/planning-agents, although she's focused on the use case of the person deciding what changes in the artifact to request from the model.
Someone found a better URL for that (Fabrice Bellard) story (16 points, 10 days later) https://news.ycombinator.com/item?id=49996383
Unless there was another one you later deleted?
Most submissions never receive any upvotes. They’re all “wasted” like that, even if not flagged.
You will find a lot of articles from before LLMs about not delegating understanding of your core system or business. You could say that the software is not your core business so you don't have to understand it. But if the software is any good then it should be taking care of a large part of the business. So software is your business and you shouldn't delegate understanding it.
https://www.tomshardware.com/speakers/in-a-blind-test-audiop...
ME: This piece of code is incorrect, was it intentional?
Fable: No, it wasn't deliberate, but this is also a hole and it's on me.
Where is the ambition you're talking about? I cannot squeeze anything that looks like production code from this benchmark champions
There are many ambitious things I have tried to work with Opus 4.8 and Opus 5.5 on, and it just can't get there. It always falls back to some tried and true method or some valley that it gets stuck in. In those times, it was impossible to push it forward into more creative and exploratory thinking based upon my relatively advanced pushes and contextualizing. So I took the commenter's position that Fable 5.2 will respond better to that type of pushing. But that type of pushing actually means you know more than those who are happy enough using the lower models. So that seems like the opposite of what you said.
One important constraint is this topic of intent (also referred to as alignment). Specifically, when a user requests a feature or change, there is MOUNTAINS of implied context and intent in their comment. Some cultural, religious, social, economic, base on work and personal experience, their use cases, their values, what they intend to get done, etc. Every time these models get smarter, they get a little better at understanding this context. It's combination of reasons. Some of it is parametric. Some is inferred. Some is about selecting the right data to examine and research. As these models get smarter, I spend less time time iterating and educating the model. They reach the intent faster and better.
From what I hear and experience, this is also true in the coding space. LLMs are basically another abstraction level on top of formal languages, which sit on top of compilers and machine code and etched instructions. Smaller and dumber models require a lot more hand holding to achieve the same results. They're less capable of inferring the gaps. Less capable of extrapolating potential negative outcomes of the change they're making. Less/less useful parametric knowledge. Less capable of selecting the right data to use to make the right decisions. They do what they're told.
This has been less of an issue for coders who religiously document, understand the codebase and architecture intimately, and demand to be kept in the loop on every change. So seniors often do not see the utility of smarter models. They know exactly what they want, how to ask, the context to provide, and how to assess if the change worked as expected. The utility is for the 99.9999% of the world which is not a senior developer.
However, your statement that there are only 8300 senior developers in the world does not seem correct to me. That seems like an unreasonably high bar for that title.
I think the issue is fairly fundamental, perhaps because of tuning, perhaps even beyond what they are tuned or trained on, because the bulk of what they can go find and ground into seems to drag them heavily toward implicit biases that split around categories I can’t quite discern. The category boundaries sometimes look like academic fields, but sometimes they seem like more fundamental attractors.
Given that reading someone else's code is slower than understanding your own code, doesn't that basically cover everyone that adopted coding agents?
This is appalling. Are you really really going to trust a YEAR's output from a machine? Are you going to read and understand all that? Will you be able to maintain and extend it to your will? I truly doubt that. Drugs do harm and are hard to quit. Good luck.
Having run teams, as much as I love getting into the details of code I care about, in the 30+ years I've been in this business, I've only ever even seen a tiny proportion of the code my teams rely on.
And the non-technical people in these businesses will have seen none of it.
They all take it on a combination of trust and verification of outcomes that the code does what the developers claim it does.
Increasingly we're getting to a point where the output from these machines are more trustworthy than an increasing proportion of human developers, and more importantly: Increasingly often good enough.
Especially as more and more of the code becomes throwaway.
I have a side-project that is profitable, and that is profitable only because I haven't needed to spend time reading the code. If the code turns out to be unmaintainable? Doesn't matter - it's so cheap code that it is reasonable to just throw it away, and start over based on the lessons learned. It enabled me to take an opportunity to profit I wouldn't have been able to profit from if I had to set aside time I didn't have, so even if it was to totally fail in the future as a result of issues with that code it doesn't matter.
As the cost of good enough code falls towards zero, how we think about which code matters and how much we need to understand it will fundamentally change.
Increasingly, a lot of code is even just part of a conversation with an agent to me. It's throwaway, for the duration of a session. Who cares if it lives on?
I don't trust or need to trust most of the code I build any more. I trust the measurable outputs. The verification pipelines we build. The feedback mechanisms we build. Those I need to read and understand.
That's no difference than when working with a team. The only thing that is different is failure rates. And at this point, for some thing the machine failure rates are still higher, for others it is lower.
It ran like a dog. Few nights of running Fable (later Opus 5.5) with a 7 strong team of DeepSeek v4.1 Flash 1017 (don't mistake it with 0731 that is crap) and llama was running 10x faster and vllm was running even faster when before it would not work at all.
I've run similarity and needle tests and the results are exactly the same content wise. But 10x faster. I've relied on this for a month now and I'm pretty happy with how it runs.
Do I now need to learn CUDA Kernel programming to understand how it was done? I don't think so. It's for my personal use. Not for a paying client so no warranty is perfectly fine.
But I also use a lot of AI at work in an I dusty where people may die if the code is buggy. So I absolutely verify and understand everything.
There is a middle ground too. Understanding the architecture.
For example I used a bunch of DeepSeek models supervised by Qwen to build adaptive-acl. A pi coding agent plugin that deterministicly checks if every tool used by an ai during an agentic session matches user intent to give permissions for those actions (reading/writing data, network access etc), as a part of this plugin I run an llm, a classifier that runs over user's prompts and extracts these permission grants then saving them in a format deterministic layer can process.
The design includes massive number of assumptions and compromises. For example, if a user allows writing this implies permission to delete and reading if what was written etc.
The thing also includes over 4 thousand actual instances of tool use preceded by "permissions talk" from my live sessions and that whole collection can be run to test for regression etc.
At some point during one night the AI had a regression and decided the best way to resolve it would be to add regex based language processing elements to the deterministic layer (a huge no no, this has to work regardless of the user speak English or Swahili, also regexing natural language is a disaster waiting to happen).
I knew enough about the architecture to notice that and burn it out with a hot iron.
That is the problem with AI. It sometimes solves problems the easiest possible way causing massive issues for later. So if one uses it for important stuff it is good to understand the architecture and the plan of what it is going to build at the very least.
Just wondering, what harness architecture to you use for this, if you don't mind sharing? Is it a parent session running opus and it writes worker briefs and spawns subagents ond demand? Or something else like the workers having shared context, etc?
I'm currently running this cheap setup where deepseek will be the "main" session but it has to submit proposals to a stronger "oracle/reviewer" model through a custom tool. So deepseek scouts the code and comes up with its own solutions but the oracle on the tool can steer it with it's higher "taste" (omniscience benchmark, low slop benchmark).
I've just started using it and I like the results so far but it's most likely suboptimal so I'm still iterating as usage data piles up.
I’ve been shifting away from using more traditional GenAI models in favor of just giving LLMs access to a custom drawing language (LOGO-like) to generate imagery and its been going shockingly well - Opus 5.5 in particular.
I put together a simple LLM driven skill that creates old adventure game (EGA) environments from simple pencil sketches and it works really well. And being procedural, they're much easier to make surgical changes to without degradation.
It has three different modes:
• You can simply describe a picture, and it'll automatically generate an image using procedural code.
https://kq-styles.specr.net/#/scene/custom/elk-valley
• You can ask it to paint over an existing image. That's what those examples show, like me creating EGA-style equivalents of various scenes from the original Myst.
https://kq-styles.specr.net/#/scene/myst/r01-c00
• The last way is to give it a rough pencil sketch. It's the mode I use the most since it's very valuable when building an adventure game to position objects in a room.
So instead for each room that needed to be rendered they just saved a series of vector instructions that would re-render it in real time. On slower machines, you could actually see the rooms pop in piece by piece. I wanted to kind of approximate that same aesthetic because it's just super cool!
https://github.com/scpedicini/agi-stylist
I just wanted something relatively human readable so after an LLM did a first pass on an image, I could easily make changes to it.
https://bbcmicro.co.uk/game.php?id=89
I think the approach of using simple procedural vector graphics was relatively common back in the days when you had to optimize for either disk space or speed. Sierra's creators talked about how they opted for procedural graphics to fit their earliest games on the old 80 KB floppies.
Then I just guided it to produce a procedural variant specialized in creating new EGA-style scenes for use in creating old-school point-and-click adventure game.
https://people.eecs.berkeley.edu/~bh/usermanual
It's all open source.
Not just "iterate on this XGBoost model" but actually looking at a problem and designing and carrying out a short-term R&D program including probability modeling, model fitting diagnostics, how to respond to various kinds of results, how to interpret/reason about what it finds, etc. That's really where I saw all the models perform poorly, and where I saw the first big step increase from Opus 5 (pre-5.5) to Fable. But then Opus 5.5 came out and I haven't needed Fable since.
Mind you, I'm doing slightly different work (and I'm very much "in the loop" still) than when I performed that side-by-side test. But it's really amazing what Opus 5.5 can do. I now have a powerful data science AI assistant that not only can write any script I need it to (including some scripts I didn't even realize I needed), and it has an encyclopedic knowledge of everything ever, and it constantly checks me on oversights, it handily derives expressions and clever model reparameterizations that aid, it has great insight into model behavior, and it has an amazing ability come up with ad-hoc experiments and tests that would have taken me 2x as long to even think of (let alone implement by hand).
It's not at the scared-to-lose-my-job phase yet, but it's become a tremendous force multiplier for a smaller data team.
I wish I had a bigger N so I could rely on that experience a bit more, but it sure does feel like I'm not really contributing anything in terms of "Data Science expertise" in my own research right now.
Based on the other comment it sounds like maybe I need to give Fable another chance, and then I suppose I won't have to steer anything at all. But at the end of the day I am not paid to be a meat proxy, I am paid to deliver things for the business that employs me, and the things I deliver are my responsibility, not Anthropic's.
So I say, embrace AI as a learning tool, let students use it to bypass programming on assignments where the programming is of secondary importance, require oral defense/presentation for projects, make homework worth a much smaller fraction of final grade, and make all of your tests in-class and hand-written.
The reality is that the entire nature of education has to change to account for cheating becoming essentially free and virtually impossible to detect. Grinding through a problem set in the library is still tremendously important, but it's going to be harder to motivate students to do it without just cheating. Some students are conscientious and will do it anyway. Some won't. The hard part is going to be crafting curricula and exams that separate the two kinds of students. Fortunately you share that problem with just about every other professor in the world right now, so at least you shouldn't feel responsible for solving it all yourself.
Relevant anecdote: I used Wolfram Alpha to cheat on my calculus homework in freshman year, and then I got my butt kicked in the exam and a C final grade that never quite averaged its way out of my GPA. That felt horrible and it was a strong motivating force to get my shit together, but that's only because I'm a fucking nerd and I really cared about learning in school and making a career out of what I learned. On the other hand, I really was struggling with the material, which is why I tried cheating in the first place. Maybe if I had today's AI I could just ask it to help me learn better.
You could! I use it all the time to generate pre-calculus and physics quiz sets for my son to work if he needs extra practice on particular concepts. And that's just scratching the surface.
Getting a kid motivated to do that _for themselves_ rather than just getting the answer and moving on to scrolling short-form video? That's another matter.
I feel like a lot of people are going to put the same faith in their new quantitative superpowers as psychologists did in their 95% confidence intervals [0], and managers did in their “scientific management”/time-and-motion studies, and American political pollsters did in their 2016 presidential prognostications, and Rudder’s OKTrends blog (delightfully) did in calculating the answers to romance [1]…
[0] https://www.psychologytoday.com/us/basics/replication-crisis
i also wonder if they're not losing motivation due to the fact that the llm can race through everything so swiftly
But then I'm someone who hasn't found Opus 5.5 good for much beyond web UIs and related frontend development. I find it more forgetful than GPT-5.6 or 6.1 or Fable, so despite having a 1M context window it gets lost in a big codebase or goes of target. Opus 5.5 doesn't manage agents particularly well IMO.
I'm surrounded by people raving about Opus 5.5 and God only knows why I'm not getting their results.
Fable got right to the point, had cleaner/better responses and reasoning for its conclusions, got less distracted with secondary concerns, and still showed signs of the cleaner writing style compared to Opus, which improved a lot with 5.5 but can still be hard to parse sometimes.
I will keep using Opus for implementation tasks (e.g. building web apps to explore model predictions) but I think I'll try using Fable this week for the real DS stuff. Thanks!
With (obra) superpowers, Fable writes a plan and delegates to Opus which works well. Fable is much better at sorting architecture in a conversation rather than me creating a giant prompt for Opus.
Does the number/frequency of safeguard stops affect the measured speed?
I think I included the Opus 4.8-backoff runs in the speed number and they were on average faster than the actual Fable 5.1 runs, so the speed result might be even bigger if I excluded the Opus 4.8 runs.
What kind of images? I can't imagine getting photorealistic or highly detailed digital art out of LLM writing drawing commands using JavaScript.
Opus - smart execution (most coding, knowledge work)
Sonnet - dumb execution (basic coding, generic text/organization/information tasks)
Haiku - really only reason is lack of auto mode becomes tedious. I only use it indirectly with sub agent delegation for text analysis (summarize web page, document). However, it's quite fast and capable
When you put it like that, it almost resembles having a classroom of kids with different personalities and talents. Some are thoughtful, some creative, some quick in execution. You choose wisely the path each takes and allocate tasks accordingly. Gives me chills to think of it...
Debugging/analysis/small scripts -> Opus
Non software engineering -> Sonnet
The bitter lesson strikes again!
I personally have consistently been disappointed by any artwork/assets created by Fable and Opus, at least compared to Astra and Sol.
All the people claiming "opus 5.5 is just as good" tends to make me think some people only do simple tasks or do not care about correctness or quality.
Have you considered the possibility of the problem being in the way you prompt a model and prepare it's context? I've been pushing myself to using mainly the cheapest models and I see them deliver the same results once we provide enough context or lay out a plan.
Fable made it work correctly in 2 days, it stayed on point, identified the real problems, and gave me clean code that was suitable to merge.
The task was simply to warm the hot path of an app so that latency was not as jittery for some rare, but important, events.
Fable built a reliable repeatable benchmark, disassembled the code to figure out how much could actually fit in L1, made tactical changes to eliminate bloat, and reliably achieved high coverage with minimal edits.
Opus just tried a bunch of random ideas without a plan, hoping to find something that sticks.
Sounds to me that you're describing a model trying to navigate ambiguity.
> Fable made it work correctly in 2 days, it stayed on point, identified the real problems, and gave me clean code that was suitable to merge.
If the problem lies in identifying the real problem, that sounds like this is a issue in how you setup the problem statement, aka provide context.
I mean, there are many reasons why in the early days of LLMs and AI code assistants we saw some people using the likes of gpt4.0 to enable software factories while others swore the models were unusable.
Your argument that holding the model's hand and telling it what to do and how to achieve the task would make it perform better is ridiculous. It's equivalent to not only giving it the answer to the problem, but also staying all day watching it while it re-derives the solution is correct, making it not only redundant but a waste of time and money.
I remember after a day it made me write in the handoff a hard lesson it learnt after burning 500 dollars of tokens: warming up a synthetic path other than the one the benchmark takes does not meaningfully decrease cache misses. No shit Sherlock, 500 bucks well spent.
It's just literally much dumber than Fable is, which is my argument. I'm not saying it's not usable, I'm saying the difference is quite obvious.
In the biz we call that "getting soaked".
But overall, a good release.