Hacker News Reader

Comment by menaerus | Hacker News Reader

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.

View on HN

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

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.

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.

Reply on news.ycombinator.com