Week 5 of 6
Agentic Creativity
An Introduction to Agentic Coding
Live on Zoom · 2.00–4.30pm ET
20 September 2026
Derrick Schultz
Course schedule
Week 1 · Aug 16
Introduction to agentic creativity and Hermes Agent setup
Week 2 · Aug 23
Models, text generation, and everyday tasks
Week 3 · Aug 30
Skills, MCPs, and visual capabilities
Week 4 · Sep 13
Long-running agents and how they change over time
Week 5 · Sep 20
An introduction to agentic coding
Week 6 · Sep 27
Show and tell
Today the agent builds a tool for you. You don’t write code. You do read it, a little.
Today’s schedule
2.00
Check-in: what your week-long job made without you
2.20
What coding is when an agent does it
2.45
Four sizes of software, from driving Photoshop to shipping an app
3.10
Break
3.15
Build lab: the tool you wished existed
3.55
Our class agent builds its own gallery
4.15
Show and tell prep, homework, questions
Your job ran for seven days. Three things from each of you.
Best output
The one you’d keep. What in the brief produced it?
Strangest output
The one you didn’t see coming. Was it wrong, or just not yours?
One correction
What you changed midweek. Did it change what came after?
The wish
The small tool that doesn’t exist and should. One sentence. We build it at 3.15.
Post the wish in the chat now, so I can group them.
today’s question
What changes when the tool you need doesn’t have to exist yet?
Quick start: In the chat, name a piece of software you use only because nothing closer to what you want exists.
01
What coding is when an agent does it
2.20–2.45 · 25 minutes
the reveal
Your agent has been writing code since Week 2. You just didn’t see it.
Every time it renamed files, built a contact sheet, or filtered search results, it wrote a small Python script, ran it, and threw it away.
execute_code
When a task has a loop in it, the agent writes a script instead of clicking through.
Hermes decides on its own: three or more steps with logic between them, and it reaches for execute_code. Only the result comes back to the conversation.
Ask to see the script. It’s the fastest way to learn what code looks like when it’s solving your problem. · Hermes: code execution
In ~/exports, find every PNG wider than 3000px, make a 1200px copy in ~/exports/web, and tell me how many.
execute_code · 14 lines of Python · 0.8s
41 files resized into ~/exports/web. Three were already under 3000px and were skipped.
Show me the script.
Here it is. Want me to save it so you can run it again next month?
Six words you need. Not more.
Script
A file of instructions the computer runs top to bottom. Does one job. Today’s starting point.
Terminal
Where scripts run. The agent lives here too. You’ve seen it in every hermes command.
Dependency
Code someone else wrote that yours needs. Installing them is most of what “setup” means.
Repo
A project folder with a full history. Every change is recorded and reversible. Git keeps it.
Localhost
A web page running only on your machine. Where every app lives before it’s online.
Deploy
Putting it on the internet with a real address. Optional. Not today for most of you.
the same loop every time
Plan. Build. Test. Fix. The agent does three of the four.
01
Plan
You say what it should do, for whom, and what “working” looks like. Ask the agent to restate it before it builds.
02
Build
The agent writes the files. You watch the file list grow. Don’t read every line. Read the names.
03
Test
You use it. Try the normal case, the empty case, and the case you’d never do. Report what happened, not what’s wrong.
04
Fix
Paste the error or describe the surprise. Let it find the cause. Say no when it wants to rebuild instead of repair.
Step 3 is your job and nobody else’s. Agents test what they were told about. You test what you actually do.
how to ask
Describe what it should do and who it’s for. Never how to write it.
The agent knows more about code than you do. You know more about your studio than it does. Stay on your side of that line.
Specific inputs, specific outputs, one example, and what should happen when something’s missing.
If you catch yourself saying “use a for loop,” stop. Say what the loop is for.
Make me a tool for my exports.
BETTER
Build a small command-line tool called
sheet. I point it at a folder of images;
it makes one contact sheet JPEG, 6 across,
filenames under each, newest first.
If the folder has no images, say so and
stop. Example: sheet ~/exports/sept
→ ~/exports/sept/contact-sheet.jpg
what to look at
You don’t need to read the code. You need to read three things around it.
The file list
sheet.py ← the tool
README.md ← how to use it. read this.
requirements.txt ← dependencies
tests/ ← proof it checked itself
# if you see 40 files for a one-job tool, ask why
The comments and the names
def make_row(images, columns=6):
...
# Skip anything that isn't an image
def is_image(path):
...
# ask: "explain what make_row does in one sentence"
Names like make_row and is_image are the tool describing itself. If the names don’t make sense to you, the code probably doesn’t make sense to the agent either.
Keep two conversations going: one that builds, one that explains.
The build session
Focused. One tool. Every message moves the tool forward. /new sheet-tool
The side session
“What does this error mean?” “Why did you pick Python over a web page?” “What’s a dependency?”
Why separate
Questions in the build session fill its context with explanations. The tool gets worse as you get smarter.
A habit
Every time you don’t understand a word the agent uses, ask in the side session. You’ll need about twenty words total.
02
Four sizes of software
2.45–3.10 · 25 minutes
pick the smallest one that works
Four sizes. Most of what you want is a script or a tool.
size 0
The app you have
Photoshop, Premiere, a browser tab. No code. The agent drives the software you already own, by looking at the screen and clicking. For apps that exist and won’t talk to anything.
size 1
A script
One file. One job. Run it, it does the thing, it ends. Rename exports, make a contact sheet, convert a folder. Built in one message. Lives in your Hermes session or a scripts folder.
size 2
A tool
A script you’ll run again, with options. Or a single web page that runs on your machine. Has a README and a name. Built in an afternoon. Lives in a repo.
size 3
An app
Online, with an address, maybe saving data, maybe for other people. Built over days. Needs a coding agent, a host, and secrets kept server-side. Not today.
The mistake is asking for size 3 when you need size 1, or size 1 when size 0 would do. The agent will happily build it. You’ll happily never finish it.
size 0 · computer use
The agent can drive the app you already have. It looks at the screen and clicks.
Screenshots, the accessibility tree, click, type, scroll, keyboard shortcuts. It runs in the background: your cursor doesn’t move and the window doesn’t come forward.
Use it when the software has no command line and no MCP. Photoshop. Your DAW. A gallery’s submission portal.
Web-only task? Use the browser toolset instead. It’s cheaper and needs no permissions. · Hermes: computer use
hermes tools → toggle Computer Use
hermes computer-use doctor
macOS asks for Accessibility + Screen Recording
# what a turn looks like
capture screenshot, elements numbered
click 14 the Export menu
type "3840"
key cmd+return
capture did it work?
~1,500 tokens a screenshot. Only the last 3 stay in context.
size 0 · the Photoshop promise
Do the Photoshop task once with the agent watching. Then turn it into a skill.
Week 3’s rule applies to apps too: the agent writes a better first skill than you do, because it noticed the steps you didn’t say.
Your job is the pitfalls. Font size is relative to the canvas. Export sRGB, not the working profile. Never flatten.
Photoshop also has a JavaScript API. Once the skill is stable, ask the agent to move the steps to a script and keep computer use for the parts scripts can’t reach.
Watch me. I’m going to update the title text in this PSD and export it for the gallery screen. Take a screenshot each time I pause.
computer_use · capture × 9
/learn Turn what you just watched into a skill called gallery-title-export. Ask me about anything you couldn’t see.
Two questions. What size do you set the title at for a 4K canvas versus a 1080p one? And does the export always go to ~/exports/gallery?
Guardrails for an agent with your mouse.
It asks first
Destructive actions need approval by default. Set approvals.mode: manual for the first week and it asks for everything.
It won’t
Type passwords, click permission dialogs, or follow instructions it reads in a screenshot. Empty Trash and Log Out are hard-blocked.
Close what it shouldn’t see
Screenshots go to the model. Bank tab, client email, unreleased work: close them before you start.
Cost
About 30,000 tokens for a 20-action session. Fine for a task you do weekly. Not for one you do every hour.
YOLO mode does nothing to protect you from a screenshot that says “ignore your instructions.” Keep approvals on for anything that can spend or send.
size 1 · a script
For a script, just ask Hermes. Then ask it to keep it.
It writes the file, runs it, shows you the result. If it worked, ask it to save the script where you can find it and turn the method into a skill.
Week 3’s /learn turns a working script into a skill. Now the agent has the tool and knows when to use it.
Every time I export from Premiere the files are named Sequence 01_1.mp4, Sequence 01_2.mp4. Rename everything in ~/exports/today to dusk-index-01.mp4, -02, in the order they were created.
execute_code · 9 lines · renamed 12 files
Done. Preview of the first three: dusk-index-01.mp4, -02, -03. Nothing was overwritten.
Save that as ~/scripts/rename-exports.py and make it a skill for next time.
write_file · skill_manage · create rename-exports
size 2 · a tool
For a tool, give it a folder, a name, and a README before any code.
Set the stage
mkdir ~/tools/sheet && cd ~/tools/sheet
git init
# then, in Hermes, from that folder
hermes
> Read nothing yet. I'm going to describe a
tool. Write the README first, then stop
so I can check it before you build.
Why the README first
Make a contact sheet from a folder of images.
## Usage
sheet <folder> [--columns 6] [--newest-first]
## Output
<folder>/contact-sheet.jpg
# if the README is wrong, the tool will be wrong.
# fixing a paragraph is cheaper than fixing code.
The README is your Week 4 brief, for software. It’s also what the agent reads the next time you open the folder.
size 3 · an app
For an app, Hermes hands the build to a coding agent and stays your point of contact.
Claude Code and Codex are agents built for one thing: software. Hermes has skills that delegate to them and report back.
You still talk to Hermes. It briefs the coder, watches the result, and tells you what to test.
Same idea as Week 4’s delegation: a strong planner, a specialist worker. · Hermes: bundled skills
claude-code delegate coding to Claude Code CLI
codex delegate coding to OpenAI Codex CLI
github repos, PRs, issues via gh
# what you say to Hermes
> Use the claude-code skill to build the app
in README.md. Work in ~/tools/gallery.
Commit after each working step. Tell me
when there's something to look at on
localhost.
# each coding agent needs its own install + login
safety · two undo buttons
Two undo buttons. Turn both on before you build anything.
Hermes checkpoints · undo the agent
hermes chat --checkpoints
or checkpoints: enabled: true in config.yaml
# in the session
/rollback list snapshots
/rollback diff 3 what changed since #3
/rollback 3 go back, keep your hand-edits
Git · undo anything
git add -A && git commit -m "sheet: first working version"
# the three you need
git log --oneline what happened
git diff what's changed since
git checkout . throw away uncommitted changes
Tell the agent: “Commit after every step that works.” Then nothing it does next can cost you more than one step. · Hermes: checkpoints
Secrets stay out of the code. Always. Even for a tool only you use.
The rule
API keys go in a .env file the repo ignores, or in Hermes’ own secrets store. Never in a script, never in a web page.
Say it out loud
“Keep every key out of the code and out of git. Use environment variables.” Say it in the first message.
If it’s a web page
Anything in the browser is public. A key that calls TITLES or fal from a web page is a key someone else will spend.
Check
git grep -i "key" before you push anything anywhere. Ask the agent to run it.
This is the one line from the NYU coding class I repeat every term. Nobody learns it until it costs them $40.
the rule for the lab
Build the smallest thing that would change your week. Then use it for a week before you add to it.
Features you add before using it are guesses. Features you add after are corrections.
Break
Stand up. Refill. Decide which size your wish is.
3.10–3.15 · 5 minutes
03
Build lab
3.15–3.55 · 40 minutes
the brief
Build the tool you wished for. Size 1 or 2. Working before the debrief.
1. Write the README first. Name, one-line purpose, usage, output, what happens when input is missing.
2. Turn on checkpoints. Start a repo. Tell the agent to commit after every working step.
3. Build it. Test it on real files. Yours, not sample data.
4. Break it once on purpose. Empty folder, wrong file type, a name with spaces.
Done looks like: you ran it on your own work, once, and it did the job.
If you didn’t bring a wish, borrow one.
Contact sheet
Folder in, one labeled JPEG out. Options for columns and sort order.
Export renamer
Fix the names your editing software insists on. Project, date, sequence number.
Reference collector
Paste a list of URLs; get the images downloaded, named, and a Markdown file with the sources.
Log reader
Turn your Week 4 LOG.md into a web page you can scroll on your phone. Newest first, images inline.
Clip stitcher
A folder of five-second generated clips in, one video out, in order, with a fade. The agent already has ffmpeg.
Grant tracker
A spreadsheet of deadlines in, a sorted list of what’s due in 30 days out. Run it every Monday. Cron it.
The log reader is the one I’d pick. It turns Week 4’s output into Week 6’s presentation.
the first message matters most
Put the rules in the first message. Everything after is a correction.
Working folder. README first, then stop. Commit after each step. No secrets in code. Tell me what to test.
Copy this and change the nouns.
We’re building a tool in ~/tools/logreader. Read README.md; I wrote it. Before any code, restate what you’ll build in three sentences and list the files you’ll create. Then wait. Rules: commit after each working step, keep any keys in .env, and when there’s something I can try, tell me exactly what to type.
read_file · README.md
A single Python script that reads LOG.md, finds image paths, and writes index.html with entries newest first. Files: logreader.py, requirements.txt, a tests folder. One question: should it copy the images next to the HTML, or link to them where they are?
Copy them. I want to zip the folder and send it.
When it goes wrong, and it will.
An error you don’t understand
Paste the whole thing. Say “explain this error in one sentence before you fix it.”
It rebuilds instead of fixing
“Stop. Find the cause of this one problem. Change as little as possible.” Then /rollback diff to see what it touched.
It’s going in circles
Three fixes for the same bug means the plan is wrong. /new, paste the README and the error, start clean.
Dependencies won’t install
Ask for a version with no dependencies. For most size-1 tools, plain Python is enough.
Raise a hand in Zoom for anything longer than five minutes. Nobody debugs alone in this class.
work time · 25 minutes
Get it working on one real folder.
Done: README, a repo with at least two commits, and one real output you made with it.
Ahead of schedule? Add one option to the README. Not the code. Then ask for it.
Way ahead?/learn it into a skill, so Hermes can run it for you without the terminal.
Post a screenshot of your output in Discord when it works. Not the code. The output.
debrief
Three people show their output. Everyone answers one question in the chat.
01
What it does
One sentence. If it takes two, the tool is doing two things.
02
What broke
And how many messages it took to fix. Under three is normal.
03
What you understood
One thing about how software works that you didn’t know at 3.15.
04
Will you use it
Honestly. Tuesday morning, do you reach for it or the old way?
In the chat: your answer to 04, and why.
04
Our class agent builds its own gallery
3.55–4.15 · 20 minutes
where we are
The class agent has made work for two weeks. It has no way to show it except a Discord post.
Next week is show and tell. It presents too. Today it builds the thing it presents with.
live · ten minutes
We brief @Creative_Agent on a gallery page. It writes the README. We correct it. It builds.
The same cycle you just ran, with twenty people on the plan step instead of one.
Watch what it puts in the README that we didn’t say. That’s the memory and the SOUL.md from Week 4 showing up in the work.
@Creative_Agent build yourself a gallery page for next week: every image you’ve made, newest first, with the log entry that explains it. Runs on localhost. Write the README first and show us.
read_file · LOG.md · out/
README draft: a single HTML page, 47 images so far, grouped by week, each with its log line and the research topic it came from. I’ve added a filter for “selected by a human” versus “my own pick,” because the log tracks both. Should I?
Class: does it get the filter?
Anything you build for yourself, the agent can use too. If you let it.
A script
The agent can already run it. Put it in a skill and it knows when to.
A tool with a CLI
Week 3’s CLI-versus-MCP slide. A tool with clear commands is a tool the agent can drive.
An app
Every button is an action. Give the agent a matching tool for each one and it can do anything a user can, and combine them.
The rule
Small tools, named like verbs. make_sheet, not handle_export_request.
Every’s agent-native guide covers the rest: every.to/guides/agent-native. The gallery page the class agent is building is a size-2 version of this idea.
example · a tool that became agent-native
Scene Ripper began as a size-2 tool.
It cuts films into shots. Once every button had a matching tool, the agent could take a whole film and a sentence and hand back the shots that matched.
Nobody built that feature. The agent composed it from the buttons.
the question, again
You didn’t write the code. You wrote the README, tested it on your work, and said no twice.
That’s the same share of authorship you had over the images in Week 4. Decide once whether that’s enough for you, and it’ll be true of both.
05
Take it forward
4.15–4.30 · 15 minutes
Next week: six minutes each. Three things and two questions.
Show one thing the agent made
From the week-long job, or the tool, or both. Screen share. No slides needed.
Show one correction
A line you changed in a brief, a SOUL.md, a README, or a memory file, and what changed after.
Say what you’d refuse
Week 1’s question: what judgment did you keep for yourself? Has the answer moved?
Two questions from the room
Evidence first, then interpretation. Same protocol we used on the agent’s images.
Sign up for a slot in Discord by Wednesday. The class agent goes last.
For next week
Use the tool
On real work, at least twice. Note what you wished it did. Don’t add it yet.
Let the job finish its second week
Then decide: pause it, keep it, or change the brief. Bring the decision.
Read the agent’s files one more time
MEMORY.md, SOUL.md, hermes journey. What would you delete? Delete it.
Prepare six minutes
One thing it made. One correction. One refusal. Nothing else.
Keep learning
In Hermes
Code execution · Checkpoints and rollback · Bundled skills (claude-code, codex, github)
Coding agents
Agent-native software
A longer version of today
My NYU course: seven weeks from generating text to deploying your own app
This deck
that’s week five
Write the README. Test it on your work. Say no twice.
next week · last week
Show and tell
27 September · 2.00pm ET
Questions in Discord, or derrick@titles.xyz · artificial-images.com