The temptation to regenerate the world
AI coding assistants can produce a working authentication module, a job queue or a charting library in minutes. That is impressive, and it creates a quiet temptation: why depend on an external project when the assistant can write one for you?
The answer is that writing code was never the expensive part. Maintaining it is. A mature open-source project carries years of bug fixes, security reviews, edge cases discovered by thousands of users and a community that keeps it current. A freshly generated equivalent carries none of that. It looks finished and is not.
There is a subtler cost too. Every component an organisation writes for itself is one more thing its own people must understand, secure and upgrade for as long as it runs. Multiply that across an estate and the saving from not adopting a dependency turns into a permanent tax on engineering time.
What open source gives that generation cannot
When you adopt a well-run open-source project, you inherit more than code. You inherit its tests, its documentation, its security disclosure process and its upgrade path. You can hire people who already know it. You can read its issue tracker to see how it fails. And when a vulnerability is found, a patch usually arrives for everyone at once.
Generated code has a different profile. Nobody else is running it, so nobody else is finding its bugs. Its provenance can be unclear, which matters for licence compliance. And it tends to multiply: ten teams generating ten slightly different versions of the same utility is a maintenance burden that grows quietly for years.
Where AI genuinely helps
None of this makes AI less useful. It makes the target clearer. The best uses we see put AI to work on the open-source ecosystem rather than around it:
Each of these uses makes the open-source components you rely on easier to adopt and safer to run. None of them requires pretending that a few hundred generated lines are equivalent to a project with years of production use behind it.
- Understanding an unfamiliar project quickly by asking questions of its code and documentation.
- Writing the integration and glue code between proven components, which is specific to you.
- Generating tests, especially for edge cases and near misses that humans tend to skip.
- Drafting documentation and runbooks for the platform you hand over.
- Preparing upstream contributions, so a fix you need benefits everyone.
Contributing back
That last point deserves emphasis. AI lowers the cost of a good contribution: reproducing a bug, writing a clean patch, adding a test and explaining the change. Organisations that use AI to carry private forks are spending that advantage on lock-in to themselves. Organisations that use it to contribute upstream spend it on a healthier ecosystem they also depend on.
Contributions should still be reviewed and owned by a person who understands them. Maintainers are rightly wary of large, unexplained, machine-generated patches. A small, well-tested change with a clear explanation is welcome in almost any project, whoever drafted it.
A simple rule of thumb
Before generating a component, ask whether a maintained open-source project already does the job. If one does, adopt it and use AI to integrate it well. If none does, or what exists does not fit, that is a sign you may be working on something genuinely new, and that is exactly where your effort and your AI tools belong.
Code to innovate, not to re-create. The spirit of open computing has always been to build on each other's work. AI, used well, makes that easier than ever.
This principle also shapes how we build platforms. The components we deliver are established open-source projects wherever one fits, joined together by integration code, rules and documentation that the client owns. AI speeds up that joining work considerably, and the client is left with software their own team, or any other team, can understand.