Hacker News Reader

Comment by colinmarc | Hacker News Reader

Code quality - and its best friend, interface design - pay dividends in large codebases. The fastest moving and most effective organizations I've worked at are ones that focused on code quality from the beginning.

All software is broken, but LLMs seem to make the wrong compromises consistently when working in large codebases.

View on HN

> The fastest moving and most effective organizations I've worked at are ones that focused on code quality from the beginning.

I agree with that in the pre-LLM world, but I don’t believe it’s the same today.

You can build something with “bad” code that works and is full of technical debt, but today paying this debt is getting cheaper and cheaper.

So if Claude’s wrong design decision leads to having to refactor several chunks of a codebase in order to implement a new feature, does it really matter if it’s Claude who is going to refactor it in a matter of seconds? Especially for a company like Anthropic which has a virtually unlimited number of tokens to spend on it.

> today paying this debt is getting cheaper and cheaper.

Like before AI, that debt is never going to get paid. Because how exactly are you paying off that debt when the means of paying are debt generators?

Sounds like converting technical debt to monetary debt that will still ultimately need to be paid. Pay engineers and/or anthropic to fix the problems caused by anthropic. What do you do when anthropic servers are down?

Now instead of the AI agents swarm you let 100 engineers making the changes on that large codebase. How do you keep the code "quality", which is a very subjective thing, while at the same time, as you say, keep the "fastest moving and most effective organizations" trait? Impossible without gatekeeping and thorough review process both of which contradicts your trait.

Good interface design allows extending or changing component X without having to step on the toes of your colleague working on component Y downstream. It's absolutely essential.

Interface design is one of the things Claude is worst at in my experience (using it every day for the past year).

But a little bit of directing of the architecture can easily bring in design patterns.

Ideally, you design patterns that enable quick replacing of parts that get to messy. The code is cheap, just start from scratch with the defined functionality pre defined instead of bolted on with jank.

Or, you could just do the thing today, and accept someone else may change it tomorrow.

That reads as an example from GoF era. In practice, especially with complex software engineering codebases, which I thought you were implying by saying "large", these patterns barely exist because the problems being solved are often in friction with what is considered to be the "best practices" elsewhere (in the books, other much simpler codebases, etc.).

Thank you for engaging with my point! I agree, actually. I think if good design patterns could simply be copied out of a book, LLMs might be better at software engineering.

My point is more about up-front investment paying dividends. To speculate, it seems like the reward hacking is not there for long-term thinking.

I thought that they are already really good at software engineering but I guess that greatly depends on how one defines the "quality".

Gang of Four

I would argue that the "fastest moving and most effective organizations" trait is relative to what we find in the set of software develepment groups. There must be a difference in code quality and development speed between the best and the slowest player, and there must be some parametrizable difference in standards (if there are any) the players operate with.

What would they be?

This is too vague for me to answer but I'll try - effective organization is the one whose revenue and net-profit per employee is higher than their competition. And fastest moving organization would be relative and tightly coupled to being an effective organization too. Reminiscent of a fail-fast culture without red tapes. Software "quality" is IME rarely a discriminator.

It's true though. I've also experienced the difference between a codebase that was an absolute tarpit from the start, and one that obviously focused on quality from the start. They both became jankier over time, but one notably less so. The latter was a bigger, more successful organization. Does that have anything to do with their codebase being cleaner? Maybe. Maybe not. It was certainly easier for me to work in.

Reply on news.ycombinator.com