DEV Community: Byunghee Kim

A year of coding by talking: what I gained and what I lost

Byunghee Kim — Wed, 26 Aug 2026 06:35:29 +0000

2024 was the year AI was everywhere. The ads, the praise, the feeling that something had already been decided without me.

I am in my fifties. I had to decide whether to watch or take part.

I decided to take part. I started with VS Code, on a paid plan.

I did not have to think about what to build. Something had been sitting in my head for years: an automated trading system.

I have lived fifty years, and while raising children the money got tighter, not looser. Financial freedom was moving away from me, not toward me. So I wanted to make money with automated trading. I think the idea first arrived in my mid-forties. That is why the decision to take part came so quickly.

Whatever I said out loud would simply get built. That was the hope I walked in on.

I do not really know how to code. But the AI would handle that part, so I trusted it.

Where the illusion first cracked

A year inside VS Code taught me that two names mattered: GPT and Claude. I used them in turn. I used them one at a time.

Two problems.

First, even on a paid plan the usage ran out fast. Faster than I expected. The road ahead was long and I was sitting still, waiting for a quota to reset.

The second one was worse.

The explanations were excellent. The results were not.

That is where the illusion cracked for the first time.

I still could not let go, so I paid for more. Adding Cursor bought me some headroom. And a different problem showed up immediately.

Switch the model and it wants to start over

Change the model, and it wants to rewrite everything from the beginning.

Handed code written by a different AI, it would rather replace the whole thing than edit it. That is when I understood that switching AI mid-project is a bad idea.

Everyone talks about pricing. Almost nobody talks about this one. And this is the one that actually held me back.

I spent a lot of time fighting the tool. In the end I paid for Claude's hundred-dollar plan, and from then on I worked with Claude.

What I gained: the job nobody wanted

I worked on trading at home, whenever I had time. Then at work I ran into a repetitive data-entry task.

Other people usually handled it, and all of them found it painful. When something got entered wrong, the stress was real. I took my turn at it too, and I hated it.

That is when Claude came to mind.

Not really believing it would work, I said I would try to automate it, and started building.

This did not go smoothly either.

As the code got longer, it kept showing me that it no longer knew what it had done. So I decided to split the files, and asked Claude to split them. That finished quickly.

That is where the trouble started.

Splitting the files made it worse

It started working without knowing what was in which file.

The same change would land in several files at once. It sprawled. I told it to check the files. Every new session it fell apart again.

It kept happening, so I merged everything back into one file. I did that out of pure frustration. By then the code was five thousand lines.

Writing documentation did not occur to me at that point. Merging was the only move I had.

The automation worked in the end.

What was left behind was a single file of more than ten thousand lines. I would not recommend it to anyone. It was simply the best I could do at the time.

That was where I felt the limits again, and started looking for another way.

Maybe the AI is the one that needs the standards.

That thought started here.

The whole thing took about two months. It felt like a small success inside a beginner's failure.

What I did not get: the trading system

I still do not have it.

Every time I thought it was close, something came back to tell me it was not.

The bigger problem was somewhere else. There were many tests. There was a great deal of verification. All of it stood alone. None of it was ever brought together.

Claude would tell me it was all there. What was there were test results. There was no integrated file that actually traded.

That one was heavy. I still could not let go, because the dream of it keeps circling in my head.

Both stories turned out to be the same story

I only saw it while writing this.

What I built and what I failed to build had the same cause.

	outcome	what actually happened
the data-entry automation	worked	I put the scattered pieces back together
the trading system	did not	I never managed to put them together

Same illness, twice. One of them I could reverse. The other I could not.

So this is where I have landed.

The AI needs standards, and it needs records. Not because it is bad at its job, but because its limits are clear enough that I should be the one preparing for them. That is a statement about what I have to do, not a complaint about the tool.

This series is the record of that year. It is not a success story. It is an account of what the AI was looking at, what I was looking at, and why the two kept failing to line up.

Will this ever work?

I still do not know.

Unread badges that would not clear: 59 of my 64 messages were junk

Byunghee Kim — Wed, 26 Aug 2026 06:29:16 +0000

I am building a small chat feature for an HR system. Shared hosting, PHP, no WebSocket, polling every few seconds. Nothing exotic.

Then a bug report landed. This is what I actually wrote, translated from Korean:

"If I open room A, it gets read. So if I close it and open another room, it should stay read. But that doesn't happen — the badge on the room I already opened is still there."

The original had two typos in it. That tells you how many times I had already retyped it.

The symptom

Open room A. Badge clears.
Open room B. Room A has a badge again.
Nobody sent anything. I was the only person on the server.

That last line is what made it worth writing about. Unread messages were appearing in rooms that nobody was in.

Wrong theory #1: the read-state cookie

The engine stores "which messages you have already seen" client side. My first guess was an encoding problem — the value round-tripping badly, so the comparison silently failed.

I checked. The cookie was fine.

Wrong theory #2: a stale high-water mark

Second guess: the "last message ID I have seen" was being captured before the room finished loading, so it lagged one step behind. That would explain a badge reappearing exactly one room-switch later, which is what it looked like.

Also wrong.

Two theories, both plausible, both about why the counter was reading the data wrong. Neither of them questioned the data.

What actually found it

I stopped guessing and counted rows.

SELECT LEFT(text, 14) AS kind, COUNT(*)
FROM chat_messages
GROUP BY kind
ORDER BY 2 DESC;

/channelEnter    31
/channelLeave    28
real messages     5

64 rows in the table. 59 of them were not written by a human.

The cause

The chat engine writes a system message every time you enter or leave a room. There is a config flag that is supposed to turn this off:

'showChannelMessages' => false,

The name is exactly right, and that is the trap. It controls showing. It does not control storing. The rows are still inserted, still owned by a channel, still newer than your last-seen marker — so the unread counter counts them.

Which produces this:

Open room A  ->  system stores "entered" in room A
Open room B  ->  system stores "left"    in room A
             ->  room A now has 2 unread messages

The act of switching rooms was generating the unread messages. I was the one creating them, by clicking around looking for the bug.

The fix

The engine is a third-party library and I did not want to patch it, so I overrode one method:

function insertChatBotMessage($channelID, $messageText, $ip = null, $mode = 0) {
    if (!$this->getConfig('showChannelMessages')) {
        $t = (string) $messageText;
        if (strpos($t, '/channelEnter') === 0 || strpos($t, '/channelLeave') === 0) {
            return;                          // not shown -> not stored
        }
    }
    return parent::insertChatBotMessage($channelID, $messageText, $ip, $mode);
}

Nine lines. The rule it encodes is one sentence: if we are never going to display it, do not write it.

Two follow-ups were needed, and I would have missed both if I had stopped at the first one:

Exclude system rows from the unread count — the junk already in the table does not delete itself.
Exclude them from search too. Otherwise searching for a username returns a wall of /channelEnter username. Same rows, second symptom, different screen.

The effect

	before	after
unread per room	16 · 5 · 8 · 3 · 6 · 6 · 4 · 2	2 · 1 · 0 · 0 · 0 · 0 · 0 · 0
junk share of table	92%	0 new rows

The second row mattered more than the first. On shared hosting the messages table is the only thing that grows without a ceiling, and I had been sizing a weekly archive job around it. I was designing storage policy for a table that was 92% garbage.

What I would keep

A flag named after the UI can quietly own the database. showChannelMessages reads as a display setting and behaves as one — and still writes rows forever. If a boolean controls both display and persistence, the name will only ever describe one of them.

When a counter is wrong, count the rows before theorizing. My two wrong theories were both about the reading side, because that is where the visible code was. The query took thirty seconds and ended the argument.

A bug that only shows up when you go looking for it is not rare. Switching rooms was both the diagnostic action and the cause. That is worth remembering the next time something only reproduces while you are watching.