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.
It was "good engineering" only because this was a new kind of product and the customers were not aware yet of what they should get for the money they pay.
The bad quality of the Claude Code program has resulted in increased costs for the customers (very high memory consumption, slow execution, higher and sometimes much higher token count than necessary), and even for Anthropic, but nobody was aware of this, because there was no previous experience to compare with.
This kind of sloppy vibe coding works only when there is no competition. When the competition comes with something much more efficient, e.g. pi-dev, the inefficient application will be eliminated.
Anthropic attempts to protect their badly written program by forbidding its customers to use other coding harnesses, but this will not be able to protect them from competition for long.
If you are the first on a new market without competitors, then indeed time-to-market matters more than anything else and the sloppiest vibe-coded application is the best if it can be delivered immediately.
However, one must plan to replace that with a better and more efficient application ASAP, because the advantage of being the first is only temporary.
I have already said that sometimes time-to-market is the most important, so that should be the priority, but the advantage of delivering immediately the application is only temporary, so you must improve quickly your first possibly vibe-coded implementation, otherwise better alternatives will be delivered by others.
Claude Code is an obvious example of this, because it has practically opened a new market, but because it has remained a mess now there are better alternatives.
What is wrong is not generating instantly a proof-of-concept application that barely works and using it in the beginning, but continuing to build upon that even after you had enough time to rewrite it.
They would have to trade off building new features for refactoring. It seems they consider shipping more important, and that as long as the existing features mostly work, that’s good enough. As customers, we have to ask: do we agree? Do we want features over stability? I think the answer is yes, at least for me (and the market seems to agree). But it’s certainly a risk Anthropic is taking.
I will note that this strategy only really makes sense because Anthropic controls the compute. If open-source harnesses could also use Claude max plans, then they’d have to focus much more on stability and quality, or just build an open-source harness themselves, or probably better yet, get out of the harness-building business altogether. So they’re gambling on staying ahead of open-source models, which seems like it’s been a good bet so far, but we’ll see.
The advantage is definitely not temporary as can be seen by how many people use codex vs Claude code.
Claude code works just fine and I have zero issues at usability level. Could they have more features? Yes but I see that they are shipping quick. It is obvious to me that they took the right balance between time to market and clan code
These discussions are insane. No agentic coding product, including Claude Code, has existed for a full year yet, but people are stating with extreme confidence who has "won" the competition to be the leading or even only provider of this kind of product and having heated arguments over whether or not we can consider the current state of the market to be temporary or not. Imagine having this same argument about Lycos versus Yahoo! in 1995.
But it is working primarily because of the Max subscription model. If I could use my Max subscription to get $5000 worth of tokens for only $200 via OpenCode or Pi, I would drop Claude Code today. I think a lot of people (and enterprises) are of a similar opinion. Not saying Claude Code would have no users, but its dominance would be greatly diminished.
But you can’t and the reason that you care also has to do with the same production process.
It’s not like a separate company made the terminal app versus the model. If we think that the desktop app is bad, but the model is good then that’s still an endorsement of the software process.
If we think the model doesn’t matter at all, then that’s an even bigger endorsement. Is the model has no content worth talking about over the nearest competitors or an open source alternative, then the remainder is marketing and polish.
I just don’t understand how people can look at a company that is capacity constrained in this market and think that they’re doing things poorly.
You can go just as fast if you make good code, you just have to burn more tokens to do it. The tokens you burn in strict structure and documentation you’ll save in debugging as the codebase grows. I’m 5-30x my normal production depending on the day…with zero team and writing better code than I ever have, but you need a robust system to manage the path, and active supervision and management basically you’ll apply your senior dev skills as if you were managing 50 frisky interns.
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.
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?
CC is riddled with bugs and poor UI/UX. It's effective in spite of that. Just think what a well-designed agent would do in place of that. I don't use other coding agents currently because the subscription with CC gets me what I need and I don't want to pay retail token rates. I would 100% prefer an open source agent so I could fork it and tweak it to my needs.
Every time I hear someone say that software is successful in spite of something I find that looking harder shows some interesting choices.
If this software succeeds despite the manifest failures that are pointed out here, that’s a sign that something is working. We could argue that something is just access to the model, but plenty of other companies sell that and they don’t seem to do as well.
In this case it's because they gate subscription access to their agent. If not for that, I wouldn't be using Claude Code. I like Anthropic overall, but it disappoints me that they didn't make CC open source and that they insist on tying subscription use to CC.
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.
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.
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.
if you read the thinking context while in plan mode (I had it shown to me, i think mistakenly, by switching modes while Claude was thinking a week or so ago) plan mode is just a pre-prompt saying “you are now in plan mode, don’t propose edits, read the code and understand how it works.”
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.
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.
It depends on the kind of software you are programming.
If you are programming regular commercial software (office applications, web apps, games) with customers tolerating occasional bug and lot of pressure deliver fast, you can gain lot from Claude. Facebook motto: Move fast and break things
If you are programming software for industrial applications, critical software, most of the time you spend is not on writing software but writing tests, documenting, doing multiple rounds of reviews and for really critical applications doing formal verification. In this case AI can be also counterproductive, because if you absolutely have to understand every single line of code, manual coding helps to understand the code.
Example of cutting costs in programming of critical software
That’s most of my work(embedded sensor and control networks) and I’m sure that informs my methodology. I honestly don’t know much about how AI can inform standards SAAS but I have seen what happens when you just turn it loose, and in my experience it hasn’t been pretty; it works, but then when you need to change something it all crumbles like a badly engineered sandcastle.
OTOH for single purpose pipelines and simple tools. Claude can oneshot small miracles in 5 minutes that would take me 2 hours to build.
An example is the local agent framework that I had Claude spinup to do JTAG testing. I used to spend hours running tests over JTAG, now I have a local model run tests that Claude and I specify in the test catalog and it just runs them every time we add features. It took Claude minimal guidance and about 3 hours to build that tool along with a complete RAG system for document ingestion and datasheet comprehension, running locally on my laptop (I know it has a fan now lol) that only reaches out to the cloud when it runs into difficult problems. I don’t care if that is a bit of a mess, as long as it works, and it seems to , so far so good.
The testing is where Claude is basically magic, but it’s because we specify everything before we build and change the specs when we change the IRL code that it works. English is code, too, if you build structured documentation… and the docs keep the code accountable if you track the coherence.
It is a lot of work, but I’m much more productive and produce better code than when I was running a small team. And I’m not spending 36k a month. As a research stage startup, that’s a really big deal.
I’ve been writing code for nearly 50 years now, and the only thing I like better than coding is getting things done. For me, AI is rocket fuel if you do it right, and a bunch of hypergolic liquid if you don’t.
Reveal = show something that was hidden previously.
Seems like the appropriate word to use about a source code leak.
The words proposed by you are suitable for describing the consequences of a revelation, while no longer containing any hint about their original cause, so using them would have lead to a more verbose sentence for delivering the same information.
It wasn't hidden previously. It was fairly well-understood.
The CC source doesn't "reveal" a single thing about anything other than Anthropic internals. It says nothing about the industry at large, certainly nothing new.
And this:
The words proposed by you are suitable for describing the consequences of a revelation, while no longer containing any hint about their original cause
doesn't make any sense. There is no "revelation" here. And the word "reveal" contains no connotations whatsoever about the "cause" of a "revelation".
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.
It was "good engineering" only because this was a new kind of product and the customers were not aware yet of what they should get for the money they pay.
The bad quality of the Claude Code program has resulted in increased costs for the customers (very high memory consumption, slow execution, higher and sometimes much higher token count than necessary), and even for Anthropic, but nobody was aware of this, because there was no previous experience to compare with.
This kind of sloppy vibe coding works only when there is no competition. When the competition comes with something much more efficient, e.g. pi-dev, the inefficient application will be eliminated.
Anthropic attempts to protect their badly written program by forbidding its customers to use other coding harnesses, but this will not be able to protect them from competition for long.
If you are the first on a new market without competitors, then indeed time-to-market matters more than anything else and the sloppiest vibe-coded application is the best if it can be delivered immediately.
However, one must plan to replace that with a better and more efficient application ASAP, because the advantage of being the first is only temporary.
I guess that now people are more aware on how bad their software is, we cannot blame the "super intelligent ai" to not be ready yet.
The amount of regex matching people found os staggering
Your kind of critique forgets the tradeoff between getting something out quick vs doing something slowly and nicely.
If you choose slowly, you are depriving your users of the value from your app for a long time. It’s not as clear a choice as you think
Have you read my entire comment?
I have already said that sometimes time-to-market is the most important, so that should be the priority, but the advantage of delivering immediately the application is only temporary, so you must improve quickly your first possibly vibe-coded implementation, otherwise better alternatives will be delivered by others.
Claude Code is an obvious example of this, because it has practically opened a new market, but because it has remained a mess now there are better alternatives.
What is wrong is not generating instantly a proof-of-concept application that barely works and using it in the beginning, but continuing to build upon that even after you had enough time to rewrite it.
They would have to trade off building new features for refactoring. It seems they consider shipping more important, and that as long as the existing features mostly work, that’s good enough. As customers, we have to ask: do we agree? Do we want features over stability? I think the answer is yes, at least for me (and the market seems to agree). But it’s certainly a risk Anthropic is taking.
I will note that this strategy only really makes sense because Anthropic controls the compute. If open-source harnesses could also use Claude max plans, then they’d have to focus much more on stability and quality, or just build an open-source harness themselves, or probably better yet, get out of the harness-building business altogether. So they’re gambling on staying ahead of open-source models, which seems like it’s been a good bet so far, but we’ll see.
The advantage is definitely not temporary as can be seen by how many people use codex vs Claude code. Claude code works just fine and I have zero issues at usability level. Could they have more features? Yes but I see that they are shipping quick. It is obvious to me that they took the right balance between time to market and clan code
These discussions are insane. No agentic coding product, including Claude Code, has existed for a full year yet, but people are stating with extreme confidence who has "won" the competition to be the leading or even only provider of this kind of product and having heated arguments over whether or not we can consider the current state of the market to be temporary or not. Imagine having this same argument about Lycos versus Yahoo! in 1995.
I understand your thoughts, but I don't think they will ever make that existing code good. Not sure if they want to and not sure if they can.
But it is working primarily because of the Max subscription model. If I could use my Max subscription to get $5000 worth of tokens for only $200 via OpenCode or Pi, I would drop Claude Code today. I think a lot of people (and enterprises) are of a similar opinion. Not saying Claude Code would have no users, but its dominance would be greatly diminished.
But you can’t and the reason that you care also has to do with the same production process.
It’s not like a separate company made the terminal app versus the model. If we think that the desktop app is bad, but the model is good then that’s still an endorsement of the software process.
If we think the model doesn’t matter at all, then that’s an even bigger endorsement. Is the model has no content worth talking about over the nearest competitors or an open source alternative, then the remainder is marketing and polish.
I just don’t understand how people can look at a company that is capacity constrained in this market and think that they’re doing things poorly.
Its the same for a lot of bundled things, mac hardware + os or windows pre-installed, chrome being pushed by google.com etc.
You can go just as fast if you make good code, you just have to burn more tokens to do it. The tokens you burn in strict structure and documentation you’ll save in debugging as the codebase grows. I’m 5-30x my normal production depending on the day…with zero team and writing better code than I ever have, but you need a robust system to manage the path, and active supervision and management basically you’ll apply your senior dev skills as if you were managing 50 frisky interns.
People notice the jank, and it's affecting CC's reputatio That's not easy to come back from.
The argument is that the bad code will result in the companies core product failing.
Successful over what time frame? It's way too early to declare victory.
Is there some testable/observable prediction where Opencode beats CC and Nanoclaw beats Openclaw?
It just won't survive, it's that simple.
You get to know before others how the future will play out
Wow this industry is so cooked. Good God almighty.
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.
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?
CC is riddled with bugs and poor UI/UX. It's effective in spite of that. Just think what a well-designed agent would do in place of that. I don't use other coding agents currently because the subscription with CC gets me what I need and I don't want to pay retail token rates. I would 100% prefer an open source agent so I could fork it and tweak it to my needs.
Every time I hear someone say that software is successful in spite of something I find that looking harder shows some interesting choices.
If this software succeeds despite the manifest failures that are pointed out here, that’s a sign that something is working. We could argue that something is just access to the model, but plenty of other companies sell that and they don’t seem to do as well.
In this case it's because they gate subscription access to their agent. If not for that, I wouldn't be using Claude Code. I like Anthropic overall, but it disappoints me that they didn't make CC open source and that they insist on tying subscription use to CC.
I used OpenCode and find it works just as well or better than CC.
I dont think CC has a moat other than their model but their model is also available through Copilot.
Have you found any cheaper models to work well with OpenCode? Like any of the Chinese models?
Haven't tried, corporate pays for use on both work and personal projects.
I use Z.ai GLM-5.1 with Opencode, haven't had any issues.
Pi
No one is going to find out exactly what you mean. I'll add this link for reference, https://lucumr.pocoo.org/2026/1/31/pi
It was my intent but it's also fine to be more direct.
> I’m seriously considering a pivot to security
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.
Man, same boat. If I weren't only looking for another 10 years of working, I'd be doing the same.
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.
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.
You don't. I learned this from it executing commands while in plan mode. It is LLMs all the way down.
if you read the thinking context while in plan mode (I had it shown to me, i think mistakenly, by switching modes while Claude was thinking a week or so ago) plan mode is just a pre-prompt saying “you are now in plan mode, don’t propose edits, read the code and understand how it works.”
it’s not an actual limitation on the harness.
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.
> Issue #38335 had 201 upvotes and zero team responses. Labeled “invalid.”
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-...
Ironically this article critical of AI coding is guilty of AI writing.
Obviously they were legit vibing it.
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.
It depends on the kind of software you are programming.
If you are programming regular commercial software (office applications, web apps, games) with customers tolerating occasional bug and lot of pressure deliver fast, you can gain lot from Claude. Facebook motto: Move fast and break things
If you are programming software for industrial applications, critical software, most of the time you spend is not on writing software but writing tests, documenting, doing multiple rounds of reviews and for really critical applications doing formal verification. In this case AI can be also counterproductive, because if you absolutely have to understand every single line of code, manual coding helps to understand the code.
Example of cutting costs in programming of critical software
https://www.industryweek.com/supply-chain/article/22027840/b...
That’s most of my work(embedded sensor and control networks) and I’m sure that informs my methodology. I honestly don’t know much about how AI can inform standards SAAS but I have seen what happens when you just turn it loose, and in my experience it hasn’t been pretty; it works, but then when you need to change something it all crumbles like a badly engineered sandcastle.
OTOH for single purpose pipelines and simple tools. Claude can oneshot small miracles in 5 minutes that would take me 2 hours to build.
An example is the local agent framework that I had Claude spinup to do JTAG testing. I used to spend hours running tests over JTAG, now I have a local model run tests that Claude and I specify in the test catalog and it just runs them every time we add features. It took Claude minimal guidance and about 3 hours to build that tool along with a complete RAG system for document ingestion and datasheet comprehension, running locally on my laptop (I know it has a fan now lol) that only reaches out to the cloud when it runs into difficult problems. I don’t care if that is a bit of a mess, as long as it works, and it seems to , so far so good.
The testing is where Claude is basically magic, but it’s because we specify everything before we build and change the specs when we change the IRL code that it works. English is code, too, if you build structured documentation… and the docs keep the code accountable if you track the coherence.
Sounds like a lot of work just to avoid doing work.
Can I just type out the code instead? Please?
It is a lot of work, but I’m much more productive and produce better code than when I was running a small team. And I’m not spending 36k a month. As a research stage startup, that’s a really big deal.
I’ve been writing code for nearly 50 years now, and the only thing I like better than coding is getting things done. For me, AI is rocket fuel if you do it right, and a bunch of hypergolic liquid if you don’t.
[dead]
[flagged]
Why does everything always have to reveal something?
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.
Reveal = show something that was hidden previously.
Seems like the appropriate word to use about a source code leak.
The words proposed by you are suitable for describing the consequences of a revelation, while no longer containing any hint about their original cause, so using them would have lead to a more verbose sentence for delivering the same information.
It wasn't hidden previously. It was fairly well-understood.
The CC source doesn't "reveal" a single thing about anything other than Anthropic internals. It says nothing about the industry at large, certainly nothing new.
And this:
doesn't make any sense. There is no "revelation" here. And the word "reveal" contains no connotations whatsoever about the "cause" of a "revelation".