I don’t write code. On August 24 I submitted five PRs to three Tari repositories using the process below. One has passed maintainer review and all CI tests and is merged into tari-ootle.
This post explains how the process works and where I think its limits are.
1. Why I did this
My contributions to Tari so far have been Chinese community management, answering questions, writing articles and organising material. That work has value but it does not reduce the workload on core developers.
There are people in the community willing to spend time. They know the community and they know the problems users run into. But they don’t code, so they have no way to turn that into something a developer can use directly.
The question I wanted to test is narrow: can someone who doesn’t code produce contributions that enter the real review process, without adding load to maintainers.
2. Tools
I use two separate AI tools:
- Hermes Agent, running on my ChatGPT Business access, handles investigation, task design, and independent review afterwards
- Claude Code handles code inspection, making the changes, and running tests
Both run on the same VPS but I operate them differently. I talk to Hermes through a Telegram bot. I use Claude Code over SSH.
I move tasks and results between the two and decide at each stage whether to continue.
To be accurate about this: the AI does perform the commit, push and PR submission. Every one of those requires my explicit approval first. The distinction is approval, not who runs the command. No step proceeds on the AI’s own judgement.
3. The process
3.1 Picking a problem
I look for problems in real code, documentation, issues, or normal use.
Before starting I have Hermes check:
- whether the problem is real
- whether someone is already working on it
- whether a duplicate issue or PR exists
- whether the scope is clear enough
- how to reproduce and verify it
- what situations require stopping and asking a developer
If the problem touches protocol design, security critical code, or has no clear way to verify a fix, I don’t let the AI proceed.
3.2 Hermes prepares the task
After investigation Hermes writes up a complete task containing:
- confirmed facts
- what may be changed
- acceptance criteria
- tests to run
- what must not be guessed at
- stop conditions for uncertain situations
I hand this task to Claude Code myself.
3.3 Claude Code makes the change
Claude Code starts from the official code, examines the problem, makes the change and runs tests.
If it finds the situation differs from the task description, or it cannot judge the correct approach, it must stop and ask. It cannot widen the scope on its own.
When done it provides a patch, test records, an explanation of results, and known limitations.
3.4 Hermes reviews independently
Claude Code saying it’s done is not a reason for me to believe it.
After my explicit authorisation, Hermes reads the specified handover material, fetches the official code again, sets up a clean review environment, and rechecks:
- whether the patch applies cleanly
- whether the changes exceed scope
- whether unrelated files got mixed in
- whether the original problem reproduces
- whether the problem is actually fixed
- whether the tests Claude Code claims passed still pass
- whether any sensitive information or other risk is present
Claude Code’s test report is a claim to be verified, not final evidence.
3.5 I approve submission
Only after review passes do I approve commit, push and PR submission. Hermes performs those operations.
3.6 Post-submission recheck
Once the PR is public, Claude Code performs a read-only recheck of the public PR on GitHub and produces a report. It cannot change anything at this stage.
I then authorise Hermes to read that report and verify its conclusions as a final confirmation.
This step looks at the actual public state, not the local environment. The final conclusion is still verified by the other tool. Claude Code does not certify its own changes.
After submission Tari maintainers have the final say. AI cannot replace maintainer judgement.
4. Why two AI tools
The point is not speed. It’s that development and review are done by different tools.
If one AI both makes a change and certifies that the change is correct, it can repeat its own mistake. The two tools use different working directories, and Hermes fetches the official code again when reviewing.
A second AI rechecking does not guarantee correctness. It lowers the risk of an error going unnoticed through the whole process.
5. The five PRs
All five were submitted on August 24:
-
Fix broken links on RFC pages docs: fix broken links in RFC pages by xt1085 · Pull Request #193 · tari-project/rfcs · GitHub
-
Fix the CryptoNote whitepaper link docs: fix CryptoNote whitepaper link by xt1085 · Pull Request #194 · tari-project/rfcs · GitHub
-
Fix headings hidden behind the fixed menu after anchor navigation fix: keep anchored headings below sticky menu by xt1085 · Pull Request #195 · tari-project/rfcs · GitHub
-
Correct the copyright holder in the WASM project template fix: template copyright holder by xt1085 · Pull Request #62 · tari-project/wasm-template · GitHub
-
Fix Tari Ootle incorrectly shortening short strings fix(bindings): avoid shortening small strings by xt1085 · Pull Request #2475 · tari-project/tari-ootle · GitHub
As of August 25, the fifth has passed maintainer review and all CI tests and is merged into tari-ootle. The first has formal maintainer approval and is waiting on confirmation from a developer familiar with the history. The other three are awaiting first review.
Worth stating plainly: four of the five are documentation, links and display issues. Only the fifth involves code logic.
That composition is deliberate, not accidental. These results show the path works. How far it goes needs more samples.
One more thing. All five went in on the same day. I won’t keep that pace. Submitting several PRs at once takes up maintainer attention. If the review feedback on this batch is negative I will stop and discuss rather than submit another batch.
Update: August 27
Since this post was published, PR #193, PR #194, and PR #195 have all been merged. PR #62 is still awaiting its first review.
I have also completed a sixth contribution using the same Hermes and Claude Code process, adding a template testing tutorial to Tari Ootle:
https://github.com/tari-project/tari-ootle/pull/2481
The PR passed maintainer review and all CI checks and has been merged. The corresponding issue:
https://github.com/tari-project/tari-ootle/issues/2247
Five of the six PRs have now been merged.
6. Cost
In time, all the work on these five PRs was done within a single day, August 24. That covers selection, investigation, changes, review and submission. It was not continuous. I did it in pieces through the day with other things in between. The actual time spent was less than a full day.
In money, what I currently pay is:
- ChatGPT Business to run Hermes, £11 a month
- Claude Pro to run Claude Code, $20 a month
- one 2 core 12GB VPS with both tools installed
There is no metered API billing. These are the rates on my own account. Plans and regional pricing differ, so check the current prices yourself rather than budgeting from my numbers.
I list this because anyone wanting to reuse this process needs to know the cost first. It is not low for some community members, and subscription plans have usage caps that bind when the workload is heavy. That is the real barrier at the moment and I don’t want to make it sound easier than it is.
Also worth stating: I have one day of experience with this. The judgements below come from that day, not from long term use.
7. What this fits and what it doesn’t
Based on this attempt, I think it suits work with clear scope and verifiable results:
- investigating and reproducing bugs
- testing existing fixes
- adding test cases
- fixing documentation and broken links
- checking display issues
- improving tutorials and usage docs
- organising issues and technical discussions
- small changes with well defined boundaries
I would not use it for protocol design, security critical code, anything involving funds or keys, or large tasks with no clear acceptance criteria.
8. You can do this too
If you know Tari and are willing to spend time, but have not had a way to contribute because you don’t code, you can use this process.
You don’t need development experience. What you do need is to find a real, small problem, not simply believe the AI when it says the work is finished, and stop to ask questions whenever you are unsure.
You don’t need a server either. I use a VPS for convenience, but both tools can run on your own computer. The real cost is the two subscriptions.
I can provide the prompts I use, the task template, the review checklist, and guidance through your first submission.
If you’d like to try this process or have any questions, reply below or message me on Telegram at @xt1085