How we use AI in TREK

[mauriceboe]

How we use AI in TREK

TREK is built with the help of AI coding tools. This post explains how, in enough detail that anyone deciding whether to rely on TREK can make that decision with the full picture instead of guessing.

We are writing it because the repository said nothing about it until now. That was a fair thing to criticise. Saying it in a comment somewhere is not documentation, and nobody should have to dig for it.

What we use it for

AI assistance is used across a wide range of work in this project:

• translations
• tests
• boilerplate
• refactoring
• and, in some cases, entire features

That last point is the one people usually want to know about, so we would rather state it plainly than let it be discovered. AI is not a small helper at the edges of TREK. It is part of how TREK gets built.

Who maintains it

TREK is maintained by four people in different countries, working on it in their free time. AI is a tool we use, not a replacement for someone being responsible for the result. Every part of this codebase has a human who can answer questions about it, and "the AI wrote that" is not an answer any of us would accept from ourselves.

How code gets into a release

Nothing goes straight into a release. Every change is opened as a pull request against dev. It is tested there, and only after that does dev get merged into main.

Beyond our own process, the licence does some of the work: TREK is AGPL-3.0, so every line that ships is public and auditable. So are our issues and our security advisories. You do not have to trust our description of the process, you can read the result.

Security

For most people, "AI wrote parts of it" and "is it safe" are the same question, so this part matters.

We publish security advisories on GitHub rather than fixing things quietly. Every GHSA filed against TREK is public, and all of them were resolved in under a week, several within a couple of days. That is deliberate. A project you self-host should tell you when something was wrong, not patch it in silence and hope nobody diffs the release.

It also means the record is checkable. You can read every advisory and see the dates for yourself.

If you find something, please use the security process first so we can coordinate a fix and disclosure. Reports found with AI assistance are welcome too, as long as you have done the work to verify them.

Maintenance and activity

In five months TREK has seen over 600 issues, of which around 550 are closed.

We know that number can be read two ways. A busy issue tracker means "lots of work" to some people and "lots of bugs" to others, and both readings are defensible. What it does show is response time, which is the part we can actually control, and it is public and dated so you can judge it yourself rather than take our word for it.

It says nothing certain about year three. No five-month-old project can prove that. What we can point to is the licence: AGPL means the code stays free and forkable regardless of what happens to any of us.

What we do not claim

We do not currently mark individual commits as AI-assisted. If you look at the commit history, you cannot tell which parts were written with AI help and which were not. We are saying that rather than implying a granularity we do not have.

We also do not claim AI assistance is risk-free. It shifts where the effort goes: less time typing, more time reviewing, testing and understanding. That trade-off is the part we take seriously, and it is why the process above exists.

This post is (soon) linked from the README so that it is visible without having to look for it.