LLMアプリは「ハーネス」が9割 ── Perl/CGIの現役SaaSにAIエージェントを組み込んで学んだことA developer shares lessons from integrating an AI agent into a legacy Perl/CGI…

A developer writing on the Japanese engineering platform Zenn has published a set of lessons from embedding an AI agent into a long-running commercial SaaS built on Perl and CGI, arguing that most of the engineering effort in an LLM application goes into the "harness" — the surrounding control structure — rather than into the language model itself. The observation matters because it pushes back against the common assumption that picking the best model is the decisive move, suggesting instead that the scaffolding around the model determines whether a feature is reliable enough to ship.

In this context, the harness refers to everything that wraps the model call: assembling and trimming context, defining and validating tool interfaces, parsing and checking outputs, handling retries and failures, enforcing guardrails, and wiring the whole loop into an existing product. The author's framing that this accounts for roughly ninety percent of the work is a rhetorical estimate rather than a measured figure, but it aligns with a broader shift in how practitioners describe agent development. As models have become more capable and more interchangeable, the differentiating engineering has moved outward toward orchestration, evaluation, and integration.

The legacy stack makes the point vivid. Perl with CGI is one of the oldest web application architectures still in production, dating to the 1990s, and the Common Gateway Interface model typically spawns a fresh process per request with little shared state between them. That design sits awkwardly next to modern agent patterns, which often assume persistent sessions, streaming responses, asynchronous calls to external APIs, and multi-step tool use that can run for many seconds. Bridging those two worlds appears to require deliberate architectural choices, such as isolating the agent logic behind a defined boundary, managing conversation or task state outside the short-lived CGI process, and treating the LLM provider as one more external service with its own latency and failure characteristics.

Several of the reported lessons are broadly applicable beyond Perl. Reliable tool calling generally depends on strict schemas and validation, because a model can return plausible-looking but malformed arguments that will break downstream code if passed through unchecked. Context management matters because feeding too much or poorly structured information degrades both cost and answer quality, while feeding too little starves the agent of what it needs. Error handling is central because model outputs are probabilistic, so the harness has to anticipate incorrect formats, hallucinated fields, timeouts, and partial results, and decide when to retry, when to fall back, and when to surface an error to the user. These concerns are less about prompt wording and more about defensive software engineering, which is likely why an experienced developer of a legacy system found the transition tractable despite the unusual stack.

The account fits alongside a wider industry movement toward agent frameworks and standardized tooling. Libraries and orchestration layers such as LangChain, LlamaIndex, and the various vendor agent SDKs exist largely to provide reusable harness components, and the Model Context Protocol, introduced by Anthropic and since adopted more widely, is an attempt to standardize how models connect to external tools and data sources. The Zenn category placement under local LLM also hints at a related theme: teams increasingly weigh whether to call a hosted API or run a smaller model locally, a decision that changes the harness around latency, privacy, and cost, even when the surrounding control logic stays similar. The core argument is that these frameworks succeed or fail based on how well they handle the unglamorous plumbing, not on which model they wrap.

For readers maintaining older systems, the takeaway appears to be encouraging. It suggests that integrating AI does not necessarily require rewriting a working application in a modern language, and that conventional software discipline — clear interfaces, input validation, state management, and robust error handling — transfers directly to LLM work. The piece stops short of claiming that model choice is irrelevant; capability, context window, and cost still shape what is possible. Its more measured position is that once a sufficiently capable model is available, the remaining and often larger challenge is engineering the system around it. That perspective is a useful corrective for teams tempted to treat model selection as the whole project rather than as one component within it.