upvote
Exactly. As someone much smarter than me once argued here on HN, the value of a software company is less in the software but much more in the mental map the team has built of the problem and of how the software solves it. Throw the team / mental map away and you'll have a very hard time maintaining the software.
reply
At the same time if the organisation want code fast, it gets code fast.

The revenue for a new feature today is something sure. While the cost associated with supporting such feature will be up to debate in the coming quarters.

As often it is the case, we are moving on a long vs short term trade-off space. And I don't think any experience will generalize

reply
I'm not saying we can get rid of humans (yet). I'm saying that it's not critical to write and review the code yourself anymore, and that the LLM is the new layer of abstraction through which code is written.
reply
I completely agree with everything you’ve said, in the pre-AI world. Now, I’m not so sure.

When I worked at a big tech company on a large codebase (tens of millions of LOC across dozens of repos), it was extremely common to work on something in an area of the codebase I had zero familiarity with, and due to turnover, no one else at the company did either. As you say, docs were frequently missing or out of date.

However, with some effort over a couple hours, I could make a LOT of progress in understanding the history of the code. Every commit and PR were linked to JIRA tickets, most had eng design docs with comments, slack discussions, etc. I could step through the git history and watch the code change, alongside the artifacts of the human discussion and decisions that led to the changes. It wasn’t perfect, but I could make tremendous progress. Now, this was a remote company with pretty strong culture around using JIRA, design docs with review, etc. Probably the biggest gap was meeting transcripts.

Today, an agent can chew through years of history and artifacts on a large codebase in a half hour, documenting as it goes, and have way better understanding of it than I ever will.

It’s true that an agent can’t hold all of that in its head at once without context rot (though this is improving every year), but neither can any human!

If your goal is understanding how to do something, why something was done, why something wasn’t done, etc, and the codebase is large, mature, and extremely well-“artifacted”, I’m not at all convinced that you’re better off asking Bob who has worked on this section of the codebase for a decade than just asking a really good frontier-level agent. Maybe, but it feels like that won’t be true much longer.

reply
> Today, an agent can chew through years of history and artifacts on a large codebase in a half hour, documenting as it goes, and have way better understanding of it than I ever will.

At my last job we worked in a large, but publicly available code base. My experience was that just giving an agent the prompt to look at area X to figure out how it works would use up half or more of the context window. And that was thrown away every time we started again. We had docs, agent generated overviews but the agents still filled their context windows way too quickly to actually really be any use.

reply