LLM codegen fails and how to stop 'em

What does it take to hand a software integration to an agent and get back changes the user actually wants? For Danilo Campos, who builds the PostHog Wizard, that question comes after enough failures that robots no longer frighten him: they have already bloodied his nose. Campos describes the Wizard as replacing two hours of integration work with eight minutes of guided setup. He reports that 15,000 people run it each month. These are his reported operating figures; the talk supplies neither a timing methodology nor a definition of the monthly counting unit.

The encouraging evidence is also unusually concrete: Campos points to two unsolicited positive posts on Bluesky and Twitter in the preceding six hours, with screenshots of the terminal interface. People are happy with code a robot put into their projects. That is also the risk. A superficially successful integration can contain invented APIs, awkward architecture or unsafe file access. The Wizard's design comes from learning how those failures happen and changing the conditions under which the agent works.

Model rot is the first failure mode. Training is a substantial capital expense, so a model's knowledge remains a snapshot while software continues changing. Campos describes snapshots that may already be six, eight, twelve or eighteen months old. That knowledge can still be useful, but a fast-moving project's current integration requirements may no longer resemble what the model learned.

An audience member suggests retrieval-augmented generation. Campos agrees that RAG is useful, but with sufficiently large context windows he favors a direct approach: put the relevant Markdown documentation into context. The Wizard offers tools that let the agent select from a menu of fresh PostHog documentation according to the integration it is performing and what it has detected in the project. This is targeted selection, followed by loading the actual instructions the agent needs.

The need became obvious when users began asking Cursor to integrate PostHog. Campos recalls agents making up keys, inventing implementation patterns and calling APIs that did not exist. PostHog had not produced those answers, but users still encountered them as a PostHog integration problem. Current context became part of supporting the product, because leaving the agent to reconstruct the integration from training data made someone else's code-generation failure the team's problem to solve.

Correct API knowledge does not guarantee sensible architecture. An agent can produce something technically workable while choosing a strange place or structure for the integration. To give it a better pattern, the Wizard team maintains Model Airplanes: small applications across frameworks and languages with PostHog already integrated. They preserve the parts of an application that demonstrate the integration without carrying an entire production system along with them.

Authentication makes the distinction clear. A Model Airplane's login can accept any password. It is not useful production authentication, but it is auth-shaped: the application still has a recognizable login path. That structure shows the agent where login events and PostHog identity instrumentation belong. The example needs to preserve the relationship between authentication and analytics, not the full machinery of credential validation.

The result is a thinner reference application that spends tokens on the integration's shape. Campos reports that this helps the agent complete the desired pattern consistently; he does not supply a measured success rate.

Even with good examples, the agent can take an unnecessarily strange path through the work. Campos imagines the support burden if the Wizard's monthly integrations each used a different approach. All might satisfy the broad request to integrate PostHog, while leaving the team unable to recognize and support what had been installed.

The Wizard limits that improvisation by sequencing the information it reveals. Giving an agent the entire destination upfront can encourage it to rush through the early work and spend its effort polishing the final task. Campos describes Claude Code making a hole through the first four tasks before overworking the fifth. The Wizard instead begins without foregrounding the PostHog integration at all.

The workflow proceeds in three stages:

1. Find business-value files. Look for login behavior, a Stripe interface or code that might signal impending churn. The first job is to identify where meaningful business activity appears in the project.
2. Plan events without editing code. Inspect those files for useful events, then save event names and descriptions in a file.
3. Introduce the integration. With the event plan established, load documentation for the relevant framework and language, then modify the application.

Campos's observation is that business behavior leaves a large, recognizable footprint in code. The discovery phase uses that footprint to decide what deserves instrumentation before the agent starts implementing it.

The next source of failure is the team maintaining the agent. Human context is limited and fragmentary: someone remembers last week's implementation but forgets a decision from last month. As tools and instructions evolve, those gaps can produce an environment in which the agent cannot follow all of its directives. The Wizard once had an MCP tool instruction that contradicted another tool's instruction. It also required a concluding tool that the agent could not find. Campos says hundreds of runs encountered that missing tool.

To surface these problems, the team added a small piece of inference at the end of every run. At the stop hook, it asks the agent: “What could we have done better to set you up for success in this run?” Campos treats this as user research in which the user happens to be a robot. The question directs attention to the agent's working conditions, including problems that may be invisible in a final completion message.

That feedback exposed several different maintenance errors:

• Unavailable tool: the agent had not been granted permission to access the tool it was instructed to use.
• Contradictory directives: different instructions demanded incompatible behavior.
• Wrong-language guidance: the agent received JavaScript instructions while working in a Python project.

These failures were actionable defects in the supplied environment. Asking about them gave the team information it otherwise would not have had.

Running an agent on someone else's machine requires trust beyond whether the generated code works. An early Wizard version read .env files before modifying them. In that editing workflow, reading supplied the information needed to write, but it also risked sending existing environment values to cloud processing and logs outside the user's control. A successful integration was not sufficient justification for that exposure.

The fix was a narrower capability boundary. The team restricted tool use and reads around environment files, then supplied a dedicated tool with only two operations: check whether a key exists, and write a new value to a key. The agent could request the configuration change without receiving the file's existing values. A JavaScript interface expressing that boundary could look like this:

export function createEnvironmentTools(localStore) {
  return {
    async hasKey({ key }) {
      return { exists: await localStore.has(key) };
    },
    async setKey({ key, value }) {
      await localStore.set(key, value);
      return { written: true };
    }
  };
}

Here localStore stays behind the tool boundary. Neither response includes an existing value or the file contents. Restricting ordinary file-reading tools is essential: the narrow interface does not help if the agent can obtain the same secrets through another tool.

The protected boundary is existing environment-file content entering inference, not a claim that all project processing stays local. Campos describes removing that content from the model's view while preserving the operations required for setup. The broader obligation remains the same: an agent must not damage a user's project or betray their trust while technically accomplishing the task it was sent to do.

These interventions change where engineering effort goes. Developers are accustomed to solving problems by writing more code, adding structure and making that structure reliable. But a new model does not automatically make yesterday's code more valuable. Campos describes code as a depreciating asset: it may already contain technical debt when it ships, even if shipping it was the right decision.

Campos characterizes the Wizard as 90% Markdown files, 8% tools for delivering and processing Markdown, and the remainder agent harness. This is his description of where the system's substance lives, rather than a repository measurement with a stated counting method. His investment thesis follows from it: better models can extract more value from the same well-written prose. Clear instructions, fresh documentation and useful examples can become more effective as the model interpreting them improves.

The metaphor is an octopus: an agent can maneuver around obstacles and squeeze into places that rigid scaffolding would not anticipate. Overconstraining that ability can remove the flexibility that makes the agent useful. The earlier safety boundaries still apply, but within them the design question becomes how to provide enough information, in the right sequence, for the agent to produce the intended result. Breadcrumbs constrain the progression of work while leaving room to solve the local problem.

The first audience question asks how the Model Airplanes are actually provided to the model. Campos explains that a context service generates skill files. In the implementation he describes, the service flattens the Model Airplanes into a single Markdown file and includes a reference to it in the skill. The full example remains accessible for the agent to search with grep or inspect in other ways. Referencing the example gives the agent access to its contents without requiring every detail to be reproduced in the top-level instructions.

A follow-up asks why use a Model Airplane rather than a regular skill. They are not competing mechanisms: the example is supplemental content inside the skill. Documentation supplies prose explaining the integration, while the Model Airplane supplies code showing its successful shape. The skill brings both forms of guidance into the agent's working environment.

The final implementation question concerns the runtime: is the Wizard built on a coding agent or running independently? Campos says it wraps the Claude Agent SDK in a CLI. Users launch it with a single command and log into PostHog, which provides inference at no charge to them. An LLM gateway lets PostHog cover the token costs on their behalf.

That packaging introduced its own failure mode. Campos recalls Claude Code storing authentication information in unexpected locations, which broke the experience for some users. He describes this way of delivering an agent as a service as still being in its early days. Even after the context, examples and tool boundaries are in place, the service must make authentication and inference access work reliably on the user's machine.