eongchen

Location: Wellington, New Zealand

Remote: Yes (worldwide)

Willing to relocate: No

Technologies: Kotlin, Swift, Flutter, Python, TypeScript, Node.js, NestJS, AI Applications, RAG, AWS, GCP

Portfolio: https://chenchen.guru

Email: eong.chen@gmail.com

15+ years in mobile engineering. Built and shipped multiple products:

- Tutor AI Solver: AI-powered education app, 100K+ downloads. Built a knowledge graph system for curriculum grounding and concurrent model racing for speed optimization.

- AgentForge: AI agent orchestration platform connecting multiple AI services (VertexAI, OpenAI, Anthropic) into unified workflows.

- canghai.ai / inkborne.pub: AI-powered serialized fiction platforms (Chinese + English), using human+AI collaboration model.

Strong across Android (Kotlin, Jetpack Compose), iOS (SwiftUI), Flutter, Python backend, and TypeScript/Node.js. I've led engineer teams, shipped products to millions of users, and I understand AI from both the builder and user perspective.

Looking for senior/staff mobile engineering or AI engineering roles at startups. Open to contractor arrangements for US-based companies (NZ entity). Available from August.

The 100 hours aren't a vibecoding tax. They're an engineering knowledge tax.

I built 4 AI products to hundreds of thousands of users, working with AI agents as collaborators, not autopilots. The difference isn't the tool. It's whether you can tell the AI is wrong and stop it before it wastes 10 hours going down the wrong path.

The author watched Claude create new S3 buckets for several rounds before catching it. An experienced engineer catches that on the first diff. Most of those 100 hours were spent not knowing you're lost.

"Vibecoding" as a concept is the problem. It implies you can vibe your way through engineering. You can't. AI is a force multiplier, not a replacement for knowing what good looks like.

I've had to deliberately strip em-dashes from my writing, even though sometimes they're genuinely the right punctuation for expressing a complex thought. The reason? I use AI to polish my professional writing (including this one), and em-dashes are the first thing I remove during review because leaving them in makes it look like I just hit "send" on an AI response without reading it.

The irony is that in tech, almost everyone is using AI to improve their writing at this point. And often it does make things clearer and more concise. But we've created this weird social norm where the output needs to look like it wasn't touched by AI, even when everyone knows it was. So we all spend time manually roughing up perfectly good text to maintain the illusion of authenticity.

This article is solving a problem that shouldn't exist in the first place. If you're loading 84 MCP tools into every session, the issue isn't MCP vs CLI, it's that you've turned on everything without thinking about when each tool is actually relevant.

MCP's token cost is the price of availability. The fix isn't to replace the protocol, it's to only activate the tools that matter for the current context. Claude's Skills already work this way -> lightweight descriptions loaded upfront, full definitions fetched on demand. That's essentially the same lazy-loading pattern CLIHub describes, just built into the model's native workflow.