标签：#engineering

Software architecture debates have a problem that most other engineering disciplines don't: the alternative was never built. When a bridge fails, the failure is physical, attributable, and measurable against every other bridge that didn't. The engineering decisions that caused it can be isolated, traced, and corrected — not just in theory, but in the next bridge, because the material itself produces feedback that no amount of professional opinion can override. Steel deflects. Concrete cracks. Physics doesn't care what the architect believed. Software produces no equivalent feedback. A system built around the wrong abstractions compiles, runs, ships, and passes its tests just as readily as one built around the right ones. A bug introduced by a misaligned domain model looks identical, from the outside, to a bug introduced by a typo. A feature that took three times longer than it should have, because the structure made it harder than the business logic warranted, produces no artifact that distinguishes it from a feature that was simply difficult. The cost is real. The cause is invisible. This is the unfalsifiability problem, and it runs deeper than "we can't measure everything." It means that when a system becomes expensive to change, the diagnosis almost always lands on the wrong variable. The domain is complex. The requirements changed. The previous team was careless. Almost never: the structure was wrong, and the structure was wrong because nobody ever built the other version of it to compare against. That version doesn't exist, it never will, and every architectural argument in the industry is conducted in its absence. This would be a purely philosophical problem if there were nothing to do about it. There is something to do about it — but it requires accepting that the standard metric for software quality, whether it works, is measuring the wrong thing entirely. The Metric That Hides the Problem The natural substitute for "is this good engineering" is "does it wor

Why HDI PCB Manufacturing Starts Long Before the First Hole Is Drilled When people think about PCB manufacturing, they usually imagine drilling, plating, imaging, etching, solder mask, and surface finishing. For conventional PCBs, that assumption isn't too far from reality. For HDI (High Density Interconnect) PCBs, however, manufacturing actually begins long before any physical production starts. The success of an HDI project is often determined during engineering review rather than on the factory floor. Manufacturing Starts with Design Decisions A PCB layout may pass every design rule check inside CAD software while still being difficult to manufacture efficiently. Typical examples include: unnecessary stacked microvias excessive sequential lamination extremely aggressive trace and space dimensions unrealistic copper balancing inefficient stack-up planning None of these issues are fabrication defects. They are engineering decisions. The earlier they are identified, the lower the overall project cost becomes. The Stack-Up Is More Important Than Many Engineers Expect One of the biggest misconceptions is that increasing the layer count automatically solves routing problems. In reality, a carefully planned stack-up usually provides greater benefits than simply adding more copper layers. A good stack-up improves: signal integrity impedance consistency EMI performance power distribution thermal behavior More importantly, it creates a PCB that is easier to manufacture repeatedly with stable quality. HDI Is a Balance Between Performance and Manufacturability Many first-time HDI designs focus only on routing density. Experienced engineers usually focus on manufacturability. For example: Should this microvia really be stacked? Can staggered vias achieve the same result? Is another lamination cycle actually necessary? Can the BGA fan-out be optimized differently? Each decision influences fabrication complexity, yield, lead time, and production cost. Why DFM Matters More for H

Part 1 of "Trust the Machine" -> a series on building AI infrastructure that is secure, compliant, and governable by design. Most organizations can produce an accurate catalog of the web services they operate. Far fewer can produce an equivalent catalog of the AI systems they run — the models, fine-tunes, retrieval pipelines, agents, and third-party AI APIs now embedded throughout their products and internal tooling. This asymmetry defines the state of AI security in 2026. Adoption has outpaced oversight. Industry reporting this year has described a surge in enterprise AI activity on the order of 83% year over year, with governance and visibility lagging well behind. The consequence is a large and only partially mapped attack surface — one that many organizations cannot fully enumerate, let alone defend. Every mature security program rests on a single first principle: you cannot protect what you cannot see. Artificial intelligence is no exception. Before threat-modeling an agent or authoring a guardrail, an organization must be able to answer a deceptively difficult question: what AI is running across the environment, and who is accountable for it? This post examines how to build that answer. The rise of shadow AI Shadow IT — the unsanctioned adoption of tools outside official channels has been a recognized challenge for decades. Shadow AI is its faster-moving successor, and it appears in more forms than most inventories are designed to detect: Embedded API calls. A product team integrates a hosted model in a few lines of code and an API key, with no formal review. Copilots and assistants enabled across existing SaaS platforms, frequently activated by the vendor rather than the customer. Fine-tunes and adapters trained on internal data and stored in locations that fall outside standard scanning. Agents and automations that have incrementally acquired the ability to act—filing tickets, sending communications, initiating transactions—one permission at a time. Model de

Reading Lilian Weng's harness engineering survey as a reliability engineer — what self-improving harness papers actually show, and the three invariants every working loop converges on.

We’ve all been there: staring at a stack of printed lab results or a folder full of cryptic report_final_v2_NEW.pdf files, trying to remember if our cholesterol was higher or lower two years ago. For developers, this isn't just a filing problem—it's a data engineering challenge. In the world of healthcare, data is messy, siloed, and often locked in "unstructured" formats. To build a truly personal Electronic Health Record (EHR) system, we need more than just a folder; we need a RAG (Retrieval-Augmented Generation) pipeline that can parse PDFs, map them to the FHIR (Fast Healthcare Interoperability Resources) standard, and provide natural language insights. In this guide, we’ll leverage Unstructured.io , Milvus , and DuckDB to turn chaotic medical PDFs into a queryable, structured knowledge base. The Architecture: From Raw Pixels to Structured Insights Before we dive into the code, let’s look at how the data flows from a messy lab report to a structured answer. graph TD A[Unstructured PDF Reports] --> B[Unstructured.io Partitioning] B --> C{Data Split} C -->|Textual Context| D[Milvus Vector DB] C -->|Tabular Data| E[DuckDB Structured Storage] D --> F[LangChain RAG Engine] E --> F G[User Query: Is my glucose trending up?] --> F F --> H[FHIR-Formatted Response] Why this stack? Unstructured.io : The gold standard for handling "ugly" PDFs (tables, headers, and nested lists). Milvus : A high-performance vector database built for scale. DuckDB : Perfect for running complex analytical SQL queries on the extracted "structured" parts of our medical data. FHIR Standard : To ensure our data follows global healthcare interoperability rules. Prerequisites Make sure you have your environment ready: pip install langchain milvus unstructured[pdf] duckdb openai Step 1: Extraction with Unstructured.io Medical PDFs often contain complex tables. Standard PDF parsers usually fail here. We’ll use unstructured to partition the document into logical elements. from unstructured.partition.pdf

You asked your AI to help you plan a trip. It gave you a paragraph about packing layers and booking early. You needed a checklist, a hotel shortlist, a flight window, and a rough daily schedule. What you got was a thoughtful non-answer dressed up as advice. That gap — between what AI tells you and what it could actually do for you — is the gap agentic AI is designed to close. And most people don't know it exists. The Difference Between Answering and Acting Standard AI models are trained to respond. You send a prompt, they generate a reply. The entire interaction lives inside a single text exchange. Agentic AI operates differently. Instead of producing one answer, it takes a goal and breaks it into a sequence of steps — then executes them, one after another, checking its own output along the way. It can look things up, organize information, write to a document, revisit a step if something doesn't look right, and deliver a final result that's actually usable. The travel example makes this concrete. A conversational model tells you to pack a rain jacket. An agentic setup builds you the trip: it pulls destination weather data, generates a packing list specific to your travel dates, identifies hotels in your price range, and drops everything into a structured itinerary. Same goal. Completely different level of output. Author's note: The word "agentic" has been overloaded to the point of meaninglessness in tech marketing. For our purposes here, it means one specific thing — an AI that runs a loop: think, act, observe the result, decide the next action. If it's not doing all four of those things in sequence, it's not really an agent. It's just a chatbot with extra steps. Why This Loop Changes Everything The reason agentic AI feels qualitatively different isn't magic — it's architecture. The core mechanic comes from a framework called ReAct (short for Reasoning and Acting), introduced in a 2023 paper by Yao et al. and now foundational to most production agent systems. The l

Quick answer: The PromptEval Prompt Quality Report scored over 1,000 real prompts across 12 use cases. The average was 52 out of 100, and only 8% reached "good" (75+). The strongest single predictor of a good prompt is whether it defines its output format, worth 27 points on average. In 9 of 10 prompts, the weakest dimension was robustness. This is the PromptEval Prompt Quality Report . Over 1,000 real prompts have been scored on PromptEval , submitted by real users across use cases from customer support to healthcare to code. Each was scored from 0 to 100 on four structural dimensions: clarity, specificity, structure, and robustness. Every figure below comes from that set. No prompt text is stored; the analysis is anonymous and aggregate. Only 8% of the 1,000+ scored prompts reached "good" (75 or higher). Fewer than 1% reached "excellent." Source: PromptEval Prompt Quality Report, 2026 How the scores break down Here is how the scores spread across the set. The bar for "good" is 75, the point where a prompt is clear, specified, and holds up under variation. Score range Share of prompts 0 to 40 (failing) 25% 41 to 60 (below par) 31% 61 to 74 (functional but mediocre) 36% 75 to 84 (good) 8% 85 to 100 (excellent) under 1% Roughly 92% of prompts never reach "good," and almost none reach "excellent." This includes prompts from people who clearly know the tools. The gap is not talent. It is a few missing pieces that repeat. What separates a good prompt from a bad one For each structural element, we compared the average score of prompts that had it against those that did not. These are averages across the set, not a controlled experiment, so read them as correlation. But the gaps were large and consistent. The prompt... Avg with Avg without Point gap Defines the output format 58 31 +27 Has explicit constraints (what not to do) 63 41 +22 Assigns a role or persona 57 42 +15 Includes at least one example 64 51 +13 Prompts that define their output format score 27 points higher

A lot of AI memory systems start with the same temptation: "Just save the useful thing." That sounds harmless until the knowledge base becomes a junk drawer. Half the notes are too specific, a few are duplicates, some are obsolete, and nobody knows which ones the agent should trust. In ai-assistant-dot-files , the memory system is deliberately slower. It uses a promotion lifecycle: Capture -> Candidate -> Audit -> Approve -> Index -> Retrieve -> Expire That lifecycle is documented in docs/runbooks/memory-engineering.md , and the important word is not "capture." It is "candidate." Nothing writes directly to memory The framework has a durable memory layer: Knowledge Items in shared/knowledge/ , ADRs in docs/adrs/ , the domain dictionary, team topology, a feature archive, and a registry at shared/memory-registry.json . But a lesson from a delivery does not jump straight into shared/knowledge/ . It first becomes a Candidate Record. That record has required fields: Source Type Evidence Tags Expiration condition Then memory-engineer audits it: Is it reusable? Is it already covered? Is it too speculative? Does it belong as a Knowledge Item, or should it become a rule change, prompt edit, or ADR instead? Only after that does a human approve the destination. The design is intentionally similar to code review. Durable memory changes future behavior, so they deserve a paper trail. Rejection is a feature One of my favorite parts of the memory runbook is that it has explicit rejection rules. Do not promote a memory when it is: a one-off already covered too speculative That makes "zero candidates promoted this cycle" a healthy result, not a failure. This is where memory engineering starts to look less like note-taking and more like gardening. The point is not to preserve every leaf. The point is to keep the soil useful. Expiration matters The lifecycle also includes expiration. A Knowledge Item can become stale when the underlying code, agent, or pattern changes. It can be supers

I hesitated to write this. Not because I don’t have an opinion about AI in software engineering, but...

When I wrote about shifting the engineering process left — spec sessions, autonomous agents, humans reviewing output rather than writing code — a question kept coming up. Where does the Product Owner fit in all of this? It’s the right question. And I think the answer is more interesting than “the PO disappears.” Let’s start with acceptance criteria. We invented them to bridge a gap. The team needed to know when something was done. The PO needed confidence that what got built matched the intent. Acceptance criteria were the contract between the two. But if the Spec Session is where intent gets defined — by the whole team, together, before the agent runs — that gap closes. What the team agreed on in the room is the definition of done. The spec is the acceptance criteria. You don’t need a separate validation step because the planning and the agreement happened at the same time. The tighter the loop, the less ceremony you need around it. There’s a caveat though. The spec is a necessary contract. It’s not a sufficient one. Simon Martinelli’s work on the AI Unified Process validates the spec-driven approach technically. But his model is about the artifact — requirements at the center, AI generating everything else from them. How the team actually builds shared understanding before the spec exists isn’t something it addresses. That’s not a criticism. It’s just a different question. A spec written after a real Spec Session — where the team worked through edge cases together, disagreed, got to resolution — is different from a spec written by one person and signed off asynchronously. Same artifact. Different quality of shared understanding. That distinction matters when the agent hits an edge case the spec didn’t anticipate. So what’s actually left for a dedicated PO? Two things. And they’re very different. The first is product thinking — challenging intent, representing user needs, asking why before the agent runs with something. That’s valuable. But it doesn’t require a ded

I used to fix weak AI drafts by asking for better prose. "Make it clearer." "Make it more persuasive." "Make it sound less generic." The output improved a little. Then it failed in the same place: the article looked polished, but nobody remembered what it was trying to say. TL;DR: Before you ask AI to write, fill a five-line editorial brief: audience, takeaway, material to use, first point to place, and scope delegated to AI. The prompt gets shorter because the decision-making moved back to the human. Quick answer: what should I decide before asking AI to write? Decide these five things before the first draft: Who is the reader? What should that reader take away? Which material should be used, and which material should be cut? What should appear first so the reader can follow the argument? Which part is the AI allowed to decide, and which part stays with you? That is the difference between an AI writing prompt and an AI writing workflow. A prompt says, "write a useful article about this." A workflow says, "write for this reader, to deliver this point, using this material, in this order, while leaving these decisions untouched." Here is the copy-paste version I now use before drafting: cat > ai-writing-brief.md << ' BRIEF ' Audience: Takeaway: Material to use: First point to place: Scope delegated to AI: BRIEF Output: a five-line brief that makes the human decisions visible before the AI starts drafting. If those five lines are empty, a better prompt usually will not save the article. It will only make the generic answer prettier. Why polished AI writing still feels empty AI can satisfy the instruction you give it. If you ask for more detail, it adds detail. If you ask for simpler language, it removes jargon. If you ask for a friendly tone, it softens the edges. All of that can be correct and still useless. The missing part is not grammar. It is aim. A draft can have headings, clean paragraphs, and natural transitions while still leaving the reader with no decision,

One of the biggest takeaways from Chapter 3 of AI Engineering was realizing that building an AI model is only part of the challenge. Figuring out 𝗵𝗼𝘄 𝘁𝗼 𝗲𝘃𝗮𝗹𝘂𝗮𝘁𝗲 𝗶𝘁 𝗳𝗮𝗶𝗿𝗹𝘆 𝗮𝗻𝗱 𝗮𝗰𝗰𝘂𝗿𝗮𝘁𝗲𝗹𝘆 can be just as difficult. With traditional software, it's usually easy to tell whether something works. If a calculation is wrong or a test fails, you know there's a bug. But AI doesn't always work that way. A model can generate multiple reasonable answers to the same question, making it much harder to determine which one is actually better. That made me think: 𝗛𝗼𝘄 𝗱𝗼 𝘄𝗲 𝗸𝗻𝗼𝘄 𝗶𝗳 𝗮𝗻 𝗔𝗜 𝗺𝗼𝗱𝗲𝗹 𝗶𝘀 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗶𝗺𝗽𝗿𝗼𝘃𝗶𝗻𝗴? 𝗕𝗲𝗻𝗰𝗵𝗺𝗮𝗿𝗸𝘀 𝗡𝗲𝗲𝗱 𝘁𝗼 𝗞𝗲𝗲𝗽 𝗘𝘃𝗼𝗹𝘃𝗶𝗻𝗴 Reading this section made me realize how difficult it is for evaluation benchmarks to keep up with the pace of AI development. The chapter explains that GLUE (General Language Understanding Evaluation) was introduced in 2018 to measure how well language models performed on common natural language tasks. But within about a year, models had already become so good at it that researchers introduced SuperGLUE in 2019 as a more difficult benchmark. GLUE evaluates tasks such as: Question answering Sentiment analysis Sentence similarity Text classification The chapter also mentions newer benchmarks like: SuperGLUE MMLU (Massive Multitask Language Understanding) MMLU-Pro Each one was introduced because the previous benchmark was no longer challenging enough. What I found interesting is that a model getting a higher benchmark score doesn't always mean it understands language better. Sometimes it simply means the model has become very good at solving that particular benchmark. 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗘𝗻𝘁𝗿𝗼𝗽𝘆 𝗮𝗻𝗱 𝗣𝗲𝗿𝗽𝗹𝗲𝘅𝗶𝘁𝘆 Another section I really enjoyed was the explanation of entropy and perplexity. The chapter explains entropy as a measure of how much information a token carries and how difficult it is to predict the next token in a sequence. Perplexity measures uncertainty. If a model is very uncertain about what comes next, its perplexity will be higher. If

Tilt a CD or DVD under a desk lamp and a band of color sweeps across its surface. The disc is not painted; it is a spiral of microscopic pits, packed so tightly that they act on light the way a finely ruled scientific instrument does. Each wavelength of white light leaves the surface at its own angle, and your eye sees the result fanned out as a rainbow. That is a diffraction grating at work. The same principle that decorates a CD is the engine inside spectrometers that identify chemical elements, tune lasers, and read the composition of distant stars. This article explains how a grating spreads light, how to compute the angles, and where the analysis goes wrong. Why this calculation matters A prism also splits white light, but a grating does it with far more control and far more precision. Because the spreading depends on a countable number — the spacing between lines — a grating can be designed to send a chosen wavelength to a chosen angle. That predictability is what makes it the heart of the spectrometer. Spectroscopy underpins a remarkable range of work. Astronomers read a star's chemistry and velocity from the dark lines in its spectrum. Chemists identify unknown compounds by the wavelengths they absorb. Telecommunications engineers use gratings to combine and separate the many wavelengths sharing a single optical fiber. In every case the first task is the same: given the grating and the light, predict the angle at which each wavelength emerges. Get that wrong and a spectral line lands on the wrong detector pixel, and the measurement is meaningless. The core formula A diffraction grating is a surface ruled with a large number of equally spaced, parallel lines. When light passes through or reflects off it, each line acts as a source of secondary waves. Those waves interfere, and they reinforce each other only in specific directions — the directions where waves from neighboring lines arrive exactly in step. The condition for that reinforcement is the grating equ

I recently worked through the classic Word Break problem in an interview. My approach was solid from the start — recursion with memoization, a breakable helper that tests every prefix and recurses on the rest. The logic was right. What slowed me down was everything around the logic. Here's the solution I landed on: class Solution { public: bool wordBreak ( string s , vector < string >& wordDict ) { unordered_set < string > dict ( wordDict . begin (), wordDict . end ()); unordered_map < size_t , bool > memo ; return breakable ( s , dict , memo , 0 ); // missed: breakable was a free function defined below -> "not declared in this scope" } private : // missed: had int here, compared against s.length() (size_t) -> sign-compare warnings bool breakable ( const string & s , const unordered_set < string >& dict , unordered_map < size_t , bool >& memo , size_t starting ) { if ( starting == s . length ()) return true ; if ( memo . count ( starting )) return memo [ starting ]; for ( size_t e = starting + 1 ; e <= s . length (); e ++ ) { string word = s . substr ( starting , e - starting ); // missed: shadowed an outer `word`, and had substr(starting, e) instead of e - starting if ( dict . count ( word ) && breakable ( s , dict , memo , e )) { memo [ starting ] = true ; // missed: wrote == instead of =, so success was never cached return true ; } } memo [ starting ] = false ; // missed: this line, so failures were never cached and memoization broke down return false ; } }; The real lesson Most of what tripped me up was syntax and scope — a function declared in the wrong place, signed/unsigned mismatches, a shadowed variable, == where I meant = . None of these were about the algorithm. But because I spent my time chasing them, I had less room to focus on the one thing that actually matters in this problem: the logical correctness of the memoization. The takeaway I'm keeping: get the syntax and scoping clean early, so the debugging budget goes toward logic, not typos. That's the

InfoQ has opened enrollment for a five-week AI Security & Privacy Engineering cohort for senior engineers and architects in regulated industries, focused on applying security, privacy, threat modeling, observability, and governance practices to production AI systems. By Artenisa Chatziou

In the previous article, we argued that a Locator is neither a UI control nor a search mechanism. It is an architectural concept that resolves business references within a specific business context and transforms them into canonical business identities. If that is true, however, an obvious question immediately follows. How can a Locator be described? Not how it is implemented. Not how it is executed. But how it can be described independently of any particular implementation. This question is more important than it may seem at first glance. If two different development teams decide to implement a Locator, how can they be sure they are implementing the same concept? How can we discuss a Locator without referring to a particular library, programming language, or framework? The answer is that, like any mature architectural concept, a Locator must first be separated from its implementation. This distinction appears repeatedly throughout the history of software engineering. Relational theory existed before relational database systems. SQL does not describe how a query will be executed. It describes only the result we want to obtain. The choice of indexes, execution plans, and optimization algorithms is the responsibility of the query optimizer. Exactly the same principle applies here. A Locator should not be defined by the mechanism that implements it. It should be possible to describe it independently of that mechanism. This naturally leads to three distinct levels of abstraction. Locator Pattern │ ▼ Locator Definition │ ▼ Execution Engine The Locator Pattern is the architectural concept itself. The Locator Definition is the declarative description of a particular resolution process. The Execution Engine is the component responsible for interpreting that description and performing the actual resolution. Each level has a different responsibility, and they should never be confused with one another. This means that a Locator Definition is not an implementation artifact. It

The Model Context Protocol team has promoted its Enterprise-Managed Authorisation extension to stable status, adding a centralised way for organisations to control access to MCP servers through their identity provider. The project states the aim is to replace per-server consent prompts with a zero-touch flow in which users sign in once and then access approved servers without further setup. By Matt Saunders

The Problem Nobody Talks About Everyone's posting AI-generated videos — characters speaking with lip-sync, manga panels coming alive, virtual idols dancing. The pitch: "just describe what you want." I tried. For months. Here's what I got: Character's face morphed by frame 2 "Slowly looks up" became "violent head shake" Voice-over sounded like Google Translate Same prompt, 3 runs, 3 completely different results No idea what to include or how long the prompt should be Tutorials were either too vague ("be detailed") or too technical (parameter tuning from line 1). The real issue: video prompts are structurally different from text/image prompts. You need to simultaneously control visuals, motion, audio, camera, and consistency constraints — in the right order, at the right length. What I Found A Skill in the Model Studio official repo called happyhorse-prompt-studio . It doesn't teach you theory — it asks you questions and assembles the prompt for you . 4-phase flow: 1. Inspiration Menu Shows you 4 "flavors" of what HappyHorse can do: Flavor What it does A · Voiced Manga Drama Characters talk to each other, with voice + lip-sync B · Character Voice PV Single character self-introduction, 8-10 sec C · Manga Panel Motion Static manga panel starts breathing D · Virtual Idol MV Idol performance with choreography 2. Discovery Asks you conversationally: character appearance, scene, emotion, dialogue, voice type, art style, camera. 3. Prompt Assembly Assembles using the HappyHorse Formula : Scene + Subject + Motion + Audio + Quality Key techniques: @「Image n」 syntax locks character identity across shots Dialogue ≤15 characters (split shots if longer) Japanese prompts work best (HappyHorse is JP-optimized) Always end with キャラの顔・髪・衣装が変わらない (face/hair/outfit stays unchanged) 4. Quality Check Auto-reviews: completeness, compliance, cost estimate, optimization tips. Before vs. After Dimension Writing myself With Prompt Studio Attempts needed 10-20 before one usable 2-3 to satisfacti

Most prompts ask AI to explain things. The best ones ask it to show you something instead. That distinction sounds cosmetic. It isn't. It changes what the model generates, how you process it, and — more importantly — whether it actually sticks. I came across this idea while watching an interview with Amanda Askell — a philosopher and researcher at Anthropic whose work sits at the intersection of AI alignment and what you might loosely call Claude's inner life. She's a primary author of the document that defines Claude's values and character — the framework that governs how the model reasons when the rules run out. Almost as an aside near the end of the interview, she mentioned a prompting technique she uses to understand complex concepts. It stopped me cold. Not because it was elaborate. Because it was disarmingly simple, and it worked in a way I hadn't thought to ask for. The Exact Prompt Template Here it is, cleaned up and ready to use: I want to understand [concept]. Please explain it by writing a fable — an indirect, narrative version of the concept. The story should embody the concept completely without naming it directly. Ideally, the reader should only start to realize what the concept actually is near the end of the story. After the fable, add a short explanation that names the concept clearly and connects it back to the key moments in the story. That's it. No elaborate scaffolding. No chain-of-thought trigger. No persona assignment. Just a deliberate decision about the order in which understanding should arrive. Why This Works (and Why Direct Explanation Often Doesn't) When you ask AI to explain a concept directly, you get a definition. Definitions are accurate and forgettable. The model produces the statistical center of everything written about that concept — clear, complete, and utterly without friction. Friction, it turns out, is how things get encoded. When a concept arrives wrapped in a story, your brain does something different. It tracks characters,

Honestly it's not a new concept. this feature already existed in models before. problem was the models were just weak. Looping only works if each attempt gets the agent closer to the correct solution. Earlier models weren't consistent enough for that. They often misunderstood feedback, repeated the same mistakes, or got stuck in an infinite loop. Instead of improving with each iteration, they frequently failed to make meaningful progress, eventually consuming large numbers of tokens without solving the problem. The Context Window Limitation Earlier language models had much smaller context windows. As the agent went through more iterations, the conversation history and reasoning gradually filled the available context. Once the context window was exceeded, older messages had to be dropped or compressed into summaries. As a result, the agent could forget previous failed attempts, lose important clues or reasoning, and sometimes repeat the same mistakes it had already made. So what did modern models actually fix? Bigger context windows Models can now hold way more of the conversation/history without forgetting, so the agent doesn't need to spin up a fresh session every few iterations. it can just keep looping with the full history of what failed and why. modern models also got way more consistent earlier if you asked a model to fix the same bug 5 times you'd get 5 different half-baked answers, now it actually converges toward the real fix. and tool use got better too . Old models could write code but couldn't run it and read the actual error, now they call a test runner, see the real failure, and fix that exact thing which is literally what makes the "verify" step possible. And then there's inference it is simply the process of a model generating an answer. like when you type "write a java binary search," the model reads your prompt, thinks, and generates code that whole process is inference. every time the model generates text, that's one inference. now here's the thin