WayLim

Nearly 50 | 20+ yrs in marketing | Started coding from scratch in Jan 2026 | Building a new chapter. AI / SaaS / Builder.

[WayLim @WayLimX]

Dynamic Workflows + 100s of parallel subagents = the persistent
memory layer becomes the bottleneck.

Built WayPalace as the local-first answer: ChromaDB + bge-m3,
23-wing per-project isolation, zero cloud calls. Pairs cleanly
with Claude Code via hooks.

MIT, 92% Recall@10:
https://t.co/kFV8NjyOac

[WayLim @WayLimX]

What’s the most frustrating problem when using AI for planning and development?

It keeps forgetting the context.
It doesn’t remember who you are.
The same mistakes get repeated, and the same information has to be explained over and over again.

WayPalace is a local AI brain.

By vectorizing and intelligently connecting every interaction between you and AI, WayPalace simulates human memory mechanisms, enabling AI to remember your goals, preferences, projects, and historical decisions.

No more AI amnesia.

Give your AI a persistent memory that learns, grows, and evolves with you over time.

[WayLim @WayLimX]

1/ Every new Claude Code conversation forgets your project context.

I built WayPalace to fix this — a local-first long-term memory layer for AI coding assistants. Zero telemetry by design. MIT licensed.

https://t.co/kFV8NjyOac

2/ The problem we all face:

— Re-explain your project structure every Monday morning
— Re-debug the same Cloud Run / OAuth bug you fixed 4 months ago
— Worry about pasting Project A's secrets into Project B's chat

mem0 / Letta default to their cloud. WayPalace doesn't.

3/ How it remembers what you write — automatically.

When Claude Code writes a memory file, WayPalace auto-indexes it in ~20s via a PostToolUse hook.

No client.add() calls. No taxonomy decisions. You write the note, the system remembers.

4/ Cross-project secret leak prevention.

A PreToolUse hook physically blocks writes that mix Project A's identifiers into Project B's namespace.

Not a soft filter — an actual block.

100% block rate on designed leak attempts.

5/ Chinese-optimized retrieval.

bge-m3 dense + sparse + RRF fusion + bge-reranker.

92% recall@10 on a 12-query Chinese golden set — comparable to mem0 on English LOCOMO.

bge-m3 is one of the few embedding models first-class for both Chinese and English.
6/ 100% local. Zero telemetry.

Your memory data stays on your disk. No accounts. No signups. No quotas.

mp-metrics-summary shows you exactly what flows through your system, all from local JSONL.

Privacy is the contract, not a setting.
7/ Self-managing once installed.

— 6 launchd daemons (memory + LLM + reconcilers)
— 4 hourly idempotent reconcilers (Stripe / Airbnb async-sidecar pattern)
— 30 pytest cases catch regressions

Install once. Forget it exists. Until you query.

8/ Status: alpha (v0.1.0).

Tested on Apple Silicon. Linux systemd templates ship untested — PRs welcome.

4 ADRs (D001-D004) document design rationale. MIT.

For Claude Code / Cursor / Codex users who value local-first + Chinese support.

https://t.co/kFV8NjyOac

[WayLim @WayLimX]

Here’s a real development example.

When I ask AI to review products from different professional perspectives, it often produces highly valuable insights and recommendations.

For example, while developing ShineFin, I would run multiple specialized agents at the same time:

A trader with 30 years of Wall Street trading experience
A professional investment research analyst with 30 years of Wall Street experience
An ordinary office worker who invests personal savings independently

Then I ask them to evaluate the product from different perspectives, including:

Whether the UI elements make sense
Whether the workflow matches real usage habits
Whether the information presentation is clear
Whether the product actually fits real user needs
Which parts still need optimization

After the analysis, they usually provide many valuable suggestions and observations.

Then, through layered follow-up questioning and iterative discussion, I guide the AI to gradually produce product design proposals, interaction improvements, and optimization directions.

This approach becomes extremely helpful for later-stage product development and refinement.

[WayLim @WayLimX]

After months of using AI, I've arrived at a counterintuitive conclusion: asking AI questions is far more effective than giving AI instructions.

My old approach was direct commands. Build this, change that, implement it this way. AI did what I said, but the results were always slightly off. Functional, but not good enough.

Then I started doing something different. Before letting it start building, I'd ask it questions first.

"What are the different ways you could implement this?"
"What are the pros and cons of each approach?"
"If the user base grows, which approach would break?"
"Is there anything I haven't thought of?"

Let it think through the problem from every angle. Only after it's fully considered the picture do I let it start building.

The quality difference is massive.

The reason is simple. When you give instructions, AI is just an executor. You say what to do, it does it. If your thinking is incomplete, the output is incomplete.

When you ask questions, AI becomes a thinker. It draws on everything it knows to analyze, to find angles you missed. Then it builds from a much more complete understanding.

This is the difference between guided communication and command-based communication.

Command-based: you figure out the answer and tell AI to execute it.
Guided: you ask the question and let AI figure out a better answer.

I still can't read code. But I know how to ask questions. That's enough.

[WayLim @WayLimX]

I made a mistake that cost me a lot of time before I figured it out.

When building a large module, I spent ages writing extremely detailed requirements. Every step, every method, every approach, all laid out precisely. Then I sent it to AI to execute.

It kept going off track. Fix one thing, another goes wrong. Back and forth, over and over.

At first I thought the AI wasn't good enough. Then I realized the problem was my approach.

I was thinking for it. Planning for it. Feeding it what I believed were the correct steps, one by one.

But here's the thing: nobody understands AI better than AI itself. It knows what it's good at. It knows the optimal path to execution. My "precise steps" were actually constraining it.

So I changed my approach. I guided it to reflect on what went wrong, let it summarize the issues itself, let it create its own plan, and let it build its own detailed documentation as a reference during execution.

The difference was night and day. Better and faster.

The more you plan for AI in detail, the more likely it goes off track. Let it plan for itself, and it executes far better.

It's the same as managing a team. Have you ever seen a good manager write every line of code for their engineers? You give direction, constraints, and goals. Then let them figure out the rest. AI is the same.

Managing AI is like managing a team, not like writing code.

[WayLim @WayLimX]

Product design, operations, marketing. I've done it all. Over twenty years, every role you can think of. The one thing I never touched was engineering.

Not because I didn't want to. Honestly, there were so many times I watched development move painfully slow and thought, I wish I could just do this myself. But every time I opened a tutorial and saw a screen full of code, I knew that wasn't my world.

One day in January, I had just submitted another request and was sitting there waiting. Again. I got fed up. Remembered everyone talking about AI writing code lately. Decided to see what it was actually about.

Opened Claude Code. Described what I wanted in the most ordinary language possible. No jargon, no technical terms. Just talked to it like I'd talk to a person.

Then it wrote a bunch of code.

I couldn't read any of it. Not a single line. But I ran it, and it worked.

In that moment, I made a judgment call: this is going to change the world.

Not an exaggeration. It was the instinct of someone who's spent twenty-plus years in product, seeing something and knowing it changes everything. Like the first time you held a smartphone.

I couldn't sleep that night. Not from excitement. My brain just wouldn't stop. If this thing can let someone who knows nothing about code build a working product, then who needs to wait for anyone else?

[WayLim @WayLimX]

Yesterday I shared about open-sourcing PixelCheck and got a lot of replies. Several people asked me the same question: how does someone who can't code actually pull this off?

Let me talk about that today.

Honestly, I'm surprised myself. About a month into building products with AI, I realized I was more proficient than many friends I know with three to five years of development experience. Not because I'm smarter. Because I have no fallback.

Here's what I noticed. Many experienced developers are skeptical of AI from the start. They try it a few times, see it make mistakes, and go right back to manual coding. They only use AI occasionally to ask questions or look up solutions. They don't bother learning how to communicate with AI properly, because they can still get work done without it.

I can't code. Learning to communicate with AI was my only option.

So I was forced to figure out something important: working with AI isn't about technical knowledge. It's about how you describe the problem.

Most people tell AI "add a button here." I say "the user needs to accomplish this task in this scenario, the current friction is here, and the experience I want looks like this." That's product logic, not feature logic.

Most people give AI commands: "write a function that does XX." I lay out the context, constraints, and goals, and let AI think through the essence of the problem itself. That's guided communication, not command-based communication.

The quality of AI's output under guided communication is completely different.

Twenty-plus years of product, operations, and marketing experience used to have no outlet. I couldn't code, so I could only write requirement docs and hand them off. Now AI is the one I hand them to. And it's more patient, faster, and never complains when requirements change.

I still can't read the code in my own projects. But I can tell whether the product is right.

Code was never the barrier. Knowing what to build and how to articulate the problem clearly, that's the real skill. Knowing how to code is sometimes the baggage, because people with a fallback never go all-in on the new path.

[WayLim @WayLimX]

AGI might be closer than we think.

I know, today's AI is still fundamentally calculating probabilities. It's not truly "thinking." But sometimes you have to admit, it behaves so much like a person that the distinction starts to blur.

Let me tell you a real story.

A while ago I updated some files and needed to deploy them to a server. Full disclosure: I know absolutely nothing about servers. Zero. So I decided to let AI teach me, step by step.

I took screenshots, pasted them into the chat, asked what to click, what to fill in. The AI was patient, walking me through every step. But some configuration pages were just too complex. I tried and failed, tried and failed again.

Then the AI said something that stopped me cold:

"Stop. Give me control of your browser. I'll do it myself. Just wait."

I authorized it. Five minutes later, everything was configured.

In that moment, I felt something hard to describe. Not fear, not excitement. A quiet kind of awe. Like suddenly realizing that what you're interacting with might not just be a tool.

The origin of life was a single, accidental instant. Maybe true AGI will arrive the same way. Not with a press conference from some lab announcing "we did it," but quietly, in an ordinary conversation between a regular person and an AI, it will simply cross that line.

Maybe it's already closer than we think.

#AI #AGI #BuildInPublic

[WayLim @WayLimX]

https://t.co/vGe9zNgx5K

[WayLim @WayLimX]

Feels like a dream.

3 months ago, I couldn't write a single line of code. Today, I'm open-sourcing PixelCheck -- a browser built for AI. It gives AI the ability to see and understand web pages -- capture screenshots, compare visual changes pixel by pixel, and navigate the browser programmatically. Think of it as giving your AI agent eyes.

Who would've thought? Someone who couldn't read a single line of code 3 months ago, independently built a browser that AI agents can use. Every line of this was built with Claude Code. No CS degree. No bootcamp. No co-founder who codes. Just me, a real problem, and an AI that never gets tired of explaining things.

Several friends have been testing it. The feedback wasn't polite encouragement -- it was "I'm keeping this in my workflow." That's when I knew: this shouldn't just be mine.

So I'm open-sourcing it today. Not because it's finished. Because I believe the real power of open source is pushing everyone forward together. If PixelCheck helps even one developer work better with AI -- it was worth every late night.

From zero code to open-source maintainer in 3 months. The tools have changed. The barrier is gone. If you've been sitting on an idea thinking "I can't build this" -- you can. Just start.

Give it a try. Open an issue. Submit a PR. Make it better together.

Built entirely with @AnthropicAI @claudeai Claude Code.

https://t.co/RjnZ3XHHFo

[WayLim @WayLimX]

PixelCheck v1.2.0 shipped

Your AI agent can now give any website a full health checkup — not just screenshots, but deep diagnostics: popups, cookies, network requests, page speed, visual scoring. One MCP call, full report.

What's new for real workflows:

"The audit crashed halfway through"→ Now auto-saves checkpoints. Resume from where it stopped. No wasted time or API costs.
"The report says contrast ratio failed — what does that mean?"→ pixelcheck explain tells you in plain language: what's wrong, why it matters, how to fix it.

"Anthropic API is down / too expensive"→ Switch to Ollama (free, local AI) with one env var. Or set up auto-fallback: local first, cloud backup.
"I want to hook into the audit lifecycle"→ Plugin system. beforeAudit, afterStep, onIssue, transform — extend without forking.

"Running in CI with no terminal"→ --quiet mode outputs only the final result. --verbose shows everything. Progress bar + ETA in interactive mode.
2,158 tests. 83 public APIs. 0 vulnerabilities. 768 KB.

npm install pixelcheck
GitHub: https://t.co/QmZQLw0qlu
MCP Registry: io.github.xcodethink/pixelcheck

Built with @AnthropicAI @claudeai — the best coding partner an indie dev could ask for.
#MCP #AI #OpenSource #DevTools

[WayLim @WayLimX]

20 years in marketing. Zero engineering background.
Started learning to code from scratch this January — with Claude Code.

4 months later I shipped my first real open-source tool, and it's already live on the official MCP registry.

I built it with Claude Code, for Claude Code.

It's called pixelcheck.
One line in your Claude Code mcp config. 12 new tools your agent gets instantly.

The pain it kills:

When Claude Code writes frontend, it's writing blind.
Agent writes a button → you open Chrome → screenshot → paste back → "yo this is broken"
Agent tweaks the OAuth flow → you log in to verify → broken. Sixth time this month.
The agent has thoughts. You have a browser. They never meet.

pixelcheck closes that gap. Local MCP server. Real Chromium. 12 primitives:

• see (screenshot + DOM)
• click / type / fill
• extract structured data
• judge (LLM scores a page by your rubric)
• compare (diff two URLs)
+ full UX audit presets

What makes it different — the persona layer.

It bundles 18 personas across 17 countries. Real Chromium walks through your app as:
• Tokyo housewife on a MacBook
• Lagos entrepreneur on a budget Tecno
• Saudi businessman with RTL Arabic
• US retiree on iPad
• Shanghai student on Xiaomi 4G

Catches i18n + a11y bugs you'd never see in manual English-only testing.

30-second install:

npm i pixelcheck

Then in your Claude Code mcp config:

{
"mcpServers": {
"pixelcheck": {
"command": "pixelcheck-mcp",
"env": { "ANTHROPIC_API_KEY": "..." }
}
}
}

Restart Claude Code. 12 new tools, immediately callable.
Local-first. No SaaS. MIT.

https://t.co/QmZQLw0qlu

If you've ever screenshotted a Claude Code UI 8 times in one afternoon, this is who I built it for. Stars / harsh feedback / issues all welcome 🙏

Built entirely with Claude Code over the past 4 months. @AnthropicAI @claudeai

[WayLim @WayLimX]

I don't write code. Not a single character.

But today I pushed a product to npm. It's called PixelCheck.

It does one thing: it lets AI agents actually see the web pages they're shipping, instead of me being the eyes for them.

Why I built it: honestly, I was forced into it.

Claude writes my frontend fast. But it's blind. It writes a login flow and I have to open a browser to check the flow didn't silently break. It writes Japanese translations and I have to open the Japanese version to see what got missed. It writes an Arabic RTL layout and I have to manually verify it actually mirrored.

Every button. Every flow. Every locale. Every device. I'd screenshot, paste back, tell it what was wrong.

Hours every week. With no end in sight.

I got tired.

So I had an idea: what if the agent could just see for itself?

I described that idea to Claude Code, and every pain point I'd been hitting, in plain English. It needed to be able to open pages. To click buttons and fill forms with natural language. To pull structured data out of any page. To score a UI like a real person would. To compare two versions. To walk through my app as different real users — Tokyo housewife on a MacBook, Lagos entrepreneur on a Tecno, 72-year-old US retiree on iPad, RTL Arabic businessman, Shanghai student on a budget Xiaomi. Those personas are mine, not generated.

Every piece of logic was my product call. Every character of code was Claude Code.

I never typed a line.

But it's on npm now. It actually works. It runs on your own machine. No SaaS in the loop.

Repo: https://t.co/RjnZ3XHHFo

If you're also bouncing between an AI writing your frontend and being the manual eyes for it, try it.

If you don't write code but have product instincts, this repo is one piece of proof: Claude Code can actually turn your logic into shipping software.

[WayLim @WayLimX]

The agent writes the code; you screenshot the result; you tell it what's wrong. Repeat for every locale, every device, every OAuth flow.

I built PixelCheck — an MCP server that gives Claude Code real eyes on the web so it can verify its own output instead of you doing it.

5 primitives: see / act / extract / judge / compare. Drop one line in ~/.mcp.json. 18 personas baked in (Tokyo housewife, Lagos entrepreneur, RTL Arabic businessman) so the agent can audit your app as different real users.

https://t.co/RjnZ3XHHFo

[WayLim @WayLimX]

Bonus — bundles a Claude-Code-callable audit preset.

Real Chromium walks through your app as:
• Tokyo housewife on a MacBook Pro
• Lagos entrepreneur on a budget Tecno
• 72-year-old US retiree on iPad
• Saudi businessman with RTL Arabic
• Shanghai student on Xiaomi 4G

Scores 6 dimensions per persona. Reports in 5 languages.

[WayLim @WayLimX]

Not Playwright. Not Stagehand. Not Browserbase.

PixelCheck sits one layer up:
• Playwright/Cypress — deterministic browser drivers (you click)
• Stagehand — natural-language act/extract for forms
• PixelCheck — MCP-shaped vision (see/judge/compare) on top of action, with 18 personas baked in

Claude Code calls it. You read the report.