Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Claude Code's Source Revealed About AI Engineering Culture

techtrenches.dev

Post reply on HN
Print view View original

51–60 of 65 posts

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

#51

Post by rhubarbtree »

golly_ned wrote: post #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 comprehen…

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.

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

#54

Post by airbreather »

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.

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

#55

Post by airbreather »

R00mi wrote: post #32

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…

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.

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

#56

Post by airbreather »

K0balt wrote: post #31
otabdeveloper4 wrote: post #22

Earlier quoted context omitted.

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.

Definately, I am similar vintage and work in Functional Safety, see my other comment re specification.

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

#58

Post by airbreather »

ninininino wrote: post #42
markisus wrote: post #34

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.

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

#59

Post by ninininino »

airbreather wrote: post #58
ninininino wrote: post #42

Earlier quoted context omitted.

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…

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.

Post reply on HN