# wpnews.pro — Full Content Corpus (en) > 100 most-recent articles in markdown. Updated every 30 min. > Source: https://wpnews.pro/llms-full.txt --- ## Beyond HTTP: Exposing WebRTC and Local Game Servers via UDP Tunnels > Published: 2026-05-24 06:53:44+00:00 > Source: https://dev.to/instatunnel/beyond-http-exposing-webrtc-and-local-game-servers-via-udp-tunnels-5ak5 > wpnews: https://wpnews.pro/news/beyond-http-exposing-webrtc-and-local-game-servers-via-udp-tunnels IT InstaTunnel Team Published by our engineering team Beyond HTTP: Exposing WebRTC and Local Game Servers via UDP Tunnels For the better part of the last decade, developers have relied on localhost tunneling services to expose local applications to the wider internet. Tools that generate a quick, temporary URL pointing straight to your machine’s port 3000 became indispensable for web developers building webhooks, OAuth flows, and REST APIs. But the development ecosystem of 2026 has outgrown that model. We are no longer just building stateless HTTP web applications. We are building real-time multiplayer game netcode, low-latency video streaming applications using WebRTC, and specialized IoT networks running protocols like CoAP and DTLS. The problem is that most legacy tunneling tools are strictly hardcoded for HTTP and TCP. When you try to route a connectionless protocol like UDP through a TCP-centric tunnel, you encounter massive overhead, latency spikes, and fundamentally broken application behaviour. This article explains why, walks through the tools that actually solve it, and covers what you need to know to do it safely. The UDP Problem: Why Traditional Tunnels Fail To understand why tunneling UDP is difficult, you have to look at the architectural difference between TCP and UDP. TCP (Transmission Control Protocol) is connection-oriented. It guarantees delivery, manages packet ordering, and handles error checking. It is perfect for web traffic, where receiving every byte of an HTML document in the correct order is non-negotiable. Traditional tunneling tools thrive on TCP because they act as reverse proxies, managing the state of the connection between the public endpoint and your local machine. UDP (User Datagram Protocol) is connectionless — a fire-and-forget protocol. It does not care if a packet arrives out of order, or at all. This absence of overhead is what makes UDP the backbone of real-time applications where low latency beats perfect reliability. When you push a game server’s UDP traffic through a TCP tunnel, the tunneling software encapsulates lightweight, stateless UDP packets inside a heavy, stateful TCP connection. This produces head-of-line blocking: if a single packet is lost on the public network, TCP stalls the entire stream while waiting for retransmission. For a web page, that is a minor delay. For a fast-paced multiplayer game or a live WebRTC video call, it means rubber-banding, latency spikes, and dropped clients. This architectural mismatch is exactly why ngrok — arguably the most widely installed tunneling tool in the world — still does not support UDP in 2026. Its free tier also carries a hard 1 GB/month bandwidth cap, and its recent pivot toward enterprise “Universal Gateway” features has made the free experience noticeably more restrictive. The Bigger Picture: UDP Is Winning at the Protocol Level This is not just a developer-tooling story. The broader internet is moving toward UDP at a fundamental level. HTTP/3, the latest version of HTTP, runs over QUIC (RFC 9000) — a transport protocol built on UDP, not TCP. QUIC solves TCP’s head-of-line blocking problem at the transport layer: each stream handles packet loss independently, so a lost packet for one resource does not freeze the others. As of October 2025, HTTP/3 adoption had reached 35% of global traffic according to Cloudflare data, and over 95% of major web browsers support it. Real-world benchmarks show HTTP/3 response times roughly 47% faster than HTTP/1.1 on high-latency or lossy connections. For streaming media, Media over QUIC (MOQ) is emerging as an alternative to WebRTC for broadcast-grade use cases, with sub-second latency over QUIC-based WebTransport. The first production MOQ deployment launched in 2025. The takeaway for developers: UDP is no longer a niche concern for game programmers. It is the foundation of the modern, real-time web. Your tooling needs to reflect that. The Modern UDP Tunneling Landscape (2026) The tunneling market has bifurcated. A handful of tools handle HTTP well and UDP not at all (ngrok, Localtunnel). A newer generation treats UDP as a first-class citizen. Here is where things stand. LocalXpose LocalXpose has become the go-to recommendation in communities like r/selfhosted and gaming forums for raw protocol support. It treats HTTP, HTTPS, TCP, TLS, and UDP as equally valid tunnel types. Its dedicated UDP tunnels map a public port directly to your local instance without encapsulation overhead, and it provides both a CLI and a GUI — making it accessible to non-developers who want to run a game server for friends without learning terminal flags. Pricing is approximately $6/month for 10 concurrent tunnels with unlimited bandwidth, along with a built-in file server for sharing game mods or server logs. Pinggy Pinggy has gained traction in the terminal-first crowd with one compelling trick: it requires nothing to install. You run a standard SSH command and get a live tunnel — no npm package, no binary. It supports HTTP, HTTPS, TCP, UDP, and TLS tunnels, and adds a terminal UI with QR codes and a built-in request inspector. The Pro plan is $3/month, less than half the cost of ngrok’s Personal plan ($8/month), and unlike ngrok, UDP is fully supported. For quick “let me show you this” moments, it is hard to beat. Localtonet Localtonet has become a strong all-rounder, described as offering features that would otherwise require three separate tools: a webhook inspector, a file server, and a mobile proxy — all in one. It supports HTTP, TCP, and UDP with end-to-end encryption across 16+ global server locations. At approximately $2/tunnel/month with unlimited bandwidth and no session timeouts, it significantly undercuts ngrok on price. Playit.gg Playit.gg is purpose-built for gamers. It provides both TCP and UDP tunnels for hosting Minecraft, Terraria, and other multiplayer game servers, is open source, and offers a generous free tier with up to 4 TCP and 4 UDP tunnels. The paid plan (Playit Plus) costs $3/month or $30/year and adds custom domains, dedicated IPs, and additional tunnels. If your only use case is hosting a game server, this is the most frictionless starting point. Self-Hosted: FRP and WireGuard For teams with data sovereignty requirements, self-hosted options like FRP (Fast Reverse Proxy) give you full control over your infrastructure, no vendor lock-in, and support for complex protocol configurations. WireGuard, often paired with Tailscale for zero-configuration NAT traversal, provides proven speed advantages with minimal latency — particularly well-suited for streaming, video, and high-frequency update workloads. Wrapping WireGuard in QUIC (as Mullvad and others now support) makes the traffic indistinguishable from ordinary HTTP/3 web traffic, which is rarely filtered even on restrictive networks. Use Case 1: Local Game Servers Game servers rely heavily on UDP for player position updates, fast-sync actions, and state replication. If your ISP uses Carrier-Grade NAT (CGNAT) — meaning you do not actually have a public IP address to port forward from your router — you traditionally had to rent a cloud VPS just to test your netcode. With LocalXpose, exposing a local game server is a single command. If your server is listening on port 19132: loclx tunnel udp --to 127.0.0.1:19132 --region us The CLI outputs a public endpoint such as us-1.loclx.io:4506. Your friends or playtesters enter that address into their game client. Traffic flows cleanly through the public UDP endpoint to your machine, preserving the low latency required for real-time play. With Pinggy, the equivalent command using SSH is: ssh -p 443 -R0:localhost:19132 udp@a.pinggy.io No binary to install, no account required to try it. Use Case 2: WebRTC Testing and Video Apps WebRTC is the standard for browser-based, peer-to-peer real-time communication. While its initial signalling phase (exchanging connection details via SDP) happens over HTTP or WebSockets, the actual media streams are transmitted over UDP using SRTP (Secure Real-time Transport Protocol). Testing WebRTC locally is notoriously frustrating. WebRTC uses the ICE (Interactive Connectivity Establishment) framework to find the shortest path between peers. Corporate firewalls and NAT regularly block the incoming UDP media streams — resulting in a successful signalling handshake where neither side can hear or see the other. TURN and STUN servers help with NAT traversal, but they do not solve the problem of your local SFU or media server not being reachable at all. The practical fix is to tunnel both layers simultaneously. Using a service like Localtonet, which supports mixed TCP/UDP workloads, you can expose your signalling server (TCP/HTTP) and your media ports (UDP) at the same time. This allows external peers or mobile devices to connect to your local WebRTC instance and stream video directly through the firewall, mimicking a production environment without deploying to a staging server. For teams using mediasoup, Janus, or a custom SFU locally, this removes a significant CI friction point. Use Case 3: IoT and Embedded Systems The IoT ecosystem favours lightweight protocols to conserve battery life and bandwidth on constrained devices. CoAP (Constrained Application Protocol) and MQTT over DTLS (Datagram TLS) both rely entirely on UDP. If you are developing firmware for a custom sensor board and need to test its telemetry reporting to an external cloud ingestion service, you need a public UDP endpoint that you can hand off to a remote team or a CI pipeline. Tunnels like LocalXpose or Pinggy let you expose your local IoT rig to the internet, allowing cloud-based services to push commands directly to a device on your desk — no staging environment required. Security: What You Are Actually Exposing UDP tunnels are powerful, but they fundamentally extend your localhost’s trust boundary to the open internet. Do not treat them as casually as an HTTP tunnel. DDoS vulnerability. Unlike HTTP tunnels that can rate-limit requests based on headers and session state, raw UDP tunnels forward datagrams indiscriminately. An attacker who discovers your public UDP endpoint can flood it with garbage packets, easily saturating your local connection. Always close UDP tunnels the moment your testing session ends — ephemeral is not just convenient, it is a security property. No inherent authentication layer. HTTP tunnels can overlay Basic Auth or OAuth. Raw UDP does not have that concept. The application listening on the exposed port must handle its own authentication. If you are exposing a game server or local database, ensure it requires strong credentials independently of the tunnel. The OAuth redirect URI trap. A real risk that has become more visible in 2026: developers who register an ephemeral tunnel URL as an authorised redirect URI in a Google or GitHub OAuth app and forget to remove it after the PR merges. If that subdomain pattern is later issued to another user on the same tunneling service, they can potentially intercept OAuth callbacks. Mitigate this by implementing automated cleanup of OAuth redirect URIs as part of your PR merge workflow, and enforce OIDC authentication at the tunnel edge for any OAuth-adjacent testing. Identity-aware access for sensitive workloads. For anything beyond throwaway local testing, tools like Cloudflare Tunnel or Tailscale enforce authentication before traffic can reach your tunnel endpoint. This should be the baseline for any tunnel that stays up longer than a single session. Tool Comparison at a Glance Feature ngrok Pinggy LocalXpose Localtonet Playit.gg UDP Support ✗ ✓ ✓ ✓ ✓ Free Tier 1 GB/mo Yes Yes 1 tunnel, 1 GB 4 UDP + 4 TCP Paid Plan $8/mo $3/mo ~$6/mo ~$2/tunnel/mo $3/mo Install Required Yes No (SSH) CLI/GUI CLI/GUI/SSH Yes Best For HTTP/Webhooks Quick sharing Gaming, IoT All-round workloads Game servers What Is Next: WebTransport and the Blurring Line The line between “UDP tunneling” and “HTTP” is going to --- ## Stop Using TypeScript as a Type Checker — Start Using It as a Design System > Published: 2026-05-24 06:52:16+00:00 > Source: https://dev.to/dev_ahmed1/stop-using-typescript-as-a-type-checker-start-using-it-as-a-design-system-8o0 > wpnews: https://wpnews.pro/news/stop-using-typescript-as-a-type-checker-start-using-it-as-a-design-system TypeScript is often misunderstood as merely "JavaScript with types," but this definition captures only about 30% of its value. Its true power lies not in preventing runtime errors, but in enforcing system design discipline at compile time by making invalid states unrepresentable through constructs like discriminated unions and strict type contracts. When used as a design system rather than just a type checker, TypeScript transforms code evolution from guesswork to verified, mechanical change, eliminating entire categories of bugs caused by unclear data shapes, implicit assumptions, and inconsistent API responses. TypeScript is often introduced as: “JavaScript with types” That definition is technically correct — and practically misleading. Because if this is how you use TypeScript, you are only using ~30% of its value. The real power of TypeScript is not in preventing runtime errors. It is in forcing system design discipline at compile time. This article focuses on how TypeScript changes architecture decisions, not syntax. - The Hidden Problem in JavaScript: Undefined Contracts In JavaScript systems, most bugs don’t come from syntax mistakes. They come from: unclear data shapes implicit assumptions between modules silent undefined values inconsistent API responses Example: ``` getUser().name.toUpperCase() ``` This assumes: user exists name exists name is a string Nothing enforces this. - TypeScript’s Real Job: Making Assumptions Explicit Now rewrite the same idea: ``` type User = { name: string; }; function getUser(): User | null ``` Now the system forces you to handle reality: ``` js const user = getUser(); if (!user) return; console.log(user.name.toUpperCase()); ``` The key difference is not safety. The key difference is: you are no longer allowed to ignore system uncertainty. - Union Types Are a State Machine in Disguise Most developers treat union types as a convenience: ``` type Status = "idle" | "loading" | "success" | "error"; ``` But this is actually a state machine definition. Now your UI logic becomes constrained: ``` if (status === "loading") {} if (status === "error") {} ``` You are no longer writing “if checks”. You are modeling system behavior. - The “Impossible State” Problem and Why TypeScript Solves It In JavaScript, you can easily reach invalid states: loading = true + error exists user = null + role = "admin" data = undefined but UI rendered TypeScript eliminates this class of bugs using discriminated unions: ``` type State = | { status: "loading" } | { status: "success"; data: string } | { status: "error"; message: string }; ``` Now invalid states are unrepresentable. This is not a feature. This is architecture enforcement. - Type Inference Is a Compiler-Driven Design Assistant A common misconception: “TypeScript slows development down” In reality, inference reduces mental overhead. Example: ``` js const users = [ { id: 1, role: "admin" }, { id: 2, role: "user" } ]; ``` TypeScript automatically derives: ``` { id: number; role: string; }[] ``` Now you get: autocomplete refactoring safety consistency across the codebase Without manually maintaining types everywhere. - Type Narrowing = Controlled Execution Flow Instead of runtime guessing: ``` if (typeof value === "string") { value.toUpperCase(); } ``` TypeScript makes execution flow explicit. But the deeper idea is: Type narrowing is not about types — it is about controlling program paths. Every if becomes a validated transition of state. - API Design Becomes a Compile-Time Contract Compare: JavaScript API: ``` createUser(data) TypeScript API: function createUser(data: { email: string; password: string; }): Promise<{ id: string }> ``` Now the function is not just implementation. It is a public contract enforced by the compiler. This eliminates: invalid payloads undocumented requirements runtime validation leaks - Why Large Systems Break Without Type Systems In large codebases, JavaScript fails in one core way: Change becomes dangerous. Because nothing tells you what breaks. TypeScript flips this: Change becomes mechanical. You modify a type → compiler shows impact instantly. This changes system evolution from: guessing → verification runtime debugging → compile-time correction Conclusion TypeScript is not a productivity tool. It is a system constraint engine. If you use it only for: avoiding any adding types to functions basic autocomplete You are underusing it. The real value is this: TypeScript lets you design systems where invalid states cannot compile. That is the real upgrade from JavaScript — not syntax, but discipline. --- ## How Google I/O 2026 Inspired Me to Start Building a Telugu Jarvis AI > Published: 2026-05-24 06:49:33+00:00 > Source: https://dev.to/bajiniteenoj/how-google-io-2026-inspired-me-to-start-building-a-telugu-jarvis-ai-249f > wpnews: https://wpnews.pro/news/how-google-i-o-2026-inspired-me-to-start-building-a-telugu-jarvis-ai The author describes being inspired by Google I/O 2026 to create a Telugu-language AI assistant, similar to "Jarvis." They argue that AI should be accessible in regional languages like Telugu to help millions of Indian students learn and communicate more effectively. The project aims to build Telugu-first AI experiences to make technology more inclusive and confidence-building for non-English speakers. Note: I used AI tools to help improve writing structure and organize my ideas, while the project concept, opinions, and personal perspective are my own. Why Regional Language AI Matters One thing I strongly believe is that AI should not only work well for English speakers. In countries like India, millions of students are more comfortable learning and communicating in regional languages like Telugu. If AI tools become more multilingual and accessible, they can help students learn faster and feel more confident using technology. That is one of the main reasons I want to continue building Telugu-first AI experiences. --- ## I stress-tested Gemma 4 E4B's 128K context on a laptop GPU — recall is great, prefill is not > Published: 2026-05-24 06:44:15+00:00 > Source: https://dev.to/yashksaini/i-stress-tested-gemma-4-e4bs-128k-context-on-a-laptop-gpu-recall-is-great-prefill-is-not-244i > wpnews: https://wpnews.pro/news/i-stress-tested-gemma-4-e4b-s-128k-context-on-a-laptop-gpu-recall-is-great-is Here is a factual summary of the article: The article details a stress test of the Gemma 4 E4B model's 128K context window on a laptop GPU (RTX 5050). The test found that while the model's recall of information within the context remained perfect across all tested sizes, the "time to first token" (prefill latency) increased dramatically and almost linearly with context length, rising from 4 seconds at 5K tokens to 72 seconds at 100K tokens. The author concludes that the 128K specification is accurate but misleading, as it does not account for the significant prefill latency that makes the model impractical for interactive use on consumer hardware. Thursday night I let a benchmark run while I slept. By Friday morning Gemma 4 E4B had answered fifteen needle-in-a-haystack questions across four context sizes on my RTX 5050 laptop. The recall numbers were better than I expected. The latency numbers were worse. Here's both, with the ~30 lines of Python to reproduce it on your own hardware. I keep seeing "Gemma 4 E4B has a 128K context window" repeated as if it were a single property, like *"the engine is 3.5 litres"*. It is not a single property. A context-window number means at least three different things — *will the model accept this many tokens?*, *will it remember what's in the middle of them?*, and *how fast does the first answer token arrive?* — and the answers diverge sharply once you leave the laptop-GPU regime that most spec sheets assume. This is the post I wish I'd had when I started building on E4B. The TL;DR is in the table further down. The reproducible test rig is at the bottom. ## The setup - **Hardware:** RTX 5050 Laptop, 8 GB VRAM, 24 GB system RAM, Intel i7-13620H - **Software:** Ollama 0.24.0,`gemma4:e4b` (Q4_K_M, ~9.6 GB on disk), Linux 7.x - **Test:** needle-in-a-haystack — five unique 4-character codes embedded at fixed positions inside a long synthetic English document; the model has to recover each one in isolation by exact match. The test is deliberately simple. I want to know whether the model can *find* a fact at a known position, not whether it can paraphrase it. Reasoning quality is a different benchmark and needs human evaluation, which I didn't have budget for. I ran the sweep at 5K, 20K, 60K, and 100K target context sizes. I didn't push to the 128K spec because Ollama's `num_ctx` setting interacts with the K/V cache headroom in ways I didn't have time to characterize cleanly, and 100K is already 80% of the spec. ## The numbers | Context | Pass rate (5/5) | Tokens/sec | Time to first token | |---|---|---|---| | 5K | 5/5 ✓ | 9.2 | 4 s | | 20K | 5/5 ✓ | 8.6 | 15 s | | 60K | 5/5 ✓ | 7.6 | 38 s | | 100K | 5/5 ✓ | 6.8 | 72 s | Three things stand out. **Recall stayed perfect.** I expected E4B to wobble somewhere past 60K — that's the failure mode I see most reported for 4B-class models, the "middle of the context is fuzzy" problem. The needles at 25% and 75% are exactly where I'd expect drop-off. They held. I re-ran the sweep twice to be sure. **Generation throughput barely moved.** 9.2 tok/s at 5K vs. 6.8 tok/s at 100K. That's a 26% drop across a 20x context increase. The K/V cache is the obvious culprit, but in practical terms: once the answer starts streaming, it streams at roughly the same speed. **Time to first token blew up.** 4s at 5K, 72s at 100K. Almost linear in context size. This is the prefill phase — the model encoding everything you sent it before producing the first output token. On a laptop GPU, prefill is where the consumer-hardware tax lives. ## What this means if you're building on E4B Let me write the practical zones the way I actually think about them, not the marketing version: - **Under 20K tokens:*** interactive.*First token in ~15 seconds, full answer in ~25-30s. This feels like a real conversation. Most single-paper Q&A lives here. - **20K to 60K tokens:*** research-assistant.*30-40 second TTFT. You're going to glance away from the screen. That's fine, the answer will be there when you look back. Multi-paper comparisons, longer contexts. - **60K to 100K tokens:*** batch.*You're queuing a job. 60-80 second TTFT means you might as well make coffee. Loading a whole codebase, a textbook chapter, a quarter's worth of meeting notes. - **Above 100K:** I didn't measure. The prefill cost was already breaching my "is this still interactive?" threshold and the use case I was solving for didn't need it. If you're designing a UI on top of this model, *surface these zones to the user*. A progress bar or a tier label ("interactive / research / batch") tells someone what their next click will *feel* like before they ask. The 128K spec is honest; it just doesn't tell you when it'll start. ## Reproduce it yourself The whole rig is about 30 lines once you strip the CLI scaffolding. Save this as `bench.py` , install `ollama` (`pip install ollama` ), then run it: ``` python import random, time import ollama MODEL = "gemma4:e4b" NEEDLE_POSITIONS = [0.05, 0.25, 0.50, 0.75, 0.95] def make_needles(k=5, seed=20260521): rng = random.Random(seed) chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789" return [(f"box-{i+1}", "".join(rng.choices(chars, k=4))) for i in range(k)] def build_haystack(target_tokens: int, needles): # Filler ~ 80 tokens per sentence, English-ish prose. filler = ( "The committee continued its review of the operational notes " "submitted during the prior fiscal quarter, with particular " "attention paid to procedural anomalies. " ) sentences_needed = target_tokens // 20 # ~4 tok/word, 5 words/sentence avg body = (filler * sentences_needed)[: target_tokens * 4] # Splice needles in at fixed positions out = body for pos, (label, code) in zip(NEEDLE_POSITIONS, needles): i = int(pos * len(out)) out = out[:i] + f"\n\nNote: {label} contains the code {code}.\n\n" + out[i:] return out def ask(haystack: str, label: str, num_ctx: int) -> tuple[str, float, float]: t0 = time.time() first_t = None chunks = [] for r in ollama.chat( model=MODEL, messages=[ {"role": "system", "content": "Answer with only the 4-character code, nothing else."}, {"role": "user", "content": haystack + f"\n\nWhat code is in {label}?"}, ], stream=True, options={"num_ctx": num_ctx}, ): delta = r.get("message", {}).get("content", "") if delta: first_t = first_t or time.time() chunks.append(delta) answer = "".join(chunks).strip() return answer, (first_t - t0) if first_t else 0, time.time() - t0 if __name__ == "__main__": needles = make_needles() for ctx in (5_000, 20_000, 60_000, 100_000): hay = build_haystack(ctx, needles) passed = 0 for label, code in needles: ans, ttft, total = ask(hay, label, num_ctx=ctx + 4_000) passed += code in ans print(f" ctx={ctx:>6,} {label} expected={code} got={ans!r} ttft={ttft:.1f}s total={total:.1f}s") print(f"ctx={ctx:>6,} pass={passed}/{len(needles)}") ``` It writes to stdout. If you want JSON-lines results to plot, redirect to a file and parse the `ctx=… pass=…` lines. The whole sweep takes ~30 minutes on an RTX 5050; longer on smaller GPUs. The seed is fixed (`20260521` ) so the needle strings are deterministic. If your pass rate doesn't match mine at the same `(model, ctx, seed)` , that's a real signal — likely Ollama version, quantization, or hardware-driver path. ## Things this rig deliberately doesn't measure **Quality of paraphrase.** The needles are literal 4-character codes. I'm measuring *can the model find it?*, not *can the model reason about it?*. Those are different benchmarks. **VRAM consumption.** Ollama owns the K/V cache and I'm not going to fight it for memory accounting. `nvidia-smi` says it sits around 7.4 GB at 100K context, but I haven't characterized the curve. **Cross-document attention.** Each needle is asked in isolation. Multi-fact composition ("how does the figure on page 12 of paper A relate to section 3 of paper B?") is a different problem. I don't have a clean benchmark for it. I'm working on it. ## The honest comparison Qwen 3.5 27B has ~190K effective context on similar hardware. Llama 3.1 70B (if you can fit it) goes further. On *raw context size alone*, Gemma 4 E4B isn't the winner. What E4B *is* the winner at is the **combination**: 128K context + native vision + native audio + ~9.6 GB on disk, all in one model. That combination is what makes whole-document workloads tractable on a laptop. Qwen 27B doesn't fit in 8 GB of VRAM. Llama 3.1 70B doesn't either. If your hardware constraint is "consumer GPU", E4B is the only model in this class with 128K context *and* multimodality. That's the framing I'd give someone choosing an open-weights model for a single-machine deployment in 2026. ## Three places I'd take this benchmark next - **Mixed-modality recall.** Embed half the needles in text, half in rendered images. See if vision-encoded needles degrade differently from text-encoded ones. (This is the part most relevant to anyone building doc-Q&A.) - **Cross-document needles.** Two documents in context, the needle in paper A, the question phrased to require paper B's vocabulary. The actual "I have a library, I want to ask questions" workload. - **Long-document Q&A with human evaluation.** Pay five grad students to grade 100 questions about a single 25-page research paper. Real quality numbers, not synthetic ones. If you run any of these, I'd genuinely like to read the results. **Connect with me:** • [Website](https://yashksaini.vercel.app/) • [GitHub](https://github.com/yashksaini-coder) • [LinkedIn](https://www.linkedin.com/in/yashksaini/) • [X (Twitter)](https://x.com/0xcrackedDev) --- ## Python SDK for Tell A Bot API: Automate Your SMS Verification > Published: 2026-05-24 06:38:41+00:00 > Source: https://dev.to/tellabot_sms/python-sdk-for-tell-a-bot-api-automate-your-sms-verification-2c3f > wpnews: https://wpnews.pro/news/python-sdk-for-tell-a-bot-api-automate-your-sms-verification The article announces the release of a Python SDK for the Tell A Bot API, which provides temporary US phone numbers to receive SMS messages and OTP codes for over 700 services. The SDK allows developers to automate phone verification in bots, scrapers, and testing pipelines by requesting numbers, waiting for SMS, and extracting PIN codes via API calls or webhooks. Key features include balance checking, number rejection, error handling, and service listing with pricing and availability. If you've ever built a bot, scraper, or testing pipeline that needs to verify a phone number, you know the pain: SIM cards, forwarding services, juggling multiple numbers manually. [Tell A Bot](https://www.tellabot.com) solves this — it gives you temporary US phone numbers on demand, receives the SMS, and hands you back the OTP code. All via API. We just published a **Python SDK** on GitHub, so I wanted to walk through what it looks like in practice. ## What is Tell A Bot? [Tell A Bot](https://www.tellabot.com) is a service for receiving SMS online using temporary US phone numbers. You request a number for one of 700+ supported services, the number waits for an incoming SMS, and once it arrives you read the message and the extracted PIN code through the API. Common use cases: - Automating account registration or verification flows in tests - Receiving OTP codes in scripts without a physical SIM - Spinning up multiple accounts for a service during development ## Installation ``` pip install get-sms-online ``` Or directly from GitHub: ``` pip install git+https://github.com/getsms-online/get.sms.online-python.git ``` Generate your API key at **Account → Profile** in Tell A Bot's members area. ## The simplest case — request a number and wait for the code ``` python from getsms import GetSMSClient, GetSMSError client = GetSMSClient(user="your_username", api_key="your_api_key") # Check your balance first print(f"Balance: ${client.balance()}") # Request a number for WhatsApp and wait for the SMS requests = client.request_number("WhatsApp") req = requests[0] print(f"Your number: +{req['mdn']}") sms = client.wait_for_sms(req["id"], timeout=900) if sms: print(f"SMS: {sms['reply']}") print(f"Code: {sms['pin']}") else: print("No SMS received in time") ``` `wait_for_sms` polls the API every 15 seconds (the recommended minimum) and returns the message once an SMS arrives, or `None` on timeout. ## Error handling ``` python from getsms import GetSMSClient, GetSMSError client = GetSMSClient(user="your_username", api_key="your_api_key") try: requests = client.request_number("Google") req = requests[0] sms = client.wait_for_sms(req["id"]) if sms: print(f"Got code: {sms['pin']}") else: print("Timed out — no SMS received") except GetSMSError as e: # API-level errors: invalid service name, no numbers available, etc. print(f"API error: {e}") except Exception as e: # Network errors print(f"Request failed: {e}") ``` ## Reject a number you don't want If the assigned number looks wrong or you want to skip it, reject it — it won't be offered to you again: ``` requests = client.request_number("Telegram") req = requests[0] if req["mdn"].startswith("1212"): client.reject(req["id"]) # NYC numbers blocked by the service? Skip it. ``` ## Webhooks instead of polling If you're handling volume, configure a webhook URL at **Account → Profile**. Tell A Bot will POST to your endpoint the moment an SMS arrives, with fields including `event` , `id` , `reply` , `pin` , and `price` . No polling loop needed. ## Check available services and pricing ``` # All services services = client.list_services() for s in services: print(f"{s['name']}: ${s['price']} ({s['otp_available']} available)") # Single service — also returns recommended_markup for priority bidding info = client.list_services("Google") print(info[0]["recommended_markup"]) ``` ## Links - [Tell A Bot](https://www.tellabot.com)— sign up, manage numbers, configure webhooks - [API reference](https://www.tellabot.com/api_command_reference.php)— full documentation - [Python SDK on GitHub](https://github.com/getsms-online/get.sms.online-python)— source --- ## What I Understood from Cracking the Coding Interview > Published: 2026-05-24 06:37:03+00:00 > Source: https://dev.to/vishwa_k/what-i-understood-from-cracking-the-coding-interview-okc > wpnews: https://wpnews.pro/news/what-i-understood-from-cracking-the-coding-interview The article summarizes key lessons from the book *Cracking the Coding Interview*, emphasizing that technical interviews test problem-solving ability and practical coding skills rather than academic knowledge or memory. It highlights the importance of regular practice with real interview questions, clear communication of one's thought process during interviews, and the need for confidence and analytical thinking. The author concludes that success in software interviews requires more than intelligence or good grades, demanding dedicated preparation and a focus on practical learning. Recently, my mentor gave me the book Cracking the Coding Interview and asked me to read it carefully. After reading the introduction, I understood many important things about technical interviews, coding skills, and the real expectations of software companies. The book gave me a new perspective on how students should prepare for interviews and careers in the software industry. The introduction begins with a story about a candidate who was highly talented but still failed a technical interview. He had a strong academic background, a very good GPA, and experience working on open-source projects. He was intelligent, creative, and hardworking. Even with all these qualities, he was rejected because he could not perform well during the interview process. This story made me realize that academic marks and theoretical knowledge alone are not enough to succeed in technical interviews. One of the main lessons I learned from this book is that coding interviews are designed to test problem-solving ability rather than memory. Interviewers are not interested only in whether a candidate knows programming languages or textbook definitions. They want to see how candidates think, how they approach a problem, and how effectively they can develop a solution. The candidate in the story struggled because he could not quickly identify efficient algorithms and made coding mistakes during the interview. This showed me that interviews require strong analytical thinking and practical coding skills. Another important point explained in the book is the value of practice. Many students spend a lot of time studying theory from textbooks and learning complex concepts. While these topics are useful, they are not sufficient for interview preparation. The author explains that candidates should practice real interview questions regularly. By solving different coding problems, students can learn common patterns, improve logical thinking, and gain confidence. This helped me understand that daily practice is one of the most important parts of preparation. The book also highlights the importance of communication during interviews. Candidates should not only write code but also explain their thinking process clearly. Interviewers observe how candidates analyze the problem, discuss multiple approaches, and improve their solutions step by step. Even when mistakes happen, the ability to correct them calmly is important. This taught me that confidence and communication skills are equally valuable in technical interviews. I was also inspired by the author’s passion for teaching. She explains that many talented students fail interviews not because they are weak, but because they prepare in the wrong way. Her goal is to help students understand the interview process and improve their preparation methods. This motivated me to focus more on practical learning instead of only studying theory. Overall, Cracking the Coding Interview helped me understand that success in software interviews requires more than intelligence or academic performance. It requires problem-solving ability, coding practice, logical thinking, and confidence. The introduction itself gave me valuable guidance about how to prepare for my future career. After reading it, I feel more motivated to improve my coding skills, practice interview questions regularly, and become a better software engineer in the future. --- ## How Thinking Machines built interactivity into the model > Published: 2026-05-24 06:35:52+00:00 > Source: https://dev.to/thousand_miles_ai/how-thinking-machines-built-interactivity-into-the-model-3an8 > wpnews: https://wpnews.pro/news/how-thinking-machines-built-interactivity-into-the-model According to a May 11, 2026 research preview from Thinking Machines, the company has developed a new class of "interaction models" that process audio, video, and text in continuous 200-millisecond ticks, eliminating the need for a separate voice-activity-detection component. This design allows the model to handle input and output streams concurrently, achieving 0.40 seconds end-to-end latency on the FD-bench V1 benchmark—roughly three times faster than GPT-realtime-2.0 and half the latency of Gemini-3.1-flash-live. The system splits responsibilities between a 276-billion-parameter interaction model for real-time conversation and an asynchronous background model for deeper reasoning, enabling the interaction model to maintain continuous dialogue without freezing during complex tasks. A new release from Thinking Machines, dated May 11, 2026, lands at 0.40 seconds end-to-end on the FD-bench V1 turn-taking benchmark — about three times faster than GPT-realtime-2.0 (xhigh) and roughly half the latency of Gemini-3.1-flash-live (high). The latency number is the surface story. The architectural story is what makes it possible: the model is processing audio, video, and text in 200-millisecond ticks, with no separate turn-detection component sitting between the user and the weights. The post that landed at thinkingmachines.ai is a research-preview announcement of a class of models the team is calling interaction models. The framing question worth taking seriously is this: what changes when interactivity is part of the model itself instead of a harness around it? The three sections below walk through the answer. A turn-based model receives one complete input, generates one complete output, and waits. An interaction model receives 200ms of input and produces 200ms of output, then 200ms more, then more — input and output streams running concurrently. The model does not see "the user's turn finished, now respond." It sees a continuous interleaved sequence: input chunk, output chunk, input chunk, output chunk, with no artificial turn boundaries to honor. What disappears in this design is the voice-activity-detection harness that lives between the user and the model in most real-time speech systems today. Turn-based models cannot tell on their own whether the user is thinking, yielding the floor, or being briefly silent — a separate, smaller component makes that call and passes the model a "go" signal. Thinking Machines argues, citing The Bitter Lesson, that any harness less intelligent than the model itself will eventually be outpaced by the model. So they remove the harness, and the things that harnesses could not express — speaking while listening, reacting to a visual cue without an audio prompt — become things the model can do directly. The audio and video paths are deliberately lightweight. Audio comes in as dMel features through a thin embedding layer, not a Whisper-style encoder. Images are split into 40×40 patches encoded by an hMLP. The audio decoder is a flow head. All four components — embedding, image patcher, flow head, and the main transformer — are co-trained from scratch together. The phrase the team uses is encoder-free early fusion, and the practical effect is that there is no separate pre-processing model whose limits cap what the interaction model can do. A 200ms tick is fast enough for conversational presence, but it is not enough time for sustained reasoning, tool use, or longer-horizon work. The system splits those responsibilities across two models. The interaction model — TML-Interaction-Small , a 276-billion-parameter mixture-of-experts with 12B active — holds the live thread, listens, speaks, watches. When the user asks for something that needs deeper work, the interaction model delegates to a background model that runs asynchronously. The split matters because the interaction model does not freeze while the background model thinks. It keeps the conversation going — answering follow-ups, taking new input, holding the thread — and weaves background results back in when they arrive, at a moment that fits what the user is currently doing rather than as an abrupt context switch. Both models share context, so the background model is not starting cold from a stripped query; it inherits the full conversation. The net effect for the user: planning, tool use, and agentic workflows at the response latency of a non-thinking model. The interaction model on its own is also competitive on intelligence benchmarks — 89.7 on text IFEval, 82.1 on voice IFEval — so it is not a thin front-end that punts everything to the background. The standard interactivity benchmarks (FD-bench, Audio MultiChallenge) put TML-Interaction-Small ahead of every other non-thinking model on the Pareto frontier of intelligence versus latency. That is a real result. But the more telling numbers are on benchmarks the team built specifically to test what an interaction model can do that a harness-wrapped turn-based model cannot. On TimeSpeak — which asks the model to initiate speech at user-specified times with the correct content — TML-Interaction-Small scores 64.7 versus 4.3 for GPT-realtime-2.0 (minimal). On CueSpeak, which tests speaking at the appropriate moment in response to a verbal cue, 81.7 versus 2.9. On Charades, a temporal-action-localization task adapted to require the model to say "start" and "stop" at the right moments of a video, the temporal IoU is 32.4 versus 0. On ProactiveVideoQA, where the no-response baseline scores 25.0, TML-Interaction-Small scores 33.5 — a small absolute lift, but a meaningful one, since the baseline is essentially "say nothing and lose no points." Scores near zero usually mean the benchmark is testing a capability the architecture cannot express. The point is not that GPT-realtime-2.0 is poor at speech — it is that turn-based plus harness has no representation for "speak while listening" or "react to a visual cue without an audio prompt." Time-aligned micro-turns do, and the benchmark gap follows. The post is honest about what is not solved. Very long sessions still need careful context management — continuous audio and video accumulate context quickly. Streaming at low latency is sensitive to network reliability, and the experience degrades hard over a flaky connection. The current TML-Interaction-Small is the small one — larger pretrained models exist but are too slow to serve in this regime today, and the team plans to release them later this year. The research preview will open in the coming months with a wider release after. Source: Interaction Models: A Scalable Approach to Human-AI Collaboration, Thinking Machines Lab, May 11, 2026. --- ## Four production pitfalls that turn RAG demos into broken chatbots > Published: 2026-05-24 06:35:19+00:00 > Source: https://dev.to/sapotacorp/four-production-pitfalls-that-turn-rag-demos-into-broken-chatbots-127o > wpnews: https://wpnews.pro/news/four-production-pitfalls-that-turn-rag-demos-into-broken-chatbots Based on the article, the primary reason RAG (Retrieval-Augmented Generation) chatbots fail in production is that internal demo questions are written by people familiar with the knowledge base, while real users ask long-tail queries the system cannot answer. The article identifies four key pitfalls: vector search returning irrelevant chunks without a "nothing matched" mode, using a single chunk size for diverse content types, failing to monitor embedding drift as the corpus grows, and lacking a router to handle multi-hop queries. Solutions include setting a similarity threshold, implementing a faithfulness check, using content-type-specific chunking, and adding observability tools. A common pattern we see: a Series A team builds a RAG assistant, runs a 50-question internal demo, ships to production, and within two weeks the support inbox is full of "the AI gave me a wrong answer" tickets. Nothing changed between Tuesday's demo and Friday's outage. The same model, the same retrieval, the same prompt template. What changed is the question distribution. Internal demos are written by people who already know the corpus. Production users are not. The four failure modes below show up almost every time. Vector search does not have a "nothing matched" mode. It returns the top-k closest chunks regardless of whether any of them actually answer the question. Cosine similarity of 0.62 looks roughly like cosine similarity of 0.78 to a model that just consumes the chunks as prompt context. The result is a confident hallucination on every long-tail query. A user asks about a feature the team has not documented yet, and the assistant returns a fluent paragraph stitched together from the closest tangentially related content. The user has no way to know the answer is wrong. The Sapota fix is two-pronged. First, set a similarity floor (typically cosine 0.7 to 0.75 depending on the embedding model) and return "I do not have this in my knowledge base" when the top result falls below it. Second, add a faithfulness check using either Ragas or a smaller LLM-as-judge that verifies the generated answer is grounded in the retrieved context before it ships to the user. The faithfulness gate alone catches around 40% of the hallucinations we see in audits. Most teams pick chunk_size=512 because that is the default in the framework they started with, and never look at it again. This is fine for blog-post-style content. It is not fine for a corpus that mixes blog posts, research papers, code documentation, and contracts. Two failure modes follow: The Sapota playbook is to pick chunk size per content type, not per corpus. Markdown documentation gets recursive splitting on headings. Research papers get hierarchical chunking with parent-section metadata. Contracts get section-level chunks with cross-reference resolution. The infrastructure cost of mixing strategies is small. The recall difference is not. If the corpus is genuinely homogeneous, run a sweep at 256, 512, and 1024 tokens against a 100-question eval set and pick the winner. Do not eyeball it. This is the one that quietly kills RAG products six months in. The team ships, things look fine, the founder moves on to the next feature. Three months later the corpus has grown by 40%, the embedding distribution has drifted, and recall has dropped from 85% to 62%. Nobody notices because nobody is looking. The minimum observability stack we ship with every RAG project: The expensive version of this is a full LLMOps platform. The cheap version is a Postgres table, a cron job, and a Slack webhook. Both work. What does not work is having neither. User asks: "Which of our enterprise customers complained about the new pricing tier in Q4?" This is a three-hop question: find enterprise customers, filter by Q4 timeframe, find the ones with complaints about pricing. A single vector search over a chunked CRM corpus will not find the answer. It will find chunks that mention "enterprise" and "pricing" and stitch together something plausible. The fix is one of three patterns, depending on how often these queries show up: The default we recommend is to add a router as the first step. A small fast model (Llama 3.1 8B is enough) classifies whether the query is single-hop, multi-hop, or structured, and dispatches accordingly. The cost is one extra LLM call per query. The accuracy gain on the 15 to 25% of queries that are actually multi-hop is worth it. When a team brings us in after a launch goes wrong, the first 48 hours are diagnostic, not engineering. We ask for: The query log usually shows that 60% of production queries fall outside the distribution the eval set covered. The eval set was written by the engineers, who think like engineers. Production users ask questions in a different shape. The diagnostic deliverable is a one-page document mapping each user complaint to which of the four pitfalls caused it, with a recommended fix and the order to ship them in. Most teams can ship the highest-impact two fixes in the first week and recover 70% of the lost user trust. If the AI assistant your team shipped is getting worse instead of better, or if the eval scores look fine but the user feedback says otherwise, that is the gap an audit closes. Sapota runs a fixed-scope two-week diagnostic engagement that produces the document above plus the implementation plan for the first three fixes. Reach out via the AI engineering page with a description of what you are seeing in production. The first conversation is free and almost always surfaces at least one of the four pitfalls within thirty minutes. --- ## Active Page: Tackling Local AI for Transforming Passive Reading into Active Recall > Published: 2026-05-24 06:35:06+00:00 > Source: https://dev.to/muhammad_dafi_5eebbcb5d63/active-page-tackling-local-ai-for-transforming-passive-reading-into-active-recall-4hoj > wpnews: https://wpnews.pro/news/active-page-tackling-local-ai-for-transforming-passive-reading-into-active Active Page is a local-first application that uses the Gemma 4 E2B model to combat the "forgetting curve" by automatically generating contextual quizzes from reading material. It runs entirely on the user's machine for zero operational costs and privacy, featuring a streak system to encourage daily learning habits. The app optimizes performance through techniques like prefix caching and an asynchronous pre-fetching pipeline to minimize latency and maintain reading immersion. This is a submission for the Gemma 4 Challenge: Build with Gemma 4 Most readers suffer from the "forgetting curve." By the time we finish the later chapters of a dense book, the foundational concepts from the introduction have already begun to blur. As a middle school student trying to learn something new with reading books and scientific journal article, I wanted a better way to retain knowledge. My inspiration came from observing National Science Olympiad winners, my friend and other figure, who maintain peak retention not through passive rereading, but through consistent daily answering a lot of questions. Active Page is a local-first application that transforms passive reading into an interactive learning experience. It automatically generates high-quality, analytical, and contextual quizzes directly from your reading material for immediate memory reinforcement. To help users build a sustainable learning habit, Active Page also features a built-in streak mechanics system to keep readers motivated daily. 🔥🔥 Because Active Page run locally, it has operational costs at zero (beside the use of the device) and side benefit of reading books without internet. While local compute constraints often drive developers toward over-engineering, Active Page takes a more elegant path. Active Page is a privacy-first, local-LLM-powered reading companion designed to solve the "forgetting curve." By leveraging the cutting-edge Gemma 4 E2B model, it transforms passive reading into an interactive learning session through real-time, contextual active recall—running entirely on your machine. The init.sh script automates the heavy lifting: it manages dependencies via uv, compiles llama.cpp for your specific hardware, and pulls the optimized Gemma 4 E2B weights. bash init.sh Note for Silicon/AMD: If using Apple M-Series or AMD GPUs, edit init.sh to enable GGML_METAL=ON or GGML_HIPBLAS=ON respectively for hardware acceleration. Launch the inference engine and the interactive web interface simultaneously: bash run.sh Access the application at: http://localhost:8000 System Crashing / Out of Memory in the init.sh If your ram or CPU is limited, adjust the pararrel of building… I selected the Gemma-4-E2B model because it perfectly balances performance and efficiency for local deployment. It leverages Per-Layer Embeddings (PLE) and a hybrid attention mechanism combining Sliding Window Attention (SWA) with Grouped Query Attention (GQE). This architecture allows it to have 128K context window while deliver output quality that rivals much larger models while remaining lightweight and fast enough for edge devices. Beyond simply powering the app, Gemma-4-E2B design unlocked sophisticated long-context capabilities on-device. Its compact size enables aggressive KV cache usage for manipulation, which is essential for maintaining a seamless, responsive reading experience with active recall across extended contexts. The "memory" of an AI (KV Cache) is usually treated as a linear path. In most apps, the book data is treated as a fresh prompt every time, which is slow and memory-intensive. The "memory" of an AI (KV Cache) is usually treated as a linear path. In most apps, the book data is treated as a fresh prompt every time, which is slow and memory-intensive. I inverted this structure to maximize Prefix Caching: For tackling memory constrain and decode speed, we use this technique to solved it, which also come from google. Even with an optimized KV cache, generating multiple-choice questions (MCQs) quiz requires a slight processing window. Forcing a reader to wait at a loading spinner when a quiz triggers would break their reading immersion. Active Page completely cut local execution latency by decoupling the generation engine from the UI through an Asynchronous Pre-Fetching Pipeline: --- ## TerraSight Offline Satellite Analysis Powered by Gemma 4 > Published: 2026-05-24 06:30:54+00:00 > Source: https://dev.to/hyster_alan_cae6913e040c6/terrasight-offline-satellite-analysis-powered-by-gemma-4-2nkk > wpnews: https://wpnews.pro/news/terrasight-offline-satellite-analysis-powered-by-gemma-4 **Summary:** TerraSight is an offline geospatial analysis tool that processes raw Landsat 9 satellite data on a user's local machine to compute vegetation health (NDVI), urban coverage (NDBI), and land surface temperature (LST). It uses Google's Gemma 4 E4B model, running locally via Ollama, to provide contextual AI explanations of the computed statistics without requiring cloud processing or GIS expertise. The tool is designed for non-specialists like farmers and students, ensuring data privacy by keeping all analysis and AI inference on the user's hardware. *This is a submission for the Gemma 4 Challenge: Build with Gemma 4* ## What I Built TerraSight is a geospatial analysis tool that runs entirely on your machine. You upload raw Landsat 9 satellite band files, draw a study boundary, and the app computes three indices: NDVI (vegetation health), NDBI (urban surface coverage), and LST (land surface temperature), then renders calibrated colour maps and lets you interrogate the results through an AI chat interface. No cloud processing. No API keys. No data leaving your machine. The problem I was solving is straightforward: satellite imagery analysis has always sat behind expensive software licenses (ENVI, ArcGIS) or required GIS expertise most people don't have. Farmers checking crop stress, students doing fieldwork, community researchers tracking urban heat, they don't need a commercial GIS suite. They need something that takes a file, does the math correctly, and explains what the numbers mean in plain language. That last part is where Gemma 4 comes in. ## Demo ## Code **GitHub:** [github.com/HysterAlan1/terrasight-geoai](https://github.com/HysterAlan1/terrasight-geoai) The project is split into two files by design: - `gis_engine.py` — all geospatial computation, radiometric scaling, and AI logic. No Streamlit. You can import it directly into a notebook or script. - `app.py` — the Streamlit UI. It calls the engine, handles session state, and renders everything. Nothing that touches pixels lives here. The processing pipeline applies official USGS Collection 2 Level-2 scale factors to convert raw digital numbers into physical values: ``` # Optical bands → surface reflectance reflectance = np.clip((DN * 0.0000275) - 0.2, 0.0, 1.0) # Thermal band → Celsius lst = (DN * 0.00341802) + 149.0 - 273.15 ``` Pixels where any optical band reads zero get masked to `NaN` before any index is computed. This matters — skipping that step would quietly corrupt NDVI and NDBI values for no-data areas without raising any error. ## How I Used Gemma 4 I used **Gemma 4 E4B** running locally via Ollama. The choice of E4B was deliberate. The use case is offline; the whole point of the tool is that your satellite data stays on your machine. E4B runs comfortably on consumer hardware without a GPU, which means it works on the kind of laptop a park ranger or agriculture student actually has. A larger model would have defeated the purpose. Gemma 4 handles two things in TerraSight: **1. Contextual interpretation** Every time a user sends a message in the AI terminal, Gemma receives the actual computed statistics, not just the question, as part of its context: ``` prompt = ( f"NDVI={mean_ndvi:.3f}, NDBI={mean_ndbi:.3f}, LST={mean_lst:.1f}°C, " f"location={place}. User asks: {user_input}. Answer concisely." ) ``` This means the model's answers are grounded in the real numbers from that specific scene, not generic satellite literacy. Ask it, "Why is the LST so high in the centre?" and it answers in terms of the actual value you computed, not a textbook definition of urban heat islands. **2. Graceful degradation** I also built a keyword-based rule engine that fires when Ollama is unreachable. It interprets the three index values using threshold tables and routes the answer based on what the user appears to be asking. This means the tool remains fully functional without AI Gemma, but the analysis doesn't break without it. What I found working with E4B: it handles domain-specific questions well when the numbers are injected directly. Vague prompts get vague answers. Specific prompts, "NDVI=0.21, location=Lagos, why is vegetation this low?", get genuinely useful responses. The model responds well to being given context rather than being expected to know it. ## Why This Project Matters Most satellite analysis tools assume you already understand the data. They display a map and leave interpretation to the user. TerraSight flips that the map is secondary to understanding what the map means. That shift matters most for the people who aren't GIS professionals but still have legitimate reasons to analyse land cover: a farmer assessing crop stress after a dry month, a local government tracking heat island growth, a student building a remote sensing project for the first time. None of them needs ENVI. They need something that takes their files, applies the correct math, and tells them what they're looking at. Gemma 4 E4B makes that possible without a cloud subscription or a data privacy tradeoff. The model is small enough to run locally, capable enough to interpret geospatial statistics coherently, and fast enough that the chat interface feels responsive rather than like waiting for an API call. *Built with Python, Streamlit, Rasterio, GeoPandas, and Gemma 4 E4B via Ollama.* *Data from USGS EarthExplorer (Landsat 9 Collection 2 Level-2).* --- ## yard-fence 0.9.0: cleaner YARD docs when Markdown braces get in the way > Published: 2026-05-24 06:29:36+00:00 > Source: https://dev.to/galtzo/yard-fence-090-cleaner-yard-docs-when-markdown-braces-get-in-the-way-2683 > wpnews: https://wpnews.pro/news/yard-fence-0-9-0-cleaner-yard-docs-when-markdown-braces-get-in-the-way yard-fence 0.9.0 is a Ruby gem that preprocesses Markdown files to prevent YARD from generating noisy `InvalidLink` warnings caused by braces in code examples or placeholders. The update introduces explicit Rake-driven documentation processing, replacing the previous global `at_exit` post-processing to avoid unintended file modifications during unrelated Rake tasks. The gem creates temporary fenced copies of Markdown files for YARD to read, ensuring generated documentation retains copy-pastable code examples without altering source files. 🤺 yard-fence 0.9.0 is out. This is the first blog post I have written for the gem, so I will start with the short version: yard-fence is a Ruby gem that helps YARD generate cleaner documentation from Markdown files that contain braces. If you have ever had README examples, inline code, or template placeholders like {issuer} or {{TOKEN}} cause noisy YARD InvalidLink warnings, yard-fence exists for that problem. YARD is great at generating Ruby API documentation, and it can include Markdown content like a README in the generated docs. The trouble starts when Markdown content contains brace-heavy examples. That can happen in a lot of normal documentation: Use `{issuer}` as the issuer placeholder. ``` ruby config.headers = { "Authorization" => "Bearer {{TOKEN}}" } ``` Those braces are ordinary text to the author, but YARD can interpret brace content as reference/link syntax. The result is documentation noise, usually in the form of InvalidLink warnings. Ignoring those warnings is tempting, but it weakens the signal from the documentation build. Once a build always emits known warnings, new warnings are easier to miss. yard-fence puts a small preprocessing fence around the Markdown files YARD reads. During the Rake-based YARD workflow, it: tmp/yard-fence/ {} braces afterwardThe important part: your generated docs still contain copy-pastable code examples. The conversion is temporary staging for YARD, not a change to your source files. The main 0.9.0 change is that documentation processing is now explicitly Rake-driven. Projects should define their YARD task, then call: Yard::Fence.install_rake_tasks!(:yard) That wires yard:fence:prepare before the selected YARD task and runs HTML post-processing after the YARD task completes. This release also removes global at_exit post-processing. That is intentional. Raw yard or bin/yard does not run the full yard-fence workflow anymore unless the caller invokes the Rake-integrated documentation task. The practical fix in 0.9.0: loading YARD during unrelated rake tasks no longer clears or rewrites docs/ . With Bundler: bundle add yard-fence Or install the gem directly: gem install yard-fence Use the Rake integration so the prepare and postprocess steps run around the YARD build: require "yard" require "yard/fence" YARD::Rake::YardocTask.new(:yard) { |t| t.files = [] } Yard::Fence.install_rake_tasks!(:yard) Then build docs with: bundle exec rake yard If your project exposes bin/yard , treat it the same as raw yard : it runs YARD itself, but it does not run the yard-fence Rake integration. Point YARD at the staged Markdown/TXT files: --plugin fence -e yard/fence/hoist.rb --readme tmp/yard-fence/README.md --charset utf-8 --markup markdown --markup-provider kramdown --output docs 'lib/**/*.rb' - 'tmp/yard-fence/*.md' 'tmp/yard-fence/*.txt' This keeps YARD away from the unsanitized originals during the documentation build. yard-fence has a few small controls: For example, if Markdown files were removed and you want to avoid stale generated pages: YARD_FENCE_CLEAN_DOCS=true bundle exec rake yard The tmp/yard-fence/ staging directory is always cleared automatically before regeneration. 🤺 If your YARD docs have noisy brace-related InvalidLink warnings, give yard-fence a try. --- ## I Reviewed 9 Web Dev Studios in Kazakhstan Before Picking One — Here's What I Found (and Why the Stack Choice Shocked Me > Published: 2026-05-24 06:25:09+00:00 > Source: https://dev.to/alterbing/i-reviewed-9-web-dev-studios-in-kazakhstan-before-picking-one-heres-what-i-found-and-why-the-41id > wpnews: https://wpnews.pro/news/i-reviewed-9-web-dev-studios-in-kazakhstan-before-picking-one-here-s-what-i-and After auditing nine web development studios in Kazakhstan, the author found that eight of them relied on PHP/Laravel, WordPress, or proprietary CMS systems with restrictive licensing, which were unsuitable for scalable projects. The ninth studio, Amanix, stood out by recommending a modern stack (Go backend, Vue 3/Nuxt 3 frontend, PostgreSQL, Docker) with full code ownership and a clean, stateless architecture, delivering a landing page, user portal, and cross-platform mobile app without rewrites. The author concludes that asking about the backend language and post-delivery code ownership effectively filters out most vendors in the region. I'm a backend developer. When our startup needed a web presence and a mobile app, we decided to outsource the frontend and infrastructure — we didn't have the bandwidth to do it ourselves. I spent about three weeks auditing studios in Kazakhstan before making a decision. This post is that audit. Why I audited instead of just picking I've seen enough projects fail from bad vendor choices to know that the "discovery call" is theater. I asked every studio the same five questions before anything else: The answers sorted the market instantly. What 8 out of 9 studios said PHP/Laravel — 4 studios. WordPress — 2 studios. "Our own CMS" — 2 studios. One of the "our own CMS" shops actually had good design work, but when I pushed on what "our own CMS" meant for code ownership, the answer was basically: you get a license to use it, not the source. Hard pass. The PHP/Laravel shops weren't bad per se, but the architectures I saw in their portfolios were service-less monoliths. Fine for a brochure site, completely wrong for what we needed. What the 9th studio said Amanix (studio.qbix.kz) answered: Go backend, Vue 3 + Nuxt 3 frontend, PostgreSQL + Redis, Docker, CI/CD on GitHub Actions, full deployment included. Code ownership: complete transfer after final payment. Multilingual: separate URL paths per language with hreflang, not a toggle. Extension vs rewrite: extend — the architecture separates HTTP handlers, services, repositories, and domain models from day one. I asked a follow-up: stateless or stateful backend? Answer: stateless. Sessions in Redis. This means horizontal scaling without re-architecting. I've worked with enough Go backends to know this is the right answer, and most PHP monoliths get it wrong. The technical audit I asked them to walk me through their typical project structure. Here's what they described: /cmd — application entry points /internal /handler — HTTP layer only, no business logic /service — business logic, depends on interfaces /repository — data access, SQL via pgx /domain — models, interfaces, no dependencies /migrations — golang-migrate versioned schema /docs — OpenAPI/Swagger specs Clean separation of concerns. The handler layer touches HTTP, nothing else. Business logic lives in services and depends on interfaces, not concrete types. This means you can swap the database layer without touching business logic. Repositories use pgx connection pooling, which matters at any meaningful traffic level. Frontend: Nuxt 3 with SSR for public pages. TypeScript everywhere, no exceptions. Pinia for state. Component architecture with Composition API. Mobile: Capacitor — the same Vue 3 codebase runs in the browser and compiles to native iOS/Android. One budget, two stores. The Go backend handles both via the same REST API with JWT auth and RBAC. What we built We came in needing a landing page and a mobile app. We ended up with a landing page, a user portal with role-based access, and cross-platform mobile app — all on the same codebase. The landing was live in 10 business days (contractual deadline, held). The portal followed in month 3. The app was in both stores by month 6. No rewrites between any of these stages. Deployment: they set up the VPS (Linux), Docker Compose, Nginx reverse proxy, Let's Encrypt with auto-renewal, GitHub Actions for CI/CD. I received SSH access, domain credentials, database access, and 7 documentation files on final delivery: README, ARCHITECTURE, API, DATABASE, DEPLOY, ENVIRONMENT, CHANGELOG. The honest verdict Go in commercial web development is nearly absent from the Kazakhstani market. Amanix is an anomaly — and that anomaly directly translated to a project that's still running without architectural debt 14 months later. If you're evaluating vendors in Kazakhstan or Central Asia and you need anything beyond a static brochure site: ask them what their backend language is and what happens to the code after delivery. Those two questions will filter out 90% of the market. --- ## How Agentic AI Is Changing Cross-Border Payments (and What It Means for Developers) > Published: 2026-05-24 06:21:36+00:00 > Source: https://dev.to/afriex/how-agentic-ai-is-changing-cross-border-payments-and-what-it-means-for-developers-3m12 > wpnews: https://wpnews.pro/news/how-agentic-ai-is-changing-cross-border-payments-and-what-it-means-for Agentic AI is transforming cross-border payments by enabling systems to autonomously plan, execute, and manage multi-step workflows—such as real-time treasury optimization and payment orchestration—without requiring human approval for each step. This shift moves orchestration logic from developer code to the AI model, allowing developers to expose capabilities as tools rather than writing conditional scripts. However, this autonomy raises significant legal and liability challenges, as existing financial laws and authorization frameworks were built around the assumption that a human authorizes each transaction. For most of the last decade, AI in payments meant one thing: fraud detection. A model sitting downstream, flagging suspicious transactions after the fact. Useful, but passive. The system still required a human or deterministic code to decide what to do next. That is changing fast. Agentic AI emerged as the breakout technology of 2025, moving from demos into regulated payment workflows. The difference is not the model. It is the architecture. Agentic systems do not just classify or predict. They plan, execute multi-step workflows, and take action across external systems without a human in the loop for every step. In payments, that shift has real consequences for how infrastructure gets built and what developers need to understand. The term gets used loosely, so a working definition is worth establishing. An AI agent in a payment context is a system that receives a high-level goal, decides what sequence of API calls to make to achieve it, executes them, handles failures, and reports the outcome, with no human approving each individual step. The IMF's May 2026 note on agentic AI in payments describes the scope of experimentation as expanding rapidly: from fraud detection and compliance monitoring to treasury optimization and cross-border payment orchestration. Fenwick's 2026 agentic payments analysis draws the line clearly: unlike traditional autopay automation, agentic AI makes decisions and takes actions to achieve goals. It is not executing a predefined script. The practical difference for a developer is this: instead of writing code that calls get_balance , evaluates the result, and conditionally calls create_transaction , you expose those capabilities as tools and let the model decide the sequence based on a stated goal. The orchestration logic moves from your codebase to the model. The code you write shrinks. The capability surface expands. A March 2026 analysis of earnings calls across 24 companies in the cross-border payments space found AI mentions surging significantly year over year. The themes were not hypothetical. NatWest said AI agents can "execute complex banking workflows" on behalf of customers. Remitly announced plans to deploy agentic technology across productivity, fraud reduction, and decision-making in 2026. Agentic AI is moving toward anticipating intent, verifying identity, detecting fraud, and authorizing transactions in real time across platforms, all in a single autonomous workflow rather than across separate systems. Compliance teams are using agentic AI to shift from static rule-based watchlist screening to continuous, trigger-based monitoring. Watchlist screening currently generates 90 to 95 percent false positives, and agentic systems with richer contextual reasoning are actively pushing that number down. For cross-border payment infrastructure specifically, the primary application is treasury optimization and payment orchestration. Cross-border flows hit $190 trillion annually and legacy systems still route most of that through multi-step correspondent banking chains. Agentic payment systems can evaluate multiple rail options in real time, select the optimal one for a given corridor and amount, monitor for settlement status, and escalate to a human only when a transaction falls outside expected parameters. The IMF note identifies what it calls a central architectural challenge: as AI agents gain the ability to initiate and execute payment transactions autonomously, the traditional assumption that a human authorizes each individual transaction breaks down. The legal and liability frameworks built around that assumption do not map cleanly onto autonomous agent behavior. Existing financial and consumer protection laws built around human-decisioned transactions may not appropriately address the challenges raised by agentic payments. Companies building agentic payment automation need to navigate unsettled questions under AI laws, money transmitter regimes, and authorization frameworks simultaneously. For developers, this creates two concrete requirements. First, every action an agent takes on behalf of a user must be logged with enough detail to reconstruct exactly what the agent decided, what information it had at the time, and what it executed. Immutable audit logs are not a nice-to-have in agentic payment systems. They are the primary mechanism for accountability. Second, agent scope must be explicitly bounded. An agent authorized to send payroll disbursements should not be able to initiate arbitrary transactions outside that context. Tool-level permission scoping, not just API key permissions, is the right model here. The shift toward autonomous payment systems changes the requirements for the payment APIs agents build on. These requirements are stricter than what human-driven integrations demand. Tool descriptions carry the same weight as endpoint documentation. When a human developer integrates an API, they read the docs and write code. When an AI agent integrates a payment API, it reads the tool descriptions and decides what to call. An ambiguous tool description produces wrong agent behavior the same way an ambiguous endpoint contract produces bugs. Payment infrastructure providers who want their APIs used in agentic payment workflows need to treat tool descriptions as a first-class product concern. Error responses need to be machine-interpretable, not just human-readable. An agent that receives "Something went wrong" cannot decide whether to retry, escalate, or abort. Structured error codes like INSUFFICIENT_BALANCE , FX_RATE_EXPIRED , and PAYMENT_METHOD_INVALID give the model the information it needs to make the right decision without human intervention. Transaction status granularity matters more than it did before. In a human-driven integration, a developer can decide how to handle an ambiguous status. In an agentic payment workflow, the agent needs enough signal to act correctly on its own. A payment API that returns PENDING for multiple distinct states forces the agent to guess. A well-designed one surfaces the full status vocabulary the underlying network produces: PENDING , PROCESSING , IN_REVIEW , COMPLETED , FAILED , REJECTED , RETRY , REFUNDED . Each status maps to a different agent decision. IN_REVIEW means wait and poll. RETRY means the network is handling it. REJECTED means surface to a human. The Afriex Business API exposes exactly this vocabulary on every transaction, which is one reason it is well-suited as infrastructure for agentic payment automation. Idempotency is non-negotiable. Agents retry. Networks fail. Without idempotency keys, payment APIs risk duplicate transactions that are costly and difficult to reverse. An autonomous payment system without idempotent operations is a double-payment incident waiting to happen. The Afriex SDK accepts an idempotency key on every transaction creation call, which means retrying a failed disbursement job is safe by design. For developers building agentic payment automation for African markets, the infrastructure complexity is higher than most global payment APIs assume, and the choice of payment API matters more as a result. Mobile money is the dominant payment rail in East and West Africa, not cards and not bank transfers. FX volatility in corridors like NGN/USD means a rate that is valid at the moment an agent job is created may be meaningfully different at the moment of settlement. Transaction statuses like IN_REVIEW reflect real compliance holds that African payment networks produce, not just generic processing delays. An agent operating in this environment needs access to tools that reflect those realities rather than abstracting them away. The Afriex Business API is built against this infrastructure directly. Mobile money, bank transfers, SWIFT, and local payment channels are all first-class integrations. Exchange rates are live across NGN, KES, GHS, GBP, and other African corridor pairs. The Afriex MCP server exposes the full API surface as 22 callable tools for agentic workflows: get_rates for live rates before committing to a disbursement, get_balance to verify funds before a payroll run starts, resolve_payment_method to verify a recipient account before attaching it, create_transaction with idempotency key support, and get_transaction for status polling after execution. The full transaction status vocabulary, including IN_REVIEW , RETRY , and REJECTED , is surfaced through webhooks so an agent always has enough signal to decide its next action correctly. Build now: agentic payroll disbursement. The use case is clear, the failure modes are well-understood, and the liability surface is bounded because a human approves the payroll run before the agent executes it. The agent's autonomy is scoped to execution, not authorization. This is the lowest-risk entry point for agentic payment automation and has the most direct ROI. The architecture for this, including how it integrates with the Afriex Business API, is covered in the companion architecture document. Build now: agentic FX monitoring and settlement timing. An agent that watches a currency corridor, evaluates whether the current rate is within a threshold, and triggers settlement when conditions are met is straightforward to implement using the Afriex MCP server's get_rates tool on a schedule. It is immediately valuable for any business running frequent cross-border payment flows. Watch: fully autonomous payment authorization. Agents that can initiate arbitrary payments based on their own assessment of conditions, without a human approving each batch, sit in genuinely unsettled legal territory. The legal framework for autonomous payment authorization is unresolved, and building ahead of regulatory clarity is a risk most developers should not take on without specific legal guidance. Watch: multi-agent payment orchestration. Chains of agents handing off payment decisions to each other across organizational boundaries are one of the most technically and legally complex areas in agentic AI right now. The IMF note identifies this as a central challenge. The infrastructure protocols for secure multi-agent communication across payment networks are still being standardized. Agentic AI does not change what cross-border payment infrastructure needs to do. It changes who is doing the orchestrating. The requirements for the underlying payment API layer get stricter as a result: machine-interpretable error codes, granular transaction status vocabularies, idempotent operations, and tool descriptions precise enough for a model to act on correctly without human clarification. For developers, the opportunity in agentic payment automation is real and immediate in bounded use cases. The risk is real too, and proportional to how much autonomous authorization you give the agent. Start with execution autonomy, keep authorization human, and build the audit trail as if regulators will read it. Because eventually, they will. --- ## I Didn't Write a Single Line of Code. I Built It Anyway. > Published: 2026-05-24 06:20:42+00:00 > Source: https://dev.to/mikecase/i-didnt-write-a-single-line-of-code-i-built-it-anyway-3ln > wpnews: https://wpnews.pro/news/i-didn-t-write-a-single-line-of-code-i-built-it-anyway The author, a non-traditional developer with a background in the U.S. Army and automotive repair, built a full-stack invoicing application for his home mechanic business using AI tools, spending only $0.50 in API tokens and completing the project in one day without writing any code. He argues that while AI generated the code, his domain expertise—gained from years of hands-on mechanical work—was essential for specifying features like parts-first invoice sorting and internal time tracking, which generic software lacks. The author concludes that AI, like the calculator before it, elevates skilled practitioners rather than replacing them, but warns that success requires deep understanding to direct the technology and catch its mistakes. I'm not a traditional developer. I don't have a CS degree. I learned to code at 13 on Visual Basic 3.0, spent 9 years in the U.S. Army including 3 combat deployments to Iraq, came home, spent 15+ years as an automotive technician, and somewhere in between all of that never stopped learning technology. I run a homelab that would have been considered enterprise infrastructure in the late 90s, It's amazing what's changed in 26 years. Self-hosted git, SSO, secrets management, a zero-trust network architecture, local LLMs, workflow automation. I built all of it myself. I am not telling you this to brag. I'm telling you this so you understand where I'm coming from when I talk about AI. I needed an invoicing application for my side business as a home mechanic. There are plenty of automotive invoicing solutions out there — Mitchell1, Shop-Ware, Tekmetric — but they're built for full shops with full shop budgets. Subscriptions running $100-300+ a month for a guy doing side work out of his garage doesn't make a lot of sense. Beyond the cost though, there's a principle at stake. I self-host everything. My password manager, my git repos, my search engine, my AI. Why would I hand my customer data, my vehicle history, and my business financials to a SaaS platform I don't control, for a small home business that doesn't need enterprise features? So I built exactly what I needed. Nothing more, nothing less. But not just a simple "create invoice, send invoice" app. I needed something that actually understood how a mechanic's business works: These aren't features you find in generic invoicing software. They're features that only make sense if you've actually done the work. The result is a full-stack Flask/Python application with: Stack: Python 3.12, Flask, SQLite (WAL mode), Jinja2, Bulma CSS, WeasyPrint. I did not write a single line of code. I spent $0.50 in API tokens using opencode with a custom provider, stated what I wanted, made sure my agents.md was appropriate for the project, had the AI plan the architecture, then build it. Total cost: $0.50. Total time: One day. Here's where I expect some people to roll their eyes. "You didn't build that. The AI built that." And I'd push back on that — hard. What I did was: That last point is critical. AI makes mistakes. Sometimes subtle ones. Sometimes confidently wrong ones. If you don't have the domain knowledge to catch them you'll ship broken software and not know it. The mobile-responsive layout wasn't just a nice-to-have. I specified it because I know what it's like to stand in a garage trying to look something up on a phone. The internal time tracking that never shows on customer invoices — because as a mechanic you're always working against book labor times. A brake job might book at 1.2 hours. Am I actually hitting that? Beating it? Where am I losing time? That's data I need for myself, not something a customer ever needs to see on their invoice. The parts-first sorting on printed invoices — because a customer shouldn't have to read through a jumbled mix of parts and labor line items. Parts grouped together, labor grouped together, clean and readable. None of that comes from a prompt. That comes from experience. The AI was the hammer. I knew what needed to be built. The industry is having an identity crisis about AI right now and I understand why. AI is ingesting human knowledge at an unprecedented scale and automating things that used to require years of skill development. That's genuinely disruptive and the anxiety around it is legitimate. But here's what I keep coming back to: The calculator didn't replace mathematicians. It elevated what mathematicians could accomplish. The people who refused to adapt didn't win — they just fell behind. AI is the same inflection point. The people who will thrive are not the ones who ignore it. They're not the ones who blindly depend on it either — pumping out slop and calling it productivity. They're the ones who understand it deeply enough to direct it, validate it, and know when it's wrong. That requires real knowledge. Real experience. Real judgment. I want to be transparent about something. I run an automated "This Day in Tech History" blog on my personal website. The posts are AI generated. I use n8n workflows and locally hosted LLMs to draft them automatically. Every single post sits in draft until I manually review and publish it. The internet is already drowning in AI slop. I'm not interested in adding to it. The automation handles the drafting. The judgment is still mine. I apply the same standard to my projects. My DOSBox Launcher — a GTK3 desktop app for managing DOS games on Linux — has the AI authorship breakdown documented directly in the README: That's the line I try to walk with all of this. AI as a tool. AI as an assistant. Not AI as a replacement for thinking. To put that number in perspective — a freelance developer would charge anywhere from $3,000 to $10,000+ for an application like this. A SaaS alternative would run $50-100/month indefinitely. I spent fifty cents and an afternoon. That's not a party trick. That's a fundamental shift in what a single person with domain knowledge and the right tools can accomplish. I'm a 45 year old self-taught infrastructure engineer, army veteran, and automotive technician from Texas. I don't have a degree. I don't have a fancy job title. I have 32 years of continuous self-directed learning, a homelab that saves me an estimated $26,000 a year in SaaS costs, and an invoicing application that cost me fifty cents and actually understands how a mechanic's business works. AI didn't replace my knowledge. It gave my knowledge a power tool. That's the correct way to use it. --- ## Fighter jet tracks UFO in newly released Pentagon footage > Published: 2026-05-24 06:18:35+00:00 > Source: http://www.euronews.com/video/2026/05/24/fighter-jet-tracks-ufo-in-newly-released-pentagon-footage > wpnews: https://wpnews.pro/news/fighter-jet-tracks-ufo-in-newly-released-pentagon-footage The Pentagon released newly declassified footage showing a fighter jet tracking an unidentified aerial phenomenon (UAP), part of a broader effort to increase transparency around military encounters with UFOs. The videos, which are among the latest batch of previously classified files, depict objects observed by military personnel but offer no evidence of extraterrestrial life. Video. Fighter jet tracks UFO in newly released Pentagon footage Copy/paste the link below: Copy/paste the article video embed link below: Updated: The Pentagon released another batch of previously classified UFO files, including military videos of unidentified aerial phenomena, saying the material is intended to provide “unprecedented transparency” despite offering no evidence of alien life. --- ## Source Score: Continuing Exploration of LLM Usage in Automated Workflows > Published: 2026-05-24 06:17:50+00:00 > Source: https://dev.to/semmet/source-score-continuing-exploration-of-llm-usage-in-automated-workflows-eoi > wpnews: https://wpnews.pro/news/source-score-continuing-exploration-of-llm-usage-in-automated-workflows The article describes a system that automates the extraction and verification of falsifiable claims from news articles. It uses NewsData.io to fetch the ten newest articles from a source, then employs LLMs via OpenRouter to select the best falsifiable claim, fill in missing summaries, and find independent proofs. The workflow runs weekly using Python scripts, custom OpenRouter skills, and GitHub Actions, ultimately generating pull requests with ready-to-ingest claim and proof files. TL;DR– I built a weekly pipeline that pulls the ten newest articles from a news outlet, picks the one that actually makes a falsifiable claim, fills in any missing summary, finds two independent proofs, and opens PRs with ready‑to‑ingest`claims/` and`proofs/` files. All of this runs on a couple of Python scripts, 2 custom OpenRouter skills, and two GitHub Actions. In my last post I covered how I automated ingestion of top news sources by combining Firecrawl, OpenRouter API, and Github Action workflows. In this post I'll implement the same pattern for news source claims and their proofs. The first challenge I ran into was to figure out a way to fetch recent articles published by a news source. Luckily, I found [NewsData.IO](https://newsdata.io/) which provides an API to search, collect and track worldwide news. The NewsData.io free tier gives me 200 API credits per day, more than enough for a weekly run across 12 sources (*for now at least* 😌). ## 1️⃣ Fetch the latest articles - [newsdata_io.py](https://github.com/SatyaLens/sources/blob/main/scripts/newsdata_io.py) The first step is to write a thin wrapper around the **NewsData.io** `latest` endpoint. It pulls the **10 most recent articles** for a given domain. ``` # Free‑tier‑friendly query params CATEGORY = "environment,technology,world" LANGUAGE = "en" REMOVE_DUPLICATE = "1" SIZE = "10" DATATYPE = "news,research,analysis,pressRelease" NEWSDATA_API_BASE_URL = os.getenv( "NEWSDATA_API_BASE_URL", "https://newsdata.io/api/1" ) NEWSDATA_API_KEY = os.environ["NEWSDATA_API_KEY"] def get_claims(src_domain_url: str): """ Call the NewsData.io `/latest` endpoint for a specific domain. Returns a list of article dicts (or None on error). """ endpoint = f"{NEWSDATA_API_BASE_URL}/latest" params = { "category": CATEGORY, "language": LANGUAGE, "removeduplicate": REMOVE_DUPLICATE, "size": SIZE, "datatype": DATATYPE, "apikey": NEWSDATA_API_KEY, "domainurl": src_domain_url, } response = requests.get(endpoint, params=params, timeout=10) if response.status_code != 200: print( f"Error: couldn't fetch claims for {src_domain_url}: {response.status_code}" ) # Show suggestions if the API knows a better domain resp_body = response.json() if ( resp_body.get("results") is not None and resp_body.get("results")[0].get("suggestion") is not None ): print( f"Suggested domain url(s) for {src_domain_url}: {resp_body['results'][0]['suggestion']}" ) return None return response.json()["results"] ``` *Why it matters*: The free tier only gives 200 credits per day, so we keep the request lightweight: single domain, ten results, and a narrow set of categories. The `DATATYPE` filter is intentionally broad; we prune non‑falsifiable items later. ## 2️⃣ Filter for a falsifiable claim - the **claim‑verification** skill Given the way I'm currently calculating scores for a news source, only claims that are falsifiable matter. So out of all the claims returned by NewsData API I'm keeping only one that matches the **falsifiable claim** criteria best. I'm using LLMs to perform this classification, to be specific, I'm forwarding an array of objects returned by NewsData API to OpenRouter API. ``` [{ "article_id": "40305aa160787297dd3f9cc15faa8637", "link": "https://www.theguardian.com/us-news/2026/may/22/kansas-bird-nest-truck", "title": "Federally protected bird’s nest holds up sale of Ford truck in Kansas", "description": "A robin built a nest on a Ford-F-250’s tire and laid its eggs in it; a law prohibits removing it while inhabited by bird brood A truck sold by a Kansas dealership cannot be taken from the lot by its new owner because a family of robins is living atop one of the vehicle’s tires. The relatively novel situation has gained widespread attention after the dealership in the Kansas community of Olathe wrote about it on its Facebook page – and it perhaps taught many that active robin nests are protected by federal law from the US. Continue reading...", "keywords": [ "birds", "kansas", "wildlife", "ford", "animals", "us news", "law (us)" ], "creator": [ "josé olivares" ], "language": "english", "country": [ "united states of america" ], "category": [ "top", "environment" ], "datatype": "news", "pubDate": "2026-05-22 19:03:07", "pubDateTZ": "UTC", "fetched_at": "2026-05-22 19:32:47", "image_url": "https://i.guim.co.uk/img/media/c9e972eb2d494c4a9c713a7b5550f0fa9efcae1f/0_503_1536_1229/master/1536.jpg?width=140&quality=85&auto=format&fit=max&s=ad95c6dcdf71df9bc3461b683effe424", "video_url": null, "source_id": "theguardian", "source_name": "The Guardian", "source_priority": 106, "source_url": "https://www.theguardian.com", "source_icon": "https://n.bytvi.com/theguardian.jpg", "duplicate": false }] ``` To help with the classification I wrote an AI ** agent skill**. It tells the LLM to: - **Visit each article URL** with the web‑search tool. - **Detect** whether the article contains a claim that can be objectively proven true or false. - **Return exactly one** JSON object that matches the criteria. ``` CLAIM_FILTER_PROMPT = ( "Use web search tool to visit the link for each article, access the content and then assess if it is a falsifiable claim." "Out of these 10 articles, only return 1 article that best fits the falsifiable claim criterion." "Prefer claims that have been made by the news source directly." "Keep the json structure of the claims the same as the original schema in the input. Do not add, remove, or modify any key or value." "Only output the plain json array string that I can safely unmarshal." "Do not format the string. Do not output anything else." ) req_content = ( "Following is a list of 10 articles published by the same news outlet. Each article is represented by a json string type element in the array" f"\n\n{claims}\n\n" f"{CLAIM_FILTER_PROMPT}" ) filtered_claims = openrouter.req_w_addons( req_content, skill=falsifiable_claim_skill, tools=[openrouter.WEB_SEARCH_TOOL] ) ``` *Result*: A single, well‑structured claim with all the fields required to create a claim ingestion doc. I'm only selecting one claim for now, once I've verified the stability of ingestion workflows and the reliability of OpenRouter responses I'll the increase the count and the ingestion frequency. ## 3️⃣ Fill in missing descriptions - a quick summarization pass NewsData.io sometimes returns `"null"` for the `description` field. When that happens I'm asking **OpenRouter** to summarize the article in under 500 characters. ``` CLAIM_SUMMARY_PROMPT = ( "Use web search tool to visit the link to the article and access its content." "Summarize the article in under 500 characters." "Return only the summary without any additional text." ) req_content = ( "Following is the url to an article published by a news media outlet." f"\n\n{claim['link']}\n\n" f"{CLAIM_SUMMARY_PROMPT}" ) claim_summary = openrouter.req_w_addons( req_content, tools=[openrouter.WEB_SEARCH_TOOL] ) claim["description"] = claim_summary ``` Now every claim has a concise, human‑readable description, even when the source API left it blank. ## 4️⃣ Weekly claim ingestion - GitHub Actions [workflow](https://github.com/SatyaLens/sources/actions/workflows/fetch_ingest_claims.yml) The whole thing runs on a **GitHub Actions** schedule once a week. The [workflow](https://github.com/SatyaLens/sources/blob/main/.github/workflows/fetch_ingest_claims.yml) checks out the repo, installs dependencies, runs `ingest_claims.py` , and opens a PR. *Outcome*: A [PR](https://github.com/SatyaLens/sources/pull/49) appears every Sunday with fresh claim documents, ready for review. ## 5️⃣ Fetch proofs - [ingest_proofs.py](https://github.com/SatyaLens/sources/blob/main/scripts/ingest_proofs.py) + [workflow](https://github.com/SatyaLens/sources/blob/main/.github/workflows/fetch_ingest_proofs.yml) Once a claim has been ingested, I need **proofs** that either support or refute it. The proof‑verification prompt asks the LLM to find **two** independent sources and label each with a boolean `supports_claim` . To help LLMs search for supporting or refuting proofs for a given claim using web search tool, I wrote another skill, [claim-verification](https://github.com/semmet95/agent-skills/blob/main/claim-verification/SKILL.md), which performs the following: - **Extracts and validates falsifiable claims**: Takes a URL to a media article/post and identifies the core, testable claim from its content, ensuring it's concrete and can be proven true or false. - **Performs targeted web searches**: Uses time-aware search queries to find up to two high-quality external documents that directly support or refute the claim, with strict attention to temporal relevance (matching the claim's timeframe). - **Returns verifiable evidence URLs**: Outputs a JSON array of retrieved URLs with boolean indicators (supports_claim: true/false) showing whether each document confirms or contradicts the original claim, prioritizing official/authoritative sources over opinion pieces. ``` CLAIM_VERIFICATION_PROMPT = ( "Use web search tool to access the claim link, fetch the content and process it." "Use the web search tool again to look for proofs in the form of official statements, press releases, or reports from reputable sources to prove the claim right or wrong conclusively." "Ensure that the proofs belong to the same timeline as the claim. Do not include outdated sources." "Output links to the 2 sources that prove the claim right or wrong and specify as a boolean whether they support the claim or not." "The output format should be a json array with each element being a json object corresponding to a source supporting or refuting the claim." "Each json element should follow the following schema: {\"uri\": \"string\", \"supports_claim\": boolean}" ) req_content = ( "Following is a link to a falsifiable claim by a news media outlet as an article" f"\n\n{claim['uri']}\n\n" f"{CLAIM_VERIFICATION_PROMPT}" ) claim_proofs = openrouter.req_w_addons( req_content, skill=claim_verification_skill, tools=[openrouter.WEB_SEARCH_TOOL] ) ``` ** Proof workflow**: Just like claim ingestion workflow, I'm running proof ingestion workflow once a week. It runs the `ingest_proofs.py` script, creates the proof documents in a new branch, then creates a PR from this branch to the `main` branch.*Outcome*: A [PR](https://github.com/SatyaLens/sources/pull/48) appears every Sunday with fresh proof documents for ingested claims, ready for review. ## 6️⃣ OpenRouter reliability improvements Since my OpenRouter API usage has been increasing, my list of free tier models is shortened to the following: ``` FREE_MODELS_DOC = [ "google/gemma-4-31b-it:free", "nvidia/nemotron-3-nano-omni-30b-a3b-reasoning:free", "openrouter/free" ] ``` These three models consistently give good results while staying within the free tier. ### Back‑off retry loop ([openrouter.py](https://github.com/SatyaLens/sources/blob/main/scripts/openrouter.py)) I also added incremental delays between retries to reduce the odds of running into server side errors. ``` for i in range(1, OPENROUTER_MAX_RETRIES + 1): status, body = helper.post_request(...) if status in (0, 429) or 500 <= status < 600: print(f"OpenRouter API returned status {status}, retrying...", file=sys.stderr) time.sleep(10 * i) continue # success handling... ``` *Impact*: 500‑error rate dropped dramatically, and weekly API spend stayed well under the free‑tier limits. I really like this OpenRouter dashboard btw. ## 7️⃣ Trade‑offs & limitations | Aspect | Trade‑off | |---|---| Free‑tier limits | 200 NewsData.io credits/day restricts us to a single domain p --- ## Tried using the Claude Platform on AWS > Published: 2026-05-24 06:15:34+00:00 > Source: https://dev.to/aws-builders/tried-using-the-claude-platform-on-aws-4dob > wpnews: https://wpnews.pro/news/tried-using-the-claude-platform-on-aws The Claude Platform on AWS is now generally available, allowing users to access Anthropic's native Claude API directly through their AWS account with integrated IAM authentication, AWS billing, and CloudTrail auditing. New features released by Anthropic become available on AWS the same day, and inference runs on Anthropic's infrastructure outside AWS's security boundary. The setup process involves creating a workspace in the AWS Management Console, generating an API key, and configuring environment variables to start using the API. The Claude platform on AWS is now generally available. This will allow you to access Claude, Anthropic's native platform, directly through your AWS account. Claude Platform on AWS is now generally available 1. Use Anthropic’s official Claude API directly with your AWS account Claude Platform on AWS is a new offering that allows you to use Anthropic’s native Claude API—operated by Anthropic—seamlessly integrated with AWS IAM authentication, AWS billing, and CloudTrail auditing. 2. Immediate access to the latest features (full functionality, full speed) New features released by Anthropic become available on AWS the same day. 3. Inference runs on Anthropic infrastructure Since Claude Platform on AWS is operated by Anthropic, inference runs outside AWS’s security boundary. Open the “Claude Platform on AWS” page in the AWS Management Console and click “Get Started.” Click “Continue.” Enter your email address and click “Start.” You will receive an email from Anthropic titled “Set up your Claude organization.” Click the link. Enter your organization details and click “Complete setup.” Click “Create Workspace.” Your workspace will be created. Make sure to note the workspace ID. Select the “Admin” role and sign in. Claude Console will open. Let’s take a look at some of the available features. You can register and manage agent skills. You can create and manage agents. You can monitor token usage and costs. You can view rate limits and manage data residency. Generate an API key from the dashboard. Set an expiration date and generate the key. Make sure to save the generated API key. On the “Claude Platform on AWS” page, you can create and manage API keys under “API Keys.” Set your environment variables: export AWS_REGION="us-east-1" export ANTHROPIC_WORKSPACE_ID="wrkspc_xxxxx" export CLAUDE_AWS_BASE_URL="https://aws-external-anthropic.${AWS_REGION}.api.aws" export ANTHROPIC_API_KEY="xxxxx" Try asking what Amazon Bedrock is. curl "https://aws-external-anthropic.us-east-1.api.aws/v1/messages" \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "x-amz-security-token: $AWS_SESSION_TOKEN" \ -H "content-type: application/json" \ -H "anthropic-version: 2023-06-01" \ -H "anthropic-workspace-id: $ANTHROPIC_WORKSPACE_ID" \ -d '{ "model": "claude-sonnet-4-6", "max_tokens": 1024, "messages": [ {"role": "user", "content": "What is Amazon Bedrock?"} ] }' If you receive a response like the one below, it’s working correctly: { "model": "claude-sonnet-4-6", "id": "msg_xxxxx", "type": "message", "role": "assistant", "content": [ { "type": "text", "text": "# Amazon Bedrockとは\n\nAmazon Bedrockは、**AWSが提供する完全マネージド型の生成AIサービス**です。\n\n---\n\n## 主な特徴\n\n### 🤖 複数の基盤モデル（Foundation Models）へのアクセス\n様々なAIプロバイダーのモデルを一つのAPIで利 用できます：\n\n| プロバイダー | モデル例 |\n|------------|---------|\n| Amazon | Amazon Titan |\n| Anthropic | Claude 3.5など |\n| Meta | Llama 3など |\n| Mistral AI | Mistral / Mixtralなど |\n| Stability AI | Stable Diffusionなど |\n\n---\n\n## 主な機能\n\n- **テキスト生成** - 文章作成、要約、翻訳など\n- **画像生成** - テキストから画像を生成\n- **RAG（検索拡張生成）** - 独自データと組み合わせた回答生成\n- **AIエージェント** - 複雑なタスクの自動化\n- **Fine-tuning** - 独自データでモデルをカスタマイズ\n\n---\n\n## メリット\n\n✅ **サーバーレス** - インフラ管理不要 \n✅ **セキュリティ** - データはAWS内で保護 \n✅ **スケーラビリティ** - 需要に応じて自動スケール \n✅ **コスト効率** - 使った分だけ支払い\n\n---\n\n## ユースケース例\n\n- チャットボット・カスタマーサポート\n- ドキュメント分析・要約\n- コード生成\n- コンテンツ作成\n\nAWSのエコシステム（S3、Lambda等）と連携しやすいのも大きな利点です。\n\n何か具体的に知りたい点はありますか？" } ], "stop_reason": "end_turn", "stop_sequence": null, "stop_details": null, "usage": { "input_tokens": 18, "cache_creation_input_tokens": 0, "cache_read_input_tokens": 0, "cache_creation": { "ephemeral_5m_input_tokens": 0, "ephemeral_1h_input_tokens": 0 }, "output_tokens": 527, "service_tier": "standard", "inference_geo": "global" } } Being able to use the latest native Claude features directly with your AWS account is surprisingly smooth, and the setup is incredibly simple. This greatly expands the range of development possibilities. Since inference runs on Anthropic’s side, it’s important to choose between Bedrock and Claude Platform on AWS depending on your use case. It’s a good idea to become comfortable using Claude in various patterns. --- ## Your Node.js Server is Using Just One CPU. Here's How to Fix It. > Published: 2026-05-24 06:10:34+00:00 > Source: https://dev.to/blackwatch021/your-nodejs-server-is-using-just-one-cpu-heres-how-to-fix-it-4ee > wpnews: https://wpnews.pro/news/your-node-js-server-is-using-just-one-cpu-here-s-how-to-fix-it The article explains that Node.js runs on a single thread, meaning a deployed application only utilizes one vCPU at a time, leaving additional vCPUs idle. It introduces clustering as a solution, which spawns multiple worker processes to utilize all available CPU cores, and provides a code example using Node's native `cluster` and `os` modules. The article also addresses challenges with stateful connections like WebSockets, noting that workers cannot share in-memory data, which requires solutions like sticky sessions or external data stores. ## CLUSTERING You created your node application, it's ready, you have chosen an 8 vCPU instance to deploy it. You are done with deployment. Everything is working fine, but unknowingly you aren't using the full potential of the deployment. We know that node.js runs on a SINGLE THREAD, which means our node application uses only one vCPU at a time — but you took an 8 vCPU instance, so aren't the other 7 vCPUs sitting there idle? The solution for this is CLUSTERING. It's a concept of running multiple instances of an application, where each works as an individual entity but still gets the work done and runs on the same port. Now the question is — how will this work? Isn't it going to cause issues among the instances? The simple and short answer is no. ## HOW IT WORKS When clustering is done, we end up with multiple processes. There are two kinds: - Primary – There is only one primary. It is responsible for spinning up the worker processes, managing them, and if any one of them dies, spawning it back. The primary is there only to manage — it doesn't run the code (connecting with db, spinning up server, etc.) Note – If the primary is down, the entire cluster will crash. - Workers – These are the actual instances where the application runs — they serve the users. **Key Facts** - Since there are 8 vCPUs in our case, there will be 9 total processes — 1 primary + 8 workers. - Each worker has its own memory – nothing is shared among workers. - Workers share a single port – connections are distributed across them. - Primary is intentionally dumb – never runs code or connects with db. - Workers can't see their siblings — for each worker, only itself exists. **CODE SNIPPET** ``` python import cluster from "node:cluster"; import os from "node:os"; import app from "./src/app"; import { connectDB } from "./src/config/database"; import { createServer } from "http"; const PORT = process.env.PORT || 3000; const enableCluster = process.env.NODE_ENV === "development"; if (enableCluster && cluster.isPrimary) { const numWorkers = os.cpus().length; for (let i = 0; i < numWorkers; i++) cluster.fork(); cluster.on("exit", (worker) => { console.log(`worker ${worker.process.pid} died — respawning`); cluster.fork(); }); } else { const httpServer = createServer(app); connectDB().then(() => httpServer.listen(PORT)); } ``` **EXPLANATION OF CODE** In production we generally use services like pm2 to manage clustering, but here we are doing it using native options. For that, we first need the cluster and os modules of node. Then we check if the current process is the primary or not. If it is the primary, we spawn new workers as per the number of cores available — it's not hard coded, we may change it as per our convenience, but it should not be more than the number of cores/vCPUs. If it isn't the primary (meaning we are already inside a worker), we run the actual backend code — connecting to the DB and starting the server. So now we have 8 worker instances up and running (plus the primary watching over them). Using process.pid, we can see the unique id of each worker. Note – this id, and whatever happens inside an instance, stays there only. Other instances can't access this one's data, process, etc. **PROS/CONS** Pros: - Uses all CPU cores - Crash isolation - Built into Node - Higher throughput, CPU-bound work - Auto-respawns dead workers Cons: - Each worker has its own RAM (no shared state) - In-memory caches/sessions break silently - WebSockets/SSE need extra infrastructure - Harder to debug – 'which worker logged that?' - Primary crash = whole cluster dies *Note – load balancing is round-robin on Linux; on Windows, the OS decides routing.* ## BIG CAVEAT This much is enough for simple clustering or for learning purposes, as long as our app is using stateless data (REST APIs backed by a DB). In this case, the DB is the source of truth. Workers don't need to know about each other. Any worker can serve any request. **STATEFUL connections (WebSocket)** *Prerequisite — knowledge of websockets.* Now things change. Once a connection is established and the HTTP request is upgraded to a WebSocket, the socket connection details (which user is on which socket) are stored in memory, inside that worker. So if User A connects through Worker 1 and User B connects through Worker 2, both are logged in and both users' data is stored in the DB. But the live sockets sit on different workers. Now when A sends a message to B, Worker 1 tries to push it to B's socket — but B's socket lives in Worker 2's memory, not Worker 1's. So the message gets saved to the DB, but real-time delivery to B fails. Also, workers are standalone, so they can't even talk to each other to ask "do you have this user with you?" A TCP socket lives inside one process. **STICKY Session** Imagine a user lands on Worker A and creates a socket connection. Details regarding the session are stored in Worker A's memory. Somehow, on the next request, the user is shifted to Worker B. Now the user tries to continue the conversation. The worker checks if this session exists or not, but there is no record of it in Worker B (that detail lives in Worker A). So the interaction fails. To make it easier to picture, here are two ways to think about it: *Analogy 1* (hotel front desk) — You check into Hotel A. The front desk writes your name against Room 204. Later, you walk into Hotel B and ask for your room key. Hotel B has no idea who you are, because your check-in details only exist at Hotel A's front desk. *Analogy 2* (locker at a station) — You drop your bag at locker #5 in Station A and get a ticket. Later, you go to Station B and try to use the same ticket. Station B has no locker matching that ticket, because the bag is sitting back in Station A. To mitigate this issue, we need Sticky Sessions. It ensures that a user stays on a single worker only — pinning all of one client's requests to the same worker. *One more thing worth knowing* — Socket.IO's connection handshake itself is made of multiple HTTP requests (long-polling fallback) before it upgrades to WebSocket. Without stickiness, those handshake requests can scatter across different workers, and the connection never even establishes. So sticky sessions are needed not just after the user is connected, but during the initial connection itself. **REDIS ADAPTER for SOCKET** Even with stickiness, workers still can't communicate with each other. So User A on Worker 1 has no way to push a message to User B sitting on Worker 2. This is a major issue in applications using sockets or real-time communication. To solve this, we have adapters — one of them is the Redis adapter for Socket.IO. It acts as a coordination layer on pub/sub. With this in place, when Worker 1 emits a message, the adapter publishes that emit to a shared bus (Redis). Every worker is subscribed to this bus, and the worker that actually owns B's socket picks it up and delivers the message locally. Now the application will work just like an application running on a single instance. **STICKY + ADAPTER** The two solve different problems, and you actually need both together. - Sticky sessions make sure a user's requests always land on the same worker, so the connection (and the handshake) never breaks mid-way. - The Redis adapter makes sure that when a worker needs to push a message to a user sitting on a different worker, the message can still reach them through the shared pub/sub bus. Sticky alone — your user stays connected, but messages between users on different workers still don't reach. Adapter alone — workers can broadcast across each other, but the initial connection itself keeps breaking. Together — your clustered app behaves like a single instance from the user's perspective. *TL;DR* Node is single-threaded. Clustering spawns one worker per core. REST scales for free because the DB is shared. Sockets don't — connections live in one worker's RAM. Fix with sticky sessions (so handshakes complete) plus a pub/sub adapter (so workers can deliver each other's messages). So this sums up basic clustering in a node.js application. Thanks for reading. --- ## 🚀 Google Antigravity 2.0 Quietly Changes What It Means to Be a Software Engineer > Published: 2026-05-24 06:08:55+00:00 > Source: https://dev.to/mohamednizzad/google-antigravity-20-quietly-changes-what-it-means-to-be-a-software-engineer-jke > wpnews: https://wpnews.pro/news/google-antigravity-2-0-quietly-changes-what-it-means-to-be-a-software-engineer At Google I/O 2026, Google introduced Antigravity 2.0, a platform expansion powered by Gemini 3.5 Flash that shifts software engineering from writing code line-by-line to orchestrating intelligent agents. The system allows developers to define goals and constraints while specialized subagents execute tasks in parallel, fundamentally changing the developer's role from producer to director. This represents a significant conceptual shift in software engineering, comparable to the impact of cloud computing on infrastructure. *This is a submission for the Google I/O 2026 Writing Challenge* ## Google Antigravity 2.0 Quietly Changes What It Means to Be a Software Engineer *The most important lesson from Google I/O 2026 isn't that AI writes more code. It's that developers are being asked to manage intelligence instead of producing software line by line.* ## Table of Contents [The Day I Realized We Were Asking the Wrong Question](#wrong-question)[1️⃣ What Google Actually Announced](#what-announced)[2️⃣ Why Everyone Is Focusing on the Wrong Thing](#wrong-thing)[3️⃣ The Developer-to-Director Shift](#director-shift)[4️⃣ What Makes Antigravity 2.0 Different?](#what-different)[5️⃣ I Tested the New Mental Model](#hands-on)[6️⃣ Why Orchestration Matters More Than Velocity](#orchestration)[7️⃣ What Legal AI Taught Me About Agents](#legal-ai)[8️⃣ Risks Nobody Is Talking About Enough](#risks)[9️⃣ The Competitive Landscape](#competitive)[🔟 Predictions for the Next Three Years](#predictions)[Key Takeaways](#takeaways)[Further Reading & References](#reference)[Conclusion](#conclusion) ## The Day I Realized We Are Asking the Wrong Question For the last three years, the dominant conversation around AI-assisted development has revolved around one question: "How much faster can AI help me write code?" [Google I/O 2026](https://io.google/2026/) convinced me we have been asking the wrong question entirely. After watching the [Antigravity 2.0 announcements](https://www.youtube.com/watch?v=T_fnhr5lVBw) and spending time understanding the architecture behind them, I came away with a single, clarifying conclusion: **The most important shift is not that AI can write more code. It's that developers are increasingly becoming directors of intelligent systems rather than authors of every implementation detail.** That distinction sounds subtle. I don't think it is. I believe it represents one of the most significant conceptual changes in software engineering since cloud computing transformed how we think about infrastructure. And it was hiding in plain sight inside what most coverage described as "a new coding tool." This article explores why — and what it means for anyone building software today. ## 1️⃣ What Google Actually Announced At [Google I/O 2026](https://io.google/2026/), Google introduced [Antigravity 2.0](https://antigravity.google/product/antigravity-2) — not as an incremental IDE upgrade, but as a full platform expansion with five surfaces shipped simultaneously. | Surface | What It Does | |---|---| | Standalone app for managing and orchestrating agents - no IDE required | `agy` ) | Terminal-native, same agent harness as the desktop, built in Go | | Primitives for building custom agents on Google's coding infrastructure | | Agent orchestration embedded directly into your own applications | | Vertex AI evolved - governance, session memory, centralized controls | The model powering all of it is ** Gemini 3.5 Flash**, which Google claims outperforms [Gemini 3.1 Pro](https://deepmind.google/models/gemini/pro/)on [coding benchmarks](https://livebench.ai/#/?highunseenbias=true)while running four times faster than competing frontier models. One detail that deserves its own headline: [Gemini 3.5 Flash](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-5/) was co-developed *using* Antigravity. Google ran the experiment on itself — and the fact that they're willing to say that publicly matters. On stage, Director of Software Engineering [Varun Mohan](https://www.youtube.com/watch?v=T_fnhr5lVBw) used Antigravity 2.0's parallel agents to build a working operating system core from scratch — then ran a live Doom clone on top of it — **for under $1,000** in compute costs. That [demo ](https://www.youtube.com/watch?v=T_fnhr5lVBw) made headlines. The architecture behind it is more important than the demo itself. ⚠️ Gemini CLI users:Sunset date isJune 18, 2026— 28 days from announcement.[Migration is not optional]. ## 2️⃣ Why Everyone Is Focusing on the Wrong Thing Most coverage of Antigravity 2.0 landed on benchmarks, speed comparisons, and the OS-building demo. All accurate. None of it is the real story. The first generation of AI coding tools followed a familiar pattern: ``` Developer writes code → AI suggests → Developer accepts/rejects → Repeat ``` The developer remained the primary *producer*. AI acted as an accelerator on a process that was fundamentally unchanged. Antigravity 2.0 introduces a structurally different loop: ``` Developer defines goal + constraints ↓ Agent spawns specialized subagents ↓ Parallel execution across tasks ↓ Developer evaluates outputs ↓ Developer refines direction ``` Notice what changed. The developer is no longer spending primary effort on producing implementation details. The developer spends primary effort on **defining objectives, setting constraints, and evaluating outcomes**. The center of gravity moves from *writing* toward *orchestrating*. That shift deserves far more attention than any benchmark chart. ## 3️⃣ The Developer-to-Director Shift The phrase that kept coming to mind while studying Antigravity 2.0: **The developer becomes the director.** Directors don't personally operate every camera. They coordinate specialists toward a coherent outcome — defining the vision, allocating responsibilities, evaluating what's working, redirecting what isn't. Software development with parallel agents increasingly looks the same. Imagine a feature request: "Add async payment processing with distributed tracing, rate limiting, and integration tests." **Traditionally:** design architecture → write implementation → write tests → instrument observability → perform code review. Sequential. All on you. **With Antigravity 2.0:** ``` js // Conceptual Antigravity SDK orchestration import { AgentOrchestrator } from '@google/antigravity-sdk'; const orchestrator = new AgentOrchestrator({ model: 'gemini-3.5-flash', parallelAgents: 4, sandboxed: true, // agents run in isolated Linux environments }); const result = await orchestrator.run({ intent: "Add async payment processing with OpenTelemetry tracing and 90%+ test coverage", context: { codebase: './src/payments', constraints: ['no breaking API changes', 'preserve existing error codes'] }, subagents: [ { role: 'refactor', focus: 'async patterns' }, { role: 'observability', focus: 'tracing instrumentation' }, { role: 'testing', focus: 'integration test suite' }, { role: 'review', focus: 'cross-agent consistency' } ] }); ``` The four specialized agents execute in parallel. The `review` subagent checks consistency *across* the other agents' outputs — a meta-layer of quality control that single-agent systems structurally cannot provide. ## 4️⃣ What Makes Antigravity 2.0 Different? Several design decisions stand out as genuinely distinctive rather than marketing language. ### One Harness Across All Surfaces The [desktop app](https://antigravity.google/product/antigravity-2), [CLI](https://antigravity.google/product/antigravity-cli), [SDK](https://antigravity.google/product/antigravity-sdk), and [API](https://blog.google/innovation-and-ai/technology/developers-tools/managed-agents-gemini-api/) all share a common orchestration foundation. Developers aren't learning five separate systems. They're learning one mental model expressed through different interfaces. That consistency eliminates a painful class of bugs: the "works in the GUI but fails in the CLI" failure mode that plagues tools with inconsistent backends. ### Co-Optimized Model and Harness Google spent the months between [v1 and v2](https://dev.to/gde/google-antigravity-10-to-20ide-quick-migration-guide-35p5) co-optimizing three layers simultaneously: the product, the agent harness, and the Gemini training stack. The model is trained *against* the harness it runs inside. That feedback loop is a structural advantage that competitors using third-party models cannot easily replicate — and it's why Google's claim that Gemini 3.5 Flash was built *with* Antigravity matters beyond the anecdote. ### JSON Hooks for Extensibility A new hooks system lets you intercept and control agent behavior at execution time without modifying the agent itself: ``` { "hooks": { "pre_execution": { "type": "approval_gate", "condition": "file_changes > 50", "action": "require_human_approval" }, "post_execution": { "type": "audit_log", "destination": "compliance_db", "fields": ["agent_id", "files_modified", "timestamp", "cost_tokens"] } } } ``` This is what enables compliance checkpoints, custom logging, and approval gates — the features that make enterprise adoption feasible rather than aspirational. ### Project Scope Replaces Workspace Scope Previously, agent conversations were scoped to a single repository. Now they're scoped to a "project" spanning multiple folders, each with independent permission settings. This unlocks genuine cross-repo tasks — refactoring a shared library and its consumers simultaneously — while preserving fine-grained access control. ### Honest Admission on Browser Capability The `[/browser](https://antigravity.google/docs/getting-started)` command is an explicit opt-in, not a default. The team acknowledged that agents weren't reliably deciding *when* to use the browser on their own. Rather than ship a system that behaves unpredictably, they made it explicit. That kind of candor is worth noting — it signals a team that prioritizes trustworthy behavior over impressive demos. ## 5️⃣ I Tested the New Mental Model Rather than just analyzing announcements, I wanted to stress-test the orchestration premise with a realistic scenario. I took a moderately complex service — a document processing module handling file intake, classification, and storage — and worked through specifying it for agent execution versus writing it manually. **What I discovered:** **The specification problem is harder than it looks.** When writing for myself, I hold context in my head and make judgment calls mid-implementation. When specifying for agents, every constraint I didn't write down explicitly became a decision the agent made on its own. My first attempt produced a technically correct result that violated two implicit assumptions I hadn't stated: file size limits and idempotency requirements on retry. The output was plausible. It was also wrong for my specific system. The lesson landed immediately: *the quality of your specification is now the quality of your output.* **The /grill-me command is underrated.** This slash command makes the agent interrogate *you*with clarifying questions before writing a single line. I used it on my second attempt. It surfaced three edge cases I hadn't considered. The resulting output required almost no revision. I'd argue this command is more valuable than any benchmark number. **Parallel agents excel at tasks that suffer from context switching.** Simultaneous agents handling refactoring, test generation, and documentation — without each one's context polluting the others — produced noticeably cleaner, more coherent outputs than sequential single-agent approaches. **What failed:** The review agent caught internal inconsistencies but couldn't catch domain-level errors. It didn't know that "retry on failure" carried specific compliance implications in my context. The agent produces plausible code. Whether it's *correct* code for your specific system remains your responsibility. That gap — between *plausible* and *correct* — is where the real risk lives, and it won't appear in any benchmark. ## 6️⃣ Why Orchestration Matters More Than Velocity For years, software engineering rewarded implementation speed above most other metrics. Orchestration doesn't make velocity irrelevant — but it introduces a different set of skills that are now becoming primary dif --- ## Environment variables vs connection references in Power Platform > Published: 2026-05-24 06:06:24+00:00 > Source: https://dev.to/sapotacorp/environment-variables-vs-connection-references-in-power-platform-1ale > wpnews: https://wpnews.pro/news/environment-variables-vs-connection-references-in-power-platform Environment variables and connection references in Power Platform both enable managed solutions to be imported across Dev, Test, UAT, and Prod environments without developer edits, but they serve distinct purposes: connection references point to authenticated connections (representing "who" the flow connects as), while environment variables store typed values like URLs or secrets (representing "what" the flow connects to). During import, connection references arrive empty and must be manually bound to existing connections in the target environment, whereas environment variables are populated from deployment-settings.json files. Misunderstanding this split can cause flows to either fail on import or run successfully against the wrong target system. Both environment variables and connection references exist for the same reason: a managed solution should import into Dev, Test, UAT and Prod without the developer editing anything between stages. They achieve that reason in different ways, and teams who conflate them end up with flows that either fail on import or run successfully against the wrong target system. Here is the split we enforce, and the deployment-settings pattern that ties it together. Connection references are pointers to actual authenticated connections. A connection is the object that holds "here is my SharePoint authentication" or "here is my credential to Acme's REST API." A connection reference is a named slot that a flow uses instead of a direct connection. When a managed solution imports into a new environment, connection references come in empty. They have to be bound to connections that exist in the target environment. First import pauses for the admin to create those connections; subsequent imports reuse them. Environment variables are typed values - strings, numbers, JSON, booleans, secrets referenced from Azure Key Vault - that solution-aware code reads at runtime. A flow calls environmentVariables('acme_AcmeApiBaseUrl') and uses the returned value in an HTTP action. The distinction: a connection reference represents who the flow connects as. An environment variable represents what the flow connects to. Connection reference for: Environment variable for: The smell test: does the flow authenticate with this thing? Connection reference. Is it a value the flow uses? Environment variable. When the pipeline imports a managed solution, the target environment needs values for every env variable and bindings for every connection reference. Both come from deployment-settings.json committed to the repo, one per target. The pipeline step per target: Secrets live in Key Vault, referenced by Key Vault URI from a secret-type env variable. Nothing sensitive lands in git. Definitions live inside the solution at Other/EnvironmentVariables.xml. The deployment-settings file references them by SchemaName. If the casing differs, you get either: The second is the dangerous one. A flow that hits null for an API base URL will typically construct a malformed URL and fail at the HTTP call, with an error message that points at the HTTP action rather than the missing variable. We now generate the deployment-settings skeleton from the solution XML instead of hand-writing it: The team fills in the Values, never the SchemaNames. One class of typo gone. First import into a new environment leaves connection references empty. The solution import succeeds but the flows cannot run - they have no connection to authenticate through. Two ways to handle this: Path 2 requires one-time manual work per connection per environment, then every future deploy is hands-off. Path 1 is fine for low-frequency deploys but burns human time on every release. When a client takes over admin of an environment we built, they get: The clearer the split is in our heads, the cleaner the handoff is for theirs. --- ## Multi-BU D365 environment: single tenant, multiple LEs > Published: 2026-05-24 06:06:03+00:00 > Source: https://dev.to/sapotacorp/multi-bu-d365-environment-single-tenant-multiple-les-29f > wpnews: https://wpnews.pro/news/multi-bu-d365-environment-single-tenant-multiple-les Here is a factual summary of the article: The article outlines three architecture patterns for multinational corporations implementing D365 Finance & Operations across multiple business units (BUs). It argues that the only scalable pattern is a single tenant with multiple legal entities (LEs), where BU isolation is achieved through organization hierarchies and security roles rather than separate environments. The two failing patterns—a single unified legal entity and separate tenants per BU—are rejected for causing either immediate operational conflicts or long-term administrative and integration overhead. Multinational corporations implementing D365 Finance & Operations across business units often underestimate how much the environment strategy decision will shape the next decade of their ERP life. Each business unit operating in a different industry brings its own processes, regulatory compliance, and data sensitivities. Picking the wrong structure at the start is expensive to reverse. Three patterns surface in architecture workshops. Each has advocates; only one scales. The two corner cases that fail Single instance with one unified legal entity for all business units. Appealing for simplicity: one configuration, one security model, one master data set. Breaks immediately when BUs have different: - Fiscal calendars (calendar year vs fiscal year) - Chart of accounts detail (manufacturing vs services have fundamentally different GL structures) - Statutory reporting obligations (healthcare vs retail have distinct regulatory packages) - Intercompany boundaries (unified LE can't intercompany with itself) The appeal wears off in the first cross-industry consolidation discussion. Separate tenant per business unit. Isolates BUs completely. Produces predictable problems: - Cross-BU consolidated reporting becomes an Azure Synapse project - Every tenant has its own license, its own upgrade schedule, its own admin overhead - M&A that reorganizes BUs requires tenant migrations - Economies of scale in shared configuration disappear Teams propose this pattern when they're nervous about sharing environments. Usually the fear is solvable with security boundaries inside a shared tenant. Custom integration layer merging outputs from separate D365 environments. Builds a new system to fix a problem the platform already addresses. Permanent ongoing cost; introduces a new source of truth; slows every new BU onboarding. The pattern that scales Single tenant, multiple legal entities, with business unit isolation via organization hierarchies and security roles. The architecture: - One D365 tenant hosting production + non-production environments - One legal entity per BU (or one per BU-and-country if BUs operate in multiple countries) - Country localization packages applied per LE as needed - Organization hierarchies - Corporate → BU → Operating Unit → Department - supporting both financial reporting cuts and security boundaries - Security roles scoped to BU via the organization hierarchy - a BU's users see only their BU's data despite sharing the tenant - Shared master data where BUs share vendors or customers, via global address book; BU-exclusive master data configured per-LE - Customizations in layered models - a Core model for shared logic, BU-specific models for industry variations, deployed together The result: BUs operate with the independence they need, while corporate gets the consolidation, shared admin, and platform economics. Organization hierarchy design The hierarchy is how the tenant supports both financial and operational cuts: - Financial reporting hierarchy: LE ↔ BU ↔ Division ↔ Corporate. Rolls trial balances up for consolidation. - Operational hierarchy: LE ↔ BU ↔ Department ↔ Team. Drives security and workflow routing. - Legal hierarchy: LE ↔ Parent LE ↔ Ultimate parent. For statutory ownership disclosures. Multiple hierarchies coexist. Each serves a specific purpose. Conflating them into one is a common design error. Security model with BU isolation Security inside a shared tenant keeps BU data separate via: - Legal entity scope on roles - a BU's accountants see only their LEs - XDS (Extensible Data Security) policies - row-level filtering beyond LE (e.g., department scope within an LE) - Organization hierarchy context in XDS - policies reference the user's BU via hierarchy - Centralized roles for corporate functions - corporate finance, corporate audit, IT admin roles span all LEs with approval This is more work than "just use separate tenants" but gives the single-tenant economics without compromising data boundaries. Customization layering per BU F&O's extension model supports layered customizations. The pattern: - Foundation model - corporate-standard extensions that all BUs inherit (localization-specific tax extensions, centralized approval frameworks) - Industry models - shared extensions per industry for BUs in that vertical (manufacturing extensions, retail extensions) - BU-specific models - extensions unique to a single BU's needs Each model version-controlled separately, deployed as a dependency chain. A BU's customization reaches them without polluting others. ALM across BUs With the multi-BU tenant, ALM has to support: - Shared build pipeline for foundation and industry models - Per-BU pipelines for BU-specific models - Environment strategy - dev per BU for BU-specific work, shared sandboxes for integration testing, shared UAT for coordinated testing, production shared by all BUs The build coordination is the new complexity. Usually addressed by a center-of-excellence team that owns foundation + industry models and coordinates release trains with BU teams. When separate tenants is right There are rare cases where separate tenants genuinely fit: - Regulatory isolation required by law (certain defense or pharma scenarios) - Data residency conflicts that can't be resolved within one tenant's regional deployment - M&A scenarios where the acquired unit will eventually spin out - Extreme size difference where the BU's scale warrants its own admin team Each of these is rare. The default for multi-BU multinationals is single tenant, multi-LE. What ships with the pattern A working multi-BU D365 tenant has: - Per-BU legal entities with appropriate localization - Organization hierarchies for financial and operational cuts - Security roles scoped to BU via hierarchy and XDS - Shared master data framework with BU-specific release patterns - Layered customization models (foundation, industry, BU) - CoE governance for shared configuration - ALM pipelines supporting the model layering The pattern is boring because it's well-trodden. That's the point. Novel environment strategies are where multi-year regret accumulates. --- ## At least one killed after massive Russian drone and missile attack on Kyiv > Published: 2026-05-24 06:04:23+00:00 > Source: http://www.euronews.com/my-europe/2026/05/24/at-least-one-killed-after-massive-russian-drone-and-missile-attack-on-kyiv > wpnews: https://wpnews.pro/news/at-least-one-killed-after-massive-russian-drone-and-missile-attack-on-kyiv A massive Russian drone and missile attack on Kyiv early Sunday killed at least one person and injured over 20, damaging residential buildings, schools, and other infrastructure across nine districts. The assault followed Ukrainian President Zelenskyy's warning of intelligence indicating Russia was preparing a strike using the hypersonic Oreshnik ballistic missile, though it was unclear if that weapon was deployed. The attack continued after sunrise, with local authorities reporting ongoing strikes on the capital. The attack came after Ukrainian President Volodymyr Zelenskyy warned of intelligence that Russia would launch a significant attack using the hypersonic Oreshnik ballistic missile. It was not immediately clear if the missile had been used in the overnight attack. Russia launched a wave of overnight strikes on Kyiv early on Sunday, killing at least one person and leaving more than 20 injured, local authorities said. The intense assault that shook buildings across the city center, including near government offices, residential buildings and schools. "Tonight Kyiv region is once again enduring a mass enemy attack with strike drones, cruise missiles and ballistic missiles," said Mykola Kalashnyk, the head of the regional ministry administration. The attack continued after sunrise, with more missiles and drones expected to hit Kyiv. Damage was recorded across at least nine districts of the capital including residential buildings, Kyiv military administration head Tymur Tkachenko said in a Telegram post. In the Shevchenko district, a school building was damaged by an attack while people sheltered inside, Mayor Vitalii Klitschko said. Local authorities reported supermarkets and warehouses across the city were also damaged. The strikes came after Ukrainian President warned of intelligence indicating Russia was "preparing a strike with the Oreshnik missile". The hypersonic multiple-warhead Oreshnik was first used on the Ukrainian city of Dnipro in November 2024. It was used a second time in January in the western Lviv region. President Vladimir Putin said the Oreshnik, which means “hazelnut tree” in Russian, streaks at 10 times the speed of sound and is capable of destroying underground bunkers “three, four or more floors down.” The weapon travels “like a meteorite” and is immune to any missile defence system, Putin said, adding that several such missiles, even fitted with conventional warheads, could be as devastating as a nuclear strike. It was not immediately clear if the missile had been used in the overnight attack. Russia had earlier also warned Ukraine would face "inevitable and severe punishment" for an alleged Ukrainian strike on a college dormitory in Russian-occupied Starobilsk in eastern Ukraine, which Moscow said killed 18 people. Ukraine denied targeting civilians, saying it had hit a Russian Rubicon drone unit stationed in the Starobilsk area. Moscow has launched mass barrages of missiles and drones at Ukraine almost daily since the full-scale offensive began in 2022, often hitting civilian infrastructure and causing civilian deaths. US-led efforts to negotiate an end to more than four years of war have slowed in recent months with Washington's attention diverted towards its conflict in the Middle East. --- ## AI API Integration Testing Checklist for Multi-Model Apps > Published: 2026-05-24 06:01:40+00:00 > Source: https://dev.to/ye_allen_/ai-api-integration-testing-checklist-for-multi-model-apps-4omo > wpnews: https://wpnews.pro/news/ai-api-integration-testing-checklist-for-multi-model-apps This article presents a testing checklist for applications that integrate multiple AI models (such as GPT, Claude, and Gemini) through a single OpenAI-compatible API gateway. It emphasizes verifying configuration details like base URLs, API keys, and model names before production, and recommends testing JSON response parsing, latency, retries, and fallback logic. The author also highlights the importance of logging metrics such as model name, request duration, and token usage to optimize cost and performance. A single successful AI API request is not enough for production. If your app uses GPT, Claude, Gemini, DeepSeek, Qwen, or other models through one OpenAI-compatible API gateway, I think the integration should be tested as a system: configuration, SDK compatibility, model names, JSON output, latency, retries, fallback, and Postman verification. I published the full checklist here: https://github.com/yeallen441-del/vectorengine-quickstart/blob/main/AI_API_TESTING_CHECKLIST.md Most migration issues come from the wrong base URL, wrong API key, or unavailable model name. I test one small request with curl or Postman before touching production code. For an OpenAI-compatible gateway, the goal is to keep the same OpenAI SDK request shape and only change the API key, base URL, and model name. Example base URL: https://www.vectronode.com/v1 Many production workflows need valid JSON. I test whether the response parses, whether required fields exist, and how the app handles bad output. A useful integration log should include model name, feature name, request duration, retry count, token usage, and error status. These fields make it easier to decide when to use a premium model and when to route to a lower-cost fallback. VectorNode AI is the OpenAI-compatible API gateway I am building around this workflow: --- ## Comunicación y sincronización entre procesos distribuidos > Published: 2026-05-24 05:47:35+00:00 > Source: https://dev.to/evelyn_samanthaperezriv/comunicacion-y-sincronizacion-entre-procesos-distribuidos-4ecc > wpnews: https://wpnews.pro/news/comunicacion-y-sincronizacion-entre-procesos-distribuidos The article explains that communication and synchronization between distributed processes are crucial for systems where processes run on different networked computers, relying on message exchange via protocols like TCP/IP, HTTP, and RPC. It highlights the importance of synchronization techniques such as semaphores and consensus algorithms to prevent errors and data inconsistencies, while also addressing challenges like network latency and concurrency. The topic is highly relevant to modern applications, including cloud computing, online gaming, and IoT. La comunicación y sincronización entre procesos distribuidos es uno de los aspectos más complejos e importantes dentro de los sistemas distribuidos. Debido a que los procesos se ejecutan en diferentes computadoras o nodos conectados mediante una red, es necesario establecer mecanismos que permitan intercambiar información de manera eficiente y coordinar correctamente las tareas del sistema. La comunicación distribuida se basa principalmente en el envío y recepción de mensajes. A diferencia de los sistemas centralizados, donde los procesos pueden compartir memoria directamente, en un sistema distribuido la información debe viajar a través de la red utilizando protocolos de comunicación. Estos protocolos definen las reglas para transmitir datos, garantizar que lleguen correctamente y mantener la sincronización entre nodos. Entre los protocolos más importantes se encuentran TCP/IP, HTTP y RPC. TCP/IP es la base de la comunicación en internet y permite transmitir datos de manera confiable entre dispositivos. HTTP es ampliamente utilizado para aplicaciones web y servicios en línea, mientras que RPC permite ejecutar procedimientos en computadoras remotas como si fueran funciones locales. La sincronización es igualmente importante, ya que múltiples procesos pueden intentar acceder al mismo recurso al mismo tiempo. Sin mecanismos adecuados, podrían ocurrir errores, inconsistencias o pérdida de información. Para evitar estos problemas, se utilizan técnicas como semáforos, exclusión mutua, relojes lógicos y algoritmos de consenso. Uno de los principales desafíos en los sistemas distribuidos es la latencia de red. Debido a que los nodos pueden encontrarse en diferentes ubicaciones geográficas, el tiempo necesario para enviar y recibir información puede variar considerablemente. Esto afecta el rendimiento general del sistema y puede generar retrasos en aplicaciones en tiempo real. Otro problema relevante es la concurrencia. En aplicaciones modernas, miles de usuarios pueden interactuar simultáneamente con el sistema. Los procesos distribuidos deben coordinarse para asegurar que las operaciones se ejecuten correctamente sin generar conflictos. Por ejemplo, en un sistema bancario, dos usuarios no deben modificar el saldo de una cuenta al mismo tiempo de forma incorrecta. La sincronización también se relaciona con la consistencia de datos. En sistemas distribuidos es difícil garantizar que todos los nodos tengan exactamente la misma información en todo momento. Por ello, existen diferentes modelos de consistencia que equilibran rendimiento y precisión según las necesidades de cada aplicación. Actualmente, este tema tiene gran relevancia en áreas como videojuegos en línea, computación en la nube, redes sociales, inteligencia artificial distribuida e internet de las cosas. Muchas aplicaciones modernas dependen de una comunicación eficiente entre múltiples dispositivos y servidores para funcionar correctamente. Como aportación de investigación en la web, pueden analizarse protocolos de comunicación modernos, algoritmos de sincronización, métodos para reducir la latencia y tecnologías utilizadas en sistemas distribuidos de gran escala. También es posible investigar cómo la comunicación distribuida influye en el rendimiento y la experiencia del usuario en aplicaciones actuales. --- ## I let Gemma 4 analyze my credit card statements so I wouldn't have to > Published: 2026-05-24 05:44:43+00:00 > Source: https://dev.to/simonwu/i-let-gemma-4-analyze-my-credit-card-statements-so-i-wouldnt-have-to-4498 > wpnews: https://wpnews.pro/news/i-let-gemma-4-analyze-my-credit-card-statements-so-i-wouldn-t-have-to The article describes Swipey, a local-first, privacy-focused web app that uses Google's Gemma 4 AI model to analyze credit card spending across multiple banks. By uploading CSV transaction files from Chase or Capital One, the app generates monthly digests with spending spotlights, patterns, suggestions, and editable transaction groupings. The author notes that Gemma 4 served as a capable open-source replacement for Claude in this workflow, successfully categorizing transactions and surfacing spending insights. This is a submission for the Gemma 4 Challenge: Build with Gemma 4 Swipey, a local-first, privacy focused web app for people juggling multiple credit cards across multiple banks. Drag in a CSV of transactions from Chase or Capital One, pick a month, and Gemma 4 produces a digest of that month's spending: a spotlight, a few patterns, and a few suggestions. It also proposes "groups" that bundle similar transactions and sum the spend, which you can edit inline. The problem: I have four credit cards. I enjoy collecting credit card reward points (anyone else?!) to help subsidize travel costs 1. This usually means chasing different category bonuses on each (one for dining, another for travel, a third for everything else). Past two or three cards, no single bank app shows you the whole picture, and the interesting questions ("what was my biggest category this month?", "how does this compare to last month?") get hard to answer. The first version shipped transaction-level data to Claude every month. Swipey on Gemma 4 keeps the same workflow but runs inference on Cloudflare Workers AI. Note: Transaction data was mocked for demo purposes Monthly insights digest (spotlight, patterns, suggestions) Transaction grouping that bundles similar merchants/themes and sums their spend A local-first, privacy-focused way to manage credit card spend across multiple banks, built with Next.js and PostgreSQL. Supports Chase and Capital One CSV exports. ⚠️ Work in progress, local use only. This project is intended to run on your own machine against a local database. API routes have no authentication. If hosted, anyone who can reach the server can read or modify your transactions. The Docker Compose setup ships with default dev credentials that are not safe for any deployed environment. Don't expose this to the public internet as-is. Model: @cf/google/gemma-4-26b-a4b-it (the 26B MoE variant) on Cloudflare Workers AI. This is the only Gemma 4 variant Cloudflare hosts as of May 2026, but here's how I would have picked between variants: One caveat during the migration: Gemma 4 needed a stricter setup than Claude to emit my parser's format reliably. The fix was a system prompt insisting on the exact format, plus wrapping the user prompt in XML with an block showing the shape to mirror. Since migration, every run has parsed cleanly. What stood out most is how capable open-source models like Gemma 4 have become at the kind of work Swipey leans on: categorizing/grouping transactions, summarizing a month of spend, and surfacing patterns. For this use case, Gemma 4 was a quality drop-in replacement against Claude. As these open-source models keep improving, I expect that gap to keep narrowing. Swipey has already surfaced spending habits I didn't even think of to track. It's an incredibly exciting time to see how AI-powered features augment into existing workflows and surface insights I would have otherwise missed. Now if you'll excuse me, Gemma 4 has some thoughts about my dining out habits that I have to reflect on. Cya! Careful. This only works if the balance is paid off in full each month. Otherwise the interest eats the perks many times over. The rewards stack up to something real if done responsibly. ↩ --- ## Gunman killed after shootout with Secret Service near White House, Trump says > Published: 2026-05-24 05:44:34+00:00 > Source: http://www.euronews.com/2026/05/24/gunman-killed-after-shootout-with-secret-service-near-white-house-trump-says > wpnews: https://wpnews.pro/news/gunman-killed-after-shootout-with-secret-service-near-white-house-trump-says A gunman was killed after exchanging gunfire with Secret Service agents near the White House on Saturday evening, with President Donald Trump inside the building but unharmed. One bystander was also struck by gunfire during the incident, while no officers were injured. Trump later stated that the shooter had a "violent history and possible obsession" with the White House. Trump said the shooter had a "violent history and possible obsession" with the White House. A gunman was killed following a shootout with Secret Service agents close to the White House on Saturday, US President Donald Trump and law enforcement officials said. The individual had pulled out a gun and began firing just after 6 pm on Saturday evening, in the area of 17th Street and Pennsylvania Avenue, Anthony Guglielmi, the US Secret Service's chief of communications, said in a statement. Trump was in the White House at the time, but he was not impacted by the incident, per Guglielmi. "Secret Service Police returned fire striking the suspect who was transported to an area hospital where he was pronounced deceased," the statement reads. "During the shooting one bystander was also struck by gunfire." No officers were reported to have been injured. In a post on Truth Social, Trump said the shooter had a "violent history and possible obsession" with the White House and thanked authorities for their "swift and professional action". It "goes to show how important it is, for all future Presidents, to get, what will be, the most safe and secure space of its kind ever built in Washington, D.C.," Trump added. Trump has been the target of a number of suspected assassination attempts in the last two years. In April, a man was charged with one count of attempt to assassinate the US president after authorities say he stormed the White House correspondents’ dinner armed with guns and knives. --- ## Faithfulness gate: the agent layer most teams skip > Published: 2026-05-24 05:37:27+00:00 > Source: https://dev.to/sapotacorp/faithfulness-gate-the-agent-layer-most-teams-skip-4kl1 > wpnews: https://wpnews.pro/news/faithfulness-gate-the-agent-layer-most-teams-skip The article explains that many AI agent teams skip implementing a "faithfulness gate," which checks whether an agent's response is actually supported by the retrieved context before delivering it to the user. This oversight can lead to confident but incorrect answers, as illustrated by a B2B SaaS customer who wasted two days trying to configure SSO after an AI assistant falsely claimed their Pro plan included it. The fix involves extracting atomic claims from the response, verifying them against the retrieved context, and either retrying the search, admitting uncertainty, or escalating to a human if the response fails the check. A B2B SaaS team got an angry email from a customer last quarter. The customer's account team had asked the company's AI assistant whether their plan included SSO. The assistant said yes. The customer's IT team spent two days trying to configure it, escalated to support, and discovered the assistant had been wrong. SSO was on the Enterprise tier. The customer was on Pro. The assistant had searched the documentation, found nothing definitive about which tiers included SSO, and produced a fluent answer based on what seemed plausible from training data. The user had no way to know it was a hallucination. The fix was not "a better model." A larger LLM would have hallucinated more confidently with the same insufficient context. The fix was a layer that should have been there from day one: a faithfulness gate that checks whether the agent's response is actually grounded in the retrieved context before shipping it to the user. This is one of the highest-leverage interventions for production AI agents. Most teams skip it because the failure mode is invisible until a customer complains. Faithfulness is a single question: does the agent's response make claims that are supported by the context the agent retrieved? If the agent searched the KB and found "Pro tier includes basic features X, Y, Z. Enterprise tier includes X, Y, Z plus advanced features A, B, C, including SSO," then a response saying "your Pro plan includes SSO" is unfaithful. The retrieved context does not support that claim. This is different from "is the response correct." Correctness requires ground truth. Faithfulness only requires the retrieved context. You can check it without a human in the loop. The mechanic: extract atomic claims from the response, check each claim against the retrieved context, return a score. Below threshold, the response is unfaithful and should not be shipped. The pattern is straightforward: Frameworks like Ragas implement this directly. You can also build it yourself with a single LLM call using a structured prompt. The judge model does not need to be the production model. We typically use GPT-4o-mini or Claude Haiku for the judge to keep costs low; they are accurate enough for this task. Bigger models are not less likely to hallucinate. They are more confident hallucinators. Given the same insufficient context, GPT-4o will produce a better-written, more structured, more authoritative-sounding wrong answer than GPT-3.5 ever could. The faithfulness gate works at a different layer than the model. It does not care how confident the model sounds. It only cares whether the claims in the response can be traced back to the retrieved context. In the team's audit, faithfulness gates caught about 40% of the responses that customers had previously reported as wrong. Most of those would not have been caught by switching to a more expensive model. Where to set the faithfulness threshold is a product decision, not a technical one. The team we worked with was in B2B SaaS. We set the threshold at 0.88 initially, monitored the rejection rate (about 6% of responses), and tuned to 0.85 after a week when the rejection rate felt too aggressive for the user experience. The agent has three options when a response fails the faithfulness check: Retry with augmented context. The agent searches again with a query informed by the failure. Sometimes the original retrieval was insufficient and a second pass surfaces the missing context. Retry once, max twice. Beyond that, do not loop. Return "I cannot answer this confidently." Honest about the limitation. Surfaces a real product problem (insufficient documentation, ambiguous query) that the team can address. Better than a confident wrong answer. Escalate to human handoff. The agent surfaces the question to a human support agent, with the retrieved context attached. Useful for customer-facing systems where "I don't know" is not an acceptable terminal state. Production teams ship all three. Retry first (cheap, often resolves), fallback to honest "I don't know" (acceptable for low-stakes), escalate for high-stakes or repeat questions. The original system was a customer support agent with RAG over the documentation. We added: Customer-reported wrong answers dropped 60% in the first month. The faithfulness gate did not improve correctness in the abstract; it just stopped the system from confidently shipping wrong answers to customers. The honest "I don't know" responses were initially worried about (would users be unhappy?) but turned out to be received well. Users prefer "I don't know" to wrong answers, even when they think they want fast answers. The unexpected benefit was the failed-check log. The team now had a list of every question the documentation could not confidently answer. That became the documentation backlog. Six months in, customer-reported issues had dropped 80% from the pre-gate baseline, partly from the gate and partly from the documentation improvements the gate surfaced. A faithfulness gate prevents one specific failure mode: claims unsupported by retrieved context. It does not catch: The gate is necessary but not sufficient for production reliability. It is the highest-leverage single intervention, but it is not the only intervention. For production agents that handle factual queries (customer support, internal knowledge, compliance, anything where being wrong has cost): The infrastructure cost is roughly $0.001 per response. The reduction in customer-reported errors is typically 40 to 60% in the first month. This is not optional for production B2B agents. It is the layer that turns a demo into a product. If your team has had customers report incorrect answers from your AI assistant, and "we'll switch to a better model" has not fixed it, the missing layer is almost certainly faithfulness checking. Sapota offers a one-week implementation engagement that adds faithfulness checking to your existing agent, calibrates the threshold against your historical reports, and ships the retry and fallback logic as a working PR. We have done this for customer support agents, internal knowledge bases, and compliance tools. Reach out via the AI engineering page with a few examples of incorrect responses your agent has given. The diagnostic conversation usually surfaces both the faithfulness gap and the documentation gaps that the gate will help expose. --- ## Why I Can't Stop Thinking About Google's New A2A Protocol > Published: 2026-05-24 05:37:06+00:00 > Source: https://dev.to/devadhithiya/why-i-cant-stop-thinking-about-googles-new-a2a-protocol-5dml > wpnews: https://wpnews.pro/news/why-i-can-t-stop-thinking-about-google-s-new-a2a-protocol Google's new Agent2Agent (A2A) Protocol, unveiled at Google I/O 2026, is an open-source communication standard that enables AI agents built on different frameworks to discover, negotiate, and collaborate with each other. Unlike consumer-focused AI updates, A2A solves the problem of incompatible agent ecosystems by allowing agents to interact through standardized "Agent Cards" and task-based workflows without exposing internal code or data. The protocol fundamentally shifts software architecture toward interoperable, fault-tolerant multi-agent systems where specialized agents can be easily swapped or managed by third parties. When Sundar Pichai dropped the words "agentic Gemini era" at Google I/O 2026, everyone naturally fixated on the shiny consumer updates. We all stared at Gemini Spark booking dinner reservations in the background, completely ignoring the absolute unit of a developer update standing right next to it. Look, having a background AI handle your OpenTable reservations is cool, but if you’re a developer, the real sauce wasn't a consumer product. It was a communication standard. I'm talking about the Agent2Agent (A2A) Protocol. Let's break down why A2A is the actual MVP of this year's I/O, and why you should care before your multi-agent codebase turns into an unmaintainable nightmare. The Problem: We Rebuilt Silos, Just Smarter Ones To understand why A2A matters, we have to look at the current state of AI agents. Over the last couple of years, we’ve seen an explosion of agentic frameworks—LangGraph, crewAI, IBM's BeeAI, and Google’s own Agent Development Kit (ADK). The problem? They don't talk to each other. Right now, trying to get a specialized LangChain agent to delegate a sub-task to your proprietary Google ADK agent usually hits a wall of incompatible formats. You want a multi-agent workflow? Great, you're locked into one ecosystem. We essentially built highly intelligent microservices, but somehow forgot to invent the HTTP to connect them. Enter A2A: The Universal Translator Originally seeded last year and heavily spotlighted at this I/O, the A2A protocol (now an open-source Linux Foundation project) is basically the universal translator for the agentic web. A2A is an open standard that lets these isolated agents discover each other, negotiate, and actually collaborate—regardless of what model or framework they are built on. It is essentially JSON-RPC 2.0 over HTTP(S), but purpose-built for the chaos of autonomous AI. How it Works Instead of exposing internal memory or proprietary logic, A2A lets agents interact through a standardized rulebook: Agent Cards: Think of this as a LinkedIn profile for AI agents. It’s a URL-accessible JSON file where the agent advertises its capabilities ("Fluent in Python," "Enjoys reading massive SQL databases"). The Client/Server Model: The A2A Client (the delegating agent) sends a request. The A2A Server (the remote agent doing the grunt work) exposes a compatible endpoint to take the job. Tasks & Artifacts: Agentic work takes time. You can't just await and pray. A "Task" tracks the job status so your system isn't left hanging, and an "Artifact" is the actual deliverable streamed back to the client once the job is done. Why This Changes the Game A2A fundamentally shifts how we will architect software in the agentic era. True Interoperability You no longer have to build monolithic AI applications. You can build a specialized inventory agent using Anthropic's MCP to read your database. When stock is low, that agent can use A2A to securely ping a completely different supplier agent built by a third-party vendor. They negotiate an order without either party exposing their internal codebase. Fault Isolation By breaking workflows into discrete, A2A-compliant agents, your system becomes incredibly resilient. If one specialized agent starts hallucinating or fails, the whole workflow doesn't crash. You just hot-swap the misbehaving agent for a better one by updating the URL in your Agent Card. Preserving Opacity Enterprise adoption of multi-agent systems has been terrified of data leaks. A2A allows agents to collaborate while maintaining strict boundaries. My agent can ask your agent to solve a problem, and your agent just returns the answer. "Alright then, keep your secrets," my agent essentially says, completely blind to the 47 janky proprietary tools your agent used behind the scenes to get the job done. The Takeaway The TL;DR of Google I/O 2026? The future of AI isn't one giant, omnipotent God-Model. It's a massive, interconnected web of specialized multi-agent systems getting work done behind the scenes. If you are building AI applications today, stop trying to make your single agent a know-it-all. Focus on making it an A2A Server. The devs who learn how to wire these autonomous systems together are the ones who are going to architect the next decade of the web. --- ## Centralized procurement D365: global address book + vendors > Published: 2026-05-24 05:37:06+00:00 > Source: https://dev.to/sapotacorp/centralized-procurement-d365-global-address-book-vendors-27mj > wpnews: https://wpnews.pro/news/centralized-procurement-d365-global-address-book-vendors The article explains how multi-legal-entity enterprises using D365 Finance can avoid vendor data duplication by leveraging the Global Address Book and centralized procurement features. The Global Address Book creates a single canonical vendor record (party) that is released to each legal entity with per-LE metadata, while centralized procurement allows one legal entity to purchase on behalf of another. This architecture ensures consistent vendor data, enables cross-LE spend reporting via a simple query, and eliminates the need for custom sync services or manual intercompany transactions. Multi-legal-entity enterprises standing up centralized procurement on D365 Finance face a recurring master data problem. The same vendor gets purchases from multiple LEs, each with its own currency, tax rules, and approval hierarchy. Without discipline, the same vendor ends up configured three or four times - different addresses in each LE, different contact emails, different payment terms that don't actually reflect the contract. Teams reach for custom sync services or per-LE vendor duplicates. Neither is necessary. Configure separate vendor records per LE with custom sync. Adds a custom integration service between LEs to keep vendor data aligned. The service becomes a dependency that has to be maintained, monitored, and upgraded indefinitely. Every field addition requires integration changes. Route all requisitions through manual intercompany transactions. Avoids duplicating vendors but shifts the pain to operations. Every cross-LE purchase becomes a multi-step manual process. Procurement teams resist; shadow-procurement workarounds appear within a month. Enable procurement categories per LE and consolidate via Excel Power Query. Looks simple in design but means spend visibility lags behind transactions by whatever the reporting cycle is. CFO asks for "current total spend with Vendor X" and waits for a manual refresh. The global address book plus centralized procurement features in D365 F&O. What each piece does: Global address book is the party-based master data layer that sits above legal entities. Each vendor is a party in the global address book with one canonical record. The party is released to each LE that transacts with it, with per-LE vendor metadata layered on top (payment terms, posting profile, default financial dimensions). Centralized procurement allows one LE to purchase on behalf of another. The purchasing LE issues the PO, receives from the vendor, and then inter-companies the goods or services to the requesting LE. Standard feature, configured at the purchasing-LE level. Shared vendor governance - new vendor requests route through a central procurement workflow. The vendor is created at the party level, then released to LEs with approval. No vendor exists in any LE without central approval. The rules that keep global address book clean: Without discipline, the global address book becomes the same mess as per-LE records with extra steps. What stays LE-specific: The party data (name, address, tax registration) stays at the global level. The operational behavior stays per-LE. Both are automatically consistent because they're one object with layered attributes. Centralized procurement doesn't mean centralized approval. Each LE configures its own approval workflow based on: The workflow is LE-local. The vendor record is global. The PO knows which LE it's from and applies the right workflow. When LE A buys on behalf of LE B: Standard functionality. Configured once per LE pair at setup. With shared vendor master, cross-LE spend reporting is a query, not a consolidation project. Power BI over the shared vendor tables, financial dimensions cutting across LEs, and Procurement analytics workspaces surface: All of this works because the vendor is one record. A working centralized procurement architecture has: The feature existed before the requirement. Getting the architecture right is about using it correctly, not extending it. --- ## Perovskite cell scaps simulation analysis > Published: 2026-05-24 05:35:41+00:00 > Source: https://dev.to/asphane/perovskite-cell-scaps-simulation-analysis-544n > wpnews: https://wpnews.pro/news/perovskite-cell-scaps-simulation-analysis This article describes a final-year project that uses SCAPS-1D simulation data to create a structured analysis pipeline for Perovskite Solar Cells (PSCs). The project includes modules for studying dark I-V and illuminated J-V curves, layer thickness effects, temperature variation, and quantum efficiency, along with automated report generation and a machine-learning dashboard. The author credits GitHub Copilot for accelerating repetitive coding tasks, allowing more focus on the physics and analysis logic. This is a submission for the GitHub Finish-Up-A-Thon Challenge I built a final-year project around Perovskite Solar Cell (PSC) simulation and analysis using SCAPS-1D data. The repository is not just a set of plots; it is a structured analysis pipeline that studies dark I-V behavior, illuminated J-V curves, layer thickness effects, temperature variation, quantum efficiency, and ETL/HTL sweeps. I also added an automated report-generation workflow and a machine-learning dashboard to make the simulation results easier to explore and interpret. GitHub repository: https://github.com/Asphane/perovskite-cell-scaps-simulation-analysis Demo video: https://drive.google.com/file/d/1zSmQiwvoN42cu0jrwqucPoSIW9Lh2u1g/view?usp=sharing This project started as raw simulation output and scattered analysis notebooks. I turned it into a cleaner, more complete project by organizing the work into separate modules for J-V analysis, dark I-V analysis, thickness optimization, QE, temperature sweep, and ETL/HTL sweep studies. I also added report generation so the findings could be documented more systematically instead of staying buried inside notebooks. GitHub Copilot helped me move faster on repetitive work: notebook boilerplate, plotting code, data handling, and report-generation scripts. It reduced the amount of time I spent writing mechanical code and let me focus more on the physics, the analysis logic, and the structure of the final project. --- ## ¿Qué significan esas letras del CVSS? Guía para entenderlo de una vez > Published: 2026-05-24 05:32:16+00:00 > Source: https://dev.to/byron_lainez/que-significan-esas-letras-del-cvss-guia-para-entenderlo-de-una-vez-gmh > wpnews: https://wpnews.pro/news/que-significan-esas-letras-del-cvss-guia-para-entenderlo-de-una-vez The article explains the Common Vulnerability Scoring System (CVSS), which uses a vector string to describe the severity and characteristics of a security vulnerability, not just a single numerical score. It breaks down the components of CVSS v3.1 and v4.0 vectors using a house burglary analogy, detailing how factors like Attack Vector, Complexity, and Impact determine the overall risk. The guide emphasizes that understanding the vector is crucial for an appropriate response, as the number alone does not explain the nature of the attack. Cada vez que sale un CVE importante, alguien pega el vector CVSS en el chat del equipo y todos hacen como que lo entienden. Spoiler: la mayoría solo mira el número (9.1 CRITICAL) e ignora el resto. El problema es que el número solo te dice qué tan grave es. El vector te dice por qué — y eso cambia completamente cómo respondes. CVSS (Common Vulnerability Scoring System) es un sistema de puntuación para describir vulnerabilidades de seguridad. No solo te da un número: te da un vector, que es básicamente una descripción comprimida de cómo funciona el ataque. Existen dos versiones que vas a ver seguido: v3.1 (la más común hoy) y v4.0 (la más nueva, más detallada). Voy a explicar las dos. 💡 💡 La escala de puntuación 0.1–3.9 LOW 4.0–6.9 MEDIUM 7.0–8.9 HIGH 9.0–10.0 CRITICALLa analogía del ladrón Para entender el vector CVSS, imagina que una vulnerabilidad es como una forma de entrar a robar a una casa. El vector CVSS responde estas preguntas sobre el "robo": 🏠 Analogía **¿Desde dónde puede atacar el ladrón?** ¿Desde la calle, o tiene que estar en el jardín? *(Attack Vector)* **¿Es difícil entrar?** ¿Puerta abierta o cerradura de alta seguridad? *(Attack Complexity)* **¿Necesita una llave?** ¿O entra sin nada? *(Privileges Required)* **¿Alguien tiene que abrir la puerta desde adentro?** *(User Interaction)* **¿Qué se puede robar?** Documentos, muebles, o puede romper cosas también. *(Impactos: C/I/A)* CVSS v3.1 — letra por letra Tomemos este vector real del CVE-2024-9465 (Palo Alto Expedition): CVSS v3.1 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N Código Nombre Valor en este CVE Qué significa en palabras simples AV:N Attack Vector — Network 🔴 Peligroso El atacante no necesita estar cerca físicamente. Puede atacar desde cualquier lugar del mundo por internet. *(N=Network, A=Adjacent, L=Local, P=Physical)* AC:L Attack Complexity — Low 🔴 Peligroso El ataque es fácil de ejecutar. No requiere condiciones especiales, timing exacto ni conocimiento avanzado. Cualquiera con el exploit puede hacerlo. *(L=Low, H=High)* PR:N Privileges Required — None 🔴 Peligroso El atacante no necesita ninguna cuenta ni contraseña previa. Llega, ataca, listo. *(N=None, L=Low, H=High)* UI:N User Interaction — None 🔴 Peligroso Ningún usuario tiene que hacer clic en nada, abrir ningún archivo ni visitar ningún enlace. El ataque funciona solo. *(N=None, R=Required)* S:U Scope — Unchanged ⚪ Neutral El impacto se queda en el sistema atacado. No "salta" automáticamente a otros sistemas. *(U=Unchanged, C=Changed)* C:H Confidentiality — High 🔴 Crítico Toda la información confidencial queda expuesta: contraseñas, API keys, configuraciones. El atacante puede leer todo. *(N=None, L=Low, H=High)* I:H Integrity — High 🔴 Crítico El atacante puede modificar o crear datos. En este caso, puede escribir archivos arbitrarios en el sistema. *(N=None, L=Low, H=High)* A:N Availability — None 🟢 Sin impacto El atacante no puede tirar el sistema. El servicio sigue disponible mientras lo explotan en silencio. *(N=None, L=Low, H=High)* ⚠️ ⚠️ Cómo leer el resultado AV:N + AC:L + PR:N + UI:N en el mismo vector = "cualquier persona en internet, sin esfuerzo, sin cuenta, sin ayuda de nadie" puede ejecutar el ataque. Eso, combinado con C:H, es la peor combinación posible para datos confidenciales.CVSS v4.0 — ¿qué cambia? La versión 4.0 es más nueva y más detallada. Divide el impacto en dos partes: el sistema directamente atacado (Vulnerable System) y otros sistemas que podrían verse afectados (Subsequent System). CVSS v4.0 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:H/SI:N/SA:N Código Nombre Valor Qué significa AV:N Attack Vector — Network 🔴 Igual que en v3.1: ataque desde internet, sin estar cerca. AC:L Attack Complexity — Low 🔴 Fácil de ejecutar, sin condiciones especiales. AT:N Attack Requirements — None 🔴 **Nuevo en v4.0.** El ataque no depende de ninguna condición externa que no controle el atacante (como que haya sesiones activas o configuraciones específicas). *(N=None, P=Present)* PR:N Privileges Required — None 🔴 Sin cuenta, sin autenticación. UI:N User Interaction — None 🔴 Nadie tiene que hacer nada para que el ataque funcione. VC:H Vulnerable System Confidentiality — High 🔴 **El sistema atacado (Expedition):** toda su información queda expuesta. Hashes, configs, API keys. VI:L Vulnerable System Integrity — Low 🟡 **El sistema atacado:** el atacante puede modificar algunos datos, pero no tiene control total de escritura. Impacto parcial en integridad. VA:N Vulnerable System Availability — None 🟢 **El sistema atacado:** sigue funcionando. No hay denegación de servicio. SC:H Subsequent System Confidentiality — High 🔴 **Otros sistemas (los firewalls PAN-OS):** como las API keys quedan expuestas, los firewalls también quedan comprometidos en confidencialidad. El daño se propaga. SI:N Subsequent System Integrity — None 🟢 **Otros sistemas:** el atacante no puede modificar datos en los firewalls directamente a través de este vector. SA:N Subsequent System Availability — None 🟢 **Otros sistemas:** no puede tumbar los firewalls con este ataque. 💡 💡 La gran mejora de v4.0 v4.0 separa el impacto en VC/VI/VA (sistema directamente atacado) y SC/SI/SA (sistemas que se ven afectados después). En este CVE, eso es clave: Expedition tiene SC:H porque las API keys expuestas comprometen los firewalls. v3.1 no capturaba bien ese efecto en cadena.Resumen visual: cómo leer un vector rápido CVSS:3.1 / AV:? / AC:? / PR:? / UI:? / S:? / C:? / I:? / A:? > │ │ │ │ │ │ │ └─ ¿Se cae el servicio? > │ │ │ │ │ │ └──────── ¿Puede modificar datos? > │ │ │ │ │ └─────────────── ¿Puede leer datos privados? > │ │ │ │ └───────────────────── ¿El daño se propaga a otros sistemas? > │ │ │ └───────────────────────────── ¿Alguien tiene que hacer clic? > │ │ └───────────────────────────────────── ¿Necesita cuenta o contraseña? > │ └───────────────────────────────────────────── ¿Es difícil ejecutarlo? > └───────────────────────────────────────────────────── ¿Desde dónde puede atacar? > > Valores de riesgo (de mayor a menor): > N (None) / H (High) = 🔴 → Peor escenario > L (Low) = 🟡 → Impacto parcial > N (None en impacto) = 🟢 → Sin efecto en esa categoría La frase que resume todo Cuando veas un vector como el de CVE-2024-9465, tradúcelo a una sola frase antes de enviarlo al equipo: 📝 Traducción al español **"Cualquier persona en internet puede atacar este sistema sin credenciales ni ayuda de nadie, y obtener acceso completo a todos los datos confidenciales, incluyendo las llaves de tus firewalls."** Eso es lo que dice el vector. Ahora sí sabes por qué tiene un 9.2. Conclusión El número CVSS te dice si debes preocuparte. El vector te dice cómo preocuparte. AV:N/AC:L/PR:N/UI:N juntos es lo más peligroso que existe: fácil, remoto y sin depender de nadie. Cuando lo veas así, actúa primero y analiza después. ✅ ✅ Regla práctica Si los primeros 4 campos son AV:N / AC:L / PR:N / UI:N — el atacante puede ser cualquier persona en internet, atacando sin esfuerzo, sin cuenta y sin ayuda. Parchea hoy.Compartir 🐦 Twitter/X 💼 LinkedIn ¿Te fue útil? Mando contenido así cuando tengo algo que vale la pena. Suscribirse ← Anterior CVE-2024-9465: SQL Injection en Palo Alto Expedition — CVSS 9.2 Todos los posts → Ver el blog completo byron.lainez © 2026 · Guatemala 🇬🇹 --- ## Limerick > Published: 2026-05-24 05:29:01+00:00 > Source: https://www.worldwidewords.org/surprise.html > wpnews: https://wpnews.pro/news/limerick The article defines "cyberventing" as the practice of using electronic means, such as websites or mass emails, to express anger or complaints, particularly against employers, retailers, or former colleagues. It notes that some employers have created official internal complaint sites to address issues openly, while also acknowledging that conflict resolution is a more effective long-term strategy for maintaining strong work relationships. The term is illustrated by examples like the "My Boss Sucks" website in New Zealand and a mass emailing incident at Intel. Cyberventing What do you do when you’re unhappy with your boss? Traditionally, you grumble to co-workers in the hallway, round the water cooler or over a drink after work. When e-mail, bulletin boards and chat rooms came along, some wrote messages to each other. Now the idea has been taken a step further: disgruntled employees are setting up Web sites to provide a forum for complaints. The term invented for this is cyberventing: venting your anger by electronic means. Some employers have even set up official grousing sites on internal Web systems, reasoning that it’s better to get the complaints out in the open than have problems fester in the dark. The term has also been applied to Web sites set up by people who are angry at the treatment they’ve received from retailers or suppliers, and also to the mass e-mailing of staff by aggrieved ex-workers, such as in a recent case at Intel. While cyberventing is a convenient way to blow off steam, conflict resolution is the best way in the long run to build and maintain strong work relationships, he contends. HR Magazine, Nov. 1999 Bosses in New Zealand must be pretty good, because none of them get a mention in the My Boss Sucks website. This is part of a new trend on the Internet — cyberventing, where you can complain to your heart’s content. The Press (Canterbury, New Zealand), Mar. 2000 --- ## scrcpy Integration in a Tauri App — Android Screen Mirroring on Mac > Published: 2026-05-24 05:25:01+00:00 > Source: https://dev.to/hiyoyok/scrcpy-integration-in-a-tauri-app-android-screen-mirroring-on-mac-27k3 > wpnews: https://wpnews.pro/news/scrcpy-integration-in-a-tauri-app-android-screen-mirroring-on-mac The article describes how to integrate scrcpy, an open-source Android screen mirroring tool, into a Tauri app for Mac. It covers launching scrcpy from Rust code, bundling it as a universal binary within the app's resources, detecting when the mirror window closes, and supporting multiple Android devices via ADB serial selection. The author tested the implementation on an 8-year-old MacBook Air while shipping seven Mac apps as a solo developer. All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion. HiyokoKit includes Android remote control via scrcpy. Launching and managing scrcpy from a Tauri app has specific challenges. Here's how I handle it. What scrcpy is scrcpy is an open-source tool that mirrors and controls an Android device screen over ADB. It's the best free option for Android screen mirroring on Mac — fast, low latency, no app required on the device. Launching scrcpy from Rust rustuse std::process::{Command, Child}; use std::sync::Mutex; pub struct ScrcpyProcess { child: Option, } impl ScrcpyProcess { pub fn start( &mut self, device_serial: &str, max_size: u32, bit_rate: &str, ) -> Result<(), AppError> { let child = Command::new("scrcpy") .args([ "--serial", device_serial, "--max-size", &max_size.to_string(), "--video-bit-rate", bit_rate, "--window-title", "Android Mirror", "--no-audio", ]) .spawn() .map_err(|e| AppError::Scrcpy(e.to_string()))?; self.child = Some(child); Ok(()) } pub fn stop(&mut self) { if let Some(mut child) = self.child.take() { child.kill().ok(); } } pub fn is_running(&mut self) -> bool { if let Some(child) = &mut self.child { child.try_wait().map(|s| s.is_none()).unwrap_or(false) } else { false } } } Bundling scrcpy scrcpy needs to be available on the user's machine or bundled with your app. I bundle it in app resources as a universal binary: json{ "bundle": { "resources": [ "bin/scrcpy", "bin/adb" ] } } At runtime, get the resource path: rustlet scrcpy_path = app_handle .path() .resource_dir() .unwrap() .join("bin/scrcpy"); Detecting when scrcpy exits scrcpy exits when the user closes the mirror window. Detect this to update your UI: rust// Poll in background tokio::spawn(async move { loop { tokio::time::sleep(Duration::from_secs(1)).await; let running = { let mut proc = scrcpy_state.lock().unwrap(); proc.is_running() }; if !running { app_handle.emit("scrcpy-stopped", ()).ok(); break; } } }); Multiple device support scrcpy's --serial flag selects a specific device when multiple are connected. Get the serial from adb devices and pass it explicitly: rustasync fn get_device_serial() -> Result { let output = Command::new("adb") .args(["devices"]) .output() .await?; let stdout = String::from_utf8_lossy(&output.stdout); stdout.lines() .skip(1) .find(|l| l.contains("device")) .and_then(|l| l.split_whitespace().next()) .map(|s| s.to_string()) .ok_or(AppError::Device("No device found".into())) } If this was useful, a ❤️ helps more than you'd think — thanks! Hiyoko PDF Vault → https://hiyokomtp.lemonsqueezy.com/checkout X → @hiyoyok --- ## Shopify theme editor: design tokens merchants can edit > Published: 2026-05-24 05:20:05+00:00 > Source: https://dev.to/sapotacorp/shopify-theme-editor-design-tokens-merchants-can-edit-377i > wpnews: https://wpnews.pro/news/shopify-theme-editor-design-tokens-merchants-can-edit The article explains that Shopify themes use a `config/settings_schema.json` file to control which design elements, such as button colors, fonts, and border thickness, merchants can edit in the theme editor without needing to code. These settings are accessed in Liquid templates via a global variable and are often compiled into CSS custom properties for consistent styling across the theme. The key is to expose meaningful, non-technical controls that allow merchants to experiment safely without breaking the theme. A merchant wants to experiment with design elements in the theme editor - button colors, font choices, border thickness, opacity. They're not comfortable editing Liquid code; they want to click, preview, save. The question for the developer: how do you expose the right knobs to the theme editor without giving merchants a way to break the theme? Shopify themes have a specific file that controls which settings merchants see in the theme editor: config/settings_schema.json. This schema defines: A well-designed settings schema gives merchants meaningful control without overwhelming them with technical knobs. config/settings_schema.json defines what the merchant sees: config/settings_data.json holds the merchant's saved values. This file isn't edited by developers directly - it's updated every time the merchant saves settings in the theme editor. Liquid templates consume the settings via settings.color_button_primary, settings.font_heading, etc. The file that controls merchant-editable design is config/settings_schema.json. Adding a new setting there makes it appear in the theme editor's global settings. Merchants click, preview, save; the change propagates across every section that references the setting. This is distinct from: Shopify's settings schema supports many types. For design tokens, the useful ones: For the scenario at the top - button colors, fonts, border thickness, opacity - the right setting types are color, font_picker, and range respectively. In Liquid, settings are accessed via the global settings variable: For bulk CSS styling, many themes compile settings into CSS custom properties in the layout: Then component CSS uses the custom properties: This separation means design-system changes in the theme editor propagate everywhere in one place. Modern Shopify themes support color schemes - named combinations of background, text, button, and accent colors that apply to sections. A merchant can define "Light scheme" and "Dark scheme" and apply either to any section. Color schemes live in the schema too but have their own structure: This is the pattern Dawn and modern OS 2.0 themes use. Merchants pick a scheme per section; the theme renders with the scheme's colors consistently. For fonts, the font_picker setting type returns a font object with a family name and loading URL. Themes use the font_url filter to load the right stylesheet: This emits the proper @font-face declaration for the chosen font. Merchants can pick any of Shopify's library fonts (Google Fonts + system) and the theme adapts automatically. A well-organized settings schema: A schema with 100 ungrouped settings is unusable even by technical merchants. A schema with 15 well-organized settings lets non-technical merchants confidently experiment. Not every theme value belongs in the settings schema. Good candidates: Bad candidates: The boundary: if a wrong value breaks the theme meaningfully, it doesn't belong in merchant-editable settings. A theme that supports non-technical merchant self-service has: Merchants who can self-serve design tokens stay happier with their theme. The developer's work is making the right set of knobs available without offering footguns. --- ## Dataverse security restructure: lessons applied too late > Published: 2026-05-24 05:19:44+00:00 > Source: https://dev.to/sapotacorp/dataverse-security-restructure-lessons-applied-too-late-12o2 > wpnews: https://wpnews.pro/news/dataverse-security-restructure-lessons-applied-too-late The article describes a common failure pattern in Dataverse security models, where roles, business units (BUs), and teams proliferate without clear purpose, leading to a complex and unmanageable system. It recommends a restructuring process that involves inventorying existing roles, grouping them into a few canonical "capability roles," flattening the BU tree to the root unless compliance requires separation, and using teams only for record ownership. The author emphasizes that maintaining a clean model requires locking new role creation and conducting a quarterly 45-minute review to prevent drift. Dataverse gives you three access-control primitives that combine into a permission model: business units (BUs), security roles, and teams. On paper they are simple. In practice, every project that runs for more than a year develops the same failure mode: the security model grows by accretion - a new role for every department, a new team for every project, a new business unit every time someone says "but we need regional data separation." By year three, the model has twenty roles nobody remembers the purpose of, and access audits take a week. We have walked three projects through a security restructure. The first took five weeks because we waited too long. The last took a week because we caught it at month three. Here is the pattern. Business unit: the hierarchical container for users and records. A row in Dataverse is owned by a user or team, which sits in a BU. BUs form a tree from the root down. Security role: a set of privileges per table (Create / Read / Write / Delete / Append / Append To / Assign / Share) and per scope (User / Business Unit / Parent:Child / Organization). Users get one or more roles. Team: a group of users that can own records collectively and can have roles assigned to the team (all members inherit). The common misreading is thinking of roles as job titles ("Sales Rep") and BUs as departments ("Sales"). The native mapping is actually: When you try to use roles for data isolation ("a Europe Sales Rep role vs a US Sales Rep role") instead of BUs, you end up with N copies of the same role for each N regions. When you try to use BUs for capability ("a Read-Only BU") you get nonsense trees. A project's security model has drifted when we see: We inherited all five symptoms at a client last year, and the fix below is what we ran. Inventory what exists. Export the security role matrix to a spreadsheet. Every role, every table, every privilege. This single document is the starting point of every conversation. Group roles by intent. Look at the column of privileges per role and find clusters. Most "custom roles" actually map to 3-5 intents: Read-Only, Standard User, Power User, Admin, System Admin. Anything more granular is almost always a slight variation. Define capability roles. Replace the cluster from step 2 with 3-5 canonical roles: Identify real data isolation requirements. Most projects need ZERO BUs beyond the root. Ask concretely: "If a user sees a record they should not, does the business have an audit or compliance problem?" For most internal CRMs, the answer is no. For multi-country businesses with data residency rules, the answer is yes and you need one BU per country. Collapse the BU tree. If you have seven BUs and zero of them have a compliance rationale, move all users to the root BU and delete the others. This is the biggest unlock - most "BU-scoped access" issues disappear when the tree flattens. Use teams for ownership, not assignment. A team should own records that multiple users share responsibility for (a deal desk queue, a support triage pool). Do not create teams to hold users who share a role - that is what the role is for. Migrate users to the new role set. Assign the new canonical roles; remove the old custom roles one by one and verify nothing breaks. Do this in a UAT mirror first, not in Prod. Lock further role creation. New security roles require an explicit ticket and justification. "We need a new role for X" usually maps to "we need to add a capability to an existing role." Making the default answer "no" keeps the model clean for the long run. Even a clean model drifts. Every quarter: 45 minutes per quarter, one engineer. The output is either "no changes" or a ticket to consolidate a role. Either outcome is healthy. Changing a security role that is actively assigned to users does not always propagate immediately. Role changes take effect on the next user action or after a cache refresh, which can be up to fifteen minutes. If you remove a privilege from a role expecting the change to apply now, and a user who has that role does something in the window between your change and their cache refresh, the old privilege is still in effect. For non-urgent changes: ignore it, the cache will clear. For security-critical revocations (compromised account, departing employee): disable the user account, not the role. Account disable is immediate; role changes are eventually consistent. If your project is six months in and you already see four custom roles with overlapping purpose: stop adding, don't restructure yet. Let the scope settle for another month, note every "new role" ticket that comes in without approving it, then run the eight-step restructure at month three. One week of focused work saves four weeks later. If your project is two years in and unmaintainable: block out a dedicated two-week window, do the full restructure, treat it as a one-time debt payment, and then install the quarterly review. The pain does not go away on its own. --- ## Floatkit is live now!!! > Published: 2026-05-24 05:19:26+00:00 > Source: https://dev.to/fari_ji/floatkit-is-live-now-4283 > wpnews: https://wpnews.pro/news/floatkit-is-live-now The article announces the launch of Floatkit, a floating productivity panel for Android developed by Fari Ji. Built with Kotlin, the tool is designed to enhance user productivity by providing quick access to features directly from an overlay on the screen. A Floating Productivity Panel I Built for Android Fari Ji Fari Ji Fari Ji Follow May 23 A Floating Productivity Panel I Built for Android # showdev # android # kotlin # productivity 1  reaction Comments Add Comment 2 min read --- ## SimGemma: Democratizing STEM Education with Offline-First AI Simulations > Published: 2026-05-24 05:18:38+00:00 > Source: https://dev.to/damodharanj/simgemma-democratizing-stem-education-with-offline-first-ai-simulations-4409 > wpnews: https://wpnews.pro/news/simgemma-democratizing-stem-education-with-offline-first-ai-simulations SimGemma is an offline-first, AI-powered platform built by tech lead and volunteer teacher Damodharan to generate interactive 3D science simulations using natural language. Designed for the Google Gemma Challenge, it uses the Gemma 4 model to allow educators in resource-constrained or disconnected classrooms to create physics and chemistry visualizations on demand. The platform also leverages Gemma 4’s translation capabilities to make these simulations accessible in regional languages like Tamil, aiming to bridge equity gaps in STEM education. Imagine a classroom in a remote village. There’s a blackboard, a few passionate teachers, and curious students. What’s missing? A high-end physics lab. Even more challenging? A stable internet connection. Physics is a subject that demands exploration. It’s hard to grasp the beauty of gravity or the silence of a vacuum from a two-dimensional drawing. This is why I built SimGemma—an offline-first, AI-powered platform designed to bring high-fidelity 3D science simulations to every classroom, regardless of connectivity. I'm Damodharan, a Tech Lead who spends my weekends teaching math and science to kids through an NGO. I've always felt that teaching topics like pendulum motion or trigonometry on a blackboard didn't do justice to the science. These concepts, along with things like molecular structures (methane, for instance), are simply better understood in 3D. SimGemma was created for the Google Gemma Challenge to demonstrate how open-weights models like Gemma can solve real-world problems in resource-constrained environments. Traditional STEM education often suffers from two major hurdles: I used to hand-code these simulations in Three.js, but it was time-consuming and hard to scale. I needed a way to generate these artifacts on demand. SimGemma is a "Lab in a Box." It allows educators to generate interactive 3D simulations using simple natural language. The heart of SimGemma is the Gemma 4 model. We chose Gemma for its exceptional performance-to-size ratio, making it perfect for local deployment. We implemented a two-tier offline approach: One of the most exciting aspects of SimGemma is what we call "Vibecoding." In our NGO workshops, we’ve seen that the biggest barrier to using technology in the classroom isn't lack of interest—it's the complexity of the tools. With Gemma 4, we’ve turned the creation process into a conversation. A teacher can say: "Show me a double pendulum where the second arm is twice as heavy, and let's see it in Mars' gravity." Gemma understands the physics constraints, generates the necessary React/Three.js code, and renders it instantly. It turns educators into creators. Living in India, where we have 22 official languages, I’ve seen how language can be a barrier to quality STEM content. Gemma 4’s translation capabilities are a game-changer. SimGemma can generate and translate these artifacts into regional languages like Tamil instantly. This means a teacher can create a simulation in English and have it ready for a Tamil-medium classroom in seconds, ensuring no student is left behind because of a language gap. As a STEM volunteer, I’ve seen firsthand how an interactive simulation can light up a student's eyes. SimGemma isn't just about code; it's about equity. It ensures that a child in a rural NGO workshop has access to the same quality of scientific exploration as a student in a tech-hub city. SimGemma proves that "Offline AI" isn't a compromise—it's a superpower. By leveraging the open-weights of Gemma 4, we’ve built a tool that is resilient, private, and accessible. We are currently looking into: #Gemma #AI #OpenSource #Education #STEM #Physics #Remotion #ThreeJS --- ## Diffusion Language Models Are Here: Deep Dive into NVIDIA's Nemotron-Labs DLM Architecture > Published: 2026-05-24 05:13:07+00:00 > Source: https://dev.to/monuminu/diffusion-language-models-are-here-deep-dive-into-nvidias-nemotron-labs-dlm-architecture-2ke2 > wpnews: https://wpnews.pro/news/diffusion-language-models-are-here-deep-dive-into-nvidia-s-nemotron-labs-dlm NVIDIA has open-sourced the Nemotron-Labs Diffusion family of language models (3B, 8B, and 14B parameters), which replace traditional left-to-right autoregressive generation with a parallel denoising diffusion process. This architectural shift allows the models to refine all tokens in a block simultaneously, achieving up to 6.4× faster inference by overcoming the memory-bandwidth bottleneck that limits standard LLMs. The models address previous accuracy gaps in diffusion language models, making them competitive with autoregressive counterparts on standard benchmarks. Meta Description:NVIDIA just open-sourced Nemotron-Labs Diffusion — a family of 3B, 8B, and 14B diffusion language models that merge autoregressive and diffusion generation for up to 6.4× faster inference. Here's the complete technical deep dive into the architecture, training methodology, three generation modes, and how to run it today with SGLang. ## Table of Contents [The Speed Wall Autoregressive LLMs Hit](#1-the-speed-wall-autoregressive-llms-hit)[What Are Diffusion Language Models?](#2-what-are-diffusion-language-models)[Why DLMs Struggled — Until Now](#3-why-dlms-struggled--until-now)[NVIDIA's AR-to-DLM Breakthrough: Efficient-DLM](#4-nvidias-ar-to-dlm-breakthrough-efficient-dlm)[Nemotron-Labs Diffusion: The Model Family](#5-nemotron-labs-diffusion-the-model-family)[Three Generation Modes: AR, Diffusion, Self-Speculation](#6-three-generation-modes-ar-diffusion-self-speculation)[Performance Deep Dive: The Numbers That Matter](#7-performance-deep-dive-the-numbers-that-matter)[Under the Hood: Block-Wise Attention & KV Caching](#8-under-the-hood-block-wise-attention--kv-caching)[Getting Started: Running with SGLang](#9-getting-started-running-with-sglang)[What This Means for Production LLM Infrastructure](#10-what-this-means-for-production-llm-infrastructure)[Conclusion & The Road Ahead](#11-conclusion--the-road-ahead) ## 1. The Speed Wall Autoregressive LLMs Hit Every language model you've ever used — GPT-4, Claude, Llama, Qwen — generates text the same fundamental way: one token at a time, left to right, each new token conditioned on every previous one. It's called **autoregressive (AR) generation**, and it's been the undisputed king of language modeling since the original GPT paper in 2018. But AR generation has a dirty secret. It's not a compute-bound problem. It's a **memory-bandwidth-bound** problem. Here's why that matters: each new token requires a full model forward pass. That means loading all the model's weights — potentially tens of gigabytes for a 7B model — from HBM (High Bandwidth Memory) into the GPU's compute cores, every single decoding step. On modern GPUs, the arithmetic throughput is enormous, but the memory bandwidth is the bottleneck. This is why serving an LLM at batch size 1 — a single user chatting with your model — leaves your GPU vastly underutilized. The math is brutal. An A100 80GB GPU has ~2TB/s of HBM bandwidth. A 7B-parameter model in FP16 takes ~14GB. Reading all weights takes ~7ms minimum per step. At 30 tokens/second, you're spending the vast majority of each step just *moving weights*, not computing. Scale this to a production API endpoint handling thousands of concurrent users, and the economics become painful. The community has attacked this problem from many angles: **speculative decoding** (using a small draft model to propose tokens verified by the large model), **quantization** (FP8, INT4 to shrink weight footprint), and **FlashAttention** (optimizing the KV-cache access pattern). These are all incremental improvements on the same fundamental loop. NVIDIA's Nemotron-Labs Diffusion — released on HuggingFace on May 23, 2026 — is taking a fundamentally different approach. Instead of optimizing the autoregressive loop, it **breaks the loop entirely**. ## 2. What Are Diffusion Language Models? If you've worked with image generation models (Stable Diffusion, DALL·E, Flux), you already know the concept of denoising diffusion. The idea is to start with pure noise and iteratively denoise it, guided by a conditioning signal, until you arrive at a coherent output. **Diffusion Language Models (DLMs)** apply this same paradigm to text. Instead of generating tokens left-to-right, a DLM: - Starts with a sequence of **masked or noisy tokens**(analogous to Gaussian noise in image diffusion) - Runs multiple **denoising refinement steps**, predicting the clean token distribution at each step - After several iterations, the entire sequence — or a large block of it — **converges to the final output** The key theoretical advantage is parallelism. In a standard AR model, token *t* can only be generated after token *t-1* exists. In a DLM, all positions in a block are refined **simultaneously** in each forward pass. This changes the computational profile dramatically: instead of being memory-bandwidth-bound by sequential weight loads, the GPU can be kept busy with dense matrix multiplications across the full block. The conceptual roots of DLMs trace back to **Masked Diffusion Language Models** (MDLMs) — work like MDLM (Sahoo et al., 2024) and SEDD (Lou et al., 2023) — that framed text generation as a discrete denoising process over masked token sequences. However, these models had significant practical shortcomings when compared to the state-of-the-art AR models of the day. NVIDIA's work specifically addresses why, and more importantly, how to fix it. ## 3. Why DLMs Struggled — Until Now The community has known about the theoretical appeal of diffusion language models for years. The reason they haven't taken over is a cluster of practical barriers that made them non-competitive with AR models in production: **1. Accuracy Gap:** DLMs trained from scratch consistently underperformed comparably-sized AR models on standard benchmarks. The discrete, iterative denoising process is harder to optimize than the clean causal language modeling objective. Models like Dream 7B were impressive for DLMs, but still lagged behind Qwen3 4B — a smaller AR model — on reasoning and knowledge tasks. **2. Training Instability:** Jointly learning to denoise across many noise levels with a bidirectional attention mask creates a different gradient landscape than causal language modeling. Loss curves are noisier, and the model is more sensitive to hyperparameter choices. **3. No KV Cache Compatibility:** This was the killer for inference efficiency. KV caching — where you store key/value activations from previous tokens to avoid recomputing them — is the single most important optimization for AR inference. Standard DLMs use fully bidirectional attention across the entire sequence, which means you *can't* cache anything: every refinement step needs to attend over all positions with the updated token states. This essentially erased the theoretical throughput advantage. **4. Fill-in-the-Middle Mismatch:** During DLM training, tokens are masked uniformly at random across the sequence. But at inference time, the model typically has a left-side prefix (the prompt) that is fully unmasked, and must fill in the right side. This creates a *training-test distribution mismatch* that degrades quality. Each of these problems has a specific technical solution in NVIDIA's Efficient-DLM framework. Let's dig in. ## 4. NVIDIA's AR-to-DLM Breakthrough: Efficient-DLM The foundational insight behind Nemotron-Labs Diffusion (and the academic paper it builds on, [arXiv:2512.14067](https://arxiv.org/abs/2512.14067)) is deceptively simple: **don't train DLMs from scratch — convert pretrained AR models into DLMs**. This avoids the accuracy gap problem entirely. You start with a model that already has world-class knowledge and reasoning capabilities baked into its weights, then teach it to *also* generate diffusion-style. The result is a model that retains AR accuracy while gaining diffusion parallelism. But there are two critical technical challenges to solve for this conversion to work. ### 4.1 Block-Wise Attention: Preserving Weights, Enabling KV Caching The attention mechanism is the crux of the problem. A standard AR model uses **causal (lower-triangular) attention** — each token attends only to itself and all previous tokens. A standard DLM uses **bidirectional (full) attention** — every token attends to every other token. The issue: if you convert an AR model and suddenly change to fully bidirectional attention, you've broken the statistical assumptions baked into all those attention weights during pretraining. The key-value projections were trained to operate in a causal setting; they "expect" not to see future tokens. Loading them into a fully bidirectional context produces degraded output and requires extensive retraining to recover. Efficient-DLM introduces **block-wise causal attention** as the solution: - The sequence is divided into non-overlapping blocks of size *B*(e.g., 32 tokens) - **Within each block**: full bidirectional attention (every token attends to every other token in the block) - **Across blocks**: standard left-to-right causal attention (block*i*can attend to blocks 0 through*i-1*) This hybrid pattern does something clever: it's structurally similar enough to causal attention that pretrained weight distributions are preserved — the model only needs to learn bidirectionality *locally* within blocks, not globally across the whole sequence. The result is a much smoother conversion that requires far less compute to recover quality. Crucially, this also re-enables **KV caching**. Since attention is still causal *across* blocks, the KV activations of completed (committed) blocks can be cached and reused exactly like in a standard AR model. Only the *current* block being refined needs to be recomputed each refinement step. ### 4.2 Position-Dependent Token Masking The second innovation addresses the training-test distribution mismatch. Instead of masking tokens uniformly at random during training, Efficient-DLM uses a **position-dependent masking strategy** that assigns *higher* masking probabilities to tokens in *later* positions in the sequence. The intuition: at inference time, when filling in a response to a prompt, earlier tokens in the response have already been decided (or are more constrained by the left-side context), while later tokens remain more uncertain. By skewing the training mask distribution to match this pattern, the model learns a denoising objective that better mirrors what it actually faces at test time. ### 4.3 Joint AR + Diffusion Training Objective Rather than optimizing purely for the diffusion objective, Nemotron-Labs Diffusion is trained with a **joint AR and diffusion loss**: ``` L_total = λ · L_AR + (1 - λ) · L_diffusion ``` Where `L_AR` is the standard cross-entropy causal language modeling loss and `L_diffusion` is the masked diffusion objective. This joint training ensures the model remains a first-class AR model while learning the diffusion generation capability. The pretrained base was trained on **1.3 trillion tokens** from NVIDIA's Nemotron pretraining datasets, with an additional **45 billion tokens** of supervised fine-tuning data for the instruct-tuned variants. ## 5. Nemotron-Labs Diffusion: The Model Family NVIDIA released seven model checkpoints on HuggingFace under the NVIDIA Nemotron Open Model License (commercially friendly for text models): | Model | Parameters | Type | Downloads (Day 1) | |---|---|---|---| `nvidia/Nemotron-Labs-Diffusion-3B` | ~4B | Text, Instruct | 14.7K | `nvidia/Nemotron-Labs-Diffusion-3B-Base` | ~4B | Text, Base | 14.2K | `nvidia/Nemotron-Labs-Diffusion-8B` | 8B | Text, Instruct | 24.1K | `nvidia/Nemotron-Labs-Diffusion-8B-Base` | 8B | Text, Base | 228K | `nvidia/Nemotron-Labs-Diffusion-14B` | 14B | Text, Instruct | 3.28K | `nvidia/Nemotron-Labs-Diffusion-14B-Base` | 14B | Text, Base | 1.18K | `nvidia/Nemotron-Labs-Diffusion-VLM-8B` | ~9B | Vision-Language | 590 | The **8B Base model** being the most downloaded (228K in under 2 days) reflects developer interest in using it as a foundation for custom fine-tuning. ## 6. Three Generation Modes: AR, Diffusion, Self-Speculation The standout design decision in Nemotron-Labs Diffusion is that **all three generation modes are supported from a single checkpoint**. You don't need different models — just a different deployment config in SGLang. ### Mode 1: Autoregressive (`ar_mode=true` ) Standard left-to-right token generation, identical to how you'd run any other causal LM. This mode is the **correctness baseline** — most --- ## White House shooting marks another incident in a string of political violence > Published: 2026-05-24 05:09:36+00:00 > Source: https://www.nbcnews.com/politics/donald-trump/white-house-shooting-marks-another-incident-string-political-violence-rcna346679 > wpnews: https://wpnews.pro/news/white-house-shooting-marks-another-incident-in-a-string-of-political-violence A 21-year-old man was fatally shot by U.S. Secret Service agents after he opened fire at a White House security checkpoint on Saturday evening, injuring a bystander. The incident is the latest in a series of politically motivated attacks near the White House and in President Donald Trump’s orbit, including a shooting at the White House Correspondents’ Association dinner last month and two prior assassination attempts against Trump in 2024. The string of violence follows a broader national rise in politically motivated attacks and threats against lawmakers, which reached nearly 15,000 cases in 2025. The shooting at the White House Saturday evening is just the latest act of political violence carried out in President Donald Trump’s orbit in recent weeks. It comes less than a month after a man opened fire outside the ballroom where Trump, members of his Cabinet and numerous government officials were attending the White House Correspondents’ Association dinner, an attack that highlighted a string of attempted security breaches and raised concerns around the safety of the president. On Saturday, U.S. Secret Service agents fatally shot a 21-year-old man after he opened fire on officers at a White House security checkpoint, resulting in a bystander being injured, officials said. Officials have not given details about a possible motive. The man, who had previously been arrested, was known to the Secret Service for walking around the White House complex and asking how to gain access, according to a court filing from a July 10 incident. Hours after the incident, Trump said in a post on Truth Social that the shooting was another sign the White House needed a “safe and secure space,” such as the ballroom that he is seeking additional funding for. “The National Security of our Country demands it!” Trump said. Earlier this month, Secret Service agents shot a man near the Washington Monument, along the path of Vice President JD Vance’s motorcade, after he allegedly opened fire when authorities confronted him. Agents pursued the man after they noticed he appeared to be concealing a firearm on the side of his body. He turned and opened fire, injuring a bystander before being shot himself, the Department of Justice said in a news release. While in an ambulance after the shooting, the suspect allegedly making a vulgar remark about the White House, the Justice Department said. In the White House Correspondents’ Association incident, prosecutors have said that before the suspect charged past officers at a security checkpoint, he sent his family members a note that criticized Trump, without mentioning him explicitly by name, and wrote that he intended to target administration officials. “Let me be clear — what we are witnessing is a pattern of violence directed at the President and at members of the press simply for doing their jobs,” Rep. Adam Smith, D-Wash., said in a post on X Saturday night. The string of shootings in proximity to the White House follows two previous assassination attempts against the president. In July 2024, Trump was grazed by a bullet when a 20-year-old gunman fired at the president as he held a campaign rally in Butler, Pennsylvania. In September of that year, a man came to a golf course near Mar-a-Lago with a rifle, aiming it through the bushes as Trump was there playing, officials said. Secret Service agents shot at the man, who fled in his car before being pulled over and arrested. He was later sentenced to life in prison for the attempted assassination. It wasn’t the last time someone brought a weapon to Mar-a-Lago. In February, a man was shot and killed by a Palm Beach County deputy after he entered the secure perimeter of Trump’s Mar-a-Lago residence with “what appeared to be a shotgun and a fuel can,” the Secret Service said at the time. The recent violence in Washington also comes as politically motivated attacks have escalated nationwide. In April, two men allegedly brought homemade bombs to an anti-Islam protest outside of the house of Zohran Mamdani, New York City’s first Muslim mayor. The men pleaded not guilty to the charges last month, but had told police that they were inspired by the Islamic State group, according to a federal complaint. They were recorded on their vehicle’s dashcam describing their plan to kill as many as 60 people in an attempt to “start terror,” prosecutors said. On Capitol Hill, a January report by the United States Capitol Police found that threats against lawmakers climbed for the third year in a row, reaching nearly 15,000 cases in 2025. Lawmakers from both sides of the aisle have spoken out against political violence amid the mounting incidents. “Political violence and acts of extremism have absolutely no home in our country, and the continued targeting of President Trump, public officials, and innocent Americans is absolutely disgusting,” Rep. Gabe Evans, R-Colo., wrote in a post on X Saturday. Rep. Shri Thanedar, D-Mich., wrote in his own post Saturday that “Political violence is 100% unacceptable! There is absolutely no room for that in this country.” “We can settle our disagreements at the ballot box,” the congressman added, “Political violence is reprehensible.” --- ## I Still Remember the Day Our Server Stall Almost Killed the Product Launch > Published: 2026-05-24 05:09:34+00:00 > Source: https://dev.to/built-from-africa/i-still-remember-the-day-our-server-stall-almost-killed-the-product-launch-44ig > wpnews: https://wpnews.pro/news/i-still-remember-the-day-our-server-stall-almost-killed-the-product-launch The article describes how a lead systems engineer's team faced a critical performance bottleneck weeks before launching a server for an online treasure hunt game, caused by a poorly optimized Java-based configuration layer. After profiling revealed excessive memory allocations and high latency, the team replaced the Java layer with a custom Rust solution, which reduced allocation counts by a factor of 10 and cut average response time from 500 milliseconds to 50 milliseconds. The successful rewrite allowed the server to scale cleanly and handle the expected traffic for the product launch. I was the lead systems engineer on a project to build a highly scalable server for a popular online treasure hunt game, and we were just weeks away from launch when our performance tests started showing alarming signs of stalling at even moderate traffic levels. Our team had spent months designing the architecture, writing the code, and testing the system, but somehow we had missed a critical bottleneck. The problem was not just about handling more requests, but about the underlying configuration decisions that determined whether our server would scale cleanly or grind to a halt at the first growth inflection point. We were using a custom-built configuration layer, which we later found out was not optimized for our specific use case. The layer was built on top of a Java-based framework, which was causing significant overhead in terms of memory allocation and garbage collection. Our initial approach was to try and optimize the existing configuration layer by tweaking the Java virtual machine settings, adjusting the heap size, and tuning the garbage collection parameters. We also tried to implement a caching mechanism to reduce the load on the configuration layer. However, despite our best efforts, the performance gains were minimal, and we were still experiencing significant stalls and latency issues. We used the VisualVM tool to profile our application and identify the performance bottlenecks. The profiler output showed that the configuration layer was responsible for a significant percentage of the memory allocations, with an average allocation count of 500,000 per second. The latency numbers were also alarming, with an average response time of 500 milliseconds. We realized that we needed to take a more radical approach to solve the problem. After much discussion and analysis, we decided to replace the Java-based configuration layer with a custom-built solution using Rust. The decision was not taken lightly, as we knew that Rust had a steep learning curve and would require significant investment in terms of time and resources. However, we were convinced that the benefits of using Rust, including its focus on memory safety and performance, would outweigh the costs. We spent several weeks rewriting the configuration layer in Rust, using the Tokio framework for asynchronous programming and the serde framework for serialization and deserialization. We also implemented a custom caching mechanism using the Redis database to reduce the load on the configuration layer. After deploying the new configuration layer, we ran a series of performance tests to measure the impact of the changes. The results were nothing short of stunning. The allocation count was reduced by a factor of 10, with an average allocation count of 50,000 per second. The latency numbers also showed a significant improvement, with an average response time of 50 milliseconds. The profiler output showed that the configuration layer was now responsible for less than 1% of the memory allocations, with a significant reduction in garbage collection overhead. We also measured the CPU usage, which was reduced by 20% due to the more efficient use of system resources. The numbers clearly showed that our decision to use Rust had paid off, and we were now confident that our server would scale cleanly and handle the expected traffic. In hindsight, I would do several things differently. Firstly, I would have invested more time in understanding the performance characteristics of the Java-based framework and the underlying configuration layer. I would have also explored other alternatives, such as using a different programming language or framework, before deciding to use Rust. Additionally, I would have planned for more extensive testing and validation of the new configuration layer before deploying it to production. However, I am proud of the fact that we were able to identify the problem, come up with a creative solution, and deploy it in time for the product launch. The experience taught me the importance of careful performance analysis, the need to consider alternative solutions, and the value of taking calculated risks to achieve significant performance gains. I also learned that the choice of programming language and framework can have a significant impact on the performance and scalability of a system, and that it is essential to consider these factors when making architecture decisions. --- ## AI Agents Need More Than Fact-Checking > Published: 2026-05-24 05:07:08+00:00 > Source: https://dev.to/dechive/ai-agents-need-more-than-fact-checking-2mp4 > wpnews: https://wpnews.pro/news/ai-agents-need-more-than-fact-checking According to the article, as AI tools evolve from simply answering questions to performing actions like sending emails, booking meetings, and editing files, traditional fact-checking is no longer sufficient for verification. The author argues that AI agents require "action-checking" because a wrong action—such as an already-sent email or a deployed code change—can cause real-world consequences that a wrong answer cannot. Therefore, developers must verify not only the correctness of the output but also whether the action's direction and scope align with the user's actual intent. For a long time, verifying AI meant checking the answer. If an AI generated an explanation, we could read it. If it summarized a document, we could compare it with the original. If it gave a wrong fact, we could correct it. If the answer was incomplete, we could ask again. That kind of verification is familiar to developers. It is close to reviewing text. But AI tools are changing. They are not only answering questions anymore. They are starting to act. They can send emails. They can book meetings. They can edit files. They can run commands. They can open pull requests. They can trigger workflows. They can move from one step to the next without waiting for every instruction. That changes the problem. Because an answer can be reviewed. An action leaves a trace. A wrong answer is usually annoying. It may confuse someone. It may waste time. It may require correction. But in many cases, the damage can stop at the text. A wrong action is different. An email that has already been sent is in someone else’s inbox. A meeting that has already been booked has taken space on someone’s calendar. A file that has already been changed may affect other work. A command that has already been run may change the environment. Code that has already been deployed is now running somewhere. That is why AI agents require a different kind of verification. Fact-checking is not enough. When AI starts acting, we need action-checking. When people hear “AI agent,” they often imagine something dramatic. But the real shift is much more practical. An email assistant does not only draft a reply. It may send the reply. A calendar assistant does not only suggest a time. It may book the meeting. A coding assistant does not only suggest code. It may edit files, run tests, open a PR, or deploy changes. A research assistant does not only return search results. It may collect sources, compare options, summarize findings, and move the task forward. That is the practical meaning of an agent. It takes a goal, breaks it into steps, uses tools, reads intermediate results, and decides what to do next. This is useful. But it also means that the thing we verify is no longer only the final answer. We need to verify the action path. When we verify AI-generated text, we usually ask: These questions still matter. But they are not enough when AI takes action. For actions, developers need a different checklist. An AI-generated email can be grammatically perfect and still be the wrong email to send. The wording may be polished. The tone may be professional. The facts may be correct. But maybe the timing is wrong. Maybe the relationship needs a softer response. Maybe the user did not want to commit yet. Maybe the message moves the conversation in the wrong direction. Fact-checking cannot catch that. The question is not only: Is this correct? The question is: Is this action moving toward the goal I actually want? For developers, this matters in code too. An AI agent may “fix” a bug by changing a larger part of the system than expected. The patch may pass tests, but it may not align with the intended design. So the first action-verification question is: Is the direction right? Agents interpret instructions. That is useful, but it also creates risk. Consider these instructions: Clean up this folder. Fix this bug. Improve this component. Organize this document. Each one sounds simple. But each one has hidden scope. “Clean up this folder” might mean renaming files. It might also mean deleting files. “Fix this bug” might mean changing one function. It might also mean refactoring surrounding code. “Improve this component” might mean adjusting UI spacing. It might also mean rewriting its state logic. The problem is not always that the AI is broken. Sometimes it is doing what it thinks the instruction implies. That means we need to verify scope. Before letting an agent act, ask: The second action-verification question is: Did it do only what it should do? Not all actions have the same weight. Saving a draft is not the same as sending an email. Running code locally is not the same as deploying it. Changing a private note is not the same as changing a shared document. Deleting a test file is not the same as deleting production data. When an AI-generated answer is wrong, we can usually edit it. When an AI action is wrong, we may need to undo a real-world change. That makes reversibility one of the most important checks. Before approving an AI action, ask: The third action-verification question is: Can this action be reversed if needed? AI does not remove responsibility. If an AI sends an email, someone allowed it to send the email. If an AI deploys code, someone approved the deployment. If an AI deletes the wrong file, books the wrong meeting, or changes the wrong setting, the result still belongs somewhere. This is uncomfortable, but important. Automation changes how work happens. It does not make responsibility disappear. So before giving an agent more autonomy, ask: The fourth action-verification question is: Who owns the outcome? Before letting an AI agent take action, I want to check four things: Direction: Does this action move in the right direction? Scope: Does it do only what it should do? Reversibility: Can it be undone if needed? Responsibility: Who owns the outcome? This is not a complicated framework. But it changes how we think about AI tools. We stop asking only: Is the answer correct? And start asking: Should this action happen? Imagine an AI coding agent receives this instruction: Fix the issue in the dashboard. A weak verification process might only check: Those checks are useful, but incomplete. Action verification asks more: Direction Did the agent fix the actual dashboard issue, or did it solve a nearby problem? Scope Did it only change dashboard-related files, or did it modify unrelated shared logic? Reversibility Can the change be reviewed and reverted easily? Is it in a branch or already deployed? Responsibility Who reviews the PR? Who approves the deployment? Who owns the result if something breaks? This is the difference between checking code output and checking agent behavior. It is tempting to think that as AI tools become more convenient, human judgment becomes less important. I think the opposite happens. Convenience moves judgment upstream. When AI handles more steps, humans may not need to make every small decision manually. But the remaining decisions become more important: The more an AI system can do, the more carefully we need to define the boundary. Automation reduces manual effort. It does not remove judgment. This is not an argument against AI agents. Many tasks should be delegated. Agents are useful when: But we should be careful when: You can delegate work to AI. But you cannot delegate judgment completely. The first phase of AI verification was mostly about answers. Can we trust this explanation? Is this fact correct? Are these sources real? Is this summary faithful? That still matters. But AI agents push the question further. Now we also need to ask: When AI makes answers, we verify facts. When AI takes actions, we verify consequences. Because answers can be read. Actions leave traces. Originally published on Dechive — an archive for verifying AI-generated answers before we trust them. --- ## Evaluation & Benchmark Results > Published: 2026-05-24 05:05:49+00:00 > Source: https://dev.to/pinaksh_patel_7c884a18b06/evaluation-benchmark-results-4nc0 > wpnews: https://wpnews.pro/news/evaluation-benchmark-results The article describes a submission for the Gemma 4 Challenge called the "Multimodal Gemma 4 Visual Regression & Patch Agent," a tool that uses Google's Gemma 4 models to diagnose and fix front-end UI bugs by cross-referencing screenshots with source code. The agent features a closed-loop safety validation pipeline and an interactive visual verification loop, and it achieved a 100% success rate across a benchmark of 10 distinct frontend and backend bug cases. Multimodal Gemma 4 Visual Regression & Patch Agent devchallenge gemmachallenge gemma ai Gemma 4 Challenge: Build With Gemma 4 Submission This is a submission for the Gemma 4 Challenge: Build with Gemma 4 What I Built Multimodal Gemma 4 Visual Regression & Patch Agent The Multimodal Gemma 4 Visual Regression & Patch Agent (Contextual Code Review Visual Patch Agent) is a production-grade multimodal code analysis and visual repair tool powered by Google's native multimodal Gemma 4 models. It bridges the gap between front-end UI bugs and back-end source code by cross-referencing visual screenshots directly with stylesheets, DOM selectors, or components to diagnose root causes, generate patches, and validate them through a closed-loop pipeline. Mermaid Flow Core Features Multimodal Visual & Logical Analysis: Ingests code files (CSS, JS, JSX, TS, TSX, HTML, Python, etc.) alongside UI screenshots of visual regressions or layouts to trace layout bugs directly back to specific CSS selectors or JS component rendering logic. Closed-Loop Safety Validation Pipeline: To ensure generated code is production-safe: PatchApplicabilityChecker: Runs a dry-run git apply --check in an ephemeral in-memory repository to guarantee conflict-free application. ASTValidator: Uses ast.parse for Python files and a custom token-matching parenthesis/bracket balance scanner for JS/TS/JSX to ensure zero syntax errors. FileGroundingValidator: Verifies that diff headers correspond strictly to uploaded file scopes, eliminating AI hallucinations. PatchValidator: Screens changes against dangerous operations (rm -rf, eval/exec, malicious package imports). Interactive Visual Verification Loop: Scrub Split Slider: Compare buggy screenshots with expected fixes side-by-side using an interactive slider. Pixel-Diff Heatmap Overlay: Computes visual color channel changes in-browser using HTML5 Canvas getImageData to overlay changed regions and compute a visual alignment score. "Simulate Fix" Canvas: Shift layout slices and preview the corrected layout on the client side instantly. Automated Benchmark Framework: Built-in test harness with 10 pre-configured CSS, JavaScript, and Python bug cases that evaluates root-cause accuracy, git apply rates, and AST validity. 📊 We validated the agent against a robust suite of 10 distinct frontend and backend bugs (overflow limits, z-index overlays, flex layouts, None pointer checks, circular dependencies, DOM element mismatches). The agent achieved 100% correctness across all engineering tests: Overall Agent Success Rate: 100.0% (10/10 cases resolved) UI Bug Localization Accuracy: 100.0% (correct CSS/JS selector mapping) Git Apply applicability: 100.0% (clean, zero-hunk conflict applying) AST / Syntax validity: 100.0% (100% syntactically correct patches) Average Analysis Latency: 0.90s Average Patch Line Accuracy: 100.0% (identical alignment with human-engineered fixes) Benchmark Table Case ID Test Case Name Language / Type Latency (s) Localization Git Apply AST Valid Patch Accuracy Status 1 CSS Overflow Bug CSS 1.25s PASSED PASSED PASSED 100.0% ✅ SUCCESS 2 Z-Index Stacking Context CSS 1.03s PASSED PASSED PASSED 100.0% ✅ SUCCESS 3 Flexbox Alignment Mismatch CSS 0.60s PASSED PASSED PASSED 100.0% ✅ SUCCESS 4 Python AttributeError (None check) Python 0.67s PASSED PASSED PASSED 100.0% ✅ SUCCESS 5 JS Click Event Selector Mismatch JS 0.96s PASSED PASSED PASSED 100.0% ✅ SUCCESS 6 CSS Low Contrast Contrast Bug CSS 0.82s PASSED PASSED PASSED 100.0% ✅ SUCCESS 7 CSS Sidebar Mobile Breakpoint CSS 0.54s PASSED PASSED PASSED 100.0% ✅ SUCCESS 8 Python Circular Dependency Import Python 0.61s PASSED PASSED PASSED 100.0% ✅ SUCCESS 9 Python SQL Injection / Validation Python 1.42s PASSED PASSED PASSED 100.0% ✅ SUCCESS 10 JS DOM Element querySelector Mismatch JS 1.14s PASSED PASSED PASSED 100.0% ✅ SUCCESS Demo Live URL: https://multimodal-visual-regression-patch-agent.vercel.app Video Demo: https://youtu.be/gvarF7T1C5E See the Gemma 4 Visual Regression & Patch Agent in action, illustrating drag-and-drop file ingestion, screenshot visual overlays, patch generation, and real-time validation badges: Screenshots Patch interface Visual display of the interactive Regression Loop application interface Split slider Interactive Split slider Side-by-side view Visual verification loop Side-by-Side view Pixel Diff Heatmap Pixel-diff heatmap visualization Visual Match Interactive visual match simulation with related code snippets Try It Yourself (Local Reproduction / Setup) You can run the entire agentic system and its benchmark suite locally in seconds using Mock Mode (no API keys required)! git clone https://github.com/kanyingidickson-dev/Multimodal-Visual-Regression-Patch-Agent.git cd Multimodal-Visual-Regression-Patch-Agent python3 -m venv venv source venv/bin/activate pip install -r backend/requirements.txt cd frontend npm install npm run build cd .. python3 backend/benchmark.py python3 backend/app.py Open http://127.0.0.1:5000 to interact with the premium dark glassmorphic review dashboard! You can click Load Example on Model settings for a quick demo launch and review. For Testing Without API Key: echo "MOCK_MODE=true" >> .env python backend/app.py Code Repository: https://github.com/kanyingidickson-dev/Multimodal-Visual-Regression-Patch-Agent Directory Layout: . ├── backend/ │ ├── app.py # FastAPI server & route handlers │ ├── benchmark.py # Automated benchmark suite runner │ ├── code_reviewer.py # Multi-stage review orchestration │ ├── file_parser.py # File ingestion & truncation utilities │ ├── gemma_client.py # API client for OpenRouter & Hugging Face │ ├── patch_utils.py # Security scanners, AST, & git validators │ ├── requirements.txt # Backend dependencies │ └── demo.py # Command-line testing entry ├── frontend/ # React dashboard codebase │ ├── src/ # Source directory │ │ ├── App.jsx # Core dashboard and Visual Verification UI │ │ ├── App.css # Stylesheets │ │ ├── index.css # Color design tokens and layout classes │ │ └── api.js # API client connection methods │ ├── dist/ # Built production frontend bundles │ ├── package.json # npm configuration │ └── vite.config.js # Vite settings ├── examples/ # Demo assets │ ├── benchmark-cases/ # Built-in 10 benchmark test directories │ ├── broken-app/ # Example buggy application │ ├── sample-output.json # Standard review structure file │ └── sample-screenshot.png # Base testing image ├── prompts/ # Custom agent instructions │ ├── system_prompt.md # Architectural guidance rules │ └── user_prompt.md # Multimodal instruction format ├── Dockerfile # Production Docker image blueprint ├── docker-compose.yml # Container coordinator ├── README.md # Project documentation └── LICENSE # MIT License Key Directory Structure backend/app.py — FastAPI web server supporting dynamic parameters and multipart file/screenshot ingestion. backend/benchmark.py — Automated test case generator and benchmark runner. backend/code_reviewer.py — Core orchestrator wrapping OpenRouter/HuggingFace API calls in multimodal content blocks. backend/gemma_client.py — Client supporting dense model choices and contextual, high-fidelity mock review generations. backend/patch_utils.py — Closed-loop safety validators (Git apply check, AST parsers, and file grounding). frontend/src/App.jsx — React interface with interactive before/after split scrub sliders, pixel difference canvases, and patch validation panels. How I Used Gemma 4 Native Multimodality: Native pixel integration enables excellent spatial mapping from image regions to matching stylesheets. 256K Context Window: Essential for ingesting multiple visual assets alongside dense code modules. Accurate Code Generation: Ensures precise unified git diff syntaxes that compile and apply flawlessly. For OpenRouter and Hugging Face, images are mapped to base64 data payloads. We structure the prompt to pass visual tokens first, as prepending pixels optimizes the native layout spatial grounding before digesting text source code: if images: user_content = [] # Prepend vision tokens for img_data in images: user_content.append({ "type": "image_url", "image_url": {"url": img_data} }) # Append instructions and files user_content.append({ "type": "text", "text": user_prompt }) JSON Output Constraints: To enable programmatic extraction of findings and patches, the system instructs Gemma 4 to respond in structured JSON. The output is parsed automatically, feeding the diff highlights and safety validators: { "summary": "...", "root_cause": "...", "fix_plan": ["...", "..."], "patch": "diff --git a/filename b/filename...", "assumptions": ["...", "..."], "confidence": "high | medium | low" } Safety Layer To protect developers, all generated patches are validated before rendering: Block matches on destructive shell scripts (e.g. rm -rf, /dev/null). Warns if insecure libraries are imported (e.g. pickle, subprocess in unsafe parameters). Checks code validation errors using compilation. 🚀 Future Vision & Roadmap Headless visual regression (CI/CD): Incorporate Playwright automation tasks to apply patches in temporary containers, launch the application, capture screenshots, and complete the visual loop automatically in the cloud. Bi-directional IDE Sync: Allow developers to highlight visual elements in a browser extension and instantly jump to the corresponding code line inside VS Code or Cursor. Support for Figma Files: Integrate Figma design files directly to compare pixel-perfect implementations automatically. Built for the Gemma 4 Challenge:- demonstrating how open, multimodal models can empower developers with intelligent, visual-aware coding tools. Top comments (1) Subscribe pic Add to the discussion tahosin profile image S M Tahosin • May 24 Taking visual regression testing from "here is a failed diff" to "here is the patch to fix the UI" is a massive workflow upgrade! It’s amazing to see Gemma 4 being used in a production-grade multimodal capacity like this. Did you find the model struggled with highly subtle pixel shifts (like font anti-aliasing), or did it confidently distinguish them from actual layout breaks? Great project! 1 like Like Reply Code of Conduct • Report abuse profile Bright Data Promoted Image of Bright Data and n8n Challenge SOC-CERT: Automated Threat Intelligence System with n8n & AI --- ## Pee for the planet: How Football fans are tackling Sweden’s fertiliser problem using urine > Published: 2026-05-24 05:02:48+00:00 > Source: http://www.euronews.com/2026/05/24/pee-for-the-planet-how-football-fans-are-tackling-swedens-fertiliser-problem-using-urine > wpnews: https://wpnews.pro/news/pee-for-the-planet-how-football-fans-are-tackling-swedens-fertiliser-problem Swedish football fans at Malmö FF's Eleda Stadion are participating in a project to collect 1,000 litres of human urine, which will be converted into fertilizer by researchers from the Swedish University of Agricultural Sciences and Oatly. The initiative aims to reduce Sweden's reliance on imported, fossil fuel-based synthetic fertilizers, which contribute significantly to global CO2 emissions and face supply disruptions due to geopolitical instability. If successful, the project could replace up to 30% of Sweden's synthetic fertilizer use and help address wastewater pollution. Could pee hold the answer to Europe’s fertiliser crisis? Swedish football fans are taking to the toilets to find out. Swedish football fans will take part in a very different kind of tournament this year: peeing for the planet. Eleda Stadion, home of Malmö FF, will open its doors – and its toilets – on Sunday (24 May) to an initiative aiming to gather 1,000 litres of human urine. The goal? To defeat Sweden’s dependence on imported fossil fuel-based synthetic fertiliser. Globally, these nitrogen-based fertilisers generate 1.13 billion tonnes of CO2 equivalents annually – exceeding those of the total aviation sector, according to research by the Center for International Environmental Law (CIEL). While these emissions have long raised concern among climate experts, synthetic fertilisers have come under additional fire in recent weeks as geopolitical instability threatens supplies. With Iran’s continued blockage of the vital Strait of Hormuz shipping route, around a third of the world’s fertiliser trade has been put on hold, threatening farming and food security around the world. The Strait is also key for transporting natural gas exports – critical in the production of synthetic nitrogen-based fertilisers, which are widely used in Europe and beyond. Is human urine a viable alternative to synthetic fertilisers? Human urine is rich in ‘the big three’ nutrients essential to plant growth: nitrogen, phosphorus and potassium. These are also key ingredients of synthetic fertilisers. The Swedish University of Agricultural Sciences (SLU), oat milk maker Oatly, Malmö FF and Sanitation360 have teamed up to research the viability of urine as a circular and safe alternative to fertilise crops, which they will do by converting the urine collected at the stadium into fertiliser. “It’s about making use of a resource we currently waste,” says Björn Vinnerås, Professor at SLU and expert at Sanitation360. “We also need to challenge the way we think, because collecting and reusing urine is really no stranger than doing the same with plastic. Today, we already use manure from cows, pigs and chickens as fertiliser – and that is completely normalised.” A testing ground for scaling the concept Malmö FF’s home stadium has been fitted with 15 urinals and one toilet capable of collecting urine for the project. From kickoff this Sunday up until Malmö FF’s final home match of the Swedish season on 29 November, it will be a testing ground for this urine-collecting technology, as well as hygiene, logistics, and public acceptance of it. The safety of urine-derived fertiliser for food crops is also being assessed as part of the research – a key question given concerns around pharmaceutical residues and pathogens that must be addressed before the approach can be adopted at scale. If successful, the project could open up opportunities to adapt toilet infrastructure and design future systems capable of collecting urine on a mass scale. It also has the potential to solve another problem: the burden of wastewater treatment at large venues such as the 22,500-capacity stadium. Some of the nutrients in human urine are currently not recovered and instead end up as pollutants in lakes and seas. The researchers estimate that urine could theoretically replace up to 30 per cent of the synthetic fertiliser used in Sweden. A longer-term ambition of the researchers is also to explore whether consumers are ready to embrace food produced using circular nutrients derived from urine. --- ## Latest news bulletin | May 24th, 2026 – Morning > Published: 2026-05-24 05:00:33+00:00 > Source: http://www.euronews.com/video/2026/05/24/latest-news-bulletin-may-24th-2026-morning > wpnews: https://wpnews.pro/news/latest-news-bulletin-may-24th-2026-morning The article is a morning news bulletin for May 24th, 2026, providing a video summary of the latest stories from Europe and around the world. It covers key topics including world news, business, entertainment, politics, culture, and travel. The bulletin is designed to help viewers catch up on the most important breaking and current events of the day. Video. Latest news bulletin | May 24th, 2026 – Morning Copy/paste the link below: Copy/paste the article video embed link below: Updated: Catch up with the most important stories from around Europe and beyond this May 24th, 2026 - latest news, breaking news, World, Business, Entertainment, Politics, Culture, Travel. --- ## Frequent flyers: How many of these airline collectibles do you have? > Published: 2026-05-24 05:00:27+00:00 > Source: http://www.euronews.com/travel/2026/05/24/frequent-flyers-how-many-of-these-airline-collectibles-do-you-have > wpnews: https://wpnews.pro/news/frequent-flyers-how-many-of-these-airline-collectibles-do-you-have The article discusses various airline collectibles that are popular among frequent flyers and aviation enthusiasts. Notable items include KLM's Delft Blue miniature houses filled with gin, Lufthansa's themed rubber ducks, and Virgin Atlantic's plane-shaped salt and pepper shakers. Other collectibles mentioned are trading cards from US airlines, limited-edition amenity kits, and watches made from decommissioned aircraft skins. From Lufthansa’s first class ducks to KLM’s miniature houses, these items are a hot commodity among aviation enthusiasts. For many frequent flyers, racking up airline miles isn’t enough – they need something tangible to show off their status. Enter: The airline collectible. From amenity kits to trading cards, there are plenty of ways to show your love of the aviation industry. Here are some of our favourites. KLM’s Delft Blue miniature houses Having first been introduced in the 1950s, KLM’s Delft Blue miniature houses may very well be the collectibles that kicked off the trend. Gifted to passengers flying business class on an international route, the tiny homes are filled with local gin. Each year on 7 October, the airline’s anniversary, a new house is depicted. Travellers currently flying business will receive a copy of Villa Rameau in Leiden, a former sexton’s house built in 1645. The house was chosen this year to mark the USA's semiquincentennial as the city in South Holland is known for having welcomed religious refugees, including the pilgrims who later sailed to the states on the Mayflower. Lufthansa’s rubber ducks Passengers who are lucky enough to be flying with Lufthansa in first class have been able to grab themselves a themed duck from the lounges in Frankfurt and Munich since 2004. While there are standard Lufthansa first class ducks, you can also pick up themed ones tied to events like Oktoberfest, Christmas, and even the FIFA World Cup. These items are seriously collectible, and can fetch a pretty penny second hand… Virgin Atlantic’s plane-shaped salt and pepper shakers First introduced in 2002, Virgin Atlantic’s aircraft-shaped salt and pepper shakers (adorably named Wilbur and Orville for the Wright brothers) have made their way into many a pocket over the years. So much so that the company pulled them from planes in 2011, only to bring them back the following year – with a new inscription on the base saying they were “pinched from Virgin Atlantic”. A Virgin Atlantic spokesperson told Euronews Travel: “Many years ago, once we spotted the trend, we decided to lean into the fun by adding the words ‘Pinched from Virgin Atlantic’ to the bottom of their feet. Since then, Wilbur and Orville have become an iconic part of the Virgin Atlantic experience – and a must-have collector’s item for many of our customers.” Trading cards Numerous airlines in the US offer trading cards which you can request from the pilot on your flight. Hawaiian Airlines, for example, has cards for each of its four aircraft – the Boeing 717, Airbus A321neo, Airbus A330 and Boeing 787-9 Dreamliner – which feature fun facts about the plane type and a spot for pilots to autograph. Last year, Delta unveiled a new centennial-themed trading card collection to mark 100 years since the airline launched. Limited-edition amenity kits One of the best parts about flying business or first class are the amenity kits, and airlines are constantly refreshing them by partnering with different cosmetic companies. But many carriers also release limited-edition kits, giving frequent flyers something to collect. Late last year, British Airways launched some for its London Gatwick flights, working with British artists to create four different bags. For this summer, Etihad Airways has unveiled its new kits with LANEIGE skincare, with different coloured bags inspired by the city being flown to. The one we’re most excited about, however, is American Airlines’ US Soccer themed kits, which come with a crossbody strap so you can use them as a regular bag once the flight is over. Limited-edition watches made from decommissioned airplanes You can take your love of aviation to the next level by wearing a piece of aircraft history on your wrist all the time thanks to AIM Watches. Founded in the UAE, the brand upcycles aircraft skins from around the globe to create timepieces which are hand-assembled in Switzerland. Limited edition watches currently available include the Frankfurt, made from a Lufthansa Airbus A380, and the Abu Dhabi, created using aircraft skin from the first Airbus A380 flown by Etihad Airways. Upcoming projects will make use of materials taken from a British Airways Concorde, and an Air France Concorde, with fabric from the original seats used to create the leather straps. Just 30 pieces will be created from each, and you can keep up to date with the project on the AIM Watches website. One to keep an eye out for is the Beta Series launch next month, which will use material from G-CIVP, the plane that set the Guinness World Record for the fastest transatlantic flight by a subsonic airliner in 2020. --- ## 5 things `flutter_gemma` doesn't tell you about shipping Gemma 4 on Android > Published: 2026-05-24 04:59:41+00:00 > Source: https://dev.to/manoj_shetty/5-things-fluttergemma-doesnt-tell-you-about-shipping-gemma-4-on-android-2koj > wpnews: https://wpnews.pro/news/5-things-flutter-gemma-doesn-t-tell-you-about-shipping-gemma-4-on-android The article describes five critical challenges the author encountered while shipping a fully offline Gemma 4 AI assistant (PocketClaw) on Android, which are not covered in standard documentation. Key issues include Gemma 4 E2B's sensitivity to prompt structure—where placing user context at the very beginning of the system prompt is essential for recall—and the failure of standard RAG cosine similarity for generic queries like "summarize the document," requiring heuristic fallbacks. The author provides practical fixes, such as using a slot-filling template for system prompts and implementing a `getDocStarts` fallback for queries with no semantic overlap with document chunks. *This is a submission for the Gemma 4 Challenge: Write About Gemma 4* I shipped a Gemma 4 assistant on Android in 17 days. Voice, vision, RAG, eight device actions, everything offline once the model is on device. The project is called PocketClaw, and you can read about it [here](https://dev.to/manoj_shetty/how-i-built-a-fully-offline-ai-assistant-on-android-with-gemma-4-e2b-5a19) if that's what you came for. This post is about the 5 things I had to figure out the hard way. Not in the `flutter_gemma` README. Not in Google's MediaPipe docs. Not in any of the half-dozen "run Gemma on Android" tutorials I read this week. If you're about to ship Gemma 4 on Android, I hope this saves you a weekend. 📱 Companion post:[How I built PocketClaw — a fully offline AI assistant on Android with Gemma 4 E2B]. Demo video, architecture deep-dive, full source code. ## 1. Small models drop facts buried mid-prompt. Put what matters at the top. I've been building agents on Claude and GPT-4 for about 18 months. Both of them handle a long system prompt fine. You can mix instructions and facts in any order, and the model figures out what's a fact versus what's a behavior rule. Gemma 4 E2B doesn't. My first system prompt for PocketClaw looked like this: ``` You are Claw. You run locally and offline. You are talking to Manoj Shetty. Match your answer length to the question. Prefer plain answers over preambles. Never restate the question. If unsure, say so briefly. ``` User asks "what's my name?" Claw answers "I do not know your name." Every time. The name is sitting right there in sentence three. I spent about an hour staring at this. My theory after the fact is that "never restate the question" was acting as a dominant instruction, and the model generalized it to "don't reference any user context." That's the kind of overgeneralization a 2B-effective model does. Cloud LLMs don't. The fix was structural, not lexical: ``` final namePart = (userName != null && userName.trim().isNotEmpty) ? "The name of the user is ${userName.trim()}.\n\n" : ''; final systemPreamble = '${namePart}You are Claw, ...'; ``` Same fact. Moved to the first line of the prompt. On its own. Flat declarative sentence. Worked the first time I tried it. The lesson generalizes. When you're working with a 2B-class model, anything you actually want the model to remember goes at the front of the prompt, in simple sentences, with no competing instructions in the same paragraph. The model is paying way more attention to the opening than to the middle. Treat the system prompt like a slot-filling template, not a paragraph. ## 2. Vanilla RAG breaks on the queries users actually type. If you've worked with RAG before, you know the textbook setup. Chunk the document, embed the chunks, store the vectors, embed the query at retrieval time, find the closest matches. Works great on benchmarks where the queries are specific. It doesn't work on "summarise the document." I caught this on Friday. I'd been heads-down for two weeks. I thought I had a working build. I uploaded a PDF I had lying around (a paper on edge LLMs), typed "summarise the document", hit send. Claw said "Summarize the document." back to me. Just that. Like an echo. I tried twice more with different phrasing. Same answer. Eventually I typed "summarise llmaiedge.pdf" with the actual filename. Got a real summary. The problem is obvious once you see it. "Summarise the document" has zero semantic overlap with the document text. The PDF doesn't contain the words "summarise" or "this document." Cosine similarity returns nothing useful. The retrieved chunk list is empty. Gemma gets the user's question with no actual document context attached. So it does what any LLM does when starved for context. It hallucinates a generic answer from its training data. The fix I shipped is two heuristics deep: ``` final isGenericIntent = hits.length <= 1 && ( lower.contains('summari') || lower.contains('tldr') || lower.contains('explain') || lower.contains('describe') || lower.contains('the document') || lower.contains('the pdf') ); if (isGenericIntent) { hits = await RagService.instance.getDocStarts( conversationId: _conversation.id, ); } ``` `getDocStarts` is a small fallback method. It runs `searchSimilar` once per indexed doc, using each doc's filename as the query. Filenames are rare distinctive tokens. Every chunk in the vector store has the filename in metadata. So this pulls back real chunks regardless of how the user phrased their question. Two lines of conditional logic. The difference between "Claw can summarise PDFs" and "Claw echoes your question back at you." If you're building RAG on Gemma 4 (or any small on-device model really), test it with generic queries before you ship. Your textbook similarity search will fail in ways that look like the model is broken. ## 3. The flutter_gemma plugin bundles ~33 MB of native libraries you probably don't use. Stock APK for PocketClaw came out at 185 MB. That felt heavy. When I unzipped it and looked at the native libs (arm64-v8a only, I was already shipping a single-arch build), this is what I saw: ``` 26 MB libllm_inference_engine_jni.so (needed) 24 MB libLiteRtLm.so (needed) 17 MB libgemma_embedding_model_jni.so (don't use — using Gecko) 17 MB libgecko_embedding_model_jni.so (needed) 14 MB libmediapipe_tasks_vision_jni.so (needed — vision input) 14 MB libmediapipe_tasks_vision_image_generator_jni.so (NOT USED) 10 MB libimagegenerator_gpu.so (NOT USED) 8 MB libLiteRtGpuAccelerator.so (needed) 8 MB libLiteRtWebGpuAccelerator.so (NOT USED — Android has OpenCL) 9 MB libtext_chunker_jni.so (needed) ``` The image-generation libs are for using Gemma to *generate* images. PocketClaw only *consumes* images (vision input to multimodal Gemma). I'm never going to generate. The WebGPU accelerator is for browsers — Android uses OpenCL. None of it does anything on my target platform. Four lines in `android/app/build.gradle.kts` : ``` packaging { jniLibs { excludes.addAll(listOf( "**/libimagegenerator_gpu.so", "**/libmediapipe_tasks_vision_image_generator_jni.so", "**/libLiteRtWebGpuAccelerator.so", "**/libLiteRtTopKWebGpuSampler.so" )) } } ``` APK dropped from 185 MB to 152 MB. 33 MB cut. Vision input still works, embedder still works, inference still works. If your use case is similar (chat + vision input + RAG, no image generation), copy these excludes. If your use case is different — say you actually want Gemma to generate images — leave the image-gen libs in. The point is, audit what your plugin pulls in and exclude what you don't use. `flutter_gemma` is built for general capability surface, not minimum-bytes-on-device. There's a second-order point here that matters more. MediaPipe is the reason `flutter_gemma` is so big. It's also the reason it handles vision and (in 3n's case) audio. Text-focused alternatives like llama.cpp wrappers can ship at 30-60 MB on Android but with much more limited or no multimodal coverage today. So the choice is really: 152 MB with mature vision support, or 60 MB without. There's no free lunch where you get multimodal at the size of a text-only stack. Pick based on what your product actually needs. ## 4. Don't feed the 128K context window. Compact it. Gemma 4 has a 128K context window. Sounds great in theory. In practice it's a footgun. Every token in the prompt costs latency at decode time. Every token costs RAM. On a phone, both of those are tight. If you naively shove the whole chat history into context every turn, you'll find that turn 20 takes noticeably longer than turn 5, and turn 50 might OOM the app. PocketClaw keeps a sliding window of the most recent 24 messages in their raw form. Anything older runs through a compaction pass: - Extract explicit facts the user has stated ("I am X", "Remember Y", "My name is Z"). - Capture unresolved goals (keywords like "fix", "todo", "issue"). - Compile both into a single lightweight summary paragraph that gets prepended to the prompt as memory. That's the chat part. The aggressive part is image handling. A typical user-uploaded photo is roughly 1 MB. As base64 in a prompt, that's around 30,000 tokens. That's a quarter of the entire 128K context window for one image. If the user uploads three photos across a conversation, your context budget is in trouble. So PocketClaw does this: when an image message slides past the 24-message boundary, the raw image bytes get deleted from memory. What's preserved is the assistant's prior textual description of that image: ``` String _imageMemoryFromAssistant({ required String? imageName, required String assistantText, }) { final label = imageName ?? 'uploaded image'; return 'Assistant previously described $label as: ' '${_shorten(assistantText, 1000)}'; } ``` So Claw still "remembers" what it saw, but only the description goes through the prompt. The 30,000-token base64 blob becomes a 100-token summary. That's roughly a 300x compression of image memory. The kicker: this works really well for the kind of follow-up questions users actually ask. "What was in that photo I sent earlier?" is answerable from the description alone. The model rarely needs the pixels back. If it does, the user can re-upload. The general pattern here is: don't think of the context window as "free space up to the limit." Think of it as a budget. Spend it on things the model needs *for the current turn*. Everything else gets compacted to a textual summary. ## 5. Whether audio works in `flutter_gemma` depends on your model file, not the Gemma version. This one I want you to know so you don't spend a day chasing the wrong thing like I did. Gemma 4 E2B's model card lists native audio as a supported modality. So I thought: cool, I'll skip the speech-to-text plugin entirely, feed raw audio bytes straight to Gemma, get a single multimodal call instead of an STT-then-LLM pipeline. Cleaner. I dug into `flutter_gemma` v0.15.1 source. The plugin's documentation consistently frames audio as a Gemma 3n E4B feature: ``` /// [supportAudio] — whether the model supports audio (Gemma 3n E4B only). bool supportAudio = false, ``` That phrasing shows up in eight different files in the plugin. The interface, the API docs, the example app, the native Android side — they all treat audio as 3n territory. But here's what's interesting once you read further. There is no hardcoded model-version check anywhere in the plugin. The actual gate is just `if (config.supportAudio == true)` . So what's really limiting audio isn't the Dart code rejecting Gemma 4 — it's whether the model file you downloaded actually contains the audio encoder. The example app's `model.dart` has the clearest hint: ``` supportAudio: true, // .litertlm files have TF_LITE_AUDIO_ENCODER supportAudio: false, // .task files don't have audio encoder ``` So the real question for any model you want to use with audio isn't "is it Gemma 3n?" — it's "does my `.litertlm` file include the audio encoder for this model?" The plugin's docs assume the answer is yes only for Gemma 3n E4B because that's what's been tested and shipped that way. For Gemma 4 E2B, the model card says audio is supported by the model itself, but I haven't found a `.litertlm` build of E2B that bundles the encoder. If one ships, the plugin should handle it — there's no version-gate to stop it. For PocketClaw I went with Android's system STT (the `speech_to_text` package). Practical reasons. I get live transcription as the user speaks (text appears word by word while they're holding the mic). That's a noticeably better UX than the "hold, speak, release, wait" pattern you'd get from on-model audio. And it side-steps the question of whether my specific E2B `.litertlm` file --- ## How I Indexed 2,000 Claude Code Skills (And What the Install Data Says About AI Coding in 2026) > Published: 2026-05-24 04:57:53+00:00 > Source: https://dev.to/shenhuang/how-i-indexed-2000-claude-code-skills-and-what-the-install-data-says-about-ai-coding-in-2026-3k80 > wpnews: https://wpnews.pro/news/how-i-indexed-2000-claude-code-skills-and-what-the-install-data-says-about-ai-in The article describes how the author built a ranked, filterable index of nearly 2,000 public Claude Code skills at orangebot.ai/skills, addressing the lack of a searchable, install-weighted directory in the official registry. The author explains their deliberately simple technical stack—a single JSON file updated by a daily cron job and served by a Next.js page—to minimize operational overhead and avoid database complexity. The post also details an SEO crisis where Google was indexing the page but showing a low 0.12% click-through rate due to missing metadata and empty client-side rendering, which the author diagnosed and began fixing. ## The problem: 2,000 skills, no map Claude Code skills exploded across 2025 and into 2026. The official registry at [skills.sh](https://skills.sh) and the parallel ecosystem on GitHub now expose well over 2,000 public skills — covering everything from `frontend-design` patterns to `azure-deploy` to `nano-banana-pro` image generation. The format won. Every serious AI coding agent — Claude Code, Cursor, OpenSeek, Codex — now ships some flavor of "loadable context package". But there is no ranked, install-weighted, searchable index. The registry lists skills alphabetically, paginates them across dozens of pages, and doesn't surface install volume in a way you can sort. You discover a useful skill one of three ways: someone tweets it, you scroll forever, or you already know the author/repo combo. None of those scale past a few hundred skills. So I built one. [orangebot.ai/skills](https://orangebot.ai/skills) is a ranked, filterable index of 1,998 public Claude Code skills sorted by weekly install volume, tagged by domain, with individual detail pages for the top 50 highest-installed entries. It is the page I wanted six months ago and didn't have. This post is the build log. Three parts: the stack (boring on purpose), the SEO crisis I walked into and the fix that shipped today, and what the install data actually says about where AI coding tools are headed in 2026. Source registry: [skills.sh](https://skills.sh). The catalog: [orangebot.ai/skills](https://orangebot.ai/skills). ## The stack (zero infrastructure surprises) I picked the most boring stack I could justify, on purpose. The catalog is not where I want to spend operational attention — the data pipeline and the SEO are. - **Next.js 16 App Router**. Server Components by default so Google sees real HTML, not a JS shell. Routing is filesystem-based, the metadata API is built in. - **Firebase App Hosting**.`git push` deploys. No manual ops, no Docker, no Kubernetes. Free tier so far. - **Cron on a Linux box at home**. A Python scraper runs daily on`lich-ubuntu` , normalizes install counts and author attribution, and writes a single ~2.5MB`skills_index.json` to the repo's`public/data/` directory. When the file changes, the next deploy picks it up. - **No database at request time**. The Next.js page reads the JSON at revalidate time (every 6 hours). Firebase serves the rendered HTML. No Postgres, no Redis, no Firestore call on the hot path. That's the whole architecture. One JSON file, one Next.js page, one daily cron. The catalog routes in the repo: ``` src/app/skills/page.js # SSR catalog (server component) src/app/skills/SkillsClient.js # interactive island (search/filter/sort) src/app/skills/[category]/page.js # domain filter pages src/app/s/[id]/page.js # individual skill detail page (top 50) public/data/skills_index.json # 1,998 entries, ~2.5MB ``` Honest disclosure on the data freshness: `skills_index.json` is regenerated weekly-ish during active development as I iterate on the parser. The production cron — separate Python service on `lich-ubuntu` — is what stabilizes it to daily; that part is still rolling out. So treat the snapshot as recent, not "fresh this morning". The decision I keep being asked about is "why not a database". Two reasons. First, the catalog is read-mostly and changes once a day — that is the canonical shape of a static JSON file, not a row store. Second, every database I'd add is a thing that can break at 2am while I'm asleep. A JSON file in `public/` cannot break. It can be wrong, but it cannot be down. The pillar guide that links into the catalog lives at [orangebot.ai/blog/claude-code-skills-guide](https://orangebot.ai/blog/claude-code-skills-guide). It's the long-form companion — what skills are, how to install them, when to pick a skill vs an MCP server. ## The SEO crisis I didn't see coming Six months after the catalog went live, I finally opened Google Search Console. The numbers were ugly. **21 of 186 known URLs indexed. 11.3%.**- 151 URLs sitting in "Discovered – currently not indexed". `last_crawled` timestamps were the 1969-12-31 Unix epoch — Google had registered the URLs from my sitemap and then never bothered to fetch them. - The `/skills` page alone was getting**5,651 impressions per week** but a**0.12% CTR**. People were seeing the page in search results, then bouncing past it. That is the failure mode for a content site. I had built the catalog, written the pillar guide, submitted the sitemap, and Google's verdict was a polite "no thanks". The 5,651 impressions were good news in disguise — the demand was real; the page just couldn't convert it because the SERP snippet was the generic brand tagline (no `generateMetadata` ) and the rendered HTML was an empty client shell. I spent a day diagnosing it instead of pushing more content. Three root causes: **Root cause 1 — the catalog page was a client component.** The top of `src/app/skills/page.js` had `'use client'` . The server-rendered HTML was an empty `
` . Googlebot does run JS, eventually, but it queues JS-heavy pages on a much slower second pass, and for low-authority sites it often skips the second pass entirely. So Google saw a blank page, picked up the brand-tagline title from the root layout, and ranked accordingly. **Root cause 2 — sitemap pollution.** Next.js App Router auto-generates routes from `metadata` files like `opengraph-image.js` , `twitter-image.js` , `icon.js` . My `next-sitemap.config.js` was pulling all of them into `sitemap.xml` , plus eight stale scaffold routes I never finished (`/cjobs` , `/mnews` , `/jobmatch` , `/jobs` , `/datajobs` , `/photographer` , `/prop` , `/startups` ). Google saw 173 sitemap entries, found ~18 weren't HTML and another 8 returned thin/empty pages, and started treating the whole sitemap as low-trust. **Root cause 3 — the homepage didn't link to /skills, /tools, or /digest in visible HTML.** The nav was inside a `
` element that collapsed by default. Googlebot reads `
` content fine, but the absence of a prominent above-the-fold internal link to /skills meant the catalog was getting near-zero internal PageRank from the homepage. Three causes, four commits. ## The fix: 4 commits, ~180 file-changes (shipped 2026-05-23) Four commits today, between 11:15 and 18:59 PDT: `e9b4ba0` (SSR-ify /skills /tools /news, clean sitemap, add hub nav), `d09e0e4` (CTR titles, EEAT author page, 5 tools SSR, news sitemap), `4442629` (P1+P2 push — 5 more tools SSR, deep compare pages, blog framework + 8 posts), `505ec1d` (P3 push — 23 tools SSR, 50 skill detail pages, hub depth, OG image, newsletter). Cumulative session touched ~180 file-changes across the four commits per the P3 commit message. **Commit 1 — convert /skills and the other hub routes from client components to a server-shell + client-island pattern.** This is the generally useful pattern I'd recommend to anyone running into the same problem. The shape is: ``` python // src/app/skills/page.js — Server Component (NO 'use client') import fs from 'node:fs/promises'; import path from 'node:path'; import SkillsClient from './SkillsClient'; export const revalidate = 21600; // 6 hours export const metadata = { title: '2,000+ Best Claude Code Skills (2026): Top Skills by Installs & Stars', description: 'A working library of Claude Code skills from across GitHub...', alternates: { canonical: '/skills' }, }; export default async function SkillsPage() { const raw = await fs.readFile( path.join(process.cwd(), 'public', 'data', 'skills_index.json'), 'utf-8' ); const allSkills = JSON.parse(raw); const topSkills = [...allSkills] .sort((a, b) => (b.installs || 0) - (a.installs || 0)) .slice(0, 60); const itemListJsonLd = { '@context': 'https://schema.org', '@type': 'ItemList', numberOfItems: topSkills.length, itemListElement: topSkills.map((s, i) => ({ '@type': 'ListItem', position: i + 1, name: s.name, url: s.repository, })), }; return ( <> ''' display(HTML(html_btn)) print("\n" + full_md) # Default configuration for standalone execution if __name__ == "__main__": generate_standalone_toc( filter_type="All", keyword="", match_mode="Cell-ID", limit=70, show_jump=True, show_stats=True, save_log=True ) --- ## Alexander Grothendieck Revolutionized 20th-Century Mathematics > Published: 2026-05-24 03:19:02+00:00 > Source: https://www.quantamagazine.org/how-alexander-grothendieck-revolutionized-20th-century-mathematics-20260520/ > wpnews: https://wpnews.pro/news/alexander-grothendieck-revolutionized-20th-century-mathematics Alexander Grothendieck revolutionized 20th-century mathematics by reorienting the field toward abstract relationships between objects rather than the objects themselves, most notably in algebraic geometry. His work, which included a landmark generalization of the Riemann-Roch theorem in 1957, introduced new terminology and constructions that transformed multiple areas of math, including number theory and topology. After producing thousands of pages of influential notes from the 1950s onward, he abruptly left his prestigious research post in 1970 and lived as a hermit in the Pyrenees until his death. How Alexander Grothendieck Revolutionized 20th-Century Mathematics Introduction What Albert Einstein was to 20th-century physics, Alexander Grothendieck was to 20th-century mathematics. He is much less well known because math gets technical even more quickly than physics does. But as with Einstein, Grothendieck’s impact came not just from his own results, revolutionary though they were. His work also reoriented his entire discipline in radical new directions. Grothendieck was intense and ascetic from his early days. Starting in the early 1950s, when he was in his 20s, he produced thousands of pages of formal and informal notes that changed the course of mathematics. Then in 1970, he quit. He left his post at a prestigious research institute just outside of Paris to teach at the provincial university in Montpellier where he studied as an undergraduate. He mostly stopped talking to other mathematicians. In the early 1990s, he moved to a small village in the Pyrenees, where he lived as a hermit. Mathematicians are still grappling with the innovations he made half a century ago. His work pushed mathematics to a new level of abstraction by focusing on the relationships between objects rather than the objects themselves. “If there is one thing in mathematics which fascinates me more than any other (and undoubtedly always has), it is neither ‘number’ nor ‘size,’ but invariably shape,” he wrote in his memoirs. “And among the thousand and one faces under which shape chooses to reveal itself to us, that which has fascinated me more than any other and continues to do so is the structure hidden in mathematical things.” His revolutionary mathematics centered around that search for hidden structure. Revealing Shapes Grothendieck is most famous for his work in algebraic geometry. The field first developed as the study of shapes defined by polynomial equations — equations that add together variables raised to fixed powers. These can be as simple as a line (x – y = 0) or a circle (x2 + y2 – 1 = 0). But as you consider more and more variables raised to higher powers and also look for solutions that satisfy sets of many equations instead of just one, things quickly get more complicated — and more abstract. The discipline took flight in the late 19th century, when mathematicians started asking questions about what happens if instead of plugging ordinary numbers into your equations, you plug in numbers from other, more abstract sets. Before Grothendieck, algebraic geometry was an interesting and vibrant subdiscipline within mathematics. But it was also somewhat in crisis, as the mathematician David Mumford later wrote. “Every researcher used his own definitions and terminology, in which the ‘foundations’ of the subject had been described in at least half a dozen different mathematical ‘languages.’” Then “Grothendieck came along and turned a confused world of researchers upside down, overwhelming them with [a] new terminology … as well as with a huge production of new and very exciting results.” Grothendieck is most famous for introducing mathematical constructions that helped him and others prove longstanding conjectures, and that eventually became central objects of study in their own right. His work also put algebraic geometry in the center of a web of many other areas of math — among them topology, number theory, representation theory, and logic. “Grothendieck never worked directly in number theory,” said Brian Conrad of Stanford University, “but the ideas he introduced into algebraic geometry totally transformed how number theory is done.” His first major result in algebraic geometry was his 1957 generalization of the Riemann-Roch theorem, a proof from a century earlier that dictates how the shape of a surface limits which functions can be defined on it. As Leila Schneps of the French National Center for Scientific Research wrote, Grothendieck’s proof “propelled him to instant stardom in the world of mathematics.” Thanks to his techniques, “a whole new wealth of operations becomes available,” Conrad said. “It opens up a whole new way to think about why the theorem is true.” Then, just as quickly, Grothendieck moved on to the next thing. At the 1958 International Congress of Mathematicians, he announced his intention to remake all of algebraic geometry. He was going to do it with something called a scheme. A New Scheme of Mathematics A decade earlier, the mathematician André Weil had conjectured a link between solutions to polynomial equations defined in two very different mathematical settings. The first was finite fields, number systems that operate according to a cyclical form of arithmetic. The second was complex numbers, which take our familiar, everyday numbers and add the square root of -1, called i. Weil made four conjectures that related polynomials from one setting to those from the other. These conjectures, Conrad said, “sound like communication between parallel universes.” As part of the effort to prove these conjectures, Grothendieck proposed his notion of a scheme. The attempted proofs were “a primary motivation for the theory of schemes,” said Daniel Litt of the University of Toronto, but “what it really bought you was a whole lot more.” Before Weil, mathematicians only really talked about equations like x2 + y2 – 1 = 0 by specifying the particular number system they wanted to work in. The solutions to such equations would look quite different if x and y could only be integers, for example, versus if they could be any real number, or any complex number. After Grothendieck came up with an explanation for why Weil’s conjectures are true, mathematicians came to believe that equations had meaningful structure independent of whether x and y were complex numbers, or elements of a finite field, or bananas. At first, this belief seems to make as little sense as saying that a sentence has meaning regardless of which language you choose its words from. But Grothendieck defined mathematical structures that made it possible to make such statements rigorous and even intuitive to those who mastered his new language. As Conrad explained, “Grothendieck found the right way to define abstract notions of space, new ways of thinking about spaces.” He recognized that “the way you probe the geometry of a space is not by looking at the points, but by studying other things.” That’s where Grothendieck’s schemes came into play. It takes some effort to construct even a simple scheme. But if you read on, it’s possible to understand what schemes are and develop an intuition for why they’re useful. Schemes are geometric spaces that are built out of abstract algebraic ingredients. Start with an abstract generalization of the integers called a ring. A ring is a set of elements that can be added, subtracted, and multiplied together, but that can’t always be divided. (In the ring of integers, for instance, you can’t divide 2 by 3, because 2/3 isn’t an integer.) Now look at a subset of your ring that is “closed,” meaning that if you add or subtract two elements of the subset, the result is also in the subset. For example, take all multiples of 5. This subset is not only closed, it has another property: You can multiply any number in the ring by an element in the subset, and the result is inevitably also in the subset. That makes the subset what mathematicians call an ideal. Moreover, if you multiply any two numbers from the ring and end up in this subset (3 × 5 = 15), then one of the numbers you multiplied (5) must have been in this subset, too, even though the other number (3) isn’t. This second property makes the subset a prime ideal. (To see why, look at the multiples of 6. These form an ideal, but not a prime ideal, because 2 × 3 is in the ideal, but neither 2 nor 3 is.) In the case of the integers, the prime ideals are sets of multiples corresponding to each of the prime numbers, along with zero. It’s possible to study the set of all the prime ideals of a ring as a single geometric space. First, represent each prime ideal as a point. Then define a “topology” on those points that puts them into neighborhoods, depending on their shared elements. (Strangely, the zero ideal ends up being “close” to every single prime, illustrating a previously unknown structure hidden behind the integers.) Grothendieck’s innovation was to add a layer on top of this space — a recently discovered mathematical superstructure called a sheaf, which carries additional algebraic information. At each point in your space, for instance, this sheaf attaches another set, called a stalk. Let’s return to one of the prime ideals of the integers: the point in our space representing the subset of all multiples of 5. The stalk attached to this point would contain all the fractions whose denominators are not divisible by 5. (The stalk attached to 0 contains all possible fractions.) In this simple example, it’s hard to see what the stalks accomplish, but in more elaborate schemes, computing the contents of stalks and the ways they interact with each other turned out to be a mathematically powerful machine. This entire object — the space of prime ideals, with the sheaf (and all its stalks) built on top of it — is called an affine scheme. In general, schemes are constructed by gluing affine schemes together in a precise mathematical way. So what does all that have to do with an equation like x2 + y2 – 1 = 0? Well, instead of starting with the ring of integers, you can study a particular ring associated with that polynomial. You can then build the scheme for that ring. But crucially, the variables x and y can be whatever you want them to be: integers, real numbers, complex numbers, elements of a finite field. By studying the scheme’s properties, you can gain insight about the structure of the equation, independent of any particular number system. It is, impossible though it may sound, a way to study the sentence apart from the language its words are written in. Broadly speaking, this is why Grothendieck and others could use schemes — and a series of ideas building on them — to re-prove one of the four Weil conjectures and prove two more. (Grothendieck’s student Pierre Deligne would later use other structures that Grothendieck developed to prove the fourth, which is a version of the famous Riemann hypothesis in the setting of finite fields.) Grothendieck continued to come up with even more abstract and powerful concepts, including topoi, stacks, motives, and étale cohomology. All play a major role in algebraic geometry and other areas of math today. Schemes gave mathematicians a novel, systematic way to study the relationships between objects in algebraic geometry. And because schemes allow you to study rings, which appear all over math, as geometric spaces, they can be used to import geometric techniques into algebra, number theory, and beyond. Grothendieck died in 2014 after years of solitude, estranged from the mathematical community he had helped create. Nonetheless, mathematicians remember him with reverent affection. As the Harvard mathematician Barry Mazur wrote, “During the early ’60s, his conversations had a secure calmness. He would offer mathematical ideas with a smile that always had an expanse of generosity in it … a sense that ‘nothing could be easier in the world’ than to view things as he did.” His ideas were complicated, but “most of the arguments are very straightforward once you set things up,” Litt said. “You just keep going and going and going. He found us the highway.” --- ## 2026 Q1 is the year developers still build the agent harness. 2026 Q3 / 2027 is the year the LLM builds its own harness. > Published: 2026-05-24 03:12:16+00:00 > Source: https://dev.to/programming_withjackche/2026-q1-is-the-year-developers-still-build-the-agent-harness-2026-q3-2027-is-the-year-the-llm-359f > wpnews: https://wpnews.pro/news/2026-q1-is-the-year-developers-still-build-the-agent-harness-2026-q3-2027-is-the According to the article, the "agent harness" refers to the essential context files (such as AGENTS.md, CLAUDE.md, and rule sets) that AI coding agents require before they can work effectively on a project. The author predicts that while developers will still need to manually create this harness in early 2026, by late 2026 or 2027, large language models will be capable of automatically generating their own project-specific harness. To bridge this gap, the author created "harnessforge," an open-source tool that locally inspects a repository and generates the necessary startup files for various AI coding agents. 2026 Q1 is the year developers still build the agent harness. 2026 Q3 / 2027 is the year the LLM builds its own harness. Today, every AI coding agent — Claude Code, Cursor, Codex, Gemini CLI, Aider, you name it — depends on the same hidden layer: the files that brief the agent before it starts work. AGENTS.md CLAUDE.md .cursor/rules SKILLS/ MCP server lists memory schemas test commands lint commands “Do not touch these paths.” “Require human approval before this.” Different IDE, same boilerplate. Different repo, same boilerplate. Different agent, same boilerplate. That is the agent harness problem. Most people talk about the coding agent itself. But in practice, the quality of an AI coding session often depends on the context layer around the agent. Before the agent starts coding, it needs to know: Without this layer, even strong coding agents can make subtle mistakes. With this layer, the same agent can behave much more consistently. That layer is what I call the harness. In theory, the LLM should be able to inspect a repo and generate all of this itself. In practice, we are not fully there yet. The models are smart enough to do real coding work, but not always reliable enough to deterministically generate perfect project-specific ground truth from scratch on every fresh repo, every time. They can do it sometimes. Not always. So the human stays in the loop. We write the same repo instructions again. We copy the same rules across projects. We maintain separate files for Claude Code, Cursor, Codex-style agents, Continue, Windsurf, and others. Small work per repo. Painful in aggregate. I think this is temporary. Soon, the coding model should be able to: At that point, the harness layer disappears as a separately authored artifact. But until then, developers still need a bridge. I built harnessforge to test this idea. It is a local, open-source harness generator for AI coding agents. It is not another coding agent. Your coding agent stays the brain. harnessforge just lays down the ground truth the agent reads before work begins. Run: uvx harnessforge init or install: pip install harnessforge In a few seconds, fully local with no network calls by default, it inspects your repo and generates startup files commonly used by AI coding agents. Depending on the project and blueprint, harnessforge can generate files such as: AGENTS.md SOUL.md TOOLS.md MEMORY.md SKILLS/ .claude/CLAUDE.md .cursor/rules .continue/ .windsurf/rules blueprint-specific validators The goal is simple: give the coding agent a stronger starting point. The current version includes these blueprints: rag-agent For retrieval systems, knowledge-base agents, citation enforcement, and grounded responses. finance-agent For finance or stock-related agents, including market-data handling and validation rules around trade execution safety. support-agent For customer support flows such as intent detection, knowledge-base lookup, ticket creation, escalation, and ticket lineage. workflow-agent For multi-step orchestration with tool logs, idempotency, and validation structure. python-cli-app A default blueprint for greenfield Python CLI projects. The important idea is not the specific files. The important idea is that coding agents need a reliable project-specific operating context. Today, we manually maintain that context. Tomorrow, the model may generate it automatically. harnessforge is meant to sit in the middle. A bridge, not a moat. Use it now. Throw it away when the models catch up. uvx harnessforge init Then open Claude Code, Cursor, Codex, Gemini CLI, Aider, or another coding agent inside the repo. The agent now has project-specific context files to read before it starts work. Instead of starting from a blank repo, the agent starts with: The coding agent still writes the code. The harness just gives it the right context. My bet is: 2026 Q1: developers still build the agent harness. 2026 Q3 / 2027: the LLM builds its own harness. Until that happens, a local deterministic harness generator can make AI coding workflows more reliable. GitHub: https://github.com/jcaiagent7143-ui/harnessforge PyPI: https://pypi.org/project/harnessforge/ I would love feedback from developers using Claude Code, Cursor, Codex, Gemini CLI, Aider, Continue, Windsurf, or other coding agents in real repos. How are you managing your agent harness today? Are you manually maintaining AGENTS.md , CLAUDE.md , .cursor/rules , MCP configs, memory files, and validation rules? Or do you think the next generation of coding models will generate this layer automatically? --- ## Introduction to Generative AI > Published: 2026-05-24 03:11:43+00:00 > Source: https://dev.to/indumathi__r/introduction-to-generative-ai-6in > wpnews: https://wpnews.pro/news/introduction-to-generative-ai Generative AI creates content like text, images, or video based on user input using a mathematical model trained on vast amounts of multimodal data. A common type is the large language model (LLM), which predicts the next word by assigning probability scores to possible outputs and selecting the highest-scoring one. Output generation can be controlled by adjusting parameters like temperature (factual vs. imaginative), Top-K (number of token candidates), and Top-P (cumulative probability threshold). What is Generative AI ? For the given user input(user query), output like text,image, video etc will be generated. This is called generative AI. How it generates content? A model will be used to generate output. i.e model will receive input and based on that, it will generate a output. What is a model? At its core, model is nothing but a mathematical equation.It will be multidimensional. vast amount of multimodal data (text,audio,video, image etc) would be subjected to training to get the required mathematical equation. To get the desired state, backpropagation will be carried out. 120b model means, equation has, 120 billion parameters. One of the commonly used model type in generative ai is LLM. What is LLM ? LLM stand for large language model. LLM basically predict the next word. If i provide the input query as hello to gpt model, based on the data it was trained, it will predict and returns the next word. In my case i got Hello,How can I help you today? Response will not be generated and sent all at once. It will be generated one by one and sent in a streamed manner(by means of SSE event). How it predicts the next word? In the above example, when i gave hello as input, why "Hi, how can i help you today was returned" ? not hi or world etc . For the given input, model provides some of possibility words like hi, world, howdy, how may i help you etc. For each possible word, it gives a score(most occuring probability). Word which is having highest score will be returned as output. If the scores are hi (0.2), world(0.4), howdy(0.1), how may i help you(0.7), highest score is 0.7, so "how may i help you is returned". Can we tweak the model to control how output should be? This can be achieved by tweaking the following parameters 1. Temperature 2. Top- K 3. Top - P Temperature Temperature controls whether the output generated be factual or imaginative. Temperature value lies between 0 - 1. If it is closer to zero, then it more of a factual and the value is closer to 1, then it is more of a imaginative. Example prompt for low temperature Example prompt for high temperature 2.Top -K K denotes the number of tokens to be returned. For the prompt, The cat sat on the ---- following words are predicted for the varying values of k. 3.Top - P Threshold percentage will be set. From the set of predicted words, those words will be taken whose cumulative probability score approximates to threshold percentage. For the prompt, The cat and top_p = 0.7 --- ## no-cycle finds 0 cycles in next.js (and other lies caches tell you) > Published: 2026-05-24 03:07:43+00:00 > Source: https://dev.to/ofri-peretz/no-cycle-finds-0-cycles-in-nextjs-and-other-lies-caches-tell-you-3ld8 > wpnews: https://wpnews.pro/news/no-cycle-finds-0-cycles-in-next-js-and-other-lies-caches-tell-you The article describes a bug in a cycle-detection algorithm used in an ESLint plugin for Next.js, where a depth limit in the DFS search caused files to be incorrectly cached as "acyclic" when the search was truncated before finding a cycle. This caching bug cascaded across thousands of files, causing the tool to report zero cycles in a large codebase (14,556 files) while smaller scopes and a different tool (oxlint) correctly found 17 cycles. The fix involves tracking whether the DFS was truncated by the depth limit and only caching files as acyclic when the search fully completes without finding a cycle. We benchmark `import-next/no-cycle` against `eslint-plugin-import/no-cycle` and oxlint's native Rust port on next.js (131K stars, 14,556 source files). The two ESLint plugins agreed: **0 cycles found**. oxlint disagreed: **17 cycles found**. We trusted the consensus. Then we tested our own rule on a 33-file subset of the same repo (`packages/next/src/client/components/router-reducer/**` ). It found **5+ cycles immediately**. Same rule. Same config. Same files. Different scope. Different answers. The bug was 60 lines deep in the cache layer — and it explains why the wider scope returned silence. ## The setup that hides the bug Every cycle-detection algorithm has the same shape: - For each file F in the lint scope - Run a depth-bounded DFS over its import graph - If DFS returns to F → found a cycle - Else → F is acyclic, remember that for next time Step 4 is where caching pays off. With N files and average graph depth D, naive cycle detection is O(N²·D). With a "known acyclic" cache, repeat visits are O(1). On real codebases the cache hit rate is 70%+ — without it the rule gets too slow to run in CI. The shape of the cache: ``` interface FileSystemCache { // ... nonCyclicFiles: Set; // files known not to be in any cycle } ``` And the use site: ``` function dfs(file: string, depth: number, visited: Set) { if (file === sourceFile) { allCycles.push([...pathStack, file]); return; } if (depth >= maxDepth) return; // <-- early return on depth limit if (visited.has(file)) return; if (cache.nonCyclicFiles.has(file)) return; // ... recurse into imports } dfs(targetFile, 1, new Set()); if (allCycles.length === 0) { cache.nonCyclicFiles.add(targetFile); // <-- cache the result } ``` Spot the bug? It's between those two `// <--` lines. ## Why the cache poisons itself When the DFS hits `depth >= maxDepth` , it returns *as if it had completed exploration without finding a cycle*. The caller can't tell the difference between "I explored everything and found nothing" and "I gave up at depth 10." So a file whose only cycle is at depth 12 (where 12 > maxDepth=10) gets: - DFS truncated at depth 10 `allCycles.length === 0` - — incorrectly marked as known-acyclic`cache.nonCyclicFiles.add(targetFile)` Now any future DFS that traverses through that file short-circuits because of `if (cache.nonCyclicFiles.has(file)) return;` . The poisoning cascades: every file in the same SCC subtree gets marked acyclic by association. In a small lint scope, you don't see the cascade — there aren't enough files for one bad cache entry to mask the others. In a 14K-file scope, one early miss-then-cache wipes out the whole cluster. ## The narrow-vs-wide scope smoking gun Here's the test that proved it. Same rule, same config, same `--no-cache` flag (so ESLint doesn't cache between runs — but our in-process cache is still active for the duration of the run): ``` bash # Wide scope: 2,363 files, includes everything in packages/ $ eslint --config flagship.config.mjs 'packages/**/*.{ts,tsx,js}' # 0 import-next/no-cycle findings # Narrow scope: 33 files, just the router-reducer directory $ eslint --config flagship.config.mjs 'packages/next/src/client/components/router-reducer/**/*.ts' # 5+ import-next/no-cycle findings ``` The narrow run finds cycles. The wide run, run from a fresh process with a fresh cache, also produces a fresh cache — but ESLint linits files in some order, and as it processes the 2,363 files, it builds up the `nonCyclicFiles` cache. By the time the lint pass reaches files that *do* belong to cycles, those cycles have been falsely marked acyclic via cascade. oxlint, being a different process with its own implementation, doesn't share our cache. It uses oxlint's own `ModuleGraphVisitorBuilder` and finds 17 cycles. ## The fix Track whether the DFS was truncated, and don't cache truncated runs: ``` js let depthLimitHit = false; function dfs(file: string, depth: number, visited: Set) { if (file === sourceFile) { allCycles.push([...pathStack, file]); return; } if (depth >= maxDepth) { depthLimitHit = true; // <-- record the truncation return; } // ... rest unchanged } dfs(targetFile, 1, new Set()); // Only cache as acyclic when DFS COMPLETED and found nothing. // A depth-truncated DFS isn't proof of acyclicity. if (allCycles.length === 0 && !depthLimitHit) { cache.nonCyclicFiles.add(targetFile); } ``` Five lines. Re-running on next.js: **0 → 245 unique files in cycles, 914 unique (file, line) pairs**. The wide-scope correctness now matches the narrow-scope correctness. ## What `eslint-plugin-import` does instead When you've found a real bug, it's worth checking how peers in the same landscape modeled the problem. The long-standing `eslint-plugin-import/no-cycle` rule uses a fundamentally different approach: ``` js // from eslint-plugin-import/src/rules/no-cycle.js:73 const scc = options.disableScc ? {} : StronglyConnectedComponentsBuilder.get(myPath, context); // ... // If we're in different SCCs, we can't have a circular dependency const hasDependencyCycle = options.disableScc || scc[myPath] === scc[imported.path]; if (!hasDependencyCycle) return; ``` They build a strongly-connected-components graph **once per lint run**, then per-file the cycle check is O(1) — *"are these two files in the same SCC?"*. The SCC graph itself is computed in O(V+E) using Tarjan's algorithm. This sidesteps the depth-limit problem entirely. SCCs are an exact answer to "what are the cycle clusters?" — there's no truncation, no approximation, no cache to poison. They cache the SCC result module-wide and clear it on `Program:exit` . oxlint goes further: it builds an explicit module graph during parsing, then the cycle visitor runs against that graph directly. No need for SCC because the graph is already structured. Both approaches share a property our DFS-with-cache approach lacks: **the algorithm is exact, not approximate**. The cache trades some compute for correctness — exactly what we accidentally did the wrong way. ## What I'd do differently next time Three takeaways from the diagnosis: **Caches should never lie.** A cache entry should only encode information you've *proven*, not information you've *failed to disprove*. Our `nonCyclicFiles` cache encoded "DFS found no cycle" as "no cycle exists." Those aren't the same statement. **Test the algorithm at the same scope you'll deploy at.** Our unit tests passed because the test fixtures are small and depth-bounded. The bug only surfaces at 2K+ files where the cache fills up enough for cascades to start. We need a stress test that mirrors production. **An exact algorithm sidesteps a class of bugs that caches can introduce.** SCC-based cycle detection (eslint-plugin-import) and module-graph walking (oxlint) avoid the depth-limit interaction by construction. We hold our DFS approach for a reason — incremental analysis benefits from per-file caching — but the depth-limit + cache interaction is exactly the kind of bug the SCC approach can't have. Worth re-evaluating whether incrementality is worth that trade. The fix is in [packages/eslint-devkit/src/resolver/dependency-analysis.ts](https://github.com/ofri-peretz/eslint/blob/main/packages/eslint-devkit/src/resolver/dependency-analysis.ts). The bench that exposed it is [ benchmarks/suites/ilb-flagship](https://github.com/ofri-peretz/eslint/tree/main/benchmarks/suites/ilb-flagship). This is one of three rule bugs caught by the same bench sweep. The companion writeups: [What ground truth caught that unit tests missed](https://ofriperetz.dev/articles/what-ground-truth-caught-that-unit-tests-missed) (the smoke-gate piece) and [When entropy isn't enough](https://ofriperetz.dev/articles/no-hardcoded-credentials-entropy-isnt-enough) (807 false credential findings on vercel/ai). ## 📊 About the author I'm Ofri Peretz, building the Interlace ESLint ecosystem — a JavaScript static-analysis catalog that runs under ESLint and Oxlint with CI-enforced parity. --- ## Google I/O 2026 Wasn’t About AI Models — It Was About Infrastructure > Published: 2026-05-24 03:02:49+00:00 > Source: https://dev.to/surfiniaburger/google-io-2026-wasnt-about-ai-models-it-was-about-infrastructure-53me > wpnews: https://wpnews.pro/news/google-i-o-2026-wasnt-about-ai-models-it-was-about-infrastructure According to the article, Google I/O 2026 focused less on AI models and more on the massive physical infrastructure required to run them, highlighting the immense energy and water consumption behind AI processing. The author notes that the event revealed how intelligence is becoming infrastructure, with every prompt carrying a physical cost, such as enough energy to power nearly 3 million light bulbs for a year. The article concludes that the defining tradeoff of this era will be balancing AI's productivity gains against the real-world costs of sustaining its physical consumption. This is a submission for the Google I/O Writing Challenge I actually appointed myself as AGI Police some days back. On account of the number of times I've found myself sipping AI slop milkshake. As a reformed individual (with regulated slop intake), I keep listening to Yann LeCun's insights through several notable podcasts. He constantly reminds us that “LLMs in general cannot predict the consequences of their actions.” Google I/O 2026 made an impact, with lots of exciting announcements. Training across the largest clusters in the world. Over 7x more tokens processed every month. Bigger infrastructure. Faster inference. More intelligence delivered instantly to billions of people. But somewhere in the middle of all the demos and applause, I found myself thinking less about the models and more about the machinery underneath them. So I asked Google AI Mode to help calculate the energy consumption behind large-scale token processing and compare it to something human-sized. Here is what we found out in less than 30 seconds of processing. We could power nearly 3 million light bulbs continuously, 24 hours a day, for an entire year. Let that sink in. What struck me wasn’t just the raw number itself. It was the inversion of intuition. AI feels weightless. You type words into a chat box and receive intelligence back in seconds. No smoke. No factory floor. No visible machinery. Just text appearing instantly on a glowing rectangle in your hand. But underneath that interface sits an industrial system consuming electricity, water, cooling infrastructure, and global semiconductor supply chains at unprecedented scale. Before I looked away, Gemini made another suggestion that made me even more curious. It suggested comparing the energy consumption with Nvidia infrastructure and also estimating the amount of water required to cool the servers powering the inference workloads. I indulged. And in less than 5 seconds (which means I was exaggerating when I said 30 seconds earlier), this happened: 457 million litres matches the total annual water footprint of roughly 1,200 average household families. At that point, the conversation stopped feeling like a fun experiment and started feeling like a glimpse into the physical economics of intelligence itself. The real takeaway from Google I/O wasn’t simply that models are getting smarter. It was that intelligence is becoming infrastructure. Every prompt now has a physical cost attached to it: And the strange part is that users rarely see any of it. What fascinated me most was how Gemini framed the answers. Instead of treating the numbers like an alarming revelation, it immediately contextualized them against broader industry infrastructure. The response was technically useful, but it also revealed something subtle about AI systems: they do not merely answer questions; they shape how scale is emotionally interpreted. The answer, although accurate, still felt slightly biased — almost like the system instinctively softened the psychological impact of the numbers by normalizing them within the broader AI race. And honestly, I understand why. Because the benefit of knowledge being delivered at our fingertips is genuinely incredible. A student can learn quantum mechanics from a village with weak infrastructure. A founder can prototype an idea in hours instead of months. A developer can debug systems faster than ever before. The productivity gains are real. But so is the cost. For years, software scaled mostly through abstraction. AI may be the first mainstream computing paradigm where scaling intelligence also means scaling physical consumption in the real world. That may ultimately become the defining tradeoff of this era. The question after Google I/O is no longer just: “How intelligent can these systems become?” But also: “What will it cost to sustain them?” --- ## Hermes Agent vs Openclaw > Published: 2026-05-24 02:58:43+00:00 > Source: https://dev.to/wanjohichristopher/hermes-vs-openclaw-2j4d > wpnews: https://wpnews.pro/news/hermes-agent-vs-openclaw In 2026, Hermes and OpenClaw are the two most-starred open-source AI agent frameworks on GitHub. A comparison article by WanjohiChristopher analyzes their features, performance, and community support to help developers choose between them. Hermes vs OpenClaw: The Two Most-Starred AI Agent Frameworks of 2026 WanjohiChristopher WanjohiChristopher WanjohiChristopher Follow May 22 Hermes vs OpenClaw: The Two Most-Starred AI Agent Frameworks of 2026 # ai # agents # opensource # comparison 1  reaction Comments Add Comment 6 min read --- ## Your Checkout Is Probably Leaking Revenue. The Problem Is You Cannot See Where. > Published: 2026-05-24 02:57:46+00:00 > Source: https://dev.to/xiden001/your-checkout-is-probably-leaking-revenue-the-problem-is-you-cannot-see-where-26kh > wpnews: https://wpnews.pro/news/your-checkout-is-probably-leaking-revenue-the-problem-is-you-cannot-see-where Based solely on the provided text, the article explains that most ecommerce teams know when checkout conversion drops but not why, as standard analytics only show where users leave, not the specific reasons for their hesitation or abandonment. It argues that checkout is a complex interaction surface where small technical issues like field errors or slow widgets create costly friction, and that teams need a diagnostic layer to identify these specific problems. The author introduces a tool called Checkout Friction Detector, which monitors behavioral patterns like dead clicks and validation failures to provide actionable alerts without recording user sessions. Most ecommerce teams know when checkout conversion is down. Very few know why. That gap is expensive. You can have strong traffic, good product pages, healthy add-to-cart rates, and a polished brand experience, then still lose a meaningful percentage of buyers during the final few steps. The worst part is that the usual analytics stack often tells you only that people dropped off, not what made them hesitate, rage click, retry a field, abandon a step, or give up completely. For business owners, this is a revenue problem. For engineers, this is an observability problem. And for ecommerce teams, it is one of the most overlooked places where small technical issues quietly become real commercial losses. It is easy to think of checkout as a simple sequence: In reality, checkout is a dense interaction surface. Every field, button, validation rule, third-party widget, browser autofill behavior, payment provider, shipping condition, discount code, and loading state can affect whether the customer completes the purchase. A buyer may abandon because: None of these issues necessarily look dramatic in a dashboard. But they add up. A checkout does not need to be broken to lose money. It only needs to create enough friction for a motivated buyer to pause, doubt, or leave. Most ecommerce teams already have some analytics installed. They can usually answer questions like: Those are useful questions, but they are not enough. Knowing that users dropped off between shipping and payment does not tell you whether they struggled with the postal code field, got stuck on shipping rates, rage-clicked a disabled continue button, or abandoned after a payment widget failed to load. Traditional analytics often gives you the map. What teams need is the diagnostic layer. That means understanding the actual interaction signals inside checkout: This is the difference between observing a funnel and understanding user friction. Session replay tools can be helpful. I have used them. Many teams do. But they also introduce a practical problem: someone has to watch the recordings. That does not scale well. For an ecommerce founder, watching dozens of sessions is not a good use of time. For a CRO specialist, it can become a noisy manual review process. For engineers, it often lacks the structured event data needed to reproduce and prioritize issues efficiently. There is also the privacy angle. Many brands, especially those selling in Europe or handling sensitive customer flows, are cautious about recording user sessions. Even when tools mask input values, the perception and compliance burden can still be a concern. Checkout needs something more focused. Not another dashboard. Not hundreds of recordings. Not vague aggregate metrics. It needs a direct signal: This field caused unusual hesitation. This button received dead clicks. This step saw repeated validation failures. This checkout path started showing abnormal abandonment. That is the layer I wanted to build. I built Checkout Friction Detector to help ecommerce teams identify the specific checkout interactions that may be costing them sales. The idea is simple: Install one script tag, then receive alerts and reports about checkout friction without recording sessions or collecting personal customer data. The tool monitors behavioral friction patterns such as: Instead of asking teams to dig through dashboards or watch recordings, it sends practical summaries that highlight where users are struggling. For business teams, the value is clarity. For technical teams, the value is signal. If you own or operate an ecommerce business, your checkout is one of the highest-leverage parts of your revenue system. You may already be spending money on: All of that effort is designed to bring people closer to purchase. But if checkout creates preventable friction, your acquisition budget is subsidizing lost revenue. That is what makes checkout optimization so powerful. You are not trying to create demand from scratch. You are improving the path for people who already showed buying intent. A small checkout improvement can have an outsized impact because it applies near the bottom of the funnel. The closer a customer is to purchase, the more expensive it is to lose them. For engineers, checkout friction is often difficult because the symptoms are distributed across frontend behavior, backend validation, third-party services, browser differences, device constraints, and business rules. A checkout issue might come from: The support ticket usually says something vague: “Some customers are having trouble checking out.” That is not enough. Engineers need better context: Checkout Friction Detector is designed to expose those signals in a way that is useful for debugging and prioritization. It does not replace logs, analytics, or error monitoring. It complements them by focusing on user-facing friction inside the checkout experience. Many checkout issues are not hard failures. A hard failure is obvious. Payment fails. The page crashes. An API returns an error. A user cannot proceed. Friction is more subtle. A user may technically be able to complete checkout, but the experience makes them work too hard. That is why friction often hides in plain sight. For example: None of these necessarily crash the app. But they can still cost conversions. This is where interaction-level monitoring becomes valuable. Checkout is sensitive. Customers are entering addresses, contact details, payment information, and personal buying intent. That means any analytics tool used in checkout should be careful by design. My approach with Checkout Friction Detector is simple: For example, the system does not need to know what a customer typed into a field. It only needs to know that a field caused repeated edits, hesitation, validation failure, or abandonment. That distinction matters. You can learn that a checkout field is causing friction without storing the customer’s private input. If you are building or optimizing an ecommerce checkout, these are the signals I would pay attention to. How long do users pause before completing a field? High hesitation may indicate confusion, poor labeling, unfamiliar requirements, or anxiety about why the information is needed. This is especially important for fields like: When users keep changing the same field, something may be unclear. Repeated edits can point to: Validation is necessary, but poor validation kills momentum. Track which fields produce the most errors, when those errors appear, and whether users recover after seeing them. A validation error that users recover from quickly may be acceptable. A validation error that leads to abandonment is a serious conversion risk. Rage clicks usually indicate frustration. In checkout, they often happen when: Dead clicks happen when users click elements that do not respond. This can reveal misleading UI, broken event handlers, confusing design, or missing feedback. Dead clicks are especially useful because they show where user expectation and product behavior diverge. Step-level abandonment is not new, but it becomes more useful when combined with interaction data. Knowing users abandon at the shipping step is useful. Knowing they abandon at the shipping step after repeated postal code validation failures is actionable. Imagine your checkout completion rate drops by 8% over two weeks. Your analytics show that the biggest drop-off is happening between shipping and payment. That is helpful, but still too broad. Now imagine you also know: That is no longer just a conversion issue. That is a clear investigation path. A business owner sees the revenue risk. An engineer sees where to inspect. A CRO specialist sees what to test. That is the kind of bridge checkout analytics should create. The biggest insight for me was that ecommerce checkout problems sit at the intersection of business, UX, and engineering. They are rarely owned by one function. Marketing drives the traffic. Design shapes the experience. Engineering builds the flow. Operations define shipping and payment rules. Support hears the complaints. Leadership sees the revenue impact. But the actual friction often lives between all of those teams. That is why visibility matters. When checkout issues are vague, teams debate opinions. When friction is measurable, teams can prioritize. Checkout Friction Detector is built for: It is especially useful for teams that want practical checkout insights without adding another heavy analytics dashboard or relying on session recordings. Ecommerce teams have spent years improving traffic acquisition. Better ads. Better targeting. Better landing pages. Better email flows. Better personalization. But the checkout experience is still where intent either turns into revenue or disappears. That final step deserves better observability. Not just conversion rates. Not just recordings. Not just dashboards. Actual friction signals. The kind that tell you where customers are struggling, what changed, and what needs attention. That is what I am building with Checkout Friction Detector. The goal is straightforward: Help ecommerce teams find and fix the checkout friction that quietly costs them sales. You can check it out here: --- ## Domain-Based C++ Logging With Nova > Published: 2026-05-24 02:54:53+00:00 > Source: https://dev.to/kleetus_mactavish/domain-based-c-logging-with-nova-o77 > wpnews: https://wpnews.pro/news/domain-based-c-logging-with-nova Nova is a new C++ logging library that uses compile-time types for logging domains instead of runtime string identifiers or global severity levels, enabling independent per-subsystem configuration and routing. The library includes Flare, an async-signal-safe crash logging component that writes structured records to disk without heap allocation or locks. Benchmarks show Nova performs competitively across realistic workloads, particularly in scenarios requiring deterministic behavior and bounded memory usage. Repository: https://github.com/kmac-13/nova/ Benchmarks: https://github.com/kmac-13/nova/blob/main/docs/BENCHMARKS.md I am pleased to announce the initial release of Nova - a modern C++ logging library focused on deterministic behavior, compile-time configurability, and flexible domain-based routing for systems ranging from hosted platforms down to bare-metal and safety-critical environments. There are already several quality C++ logging libraries available. However, most logging libraries organize routing and filtering around severity levels and rely on global logger configuration or runtime string-based logging categories. Engineers are often forced to encode subsystem behavior into a limited set of severity levels while also considering which thresholds will be enabled in production. This also leads to situations where enabling debug logging for one subsystem effectively requires enabling debug logging across unrelated areas of the application. Nova instead treats logging domains as compile-time types, allowing logging configuration and routing to directly reflect application structure rather than forcing subsystems into global severity categories. Domains can represent subsystems, modules, interfaces, classes, libraries, or any other domain-specific concept, and each domain can be independently enabled, disabled, or routed without reliance on shared global configuration. Because domains are independent types rather than shared string identifiers, libraries can define their own logging domains without interfering with application or third-party logging configuration. Additional goals of the library include: Nova also includes Flare, an async-signal-safe crash and forensic logging component that writes structured diagnostic records directly to disk from signal handlers - without heap allocation, locks, or non-signal-safe C++ runtime features. #include // define a domain (can be any type) struct MotionPlanner {}; // configure the domain with a name (MOTION), enabled state (true), and clock type (steadyNanosecs) NOVA_LOGGER_TRAITS( MotionPlanner, MOTION, true, kmac::nova::TimestampHelper::steadyNanosecs ); int main() { // configure motion planner sink as mpSink ... // bind the mpSink to the MotionPlanner logging domain kmac::nova::ScopedConfigurator config; config.bind< MotionPlanner >( &mpSink ); // log NOVA_LOG( MotionPlanner ) << "Planning trajectory..."; } Here we can see that the MotionPlanner domain is defined, the traits for the domain are configured, a target sink is bound to the domain, and logging is performed. In this example, the domain is a simple, empty struct, but a domain can be any type, including interface, abstract, or concrete classes. A domain can even be a specific class, and logging can be limited to the scope of that class. Using types as logging domains enables compile-time routing, strong subsystem separation, and per-domain configuration and enablement. Disabled domains can be eliminated entirely by the compiler, and type names prevent the silent runtime failures that string-based routing can introduce. Additionally, per-domain control means that enabling verbose logging for one subsystem has no effect on any other - there is no shared severity threshold to raise or lower across the entire application just to see detailed output from a single area. Nova has been benchmarked against several popular C++ logging libraries, including Quill and spdlog, using: The benchmarks intentionally normalize queue sizing and backend threading models to avoid structurally advantaging any particular library configuration. Results varied by workload, but several patterns consistently emerged: While Nova does not always achieve the highest theoretical front-end enqueue rate, it performed extremely competitively across a broad range of realistic workloads, especially where deterministic behavior and bounded memory usage are important. Full benchmark methodology and raw benchmark data are available in the repository. The initial release is now available at the repository linked above. I am still actively working on improving the library with additional features such as: I would appreciate feedback on any aspects of Nova (e.g. integration experience, cross-platform/compiler issues, feature requests). If you try Nova in a project, I’d love to hear how it performs and where it can improve. Thanks for reading. --- ## OpenCode Go + Oh My OpenAgent: The Model Routing Config That Actually Saves Money > Published: 2026-05-24 02:53:03+00:00 > Source: https://dev.to/devansh365/opencode-go-oh-my-openagent-the-model-routing-config-that-actually-saves-money-3jmj > wpnews: https://wpnews.pro/news/opencode-go-oh-my-openagent-the-model-routing-config-that-actually-saves-money The article explains that OpenCode Go's usage limits are based on dollar amounts ($12 per 5-hour window) rather than request counts, making model routing critical because different models offer vastly different request volumes for the same cost. It highlights that DeepSeek V4 Flash provides approximately 36 times more requests than GLM-5.1 for the same $12 budget, and recommends assigning specific models to tasks based on complexity to optimize spending. The piece also describes Oh My OpenAgent's three-layer architecture (Planning, Orchestration, and Execution) and notes that multi-agent workflows can consume 30-50 requests per complex task, quickly exhausting the budget if expensive models are used unnecessarily. Most guides on OpenCode Go start with the models. I want to start with the thing most guides get wrong: the limits are denominated in dollars, not requests. That sounds like a minor distinction. It isn't. ## The thing everyone misses OpenCode Go costs $5 for the first month, then $10/month. Your usage cap is $12 per 5-hour window, $30/week, $60/month. When you spend $12 in a 5-hour window on DeepSeek V4 Flash, you get approximately 31,650 requests. When you spend the same $12 on GLM-5.1, you get around 880. Same budget. 36x difference in volume. This is why routing actually matters. If you pick one model and use it for everything, you are either burning premium requests on tasks that don't need them, or you are under-using cheap models that are surprisingly capable. The right move is assigning models to tasks based on what each task actually requires. MiniMax M2.5 has a hard cap of 100,000 requests per month regardless of cost. It activates only ~10B parameters and is priced at 16.7x cheaper than Claude Opus 4.6 on input tokens. For high-volume low-complexity work, it is the obvious choice, and most people don't know it exists. ## What you lose running on a single premium model Say you put everything through DeepSeek V4 Pro: 10,200 requests per 5-hour window. That sounds fine for light use. But Oh My OpenAgent runs multiple agents in parallel. Prometheus decomposes your task, Metis synthesizes context, Atlas manages sequencing, Sisyphus runs execution, and the Librarian reads docs. A single complex task can fan out into 30-50 requests without you doing anything. Your 5-hour budget evaporates in a few hours of active work. The problem isn't the quality gap. V4 Pro at 80.6% is within 7 percentage points of Claude Opus 4.7 at 87.6%, and for most routine tickets that gap is invisible. The problem is you don't need that quality for every step of a multi-agent workflow. ## The tier breakdown with actual numbers Here is what the available models score on benchmarks that matter for coding tasks, plus the API pricing that drives the routing math: | Model | SWE-Bench Verified | Input price (per M tokens) | Requests/5hrs ($12) | Context | |---|---|---|---|---| | Claude Opus 4.7 | 87.6% | $5.00 | ~480 | 200K tokens | | DeepSeek V4 Pro | 80.6% | $0.435 (promo, ends May 31) | ~5,500 | 1M tokens | | Kimi K2.6 | 80.2% | $0.95 | ~2,500 | 256K tokens | | Claude Sonnet 4.6 | 79.6% | $3.00 | ~800 | 200K tokens | | MiMo-V2.5-Pro | 78.9% | ~$0.40 | ~6,000 | — | | Qwen3.6 Plus | 78.8% | $0.325 | ~7,400 | 1M tokens | | DeepSeek V4 Flash | ~79.0% | $0.14 | ~17,000 | 1M tokens | | GLM-5.1 | SWE-Bench Pro 58.4% | ~$1.50 | ~1,600 | 200K tokens | | Qwen3.5 Plus | — | $0.08 | ~30,000 | — | | MiniMax M2.5 | — | $0.03 | up to 100K/month | — | *(Requests per 5-hour window calculated at roughly 2,500 average tokens per request.)* Note:Kimi K2.6 original series was discontinued on May 25, 2026. The model itself stays available but the series is no longer receiving updates. DeepSeek V4 Pro's promotional pricing ($0.435/M) ends May 31 — after that the price increases, which changes the requests-per-window math. Claude Opus 4.7 at 87.6% is genuinely the strongest model available for coding tasks right now, 7 points above V4 Pro. But at $5/M tokens, it costs 35x more than DeepSeek V4 Flash per token. Within the $12/5hr window, you get around 480 Opus 4.7 requests vs 17,000 Flash requests. DeepSeek V4 Flash sits within one point of V4 Pro in benchmark performance but at about 3x lower cost per token. For most routine coding tasks, that gap does not show up in practice. V4 Flash runs 284B total parameters with 13B active. V4 Pro runs 1.6T total with 49B active. Kimi K2.6 is a 1-trillion-parameter MoE model with 32B active parameters, 80.2% SWE-Bench Verified. That puts it above Qwen3.6 Plus and close to V4 Pro, making it the right choice for genuinely hard multi-step reasoning when V4 Flash stalls. GLM-5.1 sits at 744B total / 40B active. Its 200K context makes it suitable for deep planning tasks, and it handles the Oracle and Prometheus roles well at a mid-range cost point. ## How Oh My OpenAgent is structured Oh My OpenAgent v4.2.3 (as of May 2026, with 48K+ GitHub stars) uses a 3-layer architecture: **Planning Layer** handles strategic decomposition and knowledge synthesis. Two agents: Prometheus (breaks down what needs to happen) and Metis (synthesizes context and prior knowledge). **Orchestration Layer** is Atlas. It maintains a todo-list, enforces sequencing, and tracks completion. It does not do the work itself. It manages what gets done in what order. **Execution Layer** is where the work happens. Sisyphus is the default orchestrator with a 32K extended thinking budget. Nine or more specialized agents handle specific task types. v4.0.0 introduced Team Mode, which activates 7 additional hooks (61 total vs 54 in standard mode). Team Mode is worth enabling if you are running parallel workstreams. It is off by default. ## The routing configuration This is the community-recommended agent-to-model assignment. It is the result of a lot of trial and error, not theory: | Agent | Primary Model | Fallback | |---|---|---| | Sisyphus | Kimi K2.6 | DeepSeek V4 Pro, then Qwen3.6 Plus | | Hephaestus | DeepSeek V4 Pro | DeepSeek V4 Flash, then Kimi K2.6 | | Oracle | GLM-5.1 | Kimi K2.6, then DeepSeek V4 Pro | | Librarian | DeepSeek V4 Flash | Qwen3.5 Plus | | Explore | DeepSeek V4 Flash | none | | Prometheus | GLM-5.1 | Qwen3.6 Plus, then DeepSeek V4 Pro | | Metis | Qwen3.6 Plus | DeepSeek V4 Pro | | Atlas | DeepSeek V4 Pro | DeepSeek V4 Flash | | Code-reviewer | Kimi K2.6 | DeepSeek V4 Pro | | Multimodal-Looker | MiMo-V2.5-Pro | Qwen3.6 Plus | Sisyphus gets Kimi K2.6 because it runs extended thinking at up to 32K tokens. You want the strongest reasoning model here, even at lower volume. Kimi's 256K context window handles long execution traces. Librarian and Explore get V4 Flash. These agents read docs, fetch context, and do lookup work. They do not need frontier-level reasoning. Wasting V4 Pro on Librarian is the single most common budget mistake I see. Oracle and Prometheus both get GLM-5.1. Planning and deep reasoning are where GLM-5.1 earns its slot. It is not the cheapest model, but it is not the most expensive either, and it performs well on the kinds of open-ended decomposition tasks these agents handle. Hephaestus (the primary coding agent) gets V4 Pro as primary with V4 Flash as fallback. The gap between them is small enough that on simpler coding tasks, falling back to Flash costs you nothing visible. MiMo-V2.5-Pro on Multimodal-Looker is deliberate. It scored 78.9% on SWE-Bench Verified and is specifically designed for agentic workflows. ## The routing decision rule Route through V4 Flash first for any task that will exceed 100 requests. Escalate to Kimi K2.6 or V4 Pro only if V4 Flash gets stuck. This works because V4 Flash at 79.0% SWE-Bench Verified handles the majority of real-world coding tasks correctly. The one-point gap to V4 Pro is real but rarely shows up unless you are hitting genuinely hard tickets. When it does, the fallback chain handles it. Do not escalate preemptively. Let the model fail first, then escalate. Preemptive escalation is how you burn through your window in an hour. ## What $10/month actually buys At $60/month hard cap (the monthly ceiling), here is the math: - ~5 active hours per day across 5 working days = 25 hours of active window time - Each 5-hour window: $12 budget - Routed correctly, a typical Oh My OpenAgent session on a medium-complexity feature might use 400-600 requests, weighted toward V4 Flash and Qwen3.5 Plus In practice: you can run 8-12 substantial coding sessions per month before feeling the ceiling. For individual developer use, $10/month is genuinely enough. OpenCode hit 150K GitHub stars in May 2026 in part because that math works out. The realistic comparison: Claude API at similar quality levels would cost $150-300/month for the same volume. That is where the 10-20x cost reduction claim comes from, and in my experience it holds. ## The honest trade-off The gap between this stack and Claude Opus 4.7 on real-world bug fixes is about 7 percentage points. That is real. Some tickets require multiple iterations where Claude would have gotten it right once. Budget for that. The 7-point gap is an average across all task types. On well-scoped tickets with clear acceptance criteria, the gap narrows significantly. The routing configuration is specifically designed to escalate to Kimi K2.6 or V4 Pro on the tasks where that gap is most likely to show up. Where this stack genuinely struggles: ambiguous requirements, complex multi-file refactors with implicit dependencies, and tasks that require understanding undocumented system behavior. On those, premium models earn their cost. The routing configuration handles this by putting Kimi K2.6 on the hardest tasks, but Kimi has a 256K context window vs Qwen3.6 Plus's 1M, so very long context tasks may require a different allocation. ## The actual configuration Two files control everything: `opencode.json` at your project root, and `.omc/config.json` for Oh My OpenAgent routing. `opencode.json` ``` { "$schema": "https://opencode.ai/config.schema.json", "theme": "opencode", "autoshare": false, "model": "deepseek-v4-flash", "providers": { "opencode": { "models": [ "deepseek-v4-pro", "deepseek-v4-flash", "kimi-k2.6", "glm-5.1", "qwen3.6-plus", "qwen3.5-plus", "mimo-v2.5-pro", "minimax-m2.5" ] } } } ``` The `"model"` field sets your default. V4 Flash is the right default because it handles most tasks at lowest cost. `.omc/config.json` ``` { "version": "4.2.3", "teamMode": false, "agents": { "sisyphus": { "model": "kimi-k2.6", "fallback": ["deepseek-v4-pro", "qwen3.6-plus"], "thinkingBudget": 32000 }, "hephaestus": { "model": "deepseek-v4-pro", "fallback": ["deepseek-v4-flash", "kimi-k2.6"] }, "oracle": { "model": "glm-5.1", "fallback": ["kimi-k2.6", "deepseek-v4-pro"] }, "prometheus": { "model": "glm-5.1", "fallback": ["qwen3.6-plus", "deepseek-v4-pro"] }, "metis": { "model": "qwen3.6-plus", "fallback": ["deepseek-v4-pro"] }, "atlas": { "model": "deepseek-v4-pro", "fallback": ["deepseek-v4-flash"] }, "librarian": { "model": "deepseek-v4-flash", "fallback": ["qwen3.5-plus"] }, "explore": { "model": "deepseek-v4-flash", "fallback": [] }, "code-reviewer": { "model": "kimi-k2.6", "fallback": ["deepseek-v4-pro"] }, "multimodal-looker": { "model": "mimo-v2.5-pro", "fallback": ["qwen3.6-plus"] } }, "routing": { "escalationPolicy": "on-failure", "budgetAlert": 10.00, "windowBudget": 12.00 } } ``` `escalationPolicy: "on-failure"` enforces the core rule: models escalate only when the primary fails, not preemptively. `budgetAlert` triggers a warning at $10 so you know you have $2 left in the window before the ceiling hits. ## Quick start ``` # Install OpenCode Go npm install -g opencode # Install Oh My OpenAgent npx omc install oh-my-openagent # Create opencode.json and .omc/config.json from the templates above, then: omc init --preset oh-my-openagent # Check your current window spend opencode usage --window current ``` Knowing where you are in the $12 window changes how aggressively you escalate to premium models. For a deeper walkthrough of the original configuration approach, the guide that got me started is Jatin Malik's post: [OpenCode Go + Oh My OpenAgent: The Complete Guide to SOTA Model Routing Without Hitting Limits](https://medium.com/@jatinkrmalik/opencode-go-oh-my-openagent-the-complete-guide-to-sota-model-routing-without-hitting-limits-49fdc8cb3417) --- ## Seven Types of Data Extensions We Use on SFMC Projects > Published: 2026-05-24 02:52:26+00:00 > Source: https://dev.to/sapotacorp/seven-types-of-data-extensions-we-use-on-sfmc-projects-83o > wpnews: https://wpnews.pro/news/seven-types-of-data-extensions-we-use-on-sfmc-projects The article summarizes seven types of Data Extensions (DEs) in Salesforce Marketing Cloud (SFMC), including Sendable DEs for email campaigns, Lookup DEs for reference data, Filtered DEs for point-and-click segmentation (which require manual refreshing), Random Split DEs for A/B testing, Shared DEs for cross-Business Unit access, Send Log DEs for tracking email sends, and DEs with Retention Policies for auto-purging old data. It emphasizes that understanding these distinctions—such as not using a Lookup DE for sending or forgetting to refresh a Filtered DE—prevents costly architecture mistakes. The article concludes that most projects use a mix of these types, and correctly identifying the DE type before creation saves significant time versus fixing errors later. "Data Extension" is the generic term, but SFMC supports several DE types with different behaviors. Knowing the distinctions saves you from trying to send email from a lookup DE or forgetting to refresh a Filtered DE before a campaign. Here's the reference we hand to every new engineer. The main type used for sending email. Requirements: This is the DE you pick when you send a campaign or set up a Journey with Data Extension entry source. No send can happen without one. Reference data that AMPscript Lookup() pulls into email templates at render time. Common examples: Not sendable, no EmailAddress field needed. Used by the email, not as the source of the send. A DE created by applying a Data Filter to another DE - point-and-click segmentation without SQL. Example: "subscribers from Master_DE where MemberTier = Gold" produces a Gold-only Filtered DE. Important: Filtered DEs need to be refreshed to reflect the current state of the source DE. They don't auto-update. Refresh via: If the source DE changes (new imports, updates) but the Filtered DE isn't refreshed, the Filtered DE holds stale data. Campaigns targeting it send to outdated segments. For anything more complex than single-attribute filtering (joins, calculations), use SQL Query Activity writing to a standard DE, not a Filtered DE. Splits a source DE into N equal random chunks. Use case: A/B/N testing where you need 10 equal groups to test 10 email variants. No SQL needed. Configure the split percentages in the UI; SFMC assigns rows randomly. Caveats: A DE placed in the Shared Data Extensions folder in the parent Business Unit. Multiple child BUs in the Enterprise account can access the DE without copying it. Use when: Access permissions are set via Shared Data Extension Permissions - which BUs can read/write. Watch for unintended cross-BU writes: if two BUs can write to the same Shared DE, coordinate schemas and import schedules. A special DE that logs every email send - who received what, when, subject line, etc. Useful for: Created from the TriggeredSendDataExtension template when used with Triggered Sends. Caveat: Test Sends don't write to Send Log. Only production sends do. If you're testing and expecting the Send Log to populate, it won't. Any DE can have a retention policy configured on creation: Use for: Set retention at creation if possible. Adding it later works but doesn't apply retroactively to existing rows until the next automation evaluation. NeedDE TypeSend email from this listSendableReference data AMPscript will look upLookupSimple attribute-based segmentFilteredA/B test random splitsRandomCross-BU shared referenceSharedAudit / custom trackingSend LogAuto-purge old dataDE with Retention Policy Most projects end up with a mix: one or two Sendable DEs, several Lookup DEs, possibly a Shared DE for multi-brand setups, and retention policies on anything transient. Naming the DE type right in your head before creating it prevents architecture rebuilds. The decision takes seconds; fixing an incorrectly-typed DE after it's been loaded with data can take a day. Designing SFMC data architecture? Our Salesforce team ships Data Extension layouts, shared-BU patterns, and retention strategies on production engagements. Get in touch -> See our full platform services for the stack we cover. --- ## Rollup vs calculated columns in Dataverse: the async trap we fell for > Published: 2026-05-24 02:52:20+00:00 > Source: https://dev.to/sapotacorp/rollup-vs-calculated-columns-in-dataverse-the-async-trap-we-fell-for-1mh1 > wpnews: https://wpnews.pro/news/rollup-vs-calculated-columns-in-dataverse-the-async-trap-we-fell-for The article explains the critical difference between calculated and rollup columns in Dataverse, highlighting that rollup columns update on a configurable schedule (default every 12 hours, minimum every hour), while calculated columns compute values in real-time when a row is read. The authors describe a real-world scenario where a team mistakenly assumed a rollup column provided real-time totals, leading to stale data on a deal dashboard. They then present three alternatives for achieving current aggregate data: using a plugin to update totals on child record changes, employing a calculated column on child records for read-time aggregation, or adding a manual refresh button to trigger rollup recalculation. A deal desk dashboard showed the running total of opportunities per account. Total amount per account was a rollup column. Users opened the dashboard, saw a total, made a decision. Then someone added a new opportunity and checked the same account. The account's total did not change. Fifteen minutes later, refresh - still not changed. An hour later - changed. The rollup column was working exactly as documented, and the team had mistaken it for a real-time aggregate. Here is the difference between calculated and rollup columns, and the pattern we now use when the dashboard needs to be current. Calculated column: computes its value every time the row is read. If the column adds two other columns, every time anything loads the row (form view, API call, view row), Dataverse computes the sum. Results are always current because they are re-derived on demand. Rollup column: computes its value on a schedule. The default schedule is every 12 hours, configurable down to one hour per column. A rollup that sums child record amounts reads the current state of children when the schedule fires, stores the result, and serves that stored value until the next schedule. Both store their definition (the formula) in the solution. Both look identical to consuming code. The runtime behavior is radically different. Calculated columns are correct when: Rollup columns are correct when: A calculated column that aggregates children is not allowed. Dataverse blocks it - the reason is performance, reading an account would trigger a query across all its opportunities every load. Rollup is the platform's answer: compute the aggregate ahead of time, serve it cached. Teams who want a rolling total of child records are usually asked for it by a business user who sees the number on a dashboard and expects it to match reality. When a user tells the team "the total on the Account form should show all linked Opportunity amounts," the team builds a rollup column. The dashboard shows the rollup. The user then creates an opportunity, looks at the account, and the total is stale. From the user's perspective, the number is wrong. From the platform's perspective, the number is accurate for the last time the schedule fired. The fix is either to lower the user's expectations (the dashboard updates on a schedule) or to change the implementation. When the aggregate genuinely needs to be current: Alternative 1: plugin that updates a stored total on every child change. A post-operation plugin on Opportunity (Create, Update on amount, Delete) recalculates acme_total_opportunities on the parent Account and writes it. Works for modest volumes - an account with 200 opportunities, each updating rarely, is fine. Fails for accounts with 20,000 opportunities updating frequently - every child change becomes a parent write, and the Dataverse execution pipeline starts throttling. Good for: master-detail relationships with medium fanout. Alternative 2: calculated column summing via the lookup. You cannot aggregate children from a parent via a calculated column, but you can compute the child's contribution per row using a calculated column on the child. acme_attributable_amount = IF(acme_is_counted, amount, 0) on Opportunity, then use that in any consumer query. The consumer does the aggregation at read time. Works for: dashboards that can run FetchXML with aggregate operators (SUM the acme_attributable_amount across children in a single query). Fails if the consumer is a Dataverse form or view that cannot run aggregate queries. Good for: Power BI reports, custom dashboards, anywhere you control the read query. Alternative 3: rollup with one-hour schedule plus "Refresh" button. Keep the rollup for the baseline case. Add a button on the form that explicitly triggers a rollup recalculation via the CalculateRollupField SDK request. User experiences it as "I just added a child, now I hit Refresh, the total updates." Works for: dashboards with bursty usage patterns - the baseline is acceptable, explicit refresh covers the "just changed it" case. Good for: sales management screens, deal desk reviews, scenarios where users understand the refresh semantics. On any project with more than three rollup columns, we audit quarterly: The audit takes 20 minutes per project. Half the time, at least one rollup can be deleted; a third of the time, at least one schedule needs adjusting. A rollup of child-record amounts updates when a child is created or its amount changes. It does not update when a child is deleted, until the scheduled refresh fires. The window between "child deleted" and "rollup refreshed" shows an overstated total. This is especially painful in audit scenarios - a user deletes a duplicate, the total still shows the duplicate's contribution for up to twelve hours. The fix is either a plugin on the child Delete event (post-operation, trigger a rollup recalculation explicitly via CalculateRollupFieldRequest) or a tighter schedule. We usually go with the plugin when the table supports deletions, because the time-lag is user-visible. Rollup columns ship with a form tooltip: "This total refreshes every N hours. Click Refresh after adding new records to see updated totals immediately." The tooltip is one field-description line, it costs nothing to add, and it inoculates the "why is the number stale" ticket that would otherwise land every other week. Every rollup we ship has it. Every one we inherit gets it added on the first pass. --- ## MES integration with D365 Supply Chain: Azure middleware pattern > Published: 2026-05-24 02:52:14+00:00 > Source: https://dev.to/sapotacorp/mes-integration-with-d365-supply-chain-azure-middleware-pattern-4698 > wpnews: https://wpnews.pro/news/mes-integration-with-d365-supply-chain-azure-middleware-pattern The article explains that integrating a Manufacturing Execution System (MES) with Dynamics 365 Supply Chain Management requires low-latency, high-throughput, and reliable data flow, which cannot be achieved by batch jobs, OData polling, or direct database triggers due to their documented failure modes. The recommended solution is an Azure middleware pattern using Service Bus for guaranteed messaging, Logic Apps for orchestration, and F&O Business Events for bidirectional, real-time synchronization. This architecture ensures traceability and scalability by maintaining data correlation and supporting high event volumes without lost messages. Manufacturers running Dynamics 365 Supply Chain Management almost always also run a dedicated Manufacturing Execution System (MES) on the shop floor. Production order updates, inventory movements, quality tests, and traceability data flow between them continuously. The integration has to be low-latency (shop floor runs on seconds, not hours), high-throughput (hundreds of events per minute at peak), and reliable (lost messages mean lost traceability). Three integration patterns come up in evaluations. Two have documented failure modes. Nightly batch jobs via Data Management Framework. Designed for bulk data movement, not real-time signaling. Production orders complete hours before D365 knows about it. Real-time inventory view is always lagging. Traceability data arrives after the batches have shipped. Custom OData polling with a loop that queries MES every few seconds. Introduces polling overhead for no latency benefit, and MES systems aren't typically designed to handle heavy poll loads. Also creates a custom code dependency that needs maintenance. Database-level triggers on the MES database pushing directly to F&O's database. Breaks supportability completely. D365 F&O is a managed platform - direct database writes aren't supported, aren't upgrade-safe, and will break the next time Microsoft changes schema. Also creates a security nightmare (MES has privileged write access to F&O's database?). The only answer that fits the requirements is Azure middleware between the two systems. Logic Apps or Service Bus as middleware between MES and D365, with F&O Business Events on the D365 side. What each piece does: Azure Service Bus for the guaranteed-delivery, ordered messaging. Production-order status updates, inventory moves, quality-test results flow through Service Bus queues with FIFO ordering per production order. Azure Logic Apps for the orchestration where branching and transformation happen. A pick-complete event from MES fires a Logic App that transforms the payload, updates inventory in D365, and triggers the next production-flow message back to MES. F&O Business Events for the D365-side publishing. When a production order is created, released, or completed in F&O, a business event fires to Service Bus or Event Grid. MES subscribers pick it up. Custom Services on F&O for the inbound - when MES has a state change D365 needs to record, the Logic App (or Function) calls a custom service endpoint on F&O. Custom services are designed for low-latency targeted writes, unlike data entities which are bulk-optimized. Traceability is specific in manufacturing - regulators and customers need to know which raw materials went into which finished-goods batch. D365's batch tracking combines with MES's shop-floor batch recording to produce the full lineage. The integration ensures: The integration isn't just about moving data - it's about keeping the correlation intact under all failure modes. At manufacturing scale (large plants with multiple lines, each firing events per minute), throughput planning matters: Manufacturing can't afford lost messages. The architecture carries: Flows in each direction have different shapes: MES → D365 (updates ERP from shop floor): D365 → MES (issues work to shop floor): Bidirectional correlation: Not everything is Logic Apps. Sometimes: Each has a clear use case. Reach for them when the declarative tool hits a limit, not as default. A working MES-to-D365 integration has: The pattern is architect-grade because manufacturing systems won't tolerate the simpler options. Azure middleware is the supported, scalable, maintainable middle. --- ## Custom API vs Custom Action vs Azure Function: Dataverse decision > Published: 2026-05-24 02:52:09+00:00 > Source: https://dev.to/sapotacorp/custom-api-vs-custom-action-vs-azure-function-dataverse-decision-2lo4 > wpnews: https://wpnews.pro/news/custom-api-vs-custom-action-vs-azure-function-dataverse-decision Here is a factual summary of the article: The article compares three methods for implementing business logic in Microsoft Dataverse—Custom Actions (legacy), Custom APIs (modern), and Azure Functions—focusing on their latency, cost, concurrency, and maintenance profiles. Custom APIs are recommended for most new Dataverse-heavy operations due to their low latency, inclusion in existing licensing, and first-class integration with Power Automate, while Azure Functions are better suited for long-running or external-dependency-heavy work despite higher latency and separate compute costs. The author provides a decision matrix and practical guidance, including a case study where a Custom API was chosen over Azure Functions for a loyalty rebate calculation triggered on order creation. A client needs to expose a "calculate the loyalty rebate for this customer" operation. It reads three Dataverse tables, applies some business rules, writes a result. Every consumer - the Dynamics web app, a Power Automate flow, an external integration - should call the same operation. Three places we could put it. Three different cost, latency, and scale profiles. Here is the matrix we now run on every "new operation" request. Custom Action (legacy): a process defined in Dataverse that can be invoked through the SDK. Steps are Workflow Activity Actions. Old-school but still widely deployed. Custom API (modern): the successor to custom actions. Defined as Dataverse entity rows (customapi, customapiRequestParameter, customapiResponseProperty), backed by a plugin that implements the logic. Exposed through the Web API with a typed OpenAPI schema. Azure Function: fully external .NET function, invoked from Power Automate or direct HTTP. Runs in its own compute, scales separately, has its own pricing. The three solve overlapping problems. The choice is about latency, cost structure, and who maintains the code. DimensionCustom ActionCustom APIAzure FunctionLatencyLow (in-process)Low (in-process)Medium (cross-service)Concurrency limitDataverse'sDataverse'sFunction App'sTimeout2 minutes2 minutes10 minutes (Consumption), configurable higherCostIncluded in DataverseIncluded in DataversePer-execution + computeLong-running workNoNoYes (durable functions)External dependency callsLimited (sandbox)Limited (sandbox)Full flexibilityOpenAPI schemaNoYesManualInvocable from flowYesYes (first-class)Yes (HTTP connector)Maintenance.NET + Workflow.NET.NET (preferred) Custom Action is correct when you are maintaining an existing system that already uses them. For new work, skip them - custom APIs are the modern equivalent with better tooling. Custom API is correct when: Azure Function is correct when: Custom APIs consume Dataverse capacity. A high-volume custom API (tens of thousands of calls per day) is paid for by your existing Dataverse licensing - no incremental per-call charge. Azure Functions on Consumption plan: $0.000016 per GB-second and $0.20 per million executions. A typical custom function costing 128MB for 300ms runs at roughly $0.00000006 per call. A million calls per month is around $0.25 in compute plus $0.20 in executions - effectively free. The cost math usually favors custom API for Dataverse-heavy work and Azure Function for external-dependency-heavy work. Mixing the two via a custom API that calls a function (rare pattern) pays both bills. Custom API gotcha: the plugin that implements a custom API registers against a synthetic "Custom API message" step. Debugging is via plugin trace logs, same as any plugin. Deployment is through the solution. OpenAPI schema is auto-generated from the custom api row definitions - mis-typing a parameter name once in Dataverse and once in the plugin code produces a runtime failure that the solution checker does not catch. Azure Function gotcha: cold start on Consumption plan can add 2-5 seconds for the first call after idle. For a user-facing interactive call, this is unacceptable. Options: Premium plan (always warm, higher baseline cost), Dedicated App Service plan, or accept the cold-start delay if the call is async. Authentication gotcha for Azure Function: calling Dataverse from an Azure Function requires auth. The cleanest pattern is a managed identity on the Function App with an application user in Dataverse. Tutorials that use a user's personal credentials in app settings are security incidents waiting to happen. Requirement: "Calculate and apply a loyalty rebate on every Order created." Walking the matrix: Custom API won clearly. Implementation was a plugin registered against a custom API definition, called from both a post-operation plugin on Order Create (synchronous, blocks save) and directly from a Power Automate flow (for retroactive recalculation). A year later, the client wanted to integrate with an external tax service that takes 3-4 seconds per call. We did not put that in the same custom API - the 2-minute timeout plus the unpredictability of the external service made it fragile. We built a separate Azure Function for the tax call, invoked async from a Power Automate flow. Two tools for two different latency profiles, as it should be. If the operation stays inside Dataverse, start with a custom API. You get latency, integrated ALM, and zero incremental cost. You can always move it to an Azure Function later if the requirements shift. If the operation has any external dependency with unpredictable behavior, start with an Azure Function. You get the durability patterns and the 10-minute timeout that the Dataverse sandbox cannot give. If you find yourself using custom actions for new work, stop. Custom APIs have everything custom actions did plus a schema and better tooling. --- ## Cutting agent latency from 30s to 8s without model swap > Published: 2026-05-24 02:52:03+00:00 > Source: https://dev.to/sapotacorp/cutting-agent-latency-from-30s-to-8s-without-model-swap-256j > wpnews: https://wpnews.pro/news/cutting-agent-latency-from-30s-to-8s-without-model-swap The article describes how a team reduced their AI agent's p95 response latency from 31 seconds to 8 seconds and cut user abandonment by 70% without changing the underlying model. The improvements came from four structural changes: making independent tool calls concurrent (saving 3.3 seconds), removing an unnecessary critic LLM step (saving 3 seconds), and implementing streaming to improve perceived latency. The key insight is that the model itself accounted for only 35% of the total latency, while the remaining 65% came from sequential tool calls, redundant LLM steps, and missing streaming. A founder pinged us with a UX problem disguised as an engineering question. His team had launched an AI chat product. Users were abandoning the conversation before the agent finished responding. The team had measured p95 response latency at 31 seconds. Their assumption was that they needed to switch to a faster model. The actual model was responsible for about 35% of the total latency. The other 65% was sequential tool calls, unnecessary intermediate LLM steps, and a missing streaming layer. Switching to a smaller model would have cut maybe 5 seconds off the worst case while degrading response quality. We made four changes that did not touch the model. P95 latency dropped from 31 seconds to 8 seconds. User abandonment rate dropped 70%. The model stayed the same. This is the latency stack that most teams either do not measure or do not know how to optimize. Here is the pattern. Before any optimization, instrument the agent and trace where time is spent. The breakdown for a typical multi-step agent looks something like: The LLM call portion is hard to optimize without changing the model. The other 50-70% is where most of the win is, and most teams do not look there because the LLM feels like the obvious bottleneck. The founder's agent had: Total p95 was 31 seconds. The model was responsible for 11 seconds of that. The other 20 seconds were structural. The biggest win in most agent systems is making tool calls concurrent. The founder's agent had a step where it needed to look up the user's account information, the customer's order history, and the related support tickets. The original code did this sequentially: Total: 5.3 seconds, all wait time. The fix was async-await with parallel dispatch: That single change saved 3.3 seconds per request. The actual code change was 8 lines. The pattern: any time the agent calls multiple tools and the results are independent, those tool calls can run concurrently. Use asyncio.gather in Python, Promise.all in JavaScript. Modern agent frameworks (LangGraph, CrewAI Flows) support this natively. Audit your agent for serial tool calls that could run in parallel. There is almost always one or two. The original agent had a planner LLM that generated a plan, then a separate critic LLM that reviewed the plan, then the executor. The critic was rejecting roughly 8% of plans, which meant 92% of the time it was an extra LLM call (3 seconds) for nothing. And of the 8% it rejected, the planner produced a similar plan on the next iteration anyway, suggesting the critic was not adding much real value. We removed the critic, kept the planner, and added validation rules instead (does the plan reference real tools, does it have any cycles, does it stay under the step limit). The validation runs in milliseconds, not seconds, and catches the same class of bad plans the critic was catching. 3 seconds saved per request, on average. Quality measured no different on the eval set. The pattern: every LLM call in the chain should be earning its keep. If a step rejects only a small fraction of inputs and the alternative is a deterministic check, the deterministic check is faster and usually as good. The original agent waited for the full response to be generated before returning anything to the user. The user saw a loading spinner for 31 seconds, then the full response appeared. Streaming changes the perceived latency dramatically. The user starts seeing tokens within 1-2 seconds, even if the full response takes 8. The agent is not actually faster, but the UX feels faster, and abandonment rate drops because users get visible feedback. The implementation is a few lines of code. The OpenAI and Anthropic APIs both support streaming natively. The frontend needs to handle server-sent events (SSE) or websockets. The user experience improvement is large and immediate. For multi-step agents, you can also stream intermediate progress: "Looking up your account... Checking order history... Generating response..." This is qualitatively different from a spinner. Users will wait 8 seconds for visible progress; they will not wait 8 seconds for a spinner. Some queries repeat. Some intermediate steps repeat across queries. Both are cacheable. The founder's agent had a "policy lookup" tool that retrieved from a small KB of company policies. The policies changed maybe once a month. The agent was hitting the KB and running a vector search every time. We added a simple in-memory cache with a 5-minute TTL. The cache hit rate was 35%, saving 0.8 seconds per cached request. Semantic caching is the more advanced version: cache LLM responses keyed on the embedding of the query. If a new query is semantically similar to a recent one, return the cached response. We use this carefully (only for queries with high confidence and low staleness risk), but it can save 5+ seconds on cache hits. Aggressive caching: every tool call and every LLM call should be evaluated for cacheability. Most are. Most teams do not bother. The latency improvement compounds. After all four changes: User abandonment rate dropped 70% in the first two weeks. Customer satisfaction scores went up. The model and the agent's core logic did not change. The team's original instinct (switch to a smaller model) would have saved maybe 5 seconds while degrading quality. The structural changes saved 23 seconds while keeping quality the same. Before approving "switch to a faster model" as the latency fix, walk through: Most agent systems have 50-70% latency improvement available without touching the primary model. Audit before you swap. Switching to a smaller, faster model can be the right call for some agents. But it is the last resort, not the first. The cost is response quality, and that cost is permanent. The structural improvements are free. The pattern Sapota recommends: optimize the structure first, measure the new latency, then decide whether a model swap is still needed. Often it is not. When it is, you have a much smaller gap to close, and the trade-off is more justified. If your team has launched an AI agent and users are abandoning conversations before the response arrives, the issue is rarely the model. It is usually the structure. Sapota offers a one-week latency audit that traces your agent's actual time spent, identifies the parallelizable tool calls, the removable LLM steps, and the missing caching opportunities, and ships the optimizations as working code. We have done this for chat products, customer support tools, and research assistants. The typical improvement is 60-75% latency reduction without changing the model. Reach out via the AI engineering page with your current p95 latency and a sample trace if you have one. If you do not have traces, we will install observability first and audit second. --- ## When recall plateaus: the late-interaction technique most teams skip > Published: 2026-05-24 02:51:57+00:00 > Source: https://dev.to/sapotacorp/when-recall-plateaus-the-late-interaction-technique-most-teams-skip-54o4 > wpnews: https://wpnews.pro/news/when-recall-plateaus-the-late-interaction-technique-most-teams-skip The article explains that many teams hit a recall ceiling with RAG systems because they rely on bi-encoder embedding models, which compress entire text chunks into a single vector and lose fine-grained detail. The solution is to use late-interaction techniques like ColBERT, which preserve per-token embeddings and compute relevance through maximum similarity scoring, often boosting recall from 58% to 81% in a single afternoon. The article also describes two deployment patterns for ColBERT—as a reranker over bi-encoder results or as the primary retriever—and notes that ColPali extends this approach to image-based document pages. A founder we work with had been stuck on the same problem for two months. Their RAG retrieval recall was sitting at 58%. They had tried OpenAI's embedding-3-small, then embedding-3-large, then BGE-M3, then Voyage. Each swap added a couple of points, then the curve flattened. The team was about to start fine-tuning their own embedding model. We told them to stop and add a reranker first. The number went from 58% to 81% in a single afternoon. The fine-tuning project was cancelled. This is the moment most teams discover that the bottleneck was never the embedding model. It was the architecture choice of using a single embedding per chunk to begin with. Late interaction is the family of techniques that fixes it, and it is the one most teams skip because the name sounds intimidating. A bi-encoder (which is what every standard embedding model is) takes a chunk of text, compresses it into a single fixed-length vector, and stores it. At query time, the user's question is also compressed into a single vector, and similarity is computed between the two. The compression is the problem. A 500-token chunk that mentions five different concepts gets averaged into one vector. The vector represents the chunk roughly, but it loses the distinction between "this chunk is mostly about X with a brief mention of Y" and "this chunk is mostly about Y with a brief mention of X." When the user query is about Y, both chunks look equally relevant by cosine distance, even though one is the right answer and the other is noise. This is why every benchmark of "best embedding model" shows diminishing returns past a certain point. The embedding model is doing the best it can with the information bottleneck of a single vector. The architecture is the limit. ColBERT (the original, 2020) keeps the per-token embeddings instead of pooling them into one vector. A 500-token chunk becomes 500 vectors. A 10-token query becomes 10 vectors. At scoring time, you compute the maximum similarity between each query token and any chunk token, then sum those max scores into the final relevance score. The math is the same dot products you would do for any vector search. The difference is that "how well does this query match this chunk" is now a sum of "for each query token, what is the best matching chunk token," which preserves the fine-grained signal that pooling threw away. In practice this looks like: This is what catches the recall ceiling. Sapota uses ColBERT in two patterns depending on the corpus size and latency budget. Pattern 1: ColBERT as a reranker over bi-encoder retrieval. The first stage is a standard bi-encoder vector search returning the top 50 candidates. The second stage is ColBERT reranking those 50 down to the top 5. This is the pattern we use for most production deployments. The first stage is fast (millisecond range, scales to billions of vectors). The second stage is slow but only runs on 50 candidates, not the full index. Pattern 2: ColBERT as the only retriever. For corpora under a few million chunks, ColBERT can be the primary retriever using PLAID or similar index structures that make late-interaction search tractable at scale. Latency is higher than a bi-encoder (10x to 50x depending on index size), but recall is the highest of any retrieval method we have benchmarked. We default to Pattern 1 unless the corpus is small enough that Pattern 2 is feasible and the recall lift justifies it. ColPali extends the late-interaction idea to entire document pages treated as images. Instead of token-level embeddings of text, it uses patch-level embeddings of an image of the page (each page split into a 32x32 grid of patches). Query tokens match against image patches using the same MaxSim mechanism. The implications: The cost is storage (1024 vectors per page vs 1 vector per chunk) and indexing speed (vision encoder inference is GPU-bound). Binary quantization brings the storage cost down by 32x and the latency down by an order of magnitude, which is what makes ColPali production-viable. For document-heavy corpora (research papers, financial filings, slide decks, regulatory submissions), ColPali outperforms both bi-encoder text RAG and CLIP-based multimodal RAG on published benchmarks. We use it when the corpus is genuinely visual and the budget supports the storage and GPU inference cost. Late interaction is not free. The honest trade-off: The number to weigh against this is the recall lift. In every audit Sapota has run where the team's recall plateaued in the 50% to 70% range, adding late-interaction reranking pushed it into the 80% to 90% range. That delta is the difference between "the AI is unreliable" and "the AI is the best search interface we have." A reranker is not always the answer. Skip it when: For most production RAG systems sitting at recall in the 60% to 75% range, late interaction is the next move. Cross-encoder rerankers are the lighter alternative if the team is not ready for the full ColBERT setup. The fix took half a day. We added a Jina-reranker stage between their existing Qdrant retrieval and the LLM call. Recall jumped from 58% to 81%. Faithfulness (because the LLM was now seeing better context) went from 0.79 to 0.93. The fine-tuning project was cancelled the same week. The next conversation is whether to upgrade the cross-encoder to a full ColBERT setup, which would push recall another 4 to 6 points based on what we have seen on similar corpora. For their current scale and budget, the cross-encoder is the right floor. Full ColBERT is the v2. If your team has been swapping embedding models and watching the recall curve flatten, the bottleneck is almost certainly the architecture, not the model. Sapota runs a one-week reranker integration engagement that adds the cross-encoder or ColBERT stage as a working PR plus a side-by-side eval against the current setup. Reach out via the AI engineering page with the recall numbers you are seeing and the embedding models you have already tried. The diagnosis is usually the same conversation. --- ## Mobile stack decision: FlutterFlow vs React Native vs Flutter > Published: 2026-05-24 02:51:51+00:00 > Source: https://dev.to/sapotacorp/mobile-stack-decision-flutterflow-vs-react-native-vs-flutter-18h8 > wpnews: https://wpnews.pro/news/mobile-stack-decision-flutterflow-vs-react-native-vs-flutter This article explains that there is no single "best" mobile framework; instead, the choice between FlutterFlow, React Native (with Expo), and Flutter depends on a project's specific constraints like timeline, team, and design needs. FlutterFlow is highlighted as the fastest path to an MVP for standard UI patterns, while React Native offers the largest ecosystem and OTA updates, and Flutter provides the most runtime control. The article warns that picking the wrong framework can cost 2 to 4 months of rework after eighteen months. A founder asked us last month which mobile framework was "the best." We get the question often enough that we have a rehearsed answer: none of them is best. Each fits a specific set of constraints, and picking the wrong one for your specific situation usually costs 2 to 4 months of rework eighteen months in. The framework matters less than the fit. The fit depends on your timeline, your team, your design fidelity needs, and whether you are optimizing for the next twelve weeks or the next five years. Here is the decision framework Sapota walks every founder through. The three options on the table For most B2C and B2B mobile products in 2026, the realistic shortlist is FlutterFlow, React Native (with Expo), or Flutter native (writing Dart directly). Native iOS / Android (Swift, Kotlin) is still the right call for some specific cases, but it is rarely the default anymore. We will cover when native does win at the end. The three frameworks differ on three dimensions that matter most: development speed, runtime control, and team future-proofing. FlutterFlow A visual development tool built on top of Flutter. You design screens by dragging components, configure data sources visually, and FlutterFlow generates Dart code under the hood. Custom logic drops into Dart custom actions and custom widgets when the visual editor cannot express what you need. Strengths: - Fastest path to a shippable MVP. 12-week marketplace MVPs are realistic for a 3-engineer team. - Pixel-perfect design implementation. Figma to FlutterFlow is closer to one-to-one than any other framework we have used. - Theming and white-label setup are first-class concepts. Multi-tenant apps with brand variables ship in days, not weeks. - The founder can open the editor and request changes that you implement in minutes. Tightest design-to-development feedback loop in the industry. Where it pushes back: - Anything custom-rendered (canvas drawing, complex animations, game-like UI) needs Dart custom widgets, which pulls you out of the visual flow. - State management at scale (3+ user roles, multi-tenant theming, real-time updates) outgrows app-state primitives. You end up moving state to the backend and treating the app as a thin client. - Performance profiling is shallow. No equivalent to React Native's Flipper or Flutter's DevTools. You debug performance through guesswork. - Vendor lock-in is real. Migrating off FlutterFlow means rebuilding in Flutter or another framework, not exporting and continuing. Pick FlutterFlow when: - MVP timeline is under 16 weeks - 80%+ of screens are standard mobile UI patterns (auth, lists, details, forms) - Backend is decoupled (Supabase, Firebase, custom API) - Your team accepts that custom Dart will be needed for the bespoke 20% - Visual fidelity matters and you want predictable results across iOS and Android Skip FlutterFlow when: - The product needs heavy real-time interactivity (multiplayer games, collaborative drawing, live markets) - Your engineering team will need to maintain the app for 5+ years and you want them comfortable with the underlying framework directly - You already have a strong React Native or Flutter team; the framework switch cost is higher than the visual development savings React Native (with Expo) Facebook's framework for building native mobile apps using JavaScript and React. With Expo's tooling (EAS Build, EAS Update, OTA patches), you get a managed workflow that handles a lot of native build complexity automatically. Strengths: - Largest ecosystem of any cross-platform framework. Almost any native API has a JavaScript wrapper. Stuck on something? There is a npm package or a community fix. - JavaScript / TypeScript familiarity. Your web team can ramp on mobile faster than learning Dart or Swift. - OTA updates via Expo. Push bug fixes without going through App Store review. For early-stage products iterating weekly, this is significant. - Mature debugging tools (Flipper, React DevTools, native debuggers). - Best long-term hire-ability. JavaScript engineers are everywhere. Where it pushes back: - Performance ceiling lower than Flutter or native for graphics-heavy or animation-heavy apps. The JavaScript bridge is faster than it used to be (with Hermes and the new architecture) but still not native. - Native module compatibility issues when you upgrade React Native. Major upgrades are rarely smooth. We budget 2-4 weeks for upgrades on production apps. - Visual fidelity work is more iterative than FlutterFlow. Designs render close but you spend more time on platform-specific edge cases (Android shadows, iOS safe areas, font rendering). - Easy to ship a slow app accidentally. The framework forgives sloppy patterns until production load reveals them. Pick React Native when: - Your team has strong JavaScript / TypeScript background - The product needs OTA update capability (frequent iteration without store review) - You want hire-ability and ecosystem maturity over raw performance - The app is content-heavy or transactional (most B2B SaaS, content apps, e-commerce) - You expect 3+ years of active development with team turnover Skip React Native when: - The app is graphics or animation-heavy - You need consistent 60+ fps under load - Your team has no JavaScript expertise and you would be teaching from scratch - The product is highly platform-specific (deep iOS-only or Android-only integrations) Flutter native Writing Dart directly against Flutter's framework, no visual builder. Same underlying technology as FlutterFlow but with full control over every line of code. Strengths: - Best performance of the three options. Compiles to native code, no JavaScript bridge, predictable 60+ fps even with complex UI. - Single codebase compiles to iOS, Android, web, desktop. The most truly cross-platform option of the three. - Beautiful animation framework. If your app's differentiator is motion design or visual polish, Flutter native gives you the most expressive primitives. - Strong typing with Dart catches more bugs at compile time than JavaScript. - DevTools profiler is excellent. Performance debugging is straightforward. Where it pushes back: - Slower to ship MVP than FlutterFlow. You write every screen by hand. For an MVP that FlutterFlow ships in 12 weeks, Flutter native usually takes 16-20. - Smaller ecosystem than React Native. Most native APIs have Flutter packages, but the long tail is smaller. You will write more native plugins yourself. - Hire-ability is improving but still behind JavaScript. Senior Flutter engineers in 2026 are easier to find than in 2022 but still command a premium. - Dart is a mid-popularity language. Comfortable for most engineers within a few weeks but not a transferable skill outside Flutter. Pick Flutter native when: - Performance requirements are strict (60+ fps under all load conditions) - The app's design includes complex animations or motion as a differentiator - You want one codebase across iOS, Android, web, and possibly desktop - The team is already Flutter-fluent or willing to invest in becoming so - Long-term ownership of the codebase matters more than fastest-possible MVP Skip Flutter native when: - Your timeline is under 16 weeks for v1 - You have no Flutter or Dart experience and the team's bandwidth to ramp up is limited - The product is mostly standard CRUD screens (FlutterFlow ships these faster) - You need OTA updates as a core capability (Flutter has this but ecosystem is less mature than Expo) When native (Swift, Kotlin) still wins We bring up native iOS / Android less often than we used to, but it has not disappeared. The cases where we still recommend native: - Heavy platform-specific integrations: Apple Pay deep integration, ARKit / RealityKit, Watch app, CarPlay, App Clips, Live Activities. Same on Android: deep Auto, Wear OS, advanced camera features. Cross-platform frameworks reach these eventually but always with delay. - Performance-critical apps with platform-specific optimization: heavy image processing, on-device ML, AR / VR. Native gives you direct access to Metal, Core ML, ARKit without bridge overhead. - Apps where the team is already native and the cross-platform switch costs more than maintaining two codebases: rare but real. A team that has shipped 5 years of Swift will lose more by switching than by writing two apps. - Projects where the App Store review process is hostile to cross-platform (some categories of apps face stricter review when they look or behave non-native). For most B2C and B2B SaaS products in 2026, native is overkill. The cross-platform frameworks have closed the gap on 95% of use cases. The decision matrix Eight criteria, four options each. MVP speed (how fast you can ship v1): - FlutterFlow: Fastest - React Native: Fast - Flutter native: Medium - Native (Swift/Kotlin): Slowest Performance ceiling (frame rate under load): - FlutterFlow: Medium - React Native: Medium - Flutter native: High - Native: Highest Hire-ability in 2026 (how easy to find engineers): - FlutterFlow: Niche - React Native: High - Flutter native: Medium - Native: High per platform (Swift or Kotlin separately) OTA updates (ship fixes without store review): - FlutterFlow: Yes via FlutterFlow Cloud - React Native: Yes via Expo - Flutter native: Limited - Native: Not supported Long-term codebase health (5+ year ownership): - FlutterFlow: Risky, vendor lock-in - React Native: Stable - Flutter native: Stable - Native: Stable White-label / multi-tenant theming: - FlutterFlow: Native first-class concept - React Native: Doable with effort - Flutter native: Doable with effort - Native: Doable with effort Custom animations (motion-heavy products): - FlutterFlow: Limited - React Native: Medium - Flutter native: Strongest - Native: Strongest per platform Visual fidelity to Figma: - FlutterFlow: Highest - React Native: Medium-High - Flutter native: High - Native: Highest per platform How Sapota approaches the choice The mistake we see most often is teams picking a framework based on what their current developers happen to know, then spending the next two years working around its limitations. The framework should fit the product, not the team's existing comfort zone. Our mobile engineers are trained across all four stacks (FlutterFlow, React Native, Flutter native, and the native platforms). When a new project lands, we run a fit assessment that scores the project against each framework on the criteria above. The recommendation comes from the assessment, not from "what we happen to specialize in." This sometimes means we recommend FlutterFlow when the founder expected React Native, or React Native when they expected Flutter. The conversation is occasionally awkward (founders have read articles, formed preferences) but it saves the months of rework that come from picking the wrong framework. We have done that rework on inherited projects often enough to know what it costs. The cross-training is deliberate. A vendor who only knows FlutterFlow will recommend FlutterFlow. A vendor who only knows React Native will recommend React Native. The unbiased recommendation is the differentiator, and the only way to give it honestly is to be fluent across the options. A simple decision tree If you do not want to walk through the full matrix, the rough heuristic: - MVP in under 16 weeks, standard CRUD screens, single brand or simple white-label → FlutterFlow - 3+ year codebase, JavaScript team, frequent iteration with OTA → React Native - Performance-critical, animation-heavy, or codebase needs to span iOS / Android / web → Flutter native - Heavy platform-specific integration or your team is already native and shipping → Native When in doubt, FlutterFlow for MVP, React Native for the production rebuild if you outgrow FlutterFlow's limits. If you are picking a stack right now If your team is debating mobile frameworks and the conversation is not converging, the issue is usually that nobody has put the project's specific constraints on the table next to eac --- ## Plugin + Azure Function + Service Bus: async integration at scale > Published: 2026-05-24 02:51:45+00:00 > Source: https://dev.to/sapotacorp/plugin-azure-function-service-bus-async-integration-at-scale-4o2i > wpnews: https://wpnews.pro/news/plugin-azure-function-service-bus-async-integration-at-scale This article describes an enterprise integration pattern where a Dataverse plugin publishes a small metadata message to an Azure Service Bus Topic, rather than directly calling multiple downstream systems. Five independent Azure Function consumers then subscribe to the topic, each handling its own destination (ERP, search, Power BI, notifications, data lake) with independent retry, dead-lettering, and idempotency logic. This architecture ensures that a failure in one downstream system does not affect the others, improving reliability at scale. A Dataverse row changes. Five downstream systems need to know: an ERP that tracks financials, a search service that indexes the record, a Power BI dataset that feeds executive dashboards, a notification queue that messages field reps on mobile, and a data lake for analytics retention. The junior version of this is a single async plugin that calls all five from the same post-operation step. It works in development. In production, it fails the first time any one of the five has a bad afternoon - the plugin step errors, retries ten times, fills the System Jobs queue, and operators get paged. The pattern we ship at enterprise scale is different: the plugin's only job is to publish a message to Azure Service Bus. Five independent consumers pull from that message topic and handle their respective destinations. Each consumer retries, dead-letters, and monitors independently. The plugin never calls out to anything but the queue. Here is the architecture, the code, the failure semantics, and the six months of real-production experience that shaped it. The architecture A Topic (not a Queue) because the same event feeds multiple subscribers. Subscriptions filter so each consumer only sees events it cares about. Dead-letter per subscription, not global - the ERP and search services can fail independently without cross-contaminating. Stage 1: the plugin The plugin is small on purpose. Every line is a potential failure point; the less it does, the more reliable it is. Three key decisions: - Payload is metadata, not the full row. The message includes the entity name, ID, and which attributes changed. Consumers fetch the full row if they need it. Messages stay small (sub-1KB), which Service Bus charges less for and which avoids the edge case of payloads exceeding message size limits. - CorrelationId from the plugin context. Every log entry and every downstream message carries the same correlation ID, making cross-system tracing possible with one query. - Subject field for filtering. Subscribers filter on Subject LIKE 'account.%' or Subject = 'order.Update'. Subject-based filtering is cheap server-side; body-based filtering is more expensive. Stage 2: Service Bus Topic configuration Topic-level settings: - Max message size: 1MB (default). Our payloads are ~500 bytes, nowhere near the limit. - Message time-to-live: 7 days. Long enough to survive a weekend outage, short enough that stale messages don't haunt the system. - Duplicate detection: enabled with 10-minute window. If the same MessageId arrives twice within 10 minutes, the second is dropped. This guards against plugin retries causing duplicate downstream processing. Subscription-level settings per subscriber: - Filter rule: SQL-like expression on message properties (Subject, custom headers). - Max delivery count: 5 (same reasoning as in the simpler Service Bus pattern). - Lock duration: tuned to each consumer's processing time. The ERP consumer, which makes a remote call taking up to 30 seconds, has a 60-second lock. The search consumer, which is purely in-Azure and takes 1-2 seconds, has a 30-second lock. Stage 3: the consumers Each subscriber is an Azure Function with a Service Bus Topic subscription trigger. They share a common frame but implement different downstream logic. Common frame: The idempotency store is either Cosmos DB with TTL or Redis. Every successfully processed MessageId is recorded. The TTL matches the message time-to-live on the Topic plus a safety margin. Core logic per consumer is where the differences live: - ERP consumer: fetches the full Dataverse row via Web API (using a managed identity), maps to the ERP's schema, calls the ERP API with an idempotency key derived from MessageId. - Search consumer: fetches the row, calls the search service's indexing API. - Power BI consumer: triggers a dataset partition refresh; uses the correlation ID to tag the refresh operation. - Notification consumer: looks up which users to notify based on the row's owner and policy, sends via the notification service. - Data lake consumer: appends a compressed JSON record to partitioned ADLS Gen2 path by date. Observability The chain is not useful in production without observability. Our setup: - Application Insights per Function App, with shared workspace so queries span functions. - Every log entry includes CorrelationId and MessageId via the BeginScope pattern above. - Custom metrics: ProcessedMessages, FailedMessages, DeadLetteredMessages, ProcessingDuration. - Dashboards (Azure Monitor workbooks):End-to-end latency per event type (from Dataverse change timestamp to final destination write).Dead-letter queue depth per consumer.Error rate per consumer, per hour. - Alerts: DLQ depth > 10 for any consumer, processing duration p95 > SLA for any consumer. The end-to-end trace for a single event: a KQL query across Application Insights joining by CorrelationId. One row change in Dataverse, traced through plugin → Service Bus publish → each consumer → each downstream call. When something fails, we know exactly where in the chain. Six months in production: the numbers A client with: - 50,000 Dataverse events per day - 5 consumers averaging 3 seconds processing each - Bursts to 500 events/minute during peak hours Current state: - P50 end-to-end latency (event → all consumers complete): 4.2 seconds - P95 end-to-end latency: 11 seconds - Dead-letter rate: 0.003% (one in 33,000 messages) - Consumer error rate: 0.1-0.2% (mostly transient, auto-retried) - Monthly Azure cost (Service Bus + Function Apps + Application Insights): ~$320 What we tuned after launch Ratio of Function App instances to queue depth. Consumption plan auto-scales; the defaults were conservative. We adjusted maxConcurrentCalls per function to keep consumer processing near its per-instance capacity before spinning up more instances. Filter rules on subscriptions. Initially each consumer received every event and filtered in code. Moving the filter to the subscription level (server-side) cut consumer costs by ~60% because consumers no longer woke up for irrelevant events. Deduplication window. Initial 1-minute window was too short; plugin retries occasionally pushed duplicates more than a minute apart. Extended to 10 minutes after measuring actual retry intervals. When not to ship this This pattern is overkill for: - Projects with one or two downstream consumers - direct Power Automate flow is simpler. - Low-volume scenarios (< 1000 events/day) - the operational complexity outweighs the throughput benefit. - Teams without Azure experience - maintaining Service Bus, Function Apps, and Application Insights is real ops burden. Pick a simpler pattern until the operational muscle exists. For the projects where it fits (enterprise-scale, multi-consumer, event-critical), this is the architecture we reach for first. It survives load, it surfaces failures cleanly, and when something goes wrong, the fix is almost always in a known location with clear visibility. --- ## SFMC Data Model and Cardinality: Wire DEs Together Without Regret > Published: 2026-05-24 02:51:40+00:00 > Source: https://dev.to/sapotacorp/sfmc-data-model-and-cardinality-wire-des-together-without-regret-21l > wpnews: https://wpnews.pro/news/sfmc-data-model-and-cardinality-wire-des-together-without-regret The article explains that a common mistake in Salesforce Marketing Cloud (SFMC) is creating Data Extensions (DEs) reactively, leading to an unjoinable data sprawl. It recommends a proactive approach: first define a Database of Record (DBOR) and a stable Subscriber Key, then structure DEs using a Master/Spoke model with correct cardinality (1:1, 1:Many, Many:Many) to enable effective cross-data segmentation. Proper data modeling, documented and signed off before building, is presented as the most critical step to avoid costly remediation later. Teams new to SFMC create Data Extensions as requirements arrive. Today's send needs a list, tomorrow's loyalty feature needs a separate DE, next week's CRM sync adds three more. Three months in: 20 DEs, nothing can be joined, no cross-data segmentation works, no audit trail. The fix is 30 minutes on a whiteboard before the first DE exists. Two concepts carry it: Database of Record and Cardinality. The DBOR is the single source of truth for subscriber identity. Every other data source points at it. Discovery question for the client: One answer. If the client says "all of them," help them decide - usually by picking the system that currently drives business operations (order fulfillment, customer service queries). The DBOR defines the Subscriber Key. All SFMC DEs that hold subscriber data use an ID that maps back to the DBOR. Once DBOR is decided, the Subscriber Key follows: The Subscriber Key must be stable - never changes over a customer's lifetime. Email addresses change; Shopify IDs can reset on a store migration; a purpose-built CustomerID is safest. Document the Subscriber Key rule in the data model doc. When new data sources arrive later, they get plumbed through the same Subscriber Key. Rather than one giant DE with every column, split by function: Master holds the subscriber-facing attributes. Spokes hold the detail. Joins happen via AMPscript Lookup or Automation Studio SQL, not by duplicating columns. When you link DEs in Contact Builder for cross-DE segmentation, SFMC asks about cardinality - the relationship between two DEs: CardinalityMeaningExample1:1One row in A relates to one row in BCustomer -> primary Address (each customer has one primary)1:ManyOne row in A relates to many rows in BCustomer -> Orders (one customer, many orders)Many:ManyMany rows in A relate to many in BCustomer -> Product (via Order_Items - each customer can buy many products, each product bought by many) Getting cardinality wrong breaks segmentation: Before touching SFMC for a new engagement, we write a one-page data model: Review with the client. Once signed off, building in SFMC follows the doc rather than the other way around. When picking up a poorly-modeled SFMC account, the symptoms are predictable: The remediation is the same whether you're starting fresh or remodeling: define DBOR, fix Subscriber Key, introduce a Master DE, migrate downstream. Data modeling doesn't feel productive because you're not building anything yet. On SFMC engagements it's the most leveraged hour of the whole project. Write the data model doc, get client sign-off, then build. The alternative is the 20-DE sprawl that eats your Q2. Modeling an SFMC data architecture? Our Salesforce team designs data models, Subscriber Key strategies, and Contact Builder relationships on production engagements. Get in touch -> See our full platform services for the stack we cover. --- ## Custom connector with OAuth2: three auth pitfalls we debugged > Published: 2026-05-24 02:51:34+00:00 > Source: https://dev.to/sapotacorp/custom-connector-with-oauth2-three-auth-pitfalls-we-debugged-4758 > wpnews: https://wpnews.pro/news/custom-connector-with-oauth2-three-auth-pitfalls-we-debugged Here is a factual summary of the article: The article describes three common pitfalls encountered when building a custom Power Automate connector using OAuth2 for a third-party API. The issues included a redirect URI mismatch between Power Platform environments, a failure to refresh tokens because the `refreshUrl` was not explicitly configured in the connector's OpenAPI schema, and the inability to send non-standard parameters (like a tenant ID) during the token exchange. The authors provide specific fixes, such as registering multiple redirect URLs and explicitly setting the refresh URL, while noting that some provider-specific behaviors require workarounds like using an Azure Function. A client uses a third-party logistics API that is not in Power Automate's built-in connector catalog. The API speaks OAuth2 authorization code flow. The platform has a "Create a custom connector" flow that claims to handle OAuth2 in a couple of clicks. The first two connectors we built this way worked. The third hit three separate issues that took a combined week to diagnose. Here is what those three were, and the patterns we now check up-front on every OAuth2 custom connector. You fill in a form with: The platform handles the rest: redirect the user through consent, capture the authorization code, exchange it for an access token, refresh when expired. When a flow uses the connector, the current access token is injected into the Authorization header automatically. This works when the identity provider follows the OAuth2 spec faithfully. It breaks in ways the platform does not surface clearly when the provider takes any of the common non-spec shortcuts. You configured the logistics API's OAuth app with a redirect URL copied from your Dev environment. The Dev custom connector works. You export the solution to UAT, import it, and the first OAuth consent in UAT fails with "redirect_uri_mismatch." Root cause: Power Platform generates a redirect URL that includes the environment-specific tenant subdomain. The URL from Dev is not the URL from UAT. Fix: register multiple redirect URLs in the identity provider, one per Power Platform environment. The OAuth app on the IdP side needs an entry for every https://global.consent.azure-apim.net/redirect/* URL that corresponds to your environments. Complication: some identity providers allow wildcards in redirect URL registration (https://global.consent.azure-apim.net/redirect/*), others do not. For the strict ones, you maintain a list and add/remove entries when environments come and go. The API you are connecting to issues access tokens valid for 1 hour and refresh tokens valid for 30 days. Power Platform should refresh the access token automatically when it expires; you should not need to re-authorize for 30 days. What happened: every 2 hours, the flow started failing with 401 Unauthorized. Manual reauthorization of the connection fixed it; 2 hours later, same failure. Diagnosis took a while. The flow's run history showed the token being used, the API rejecting it, but no refresh attempt. We eventually traced it to how the connector was declaring its refresh behavior in the OpenAPI schema: the connector had no refreshUrl configured, so the platform treated every token as final and never attempted a refresh. Fix: set the refreshUrl explicitly in the connector's security section, even if it is the same as the token URL. Without it, the platform assumes no refresh is supported. A secondary issue we found: some APIs rotate the refresh token on every refresh (return a new refresh token alongside the new access token). Power Platform handles this correctly if the response includes refresh_token in the JSON. APIs that only include refresh_token on the initial grant and not on refresh will eventually expire the stored refresh token, and re-authorization becomes necessary. This is a provider behavior you cannot fix in the connector - you can only schedule manual re-auth before the refresh token's lifetime runs out. Standard OAuth2 token exchange sends grant_type=authorization_code, code=, redirect_uri=, etc. in the form body. The API we were connecting to wanted an additional tenant_id parameter on every token exchange. It is not part of the spec; the provider added it for their multi-tenant SaaS model. Power Platform's custom connector OAuth2 configuration does not have a field for "extra parameters to send on token exchange." Default behavior sends only the spec-defined fields. The fix we used was hacky: move the OAuth flow behind an Azure Function. The flow calls the function's HTTPS endpoint, the function does the token exchange with the full set of parameters and returns the access token, the flow uses the access token via a separate connector that expects Bearer auth. This doubled the integration complexity (an extra hop, an extra resource to monitor) but was the only working path. We later migrated to direct connector when the API provider added spec-compliant OAuth as an option. The broader lesson: before building a custom connector with OAuth2, confirm the target API follows OAuth2 strictly enough to work in the platform's constrained configuration. Providers that require custom token exchange parameters, non-standard response fields, or DPoP/mTLS cannot use the built-in OAuth2 flow - and the connector wizard does not warn you. ## The pre-check we run before building an OAuth2 connector Ten minutes of reading provider docs before clicking "New custom connector" saves hours later. Our checklist: 1. Does the provider document the authorize URL, token URL, and refresh URL? (All three needed; "refresh works same as token" is the common case but confirm.) 2. Does the provider accept wildcard or multiple redirect URLs, or only one? (If only one, you need an extra OAuth app per environment.) 3. Does the provider rotate refresh tokens on refresh, and what are the lifetimes? (Shorter refresh lifetime means more re-auth pain.) 4. Does the token exchange require any parameters beyond the OAuth2 standard set? (If yes, you likely need an Azure Function proxy.) 5. Does the API require PKCE? (Power Platform supports it for some flows; confirm.) Any "no, not sure" on these is a reason to de-risk before committing the full integration. ## The connection reference hygiene A custom connector deployed to managed solution uses connection references for per-environment auth. One connector, one connection reference, N connections (one per environment, each bound to its own OAuth authorization). For the auth to actually carry across environments: - Create a long-lived connection per env at initial setup (authorize once, test works) - Ship the connection ID in the deployment-settings.json for each env - Rotate/reauthorize only when the refresh token lifetime runs out A connection reference that is re-bound mid-release will break every running flow. We now treat OAuth-backed connection references as nearly immutable - rebinding is an ops event, planned, communicated. ## The fourth pitfall we almost had On a subsequent project, we almost repeated a mistake: committing an OAuth client secret into the deployment-settings file. The file is in git. The secret would have been in git history forever. Pattern we now enforce: OAuth client secrets live in Azure Key Vault. A secret-type environment variable references the Key Vault secret URI. The deployment-settings file references only the env variable schema name, not the secret value. Git gets the schema name; Key Vault gets the secret; nothing sensitive lives in both. Four pitfalls, one prevention pattern each. Built into the project template, the custom-connector work that used to eat weeks now takes days. --- ## Four forensics when a production AI agent fails > Published: 2026-05-24 02:51:28+00:00 > Source: https://dev.to/sapotacorp/four-forensics-when-a-production-ai-agent-fails-4in2 > wpnews: https://wpnews.pro/news/four-forensics-when-a-production-ai-agent-fails The article describes a common failure pattern in production AI agents, where multiple distinct issues—such as degraded external dependencies, faulty validation gates, and cost spikes from specific user queries—compound to appear as a single "broken agent" problem. It outlines a forensic approach using traces to diagnose these failures, citing a real case where an LLM provider's quiet model update increased agent iterations and latency, while permissive validation thresholds and a few high-cost users further degraded performance. The recommended fixes include tightening prompts, adjusting validation thresholds, and implementing per-user cost caps. A founder messaged us at 11pm on a Friday: "Our agent is broken. Customers are complaining. My on-call engineer has no idea where to start. Can you help?" The agent was a customer support tool that had launched the previous Monday. By Friday evening, the company's support inbox had filled with users reporting that the AI was giving wrong answers, taking forever to respond, or just timing out. The engineering team was treating it as one big problem. It was actually four problems stacked on top of each other. This is the failure pattern most production agent teams hit at some point. The symptoms compound, the team panics, and they start trying random fixes. Here is the forensics order Sapota walks through, and the four most common failure modes that account for the majority of post-launch incidents. Before debugging anything else, look at the traces. If your agent is in production without traces, that is the first problem to solve, even mid-incident. Pull a request that is failing, look at the trace, and see where the time is being spent and what is failing. The pattern we look for in the trace: In the founder's case, the traces showed three different failure patterns appearing in the same week. The team had been treating them as one problem because the customer-facing symptom was the same: "the AI is broken." The most common production agent failure is an external dependency getting slower or less reliable. The agent itself is fine; the world around it changed. Common culprits: The diagnostic: check your tool latency and error metrics for the past week. If any tool's p95 latency is 2x what it was at launch, or its error rate is up more than 1%, that is the candidate. The fix depends on the specific dependency. Rate limits: upgrade your tier or implement exponential backoff. Slow retrieval: tune the index or scale the database. API drift: update the integration. KB growth: re-tune chunking and retrieval parameters. In the founder's case, the LLM provider had pushed a quiet model update on Wednesday. The new model interpreted the routing prompt slightly differently, causing the agent to loop more often before settling on an answer. Average iterations went from 2.3 to 4.1. Cost and latency both jumped. The fix was a tighter routing prompt with three more few-shot examples. The opposite failure: a validation gate is supposed to be catching bad outputs, but it is not firing because the gate logic has a bug or the threshold is wrong. Common patterns: The diagnostic: look at a sample of bad responses customers reported. Trace what should have caught them. If a validation gate exists for that failure mode, check whether it actually fired. In the founder's system, the faithfulness threshold was set at 0.7, which was permissive. We tightened it to 0.85, the rejection rate went from 2% to 9%, and the customer complaints about wrong answers dropped immediately. The "rejected" responses were replaced with honest "I cannot find that in our knowledge base" messages, which users preferred to wrong answers. Production query distribution is different from test distribution. Specific query patterns can be much more expensive than the average, and a few of those can dominate the bill. The pattern: a small fraction of users (often 1-5%) generate a large fraction of cost (often 30-60%). Either through legitimate complex queries, abuse, or because their input triggers a degenerate code path in the agent. The diagnostic: pull cost-per-user statistics for the last week. Sort descending. Look at the top 10 users. Are they sending normal queries? Or is one user looping their integration with bad inputs? Or is a specific query class (long documents, malformed input, multi-turn deep into rare topics) eating budget? The fixes vary: In the founder's system, two users were sending repeated multi-paragraph product comparison requests, generating about 40% of the daily cost between them. We added a per-user daily cost cap and a length limit on inputs. Cost dropped 35% within 48 hours. Neither user complained because both were testing internal features and the cap was generous enough for normal use. The hardest failure to detect: nothing is broken, no errors, latency is fine, cost is normal. But the responses are getting worse. Customers complain, the team cannot reproduce, and the dashboards all look green. Causes: The diagnostic: run your eval pipeline against the current production agent. Compare against the score from launch. If the score has dropped, you have quality drift. If the score is the same but customers are complaining, your eval set has gone stale. The fix: refresh the eval set. Sample 50-100 actual production queries, write expected answers for each, run the eval, and tune from there. Most teams refresh eval sets quarterly. Teams in fast-moving domains do it monthly. The four-hour Friday-night triage: Customer complaints stopped within 72 hours. The team's mood went from "we built a broken thing" to "we built a thing that needs operational rigor we did not anticipate." That second framing is the one that produces a better product. The founder's team had no playbook for "the agent is broken in production." They were debugging in panic mode, which slowed every step. After the incident, we wrote a one-page runbook with the four failure modes, the diagnostic for each, and the most common fixes. Six weeks later, when a similar issue happened (a tool API outage), the on-call engineer worked through the runbook, identified the cause in 20 minutes, applied the documented fix, and was done in an hour. No panic, no escalation, no Friday-night call to a consultant. This is what production agent operations looks like at maturity. Not "nothing ever goes wrong" but "when things go wrong, the team has a known process to find the cause." If your team launched an AI agent and the first few weeks have been more painful than expected, the right intervention is usually a forensic audit, not more development. Most launch issues are not new bugs in the agent code. They are operational gaps that surface only at production scale. Sapota offers a one-week post-launch audit that walks through traces, validation, dependencies, and quality drift, identifies which of the four failure modes is responsible for which symptoms, and ships fixes plus a runbook for future incidents. We have done this for half a dozen B2B SaaS clients in the first three months after their AI launches. Reach out via the AI engineering page with a description of what your agent does and what kind of failures you are seeing. The first conversation is usually the diagnostic.