标签：#Engineering

Your AI agent is confident. It points to line 42 of PaymentService.java . "There's your null pointer exception." You check. Line 42 is a comment. The code was refactored 14 commits ago. The production crash happened 3 hours ago . Your agent just spent 45 minutes debugging ghosts . The Problem: Agents Are Stuck in the Present Every AI coding agent today — Claude Code, Cursor, Copilot, Cody, you name it — operates on the same assumption: The code that matters is at HEAD . But production bugs don't live at HEAD . They live in the commit that was running when the crash happened. That commit is buried under hotfixes, refactors, dependency updates, and feature merges that landed after the incident. HEAD (now) ← Agent analyzes THIS │ ├─ feat: add new payment provider ├─ refactor: extract UserService ├─ fix: handle edge case in checkout ├─ chore: update dependencies │ ▼ a1b2c3d (3 hours ago) ← Bug ACTUALLY lives HERE Your agent confidently finds bugs in code that didn't exist when the crash occurred . The Insight: Git Already Has Time Travel We don't need a time machine. Git has had one for years: git worktree . # Get the commit from 3 hours ago git log --before = "3 hours ago" -1 --format = "%H" # → a1b2c3d4e5f6... # Create an isolated, read-only snapshot at that commit git worktree add /tmp/debug-a1b2c3d a1b2c3d # Now analyze the historical codebase cat /tmp/debug-a1b2c3d/src/PaymentService.java # Clean up when done git worktree remove --force /tmp/debug-a1b2c3d This gives you: ✅ Isolated — doesn't touch your working directory ✅ Parallel — can have multiple historical snapshots simultaneously ✅ Disposable — cleanup is one command ✅ Zero deps — pure Git, works everywhere The Missing Piece: Teaching Agents When to Time-Travel Agents already know git log , git show , git diff , cat , grep . They can analyze code perfectly. What they struggle with : Fuzzy time → commit resolution — "last night", "v2.4.1", "the deploy before the hotfix" Worktree lifecycle management — create,

Let's be real: our personal medical history is a mess. It’s a chaotic mix of PDF lab results, grainy scans of prescriptions, and cryptic Electronic Medical Records (EMR) scattered across different hospital portals. If you’ve ever tried to remember exactly when a specific symptom started or how your cholesterol has trended over the last decade, you know the "search" struggle is real. In this guide, we are moving beyond simple folders. We are architecting a Personal Health Knowledge Base using a modern Vector Database and RAG (Retrieval-Augmented Generation) pipeline. We’ll leverage Qdrant for high-performance similarity search, Unstructured.io for complex document parsing, and Sentence-Transformers to turn 10 years of medical jargon into searchable embeddings. By the end of this post, you'll have a system capable of cross-year symptom correlation and instant medical history retrieval. The Architecture: From Pixels to Insights 🏗️ The biggest challenge with medical records isn't storage; it's ingestion . Medical PDFs are notoriously difficult to parse because they often contain nested tables and checkboxes. Our pipeline handles this by isolating the layout before embedding. graph TD A[Raw Medical Data: PDFs, Scans, EMRs] --> B[Unstructured.io: Partitioning & OCR] B --> C[Text Chunking & Cleaning] C --> D[Sentence-Transformers: Vector Embedding] D --> E[(Qdrant Vector DB)] F[User Query: 'Show me my blood sugar trends since 2015'] --> G[FastAPI Interface] G --> H[Query Embedding] H --> I[Vector Search in Qdrant] I --> J[Contextual Results + LLM Synthesis] J --> K[Actionable Health Insight] Prerequisites 🛠️ To follow along, you'll need: Python 3.9+ Unstructured.io : For the heavy lifting of PDF/Image parsing. Qdrant : Our vector engine (run it via Docker: docker run -p 6333:6333 qdrant/qdrant ). Sentence-Transformers : To generate local embeddings without sending sensitive data to the cloud. FastAPI : To wrap it all in a slick API. Step 1: Parsing the Chaos with Unstructu

Pull a hot steel bolt out of a furnace and quench it in oil, and a fair question is: does the bolt cool from the outside in, with a sharp temperature difference between its skin and its core, or does the whole thing drop in temperature more or less together? The answer is not obvious from the part itself. A thin copper washer and a thick ceramic block behave very differently in the same bath, even at the same starting temperature. The Biot number is the small calculation that settles this question before you commit to any heavy analysis. It tells you, in a single dimensionless figure, whether an object can be treated as having one uniform temperature or whether you must resolve a temperature gradient inside it. That distinction changes the math from a one-line exponential decay to a partial differential equation. Why this calculation matters Transient heating and cooling problems show up everywhere: heat-treating metal parts, quenching forgings, cooling electronics, baking or chilling food, warming up an engine block. In every one of these, the engineer wants to know how the temperature changes over time. The hard version of that question requires solving the heat conduction equation across the body, with position and time as variables. The easy version is the lumped-capacitance model, which treats the whole object as a single point at one temperature. It reduces the problem to a simple first-order exponential. The catch is that the lumped model is only valid when internal conduction is fast compared with surface convection. The Biot number is exactly the check that tells you whether that condition holds. Skip the check and apply the lumped model where it does not belong, and you can badly mispredict cooling times, residual stresses, and the risk of cracking from thermal gradients. The core formula The Biot number compares two thermal resistances. One is the resistance to conducting heat through the inside of the solid. The other is the resistance to carrying heat a

Stop Writing Prompt Strings: Meet PromptForge Core As AI becomes part of modern applications, prompts are no longer just strings—they're becoming part of your codebase . Yet most of us still write prompts like this: const prompt = " You are a helpful assistant. \n " + " Summarize the following text. \n " + " Return the output as JSON. \n " + " Keep it concise. \n " + " Use simple language. " ; This works... Until your project grows. The Problem As prompts become larger, they quickly become difficult to maintain. You start dealing with: ❌ Giant string templates ❌ Copy-pasted prompts ❌ Missing variables ❌ Inconsistent formatting ❌ Provider-specific implementations ❌ Difficult debugging Unlike your application code, your prompts have: No structure No validation No type safety What if prompts were treated like code? That's exactly why I built PromptForge Core . PromptForge is an open-source TypeScript toolkit for building production-ready prompts using a clean, structured API. Instead of writing strings... const prompt = " You are... " You write import { pf } from " @promptforgee/core " ; const summarize = pf . define ({ input : z . object ({ text : z . string (), }), output : z . object ({ summary : z . string (), }), messages : ({ text }) => [ pf . system ` You are an expert summarizer. ` , pf . user ` Summarize: ${ text } ` , ], }); Much easier to read. Much easier to maintain. Features PromptForge focuses on developer experience. ✅ Type-safe prompt definitions ✅ Structured prompt composition ✅ Prompt compilation ✅ Validation ✅ Provider-agnostic architecture ✅ Reusable prompt blocks ✅ Modern TypeScript API Compile Once, Use Anywhere Instead of maintaining different formats for every provider... PromptForge compiles your prompt into provider-specific formats. Prompt Definition ↓ Prompt Compiler ↓ OpenAI Anthropic Gemini Ollama Write once. Compile anywhere. Composable Prompts Large AI applications usually repeat the same instructions. With PromptForge you can compose p

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

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

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

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-

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

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

How you split your code into repositories seems like a plumbing decision, but it quietly shapes how your team collaborates, ships, and reasons about the system. A monorepo keeps everything in one repository; a polyrepo gives each service or app its own. Neither is universally right, and the loudest opinions online usually ignore your actual stage and team size. Here's how to think about it clearly. What a monorepo buys you A monorepo puts your web app, mobile app, backend, and shared libraries under one roof. The advantages are real, especially for smaller teams: Atomic changes. Update a shared type and every consumer in the same pull request. No cross-repo coordination dance. One source of truth for tooling. A single lint, format, and CI config instead of drift across a dozen repos. Effortless code sharing. Shared TypeScript packages are just imports, not published versions you have to bump and reinstall everywhere. Easy refactoring. You can find and fix every caller of a function because it's all in front of you. Tools like Turborepo and Nx make this practical by caching builds and only running work for the parts that actually changed. What a monorepo costs The trade-offs show up as you grow. Build and CI times can balloon without smart caching. Access control is coarser — it's harder to give a contractor one service without the whole codebase. And a naive setup rebuilds and tests everything on every change, which gets slow fast. Good tooling mitigates all of this, but you have to invest in it deliberately. What a polyrepo buys you Separate repositories give each service hard boundaries . A team owns its repo end to end, deploys on its own schedule, and can't accidentally reach into another team's internals. Access control is naturally granular, CI for each repo is small and fast, and the blast radius of a bad change is contained. The cost is coordination. A change that spans services becomes multiple pull requests across multiple repos that must land in the right