I can't try it since it hasn't appeared in my Codex yet, but this is is necessary from OpenAI in my opinion. Fable is just so much better at understanding broad context. I only use GPT 5.5 for straight forward easy to describe tasks, and it does crush those. But I spend a lot more time steering Codex towards good design on broad concept type tasks, ones that Fable shows sometimes surprising clarity.
I look forward to seeing how it compares once I have access. Not getting tripped by spurious safe guard flags could be an advantage.
> Avoid generic brevity instructions: GPT-5.6 is more sensitive than GPT-5.5 to instructions such as “Be concise,” “Keep it short,” or “Use minimal text.”
I used to go to a barber and if you said "cut it short", he cut it really short.
I've just been carefully reading the code. It is easy to slip into just accepting what comes out to speed things up, but reading the code is important.
I save myself by skimming things like tests, templates, some UI. Anything cosmetic. But I have to read the majority of code that ends up on my back end systems.
I've had mixed results with downgrading on Fable. I was able to do a complete audit of my OAuth implementation without any issue. But when I asked for an OWASP top-ten review of my code base it got through 5 of 6 tasks and tripped in the final summary, which Opus had to finish.
I had one completely random trip when I was investigating some normal code. As far as I can tell a sub-agent ended up reading a file that tripped Fable during a review, but the whole feature was nowhere near anything secure so I don't know what could have caused it.
I also got completely locked out of Fable when working on parts of a subscription system (stripe subs).
But my experience isn't as bad as some peoples. The above maybe covers 15% of my attempted use cases. For the remaining 85% it has chugged along fine, sometimes in code I assumed would trigger it. It really feels random to me when it actually flags.
I'm pointing out how I noticed a particular emotional response when working with LLMs.
I've been an engineering manager in the past and I have tried my best to keep the needs of my team in mind when I am delegating work. I try to consider the person, their goals, motivations, preferences, frustrations. I consider before interrupting them if the minor issue I am bringing up is worth the distraction it might cause them, since switching tasks is a mental load.
But with LLMs, almost none of that matters. They don't have goals, motivations or preferences in the same way people do. I can interrupt it all day and it won't get frustrated or lose motivation.
I think anxiety is a harsher word than I mean, but it is close to the feeling I have when I'm about to deliver bad news to someone. When I'm about to say "you know all that work I asked you to do, I need you to throw it away and restart". And I model in my mind the frustration and demotivation this can cause a person. And then I feel anxious about causing them this frustration.
I have to train myself out of that when instructing LLMs. It doesn't mean I have to avoid moments of joy or appreciation. It means I have to understand LLMs have different needs than people, and I have to work towards those needs.
I feel on the other side of this. Just yesterday I was reviewing some code output from Claude and I realized a change that I had asked for in a previous review step wasn't what I wanted. I had a moment of social anxiety, like I didn't want to bother a coworker with my indecision. But I have to remember, the LLM doesn't care. It doesn't have an ego. It doesn't get annoyed at being asked to redo work.
I still say "please" and "thank you" frequently, but I'm starting to embrace the fact that the LLM doesn't care about grunt work, doesn't care about rework, doesn't care about nitpicking, doesn't have a preference in general. It needs very little more than for me to be completely clear in my instructions.
I agree, but that is the crux of my initial post. There is a ceiling to how quick I can deliver using LLM coding agents which is the speed at which I can write good enough specs.
I feel I'm at the point now where the time the LLM takes to deliver a feature, no matter how big, is nearly inconsequential. Because while it is in the process of delivering the feature, I am writing the next spec, and by the time I finish the spec the agent is waiting for the next feature. And at that point I have to review it's code, give it feedback, review it's fixes, merge, etc. All of the "waiting" is on me. It is basically delivering features as fast as I can write specs and could only get faster if I write specs faster.
It does, but I have to direct it and review it. That means I have to think about it, research it, consider how the new feature or system fits in with the existing feature or system. I have to make decisions on libraries/dependencies. I have to consider how the project will evolve in the next week, month, quarter. I communicate all of that to Claude in an interactive planning session and it outputs a detailed spec, ready for implementation.
All of that thinking, planning, rewriting, etc. takes almost as long as it takes Claude to actually deliver the feature. The big features Claude writes take ~30-45min of uninterrupted coding to deliver (I just checked the last feature was 39m 41s for +1,610/-26). To write that same code would have taken me probably 2 days.
One thesis I am developing is that LLMs have given us a new kind of tradeoff. We can use the intelligence and tremendous speed up that mechanically pumping out basic CRUD code has given and we can either deliver more features or deliver higher quality.
What that means to me is that there is a balance. My belief is that we have to take some of the new power and put it towards quality rather than spend it all on speed.
Yes, I review every PR (which is part of the bottleneck) and give strict feedback (as I mentioned, averaging 2 to 3 fixes per task).
What I'm saying is that there are some higher-level loops (as described in this article) that are outside of the bottlenecks I mentioned (spec creation and PR review).
For example, I may have 3 written and ready to go specs that are totally unrelated (don't touch the same files, each can go to PR stage with no conflict) but it isn't easy to keep the agent moving on them unless I do so manually. Having an outer-layer orchestrator that can move that along makes a lot of sense.
But when there are dependencies between tasks, it has to wait for my PR. And once I run out of good specs, it has to wait for me to write them.
My experience is that I am bottle-necked on specs. The agent loop is less of a thing for me now.
If I can get a clear understanding of what I want to build, communicate that to Claude Code in planning mode with the goal to write an actionable spec (not code, plan to write the spec) then I tend to get very good results once the agent goes to implement.
But this strategy, while effective, puts a big load on me to write the specs. The agent tends to knock each one out of the park (usually 2 to 3 follow ups based on code review) but then I'm back at the stage that requires the spec.
Another issue for me is that when I step away, if the agent finishes a task and could technically start on an existing spec (no overlap on files so no conflict possible) it doesn't know it can just create a new branch and start. Before I go to bed I'll often say "do task X and once done and pushed start on task Y". But I haven't had luck beyond that. Often I find that it starts on Y and has a question and then the agent is idle the rest of the time.
The final issue is dependency coupled with the above. For example, today I was writing a background job processor. Obviously, the jobs that are in subsequent tasks require the system. That happens with some frequency. Even the specs need to be refreshed after the implementation to take any details that were resolved at coding time into account.
But I am just on the cusp of wanting the outer loop. The gate is almost entirely on spec creation and PR review. In places where those gates don't matter, I want the agent to keep chugging away.
As an aside, I strongly believe we need to start using tools that are better for LLMs even if they are worse for us. For example, Rust is annoying because the compiler is so strict. Bad for me, great for LLMs.
I came across the following yesterday: "The Great Way is not difficult for those who have no preferences," a famous Zen teaching from the Hsin Hsin Ming by Sengstan
As we move from tailors to big box stores I think we have to get used to getting what we get, rather than feeling we can nitpick every single detail.
I'd also be more interested in how his 3rd, 4th or 5th vibe coded app goes.
One thing that comes to mind, more of a first reaction than a considered opinion, is the complexity of V8 getting in the way. JavaScript and Typescript present a challenge to language implementors.
There is something to be said about giving AIs a clean foundation on which to build their own language. This allows evolution of such systems to go all the way into the compiler, beyond tooling.
I'm old, so I remember when Skyrim came out. At the time, people were howling about how "dumbed down" the RPG had become compared to previous versions. They had simplified so many systems. Seemed to work out for them overall.
I understand the article writers frustration. He liked a thing about a product he uses and they changed the product. He is feeling angry and he is expressing that anger and others are sharing in that.
And I'm part of another group of people. I would notice the files being searched without too much interest. Since I pay a monthly rate, I don't care about optimizing tokens. I only care about the quality of the final output.
I think the larger issue is that programmers are feeling like we are losing control. At first we're like, I'll let it auto-complete but no more. Then it was, I'll let it scaffold a project but not more. Each step we are ceding ground. It is strange to watch someone finally break on "They removed the names of the files the agent was operating on". Of all of the lost points of control this one seems so trivial. But every camels back has a breaking point and we can't judge the straw that does it.
> We all know that the industry has taken a step back in terms of code quality by at least a decade. Hardly anyone tests anymore.
I see pseudo-scientific claims from both sides of this debate but this is a bit too far for me personally. "We all know" sounds like Eternal September [1] kind of reasoning. I've been in the industry about as long as the article author and I think he might be looking with rose-tinted glasses on the past. Every aging generation looks down at the new cohort as if they didn't go through the same growing pains.
But in defense of this polemic, and laying out my cards as an AI maximalist and massive proponent of AI coding, I've been wondering the same. I see articles all the time about people writing this and that software using these new tools and it so often is the case they never actually share what they built. I mean, I can understand if someone is heads-down cranking out amazing software using 10 Claude Code instances and raking in that cash. But not even to see one open source project that embraces this and demonstrates it is a bit suspicious.
I mean, where is: "I rewrote Redis from scratch using Claude Code and here is the repo"?
I want to consider the higher-level claims in the article. In between the historical context helpfully provided by the article there is also some speculation about Merkaba, Platonic solids, Flower of Life and other sacred geometry.
There is a premise hidden in those speculations that there is some strong connection between the structure of the universe itself and the structures humans find pleasing when listening to music. And I detect a suggestion that studying the output of our most genius musicians might reveal some kind of hidden information about the universe, specifically related to some kind of "spirituality".
This was a sentiment shared, in some sense, by the deists of the enlightenment. They rejected the scriptures and instead believed that studying the physical universe might reveal the "mind of God".
If we are looking for correspondences between these things - why limit ourselves to Euclidean geometry? Modern physics leans on Riemannian geometry, symmetry, and topology. It appears the topology of the universe, under a wide array of experiments, is way more complicated than the old geometric ideas. Most physicists talk about Lie Groups, fiber bundles, etc.
If you take "as above, so below" seriously and you want to find connections between cosmology and music, I believe you have to use modern mathematical tools. I think we need to expand beyond geometry and embrace topology. Can we think of the chromatic scale tones as a Group? What operators would we need? etc.
It's interesting to try to get into the head of a guy like Coltrane and his mathematical approach, but perhaps we could be pushing new boundaries based on new understanding.
One analogy I have been thinking about lately is GPUs. You might say "The amount of time it takes me to fill memory with the data I want, copy from RAM to the GPU, let the GPU do it's thing, then copy it back to RAM, I might as well have just done the task on the CPU!"
I hope when I state it that way you start to realize the error in your thinking process. You don't send trivial tasks to the GPU because the overhead is too high.
You have to experiment and gain experience with agent coding. Just imagine that there are tasks where the overhead of explaining what to do and reviewing the output are dwarfed by the actual implementation. You have to calibrate yourself so you can recognize those tasks and offload them to the agent.