Code quality is a side-effect of caring. The most important part of product design is caring at all levels. However it's caring about the external details that is the most important. Coding language is largely a function of the population of good coders in your areas. Code evolvability is almost entirely subjective.
I agree with OP's distinction. However just because you see software as a means to an ends, doesn't mean that you don't feel that quality and craft are unimportant. You can see the "craft" oriented folks as being obsessed with the form of their software. A "craft" oriented engineer might rewrite a perfectly functioning piece of software to make it what they perceive to be "easier to reason about". I consider most software rewrites to be borderline malpractice.
I think the kind of surface level rewrites that people rag on are pretty rare, at least in my experience. Realistically code that's impossible to understand, underdocumented, and lacking in proper abstractions is also deficient code. If you've ensured that the code is "good enough", you will likely hit a bug or feature request that is hindered by the poor structure and understanding of the code.
It's totally fine to say "the code works, that area is stable, let's not mess with that code". I make those kinds of tradeoffs on a near daily basis. But let's be real, "perfectly functioning code" is an ill defined, moving target. What looks like perfectly functioning code to a sibling team or a PM, could be a massive liability to someone who actually knows the code.
But then again I'm writing OS and performance critical code. A 1 in 1 million bug is easier to ignore in a throwaway log viewer website.
The most productive teams I've seen (eg at Jane Street) rewrite things all the time, and still move faster than any "normal" teams I've seen. I remember when I interned there over a decade ago, they were already on like the seventh? version of their incremental computing framework, and were building a new build system. But they were also incredibly effective at getting things done both on a per-engineer basis and in terms of making money.
With bad code it’s often almost impossible to improve the functionality or correctness or performance of the code, without first rewriting parts of it.
“Vibe coded”? I doubt that there is the documentary evidence that the code in these systems was never touched by a human. At best this is a list of code where AI tools were used in development. To be honest if you just created a list of all outages in all companies and systems you’d probably have a better list since AI tools are ubiquitous.
Only among people who don't value the quality of their output. There are, fortunately, many who do value quality and are not using AI tools until they get to the point where they can usefully contribute.
Have you used a state of the art tool (e.g. Claude Code) in the past 6 months? If you only tried free tools, or only tried 1 year ago last, you really need to check again.
AI tools can absolutely contribute usefully, I can't keep count of the times where an AI pointed to an edge case I didn't think about, then helped me write the fix and the test for the issue.
I'm not vibe coding, as I'm reviewing the code, but saying they can't be useful means you haven't taken the time to look at the state of them recently.
Isn't it odd that you wrote your comment with AI then!?
Ha, gotcha, AI slop poster!
I know you didn't, but this is where we'll end up if people just write off everything as 'bad because AI' instead of critically assessing the quality of something on its own merit rather than the (very ironic) 'vibe' that it was generated rather than written.
Some estimates are about two million but I think that’s an extremely loose definition of Ruby Developer.
I run rubyschema.org which maintains the rubocop JSON schema that’s pulled via schema store. I can see there are about 21k unique downloads each month, which I think is a pretty reasonable lower bound.
Most text editors will pull this schema when opening a project with Rubocop.
The copyright example is naive at best. Any AI work that has been meaningfully modified by a human can be copyrighted. So if LLM generated code is used a the starting point and it is then modified in the testing and review phases you are good. Code that has not been touched by humans is very rare.
Currently: human output is copyrighted so companies sign a transfer agreement with employees that anything they produce at work belongs to the employer. The employer now owns the copyright eventhough the employee, depending on jurisdiction, still owns the moral rights (which matter not much more than squat).
With AI: the company uses AI to produce code that isn't copyrighted. The company can take it like any public domain piece of software and incorporate it into their product. Their product is copyrighted by the company. There are even no moral rights that are personal (no need to mention "This product is based on work by Claude").
On reddit there are two sub-Reddits that are mirrors, /accelerate and /betteroffline. The people in the subs go there for dopamine hits. One for how AI is going to transform their lives and lead to a work-free future. The other how AI is worthless and how everyone (except them) is being fooled. They are the same people with opposite views. The people in either sub don't recognize this.
Nope. It remains the most dynamic and impactful area in software today. I'm sure it will fade in to common practice over the next few years and become less talked about. I find it infinitely more interesting than yet another article talking about the wonders/horrors of the Rust borrow checker.
I run many instances of Claude Code simultaneously and have not experienced what you are seeing. It sounds like you have a bias of Rust over Typescript.
No, they are describing a typical experience with the two apps. Just open both apps, run a few queries, and take a look at the difference in resource management yourself. It sounds like you have a bias of Claude Code over Codex.
Uh, it sounds like you're having trouble understanding that people in this thread are talking about two wildly different "claude code" applications. Those who are claiming the resources issues don't apply to them are referring to the cli application, ie: `claude` and those are saying things like "Just open both apps..." are surely referring to their GUI versions.
No, I've never used the GUI version. I literally just had to close and reopen the terminal running the Claude Code CLI on my Mac yesterday because it was taking too many resources. It generally happens when I ask Claude to use multiple sub agents. It's an obvious memory leak.
I own both a PHEV and EV. I really don't like driving the PHEV because the performance goes to crap at 40 miles when the gas motor kicks in. Once you are in ICE mode you are driving a loud poorly performing car. In rural areas I think PHEVs are fine.
That sounds like you just bought a really poor choice of PHEV. I've got a PHEV DS 7 and the performance is essentially identical on ICE or EV. Combined with the sound proofing, I've never even noticed the car switch between the two modes.
reply