From d4287699138b6fbfda071425ec011a0afe4d2bb9 Mon Sep 17 00:00:00 2001 From: Fi3w0 Date: Fri, 28 Aug 2026 01:52:50 +0200 Subject: [PATCH] docs: describe AI use in my own voice --- ai.md | 48 ++++++++++++++++++++++++++---------------------- 1 file changed, 26 insertions(+), 22 deletions(-) diff --git a/ai.md b/ai.md index 48d103f..80f3bd9 100644 --- a/ai.md +++ b/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`.