Things that made me think: Open Source trust relationships, knowledge without provenance, and theory building

By Tom Renner

June 15, 2026 - 3 minutes read - 505 words

This series is a place to collect interesting things I’ve seen, read, or heard, along with some brief thoughts (often incomplete and/or inconclusive) that they provoked.

AI Agent Lands PRs in Major OSS Projects, Targets Maintainers via Cold Outreach – socket.dev

Back in February this report landed in a security blog, and I found it fascinating. As is usual for me, it’s at the intersection of human behaviour with technological automation that the real interesting problems lie.

The whole industry uses GitHub profiles as a proxy for a CV. Now agents can build a credible looking one in hours or days, and it results in our whole system of reputation and trust being borked.

Once again, the thing you should be optimising for is trust. I wonder what new systems we need to build to deal with the old ones being broken.

Where Provenance Ends, Knowledge Decays – Jessica Talisman

My first job was building information management systems, and for those of you that haven’t worked in the industry, let me tell you: knowledge architecture is fascinating. We should all be hiring librarians to help us with these problems.

The core question posed here is: without provenance how can users interrogate the answers from LLMs? How do you then challenge the all-knowledgeable answer machine?

And a key point, countering the attempted solutions of the big LLM vendors – CITATIONS ARE NOT PROVENANCE – the training set is critical to understand the context to your answers, not just the retrieval path.

Given the many reports of click-through rates dropping on Google as people increasingly rely just on the AI summary, this is an important topic for search in general.

Programming as Theory Building – Peter Naur

This resonated very strongly with me, and helps clarify lots of my thinking about team building and software product development.

But accepting that the thing you’re building is the theory, not the textual representation (ie. the code), the cost of organisational changes (eg. losing engineers after a year or two, changing team topology too often, etc) is clear – you are destroying the very thing you’re trying to build.

What I still need to think more on is how does this play with the capitalist reality in which businesses operate? What you’re selling is the product, not the theory – this creates a tension between the priorities of the team and those of the business.

If not the theory, then is the text the product? Also no! Look at all the things that comprise the sold product that are not the textual artefact: user education, documentation, training, etc. The marketing cliché “we sell solutions” is a clear signal that the text is also not the product.

So if neither the theory nor the text are the product, is there a better concept for software teams to align to, for maximising their commercial impact? Probably not a singluar one, I’d bed. My hunch is that the most “product-aligned” concept will vary depending on whether you want short, medium, or long-term impact.