AI coding agents are brilliant juniors — review like a senior
Working with coding agents: CLI, repos, and reading AI code
The question: How does a non-developer steer an AI that writes and runs real code?
Coding agents (Claude Code, Cursor agents, Copilot Workspace) work in the terminal with full file access: they read your project, write changes, run tests, and commit. Managers who understand this workflow can scope, review and buy software fundamentally better.
What the lesson covers
Why the terminal? Because that is where software actually lives: files, versions (git), tests, builds. A CLI agent can do what a chat window cannot — open your whole project, run it, see the error, and fix it in a loop. The same plan-act-observe loop from Lesson 10, pointed at code.
Git in one paragraph for non-devs: a project is a folder whose every change is recorded as a COMMIT (a snapshot with a message); GitHub hosts the folder so machines and people can share it; deployment services (Vercel) watch it and publish automatically. When your agent says "committed and pushed", it means: change recorded, uploaded, and — if wired — live.
Reviewing AI code without reading code: ask for the CHANGE SUMMARY in plain language, ask what could break and how it was tested, run the thing yourself and click around (Lesson 21's tester discipline), and insist on small commits — five small reviewed changes beat one 2,000-line mystery. Trust grows exactly like the autonomy ladder: evidence first.
The safety rails mirror agent governance: agents work on a branch or with permission prompts, never hold production secrets in plain sight, and every irreversible step (deploy, delete, spend) gets a human gate until proven. This very academy was built this way — a human setting intent and reviewing, an AI agent writing and running the code.
What the agent cannot do for you is the part worth being deliberate about. It will not tell you the requirement was ambiguous, it will not decide what "done" means, and it will not notice that the thing you asked for is the wrong thing to want — because none of those are visible in the code. That is the whole of the human contribution and it is not a consolation prize: the scarce skill in agent-assisted work is writing a brief precise enough to be wrong. A brief you can check is a brief the agent can satisfy exactly, and the discipline of writing one is the same discipline as writing a good acceptance test, which is why the two feel identical in practice.
Key points
- CLI agents = plan-act-observe pointed at your files, tests and git.
- Git for managers: commit = snapshot; push = share; Vercel-style deploys watch the repo.
- Review behaviour, not just code: change summaries, "what could break", run it yourself, small commits.
- Same governance as any agent: branches/permission gates, no secrets in code, human gate on deploy until proven.
- The agent will never tell you the requirement was ambiguous. Writing a brief **precise enough to be wrong** is the scarce skill, and it is the same discipline as writing an acceptance test.
Framework — Scope small → Agent builds → Human verifies → Commit → Repeat
The unit of work is a small, named, testable change. If you cannot describe the change in one sentence, it is too big for one loop.
The lab
Experience the agent loop and learn to review it.
Open this lesson, its lab and its quiz
Sources and further reading
- GitHub — Hello World (git basics, friendly) — GitHub
- Claude Code overview — Anthropic
- Claude Code best practices — how the engineering team actually works — Anthropic