I built 3 MCP servers for the same API. Same 5 test scenarios. Three different architectures.
The results:
→ Traditional (10 tools): 6,624 tokens, 3.6s
→ Code Mode (1 tool): 2,270 tokens, 2.7s
→ Layered + Query (3 tools): 2,311 tokens, 2.0s
Both alternatives cut token usage by ~65%.
The deeper insight: your MCP server is middleware, not a passthrough.
People get high on abstraction too early. They want the system before they’ve earned the insight.
But the good abstractions are never designed. They’re discovered. You do the stupid manual thing enough times and the real bottleneck just emerges. Your initial agency might be driven by a hunch you had in the shower, but that moment won’t get you all the way to making something people want. The right way to make anything is forced on you by reality: what are the real jobs to be done? And what sequence?
This is why “do things that don’t scale” still hits, especially now when AI makes it trivially easy to scale things that probably shouldn’t be scaled yet. PG’s point was never about suffering. It was about contact. When you’re the one manually doing the loop, you see the edge cases. The weird user behavior. The failure modes nobody designed for. The hidden dependencies that only show up at 2am when some flow or intermediate step breaks in a way you didn’t anticipate. If you automate before you have that contact, you just scale your misunderstanding faster.
When the machines can help you vibe code perfection it gives you a false sense of power. I love that feeling as much as you do. But fuck perfection. Do it live. Be the loop.
Feel every friction point. Notice what’s actually true every single time versus what just looked true because you hadn’t seen enough cases yet. Formalize that. Build the recursive version. Then keep checking that your abstraction is still attached to real humans and their needs. Because reality drifts. Your users drift. The ground truth changes under you. You may think you understand but no plan survives contact with the real users and what they want. You find those body blows in analytics and user feedback and we call them the roadmap.
Humans left with not enough data hallucinate too. But just like the LLMs with enough data you unlock real transcendence. Real utility. Prosperity for humans in real life.
The abstraction is a tool, not a destination. The moment you forget that, you’re cooked.
Model alignment handles jailbreaks.
It doesn't handle:
→ Unauthorized tool calls
→ Poisoned RAG retrievals
→ Missing compliance disclaimers
→ Tenant policy leakage
These are the 4 production LLM risks nobody's guarding against.
Here's how to fix it with @NVIDIA NeMo Guardrails 👇
New research tested what Claude Code picks when you don't specify tools.
shadcn/ui → 90%
Stripe → 91%
GitHub Actions → 94%
Drizzle → 100% (Prisma: 0%)
AWS for deployment → 0%
The most powerful distribution channel in dev tooling is now invisible.
Details here 👇👇👇👇
@aakashgupta "But taste is only half of it. You also need the channel. The unsexy reality is that a mediocre app with 100,000 newsletter subscribers will outperform a beautiful app with zero distribution every single time" -- I cannot agree more! Distribution is the key.
I wrote a deep-dive analyzing:
→ The "test suite as spec" pattern → The documentation paradox threatening open source → A 4-condition checklist for when cloning makes sense → Why integration cost collapse is the real story
Full article:
https://t.co/e6i3dxg3cZ
Cloudflare rebuilt Next.js in one week.
$1,100 in AI tokens. Already running on a .gov domain.
This isn't a Cloudflare story. It's the moment build-vs-buy became a 3-option decision.
Here's what changed 🧵
AI-cloning only works when ALL four are true:
You need <50% of features
Upstream is well-tested and stable
You have senior engineers who understand both architectures
You're not in a safety-critical domain
Three out of four isn't enough.
The real insight isn't about cloning.
It's that integration cost is collapsing.
The question is no longer "which tool do we adopt?"
It's "which subset of which tool do we need?"
That's a fundamentally different engineering conversation.