Three Months with Claude Code — Building Like Mad, Nobody Coming, Back to My Own Pain Point

On Lunar New Year 2026, I opened Claude Code for the first time. CLI environment, with zero programming under my belt. It was exactly one year after Andrej Karpathy tossed the phrase “vibe coding” onto X.

Three months later. Three subscription receipts. A few all-nighters spent building a single hackathon service. A stretch where I was juggling so many projects in parallel that my head couldn’t keep up. Out of all that, one or two things actually got finished, and next to them sit dozens of folders containing toy prototypes or just an idea pinned down in a README.

This piece is about that three months — the pattern I kept hearing in “oh, you too?” exchanges at meetups, and where I ended up. People who picked up the same tool at the same moment seem to walk through nearly the same stages in nearly the same order.

Is This Really FOMO?

The word I hear most at meetups lately is FOMO (Fear Of Missing Out). Everyone is labeling their feelings with it. But is that label accurate?

FOMO makes the diagnosis too coarse. Once you reduce a feeling to one word, the prescription gets coarse too. “Don’t fall behind — go faster.” So everyone builds more, reads more. The more you build, the more behind you feel, and the more behind you feel, the more you build. A self-reinforcing loop.

What I and the people around me actually feel isn’t one emotion. It’s at least four, running in parallel.

• Dopamine: Someone who has never written a line of code now ships something in a few days. That’s an immediate reward, and it isn’t quantitative — it’s qualitative. The feeling of “I can do this” is what drags you into the next build.
• Excitement: “What could I do with this?” — an open-ended possibility that feels limitless. Ideas fan out in your head. The thought you had on the morning commute becomes a project you fire up at lunch and start running by evening.
• Exhaustion: The fatigue of juggling more than your head can hold. Five parallel builds means five context windows open in your head. Even at night, “where did I leave that project” keeps rotating on its own.
• Reasoned anxiety: The market is actually moving fast. You don’t know what the standard will be a year from now. This anxiety has evidence behind it: Claude Code went general within a year, and crossed an annualized 10-billion-dollar revenue run rate within another six months.

All four operate at the same time. FOMO is a coarse label for just the last one. Prescribe based on it and you miss the other three. Run on dopamine and you only build. Run on excitement and you only fan out, then burn out. What should have been the prescription target — reasoned anxiety — gets diluted into the same single word.

This post sets aside FOMO for a moment and looks at the feelings and patterns mixed inside it separately. Each emotion has a different prescription.

”Oh, You Too?” — Meetup Moments

Over three months, the meetup conversations that repeated most often look like this.

Scenario	Opening line	Reply
The agent turn-around moment	”I used to think AI would just do it for me, and it wouldn’t. Then late last year it suddenly did."	"Yeah, that’s when I first had the ‘aha.’”
The slop factory stage	”I’m building whatever I feel like trying. Just churning them out."	"Right, until yesterday I couldn’t remember which project was which.”
User absence	”But nobody’s coming to it."	"Oh… so I made something else.”
Return to personal pain	”I ended up digging deep into something I actually use every day."	"Same — the satisfaction is on a different level.”
Missing feedback loop	”It was great for a week, then I stopped opening it."	"That’s because there was no learning loop.”

The first time, I thought it was coincidence. The second, “maybe the fields overlap.” By the fifth, the pattern was obvious.

What’s interesting is the perceived timeline. People say “it’s been about six months.” I thought that too at first. Counting carefully, that isn’t quite right. Karpathy’s tweet went up in February 2025 — in his own words, a “shower of thoughts throwaway tweet” that ended up with over four million views. About three months later, in May 2025, Claude Code went general. That’s when a non-developer could enter with stable footing. I first opened it on Lunar New Year 2026, and today is late May 2026. Three subscription receipts. So it’s three months for me, not six.

“Six months” isn’t real time — it’s the density of change inside that window. If you pass through parallel building, user absence, and a return to your own pain point in a single quarter, your sense of time stretches. A year’s worth of learning compressed into three months pulls perceived duration along with it.

The job titles at those meetups also varied. Marketer, PM, designer, consultant, lawyer, café owner, HR, data analyst. The only thing in common was that none of them write code as their main job. Developers are at the meetups too, but the aha-moment amplitude was far larger on the non-developer side. And yet they were walking through nearly the same stages in nearly the same order. When the sequence is constant across different roles, the sequence is being shaped by the tool, not the person.

The recent change I notice most at meetups is that more people are starting to build something specific for themselves and actually use it. Not “a SaaS others will use” — “a tool I open every day.” One or two new people fit that pattern at every meetup. That’s a signal that everyone is converging on the last stage.

One thing worth pointing out

When you pick up the same tool at the same moment, you walk through the same stages in the same order. The tool is enforcing the sequence. This isn’t a problem of individual willpower — it’s a problem of the tool’s affordances. The fact that a non-developer can ship something working within a week forces the slop-factory stage; the fact that nobody comes to that output forces the user-absence stage. Only the people who pass through both honestly reach the return to their own pain point.

The Four Stages Everyone Goes Through

The pattern I found is four stages. They repeat in almost exactly this order.

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    A["Stage 1 — Aha Moment<br>coding-agent turn-around"] --> B["Stage 2 — Slop Factory<br>churning out builds"]
    B --> C["Stage 3 — User Absence<br>missing pain point"]
    C --> D["Stage 4 — Personal Pain Return<br>the real next hypothesis"]
    D -.->|new cycle| A

Stage 1 — The Aha Moment

There was a brief turn-around between late 2024 and early 2025. Before then, the running joke was “I thought the AI would just do it, but every time I asked it actually couldn’t.” That moment ended, and coding agents suddenly started working. People who passed through that window say, without exception, “that was the first time I had the ‘aha.’”

“Aha” here isn’t just a moment of surprise. It’s the realization that “I, someone who can’t write code, can ship something.” Once that realization lands, the next action follows automatically. The next stage doesn’t need to be willed into existence — it gets pulled forward.

Stage 2 — The Slop Factory

The stage right after the aha. You build every idea you ever wanted to try. You really do just churn them out. Instead of finishing one and starting the next, you spin up five or seven at once. Which project is in what state gets mixed up in your head. You open a Claude Code session and forget which directory and what task you were in the middle of.

For me, the peak of this stage was a hackathon service I shipped over a few sleepless nights. The shipped artifact mattered less than the expansion-of-possibility — the discovery that “I can ship something in this timeframe.” During the same window, dozens of toy-prototype and idea folders accumulated in my workspace.

What’s dangerous about this stage is how fast the behavior pattern hardens. “Let me just spin one up” leads to a new directory and a new project every time. By week one, there are ten folders; by week two, twenty. Each folder stalls for a few days, gets briefly reopened, stalls again. Effectively nothing is finished, but a month has gone by.

The real cost of Stage 2 isn’t the ideas — it’s the context load. Five parallel builds means even when you’re lying in bed, “where did I leave that project” runs on its own. The capability discovery itself is over in a few days, but the slop-factory behavior pattern outlives it by a long stretch. That’s what makes Stage 2 drag.

Stage 3 — User Absence, Pain Point Absence

You ship and wait. From your point of view, someone is going to come, someone is going to use it, someone might even pay. Nobody comes.

This is where everyone notices the same thing. What you assumed someone would need and what someone actually needs enough to pay money or spend time for are different things. You committed the hypothesis to code without nailing the pain point.

It’s planning-and-founding 101, and yet you don’t internalize it until you’ve shipped and seen the lack of users yourself. The pain point you read about in a book and the pain point you saw the dashboard for after shipping are different kinds of learning. Only people who refresh the dashboard for a few days and accept “the needle isn’t moving” actually get the latter.

Two avoidance patterns show up at this stage.

• Marketing excuse: “Nobody’s coming because nobody knows it exists.” You defer the obligation to check whether a pain point even existed before marketing. If there’s a real pain and no marketing, at least two or three beta users should still find their way in. If even that doesn’t happen, it isn’t a marketing problem, it’s a pain problem.
• Escape to the next project: “Okay, that one’s done. Let me build the next one.” Same hypothesis-setting pattern, back to Stage 2. Same result. Build five more and you’ll have the same “nobody coming” experience five more times.

Only people who avoid those two and walk through Stage 3 honestly move on to Stage 4. “Honestly” here means accepting the sentence: “the pain point I assumed wasn’t the real one.” That costs ego.

Stage 4 — Return to Your Own Workflow

So everyone pauses, and the question shifts.

“What’s the friction I actually run into every day?”

That question unlocks the next stage. Instead of guessing what someone else needs, you look at what eats thirty minutes of your own day. The real next hypothesis lives in there.

The shape of this stage is that things get smaller. You step down from Stage 1–2 ambition (capture a market, build a tool everyone will use) and focus on seeing your own pain precisely. The tools you build shrink. Instead of a huge SaaS idea everyone might use, it’s one workflow that saves the single person you are thirty minutes a day. But the precision of that one workflow is far higher than what came out of Stage 1–2.

Smaller isn’t the same as less ambitious. The five Stage-2 projects all assumed an average user, and the average user never showed up. The single Stage-4 project assumes exactly one person, and that one person uses it every day. The distance from zero users to one user is greater than the distance from one to a hundred. Stage 4 starts by setting that single user as yourself.

One thing worth pointing out

These four stages aren’t a curriculum or an act of will. They emerge naturally from the gap between how fast capability explodes and how slowly pain detection follows. The ability to build explodes first; the ability to spot real pain trails behind. That’s why Stages 1–2 typically come first. Skip them and try to start at Stage 4, and you risk turning the pain point back into a book-pain — you hypothesize while still in the “I haven’t actually built and watched users not show up” state, and you walk into the same trap from the other side.

My Case — News-Collection Automation

The first thing I touched after reaching Stage 4 was news-collection automation. A workflow that delivers IT/AI news in a single morning batch.

When I describe this to people, the reaction is similar: “isn’t that trivial? Just pipe RSS through an LLM and have it summarize.”

On the surface, yes. But once you look at your own pain precisely, the simple picture breaks in five places, and those breaking points become the workflow’s stages.

Looking at the pain point precisely

The problem isn’t “automate news intake.” What I actually struggled with every day was three things.

1. Single-device dependency: The Chrome recommendations on my Galaxy phone are heavily optimized for me. They disappear on any other device or browser. As a result, the five-minute commute window where I look at that screen has become my one and only daily news intake — and on days I skip it, I work in an information-deficit state the whole day.
2. Headline news vs. one-layer-down news: “IT and AI news” is too coarse. What I actually click isn’t the headline articles, it’s the layer below — personal blogs, Hacker News, certain Reddit channels. On the same topic, the headline catches attention while the layer below contains the part you can act on.
3. Personal curation vs. average-reader curation: Standard newsletters target an average reader. There’s no off-the-shelf newsletter aligned with my actual working context (AI strategy, business consulting, automation). Read commercial newsletters for a week and roughly 70% won’t apply to your work.

Roll those three into one sentence and the pain becomes: “from the thirty-odd one-layer-down sources I actually read, only what’s new today, filtered through my context, in a single delivery.” That one sentence drives every other decision downstream.

Workflow structure

I broke this pain into six stages.

---
config:
  look: handDrawn
  theme: neutral
---
flowchart TB
    A["1. Source Curation<br>35 sources · 5 categories"] --> B["2. Multi-category Parallel Collection<br>04:00 KST + 06:00 safety-net"]
    B --> C["3. Collection Dedup<br>URL · title prefix · topic-word overlap"]
    C --> D["4. Date Cutoff<br>1–3 days, per source"]
    D --> E["5. Curation (LLM)<br>05:15 KST · 60–80 → 20"]
    E --> F["6. Feedback Loop + Reports<br>up/down → rule updates"]
    F -.->|periodic expansion| A

1. Source Curation — start by re-examining the routine

I started from the routine. I wrote down “where do I normally read news?” by time slot. Five minutes on the commute (Galaxy Chrome recommendations), ten minutes before morning work (Hacker News front page), five minutes after lunch (specific Reddit channels), ten minutes at end-of-day (personal blogs in my areas of interest). Thirty minutes total.

The key finding was that the Chrome recommendation feed had already been optimized to me once. When I pulled out the articles I tend to click from that feed, I ended up with about thirty-five sources. The share of personal blogs, case-study blogs, Hacker News topics, and specific Reddit sub-channels was much higher than mainstream media.

Instead of handing all thirty-five candidates to an LLM at once, I narrowed them by talking through my routine. “Why do I read this channel every day?” “What kind of articles do I actually click from it?” — repeating these questions while sorting the meaning of the thirty-five. The end state is that even though it’s still thirty-five sources, each carries a different weight and collection cadence. Some are checked once a day, some hourly, some once a week is enough.

I then organized the thirty-five into five categories by fetch method: RSS · Atom feeds, Hacker News (Algolia search API), web scraping (static-page cheerio + selector), Reddit sub RSS, and the Tavily search API. The categorization isn’t a pain classification — it’s a distinction of how the data is shaped on the way in.

2. Multi-Category Parallel Collection

Trying to fetch all thirty-five sources in one way breaks immediately. Each category has a different shape: RSS-open sources are five-minute affairs, but dynamically rendered sites don’t have RSS. So all five categories fire in parallel, once a day.

• RSS · Atom feeds: XML parsed with cheerio, pubDate or published for the date.
• Hacker News: keyword queries to the Algolia search API, restricted to stories from the last 24 hours.
• Web scraping: cheerio + selector against static pages for titles and links.
• Reddit: subreddit hot.rss parsed by entry. [D] and [P] prefixed posts are filtered out (discussion and project posts aren’t curation targets).
• Tavily Search: advanced search against a fixed query and domain whitelist (days=2).

Schedule: main collection at 04:00 KST, safety-net re-check at 06:00 KST. An hourly cron is wasteful on both cost and duplication. Once a day at dawn, plus a single 06:00 retry if the row is missing, is operationally enough. (On 2026-04-08, node-cron silently missed the 04:00 tick under WSL2 idle suspend. The 06:00 safety-net was added after.)

The principle of this stage is that all five categories are deterministic. Tavily is LLM-flavored search, but the query and domain whitelist are fixed, so the same input yields the same output. The place where the LLM enters is curation (Stage 5), not collection. Blur this distinction and collection cost slips, and the variance between same-input-different-output rises.

3. Collection Dedup — URL · title prefix · topic-word overlap

Five categories often see the same event five times. So a single dedup pass runs right after collection. Three comparisons, in order.

1. URL normalization — strip query strings and fragments, normalize trailing slashes, exact match. Removes the same article reaching me via different tracking parameters.
2. Title prefix — strip non-alphanumeric characters, lowercase 60-character prefix, exact match. Removes cases where the same outlet indexed an article twice.
3. Topic-word overlap — words of four or more characters, stop words excluded; three or more shared words counts as duplicate. Bundles cases where different outlets covered the same event.

The third pass is the body of cross-source dedup. The version with a description is usually kept; the others are folded in. No embedding model. At a daily scale of ~100 items, string + token overlap is precise enough relative to its cost. Embeddings would add per-call latency and pull cache-expiry policy into the operations surface.

This single pass typically drops the count from 80–150 items to 60–80. The lower the count, the higher the signal density of what remains.

4. Date Cutoff — per-source

Ideally collection itself returns only today’s articles, but each category leaks older ones in. So there’s a per-category cutoff.

Category	Cutoff	Where applied
RSS · Atom	3 days (lenient)	Client-side filter, entries with no date pass through
Hacker News	24 hours	Algolia numericFilters=created_at_i>
Reddit	3 days	Client-side filter on entry.updated
Tavily	2 days	API parameter days=2

The lenient policy for RSS and Reddit is intentional. Drop every article without a parsable date and a subset of RSS feeds lose all their entries. Taking a little noise from a short cutoff beats missing a good article on a longer one.

I don’t outsource the cutoff judgment to the LLM. The curation LLM frequently breaks “give me only today’s news” instructions. Its date inference past its training cutoff is weak, and it tends to overwrite metadata-published dates with body inferences. There was a case where a month-old article got tagged as “published today” and passed even through dedup because another outlet covered the same topic anew. So date-determination is owned by the deterministic pipeline, and semantic selection is owned by the curation LLM. The split is explicit.

5. Curation — where the LLM finally enters

Collection, dedup, and cutoff are deterministic. The semantic-curation step is where the LLM enters, for the first time.

A separate LLM job fires daily at 05:15 KST. Input: today’s row of daily_news_raw (typically 60–80 items post-dedup and post-cutoff). Output: 20 items in daily_news plus a single overall headline. The selection rules:

• Six-tier priority: new models/benchmarks → methods/agents → tools/frameworks → products/funding → industry/regulation → consulting reports (only if published within 14 days).
• Source balance: maximum three items per source, maximum three items per topic keyword (OpenAI, Claude, Gemini, Meta, etc.).
• Cross-day fatigue: if the same keyword appeared two or more times on each of the prior two days, today’s limit is one — a code-level guard against the “reader gets bored of the same topic” pattern.
• Cross-day dedup: any URL that already appeared in daily_news within the prior 14 days is auto-excluded.
• Writing rules: headline in causal form (two or three proper nouns + WHY), no “etc.”-style enumeration. Each item is three Korean bullets, each at least 50 characters as a complete sentence, with two or more of (a) numeric/before-after, (b) HOW mechanism, (c) concrete prior-state-to-now delta.

A jq pipe runs lint one more time before save: exactly 20, source/topic ≤ 3, every bullet ≥ 50 characters. If any rule fails, the LLM rewrites that slot on the spot.

The operational point is that the LLM isn’t a single-line passthrough — dedup, balance, and lint rules are pinned around it explicitly. “Just let the LLM figure it out” is the same sentence as losing control of the surface. The curation output becomes the body of that day’s single delivery.

6. Feedback Loop + Missing-Item Reports

Every delivered article splits into “this is actually great” and “I didn’t really need this one.” I didn’t want that signal to evaporate, so up- and down-vote buttons are placed in a first-class slot at the end of each delivery. If they’re hidden one level in, they don’t get clicked.

• The news_feedback table: per-item rating (up · down) plus a free comment field.
• The news_feedback_weekly view: thumbs_up, thumbs_down, and approval_rate per day.
• Periodically I pull comments from low-approval days and revise the Stage-5 curation prompt and the Stage-1 source categories. When recent downvotes cluster on “Outdated,” the writing rules for announcement items get tightened with conditions like “must include at least one of: explicit delta vs. prior version, release date, benchmark change.”

The missing-item channel isn’t separate — it’s integrated into this same feedback loop. When a comment says “this should have come through,” the next round either adds a source to a Stage-1 category or adjusts a search query. The system gets better the longer it runs. Without this channel, the workflow would freeze on day-one’s thirty-five sources, and expansion into new areas (AI safety, regulatory news) would never be reflected automatically.

Three decisive trade-offs

Can I recommend this workflow to someone else as-is? “Not as-is.” Three trade-offs are the splitting points.

Trade-off	One end	Other end	My choice
Generality vs. personalization	Average-reader newsletter	Per-user, context-bound curation	Latter (reusability sacrificed)
Full-LLM pipe vs. deterministic + LLM split	LLM does collect, filter, summarize	Deterministic collect/dedup/cutoff, LLM only for curation	Latter (cost, reproducibility)
Out-of-the-box vs. learning loop	Useful day one	Up/down accumulate, then update	Latter (precision compounds over time)

The common thread across my picks: trade short-term efficiency for long-term precision. A workflow you use every day usually gains value as it stops generalizing. Generalization is the act of meeting an average; a daily tool needs to match one person’s pattern, not the average.

One thing worth pointing out

The deeper the personal pain, the more separation between “easy-looking” automations like this one. If you automate the surface, you get a surface-level result. If you precisely see the pain first and then automate, you get a tool that nobody but you can really use.

The path from there to a generalizable SaaS is one layer further down. But the fact that your own pain is getting deeper is, by itself, the real hypothesis for the next build. Interviewing a hundred users in the same domain usually yields lower per-hour learning than digging deep into your own single workflow.

The Reframe — One Line

If I compress three months of observation into one line, it’s this.

“What looks like FOMO is a return signal.”

You start out feeling like you need to keep up with everything. So you build. While building, you notice the absence of a real pain point. People who built where there was no pain go back to their own pain. People who go back to their own pain start looking at it precisely. That’s where the real next hypothesis comes from.

If this flow really is the sequence the tool enforces, there’s no point in denying Stage 1. The cost is in staying in Stage 2 too long. Five parallel builds isn’t an exaggerated load — it’s a real one. And it’s not the kind of fatigue rest resolves; it’s context cost, so it only releases when you cut the number of parallel builds.

Three operating principles distill it.

1. Stages 1 and 2 short: The aha arrives by itself, so it isn’t really an operations target; but the slop factory should be a few days to a few weeks at most. The moment you’re juggling five in parallel is the moment to stop. Beyond that you’re no longer discovering capability — you’re avoiding.
2. Stage 3 honest: If users don’t come, users don’t come. Using “I haven’t done marketing yet” to dodge Stage 3 closes Stage 4 off. The honest question to ask yourself is whether the pain point was actually correct. Even short of marketing, trying to recruit two or three beta users is on the table.
3. Stage 4 deep: The depth at which you look at your own pain decides the depth of the next hypothesis. That’s why news-collection automation breaks down into six stages. Take any “easy-looking” automation seriously and the mechanisms of your own domain are sitting inside it.

Run these three as a one-week retro and you can check the pattern every Sunday. Did Stage 2 drag in week one? Did Stage 3 get dodged in week two? Is Stage 4 getting deeper in week three? The retro itself doesn’t need to be heavy. Ten minutes on Sunday evening is enough.

When we say “oh, you too?” at meetups, the thing we’re actually confirming isn’t fear. It’s that we’re walking through the same sequence of stages enforced by the same tool, in the same order. That’s a more accurate label than FOMO.

Three months in, I’m running the single survivor out of dozens of Stage-2 slop folders every day, and I’m crossing the threshold where its learning-loop count of ups and downs passes fifty. The hypothesis for the next build is growing inside that loop. That’s the next path the return signal pointed to.

---

Sources

• Andrej Karpathy, “There’s a new kind of coding I call ‘vibe coding’…” X (Twitter), 2025-02-02
• “Claude Code was released for general use in May 2025.” Hacker News thread, 2025