Harnessing the Power of Coding Agents

Coding Agent as General Agent

The name is the worst thing about this technology. "Coding agent" sounds like something for software engineers — a tool you'd have no business touching. That framing costs people the single biggest upgrade available to them right now.

Here's the reframe. Think about what actually runs your job. Your reports live in spreadsheets. Your communication lives in email and chat. Your documents live in a drive. Your customers live in a CRM. Every single one of those is software — and every piece of software is reachable through code. There are exactly three doors in:

• API — how systems talk to each other. Your CRM, your accounting tool, the stock exchange, the weather — almost everything exposes one.
• CLI — the command line: text commands that operate a computer directly. Files, folders, conversions, batch operations — anything your machine can do.
• MCP — the AI-native connector. A standard socket that plugs an agent straight into a tool: your drive, your calendar, your browser, your database.

A coding agent is an AI that can write and run code — which means it can walk through all three doors. It can call the API, drive the CLI, plug in the MCP. And that leads to the thesis of this entire module:

A coding agent is a general agent — because everything in your work is reachable through code.

This is Level 4 on the use-case ladder from Module 2 — and it's the level where things change shape. Levels 1 through 3 made you faster at individual tasks: a chatbot here, an AI feature in a tool there, an automation for one workflow. Level 4 gives you one tool that spans the whole role. The same agent that drafts your report can also clean the data behind it, file the output in the right folder, and log what it did — because to the agent, those are all just software operations on your project.

And the crucial part: you direct it in plain language. You never write the code. You describe the outcome, the agent writes and runs whatever code gets there, and you review the result. The code is an implementation detail — like your accountant's spreadsheet formulas. You care that the numbers are right, not how the cells reference each other.

Claude Desktop & Codex Desktop, hands-on

You reach a coding agent through a desktop app: Claude Desktop (Anthropic) or Codex Desktop (OpenAI). Both put a frontier coding agent behind a chat window and give it a working folder on your machine. And here's the sentence I'll repeat until it sticks: the apps are the interface, not the topic. We're not studying software today. We're learning to direct an engineer — the app is just where the conversation happens.

The working pattern is the same in both, and it's the pattern for everything else in this module:

• Point it at a folder. That folder is the agent's world — the files in it are what the agent can see and work on.
• Say what you want, in plain language. Outcome, not instructions. "Turn these three exports into the weekly report, my usual format."
• Watch it work. The agent narrates: reading files, writing a script, running it, checking the result. You can interrupt and redirect at any point.
• Review what comes out. The deliverable lands in your folder as real files — a report, a cleaned spreadsheet, a draft. Your judgment is the last step, always.

To make it concrete — the kind of requests that work on day one, in your plain words:

When to use which

In the session we run both apps side by side on the same task, and you'll see it immediately: the differences are real but small — interface details, how each one presents its work, house style. The skill is identical. My advice: pick one as your daily driver and go deep — depth in one beats shallow familiarity with both. Keep the second installed for comparison, and because model quality shifts every few months; when it does, your skill transfers in an afternoon. Which one to pick depends on which ecosystem your company already pays for — that's usually the deciding factor, not the apps themselves.

Managing your project — CLAUDE.md, roles, and task instructions

Your first sessions with an agent all share one flaw: you re-explain yourself every time. Who you are, what the report should look like, what "our format" means, what it must never do. The fix is the single highest-leverage file in this entire course: a standing context file that lives in your project folder. Claude Desktop reads CLAUDE.md; Codex reads AGENTS.md. Same idea, same content.

A prompt is what you say once. Standing context is what the agent knows every time.

The agent reads this file at the start of every task, automatically. Which means everything in it rides along on every piece of work — without you typing it again. Four things belong in there:

• Who you are. Your role, your department, what you're responsible for. The agent calibrates everything to this.
• Your SOPs. How the recurring work is actually done, step by step — the same SOPs you wrote down in Module 4.
• Your style. Tone, format, language, length. Definitive statements, not vibes: "short sentences, numbers first" beats "professional tone."
• Your boundaries. What the agent must never do without you — the standing version of human-in-the-loop from Module 1.

A skeleton to steal — this is genuinely enough to start:

# CLAUDE.md

## Who I am
Sales operations manager, retail division.
I own the weekly sales report and the client list.

## My SOPs
- weekly-report.md — how the Monday report is built
- client-onboarding.md — steps for a new client

## Style
Short sentences. Numbers first, commentary second.
Reports in English and Mongolian.

## Boundaries
Never send anything external without my review.
Never modify the raw export files — work on copies.

Notice what this actually is: your role context, made executable. This is the thesis of the whole practice — no consultant could write this file, because no consultant knows your job at this resolution. You do, and it takes twenty minutes. In the session, everyone writes theirs, reruns the morning's task, and compares output before and after. The difference is not subtle.

Skills — teaching your agent your workflows

Task instruction files have a natural next step, and the platforms have formalized it: Skills. A skill is a packaged workflow — instructions, plus any templates or helper scripts it needs — that the agent loads exactly when the task calls for it. If CLAUDE.md is what your agent always knows, a skill is what it knows how to do.

The mental model: teach the workflow once, then replay it on demand. Write down how the job is done — the way you'd train a new hire — and from then on the agent performs it the same way every time. Consistency is the point. Prompting from scratch gives you a different result every run; a skill gives you your standard, every run.

The exercise, which we run live:

• Pick one repetitive task — the one you do weekly and could do on autopilot. Highest reps wins; boring is perfect.
• Write the instructions — steps, inputs, output format, quality checks. If a bright new hire could follow it, the agent can.
• Test it live, three times — on real inputs, including one messy case. Watch where it deviates from what you meant.
• Fix the instructions, not the output — every deviation is a sentence you haven't written yet. Edit, rerun, done.

Skills get better with more eyes on them. Members of the AI Architects community swap theirs and pressure-test each other's instructions.

MCP, CLI & API — connecting external tools

So far the agent's world has been a folder. Your work doesn't live in a folder — it lives in Google Drive, in spreadsheets, in email, on GitHub, in whatever system your company runs on. There are three doors into that software, and a coding agent can use all three.

• MCP (Model Context Protocol) — a ready-made connector. Plug one in, and the tool's actions appear in the agent's hands: read the sheet, search the drive, open the browser. Nothing to build.
• CLI — command-line tools the agent runs in the terminal, like gh for GitHub, vercel for hosting, supabase for databases. If a service ships one, it's often the fastest and most capable route: the full product, one command at a time.
• API — calling the service directly with a key. The agent writes a small script that sends the request. Most flexible, a little more setup.

Each connection removes one manual bridge you used to be: download from here, paste to there, upload back. With a spreadsheet connected, the agent works on the live sheet — not an export. It stops working on copies of your work and starts working where your work lives.

Which one to use

You don't have to pick by hand every time. Tell the agent what you want done, and ask it which door it's using. But knowing the three lets you spot when it's taking the long way round.

In the session, each participant connects the one connection their target workflow actually needs — usually a drive or spreadsheet MCP — and reruns their task end to end. One is enough to feel the shift.

Review, iterate, trust

Here's the shift most people miss: you're not prompting a chatbot anymore. You're working with an AI engineer — and that's a management relationship, not a vending machine. Nobody hands a new hire the keys on day one; nobody should hand them to a new agent either. But a good manager also doesn't hover forever. The skill is moving along that line deliberately.

Three habits make the relationship work:

• Review the output, not the code. You check the report the way you'd check a colleague's: are the numbers right, does it match the source, would you sign it? The code that produced it is the agent's concern — you audit results, and you can always ask the agent to explain, in plain language, how it got them.
• Test with real cases — including ugly ones. Anything can look right on a clean sample. Run last month's actual files, the messy export, the week with missing data. Trust built on real inputs is the only kind that holds.
• Iterate the instructions. Same discipline as Section 4: when review catches a miss, the fix goes into CLAUDE.md or the skill file. Every reviewed run either raises trust or improves the instructions. Both are progress.

Trust is earned per task, not granted per tool.

The weekly report your agent has nailed ten times in a row? Check the totals and ship it. The client-facing email workflow it ran for the first time yesterday? Review every word. Both stances are correct — at the same time, for the same agent. This is Module 1's human-in-the-loop, applied per workflow: you decide where you sit in the loop of each job, and you move as trust accumulates. In Module 6 this becomes a formal dial — the Trust Ladder — when the agent starts acting without you in the room. Today's review habits are what make that step safe tomorrow.

Build: real automations for your actual workflows

Everything above was the toolkit. Now we use it. This is the block where the module earns its keep — you leave with a working automation you built, for a workflow you actually run. Not a demo on sample data. Yours.

The raw material comes from Module 4. You already captured your automation candidates there — each one screened for value (reduce cost? increase speed? optimize quality?) and specified as trigger → engine → output, with a KPI attached. Today, that capture card becomes a build spec. The flow:

• 1 · Pick. Your highest-value card that touches only data you're allowed to use here. When in doubt, take the more boring one — boring means well-understood, and well-understood builds fast.
• 2 · Scope down. Smallest version that produces the real output. Automate the Monday report before the whole reporting function. Task first — SOP, role, and department come later; that's the escalation path, not day one.
• 3 · Brief the agent. Hand it the capture card, the SOP, and two or three examples of past output — your quality bar, shown not described. Then direct: outcome first, corrections as it works.
• 4 · Test on real data. Last week's real inputs. Compare against what you actually produced by hand. Push every fix into the instructions, not just the chat.
• 5 · Package. The workflow becomes a skill file, the standing rules live in CLAUDE.md, and running it is one sentence. Write that sentence down.

Two builders on the same afternoon, from real cohorts: a finance manager whose month-end close prep — pulling five exports, reconciling, formatting the summary — went from a half day to a directed twenty minutes. A department head whose meeting notes now become tracked action items in the team sheet, automatically, in both languages. Neither wrote a line of code. Both can explain exactly how their automation works — because it's their SOP, executed.

The hands-on track

Everything in this module is done, not watched. The five exercises, in order — each one feeds the next:

And that automation is the entry ticket to Module 6. Right now, you initiate every run — the agent works when you ask. Next module, Hermes sits above these desktop apps and starts initiating on its own: on a schedule, on a trigger, on its own judgment — inside boundaries you set. The engineer you learned to direct today becomes part of a system that runs without you pressing the button.