LLM Engineering

Glue is not glamorous. In most AI product discussions, the model gets the spotlight. The harness—the scripts, prompts, validators, retry rules, state files, tool adapters, and stopping criteria around the model—gets treated as plumbing. Necessary, slightly annoying, and best ignored until it leaks. That habit is becoming expensive. The paper Natural-Language Agent Harnesses argues that the surrounding execution system is no longer a secondary implementation detail. It is often the actual unit of agent performance, reliability, and portability.1 The paper’s useful claim is not that “natural language replaces code.” That would be a lovely fantasy for people who have not debugged parsers, sandboxes, or file permissions lately. The sharper claim is that part of the harness can become an editable natural-language policy object, while exact execution remains in code. ...

Context is comforting. A large context window gives managers, developers, and product demos the same pleasant illusion: if the model can see enough of the repository, it should stop missing important files. Put the whole codebase into the window. Add retrieval if necessary. Let the agent read, reason, edit, and move on. ...

A cloud incident does not arrive politely. It does not say, “Hello, I am a memory leak in service X, beginning at 14:03, propagating through service Y, and pretending to be a latency spike somewhere else.” That would be useful. Naturally, production systems prefer theatre. So when companies imagine AI agents taking over cloud Root Cause Analysis (RCA), the promise sounds almost unfairly attractive. Give the agent logs, metrics, traces, a Python executor, and a large enough model. Let it inspect the evidence, reason through the causal chain, and return the faulty component, incident time, and failure reason before the human on-call engineer has finished the second coffee. ...

The problem is not that LLMs cannot write code. It is that they write the wrong kind too confidently. A familiar scene: someone gives an LLM a task, receives a block of code that looks elegant, runs it, and discovers that it has invented an API, misunderstood the library, or solved a neighboring problem with excellent grammar. This is annoying when the target is ordinary Python. It is worse when the target is a specialized framework where the code is supposed to encode logic, constraints, and domain structure. ...

Assembly lines are not exciting because every worker improvises. They are useful because each station does a narrow job, hands the result forward, and leaves as little room as possible for charming chaos. That is also the quiet lesson in A Practical Guide for Designing, Developing, and Deploying Production-Grade Agentic AI Workflows.1 The paper looks, at first glance, like another guide to agents, tools, MCP servers, multi-model reasoning, and cloud-native deployment. The tempting summary would be: “Here are nine best practices for building agentic AI.” ...