David Max

Spent some time to make the #Hardwood parser for Apache Parquet files a little faster; The engine parallelizes better now, a full parse of 720 MB of the NYC taxi ride data set--summing up the values from three columns--takes about 2.3 sec on my laptop (MBP Pro M3 Max). Still lots of potential for further speed-ups; perhaps it's time to apply some of the more advanced tricks from #1BRC; fun fact: I'm already making good use of a custom open addressing map for mapping field names to indexes 🤓. The public API is more concise now too, as per your feedback. Thanks! 👉 https://lnkd.in/e5fjx3XW

56

2 Comments

Just submitted MAM: Maker Auction Markets to https://lnkd.in/gdfEhNhH (Designing Defi) MAM eliminates entire classes of MEV by shifting from reactive pricing to time bound collateralized commitments and user constraints/intents. Im curious do you think the way things are currently are the way things always have to be? We are what? 12-15 years into this industry? Innovation has only just begun.

1

I've always found myself switching to Claude models when working through coding problems. There's just something about how Claude handles context and works its way through large code bases and complex logic. With Claude Code, that workflow has become ridiculously smooth.                                                    Also been experimenting with OpenAI's Codex (GPT-5 powered) and the results are way better than previous versions. The code generation quality has taken a real jump. Now here's where it gets interesting. You keep hearing stories about developers opening multiple coding agents, feeding them the same task, and manually cross-referencing outputs to find the best solution. Turns out there's an easier way. By integrating Codex as a skill inside Claude Code, you get insights from both agents in a single terminal session when you need. No tab switching, no copy-pasting, no manual comparison. Claude Code orchestrates the workflow while Codex brings its strengths. Best of both worlds in one window. Claude OpenAI

35

There’s a bug in production, and R&D needs data from the prod DB to figure it out. You’ve got a large >1TB database on RDS, what do you do? 😵‍💫 Grant read only access to production? 🚩 CISO says no bueno. Even if you could, devs say read-only access isn’t enough. They want to run the app live and it creates transactions. Use RDS restore from snapshot? ❌ It takes 30 minutes to spin up, and you still need to anonymize/subset/mask. How long does this take for a >1TB DB? We’ve heard it can take anywhere from 8 to 24 hours (!), even with optimizations like index drop and rebuild. .. and it only gets worse with AI in the IDE and agentic development. Agentic coders also need access to fresh prod data, but they need infrastructure that tolerates messing up and quickly resetting to try again. ⚡ At Baseshift we’re solving this problem efficiently and at scale: - Get a fresh, anonymized, subsetted snapshot of production in less than a minute - Launch cheap, writable and resettable clones on a server in seconds or as a Docker container - Exposed as an MCP server for quick integration with AI If you’re interested in a demo feel free to reach-out, we’re happy to chat. Follow for updates 👀

46

1 Comment

Paragon is the world’s best QA engineer. This performance reflects Polarity Labs’ research in context engineering and multi‑agent QA: deep codebase understanding, parallel reasoning with intelligent sharding, and rigorous reasoning and verification. On the ReviewBenchLite benchmark; testing real production issues, Paragon-Deep leads at 81.2%, with Paragon-Fast at 72.6%. That’s +8.6 pts over the next best agent and +24.8 pts above the median across leading code‑review systems.

26

1 Comment

Any Subgraph provider claims 99.9% up time is most likely misleading you (although not intentionally). {⏰ 19 days until Alchemy Subgraph shut down ⏰ } I have seen graph nodes take up to two hour to reconcile a re-org. Since this is technically "outside" the provider's control, nor can they actually intervene, they don't count it as downtime. Subgraphs still technically "Operational" although there is a massive delay due to chain re-org. 🪫 They maintain their 99.9% claim, but your data is stale, user transactions fail, and your community on Discord is mad. 🤯 You must clarify this with your new Subgraph provider when moving away from Alchemy Subgraphs Most Blockchain Backend Engineers assume uptime is binary: it is either up or down. The truth is, blockchain availability is never one-size-fits-all, yet Subgraph providers rarely tailor their re-org configurations per chain. Re-org impact is the grey area providers don't mention. That is why your dApp must have a system to respond to these nuances: 1️⃣ Define Freshness Targets Per Chain I see teams treat every chain the same, but block times vary wildly. You must define specific latency targets for each network.  e.g. If Arbitrum-one falls behind 20 blocks for 5 minutes, you need to know immediately. 2️⃣ Set Granular Alert Thresholds Per chain Don't rely on generic uptime pings. Your alert thresholds should be set per chain. If Monad stalls, it probably shouldn't trigger the same alert urgency as a delay on Mainnet unless the threshold is crossed. Trigger the on-call person only when it matters. 3️⃣ Implement Alerts for Re-orgs I’ve seen projects fly blind during re-orgs because they assumed the Subgraph would just "catch up" silently. You need an explicit alert for when a re-org is detected. Deep re-orgs can wreck data consistency if you aren't watching. sometimes it is not automatically recoverable you have to inform your subgraph provider. e.g. XLayer in June 2025, from 3M block re-org introduced block 7M to re-org causing all subgraph providers to fail Lastly your new provider will definitely have different re-org threshold settings than Alchemy. This means your recovery time could be longer than you expect, leaving users staring at stale data. -- If you are a Blockchain Backend Engineer looking to migrate your Alchemy Subgraph to a new provider with zero disruption to your dApp and want more educational resource. Get my 📑 5-Step Alchemy Subgraph Migration Checklist 📑. Follow the link in the comments below to grab your complimentary copy 👇👇

4

1 Comment

In software architecture, "the lines are more interesting than the boxes"… Excited to share my latest LeadDev article on how steel threads help engineering teams cut through uncertainty and expose risks early — and how, as a staff+ engineer, you can use it not just as a technical practice, but as a powerful leadership tool. 🔗 Read it here: https://lnkd.in/gfYin7ch

38

1 Comment

The people arguing that Claude replaces n8n are thinking in either-or terms. The more valuable question is how they work together. Claude is very good at designing and generating the logic inside a workflow. You can ask it to map out a multi-step automation, write custom transformation code, clean messy JSON, handle edge cases, or draft branching conditions. It meaningfully reduces the cognitive load of building the steps. n8n gives that logic a durable operating environment. It handles triggers, credentials, execution history, retries, scheduling, webhooks, and team visibility. It makes the automation observable and modifiable without redeploying a codebase. In practice, that looks simple. You use Claude to design the workflow structure and generate any custom code nodes. You bring that into n8n, which handles execution, logging, error handling, and credential management. When something breaks, you inspect it in n8n. When the logic needs to change, you bring Claude back in to rethink or refactor the step. Claude becomes the architect of the workflow. n8n becomes the runtime that carries it. That division of responsibility is cleaner than forcing one tool to do both jobs. Teams who understand architectural layers tend to converge on this model. Teams who do not often swing between extremes, either rebuilding infrastructure themselves or overtrusting generation without thinking about runtime realities. The leverage shows up when generation and operation are treated as distinct capabilities that reinforce each other. So the real divide is not between Claude and orchestration tools. It is between teams that recognize layers and teams that collapse them because a new interface feels powerful. No, n8n is far from dead.

4

2 Comments