As someone who finds a huge amount of enjoyment in developing using Opus 4.6 in Claude code, I’d love to know what other harnesses people use that deliver the same experience as CC. CC is a vibe-coded mess, but it works very well for me.
I do a lot of work in R and find codex (5.4 & 5.3-codex) just totally drop the ball with R. Anthropic’s models are far better with R, so I use them.
But I do wonder how much the harness affects performance.
Would GPT-5.3-Codex perform just as well if it was plugged into CC?
I came away with a very different conclusion, which is that the fact that such “bad” software can be so resoundingly successful for a business, yet be so odious to experienced human reviewers, means that it was the right engineering choice to go fast, rather than “do things right” by emphasizing code quality.
What good would it truly be if a 3K line function is split into 8 modules? It’ll be neater and more comprehensible to a human reader. More debuggable, definitely.
But given the business problem the have: winner takes all of a massive market, first mover wins, — the right move is to throw the usual rulebook about quality software out the window, and double down on the bets of the company, that AI will make human code engineering less and less necessary very quickly.
It turned out incredibly well despite the “bad” engineering — which in this case, I really count as good engineering.
Unsure if this was AI generated, but doesn't pass close scrutiny:
"winner takes all of a massive market, first mover wins"
...this is the kind of AI spam that sounds convincing until you think about it.
It's not at all clear the foundation model or coding agent markets are winner takes all. Far more likely to be a handful of successful players based on the market so far.
First mover wins? OpenAI was first to market and looks in trouble.
There's something convincing about this kind of cliche that lets it slip past you until you start inspecting each claim.
I think your "winner takes all, first mover wins" premise is wrong, even if it may be what Anthropic believe. Their mission has certainly shifted from "save the world from AI" to "push AI onto the world ASAP, because we've got an IPO coming up".
In reality the coding market, which is really the biggest success story for frontier AI (because code it is uniquely suited for LLMs and RL) is rapidly headed for, if not already arrived at, commodification, with each release from any of the US big 3 heralded as best yet, and the Chinese models like DeepSeek, Kimi, Qwen, GLM maybe no more than 6 months behind.
As far as code quality and level of bugs, certainly Claude Code has been hugely successful despite that, for two reasons.
1) It's a revolutionary product, and people are willing to accept a high level of bugs because of that.
2) The product is an LLM, itself an inherently flawed and unreliable technology, but one that people have got used to. The fact that the agent/harness, as well as the LLM itself, is unreliable and regresses from release to release doesn't much change the vibe
The quality of code produced by Claude Code, at least the way it has been used to write itself, would be a complete non-starter for any business where reliability is important. Maybe best suited for things like consumer web apps where the cost of product failure, or version regression, is just an annoyed customer rather than a lawsuit.
AI coding is like having a team of 100 interns. It’s incredibly powerful but you need to keep it under control or you’re gonna have a bad day.
Write documentation describing the specs , the APIs, the protocols, and the customer stories. Specify that everything must be divided with clear separations of concerns, interfaces, and state objects. Any single file should have a clearly defined role and should not span domains or concerns.
File separation is even more critical than functional refactoring. It’s the files and their well defined and documented interface surfaces that will keep things from becoming an indecipherable tangle of dependencies and hidden state. Keep everything not defined in the interfaces private so that it is not accessible from outside the file, and prohibit attaching to anything without using the designated public interface surfaces.
Then write an implementation plan.
Then the skeleton, then start filling features one by one. Write the tests or testing documentation at the same time. If you have the luxury of compile time flags, put the tests right in the functions so they are self validated if built with test=1. (I know that’s weird but it helps the AI stay constrained to the intent)
After each minor feature (anything that would take me >1 hour to personally do, since the last review), have all touched files reviewed for correctness, consistency, coherence, and comments both within the codebase and the documentation. Don’t add features to the code, add them through the documentation and implementation plan. Don’t let Claude use the planning tool, it tries to do too much at once…. That’s how you get spaghetti.
One little thing, then review. 1/4 of the tokens burned in writing code, 1/2 in aggressive review / cleanup and 1/4 in ongoing documentation maintenance.
Thats the real price if you want to produce good code…. and you can produce really solid , maintainable code.
It’s just 4x the price of vibe coding… but 1 solid senior developer can still produce about as much as if he was running a team of 5-10 engineers depending on the project. Still incredibly rapid and economical…. But it takes the same skills as you need to run a team as well as an excellent sense of smell to call out wrong turns.
Also, use the 1M context model, have a solid onboarding that describes your company culture, and why the project matters to the AI collaborator, as well as your coding practices, etc. I also use several journals (musings, learnings, curiosity) that the AI maintains itself, reading them during onboarding and writing them in wrapup. It is at least a 2x when the AI is acting as if it were a person that is deeply invested in the outcome. Treat it like a collaboration and you will get better results.
It’s a token fire. But IMHO it’s the way if you’re building something that has to be deployed at scale and maintainable.
Straight vibes are fine for mockups, demos, and prototypes.
Sure, worse may be better, but how do you know your code is worse unless you actually review it? You might accidentally let some good code slip into production, then your product isn't as better as it could be.
Exactly my conclusion, unfortunately I'm too old to pivot now, but anyone in their junior-to-mid days as a software developer should consider this pivot.
And this is only about generating source code in a closed environment. All hell will break loose when Openclaw et al get in the hands of average users...
I wouldn't. Until companies become liable for their security failures, and that liability comes with a big price tag, there will be no money in security. Currently, poor security costs companies nothing, so they won't pay to improve their security.
I agree with the core of what you're saying, but I think the real split isn't "Anthropic trustworthy or not" — it's: what's proprietary vs what's open in the stuff you're actually building on.
Routines, Projects, Artifacts, Skills — that's vendor-specific, disposable by definition. MCP, CLAUDE.md, markdown in your repo — that's portable. If Anthropic pivots or nerfs the thing tomorrow, you just rewire your MCP tools onto another harness in 10 minutes.
Personally I build my agent workflows as scripts + MCP tools — called by Claude Code today, callable by whatever harness replaces it tomorrow. The building block is "a set of MCP tools + one CLAUDE.md", not "a Routine defined in Anthropic's console". Functionally the same, zero lock-in.
Routines are fine for quick-wins, but the moment you start stacking them into a real workflow you're just moving your tech debt into a proprietary format. At that point you might as well externalize to scripts from the start.
Yes definately, I do a lot of OT devops and if you want determinstic results then the best use of AI is to get it to write scripts that solve your problems and that you run outside of AI.
Often, the use of AI is a lazy case of not wanting to spend the time to understand the essence of the problem and solve it directly, often far more efficiently. (Not always, but often).
The ability of getting results that surpass your understanding, and quickly, is seducing, but you invariably end up being capped on the usefullness.
AI generally seems to raise anyone with the basic skills to "expert beginner" in almost any field, but it is then a big struggle to get past this stage, without substantial extra work.
Claude code has some basic security features like asking for user confirmation for bash commands, or restricting commands to the current directory. If these features are not being code reviewed, what assurances do we have that they actually work?
They don't work. Do not trust them. Run Claude Code in an isolated, disposable micro VM and assume it will break your environment, steal any available secrets, do destructive commands, etc. So don't give it any way to do that to anything you care about.
Humans don't really work any better, just fail in different ways. This is why certain workflows and practices have emerged.
We are now in the early days of working through a similar process with AI.
They most definately do work for some use cases, but how they are used is important.
Just because you apply human processes and systems to AI based workflows and don't get historically expected results, this is zero basis to claim the sky is falling with use of AI in coding.
I didn't claim the sky is falling with the use of AI in coding.
I claimed
> basic security features like asking for user confirmation for bash commands, or restricting commands to the current directory
Do not currently reliably work. Not to the point that anyone concerned with security or reliability/not-having-their-env-fucked-up should trust these safeguards as standalones.
The problem isn't the AI writing the code, it is the specification - I assert much of the described problems could be rectified by improved specification with no hand coding.
Specification of software has been very weak for decades, and little effort has been put towards defining methadologies of specification that are both exhaustive and unambiguous.
It is possible, I know because I work in an exotic niche where being exhaustive and unambiguous isnot optional - Functional Safety. Here you might spend 90% or more of your time planning what and how to code, before writing the first line.
The cost - I have worked on projects where, across the duration of the project, the average production of code was less than two lines a day.
But when a single error could result in the death of 100, or 300, people, then this time worth it.
You can't get this kind of quality when you pivot twice a week, you need to have fairly fixed objectives.
The are ways to get better outcomes that are known, but not widely applied, and they could do with some development to make them accessible. Some has been done, eg Leslie Lamport and TLA+.
But, as you might have been told as a child, don't get upset that you did not get what you wanted when you failed to ask for it properly.
the "it worked despite being bad code" argument proves too much. plenty of bad codebases succeeded for reasons unrelated to their quality such as first mover, distribution, pricing. correlation isn't causation, and survivorship bias is real. the 3K-line function didn't make Claude Code win, the model and the timing did.
the more honest version of golly_ned's point upthread is narrower: in the very early days of a new category, shipping beats quality because nothing is proven yet. that's actually true. it's not true as a general principle, and it's definitely not true for the 99% of projects that aren't racing to define a new market.
26 comments
[ 2.7 ms ] story [ 71.1 ms ] threadI do a lot of work in R and find codex (5.4 & 5.3-codex) just totally drop the ball with R. Anthropic’s models are far better with R, so I use them.
But I do wonder how much the harness affects performance.
Would GPT-5.3-Codex perform just as well if it was plugged into CC?
It's such a definitive, decisive word, which is abused to the point of meaninglessness by clickbait.
Claude Code's source could imply, suggest, point to, highlight, call attention to, indict, or invite deeper reflection about AI engineering culture.
Quit sucking all the life out of words to get clicks. The way we use them, they're a finite resource.
What good would it truly be if a 3K line function is split into 8 modules? It’ll be neater and more comprehensible to a human reader. More debuggable, definitely.
But given the business problem the have: winner takes all of a massive market, first mover wins, — the right move is to throw the usual rulebook about quality software out the window, and double down on the bets of the company, that AI will make human code engineering less and less necessary very quickly.
It turned out incredibly well despite the “bad” engineering — which in this case, I really count as good engineering.
"winner takes all of a massive market, first mover wins"
...this is the kind of AI spam that sounds convincing until you think about it.
It's not at all clear the foundation model or coding agent markets are winner takes all. Far more likely to be a handful of successful players based on the market so far.
First mover wins? OpenAI was first to market and looks in trouble.
There's something convincing about this kind of cliche that lets it slip past you until you start inspecting each claim.
In reality the coding market, which is really the biggest success story for frontier AI (because code it is uniquely suited for LLMs and RL) is rapidly headed for, if not already arrived at, commodification, with each release from any of the US big 3 heralded as best yet, and the Chinese models like DeepSeek, Kimi, Qwen, GLM maybe no more than 6 months behind.
As far as code quality and level of bugs, certainly Claude Code has been hugely successful despite that, for two reasons.
1) It's a revolutionary product, and people are willing to accept a high level of bugs because of that.
2) The product is an LLM, itself an inherently flawed and unreliable technology, but one that people have got used to. The fact that the agent/harness, as well as the LLM itself, is unreliable and regresses from release to release doesn't much change the vibe
The quality of code produced by Claude Code, at least the way it has been used to write itself, would be a complete non-starter for any business where reliability is important. Maybe best suited for things like consumer web apps where the cost of product failure, or version regression, is just an annoyed customer rather than a lawsuit.
AI coding is like having a team of 100 interns. It’s incredibly powerful but you need to keep it under control or you’re gonna have a bad day.
Write documentation describing the specs , the APIs, the protocols, and the customer stories. Specify that everything must be divided with clear separations of concerns, interfaces, and state objects. Any single file should have a clearly defined role and should not span domains or concerns.
File separation is even more critical than functional refactoring. It’s the files and their well defined and documented interface surfaces that will keep things from becoming an indecipherable tangle of dependencies and hidden state. Keep everything not defined in the interfaces private so that it is not accessible from outside the file, and prohibit attaching to anything without using the designated public interface surfaces.
Then write an implementation plan.
Then the skeleton, then start filling features one by one. Write the tests or testing documentation at the same time. If you have the luxury of compile time flags, put the tests right in the functions so they are self validated if built with test=1. (I know that’s weird but it helps the AI stay constrained to the intent)
After each minor feature (anything that would take me >1 hour to personally do, since the last review), have all touched files reviewed for correctness, consistency, coherence, and comments both within the codebase and the documentation. Don’t add features to the code, add them through the documentation and implementation plan. Don’t let Claude use the planning tool, it tries to do too much at once…. That’s how you get spaghetti.
One little thing, then review. 1/4 of the tokens burned in writing code, 1/2 in aggressive review / cleanup and 1/4 in ongoing documentation maintenance.
Thats the real price if you want to produce good code…. and you can produce really solid , maintainable code.
It’s just 4x the price of vibe coding… but 1 solid senior developer can still produce about as much as if he was running a team of 5-10 engineers depending on the project. Still incredibly rapid and economical…. But it takes the same skills as you need to run a team as well as an excellent sense of smell to call out wrong turns.
Also, use the 1M context model, have a solid onboarding that describes your company culture, and why the project matters to the AI collaborator, as well as your coding practices, etc. I also use several journals (musings, learnings, curiosity) that the AI maintains itself, reading them during onboarding and writing them in wrapup. It is at least a 2x when the AI is acting as if it were a person that is deeply invested in the outcome. Treat it like a collaboration and you will get better results.
It’s a token fire. But IMHO it’s the way if you’re building something that has to be deployed at scale and maintainable.
Straight vibes are fine for mockups, demos, and prototypes.
Exactly my conclusion, unfortunately I'm too old to pivot now, but anyone in their junior-to-mid days as a software developer should consider this pivot.
And this is only about generating source code in a closed environment. All hell will break loose when Openclaw et al get in the hands of average users...
Often, the use of AI is a lazy case of not wanting to spend the time to understand the essence of the problem and solve it directly, often far more efficiently. (Not always, but often).
The ability of getting results that surpass your understanding, and quickly, is seducing, but you invariably end up being capped on the usefullness.
AI generally seems to raise anyone with the basic skills to "expert beginner" in almost any field, but it is then a big struggle to get past this stage, without substantial extra work.
We are now in the early days of working through a similar process with AI.
They most definately do work for some use cases, but how they are used is important.
Just because you apply human processes and systems to AI based workflows and don't get historically expected results, this is zero basis to claim the sky is falling with use of AI in coding.
I claimed
> basic security features like asking for user confirmation for bash commands, or restricting commands to the current directory
Do not currently reliably work. Not to the point that anyone concerned with security or reliability/not-having-their-env-fucked-up should trust these safeguards as standalones.
They're doing the right thing. The market is resoundingly telling them this.
> Anthropic draws VC interest at up to $800 billion valuation, Business Insider reports
https://www.reuters.com/legal/transactional/anthropic-draws-...
Specification of software has been very weak for decades, and little effort has been put towards defining methadologies of specification that are both exhaustive and unambiguous.
It is possible, I know because I work in an exotic niche where being exhaustive and unambiguous isnot optional - Functional Safety. Here you might spend 90% or more of your time planning what and how to code, before writing the first line.
The cost - I have worked on projects where, across the duration of the project, the average production of code was less than two lines a day.
But when a single error could result in the death of 100, or 300, people, then this time worth it.
You can't get this kind of quality when you pivot twice a week, you need to have fairly fixed objectives.
The are ways to get better outcomes that are known, but not widely applied, and they could do with some development to make them accessible. Some has been done, eg Leslie Lamport and TLA+.
But, as you might have been told as a child, don't get upset that you did not get what you wanted when you failed to ask for it properly.
the more honest version of golly_ned's point upthread is narrower: in the very early days of a new category, shipping beats quality because nothing is proven yet. that's actually true. it's not true as a general principle, and it's definitely not true for the 99% of projects that aren't racing to define a new market.