The agent principal-agent problem

I've been thinking about it quite a bit, and there's a combination of solutions/improvements that I think is the best approach:

The fact that IC-s can be more productive means that there's much less need for larger team to work on the same codebase. It's better to split the very large projects a bit more than before, and delegate responsibilities over each to smaller team to keep ownership and accountability clear.

More tests, more code documentation. The fact that LLMs can keep track and maintain things means documenting architecture, design decisions, constrains, requirerments, etc. is easier.

Code review and prompt inclusion into code revision. The code becomes more of an intermediate artifact, and actual "source" are the prompts, specs and documentation used to make the agent produce the code. Git history should contain more context about why changes were made and why certain way. Normally devs would not have time to read such long commit messages, at least for normal projects (most projects are not Linux kernel), but agents can handle and use it efficiently.

Review automation. Not long ago LLM-reviews were quite bad and just produce noise and nitpicking, but I've personally seen very well working LLM-review systems now. LLM-review can be greatly customized and use some pre-processing. E.g. you can have agents (asynchronously) scan git commit history for certain components and produce prompts and instructions for review based on on existing code, documentation, requested patterns and bug fixed in the past.

In a way - we are just going to spend quite a large portion of the just gained productivity boost on self-maintanance of the tools (LLMS) and approaches that made it possible.

I've been thinking about it quite a bit, and there's a combination of solutions/improvements that I think is the best approach:

The fact that IC-s can be more productive means that there's much less need for larger team to work on the same codebase. It's better to split the very large projects a bit more than before, and delegate responsibilities over each to smaller team to keep ownership and accountability clear.

More tests, more code documentation. The fact that LLMs can keep track and maintain things means documenting architecture, design decisions, constrains, requirements, etc. is easier.

Code review and prompt inclusion into code revision. The code becomes more of an intermediate artifact, and actual "source" are the prompts, specs and documentation used to make the agent produce the code. Git history should contain more context about why changes were made and why certain way. Normally devs would not have time to read such long commit messages, at least for normal projects (most projects are not Linux kernel), but agents can handle and use it efficiently.

Review automation. Not long ago LLM-reviews were quite bad and just produce noise and nitpicking, but I've personally seen very well working LLM-review systems now. LLM-review can be greatly customized and use some pre-processing. E.g. you can have agents (asynchronously) scan git commit history for certain components and produce prompts and instructions for review based on on existing code, documentation, requested patterns and bug fixed in the past.

In a way - we are just going to spend quite a large portion of the just gained productivity boost on self-maintenance of the tools (LLMS) and approaches that made it possible.