Jacek Migdał

You can think of agentic engineering as just another compiler layer, which sits on top of your C++ compiler, which sits on top of LLVM, etc... But the analogy breaks down, because prompts are ephemeral, and don't stick as the literate description (in Don Knuth's sense of "literate programming") of the code. The main reason is that your "compiler," the LLM, is neither hermetic nor deterministic. I do wonder if we're in a wrong local optimum of vibe coding as a result: imagine a world in which you check in your prompts as the source of truth, and the resulting code is what's ephemeral, or a blend of both like in CWEB. This would bring some rigor and sharing capabilities to the exercise of prompting agents, and elevate the entire codebase by one abstraction layer. Another big challenge is that the results of a prompt are non-local, and as a consequence, using them as a linear description of the code is not particularly useful: it's more like a version tree. It is be super interesting to think about what a prompting-aware 'git' would look like, and the role of comments vs. prompts in this environment.

120

14 Yorum

Front-loading LLMs with clear specifications can be challenging even for relatively narrow-scoped tasks, like a full-featured production-ready bash script. Encouraging an LLM to ask questions if any aspect of the specifications is incomplete or confusing, often as not, gets ignored. Adding asterisk-delimited text sorta-kinda-sometimes nudges it to ask. Adding ampersand characters as delimiters works even better. One small problem: Now it won't *STOP* asking questions. "I noticed you use the number 1. Is that number 1 really a number 1? Please confirm before I proceed." (makes prompt change: "but encouraging you to ask questions does not mean ask questions that the specification obviously already answers in three different places") It's the tedious part of so-called prompt engineering. LLM behavior flips from "ignoring you" to "over-reacting" very easily. You can almost feel it jumping a low-probability transition from one sticky cluster in the weights to another cluster. Arguably I think it's the biggest gap we have in making this be actual engineering instead of what it tends to be in practice: permute your instructions until you luck out. What we actually need is an observability mechanism that identifies the sticky clusters and measures how specific instructions move you between them. I've got some articles coming out soon that uses Markov chains to show how some of the math around this works. LLM inference isn't absolutely the same thing but the underyling mechanics are pretty close.

2

What kind of guidance does an LLM need to write a direct-style #Scala 3 application? At the baseline - not a lot, e.g. Claude is quite good both in Scala 3 & direct-style. For finer details - some additions to the prompt might be useful. Read more: https://lnkd.in/dxwy-WdD

20

5 Yorum

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 Yorum

Great post by Confluent's Jack Vanlightly on how open table formats like #Iceberg require techniques different from traditional secondary indexes to reduce IO operations enough to get performance at scale.

3

Vijay Bendigeri, Ph.D., excellent post. The truth is, this new multi-trillion-dollar Industry requires INTELLIGENT INFRASTRUCTURE to address supply chain logistics, optimization, orchestration, reduced emissions, Vision Zero, and enabling Autonomy 2.0. Exceptional work has advanced the vehicle with sensors, software, computing, AI algorithms, and safety features. It is far more than the vehicle. Exciting times for our nation, Building Our Next Golden Age. The national buildout of Intelligent Infrastructure Economic Zones will revitalize infrastructure in the United States. Supporting NextG for DoD and Civil, FAA NextGen, Intelligent Transportation, Golden Dome, resilient grids, precise positioning, and autonomous systems. ODC AI-RAN is the convergence of AI and the physical world. Autonomy Institute https://lnkd.in/giehikzr

7

A Claude Code tutorial just hit 4.8M views on X. The author? Eyad Khrais - ex-Amazon and Disney dev, now a CTO building enterprise agents. I read his playbook. Here's what actually matters: 𝟭. 𝗧𝗛𝗜𝗡𝗞 𝗕𝗘𝗙𝗢𝗥𝗘 𝗬𝗢𝗨 𝗧𝗬𝗣𝗘 Press Shift+Tab twice to enter plan mode. This 5-minute step saves hours. Don't say "Build an auth system." It gives too much creative freedom. Instead: "Build email/pass auth using the User model, Redis sessions (24h expiry), and middleware for /api/protected." Architecture first. Automation second. 𝟮. 𝗖𝗟𝗔𝗨𝗗𝗘.𝗠𝗗 𝗜𝗦 𝗬𝗢𝗨𝗥 𝗟𝗘𝗩𝗘𝗥𝗔𝗚𝗘 𝗣𝗢𝗜𝗡𝗧 Claude reads this file every time. But attention is scarce:  1. It can follow ~150 instructions max  2. System prompts use ~50  3. Every new line competes for attention Keep it surgical. Explain WHY, not just WHAT.  • Bad: "Use TypeScript strict mode"  • Good: "Use strict mode because we have bugs from implicit any types" Context enables better judgment calls. 𝟯. 𝗖𝗢𝗡𝗧𝗘𝗫𝗧 𝗗𝗘𝗚𝗥𝗔𝗗𝗘𝗦 𝗔𝗧 𝟯𝟬% Opus 4.5 has a 200K window, but quality drops at 20-40% usage. If Claude compacts and outputs garbage, the model was already degraded. The fix? The copy-paste reset:  • Copy key info from terminal  • Run /compact • /clear context • Paste back only what matters Fresh context preserves intelligence. 𝟰. 𝗪𝗛𝗘𝗡 𝗖𝗟𝗔𝗨𝗗𝗘 𝗚𝗘𝗧𝗦 𝗦𝗧𝗨𝗖𝗞 If you've explained it 3x, stop. More explaining won't help. Change the approach:  • Show examples instead of telling  • Break complex requests into pieces  • Reframe: "Implement state machine" vs "Handle transitions" Recognize loops early. Don't fight degraded context. 𝟱. 𝗨𝗦𝗘 𝗧𝗛𝗘 𝗥𝗜𝗚𝗛𝗧 𝗠𝗢𝗗𝗘𝗟  • Opus: Planning, reasoning, architecture  • Sonnet: Execution, refactoring The winning workflow: Opus plans, Sonnet executes. Your CLAUDE.md ensures they share constraints. 𝟲. 𝗕𝗨𝗜𝗟𝗗 𝗦𝗬𝗦𝗧𝗘𝗠𝗦, 𝗡𝗢𝗧 𝗢𝗡𝗘-𝗦𝗛𝗢𝗧𝗦 Use the -p flag for headless automation. This enables scripting for PR reviews and ticket responses. The flywheel: Claude makes a mistake → Review logs → Update CLAUDE.md → Claude improves. This compounds. Read Eyad's full article here: https://lnkd.in/er8_YTyg

520

21 Yorum

I ran `apk add python3` inside my browser tab yesterday. Not a simulation. A full Alpine Linux distribution with a real package manager, executing real x86 binaries through JavaScript emulation. This is Apptron, and it broke several assumptions I didn't know I had. The economics are backwards: Traditional cloud IDEs (Gitpod, Codespaces, Replit) run compute on their servers. You pay for it. Apptron inverts this—all the heavy lifting happens in YOUR browser. The backend just handles file sync and networking. Part of the infrastructure runs on Cloudflare's free tier. The cost of providing a full Linux environment to users is essentially zero because users bring their own computers. It's not emulating Linux. It's running Linux: At the core is v86, a JavaScript x86 CPU emulator with JIT compilation. On top sits Wanix, a WebAssembly kernel framework bridging the emulated environment with browser APIs. Real, unmodified 32-bit x86 binaries execute in your browser. Why this matters: → Interactive documentation with actual Linux environments → Programming education without "works on my machine" → Legacy software preservation via URL → AI agent sandboxing (the use case I keep coming back to) Browser as OS substrate. User as infrastructure. I don't know if this project will take off. But the pattern it demonstrates is something I hadn't considered. Now I'm wondering what else we've been overcomplicating. 🔗 Try it: https://apptron.dev 🔗 Source: https://lnkd.in/g2JXtD7q Full writeup on my Substack (link in comments). #WebDevelopment #Linux #CloudComputing #DeveloperTools #OpenSource #WebAssembly #AI #SoftwareEngineering

8

3 Yorum

Hot take: most "AI agent" systems today are not usable in any trust-sensitive environment. They're non-deterministic, non-reproducible, and non-verifiable. You can't audit them, you can't prove what they did, and you can't safely let them touch anything that matters. And yet we're trying to use them for financial flows, on-chain interactions, and autonomous coordination. If agents are going to operate in adversarial or trust-minimised systems, **"it probably did the right thing" isn't good enough**. So I built something different. luai flips the typical agent loop. Instead of the LLM calling tools in a back-and-forth ReAct loop, the LLM generates a complete Lua program in a single call. That program then runs in a sandboxed, deterministic VM — making tool calls, processing results, and returning structured output — all at zero additional LLM cost. Every tool call and result is captured in a transcript that can be replayed, verified, and optionally zk-proved. Why Lua? Lightweight, embeddable, and sandboxed by nature — no filesystem, no network, no OS access. Tools are the only external interface. The goal is simple: treat agent execution as **computation you can verify**, not behaviour you hope is correct. My guess is that most current agent frameworks won't survive contact with real-world constraints — and we'll end up rebuilding them on top of verifiable execution models anyway. Early days, but the code is here: https://lnkd.in/ejJ9cVuN

10

3 Yorum