DEV Community: Sungsoo Youn

The Server Returned 500. The Change Had Already Gone Through.

Sungsoo Youn — Tue, 03 Nov 2026 04:10:05 +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.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My agent posts one article a day, and after each post it groups the articles into a series by sending a small update to each one. On October 29 the daily log ended with "grouped 42 / 43" and the scheduled task finished with exit code 1. One update had failed with a 500.

What I almost did

For two cycles my to-do line said: on October 30, check that the log shows "grouped n / n". I treated "n / n" as the success signal I was waiting for. But the number I was waiting for had already been printed the day before, and it was the failure: 42 out of 43.

What the server said when I asked it directly

I stopped waiting and read the log, then sent a read-only request for the one article that failed. It already belonged to the series. The update had been applied, and the server answered with a 500 anyway.

So the failure was not in the article and not in the series. My code had decided "failed" from the response code alone, and a response code is only the server's report about the request. It is not the state of the thing I asked it to change.

What I changed

When an update comes back with a 5xx, the code now reads the article again and decides from the data: if the series is there, it counts as grouped; if not, it counts as failed. I added two tests: one where the 500 came after the change was applied, one where it did not. The first one failed before the fix.

The next day's log had no grouping line at all, because nothing was left to group, and the task ended with exit code 0.

The rules

A 5xx on a write is not "it didn't happen." Read the state back before you decide.
Check the thing you are waiting for before you wait for it. My "n / n" had already printed, and it was the bad news.
An exit code of 1 is a prompt to read the log, not a verdict. Here it pointed at a false alarm, and the only way to know was to look.

Where this comes from. Every post here comes from one setup I run daily: a CLAUDE.md, memory files the agent reads before it touches anything, and a separate auditor agent that returns PASS or FAIL. The first 3 chapters of the book that walks through it are free as a PDF: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

The full edition is 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, $19 as a PDF: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code

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

I Wrote "Check Back on October 31" Three Times. The Check Could Not Have Told Me Anything.

Sungsoo Youn — Mon, 02 Nov 2026 04:10:05 +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.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My agent keeps a to-do line at the bottom of every cycle report: what to look at next, and when. For three cycles in a row that line said the same thing: on October 31, look at how many views article 32 got.

Why that line existed

I had been testing tags on these posts. Articles 23 through 31 went out with a new set of tags, and the older ones had the original set. A judge script compared the two groups and, on October 28, said the new tags did not raise views. So from article 32 on, the posts went back to the original tags.

Article 32 was the first one back on the old tags. It seemed natural to look at it three days after posting, the same waiting period the judge used. So the to-do line said: October 31, article 32 views.

What the ledger said when I finally read it

On the fourth cycle I stopped copying the line forward and read the numbers. On October 29, the views on recent articles, all posted under one of the two tag sets, were:

article 33: 10 (its first day)
article 31: 14
article 30: 12
article 29: 20
article 25: 34
articles 23, 24 and 27: 0
article 32: 0

Within the same tag set the articles ranged from 0 to 34. One article sitting at 0 or at 15 on October 31 would say nothing, because the spread among articles of the same kind is already bigger than any difference I could be looking for. And the judge that had a rule for this question had already finished on October 28. There was no rule waiting for the October 31 number.

What I changed

I deleted the line. In its place the report lists only the waits that have a judge behind them: two experiments with a date and a script that will print a verdict. The leftover time went to a real problem I had noticed while counting: only three unpublished articles were left in the queue, so the queue would be empty on November 1.

The rules

A wait needs a judge. If no script or rule will turn the number into a decision, "check back later" is a habit, not a plan.
Read the spread before you read the value. A single number means something only next to how far its neighbours differ.
Copying a to-do line forward is not checking it. The third copy was the one that made me open the ledger.

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

I Blamed a Field for a Rate Limit and Left It Out for 45 Days

Sungsoo Youn — Sun, 01 Nov 2026 04:10:05 +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.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

On September 4 my agent posted its first article here through the API. The request came back with a server error, 500, but the article was live. To find out which part of the request the server did not like, the agent tested the fields one at a time on an unpublished draft: a minimal draft, then the title, then the tags. All passed. Then it added the series field, the field that groups posts into one series on this site. That request came back 429.

What a 429 says

429 means too many requests. It is the server asking you to slow down. It does not say which field it disliked, or that it disliked any field at all.

The agent knew that on the day. The comment it left next to the posting code says the series step was blocked, then adds in brackets that because it was a 429 this was not finally confirmed.

It removed the field anyway. A test was added that fails if the posting code sends a series field. Every article posted after that went out without it.

Forty-five days

Between September 4 and October 19 there is no record in my logs of the series field being tried again. Over that time 33 articles went up. On October 19 I fetched each of them one by one: 0 of 33 belonged to a series.

The retest

On October 19 a session sent the series field to the same unpublished draft used on September 4. The answer was 200, and the draft now had a series number. It then sent only the body to the same draft, and the series number stayed. Last it sent an empty series, and the draft went back to having none.

I do not know whether the field would have passed on September 4 if the agent had waited and sent it again. I only know that the reason written down for dropping it was a 429, and that the same note said it was not confirmed.

The fix

From October 29 new articles go out with the series field. The daily posting run also goes through my published articles, checks each one, and adds the series to any that have none, five seconds apart. If it gets a 429 it stops and leaves the rest for the next day.

It waits until October 29 because a tag experiment on articles posted from October 19 to 25 is judged on October 28, and I do not want two changes inside the same window.

The rules

A 429 is about how fast, not about what. Wait and send the same request again before deciding a field is refused.
A reason marked not confirmed needs a day to come back to it. Mine had no such day and stayed open for 45 days.
Retest what you removed on a guess. The test that kept the field out was checking my guess, not the server.

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

My Morning Check Said My Writeup Was No Longer Submitted. The Site Had Changed Its Capital Letters.

Sungsoo Youn — Sat, 31 Oct 2026 04:10:05 +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.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

Every morning at 08:30 my agent runs a list of checks on things it has put out in public. One line asks whether my writeup for a Kaggle competition is still marked as submitted. The check opens the competition's writeup page, reads the page text, and looks for the word SUBMITTED.

The red line

From October 1 to October 11 that line passed every day. On October 12 and 13 the page did not load in time, so the line said it could not check. October 14 passed. October 15 and 16 did not load again. On October 17 the page loaded, and the line turned red: no submitted marker.

A red line on that check would mean my writeup was no longer marked as submitted. Before changing anything, a session opened the same page with the same browser profile and read the text again. My writeup was there, marked Submitted.

Capital S, then lower case. The page used to show SUBMITTED in capitals. The check matched the word with its capitals exactly, so it no longer matched. My writeup had not changed. The spelling on the page had. The last day the old spelling was seen is October 14, and the next run that loaded the page was October 17, so I do not know which day it changed.

The hole behind it

The old check looked for the word anywhere on the page. That page also lists other people's writeups. In the first 3,000 characters of the page text saved that morning, the word appeared 13 times: once for my writeup and 12 times for other people's. So while the old spelling was in use, the check would have passed on any other writeup carrying it, even if mine had been only a draft.

The red line was false. The green lines before it were weaker than they looked.

The fix

The new check reads only my own section of the page, from the Your Work heading to the New Writeup button, and finds the word there in any mix of capitals. If it cannot find my section at all, it does not say red. It waits 90 seconds and reads once more, and if it still cannot find the section, the line says it could not check.

Against the page text read that morning, the old check said no and the new check said yes. The next morning, October 18, the line passed with the new check.

The rules

Read the source again before acting on a red line. Here the source said the opposite of the alarm.
Search only where your item is. A word that also appears next to everyone else's items tells you nothing about yours.
Not found is not the same as not submitted. When my section is missing, the check reports that it could not check, not a failure.

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

My Warning Showed Up Every Evening for Eight Days. Nobody Who Could Act on It Read It.

Sungsoo Youn — Fri, 30 Oct 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.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My agent replies to other people's posts on Threads. The split is strict: a scheduled job sends replies from a queue, but only a working session writes them. The job does not write a sentence on its own. If no session fills the queue, the job runs on schedule and sends nothing.

The first gap: 12 days

On October 4 my agent found that no reply had gone out since September 22. Twelve days. On September 24 a session had decided to leave the queue empty until after October 1, so the replies would not mix with an experiment to be judged on October 1. It wrote down that it would reopen them. Nothing was set up to do that, and no session did. An empty queue is not a stop, so no screen showed it.

The fix that day was a warning. My agent sends me an evening summary every day at 19:00. From then on, if the queue was empty and no reply had gone out for 3 days, the summary said so, with the number of days.

The second gap: 10 days, with the warning on

The last replies went out on October 5. Then none from October 6 to October 15. The warning worked as written. It appeared in the evening summary on all eight days from October 8 to October 15, counting up from 3 days to 10. Two replies went out on October 16, and after that the queue was empty again.

The summary is for me. The queue is filled by my agent's sessions, and they do not read the summary. The warning reached the one reader who does not fill the queue, and missed the readers who do.

The fix: put the check where the sessions look

On October 18 my agent wrote a small check and added it to the first steps a session takes in every cycle. It fails in only two cases:

the replies were stopped in a way that needs a person to clear it, or
the queue is empty and today's candidate posts have not been read yet.

If today's candidates were already read, it stays quiet even with an empty queue. The candidate read runs once a day, so after that a session has nothing more to do, and a check that fails every cycle with nothing to do gets ignored.

The same morning a session read the candidates: 48 posts in the feed, 4 related to my topics. It wrote 3 replies, each one leaning on something my agent had built or measured, and skipped one post that was promotion with no sentence that touched anything my agent had measured. The scheduled job sent all three that day.

The rules

A warning belongs where the one who can fix it looks. Mine was correct for eight days and went to the wrong reader every time.
A count that keeps going up means the warning is not working. 3 days, 4 days, up to 10 was the warning telling me it had no effect.
Stay quiet when there is nothing to do. The new check fails only when a session can act right now.

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

I Found Three Wrappers Hiding Failures, Wrote Them Into a Test as a Fact, and Left Them for Five Days

Sungsoo Youn — Thu, 29 Oct 2026 04:10:03 +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.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My agent runs on scheduled tasks. Each task starts a small Python wrapper, and the wrapper starts the real runner. My runners have a guard: if a runner gets a flag it does not know, it stops with exit code 2.

On October 13: found by reading

A reader had asked whether the scheduler commands were part of my tests. They were not, so my agent wrote a test that reads all 17 wrappers and checks every flag they pass against the runner's allowed list. While reading them it found that three of the 17 caught the runner's exit and ended with success. A guard stop in any of those three would show up in the scheduler as a successful run. In the one that runs three steps in a row, the next step would still run.

I wrote that in a public reply. In my notes for that day, two of the three were listed as a defect outside the task, not to be fixed. Then I wrote a test to keep the reply honest. It opens the wrapper folder and asserts that exactly these three wrappers catch the exit.

That test recorded the defect as an expected fact. If one of the three had been fixed while the folder stayed as it was, the test would have gone red. That test now skips itself, because the folder no longer matches the day it describes.

Five days later: found by running

Two comments from a reader, on October 13 and 17, suggested a different test: run each wrapper against a stand-in runner that exits 2, and check that the wrapper exits 2 as well.

My agent built it on October 18. The test globs the wrapper folder, replaces the runner with a stand-in that exits with a chosen code, and runs each wrapper as written. There are 18 wrappers now. 15 passed a 2 through. The same three ended with 0.

Reading had found the same three five days earlier. The difference was what the test asserted. This one asserts what should be true, so it stayed red until the three were fixed.

The fix was not the same for all three

One wrapper now passes the runner's exit code on.
One runs three independent steps in a row. It still runs all three, then exits with the first non-zero code.
One starts my morning check. That runner exits 1 when one of its checks fails, and a monitor in another project alerts on any scheduled task that ends non-zero. The check had a failing line on 7 of the last 14 days, and my agent already reads those lines every cycle. So this wrapper turns only a 1 into 0 and prints a line saying so. A guard stop or a crash still ends non-zero.

A review claim I checked by running it

A second model reviewed the change and marked one point critical: a runner that ends with SystemExit(None) makes Python exit with 1. The test already had that case. Python exits with 0, and all 18 wrappers passed it.

To check the test itself, my agent ran the three old wrappers and seven edited copies of the new ones through it. It flagged all ten.

The rules

A defect you write down is still there. The three wrappers were found, reported in a public reply and left as they were for five days.
Do not assert that a known bug is present. A test that checks for the bug turns red when someone fixes it. Assert what should be true and let it stay red.
Run the code when you can. Reading the wrappers told me what they contained. Running them showed which exit code each one actually produced, including the case a reviewer got wrong.

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

My Fix for Counting My Own Visits Erased the Visitor It Was Meant to Find

Sungsoo Youn — Wed, 28 Oct 2026 04:10:05 +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.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My Korean storefront shows a visit count for each product. It is not a daily number. Each day's value is the total for the last seven days. My agent uses it to judge one small experiment: on most days a blog post ends with a line pointing to one chapter of my book, and the judgment asks whether that chapter's count rose more than the other chapters' counts did.

A rise of zero

The judgment said the line had worked on four days. One of them was October 13. That chapter's count was 12 when the line appeared, then 12 and 11 on the next two days. It had not risen at all. The rule was that the door chapter rose more than the comparison chapters. On those days the comparison chapters went down, so zero beat them. The rule now asks for a rise above the comparison and above zero.

My own visits are in the count

As far as I can tell, the storefront counts my visits too. On October 12 my agent opened one chapter's page 8 times, 7 of them while checking an edit. That day its count went from 12 to 19. My agent keeps a ledger of the times it opens a product page, and its first full day is October 6, so the judgment should take those visits out.

The first fix

My first version added up my visits between the day the line appeared and the day being checked, and subtracted that sum from the rise.

My auditor rejected it. The count is a seven-day total. My agent's morning check opens each product page once, on most days. A visit that comes in each day also drops out of the window each day, seven days after it came in, so a daily check adds nothing to the rise. I was subtracting it anyway. The auditor built a test case: every product checked once a day, and one real visitor on the door chapter. My first version found no rise at all.

It was worse than a wrong number. With that subtraction I had written that only one day showed a rise, and that the October 12 rise came from how often I had opened each chapter. Both were wrong, and the second turned a result of my own arithmetic into a cause.

The second fix

The correction now uses the same unit as the count. For a given day, the ledger gives my visits over that day's seven-day window. The judgment subtracts the change in that window total between the two days it compares, not the sum of visits in between. A morning check that repeats every day cancels out. A burst of extra checks counts while it is inside the window and comes back out when it leaves.

With both changes, the rising days went from four to three: October 6, 10 and 12. The one that dropped was October 13, the zero rise. The ledger's first full day is October 6, so for most door days the window reaches back before it. On those days the judgment subtracts nothing and says so. Of the ten doors it measured, only two could have my visits taken out. For the rises on October 6 and 10, I do not know whether my visits were part of them.

The test file for this change has 16 tests. Run against the code from before the change, 15 of them fail. The auditor's case is one of them.

The rules

Correct a rolling number in the same unit. If the count is a seven-day total, subtract the change in a seven-day total of your own visits, not a sum over the days in between.
Put the boring case in the test data. A check that runs every day was the case that broke my fix, and none of my own tests had it.
A result of your own arithmetic is not a cause. Before writing why something rose, open the numbers the arithmetic took away.

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

My Ledger Said Nobody Took My Free Sample. I Had Never Checked What That Column Counts.

Sungsoo Youn — Tue, 27 Oct 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.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My free sample is a PDF that costs nothing. It goes out from two places: an international storefront and a Korean storefront. At the end of the PDF I had added links to the full book's pages at three bookstores. To judge whether that line did anything, my agent first needed to know whether anyone was receiving the PDF.

The first zero came from half the doors

The first version of that judgment counted receipts from the international storefront only. When the count was zero, it named the result not through the door. My auditor rejected it. The same PDF also goes out from the Korean storefront, and nothing measured receipts there. A zero from one of two places is not a zero.

The second zero came from a column I had not checked

So the next step was to measure the Korean side. Its management screen has a sales tab for each product, with a line for buyers. On October 15 the free sample showed 0 buyers there. Its dashboard showed 23 visits and 0 purchases. It had been listed since September 5.

My agent's evening run was already reading that buyer line for every product. When it added the products up, it kept the money and dropped the buyer counts. The fix was small: keep each product's buyer count and write it to a dated ledger. The first row, on October 15, had 15 products, all at 0.

Then I wrote the judgment for the case where both places show zero: nobody had taken the free sample, so the door had not been used yet.

My auditor rejected this too. The sample costs nothing. Does a free order show up in a column called buyers? Nobody had checked. There had never been a free order to check with. And the same block of my own notes already said I did not know whether a free order counts in the dashboard's purchase total. I doubted one count and trusted the other, on the same storefront, without checking either.

What changed

The judgment now carries a caveat: whether the buyer count includes free orders is unconfirmed until the first one arrives. The next step it suggests is narrower too. It says the ledgers show no trace, not that nobody took the sample.

The test file for this change has 27 tests. Of the first 23, 17 failed against the old code; the other 6 tested the new ledger itself. Two more I had written after the code, so after the auditor pointed it out I flipped the source briefly and watched them fail. The last two came with the caveat, and both failed before it was added.

This reaches past the bookstore line. One of my goals is five purchases in 30 days on the Korean storefront. If a free order counts as a purchase there, that goal would be counting free downloads. The day the first free order arrives is the day to compare the buyer ledger with the purchase count.

The rules

Before a column becomes evidence, confirm with a real record that it counts your kind of event. Its name is only a guess about what it counts.
When you write that you do not know one thing, read the sentence next to it. Mine said I did not know one count, then relied on its neighbor.
A zero is only as wide as the places you measured.

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

My Dashboard Told Me to Apply to the Bookstores. Two of Them Were Already Selling My Book.

Sungsoo Youn — Mon, 26 Oct 2026 04:10:05 +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.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

In an earlier note I wrote about a waiting clock for my book's ISBN. The Korean edition sells on a Korean e-book platform, and that platform passes books on to bookstores once they have an ISBN. At the end of that fix I added one more line to my agent's evening summary: when an ISBN number appears, ring a bell that says it is time to request bookstore distribution, and keep it until the request is recorded.

The ISBN was approved on October 6. From October 7 to October 11, five evening summaries carried the bell. The bell even carried its own warning: requesting sale again may send the book back to waiting for approval.

Reading before pressing

On October 12 my agent went to make the request. It opened the screens and read them first, without pressing any button that changes state.

The sales management screen listed eight bookstores, all requested on August 31, the day the book was first submitted for sale. Two showed on sale. One showed sent. Five showed request pending.

The platform's seller help says that a book without an ISBN cannot be sent to partner bookstores, so its requests are held. Nobody had asked again after the ISBN arrived, yet three of the eight had gone out. Five were still pending.

So the request had been made 42 days earlier. The bell asked for something already done. Following it could have cost something. When my agent resubmitted the book on October 1 to replace its file, the status went back to waiting for approval, and the agent read it as on sale again on October 2.

October 12 is only the day I first saw the two bookstores selling it. When they started, I do not know.

Why the bell was wrong

The bell did check for a record of the request. It looked for one field in my agent's ledger. But no code ever filled that field, so it stayed empty. Meanwhile the same ledger already held the August 31 sale request and the list of eight bookstores, and the bell did not look at those. The status of each bookstore was on a screen my agent did not read.

The evening run now reads the sales management screen every day and stores each bookstore's status and the first day it was seen on sale. The summary shows the real status. It rings only when a bookstore rejects or stops the book. If the status cannot be read, it says the status is unknown and that the request should not be repeated.

This fix came with 10 tests, and 8 of the first 9 failed against the old code. My auditor rejected the first pass: the evening run now read one more screen, but two descriptions still said three. It also pointed out that the new screen's address belonged to one book, so it now reads that screen only for that book.

The second gap

The next question was whether my revenue goal would see a bookstore sale. My revenue meter read the sales count on the platform's own public page. Bookstore sales show up in a monthly sales table in the seller dashboard, and they are added once a month, on the 10th.

The evening run now reads that table every day. Two details mattered.

The table also has a column for the platform's own sales. Those are already counted from the public page, so the meter leaves that column out. Otherwise one sale would count twice.
December sales arrive on January 10, in the previous year's table. So the meter reads every year's table from 2026 to the current year. If any one year cannot be read, it records nothing that day.

This came with 13 tests, and all 13 failed against the old code. The baseline on October 12 was 0.

Two things I do not know yet. Whether the numbers in that table are sale prices or the amount paid out to me. And whether the public page's sales count already includes bookstore sales; if it does, the new meter counts them twice. The first bookstore figures are due on November 10, and that is the day to check both.

The rules

A reminder that waits for a record needs code that writes the record. An empty field that nothing fills makes the reminder ring forever.
Read the screen before pressing the button a reminder asks for. This bell came with its own warning about that button.
For every new place that sells, find the screen where its money shows up. The public page my meter read and the dashboard table where bookstore sales appear were different screens.

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

My Visitor Count Fell From 95 to 7 Overnight. Only the Counting Had Changed.

Sungsoo Youn — Sun, 25 Oct 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.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

I sell the Korean edition of my book on one store as 15 products: the main book, a bundle, a free sample, 11 single chapters and one more product. Every evening my agent saves the store's visit count for each product over the last 7 days. A meter then estimates how many of those visits came from people other than me.

Why the meter has to subtract me

My agent opens these product pages itself. A morning check opens every product once a day. Other jobs open the main book, the bundle and the free sample more often. The store counts all of it.

Until October 11 the meter used a floor. It took the lowest count among the 15 products as my own visits and subtracted it from every product. On October 11 that gave 95 visitors out of 215 visits.

On October 5 I had started a ledger that writes down every time my agent opens a product page. Its first full day was October 6. On October 12 it covered the whole 7-day window for the first time, the meter switched to subtracting the ledger product by product, and the number dropped to 7.

What the products showed

Split by product, seven came out at 0. Five were positive: 4, 5, 3, 3 and 2. Three were negative. The main book had 20 visits in the store's count and 28 in my ledger, so it came out at minus 8. The other two were minus 1 each.

Added together, the negative 10 cancelled most of the positive 17.

The negatives had two causes. The snapshot is taken in the 18:40 run, but the ledger kept going after it: the 19:00 report opened the main book and the free sample again. And for the main book, my ledger records more opens than the store seems to count.

A negative number for one product only says that product had no other visitors. It cannot take visitors away from a different product.

The fix

Each product now counts as at least zero, so the total is a lower bound: 17, not 7. The 10 that my ledger counted above the store's count is shown on its own line.

The evening run now also writes down my ledger total at the moment it saves the snapshot, so later visits no longer leak into it. That field starts on October 13.

I wrote 8 new tests first, and 7 of them failed against the old code. The fix changed how the snapshot is saved and the three places that read it: the meter, the experiment judge and the evening report. My auditor rejected the first pass because the judge was covered only by a test that searched its source text. I added a test that runs it. The full suite ran 3,355 tests, all passing.

What the fix showed

On October 12 the store counted 209 visits. At least 17 came from someone else, at least about 2.4 a day. On the same snapshot, the old floor method would have said 104.

My ledger also recorded 74 opens on October 12 against 21 a day from October 6 to October 10. That day my agent's work sessions had checked the public pages many extra times. Those opens stay in the 7-day window until October 18. My weekly traffic goal is 240. If the count passes 240 this week, much of the rise may be me.

The rules

When a number falls on the day the counting method changes, check the count first. Split it by part before believing it.
A negative part means zero, not a debt to collect from the other parts.
Take what you subtract at the same moment as the thing you subtract it from.
Find out how much of a metric is you before you try to move it. My own checks alone can move my traffic goal.

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

My Agent's Skip Rule Switched Itself Off After a Week

Sungsoo Youn — Sat, 24 Oct 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.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

Every morning my agent runs a short job that opens a list of daily links and logs what each one returned: something earned, or invalid. Some of the links are not collected from a page. They are guessed from a date pattern in the address, so on a given day some of them do not exist.

The rule

On September 26 I added a rule to skip guessed links that never pay. For each address pattern, it looked at the last 30 days of logs. If the pattern had been opened on at least 14 of those days, had earned nothing, and had come back invalid on at least 80 percent of them, the job skipped it. Fewer than 14 days meant not enough evidence, so the job kept opening it.

Three patterns met the rule, and from September 27 they were skipped. Invalid results went from 3 to 5 a day before the rule to 0 or 1 a day after it. The invalid ones that remained came from a fourth pattern that still had an earning inside its window.

My experiment judge looked at September 27 to October 3 and wrote that the rule only removed wasted requests: 0.71 invalid a day against 4.00 before, with earnings no lower. I kept it.

What the logs showed

On October 11 I opened the logs for another reason and saw the three patterns in the October 10 run. Counting by day, two of them had come back on October 4 and the third on October 5. Apart from October 7, when the run stopped early for an unrelated reason, the guessed links came back invalid 3 or 4 times a day. Between October 4 and October 10 that was 21 times.

Why

I replayed the old rule one day at a time.

Skipping a pattern meant it produced no new log lines. Each day the 30-day window slid forward and dropped one more day on which the pattern had been opened. For two of the three, the count went from 20 on September 27 to 14 on October 3 and 13 on October 4. At 13, the rule said not enough evidence and opened them again. The third followed a day later.

Once they were reopened, the count stayed at 12 or 13. The window still held the week they were skipped, and my logs have days with no file at all. In the replay, the old rule did not skip them again on any day up to October 12.

The rule's own effect removed its evidence. With a fixed window and no new data, it was always going to undo itself. The only question was when.

The check that missed it

On October 10 an earlier cycle had been asked to confirm whether the fourth pattern was now being skipped. It ran the rule, got an empty set, and wrote that the fourth pattern was not skipped.

The empty set was the finding. Three patterns should have been in it.

The fix

The rule now looks at the last 20 days on which each pattern was actually opened, however far back those are. A skipped pattern's last 20 opened days stay the same, so skipping no longer wears the evidence down. 20 is how many opened days the old window held in practice.

If a pattern has not been opened for more than 30 days, the job opens it once to check. If it is still invalid, it is skipped again the next day. If it earns, it stays.

Replayed over the real logs, the three patterns are skipped on every day from September 25 to October 12. From October 11 the fourth is skipped too. Its last 20 opened days ran from September 10 to October 10, 16 of them invalid and none with an earning. Its last earning was September 8.

I wrote 5 new tests first, and 4 of them failed against the old code. 12 deliberate breakages of the code all made the tests fail, and the full suite ran 3,221 tests, all passing.

The rules

A rule that removes something also removes its own evidence. Before shipping it, replay it forward a few weeks with its own effect applied.
Choose evidence that stops when the thing stops. The last 20 times it ran stays still. The last 30 days does not.
Write the expected answer before running a check. An empty set where three items belong is the finding, not a pass.
A judge window can fall entirely inside the good part. One good week did not reach the day the rule wore out.

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

My Test Checked the Words I Picked. The Auditor Changed the Ones I Didn't.

Sungsoo Youn — Fri, 23 Oct 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.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

One of the rules in my last note was that a test that copies your sentence copies your mistake. This note is about the opposite failure. It happened the same day, on a short post.

The post

My agent queues short Korean posts for another channel. One of them retells a story from an earlier note in this series: my ebook checker printed a pass line, and the store's validator rejected the file I had resubmitted with 17 errors. The post then says what my checker looked at, which was zip layout, XHTML parsing, the copyright page, and that the validator the store uses had not been run until then.

Every sentence in the post matched its source. The rejection comes from my diary entry for that day. What the checker looked at comes from the checker itself, as it was one commit before the validator was added. The test reads that diary line and runs git show on that commit. I wrote a second post in the same cycle, and its test was built the same way.

What the test held

For each post, the test held words I thought were the facts. For this one, that meant words like the 17 errors and XHTML parsing. I broke the two posts 10 ways by hand, and the tests failed all 10 times.

That looked like a good test. It was a test of my own picks. Most of the 10 went after the words I had picked, and none touched two phrases.

The first pass

An independent auditor agent made its own changes to the post.

One turned the file I had resubmitted into a first submission. Another turned had not been run until then into had been run only sometimes. Both made a true post false. Neither touched a number or a name, so the test never looked at them, and it passed.

The auditor also flagged one verb. My post said the checker stamped the pass line on the file. The source says it printed it. I changed the verb.

For the fix, I held longer stretches of each sentence and added the opposite wordings as text that must not appear. My hand breakages across the two posts grew from 10 to 18, and the tests failed on all 18.

The second pass

The auditor failed it again. This time it changed the subjects. One sentence starts with the ebook checker, another with what our tool looked at. Swap who did it, and the test still passed. I had held phrases from each sentence and left the start open.

It also found two gaps in my notes: my diary did not record the first failed pass, and my handoff note's list of source lines left one out.

The fix

I stopped picking. The test now compares each of the two posts with its full text, character for character. The source checks stay next to it as separate assertions: the diary line, the old checker's items, the commit where the validator first appears.

The auditor's own set of 35 breakages, across both posts, failed the test 35 times. The third pass passed. The full suite ran 3,112 tests, all passing.

Why this does not undo the last note

Holding the whole text only says the post did not change. It says nothing about whether the post is true. That half is the source checks.

A test that holds only your sentence, with no source, copies your mistake. A test that holds only the words you picked misses the words you didn't. I needed both, in two places.

The cost is that any edit to the post now needs an edit to the test. The posts are under 200 characters and already written. That is cheap.

The rules

Do not choose which words are the facts. In a short public text, the subject, the verb and the words about time carry facts too. Hold the whole text.
Hold the text and check the source separately. One says nothing changed. The other says it was true.
Your own breakages test your own blind spots. Most of my first 10 went where I was already looking. Let someone else break it.
Add the opposites. First against again, never against sometimes. They cost one line each.

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