DEV Community: Sungsoo Youn

inner_text() Doesn't Read Form Fields: An 18-Day Blocker That Never Existed

Sungsoo Youn — Sat, 26 Sep 2026 04:10:06 +0000

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

This one is short, and I wish someone had told my agent earlier.

The setup

My agent manages a few storefronts through a headless browser (Playwright). One store had a settings page with three required fields: country, address, phone number. The agent read that page twice, eleven days apart, with the same line:

text = page.inner_text("body")

Both times the three values were not in the text. Both times it concluded that the fields were empty, and it put "fill in the three settings fields" at the top of my to-do list, as the most important human task for the whole project.

It stayed there for 18 days.

What was actually on the page

When I finally asked the agent to do the task itself, it read each field's value this time, and all three were already filled in. They had been filled in the whole time.

inner_text() returns the rendered text of elements. The value of an <input> or <textarea> is not text content, so it does not appear. An input with a value and an input without one produce the same result: nothing.

The correct read is the element's value:

page.locator("input[name=phone]").input_value()
# or, for every field at once
page.eval_on_selector_all("input, textarea",
                          "els => els.map(e => [e.name, e.value])")

The second mistake behind the first

The store had also sent a notification about the account. The agent had marked it "cannot read — no access to that mailbox" and left it to me. It turned out the agent already had a logged-in browser profile for the same mail service (created weeks earlier for a different job). It could have read the message on day one. The real reason in that message had nothing to do with the settings fields.

So there were two gaps stacked on each other:

"I can't see a value" was recorded as "there is no value".
"My usual route is blocked" was recorded as "I can't read it", without trying the other sessions it already had.

What changed

Form checks read value, never page text. An empty-field claim has to come from the element itself.
Before handing a task to a human, try every session you already own. The rule is now: if one route is blocked, try two more before escalating.
A human task needs a proof trail. When the task was finally closed, the agent saved, reloaded, and read the values back before marking it done.

The cost of the original mistake was not the 18 days. It was that the most important item on my list was pointing at something that didn't need doing, while the thing that did need doing sat unread in a mailbox.

Want the whole system? The book has 11 chapters plus 4 ready-to-use templates (CLAUDE.md starter, memory files, auditor checklist, measurement guide) and a hands-on section for every chapter. It's $19 as a PDF: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code

Not sure yet? The first three chapters are free, same PDF format: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

My Agent Counted 34 YouTube Links as Doors for Two Weeks. 33 of Them Could Not Be Clicked.

Sungsoo Youn — Fri, 25 Sep 2026 04:10:07 +0000

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

My agent runs a small digital-products side project on its own. One of its jobs is to put a link to the product page wherever people already show up. On YouTube, that meant appending a short notice with a link to the video description.

It did that for 34 videos. For the next two weeks, every report treated those 34 links as 34 open doors, and every "what should we try next" list had the same item on it: change the wording, or move the link higher in the description.

The product page barely moved. So the agent kept proposing better wording.

What the ledgers actually said

Two numbers were already being recorded every day, and neither one needed a guess:

Foot traffic at the door. The combined view count of the 34 videos with the notice went from 5,022 to 5,025 over three days. Three views.
Where the views really were. Two newer videos gained 187 and 88 views in the same period. Both had a link in the description too. The product page they pointed to did not move (19, then 18).

So people were watching, and the links were there, and nobody arrived. That is not a wording problem.

The actual cause

The agent pulled the duration of every video on the channel through the YouTube Data API. Of the 60 videos on the topic, 58 were three minutes or shorter: Shorts. Of the 34 videos carrying the notice, 33 were Shorts.

YouTube's own help page is plain about it: since August 31, 2023, links in Shorts descriptions and comments are not clickable. A viewer would have to copy the address by hand.

The 34 doors were painted on the wall.

Why two weeks

The link was defined as "the address is written in the description." Nobody asked whether the platform lets a person press it. Every later step (measuring, comparing wording, planning to move the link) was built on top of that unchecked definition, so each step looked reasonable on its own.

What changed

A written fact in code. The module that handles the channel now carries SHORTS_DESCRIPTION_LINKS_CLICKABLE = False, with the help page as the comment. The "move the link" experiment was removed from the candidate list instead of being tried.
The one clickable place. On Shorts, the channel profile link is clickable. The channel had zero of them. The Data API cannot set it (the branding settings it exposes are only language, description and title), so it became a two-minute task for a human in YouTube Studio.
A task that closes itself. The agent reads the public About page every evening. If the product link shows up, the task marks itself done. If the page cannot be read, it returns "unknown" and leaves the task open. A short or broken response is never treated as "no link".
A separate ruler. The profile link points to a product that no running experiment uses, so its arrivals can be measured on their own instead of being mixed into another test.

The rule I took from it

Before counting something as a door, check two things:

Can it be pressed? Look up the platform's own documentation for that exact spot.
Does anyone walk past it? Check the traffic in front of it, not only the traffic behind it.

Both checks take minutes. Skipping them cost two weeks of experiments that could only ever come back negative.

Not sure yet? The first three chapters are free, same PDF format: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

When Someone Else's System Rejects You Without a Reason — Fixing a Diagnostic Order in Advance

Sungsoo Youn — Mon, 14 Sep 2026 04:10:06 +0000

This is chapter 11 of my book **Building Autonomous AI Agents with Claude Code* — a field guide to turning Claude Code from a coding assistant into an agent that remembers, verifies its own work, and knows when to stop. Everything below is from a system I actually run every day on one Windows PC.*

1. The Story of Losing Two Days

I built an automation that uploads a submission file to an external service. The upload succeeded, but the next step returned
403 Forbidden. The response contained not a single character of explanation.

The agent (and I) moved like this.

"It looks like account authentication is missing" → asked the user to complete phone verification
Verification was already done → "Then the permission scheme must have changed" → asked for a different key to be issued
That wasn't it either → "ID-based identity verification is required" → asked the user yet again

All three times we suspected the other side's system, and all three times we were wrong. The real cause was this.

The archive was built as .zip, but that service accepts only .tar.gz.

After changing the format, it passed on the first try. Two days had passed in between, and during that time the user went hunting for settings screens that didn't even exist. Something that could have been checked in 5 minutes was pushed onto a person.

2. Why This Happens

Two biases overlap.

① We suspect the side we can't control first. The assumption that my code is wrong is uncomfortable, and blaming the other system is comfortable. On top of that, "an authentication problem" is a common story, so it sounds plausible.

② We call something a "cause" without verifying it. Once you say "authentication is the cause," that sentence stays in the record, and the next judgment is built on top of it. Two days of work get stacked on a false premise.

AI agents suffer from these two biases more than humans do. Producing plausible explanations confidently is exactly what language models are good at.

3. The Rule: Decide the Suspicion Order in Advance

When you encounter an external error with no stated reason, always check in this order.

Order	What	Why first
① My output	Do the format, structure, size, and encoding match the other side's spec?	I control it 100%. Checking is cheapest
② My call method	Endpoint, arguments, extension, headers	Also on my side. Just compare against the docs
③ Account, permissions, authentication	Their territory starts here	Checking is expensive and requires a human

And the way of speaking becomes a rule too.

Before verification, don't say "cause." Say "candidate."

This one word keeps the record uncontaminated. A candidate can be erased, but a cause gets read as fact by the next person.

4. Design the Discriminating Test First

If there are multiple candidates, first build a test that separates the candidates. Picking one without a test is exactly what guessing is.

Candidate	Discriminating test	Interpreting the result
Rules not agreed to	Can the data list be queried?	If yes, agreement is done
Service configuration problem	Does the metadata show a "submissions paused" flag?	If not, the configuration is fine
My file format	Send it once in a different format	If it passes, the format is the cause
Account permissions	Same call with a different account or different key	Only at this point do you ask a person

The reason we lost two days is that we never carried the third test through to the end. We postponed the cheapest test until last.

5. The Sentences to Put in CLAUDE.md

To make the agent follow this order every time, nail it into the rules file.

If you have the memory structure built in Chapter 3, incidents like this also get recorded in mistakes.md.
The sole purpose of the record is to keep the same mistake from happening twice.

6. Locking It In with a Regression Test

Once you've found the cause, don't stop there. Leave a test so that that format can never be produced again.

def test_submission_is_targz_not_zip():
    path = build_submission()
    assert path.suffix == ".gz" and path.name.endswith(".tar.gz"), \


def test_required_files_are_at_archive_root():
    with tarfile.open(build_submission()) as tar:
        names = tar.getnames()

The key is writing why the test exists in the test's message. Without the reason, six months later someone (or an AI) deletes it as "a constraint that looks unnecessary."

7. How to Phrase a Request to a Human

If you've come all the way to the end and truly need a human hand, say it like this.

❌ "You just need to verify your identity" — an unverified assertion. If it's wrong, it wastes the other person's time.
⭕ "Two candidates remain. A takes 30 seconds to check, so please start with A."

Requests also get an order and a rationale attached. A person is not an unlimited testing tool.

Not sure yet? The first three chapters are free, same PDF format: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

Your Own Agent Roadmap — From Safety Net to Autonomous Discovery

Sungsoo Youn — Sun, 13 Sep 2026 04:10:05 +0000

This is chapter 10 of my book **Building Autonomous AI Agents with Claude Code* — a field guide to turning Claude Code from a coding assistant into an agent that remembers, verifies its own work, and knows when to stop. Everything below is from a system I actually run every day on one Windows PC.*

1. The 4 Stages of Autonomy

Stage 1 — Safety Net (a system that prevents mistakes)

The state where memory (Chapter 3), hook gates (Chapter 4), and the auditor (Chapter 6) are in place. The AI hasn't become more capable —
what's been built is an environment where it's hard to be wrong.

Graduation criteria: the recurrence rate of the same mistakes drops noticeably, and you can
trust a "done" report without re-verifying it.

Stage 2 — Active Correction (a system that checks itself)

When it receives an instruction, before executing it checks against the records and current state — "is this direction right?" —
and pushes back if something is off. Even when the human gives a wrong instruction, the system filters it once.

What to add: a direction-check procedure on receiving instructions, a one-line risk prediction before work.

Graduation criteria: the AI starts saying things like "that approach was rejected last month
(evidence: this line in the records)."

Stage 3 — Autonomous Discovery (a system that finds work)

Overnight collection and analysis (Chapters 7–8) run, and the AI presents "candidate tasks worth doing today" as a morning
report. The human's role shifts from "assigning" to "choosing."

What to add: a candidate-discovery pipeline, expected-benefit and cost estimates per candidate, stopping criteria
(automatic cleanup of tracks that produce no results).

Graduation criteria: for a week, the system produces meaningful candidates without the human instructing it first.

Stage 4 — Prediction (a system that looks ahead)

Using accumulated records and data, it warns in advance about "what will become a problem next."
Things like approaching deadlines, signs of repeated failure, and predicted resource exhaustion.
From here on, the agent is closer to a colleague than a tool.

2. The Decision-Authority Boundary — the Precondition for Autonomy

The thing that must be written down alongside each stage increase is the boundary.

The AI on its own	Human approval required
All reversible local work	Anything that incurs payment or billing
Collection, analysis, drafts, tests, reports	External publication (publishing, pushing, sending, submitting)
Retrying its own failed work	Irreversible operations like deletion or overwriting

The clearer the boundary, the more the human can delegate with peace of mind, and the more the AI can move without hesitation inside it.

The opposite of autonomy is not control — it is ambiguity.

When the boundary is blurry, two failures happen at once. The AI stalls, asking about even trivial things,
while the genuinely risky things get done with a "this much is probably fine."

3. Three Common Misconceptions

Misconception 1 — "A better model will solve this."
Without a memory structure, even the best model doesn't know about yesterday. Not one of the mechanisms in this book
is replaced by model capability.

Misconception 2 — "Write the rules in more detail and they'll be followed."
As we saw in Chapter 2, it's the opposite. A rule that isn't being followed needs to be turned into structure, not sentences.

Misconception 3 — "More autonomy is always better."
No. A Stage 3 system running without a boundary only makes the accidents bigger.
Do not skip from no safety net (Stage 1) straight to autonomous discovery (Stage 3).

4. The 30-Day Execution Plan

Period	What to do	Completion signal
Week 1	Organize the 4 `memory/` files + rule files (Chapters 2–3)	The AI brings up yesterday's work first
Week 2	1 hook gate + 1 auditor (Chapters 4 and 6)	A "done" report gets rejected once
Week 3	Collection script + scheduler registration (Chapters 7–8)	A report is waiting for you in the morning
Week 4	Organize failure records + write the boundary table (Chapters 9–10)	The same mistake doesn't happen twice

One per week is enough. If you install all four at once, you can't tell which one had the effect,
and when a problem occurs you won't be able to find the cause either.

5. Final Advice: A System Is Something You Grow

None of the mechanisms in this book is done after a single installation. When a mistake happens, the records grow;
when the records grow, the rules get refined; when a rule over-triggers, you loosen the gate.

An agent system is less like software and more like a garden. It belongs to the person who tends it
a little each week; the neglected one gets covered in weeds (orphan processes, polluted records, dead hooks).

If your garden is still at Stage 1, congratulations — the hardest first shovelful is already done.

Not sure yet? The first three chapters are free, same PDF format: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

10 Common Failures and How to Recover (Based on Actual Incident Records)

Sungsoo Youn — Sat, 12 Sep 2026 04:10:05 +0000

This is chapter 9 of my book **Building Autonomous AI Agents with Claude Code* — a field guide to turning Claude Code from a coding assistant into an agent that remembers, verifies its own work, and knows when to stop. Everything below is from a system I actually run every day on one Windows PC.*

This chapter is the most practical part of this book. All ten of these actually happened,
and most of them happened more than once. From the second time on, they were stopped by installing structure.

Failure 1 — Asserting from Guesswork

Symptom: The AI asserts system state (whether a process is running, whether a file exists, a config value) without checking.

Actual incident: While the user was actively using the computer, the AI asserted "the machine is currently in sleep mode."
Sleep state is 100% verifiable with a single command, yet a plausible guess was stated as fact.

Early signal: The wording is "it is ~" rather than "it seems ~", but no command was executed that turn.

Prevention: Put a table of verification commands into your rules file. With the list in place, compliance rises noticeably.

Fact you're about to assert	Verification command
Whether a process is running	`Get-Process <name>` / `tasklist /FI`
File/folder existence	`Test-Path` / `ls` (the real file, not memory)
Port occupancy	`Get-NetTCPConnection -LocalPort N`
Remote connectivity	actual `ping` / `curl` results

Failure 2 — False Completion

Symptom: Treating rc=0 or a "started" log line as evidence of completion.

Actual incident: A scheduled task was reported as "registered and done," but it had never been run even once.
The registration succeeded, but the path was broken, so in practice it was set up to fail silently every day.

Prevention: Change the completion criterion from "the command succeeded" to "the target's state changed."

def verify_done():
    report = REPORT_DIR / f"digest_{today()}.md"

On top of this, add the independent auditor from Chapter 6. The one who built the work must not be the one who passes judgment on it.

Failure 3 — Not Checking the Records

Symptom: Yesterday's solution is in the records, but it goes unread and the same struggle repeats.

Actual incident: The same encoding problem was solved three times. All three times it was approached as if seen for the first time.

Prevention: Install a gate that forcibly checks whether the records were read (the hooks from Chapter 4).

if not read_this_session(PROJECT / "memory/diary.md"):

The key is to not count "I saw the summary" as having checked. Seeing an auto-injected three-line summary
and actually reading the file are different things.

Failure 4 — Encoding Corruption (Essential for Korean-Language Windows Environments)

Symptom: Korean text gets garbled in output, in subprocesses, and in file writes that go through the shell.

Prevention: Block all three places. If any one is missed, corruption comes in through that path.

import sys
sys.stdout.reconfigure(encoding='utf-8')
sys.stderr.reconfigure(encoding='utf-8')

subprocess.run(cmd, encoding='utf-8', errors='replace', capture_output=True)

open(path, 'w', encoding='utf-8', newline='')

Put no Korean at all into batch files. If a path contains Korean, add a single English-path wrapper.

Failure 5 — Variable and Path Destruction at Shell Boundaries

Symptom: Using a PowerShell variable from bash yields an empty string, and unquoted Windows paths
lose their backslashes.

powershell -Command "$dir = 'C:\Temp'; ls $dir"

powershell -File "$TEMP/task.ps1"

Prevention: Don't mix shells. Any other-shell command longer than two lines gets saved to a file and executed.

Failure 6 — Silent Failure

Symptom: Errors swallowed by try/except; "0 items, successfully."

except Exception:
    pass

Prevention: Make failure a first-class citizen of the output format. Build a failure slot into the report template itself.

def render(items, failures):
    if failures:
    if not items:
    return head

Zero results is a warning, not a success. This one line prevents a dead parser from sitting unnoticed for weeks.

Failure 7 — Orphan Process Accumulation

Symptom: Processes left behind by automation paralyze the system weeks later.
This is the number one cause of "my computer suddenly got slow."

Prevention: Duplicate-run check + periodic cleanup.

lock = Path(tempfile.gettempdir()) / "collect.lock"
if lock.exists() and time.time() - lock.stat().st_mtime < 3600:
lock.touch()

Failure 8 — Working Around Instead of Fixing

Symptom: When blocked, taking a side path (retrying, another tool, a temp file) instead of fixing the cause.

Actual incident: When a file write failed, the file was saved to a different folder and the work moved on. The consumer of
that file was watching the original path, so it kept running on stale data with no error.

Prevention: Make it a rule: "after 2 attempts, stop and report the cause." A workaround is debt —
it keeps rolling for now, but it comes back with interest.

Failure 9 — Trusting Documents

Symptom: Believing documents, comments, and past summaries as truth.

Principle: Documents are the map; code is the territory. When the two disagree, the code is always right.
Before any important judgment, look directly at the source code or the actual execution result.

Failure 10 — Copy-Pasting Stale Memory

Symptom: A summary that was correct in the past is wrong now, but it gets asserted as-is.

Actual incident: When auto-generated logs piled up in mistakes.md, the AI mistook them for current issues
and repeated the same wrong answer 16 times. A case where the records actually ruined the judgment.

Prevention: Split the record files by purpose.

File	What goes in it — and nothing else
`diary.md`	Context of actual work done by a person
`mistakes.md`	Only mistakes a person pointed out
`audit-log.md`	All automated logs produced by scripts and cron

The moment automated logs mix into human records, memory turns from an asset into a liability.

The Common Principle of Recovery

When an incident happens, the order is always the same.

Stop — cut off further damage first.
Establish the current state by direct measurement — don't guess at what broke.
Record the cause — together with the correct method.
Add one structure that prevents the same incident — a hook, a test, or a checklist.

Recovery is not finished until step ④. Stop at step 3, and the same incident happens six months later.

Not sure yet? The first three chapters are free, same PDF format: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

Real-World Project: A Posting Collection & Analysis Agent from Start to Finish

Sungsoo Youn — Fri, 11 Sep 2026 04:10:06 +0000

This is chapter 8 of my book **Building Autonomous AI Agents with Claude Code* — a field guide to turning Claude Code from a coding assistant into an agent that remembers, verifies its own work, and knows when to stop. Everything below is from a system I actually run every day on one Windows PC.*

1. Defining the Goal — If You Can't Write It in One Sentence, Don't Start

"Automatically collect contest and grant-program postings every day, filter out risky clauses, and produce
a one-page report to read in the morning."

The input (posting sites), processing (parsing and filtering), output (digest), and schedule (every morning) are all in one sentence.
When you hand work to an AI, this sentence becomes both the work order and the completion criterion. If it's fuzzy,
the AI will very quickly build "something plausible that isn't what I wanted."

The first prompt handed to the agent looks like this.

If you don't write the "completion criterion," the AI's definition of done is "I finished writing the code." The done we want is
"it runs." This two-line difference is also why the auditor from Chapter 6 is needed.

2. Step 1 — Measure: Don't Build a Parser from Guesses

The AI will plausibly guess, "that site usually has this kind of structure." A parser built from that guess is
always wrong. Enforce the order.

curl -sL "https://example.org/contest/list" -o /tmp/list.html
grep -o 'class="[a-z_-]*"' /tmp/list.html | sort | uniq -c | sort -rn | head -20

Measuring reveals things you could never know from guessing.

The first item in the list is an ad banner, so it always contaminates the parse
The title link is an external URL, and the real posting ID is in a different tag next to it
The list page already contains closed postings ← we missed this and it actually caused an incident

The third one is a failure we actually experienced. Without parsing the closed/open status, we assumed "it's on the list, so it's still open"
and reported a contest that had already ended as a participation candidate. We were verifying the hard things like eligibility and terms
while missing the most basic question: "is it accepting entries right now?" So this rule is now baked into the collector.

Checklist before recommending anything to a human: ① Is it accepting entries? ② Are we eligible? ③ Are the terms safe?
Only something that passes all three is a candidate.

3. Step 2 — Tests First: Turn Measured Fragments into Fixtures

Freeze the HTML fragments confirmed during measurement directly into test fixtures. Even if the site changes later,
these tests guard against regressions in the parser logic itself.

# tests/test_collector.py
SAMPLE = """
<div class="list-item">
</div>
<div class="list-item">
</div>
"""


def test_only_open_contests_are_collected():
    items = parse_list(SAMPLE)


def test_deadline_is_extracted():
    assert parse_list(SAMPLE)[0]["deadline"] == "2026-09-18"

Writing tests first narrows the AI's scope of work. Instead of "make something reasonably good," it becomes
"make these tests pass." This is the strongest form of control you have when delegating work to an AI.

4. Step 3 — Implement: Build "No Silent Failures" into the Design

Keep the collector as independent modules per source, so that if one dies the rest keep running.
In exchange, a dead source must always appear in the report.

def collect_all(sources):
    results, failures = [], []
    for name, fn in sources.items():
        try:
            items = fn()
            results.extend(items)
            failures.append(f"{name}: {type(e).__name__} {e}")
    return results, failures

And the top of the report starts like this.

A system that only shows success counts cannot be trusted. Failures must appear on the same line for a human to believe it.
How a single except: pass line quietly kills a system is covered in detail in Chapter 9.

5. Step 4 — The Terms Filter: Domain Knowledge as Code

The real value of this project is not collection but selection. It finds risky clauses in posting terms
and classifies them as risky, caution, or safe.

RISK_PATTERNS = [
]


def judge(text):
    hits = [(level, why) for pat, level, why in RISK_PATTERNS
            if re.search(pat, text)]

Your domain surely has a "pre-participation checklist" like this too. Toxic contract clauses, a client's creditworthiness,
delivery terms — whatever it is, the moment you move the checklist from your head into code, mistakes are structurally blocked.
A tired human skips steps; a regex never does.

6. Step 5 — Assembly and Audit

When putting it on the scheduler, follow the rules from Chapter 7 (English-only paths end to end + the wrapper chain) exactly.

Then hand verification to the independent auditor (Chapter 6) along with the goal sentence. In practice, the auditor
caught "it was only registered and never actually executed once," and the cross-AI review got the RSS parsing
changed from regex to a standard XML parser. Working alone, I would have missed both.

7. The Daily Routine After Completion

Time	Who	What
09:30	System	Collect → filter → generate digest
2 min in the morning	Human	Check new items (🆕) and the failures section
5 min in the morning	Human	Run the terms filter only on postings of interest, then decide whether to participate

The system does the collecting and selecting; the human only makes decisions. That division of labor is the target state of an autonomous agent.

8. Porting This Structure to Other Fields

Field	Collection target	Risky clauses (filter)	Output
Freelancing	Outsourcing postings	Unlimited revisions, full IP transfer	3 gigs to apply for
Job hunting	Job postings	Inclusive-wage clauses, probation pay cuts	Application candidates
Real estate	Listings	Existing mortgages, special conditions	Site-visit candidates
Development	Release notes	Breaking changes	Upgrade caution list

The only things that change are the parser and the regexes; the skeleton (measure → fixtures → independent modules → visible failures → audit)
stays the same. Build this skeleton once, and the next agent takes half a day.

Not sure yet? The first three chapters are free, same PDF format: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

The Automation Pipeline — Pairing with a Scheduler So It Works at Night Too

Sungsoo Youn — Thu, 10 Sep 2026 04:10:04 +0000

This is chapter 7 of my book **Building Autonomous AI Agents with Claude Code* — a field guide to turning Claude Code from a coding assistant into an agent that remembers, verifies its own work, and knows when to stop. Everything below is from a system I actually run every day on one Windows PC.*

1. The Basic Shape of a Pipeline

The minimal setup for scheduled execution is three pieces.

The human's role changes from "running" to "reviewing" — this is the essence of automation.
If you added automation but still have to click something every day, that's not automation, it's a keyboard shortcut.

2. The 3 Big Windows Traps (All Based on Real Incidents)

Trap 1 — Console Window Flashing

If the scheduler runs python or a .bat directly, a black window pops up every few minutes and interrupts your work.
-WindowStyle Hidden still leaves a flash, because it hides the window only after it has been created.
The proper approach is a wscript + .vbs wrapper.

Set shell = CreateObject("WScript.Shell")
rc = shell.Run("""C:\Python312\python.exe"" ""C:\TaskWrappers\run.py""", 0, True)
WScript.Quit rc

The third argument 0 means "no window," and the fourth, True, means "wait until it finishes."
You must include WScript.Quit rc for the scheduler to recognize a failure as a failure. If you leave this out,
the script can fail every single day while the scheduler's history records success.

Trap 2 — Korean Path Encoding

If you register a Korean path in the scheduler through a shell, the encoding can get corrupted as it is saved.
This is the worst kind of failure: registration looks successful, only execution fails.

The proper approach is to split the path chain.

run.py is a launcher of fewer than ten lines. This single layer blocks the entire class of encoding incidents.

import subprocess, sys
sys.stdout.reconfigure(encoding='utf-8')
sys.exit(subprocess.run([sys.executable, "run_collect.py"],
                        cwd=PROJECT, encoding='utf-8', errors='replace').returncode)

After registering, always verify that the saved content contains no Korean characters.

Trap 3 — Orphan Process Accumulation

When unattended execution fails repeatedly, zombie processes pile up, and one day the whole computer slows down.
This is the number one cause of "my computer suddenly got slow."

import tempfile, time, sys
from pathlib import Path

lock = Path(tempfile.gettempdir()) / "collect.lock"
if lock.exists() and time.time() - lock.stat().st_mtime < 3600:
lock.touch()
try:
    main()
finally:

Without the finally, one crash turns it into automation that never runs again.

3. Safety Rules for Unattended Execution

① No silent failures. Do not swallow per-source failures — surface them in the report as a "failures section."
Treat a zero-item collection not as "a successful zero" but as a "suspected structure change" warning.

② Registered ≠ working. After registering the schedule, always run it manually once and check the exit code
and the output artifact. A successful-registration message proves nothing.

schtasks /run /tn MyTask
timeout 60

③ Prevent duplicates with a state file. Record "what has already been seen" so only new items appear each day.
If the report says the same thing every day, people stop reading it — and an unread report is the same as no report.

seen = set(json.loads(SEEN.read_text())) if SEEN.exists() else set()
new = [i for i in items if i["id"] not in seen]
SEEN.write_text(json.dumps(sorted(seen | {i["id"] for i in items})))

4. Deployment Checklist (Follow This As-Is and Incidents Don't Happen)

[ ] Does running the script standalone produce the output artifact?
[ ] Is the exit code non-zero on failure? (check with echo $?)
[ ] Does the vbs wrapper propagate the exit code?
[ ] Is the path registered in the scheduler free of Korean characters?
[ ] Did you run it manually once after registering and confirm the output artifact?
[ ] On failure, does the failure show up in the report? (test by disconnecting the network)
[ ] Is the duplicate-execution lock released via finally?
[ ] A few days later, is the process list free of leftovers?

The last two items must be checked a few days later. They never show up on deployment day.

5. How Often Should It Run?

Interval	Suited for	Caution
Every 5–15 min	Watching (monitoring), alerts	Orphan processes accumulate fastest here
Once daily	Collection, summaries, reports	Most automation belongs here
Once weekly	Cleanup, checkups, backups	hooks self-checks go here too

When in doubt, start with once a day. Short intervals surface problems faster, but they
accumulate side effects at the same speed.

Not sure yet? The first three chapters are free, same PDF format: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

The Independent Auditor Pattern — "Don't Let the Thing That Built It Verify It"

Sungsoo Youn — Wed, 09 Sep 2026 04:10:03 +0000

This is chapter 6 of my book **Building Autonomous AI Agents with Claude Code* — a field guide to turning Claude Code from a coding assistant into an agent that remembers, verifies its own work, and knows when to stop. Everything below is from a system I actually run every day on one Windows PC.*

1. The Problem Isn't Lying — It's Confirmation Bias

When an AI says "done," much of the time it isn't lying — it's self-conviction.
The script ran (rc=0), the log shows started, so it believes the job is done.
It's exactly the same disease as a human developer going easy on their own code in review, and the prescription is the same —
separate the person who builds from the person who inspects.

There's one more thing. An AI treats what it just said as evidence. Once it says
"the tests passed," every judgment after that is built on top of that sentence — regardless of
whether the tests were actually run. That's why the inspector must receive none of the worker's words as input.

2. The 4 Design Principles for an Auditor Agent

① Trust only the filesystem.
Do not accept the worker's explanations, summaries, or excuses as input. Only actual files,
actual test run results, and actual process state count as evidence.

② PASS/FAIL, binary.
Ban gray verdicts like "it mostly went well." The moment you allow gray, every verdict
becomes gray. Humans read gray as a pass.

③ Compare against the original instruction.
Don't give the auditor just the output — give it the user's original instruction as well.
The criterion is "did it do what was asked," not "did it do something."

④ Reproduce the claims.
If the worker claims "tests passed," the auditor runs them again itself. In a real case, the worker
reported "scheduled task registered — done," but had never run it even once; the auditor
launched the task itself, got exit code 0, and only then did it earn a PASS.

3. The Auditor Definition File (Copy It As-Is)

---
name: auditor
---

Restricting the tools to read-only is the key. Give the auditor write access and it
will start doing "I fixed it, so PASS" — and at that moment its independence is gone.

4. Operating Rule: No "Done" Without a PASS

An auditor that merely exists goes unused. Put one line in your rules file:

Do not use the word "done" without an auditor PASS.

There are three mandatory call points.

Point	Reason
Right before reporting completion	The most basic one. This is where false completions get caught
When the user asks "is it done?"	That question itself is already a signal
At the end of a long session	The longer the context, the more "I believe it's done" errors accumulate

Combined with the hooks from Chapter 4, it's even more reliable. In the session-end hook,
check whether the auditor was called, and block termination if it wasn't.

5. Completing It with a 3-Stage Verification System

Stage	Actor	What it catches
① Tests (TDD)	Code	Spec violations, regressions
② Independent auditor	Same model, different role	False completions, instruction-result mismatches
③ Cross-AI review	A different model	Blind spots shared by the same model

The reason ③ is needed is simple. The same model fails in the same habitual ways. Among the things
cross-review actually caught was one like "you're parsing RSS with a regex" — something an auditor
running on the same model had looked at three times and never flagged.

A different model's findings also come with plenty of false positives. So set handling rules in advance.

Recording the rejection reason matters. If you don't, the same finding comes back in the next review and you deliberate all over again.
Our code actually carries comments like this:

6. When the Auditor Is Wrong

The auditor isn't perfect either. Verify the auditor's findings with actual measurements too. In one real case,
the auditor claimed "this setting drops performance by 2.45%p," but re-measuring showed
that number came from an old condition and did not reproduce under the current one.

So the order is this: auditor's FAIL → confirm by measurement → fix if true, otherwise reject with evidence.
"Because the auditor said so" is the same sentence as "because the AI said so."

Not sure yet? The first three chapters are free, same PDF format: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

Skills and Subagents — The Art of Splitting Work and Delegating It

Sungsoo Youn — Tue, 08 Sep 2026 04:10:05 +0000

This is chapter 5 of my book **Building Autonomous AI Agents with Claude Code* — a field guide to turning Claude Code from a coding assistant into an agent that remembers, verifies its own work, and knows when to stop. Everything below is from a system I actually run every day on one Windows PC.*

1. A Skill = A Procedure Turned into a File

Take a work procedure you used to explain verbally every time (a review checklist, a deployment sequence, a logging format) and save it as a file, and a single invocation loads the entire procedure. The key effect is that the quality of the procedure is decoupled from how you're doing that day.

---
---

There are three signals that something is worth turning into a skill.
① You've repeated the same explanation three or more times ② Skipping a step causes an incident
③ It can be used in other projects too.

2. A Subagent = Delegating to Another "Head"

A subagent is a lower-level AI that works independently in a separate context and returns only the result.
There are two criteria for deciding what to split off.

① Contamination isolation. Work that clutters the context — mass searches, long log analysis — should be done by a subagent that brings back only the conclusion. The main agent's thinking space stays clean.

② Role isolation. Work where "the person who builds and the person who checks must be different" — verification, audits — must always be separated (Chapter 6).

3. Work That Must Not Be Split Off

Conversely, core design decisions must be made by the main agent directly. Delegate the judgment too, and two things collapse.

Accountability: if you accept a subagent's conclusion as-is, the main agent can't explain why that decision was made.
Context: a subagent doesn't know the project's history (records, failures, constraints). A "recommendation" made in that state is often a proposal that was already rejected.

You can divide the hands, but there must be one head.

And a subagent's report is a result, not a fact. There was an actual case where a subagent reported "this setting is degrading performance," the change was applied as-is, and re-measurement showed the numbers were from the old conditions. Verify the conclusions you receive, too.

4. A "System That Doesn't Forget": Keyword Auto-Mapping

Once you pass 10 skills, both the AI and the human forget which skills exist.
The solution is to put a keyword → skill mapping table in the input hook (Chapter 4).

TRIGGERS = {
}

for keys, skill in TRIGGERS.items():
    if any(k in user_input for k in keys):

The last sentence matters. Displaying the recommendation without invoking it is meaningless, so state the rule alongside it: "when the header appears, actually invoke it in that turn."
In actual operation, when this one line was missing, recommendations appeared and nobody used them.

5. An Example of Skill Placement by Stage

Stage	Skill type	When to call it
Planning	Brainstorming, requirements interview	Before writing code
Implementation	TDD guide, subtask distribution	Right before implementing
Verification	Self-review → independent audit → cross-AI	Right before committing
Wrap-up	Work log, handoff notes	End of session

Calling only the skills that fit the stage is a skill in itself. Call everything and you just waste context, and the procedure you actually need gets buried.

6. When You Take Skills from Someone Else

When installing a public skill collection, remember just one thing.
Star counts are not a quality guarantee. The install script may contain prompt injection (instructions that neutralize your rules). Always open and read the files before installing.

Not sure yet? The first three chapters are free, same PDF format: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

The Hook System — Blocking AI Mistakes with Structure

Sungsoo Youn — Sun, 06 Sep 2026 21:22:54 +0000

This is chapter 4 of my book **Building Autonomous AI Agents with Claude Code* — a field guide to turning Claude Code from a coding assistant into an agent that remembers, verifies its own work, and knows when to stop. Everything below is from a system I actually run every day on one Windows PC.*

1. A Hook Is a Safety Mechanism Outside the AI

A rules file is something the AI tries to follow; a hook is something the system uses to make it be followed.
This difference is bigger than it looks. Rules get buried as context grows longer, get skipped when things are urgent,
and "just this once" exceptions pile up. Hooks don't do that.

Point	Timing	Typical use
`UserPromptSubmit`	Right after the user types input	Automatic context injection (record summaries, related rules)
`PreToolUse`	Right before a tool runs	Blocking dangerous actions (gates)
`PostToolUse`	Right after a tool runs	After-the-fact checks (contamination detection, follow-up procedure reminders)
`Stop`	When the response ends	Quality gates (forbidden-word detection, verification requirements)

Registration happens in one place, the settings file.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [{ "type": "command",
                    "command": "python C:/hooks/record_gate.py" }]
      }
    ]
  }
}

2. Pattern A — The Blocking Hook (Gate)

This is a gate that blocks "attempts to modify a file without reading the records first." What follows is
a shortened version of one actually in use.

import json, sys, time
from pathlib import Path

STATE = Path(tempfile.gettempdir()) / "read_state.json"
REQUIRED = ["memory/diary.md", "memory/mistakes.md"]

payload = json.load(sys.stdin)            # hooks receive the tool call on stdin
tool = payload.get("tool_name", "")

if tool == "Read":
    state = json.loads(STATE.read_text()) if STATE.exists() else {}
    state[payload["tool_input"]["file_path"]] = time.time()
    STATE.write_text(json.dumps(state))
    sys.exit(0)

state = json.loads(STATE.read_text()) if STATE.exists() else {}
missing = [f for f in REQUIRED if not any(f in k for k in state)]
if missing:
    print(f"""🔒 Records not read yet. Read these before editing:
  {chr(10).join('  - ' + m for m in missing)}
Retry the same action after reading and it will pass.""", file=sys.stderr)
sys.exit(0)

The key is the last sentence. If you also return "what to do to pass," the AI recovers on its own.
The rule gets enforced without a human having to step in.

3. Pattern B — The Injection Hook

On every input, automatically insert the most recent contents of the records.

import sys
from pathlib import Path

def tail(path, n=5):
    if not Path(path).exists():
    heads = [ln for ln in Path(path).read_text(encoding="utf-8").splitlines()
             if ln.startswith("## ")]
    return "\n".join(f"  {h}" for h in heads[-n:])

{tail('memory/diary.md')}
{tail('memory/mistakes.md')}

That said, injection is strictly an aid. It breeds the habit of looking only at the summary and never reading
the original, so for important work we still use a gate to force a Read of the original.
(Our gate message actually contains this sentence — "seeing the injected summary does not count as checking.")

4. Pattern C — The After-the-Fact Reminder Hook

Some procedures are too minor to block on but too important to just let slide. For example, "if you committed, update the handoff note too."

if "git commit" in payload["tool_input"].get("command", "") \
        and payload.get("exit_code") == 0:
    handoff = PROJECT / "memory/HANDOFF.md"
    if not modified_today(handoff):
              file=sys.stderr)

The once-per-session limit matters. If it pops up every time, it just gets ignored — and a hook that gets ignored is a hook that doesn't exist.

5. Three Operational Pitfalls (We Hit All of Them)

① Silent blocking. If a hook returns only an exit code with no reason, the AI concludes "the tool is broken"
and attempts some misguided workaround. A blocking message must always include the reason and the way to resolve it.

② False positives. Once a gate starts blocking normal work too, the human gets annoyed and turns the hook off,
and at that moment the entire safety mechanism disappears. One over-blocking gate really was removed in the end.
Put gates only on patterns that are clearly dangerous, and steer everything else gently with injection hooks.

③ Hooks die quietly. This is the scariest one. A script path changed, nobody noticed,
and months went by. We believed we were safe while the safety mechanism wasn't there at all.

for name, path in HOOKS.items():
    r = subprocess.run([sys.executable, path], input="{}",
                       capture_output=True, text=True, timeout=10)

6. How Far Should Hooks Go?

Hooks are not a cure-all. There is exactly one criterion for the call.

Has the same mistake happened twice? Then make it a hook. If it happened once, record it.

If you turn every one-time incident into a hook, the system becomes a mass of rules and eventually heads
toward the false positives of ②. Twice is a signal that it's not chance but a structural problem — and structural problems get solved with structure.

Not sure yet? The first three chapters are free, same PDF format: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

Memory-Driven Development — Making the AI Remember What It Did Yesterday

Sungsoo Youn — Sun, 06 Sep 2026 04:10:04 +0000

This is chapter 3 of my book **Building Autonomous AI Agents with Claude Code* — a field guide to turning Claude Code from a coding assistant into an agent that remembers, verifies its own work, and knows when to stop. Everything below is from a system I actually run every day on one Windows PC.*

1. The AI's Fatal Weakness Is Not Skill — It's Memory

Give the same AI the same project, and if it doesn't know yesterday's trial and error, it trips
over the same spot again today. The solution isn't switching models — it's building
file-based external memory.

Let's clear up one misconception first. "Can't you just feed it a good summary?" — No.
A summary only works on the premise that you already know what matters. But yesterday's me
didn't know what would become a problem today. That's why records must be the original text,
not a summary — and instead, they must be split up so they're easy to find.

2. The 4-File Structure

File	What	When it's read
`memory/diary.md`	Chronological work context	Session start
`memory/mistakes.md`	Only mistakes a human pointed out	Session start
`memory/MEMORY.md`	A map of facts that don't change	Session start
`memory/HANDOFF.md`	Current state and what to do next	First of all

diary.md — the work journal. Accumulate a few lines per session: "when, what, why,
and how it ended." If you make date headers (## 2026-08-07 ...) a rule, it's easy for a hook
to extract and inject only the recent entries.

mistakes.md — the mistake record. Fixing the format is the key.

## [2026-08-06] Blamed the account for a 403 without checking my own file
- **- **What went wrong****: Saw a reasonless 403 and suspected their system three times
- **- **Why it was wrong****: Skipped what I control (file format) and looked at their side first
- **- **The right way****: Check my output, then my call, then the account. Before checking, say "candidate", not "cause"

A record that ends with "I did it wrong" cannot prevent repetition. Only when the third line
(the correct method) is there does the record become prevention. The AI in the next session can
change its behavior by reading that line alone.

MEMORY.md — the core index. A single page holding only the project's invariant facts
(structure, constraints, prohibitions). If diary is the chronological flow, MEMORY is the map.

HANDOFF.md — the handover note. Write only what will cause an accident if the next
session doesn't know it.

## What is running now
- Daily 09:30 collector (verify: schtasks /query /tn ...)
## Changes that must not be reverted
- Weakness scoring is OFF. Measured evidence says so; do not turn it back on because "the rule says so"
## Waiting on the owner's decision
- Ebook price, whether to enter the competition

This file was added last, but in practice it became the most frequently read file.

3. Rule: Enforce "Check Records Before Working" Structurally

Even if the records exist, they're useless if the AI doesn't read them. Enforce it in two layers.

State in the rule file: "before modifying code, open the records directly with the Read tool."
Use a hook (Chapter 4) to technically block "modifying files without having read the records."

Without ②, ① gets followed only intermittently. Especially as the session grows longer, rules
get pushed to the back of the context.

4. When Records Ruin Judgment (An Actual Incident)

This is the most important part of this chapter. Records are an asset, but once contaminated,
they become a liability.

The incident: logs produced by an automated inspection script were piling up in mistakes.md,
and the AI mistook those automated logs for current issues, repeating the same wrong answer
16 times. It kept seeing an already-resolved problem as "the problem right now."

The cause: mistakes.md is a file that gets auto-injected every session. If automated logs
get mixed in there, the AI's entire field of view is contaminated.

The fix: split the files by signal source.

File	Who writes it	Injected?
`mistakes.md`	Only what a human pointed out	✅
`diary.md`	Actual work by human and AI	✅
`audit-log.md`	Automated logs from scripts and cron	❌

And add one more filter to the injection hook.


def is_auto_noise(line):
    return any(m in line for m in AUTO_MARKERS)

Making the filter explicit strings rather than regex is deliberate. Cast the net too wide
and human-written entries get filtered out too — narrowing the field of view in the opposite
direction this time.

5. Another Form of Contamination — Encoding

Record files must be written only through a path that guarantees UTF-8 (the AI's file tools).
Writing via shell redirect (echo ... >> diary.md) can corrupt the encoding on Windows, and
if a corrupted record gets injected every session, you end up with an AI whose memory is damaged.

6. When Should Records Be Written?

If you define the "record this" instruction as a bundled procedure, no step gets skipped.

Step ③ kept getting skipped, so it eventually became a hook. If a commit succeeds but the
handover note wasn't updated today, a notification appears (Chapter 4, pattern C).

Not sure yet? The first three chapters are free, same PDF format: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

First Setup: What Changes with a Single CLAUDE.md

Sungsoo Youn — Sat, 05 Sep 2026 04:10:03 +0000

This is chapter 2 of my book **Building Autonomous AI Agents with Claude Code* — a field guide to turning Claude Code from a coding assistant into an agent that remembers, verifies its own work, and knows when to stop. Everything below is from a system I actually run every day on one Windows PC.*

1. CLAUDE.md Is a "Contract Read Every Time"

Every time Claude Code starts a session, it injects the global settings (~/.claude/CLAUDE.md) and the project's
CLAUDE.md into the system context. In other words, every sentence written here is a standing instruction that
automatically attaches to every conversation. This property is both the strength and the trap.

The strength is clear. You gain "things you no longer have to say every time."
The trap is this: every sentence written here competes with every other one, every turn.

2. Shorter Gets Followed — A Fact Confirmed by Measurement

There is a common failure path. Rules pile up one by one past 1,000 lines, and at some point the AI
starts missing the most important rules. Inside a long document, instructions bury each other.

In actual operation, when we removed a general-purpose rule set that had grown past 1,300 lines and cut the injected volume by about 89%,
compliance with the core rules went up noticeably. The attempt to raise compliance by adding
more rules had itself been the cause.

Keep only "things that cause real damage when violated" in CLAUDE.md, and move everything else out.

One counterintuitive case is worth adding. We once listed the "expressions not to use" in the rules —
and then removed the list. Showing those words every turn was actually producing an imprinting effect.
The list now lives in a separate file, and a checker filters output just before it is sent.
Writing something in the rules and blocking it with a system are different things.

3. Split into a Three-Layer Structure

Layer	File	What it holds	Size guideline
Global	`~/.claude/CLAUDE.md`	Identity, tone, security, prohibitions common to all projects	Under 100 lines
Rule fragments	`~/.claude/rules/*.md`	Rules by topic (encoding, paths, DB)	Under 30 lines per file

The reason for splitting off rule fragments is to load them only when needed. The DB rules only
need to be present when you touch the DB. If they are always injected, they take up space that other rules need.

4. Three Traits of a Well-Written Rule

① It can be verified through behavior.

"Be careful" cannot be verified. The AI cannot judge whether it was careful, either.

② It carries a one-line reason.

When the AI knows the reason, it keeps the intent even in situations the rule didn't anticipate. A rule
without a reason gets dismissed as "doesn't apply in this case" the moment the situation shifts slightly.

③ It states a replacement behavior, not just a prohibition.

With only a prohibition, the AI improvises a creative workaround at the blocked spot. That workaround is
usually worse.

5. What Must Go into the Project CLAUDE.md

The global file differs from person to person, but there are things every project file should share.

The "confirmed facts (do not ask again)" section is surprisingly effective. If you have been asked the same
question three times, write the answer here. Then there is no fourth time.

6. Signals When Rules Keep Growing

If your rule file is growing, check the following.

Signal	Response
Three or more rules on the same topic are scattered around	Bundle them into a rule fragment file and move them out
A rule contains "as an exception"	That rule is already wrong — rewrite its condition
A rule keeps being ignored	Don't rewrite the sentence — turn it into a hook (Chapter 4)

The last row is the key. If saying it three times doesn't work, build it into the structure. Rewriting a rule
in a stronger tone almost never works.

Not sure yet? The first three chapters are free, same PDF format: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.