docs: describe AI use in my own voice

ai.md

@@ -1,28 +1,32 @@
 # AI assistance
 
-This project was built with help from AI coding tools. The main assistants were
-Codex CLI and Claude Code CLI, using GPT-5.6 Sol and Sonnet 5.0.
+I am an AI-assisted systems developer. I use automation to scale how much I can
+build, but I still own the architecture, the constraints, the integration and
+the final result.
 
-Some code, configuration and documentation were drafted by these assistants.
-Other parts were written by me. I defined the architecture, requirements and
-constraints, decided what belonged in the project, reviewed the generated
-changes, tested them on the real infrastructure and kept responsibility for the
-final result. AI output was treated as a draft or implementation proposal, not
-as proof that something worked.
+For Nereus, the main assistants were Codex CLI and Claude Code CLI, using
+GPT-5.6 Sol and Sonnet 5.0. Some application code, infrastructure configuration
+and documentation were drafted or implemented by those tools. Other parts were
+written by me. The agents handled a lot of the repetitive implementation work;
+I decided how the system should fit together, reviewed the changes and ran them
+against the real environment.
 
-Debugging was mixed. Some problems were investigated manually with logs,
-metrics and command-line tools. Some research used Google and official
-documentation. Other issues were worked through with AI, including longer Codex
-loops that inspected a failure, changed one thing, ran the verification again
-and continued until the real system reached the expected state.
+The debugging process was also mixed. I investigated some failures manually
+through logs, metrics, packet paths and command-line tools. Some research came
+from Google and official documentation. Other problems were handled through AI
+sessions or longer Codex loops that inspected the current failure, changed one
+thing, reran the check and continued until the system reached the expected
+state.
 
-Most failures were not complicated application bugs. They were networking or
-small configuration mistakes: firewall rules between Kubernetes nodes,
-permissions on pod log files, an incorrect image tag, missing RBAC verbs,
-stale credentials after a database reset, or monitoring windows that still
-contained earlier errors. Those failures were only considered fixed after the
-relevant test, deployment, metric query or health check passed.
+Most of the difficult failures were not application-code problems. They were
+networking and integration details: firewalld blocking VXLAN, permissions on
+pod log files, missing RBAC verbs, incorrect image tags, stale buoy IDs after a
+database reset and Prometheus windows that still contained earlier errors.
+Those are the parts I debugged on the actual hosts and cluster. An AI-generated
+configuration was never treated as working just because it looked correct.
 
-No assistant was allowed to invent successful results. The repository roadmap
-uses partial status for work that still needs external hardware or credentials,
-and `docs/evidence.md` records the important checks that were actually run.
+I am responsible for the final project. AI helped type, research and iterate;
+the architecture, acceptance criteria, hardware debugging, system integration
+and final review remained mine. The checks that actually passed are recorded in
+`docs/evidence.md`, and anything still dependent on external hardware or
+credentials is marked honestly in `docs/roadmap.md`.