AI Development Has a Different Kind of Frustration from Human Teams
Tomohiro Iida · Published August 19, 2026 · Updated August 20, 2026
I use ChatGPT, Claude Code, and Codex deeply in day-to-day development. The amount of code I write has fallen and implementation is faster. At the same time, I became unusually frustrated: a session understood a rule and the next session forgot it; an agent said a task was complete while the pull request, main branch, and production were in different states; and I was copying one AI's report into another AI's conversation. This is not a general argument that AI development is good or bad. It is a record of what that supervision fatigue felt like and why I began moving it into the system itself.
Key takeaways
- AI reduced implementation work, but I was compensating for its gaps with human attention and copy-paste.
- AI development has a different kind of non-determinism from a human team: the same instruction is not guaranteed to work across sessions, contexts, models, or execution environments.
- A natural-language report such as “complete” is not evidence. The source of truth is Live State plus evidence tied to the exact SHA under test.
- The design shift is from chasing Agent Intelligence to building System Reliability: a system that remains safe even when an agent forgets or makes a premature claim.
- A Controller, Task Compiler, Planner Agent, Executor, Evidence Ledger, and Gate are concepts for moving human Control Plane work into repeatable mechanisms.
The goal is not to make AI look like a human colleague. Human engineers also misunderstand requirements and miss checks. A healthy team turns repeated mistakes into tests, permissions, review rules, or monitoring. AI-assisted development needs the same discipline, with an additional problem: sessions, contexts, agents, GitHub, CI, and production are easy to separate.
The same rule does not always survive the next session
I have repeatedly had to say: do not push directly to main; do not call a green CI run complete without checking what SHA it covered; confirm the pull request state; confirm the merge; confirm the production SHA; and run the production check. The agent often understood in that conversation. A different session or execution environment could still lose the assumption. Human organizations accumulate operating memory. An AI session does not automatically turn a correction into a durable organizational rule.
“Complete” was not a system state
The most alarming sentence became “complete”. It could mean implemented locally, a draft pull request, a merged pull request, a main branch that had moved again, a deployment still running an older SHA, or a production page that had only been checked while logged out. The conversation had one meaning of complete while the system had several different states.
| Report | Evidence that actually answers it |
|---|---|
| “CI passed” | The required job is green for the exact current subject SHA. |
| “It merged” | The pull request state, merge commit, and current main SHA on GitHub. |
| “It is in production” | The deployment SHA and a production observation for the relevant path. |
| “The page is healthy” | The correct authenticated or unauthenticated smoke path, not only a generic uptime check. |
This is why evidence, rather than an AI self-report, has to be the source of truth. If main or the candidate SHA changes, old verification is stale even when the old job was green.
I became the API between AI systems
| Role | Typical responsibility |
|---|---|
| ChatGPT | Clarify purpose, requirements, constraints, and acceptance criteria. |
| Claude Code | Inspect the repository, implement, test, and prepare the change. |
| Codex | Independently inspect the diff and the evidence before release. |
| Human | Decide priority, risk tolerance, customer value, and publication. |
The role split can work. The expensive part was the connection. Claude Code produced a report; I copied it into ChatGPT; ChatGPT produced the next instruction; I copied that into Claude Code; then I carried Codex findings back into the flow. I was acting as a message queue, router, and Controller while also checking whether every report was true. Implementation labor decreased, but supervision labor increased.
A different kind of non-determinism
Human teams have variation too. AI development adds a distinct kind of non-determinism: an agent can solve a difficult design problem and then miss a simple state check, or follow yesterday's instruction differently after a context, model, or environment changes. The human rule of thumb “I know how far this person can be trusted” does not transfer directly. The safe assumption is that the agent may forget, misunderstand, or declare success early.
From Agent Intelligence to System Reliability
At first I tried longer prompts, stricter instructions, more checklists, and more QC. Those tools still have a place, but they do not enforce permissions or compare a CI subject SHA with the current head. The design axis therefore changed: do not only ask how to make the agent smarter; build a development system that does not break even when the agent is wrong. The priority is **System Reliability over Agent Intelligence**.
This is a design vocabulary, not a product manual. It describes where the human Control Plane is still hiding and which part can be moved into a repeatable boundary.
- Task Compiler
- Turns purpose, constraints, non-goals, and acceptance criteria into an executable Task Contract so a person does not have to fill in ambiguity at every handoff.
- Planner Agent
- Chooses dependencies, allowed paths, verification steps, and stop conditions before an executor edits the repository.
- Executor
- Implements and tests within the approved boundary. It reports observations, but its confidence is not the completion condition.
- Controller
- Reads GitHub, CI, deployment, and production Live State and decides which state transition is actually available.
- Evidence Ledger
- Stores observations such as CI, merge, deployment, and smoke results with the exact subject SHA and an ACTIVE or STALE status.
- Gate
- Stops the next transition when required evidence is missing, stale, or inconsistent with the candidate.
How Netsujo separates ChatGPT, Claude Code, Codex, and human judgment（日本語）The role split and its limits are covered in a separate article.
1. Controller: keep the current state in one place
The Controller distinguishes DISCOVERED, PLANNED, IMPLEMENTED, EXACT_HEAD_VERIFIED, MERGED, DEPLOYED, PRODUCTION_VERIFIED, and READY. It does not infer these states from a conversation. It reads the current pull request, head SHA, main SHA, CI, merge state, production SHA, smoke results, and unresolved blockers. Only READY is a real completion state.
If main advances after a check, the old check remains history but no longer proves the new candidate. The Controller should make that evidence STALE instead of asking a person to remember the invalidation.
2. Evidence Ledger: record what was observed
A sentence such as “production verification passed” is not enough to reproduce a decision. An evidence entry needs a task identifier, evidence type, subject SHA, result, status, source, and observation time. The key is to distinguish “it passed once” from “it still proves the current candidate”.
| Field | Why it matters |
|---|---|
| subject_sha | Identifies exactly which code was observed. |
| result | Separates PASS, FAIL, and BLOCKED. |
| status | Separates ACTIVE evidence from STALE or SUPERSEDED history. |
| source | Names GitHub Actions, production, or the monitoring system. |
| observed_at | Makes the observation auditable later. |
3. Gates: stop without waiting for a human reminder
A final READY gate can be expressed as exact-head CI PASS and ACTIVE, a merged pull request, main equal to the candidate, production equal to main, an authenticated production smoke PASS when required, and zero unresolved blockers. If one condition is missing, READY is false even when an agent sounds confident.
- Scope Gate checks the branch, allowed paths, and change ownership.
- Quality Gate checks lint, typecheck, tests, build, and the exact SHA under review.
- Integration Gate checks the pull request, merge commit, main, and required branch protections.
- Production Gate checks the deployment SHA and the smoke path that real users need, including authentication when applicable.
Parallel AI agents with Git worktrees and integration gatesThe separate article covers workspace, runtime, and integration isolation.
The second correction is an orchestration bug
The number two is not a mathematical law. It is a practical trigger. The first correction is a lesson. When a human has to make the same correction a second time, the orchestration has failed to carry that knowledge. If the rule is objectively checkable, move it into a blocking gate. If it is contextual, keep the human decision but require evidence and an explicit approval.
Do not make every Gate expensive
A system can create a new kind of frustration by running every full test and every QC check for every change. High-risk changes such as authentication, billing, permissions, migrations, and production deploys deserve heavier checks. Lower-risk changes can reuse ACTIVE evidence for the same SHA and use event-driven checks instead of a permanent schedule. Reliability includes the cost of the safety mechanism.
How we redesigned GitHub Actions firing for AI agent workloads（日本語）This article covers path-aware and budget-aware CI triggering.
The human work I want to keep
The purpose is not to remove people from development. I want to spend human judgment on what to build, whether customers are actually struggling, where to invest, how much risk to accept, what to stop, and how to explain an incident. I do not want that judgment consumed by repeatedly checking whether a pull request merged or whether two SHAs match.
The KPI changed too
- Number of human interventions.
- Number of times a human copied information from one AI to another.
- Number of mismatches between an AI completion report and Live State.
- Number of human-discovered AI mistakes.
- Number of repeated corrections of the same kind.
- Number of stale evidence records mistakenly treated as active.
- Total cost and time required to move one change to READY.
If an agent can implement one hundred changes but a person must supervise every one, the system does not scale. The number of times a human is called back is often a better measure of agent operations maturity than the number of tasks an AI claims to have completed.
Frustration is a debugging signal
When I think “why am I checking this again?” I now ask what the system still relies on me to remember, observe, or route. That irritation identifies a remaining human Control Plane. I move it into a Controller, Evidence Ledger, or Gate one item at a time.
Conclusion: build without depending on human endurance
The answer to AI frustration is not to scold an agent more effectively. The answer is to make the development system fail safely when an agent forgets, misreads, or reports too early. I want to build an AI development environment that does not depend on human endurance: humans keep direction and responsibility, while state, evidence, and repeatable stops move into the system.
Frequently asked questions
- Does every second correction become a blocking Gate?
- No. Start with issues that recur, matter, and can be judged mechanically. Contextual design preferences belong in guidance and human approval.
- Is prompt improvement unnecessary?
- No. Prompts still carry purpose, background, constraints, and judgment criteria. Permissions and state verification should not rely on natural language alone.
- What should be automated first?
- Start with objective checks that people repeat: whether CI covers the latest head, whether a pull request merged, and whether production runs the same SHA.