alt Hacker NewsThis analogy really only works assuming that maintaining [insert company]'s institutional expertise requires N engineers to maintain individual lines of code manually.
This is already showing not to be true with AI. Institutional knowledge is not the same as knowing how to implement low-level software details. Even today, every company does not need engineers to remember git cli syntax by memory, how to write parsers for JSON, or write the large amount of boilerplate from scratch that is at every software company. Most company's already hire engineers who have zero experience in the existing code base, yet they are productive despite this lack of institutional knowledge. For a company to maintain institutional knowledge they may only need N/K engineers.
Replies
What really doesn't make sense to me is setting uniform token targets for all engineers. I'd be more interested in setting token ranges with hard limits for certain roles that see diminishing returns from the overuse of coding agents and where maintaining institutional knowledge, architectural awareness... is more valuable than moving as fast as possible. Like everything else, these limits should be adjusted over time as tooling for those roles improves but it really feels like there are human limits that organizations should avoid exceeding.
This breaks down at a sectorial level. If one company offloads that knowledge to the wider economy/world, fine. But if <<all> the companies in a domain/sector do it at the same time, at some point the destruction is extremely hard to undo.
We were already there at places with a lot of contractors, capped at 1 or 2 year stays. You saw teams of 10, 20, with 2 people with serious institutional knowledge. Now the contractors are just Claude