Unwritten project knowledge holds newcomers back
Boris as quoted by Theo argues that domain knowledge held by existing engineers blocks newcomers from contributing immediately. He proposes encoding that knowledge through comments, skills, and written rules beyond lint, types, and tests. He frames rejected pull requests as automation failures, while Theo supports the core idea but considers that framing too strong.
Record recurring corrections for everyone's agents
Audit the contextual corrections you repeatedly give people joining the codebase and identify what each correction depends on. Put each into a durable form, such as a lint rule, type, architectural structure, or written steering file. Aim that guidance at everyone's agents so the project knowledge is available beyond your own working context.
Write down project rules you keep explaining
This pays when the same project rules have to be explained verbally to every new engineer. The repeated explanation identifies knowledge that the codebase could make available to newcomers and their agents. Do not assume every rejected contribution exposes missing automation, since that is the strong framing Theo qualifies.
Theo doubts non-engineers contribute equally
Boris also claims non-engineers can contribute as effectively as engineers, and Theo explicitly calls that a reach. Theo supports turning knowledge into project infrastructure but says Boris takes that argument further than he would. Preserve the practical effort to make knowledge available without treating equal effectiveness or every rejection as established facts.