Live data from Hacker News

What Claude Code's Source Revealed About AI Engineering Culture

techtrenches.dev

1–10 of 65 posts

Re: What Claude Code's Source Revealed About AI Engineering Culture

#2
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?

Re: What Claude Code's Source Revealed About AI Engineering Culture

#3
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.

Re: What Claude Code's Source Revealed About AI Engineering Culture

#4
post #2

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 harn…

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.

Re: What Claude Code's Source Revealed About AI Engineering Culture

#5
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.

Re: What Claude Code's Source Revealed About AI Engineering Culture

#6
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.

Re: What Claude Code's Source Revealed About AI Engineering Culture

#7

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 comprehen…

People notice the jank, and it's affecting CC's reputatio That's not easy to come back from.

Re: What Claude Code's Source Revealed About AI Engineering Culture

#8

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 comprehen…

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.

Re: What Claude Code's Source Revealed About AI Engineering Culture

#9

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 comprehen…

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.

Re: What Claude Code's Source Revealed About AI Engineering Culture

#10
post #3

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.

Post reply on HN