Humans can share context outside the code, while LLMs need it to be more explicitly structured inside. And if we keep the slightly verbose good practices that already help humans understand the intent, we kind of get the best of both worlds.
I agree, but “write code like a human will maintain it” can also be limiting: if LLMs reduce the cost of maintaining more explicit or verbose code, we should use that to raise the standard, not preserve compromises made for human convenience.
It seems possible to optimize for these metrics and still end up with a society where I wouldn’t want to live if I were randomly placed in it (high stress, low trust, poor quality of life).
But to me, what matters is the actual change to main/master at the time the thing is merged — that is what affects the team.
Totally agree, if the developper goes in wrong product direction at the beginning and add 10 additional commits afterwards: team + 6 month actually don't care about it.
I certainly see no point in merging it in when it based on an ancient ancestor
If you want the CI to run, before the merge on the result it will produce on main branch ?
To some extent Tesla could be Starlink's AWS. Every Tesla user could be a potential starlink customer. Could we even imagine a more efficient data collection?
We are using ActiveAdmin to manage our backoffice since few years, but we are facing some issue, especially in dev env, where the more you have models, the slower will be hot reloading of the code.
Before considering to kill it to create a new backoffice in our rails app from scratch, I wonder if some HN people faced these issue and found some best practice to put AA at scale.
"Why does working longer hours not improve the situation? Because working longer makes you less productive at the same time that it encourages bad practices by your boss. Working fewer hours does the opposite."