How I Think

Every system eventually finds its bottleneck.

Sometimes it's a database. Sometimes it's a deploy pipeline.

In 2020, mine was a Python runtime on an on-prem server I wasn't allowed to touch.

First year on the job. A sentiment model that worked, and no way to ship it.

In 2026, it was my own attention.

Vibe coding multiplied what one person could ship by tens. Past a point, the only bottleneck left to move was me.

So I stopped trying to work faster.

I redesigned the system instead: one where I'm only needed for exceptions.

ambitstock · office-simulatorrecorded from the live system

ambitstock, right now
One master agent, an agent for each site, and me above them with the master. The shape exists to push the human bottleneck as far back as it will go, and to get more done.

I like understanding a system well enough to explain every tradeoff in it.

That's the kind of system I enjoy building. The rest of this site is why.

Keep reading

Chapter 1 · 2020

Why can't good models reach production?

A first-year model that worked, and the on-prem runtime that wouldn't let it ship.

First year on the job. Found a pile of review data that no one was reading systematically, and started reading it.

Built a sentiment model to make sense of it. Logistic regression, nothing fancy. Classified every review by sentiment and category, then led the business meetings on what it found.

It worked. It never shipped. The last step, deploy automation, ran into an on-prem Python runtime I wasn't allowed to touch.

data
model
runtime
deploy
production

assembled, then stopped at the last piece

A good model is the finish line, I believed. The environment decides the outcome.

That unfinished pipeline set the direction for the next six years.

Questions I'd enjoy discussing

Chapter 2 · 2023

Why doesn't SEO reward effort?

Six months of rejections, four blogs stuck at a dollar a day, measuring instead of guessing, and the platform that taught me to own what I build.

Started a blog. Six months of AdSense rejections before a single line of it earned anything.

So I stopped guessing. Taught myself SEO, then GA and Clarity, and started measuring instead of trusting my intuition. Four blogs later, traffic was real and revenue was still stuck near a dollar a day.

Tried a different channel to understand reach: a YouTube channel set up for a US audience reached ten thousand subscribers in three months. Then a platform I did not own, Tistory, deleted my highest-earning post without warning.

That incident convinced me that anything meant to last should run on infrastructure I control.

Moved every asset onto my own infrastructure. Set canonicals, kept the 301s, absorbed an indexing incident along the way, and brought the Naver rankings back.

migration
Same effort, plotted over time. The floor is the blogs; the rise starts where the assets moved onto infrastructure I control.

Effort ranks, I believed. Unmeasured intuition is usually wrong.

Questions I'd enjoy discussing

Chapter 3 · 2025 → 2026

How should humans operate AI systems?

When content generation stopped being the bottleneck and my attention became it, I redesigned the system around that: a master, one agent per site, and a human kept for the exceptions.

Once I was running more than a few sites, I realized content generation wasn't the bottleneck anymore; my own attention was.

The system

A master and one worker per site. Each site's agent receives its work, runs it, and reports back. Around a hundred posts a day move through it. I am only in the loop for the exceptions.

The protocol

For how they talk, I went to first principles instead of the newest framework. The coordination is a mailbox and a filesystem, borrowed from 1970s mail systems.

I wanted a structure I could understand completely, and honestly, building it that way was fun.

The harness

The quality control is a context budget. The base spec stays under two hundred lines, posting has its own narrow spec, and indexing is handed to IndexNow automatically. The constraint is what keeps the output from drifting.

Rendering is not separate from revenue

Under it all is one line, and first-party analytics across all thirteen properties is how I can see the whole of it.

One person designs and operates that entire chain. That is the argument of this chapter.

Then, what that validated

per month

Someone on the internet found this useful enough to generate revenue every day.

How I Debug · an interactive incident

A real one. You pick where to look. I show you where I actually looked, and why.

incident · rpm-dropDay 1

RPM on the biggest site dropped from $8 to $4. Nothing was deployed... or was it?

  1. 1The numbers dropped overnight. Where do you look first?

    Hover a path to see what it would show.

Six years later

The step that could not reach production in 2020 is the same step that now ships a hundred times a day. The pipeline finally closes.

data
model
runtime
deploy
production

the piece that stalled in 2020, fitted

Three windows onto the running system

office simulator
ambitstock · office-simulatorrecorded from the live system
analytics dashboard
ambitstock · analytics[ASSET-3]
operator screenshot [ASSET-3]
First-party analytics, all thirteen properties in one view.
revenue
ambitstock · revenue[ASSET-4]
operator screenshot [ASSET-4]
Validation, plotted. Search intent in, a small daily signal out.

Questions I'd enjoy discussing

I never planned to build thirteen websites.

I only kept solving the next bottleneck.

None of these were the real problem. They were symptoms.

The real problem was that I didn't yet understand the whole system.

Chapter 4 · Principles

  1. Understand before abstracting.from the mailbox
  2. Measure before trusting.from six months of failure
  3. Own what must last.from the platform that deleted the post
  4. Move the bottleneck, don't fight it.from attention to orchestration
  5. Learn top-down, when the need is real.from the diary

I write something every day. Not what I did, just what I'm seeing right now. One line counts. After enough years of this, you notice that to write anything down you first have to decide what matters, and to decide what matters you have to see the whole thing.

I don't collect technologies. I collect explanations.

Chapter 5 · The Day Job

The same person, inside an enterprise.

As a first-year engineer I decided the fastest way to become useful was to do all of it. Store display, membership, customer support, orders, the parts most people would rather skip.

I believed experience could fill whatever I lacked, and that the tasks no one rushes to take are where the interesting problems hide. The difficulty was the point, and so was the satisfaction of working my way back out of it.

Where
Hyundai Department Store Group, six-plus years.
Greating
Built the storefront from launch and owned display, product, event, and promotion end to end, alongside order, membership, CS, and infrastructure. An unusually wide scope for one engineer, and exactly the breadth I wanted.
Delivery
Designed the delivery path myself: from manual jar uploads over SVN to Jenkins, then Bitbucket and Bamboo. Wrote the deployment shell scripts and led the infrastructure analysis.
Data modeling
An interest in how data is shaped, not just queried, led me to get certified in data modeling and SQL (SQLD).
Papia
Led the company AI learning crew and brought agentic coding into daily work. First result: a viral-mention tracker that pushed Teams alerts when community response spiked.
Now
Since November 2025, on The Hyundai e-commerce team: five global brands (COS, ARKET, & Other Stories, TOTEME, NANUSHKA) and five NCP shop-in-shops. Akamai, React, Next.js, Tomcat, Oracle.

Questions I'd enjoy discussing

Everything on this site exists because I got curious once.

The rest is just accumulation.