Join me in this thought experiment as I model one potential reality for the future of software engineering.

1️⃣ Code may become a worse training corpus

LLMs are trained mostly on human-produced code. Labs spend a lot of money filtering, curating, and evaluating this data to remove garbage. But consider this: the number of commits on GitHub could grow by more than 10x from 2025 to 2026, with 1 billion commits in 2025 versus 14 billion projected for 2026, if the current pace holds. This additional volume is mostly agent-produced code. Under the assumption that the average LLM-produced code sits below the average backward-looking code quality we can predict that the quality of training data specifically for coding will decline over time, with the downtrend accelerating as more and more LLM-produced code is published.

2️⃣ No more libraries, just build it

There is a growing trend that worries me: avoid dependencies and generate bespoke implementations instead. But for real-world software, this will only result in more code being produced and maintained by AI agents.

3️⃣ Open source may lose one of its strongest incentives, which may slow down innovation

If large companies can point swarms of agents at internal systems, why release the next Kubernetes, TensorFlow, React, or Airflow? Why accept outside governance when internal software can be cheap to maintain and strategically private?

4️⃣ New ecosystems will be optimised for LLMs, not people

Frontier labs are incentivised to make their own models most effective with their own tools, frameworks, agent runtimes, and hosted infrastructure. This means that code, interfaces, and workflows that are easy for a specific model to generate and modify might become increasingly difficult for human engineers to inspect independently because they will not be designed with humans in mind.

5️⃣ New engineers will not develop the skills current engineers have

A software engineer does not just get their knowledge downloaded into their head. They build it by writing and reading bad code, debugging failures, making wrong trade-offs, and especially by breaking production at 5pm on a Friday. If agents write and maintain most of the implementation, how can new engineers develop that muscle memory? A generation of engineers may become excellent at directing systems they do not fully understand: black-box orchestrators. That works until a system fails in a way the agent cannot explain.

My question is: who will still know enough to decide whether that code is correct, safe, maintainable, and worth operating? And when that knowledge becomes scarce, who owns it?