Comment by p0w3n3d | Hacker News Reader

Comment by p0w3n3d | Hacker News Reader

That's quite impressive approach from the companies' perspective. Let's first use claude code and then we'll think who the code belongs to.

I think that the gold rush approach happening right now around me (my company EMs forcing me to work with claude as fast as possible) show really short-sight of all the management people.

First - I lose my understanding of the code base by relying too much on claude code.

Second - we drop all the good coding practices (like XP, code review etc.) because claude is reviewing claude's code.

Third - we just take a big smelly dump on the teamwork - it's easier and cheaper to let one developer drive the whole change from backend to frontend, despite there are (or were) two different teams - one for FE, one for BE.

Fourth - code commenting was passe, as the code is documentation itself... Unless... there is a problem with the context (which is). So when the people were writing the code, they would not understand the over-engineered code because of their fault. But now we make a step back for our beloved claude because it has small context... It's unfair treatment.

I could go on and on. And all those cultural changes are because of money. So I dub this "goldrush", open my popcorn and see what happens next.

> Third - we just take a big smelly dump on the teamwork - it's easier and cheaper to let one developer drive the whole change from backend to frontend, despite there are (or were) two different teams - one for FE, one for BE.

Agree with your other points, but IMO this one has always been better. You often need to design the backend and frontend to work with each other, and that requires a lot more coordination when it's separate teams.

One of the few things I do kind of like about LLM-assisted coding is that it's helping to bring back "lone wolf" programming. We currently default to using massive teams to build massive software because of all the work involved, but teams have a huge communication/documentation cost, and a lot can leak and be lost the more communication has to happen to get things done. Code assistants cut down on the "all the work involved" part, and I think will help to bring one-man shops back into fashion.

On the other hand, separating FE and BE between two teams, necessitating proper interfaces, can often be considered a feature.

I rarely see #3 yield better solutions, it's usually better to collaborate as a team on requirements and gotchas, but let one person own implementation.

But both backend and front-end? Do everyone have to be full stack?

The fourth point about code commenting is the one that connects directly to the ownership question. When developers write comments to explain intent, those comments are evidence of human creative direction. When Claude writes the code and the comments, and the developer merges without adding their own explanation of the architectural decisions, the record of human authorship disappears along with the institutional knowledge. The documentation problem and the copyright problem are the same problem.

Also, it's supremely easy do the wrong abstractions long term and compromise premature internal designs that will start to starve of human mental modeling, hence explaining with accountability how things work and what the plans are when an incident happens. Also, if the wrong generalizations are introduced, coded correctly and reviewed and approved by AIs, then who's even driving really?

people quickly have forgotten: when copilot was announced, there were warnings not to use it for company code because of the license attribution problem. so what's changed? that anthropic is willing to defend and indemnify?

I opened my popcorn for the unholy trinity of HN x law x AI, your comment was one of my faves, love the purple prose. :)

Reply on news.ycombinator.com