标签：#ring

How migrating Copilot code review to shared Unix-style code exploration tools reduced review cost by reshaping agent workflows around pull request evidence. The post Better tools made Copilot code review worse. Here’s how we actually improved it. appeared first on The GitHub Blog .

Agentic testing is an AI-driven approach to end-to-end test automation introduced by Slack engineering. It uses AI agents that execute workflows based on intent rather than fixed scripts, adapting to UI and system changes at runtime. The approach aims to reduce brittle tests in distributed systems while complementing deterministic unit, integration, and E2E testing strategies. By Leela Kumili

Bryan Oliver discusses the frontier of AI infrastructure: chaos engineering for large-scale GPU clusters. He shares how engineering leaders can handle complex topologies, network protocols like RDMA, and NUMA misalignments. Discover seven practical fault-injection strategies to maximize multi-million dollar hardware efficiency and build robust observability loops. By Bryan Oliver

Understanding Observability with the LGTM Stack From "what happened last night?" to "here's exactly what happened and why" — in under 5 minutes Table of Contents Introduction What Is Observability? The Three Pillars of Observability Metrics Logs Traces Why You Need All Three Together The LGTM Stack Architecture: How It All Fits Together OpenTelemetry: The Instrumentation Standard The OTel Collector: The Brain of the Pipeline Loki: Log Aggregation Tempo: Distributed Tracing Mimir: Metrics at Scale Grafana: Connecting the Dots Conclusion Introduction Let me tell you a story that probably sounds familiar. It's 2 AM on a Sunday. Your API is slow. Users are complaining. But you're not at your desk — you're in a Sleeping, or just living your life. You have no idea it's even happening. The next morning you walk into the office and your boss meets you at the door. "Hey, the API was really slow yesterday around 2 AM. What happened?" And you're stuck. Completely stuck. You pull up the server logs — it's a wall of unformatted text. Maybe the issue already fixed itself. Maybe the container restarted overnight and the logs are gone. You weren't there, and your system left no trail. So you say the thing every developer dreads saying: "I don't know. I'll look into it." Now imagine the exact same situation — but this time you have observability set up. You open your dashboard, set the time range to yesterday 2 AM, and within two minutes you can see everything. Response times spiked to 4 seconds. The database connection pool got exhausted. And it started the exact moment a scheduled batch job kicked off and hammered the DB with hundreds of queries at once. You have a graph. You have traces. You have the exact log line that caused it. You walk back to your boss with your laptop: "Here's what happened and here's the fix." That's observability. Your system tells its own story — even when you're not watching. That's what this blog is about. I'll walk you through what observability actua

GitHub has made the redesigned GitHub Copilot CLI terminal interface generally available. It adds a tabbed layout for sessions, gists, issues, and pull requests; an in-session, form-driven setup for MCP servers, skills, and plugins that avoids hand-editing config files; and a cleaner, theme-aware, more accessible UI with screen reader support. By Mark Silvester

In this podcast Shane Hastie, Lead Editor for Culture & Methods spoke to Gabriela Moreira about making formal methods accessible through the Quint specification language, how AI is dramatically lowering the barrier to entry for formal specification and model-based testing, and why defining correct system behaviour remains essential human work in an AI-driven world. By Gabriela Moreira

In a recent article, Datadog engineer Arnold Wakim shared what worked, what didn't, and the lessons they learned while evolving a critical production system using AI to overcome hard limits in its storage backend and significantly improve performance. By Sergio De Simone

Original Japanese article : Iceberg REST Catalogを直接叩いて、Glue Data CatalogとS3 Tablesの違いを理解する Introduction I'm Aki, an AWS Community Builder ( @jitepengin ). Most of the time, when working with Iceberg tables, we reach for PyIceberg or Spark. I'm no exception, and honestly there were parts of the PyIceberg configuration — rest.sigv4-enabled , rest.signing-name , warehouse — that I understood only vaguely. Iceberg defines a standard called the Iceberg REST Catalog Open API specification , and AWS implements it through two separate endpoints: The AWS Glue Iceberg REST endpoint ( https://glue.<region>.amazonaws.com/iceberg ) The Amazon S3 Tables Iceberg REST endpoint ( https://s3tables.<region>.amazonaws.com/iceberg ) If two implementations follow the same spec, sending the same requests to both and comparing the results should reveal what's actually different between them. In this article, I'll bypass clients like PyIceberg entirely and hit the REST API directly to explore the differences between the two endpoints. To state the conclusion up front: Even though both implement the same Iceberg REST Catalog specification, Glue is designed as an "entry point to multiple catalogs," while S3 Tables is designed as an "entry point to a single table bucket." That difference is visible just by looking at the URL paths. I previously wrote about the relationship between S3 Tables and Glue Data Catalog in another article — worth a read alongside this one: Does Amazon S3 Tables Replace AWS Glue Data Catalog? Understanding Their Relationship What Is the Iceberg REST Catalog? The Iceberg REST Catalog is a specification that standardizes Iceberg catalog operations as an HTTP API. It's published as an OpenAPI definition (YAML), and any catalog that conforms to it can be accessed the same way from clients such as PyIceberg, Spark, and Trino. The key points of the spec are: URL paths follow a pattern like GET /v1/{prefix}/namespaces , where {prefix} is a free-form segment Clients first call

Ingeniería de Datos aplicada a la Biodescodificación: Presentando Bio-Mapping Engine 🧬 ¿Es posible aplicar ingeniería de datos de alta fidelidad a campos de conocimiento no estructurados? La respuesta es un rotundo sí. Hoy quiero presentarles Bio-Mapping Engine , un framework diseñado para resolver un problema clásico de la extracción de información: convertir literatura densa y desorganizada en una base de conocimientos semántica, estructurada y totalmente navegable. El Problema: El caos de la información no estructurada En campos como la Biodescodificación , la información suele residir en libros o archivos PDF donde los conceptos (síntomas, emociones, zonas anatómicas) están entrelazados de forma narrativa. Para un investigador o un desarrollador de herramientas de salud alternativa, extraer relaciones precisas entre un síntoma físico y su conflicto emocional mediante métodos tradicionales es una tarea manual, lenta y extremadamente propensa a errores. La Solución: Bio-Mapping Engine Bio-Mapping Engine no es un simple scraper . Es un motor de segmentación semántica y mapeo topológico. Su propósito es transformar un PDF bruto en un grafo de conocimiento estructurado en formato JSON, permitiendo realizar consultas multidimensionales con precisión quirúrgica. 🚀 Características Principales Segmentación Semántica Avanzada: Implementa un parsing topológico que distingue inteligentemente entre encabezados de síntomas, contenido emocional y el "ruido" estructural (como índices o números de página). Mapeo Relacional Multidimensional: Realiza una extracción de alta fidelidad a través de tres vectores fundamentales: Síntomas Canónicos: Estandarización de la nomenclatura de síntomas y condiciones. Jerarquía Anatómica: Mapeo inteligente que escala desde Sistemas $\rightarrow$ Regiones $\rightarrow$ Órganos. Arquetipos Emocionales: Extracción estructurada de modelos mentales y conflictos (ej. "Causa probable" , "Bloqueo emocional" ). Consultas Multi-Eje (CLI): Una potente inte

News publishers say OpenAI hid tools and datasets that could identify copyrighted journalism in ChatGPT outputs, escalating their lawsuit with a new motion for sanctions.

Here's the problem nobody talks about: the reason most AI outputs are mediocre isn't the model — it's that you asked for a final answer and got one. A model with no friction produces the path of least resistance. It pattern-matches to "good-enough" and stops. It doesn't know what your bar for quality is. It doesn't know what logic you'd push back on, what tone would make your audience tune out, or what structural flaw a sharp reader would catch in the first 30 seconds. It just fills the token space with the most statistically probable response and calls it a day. So the output hits your clipboard. You read it. You sigh. Then you spend 40 minutes editing something that should have come out right the first time. There's a better way — and it exploits the fact that AI critique is significantly sharper than AI generation. The Core Insight: Models Are Better Critics Than They Are Authors This sounds counterintuitive, so stay with me. When you ask an LLM to generate something from scratch, it operates in "produce plausible content" mode. The pressure is to fill the blank. But when you ask a model to critique an existing piece — especially if you hand it a specific evaluative persona — it switches into "find the gap between what is and what should be" mode. That's a fundamentally different cognitive task, and it's one where models consistently perform better. Research on iterative self-refinement in LLMs (Madaan et al., 2023) shows that when models are given their own output and asked to improve it with explicit feedback criteria, quality scores improve substantially across writing, code, and reasoning tasks. The key variable wasn't model size or prompt verbosity — it was the presence of a structured feedback loop. The mechanism is simple: the critique generates tokens that constrain and guide the rewrite. Those critique tokens become working context. The model rewrites against them. The output is necessarily better-fitted to the evaluation criteria than anything a single-

RQ (Redis Queue) is a delightfully simple way to run background jobs in Python. That simplicity is also why teams under-monitor it: it just works, until a downstream API gets slow or a bad deploy ships, and jobs start failing in bulk — quietly. Here's what to watch and how to get alerted before a customer tells you. RQ failures don't announce themselves When a job raises, RQ moves it to the FailedJobRegistry and moves on. The worker keeps running; nothing crashes. If you're not looking at that registry, the failure is invisible — the same trap BullMQ, Celery, and every robust queue share. So the job is to reach into the queue's state and turn it into a signal. The four signals that matter for RQ Failure count / rate — jobs landing in the FailedJobRegistry over a window. Backlog — how many jobs are queued vs. being worked; is the worker keeping up? Latency — how long jobs take, and how long they wait before a worker picks them up. Worker liveness — are your workers actually alive and heartbeating? Where to read them RQ exposes queue and registry state directly: from redis import Redis from rq import Queue from rq.registry import FailedJobRegistry , StartedJobRegistry redis = Redis () q = Queue ( " default " , connection = redis ) queued = len ( q ) # backlog failed = FailedJobRegistry ( queue = q ) # failures started = StartedJobRegistry ( queue = q ) # in-flight print ( " queued: " , queued ) print ( " failed: " , len ( failed )) print ( " started: " , len ( started )) Poll this on an interval and store the series — a single snapshot hides the trend , which is the part that matters. For failures specifically, walk the registry to get the actual exceptions: for job_id in failed . get_job_ids (): job = q . fetch_job ( job_id ) print ( job . id , job . exc_info . splitlines ()[ - 1 ] if job . exc_info else "" ) Two gotchas: Group by exception, not by job. A thousand jobs failing with the same traceback is one incident. Normalize the message (strip IDs, timestamps, host

PR volume went up, ticket quality didn't, and the gap got filled with LLMs on both sides of the review: bots reviewing, bots replying, bots occasionally arguing with bots about priorities that only existed in a teammate's head. Our CEO named the actual problem, and it's bigger than code review.

OpenAI found two unrelated bugs masquerading as one in ChatGPT's data infrastructure. Silent hardware corruption on one Azure host and an 18-year-old race condition in GNU libunwind's setcontext function with a one-instruction vulnerability window. The breakthrough came from switching to population-level crash analysis rather than examining individual core dumps. By Steef-Jan Wiggers

AWS has outlined how ProGlove, an industrial-wearables manufacturer, was able to scale its SaaS platform to run more than one million AWS Lambda functions spread across thousands of dedicated customer accounts. By Matt Foster

From answering questions to solving problems — Phase 6 of the Jarvis AI Platform After Phase 5, Jarvis could hear, speak, remember conversations, retrieve documents, and use tools. But every interaction was still limited to a single request and a single response. You: "What's the weather in Kathmandu?" Whisper ↓ AiOrchestrator ↓ WeatherTool ↓ Text-to-Speech Jarvis: "It is 22°C and clear." That works well for simple questions. It completely breaks down when a task requires multiple decisions. The Limitation of Single-Turn AI Imagine asking: Research the top 3 Java AI frameworks, compare them, and summarize the findings. A traditional chatbot usually replies: I don't have enough information to research that. The problem isn't intelligence. The problem is planning. To answer properly, the AI must: Search for Java AI frameworks Search for comparisons Gather information Analyze results Produce a summary That requires multiple tool calls and reasoning between each one. This is exactly what AI agents are designed to do. What Is the ReACT Pattern? ReACT stands for: Reason + Act Instead of generating one response, the AI repeatedly performs a reasoning loop. THINK ↓ ACT ↓ OBSERVE ↓ THINK ↓ ACT ↓ OBSERVE ↓ FINAL ANSWER Example: THOUGHT: I should search for Java AI frameworks. ACTION: search INPUT: Java AI frameworks 2026 ↓ OBSERVATION: Spring AI LangChain4j Semantic Kernel ↓ THOUGHT: Now I need comparison data. ↓ ACTION: search INPUT: Spring AI vs LangChain4j ↓ FINAL ANSWER Instead of guessing everything up front, the AI gathers information step by step before producing the final response. The Biggest Architectural Decision The most important design decision of Phase 6 was not modifying the existing chat pipeline . Instead of turning AiOrchestrator into a giant class responsible for both chat and agents, agents became a completely separate orchestration layer. ❌ Wrong AiOrchestrator ↓ Single Chat ↓ Agent Logic ↓ Tool Logic ↓ Everything Mixed Together ✅ Correct AgentController

Why Prompts Matter More Than You Think The difference between a great AI response and a mediocre one isn't always the model. It's the prompt. Experience this: You ask ChatGPT a vague question and get a vague answer. You ask the same AI a perfectly crafted prompt and get something incredible. The skill gap is massive. Companies are paying prompt engineers $150K+ because mastering prompts directly impacts: Response quality Token usage (costs) Speed of inference User satisfaction The Science of Better Prompts Rule #1: Be Specific, Not Vague BAD : "Write me something about AI" GOOD : "Write a technical explanation of how transformer attention mechanisms work, suitable for a developer with 2 years of ML experience" Specificity reduces hallucinations and increases relevance by 10-50x. Rule #2: Use Roles & Context You are an expert senior software engineer with 15 years of experience. You specialize in system design and scalability. Respond in a way that balances technical accuracy with accessibility. Target audience: Mid-level engineers. How would you design a real-time chat system for 10 million concurrent users? Role-based prompting improves response depth and tone. Rule #3: Provide Examples (Few-Shot Prompting) Classify the sentiment of these reviews: Example 1: "This product is amazing!" → Positive Example 2: "Terrible experience, would not recommend" → Negative Example 3: "It's okay, nothing special" → Neutral Now classify: "The service was slow but the staff was friendly" Examples guide the AI toward your exact expectations. Rule #4: Break Complex Tasks Into Steps Instead of: "Analyze this code and find bugs" Use: "1. First, read through this code carefully Identify any logical errors Check for performance issues List potential security vulnerabilities Provide a summary of findings with severity levels" Step-by-step prompts (Chain-of-Thought) improve reasoning by 20-40%. Rule #5: Specify Output Format Respond in JSON format: { "summary" : "brief explanation" , "key_

A while back I was researching a topic I didn't know much about — the kind of casual, late-night "let me just ask the AI a few questions" session. A few messages in, I asked a follow-up that only made sense in the context of what we'd just been talking about. I didn't restate the subject, because... why would I? We were three messages into the same conversation. The answer came back completely off-topic. It had lost track of what "it" referred to, latched onto the wrong noun, and confidently explained something I hadn't asked about at all. Not a small tangent — a whole paragraph about the wrong thing. My first reaction was annoyance at the model. My second, more useful reaction came a bit later: I'd been treating it like a person who remembers what we were just discussing and fills in the gaps naturally. It doesn't do that the way a human conversation partner does. If I don't restate the subject, it's genuinely not there for the model — it's not being lazy, there's just nothing to work with. So I started over-specifying. Every follow-up got longer: restate the subject, restate what I actually wanted, restate the constraint I cared about. It worked, but some days I didn't have the energy for it — I'd just take the mediocre answer, say "ok thanks," and move on. Which meant I was quietly leaving useful answers on the table half the time, just because typing out the full context felt like a chore. Eventually I stopped thinking of it as "the AI being difficult" and started treating it as a simple rule: if I want it to know something, I have to say it. It won't infer the unstated stuff the way a person would , no matter how obvious it feels to me. Once that clicked, a few concrete habits followed. Restate the subject, every time Not "what about the second one" — the actual name of the thing. It costs three words and removes an entire failure mode. Say what you actually want, not just the topic "Tell me about X" and "I'm trying to decide whether X is worth the switching co

The biggest losses in software history were, with one deliberate exception, not attacks. They were silent, correlated, self-inflicted — and they teach the exact risk autonomous AI agents are about to make expensive again. At 9:30 in the morning on August 1, 2012, Knight Capital Group was one of the largest trading firms in the United States, executing a sixth of all the volume on the New York Stock Exchange. By 10:15 it was, for practical purposes, finished. In those forty-five minutes a piece of its own trading software (not a hacker's, its own) fired more than four million unwanted orders into the market, accumulating roughly $7 billion in positions the firm never meant to hold and a loss of about $440 million by the time humans understood what their machine was doing. The cause, documented in the SEC's administrative proceeding, was almost insultingly small: a deployment that updated seven of eight servers. The eighth still carried a dormant piece of code called Power Peg, retired years earlier, and the new release reused the old feature flag that woke it up. No one attacked Knight Capital. The market data was accurate, the exchange functioned perfectly, and every system reported itself healthy while the company bled ten million dollars a minute. That shape (no adversary, no alarm, one change propagating everywhere at once) turns out to be the shape of almost every entry on the list below. We've written before about the biggest bug-bounty payouts in history , the ledger of what it costs when someone does attack. This is the other ledger, the bigger one: what software has cost when nobody attacked at all. Every figure below states what it counts, and comes from a primary or authoritative source (inquiry boards, SEC filings, statutory inquiries) linked at the end. The ledger 1. CrowdStrike outage (2024) — roughly $5.4 billion in direct losses to Fortune 500 companies alone (estimate). One faulty content update to the Falcon Sensor security agent blue-screened Windo

Picture a power plant burning fuel to spin a turbine. It is tempting to assume that with enough engineering — better seals, smoother bearings, cleaner combustion — the plant could be pushed toward converting nearly all its heat into useful work. It cannot. A large modern thermal power station turns only something like 40 to 45 percent of its fuel energy into electricity, and the missing majority is not lost to sloppy design. It is lost to a law of physics. That law sets a ceiling on every device that turns heat into work, from a car engine to a steam turbine to a jet. The ceiling is called the Carnot efficiency, and the remarkable thing about it is how little it depends on. Not on the working fluid, not on the mechanism, not on the cleverness of the builder — only on two temperatures. This article explains where that limit comes from, how to compute it, and why it reshapes how engineers think about efficiency. Why this calculation matters The Carnot efficiency is the benchmark against which every real engine is judged. When an engineer reports that a gas turbine runs at 38 percent efficiency, that number means little on its own. Compared against the Carnot limit for the same hot and cold temperatures, it suddenly tells you how much room is left — whether the design is already near the physical wall or still has slack worth chasing. It also redirects design effort toward the things that actually matter. Because the Carnot limit depends only on the ratio of cold to hot absolute temperatures, the single most powerful way to raise the ceiling is to raise the temperature at which heat enters the engine, or lower the temperature at which it is rejected. This is why turbine inlet temperatures have climbed for decades, pushing the limits of metallurgy and cooling. Polishing internal friction yields small gains; raising the hot-side temperature raises the ceiling itself. The core formula Sadi Carnot, in 1824, imagined an idealized engine running on a perfectly reversible cyc