Wall of Pitfalls & Reflections
Currently 31 notes, each one earned from a real project, with new ones pinned up regularly. On mobile, tap a note to expand the full text.
Hard-won lessons
A parallel pipeline without rate limiting is an amplifier bolted onto a single point of failureOne runaway process can eat all the resources and bring the whole line to a halt — parallelism amplifies not just throughput, but also failures. The first thing to do when writing a pipeline is to set a concurrency cap, not to let it run.
Trust is built bit by bit, but it collapses in an instantOne poorly executed release dealt a heavy blow to the project — the trust accumulated through daily punctuality and correct results was wiped out by that single failure. The little extra validation before going live is always cheaper than explaining afterward.
After AI labeled my project a 'legacy mess,' I wrote my first regression testI ran an AI-assisted review of my own project, and it graded without mercy. The fix wasn't a rewrite; it was freezing a gold-standard snapshot plus assertions: if the numbers don't match, you're not allowed to say 'done.'
Before starting, write down 'how to know it is correct'Before starting, write down what command to run and what numbers to look at to accept the work when it's done. It is both the embryo of a test and the best constraint you can give an AI-assisted workflow.
'Looks like it's running' ≠ 'actually working'Cron failed silently 22 times before it was noticed. Silent success and silent failure look identical from the outside — all automation must have failure alerting.
An API saying 'success' does not mean the data actually landedThe Feishu (Lark) API returned 200, but the data was not written into the table. Since then, every write must be followed by a read-back verification.
Discuss first, then actWriting code before aligning on the approach costs ten times more in rework than discussing it upfront. Long tasks need continuous progress reporting.
'It will take only two or three days' is an illusionA prototype ≠ production delivery. In between are guardrails, alerting, edge cases, and acceptance. One's sense of speed needs to be calibrated.
If you're not sure, say you're not sureOne time saying 'it works' when it actually didn't takes ten times of 'it really works' to make up for. The trust account cannot survive overdrafts.
Back up before changing productionIn a production environment, there is no 'it should be fine.' Leaving yourself a way back before making changes is the cheapest insurance you can get.
New features: integrate first, activate laterWire it into the system but keep it turned off; open it only after validation. Canary release is a release strategy even the poor can afford.
Configuration and tooling maintenance are hidden costsI counted my own sessions: 24% of the time was spent on configuration, environments, and tooling. This is the bill nobody tells you about in Vibe Coding.
The first night of multi-agent interconnection, they chatted all night longTwo agents replied to each other politely forever, burning tokens until dawn. Rate limiting and circuit breakers are not optional.
Chinese and Windows are the two biggest traps in automationFull-width punctuation, encodings, path separators — I've stumbled over these more than over any algorithm.
The first 80% is easy; the last 20% decides everythingEveryone is fast at the prototype stage. What decides whether a project is actually good and whether anyone really uses it is the final 20% — and that is the hardest part. Without disciplined tests and disciplined reviews, technical debt keeps compounding, and the further you go, the harder it becomes to keep building.
Deep thinking
Spread thin, force dilutedThe more fronts you open, the less attention each one gets. Focus on the most important thing first: make it work, then open the next front.
Drucker's ledger: if technology doesn't create customers, it goes on the cost side'The purpose of a business is to create customers; marketing and innovation are the only two productive functions, and everything else is cost.' Notice how he keeps the books — knowing technology itself is not on the output side; if technology does not directly create customers, it is booked as cost.
Action tendency formulaAction tendency ≈ value priority × self-efficacy × path clarity × feedback speed × environmental support ÷ immediate cost
AI is the typist; I am the architect + reviewer + acceptance testerWhat I need to train isn't writing code; it's three things: translating requirements into acceptance criteria, the eye to read diffs, and turning discipline into mechanisms. The code is AI-assisted; the responsibility is mine.
I don't trust self-discipline; I trust the gates in the codeReview gates, dual-gate activation, automatic snapshots — I've installed quality gates in other people's systems for so long that I finally realized my own development process needs the same philosophy. Every pitfall becomes a rule, and that rule automatically takes effect in the next session — this loop compounds.
There is really only one experiment I am runningWhether a resource-constrained but fast-moving individual can use AI-assisted workflows to have the execution power of a small team. Every project is a subproblem of that question.
More projects ≠ more deliveryExperience from projects without closure evaporates. Ten things half done are worth less than one thing fully delivered.
What counts as 'delivered'?Real users, continuous use for at least two weeks, feedback-driven iteration, and a retrospective. Anything short of that is only 'partly done' and cannot be packaged as a case study.
AI is an executor, not a decision-makerIn January I thought AI was a fun tool; by April I understood: direction, acceptance, and responsibility always remain in human hands.
Businesses don't care what model you useThey care about results: how many labor hours were saved, how many more leads came in, how much the error rate dropped. Technical narratives must be translated into business language.
Compress complex reality into the smallest system that runsAgentLink converged from a heavyweight architecture to 200 lines, and the AI customer service went from an ideal route to a realistic route. Maturity is not making things more complex; it's converging harder.
Context is the leverage of the AI eraThe stronger AI gets, the more it needs high-quality personal context. I distilled 1400+ sessions into a book that agents can inherit — experience should not die when the conversation ends.
Content isn't self-expression; it's an entry pointEvery case study I write is simultaneously a customer acquisition channel, a trust credential, and a proof of capability. Doing things without saying anything is the same as not doing them.
The path: deliver first → then case study → then solution → then productThe order cannot be skipped. A solution without delivery is just a slide deck; a product without case studies is just self-indulgence.
A pioneer isn't self-proclaimed; the title is earnedOnce there are complete case studies, stable revenue, and external recognition, the title will come naturally. Right now my identity is just one thing: an AI automation deliverer in real business.
What users want is not what you think is goodThe biggest trap in product building is mistaking what you find useful or convenient for what users need. You have to get inside the world of real users and investigate their opinions. The same applies to enterprise AI implementation — whatever you build apart from users, no matter how polished, will be used by no one.