Selected posts from X and LinkedIn. Each one opens here with its context, and links to the original.
this reframes the junior problem. the reps were never the point, they were where judgment got installed for free. now reps are cheap and judgment is the scarce part, so you have to seek the friction on purpose. reviewing what an agent produced is the new place you earn it.
β³ Addy Osmani replied
A server rejected me in 125 milliseconds. π₯Ά π₯Ά I was harvesting public data from a handful of sources for a tool I built on Cloudflare Workers. One source, Reddit, kept blocking the reads. I already had a proper descriptive User-Agent set, so I did what everyone does first: I assumed the bug was mine. Then I looked at the timings instead of the code: β Reddit: 403, in 125 ms β Google News: 503, in 9.6 s β ArXiv: aborted at exactly my 10 s timeout β Hacker News: 200, in 2 s The 125 ms is the whole story π€― ! A rejection that fast is not a rate limit and it is not your headers. Nothing was measured and nothing was throttled. It is a reputation decision made before the request was even read. Reddit blocks anonymous reads from datacenter IP ranges, and Cloudflare Workers, Cloud Run and GKE all egress from exactly those ranges. Which means the move I was tempted to make, was never going to work. You cannot out-engineer an IP reputation block with a disguise. The only durable fix is to stop being anonymous: authenticate as a registered app, and you are allowed in from datacenter IPs under a published quota. The reframe I kept: β A fast reject is a policy decision. Look at auth, identity, IP reputation. β A slow reject is a load decision. Look at rate limits, backpressure, timeouts. Before you fix the code, read the timing. How long something takes to fail tells you what failed. A 125 ms no and a 9 second no are two different bugs wearing the same error message. What is a failure whose speed gave away the real cause, once you stopped blaming your own code? π€
decentralization claims for these platforms usually hinge on resolution, not matching. matching engines are easy to decentralize, but oracle resolution, who actually decides who won a bet, is where most platforms still lean on a small trusted set. curious how Trueo handles that part
Anyone can vibe-code a demo now. Shipping a product that survives real users is a completely different sport. β‘ "I built this with AI" and "I can maintain this with AI" are two very different sentences. Most people can't tell them apart yet. They're about to. β¨ Vibe coding: prompt, accept, prompt, accept, ship the moment it looks like it works. Feels like magic. Dies the second a real user touches it. π οΈ Engineering with AI looks slower and is actually faster: β Spec before code. I write what I want before Claude writes a line. β One concern per change, even when it could do ten at once. β Not done until I've watched it run. Green tests aren't proof. β Every decision logged, so the same mistake doesn't get a second shot. Same model. Same prompt window. Opposite outcome. The difference was never the AI. It's whether there's an engineer on the other end who knows what "correct" actually looks like. I run 8β16 Claude Code instances in parallel worktrees, merge queues, the whole rig. None of it ships clean without a spec and a human who can read the diff. "I built this with AI" is cheap now. "I can maintain this with AI" is the moat. π Curious who's already feeling the gap between the two. πββοΈ
we're shipping quantum-recoverable notes before quantum computers can reliably read an email. building the seatbelt before the car exists. the single most Zcash thing imaginable and honestly i respect the paranoia.
spent an hour on "the login is broken". π the login was fine. the accounts in the runbook had never existed in that database. credentials were written down in two places and only one got updated. a doc that restates a value will drift. a doc that points at it cannot.
Wow, this was a great morning read
nader dabit @dabit3How to Run a Fleet of Cloud Agents (The Complete Guide)the agent asked me to approve a transaction. i said yes without reading it. so which one of us is the security risk here
Your wallet doesn't care how your swap was protected. It only cares how much came back. That's the problem with MEV protection today. Private relays hide your transaction from sandwich bots, Great!!!. But the cost isn't fixed, it depends on how much your trade distorts the pool's price. The same trade can cost pennies in a deep pool or dollars in a shallow one. And nobody tells you whether using a relay is even the cheapest option for your specific trade. Nobody is asking the actual question: what is the mathematically cheapest way to execute THIS specific trade? That's why I built π‘οΈMEV Shield. MEV Shield is an autonomous execution firewall for DeFi. Before your swap hits the chain, it: β Simulates the exact sandwich attack a bot would run against your trade using live pool state β Calculates your real MEV exposure down to the dollar β Evaluates three competing strategies unprotected public swap, private relay via Flashbots, and Optimized order splitting β Picks the one that puts the most money back in your wallet The Optimizer uses a cost function that balances MEV reduction against gas overhead, finds the analytical minimum using calculus, then refines it numerically to handle real-world edge cases like threshold effects and chain-specific gas pricing. For small trades? It tells you to do nothing the MEV isn't worth a bot's gas to attack. For mid-size trades? Private relay wins. For whale trades? The math says split and it tells you exactly how many chunks, and why. Three trades, three different optimal strategies. The system adapts to each one. I also integrated ENS as a Decentralized Policy Layer. Your MEV protection preferences risk tolerance, relay thresholds, chunk limits, slippage bounds are stored as text records on your ENS name. Set them once, and they follow your identity across any wallet or protocol that reads the namespace. No database. No accounts. Your config lives on-chain with you. Built this for ETHGlobal HackMoney 2026, but I'm not stopping here. The vision is a fully autonomous execution layer that optimizes across: β’ Multiple DEXs - routing through whichever pool has the deepest liquidity and lowest MEV surface β’ Multiple chains - splitting chunks across Ethereum, Arbitrum, Base, Optimism based on real-time gas and bridge costs β’ Multiple bridges - comparing bridging fees, latency, and security tradeoffs for cross-chain splits β’ Multiple private relays - not just Flashbots, but MEV Blocker, MEV Share, and chain-specific builders, each with different fee structures and inclusion guarantees Every parameter feeds into the same cost function. The math scales. The more inputs it has, the better it optimizes. DeFi shouldn't require a PhD to not get robbed. But building the thing that prevents it? That took some calculus. Github - https://lnkd.in/diWkxWrx #DeFi #MEV #Ethereum #Web3 #ENS #ETHGlobal #HackMoney2026
spent years making sure a node wouldn't fall over at 3am. now i make sure an agent won't wire the treasury to a contract it met five seconds ago. same job. the pager just got scarier.
people think Zcash is about hiding. it's about choosing. transparency should be a decision you make, not a default the entire world extracts from you by force. privacy isn't the opposite of accountability, it's the precondition for consent.
asked claude code if i should cram kubernetes into one cloud run service to save money. it audited the project instead. the whole bill was six services pinned to min-instances 1, idling 24/7. zero traffic, full rent.
audited a build against its own spec. the demo ran clean. but half the required tables did not exist, assignment overwrote in place with no history, and the "config driven" enums were hard coded strings nothing read at runtime. a working demo hides how much of the spec is still scaffolding.
a healthy protocol isn't five orgs nodding along. it's five orgs disagreeing loudly and still shipping Ironwood on schedule. decentralized governance looks like a mess from outside, and the mess is the feature. no single throne to capture.
the interesting part of agent payments was never letting them spend. it's the off switch. every serious onchain agent is really just a very fast intern with a kill switch you'd better test before you need it.
the seed phrase was never a feature, it was a tax. account abstraction lets your wallet say "cap gas at $5, block anything over $1k, log me in with a passkey." turns out self-custody didn't have to feel like defusing a bomb.
everyone's shipping agents. almost nobody's shipping the evals that tell you it still works tomorrow. the demo is easy. the regression test is the moat.
I started @torbitxyz because I was the worst version of the problem. Brilliant thoughts in the shower. Blank drafts by noon. Zero posts by night. Turns out consistency isn't a discipline issue. It's a systems issue. So I built the system.