---
title: "AI is eating the AI engineering loop"
date: 2026/06/09
description: The full AI engineering loop can technically be automated now. But that doesn't mean it should. Here is what we think you should hand to agents, and what you should keep doing yourself.
tag: engineering
author: Lotte
highlight: true
---

AI agents can run almost every step of the [AI engineering loop](#ai-engineering-loop) on their own. The tools are in place, the context is available, and the loop can close without a human touching it.

That is also where the industry is heading, often referred to as "continual learning":

We think this is directionally right. We also think handing over the whole loop is a mistake. Automate past the point where you can still vouch for the output, and you'll find yourself shipping _agent slop_.

## What do we mean by AI engineering loop? [#ai-engineering-loop]

The AI engineering loop is how we describe the process of continuously improving AI agents, based on what we have seen across the industry and across our user base. We wrote about it extensively in our [academy](/academy/ai-engineering-loop).

The AI Engineering Loop:

- [Trace](/academy/tracing): traces, sessions, agents, prompts
- [Monitor](/academy/monitoring): dashboards, LLM-as-judge, feedback
- [Build datasets](/academy/datasets): datasets, features-as-tests
- [Experiment](/academy/experiments): prompts, models, code variants
- [Evaluate](/academy/evaluate): judges, custom evals, annotation

Part of the loop runs on live activity. Traces flow in from production, and monitoring surfaces anything worth a closer look. Part of monitoring is reading traces yourself. This gives you direct insight into how the system behaves and is one of the more valuable steps in the whole process.

The rest happens in development, before shipping a change. You build a dataset that approximates real production usage, so you can test changes systematically and hill-climb on quality. If a change performs better, you deploy it to production. **This is a continuous process**.

## You could automate all of it

Walk through the steps and none of them technically need a human. Instrumenting an app is something agents do fully autonomously now. For every other step, platforms usually have an [API](/docs/api-and-data-platform/features/public-api) or a [CLI](/docs/api-and-data-platform/features/cli) an agent can call to do the work.

| Job                                                              | Tools exist to automate |
| ---------------------------------------------------------------- | :---------------------: |
| Read traces, surface all anomalies, and label them               |           ✅            |
| Build datasets from production errors and synthetic cases        |           ✅            |
| Run experiments and derive new ideas to hill-climb against evals |           ✅            |
| Test a newly released model and open a PR with the adapted agent |           ✅            |
| ...                                                              |           ...           |

So if every step can be automated, the loop can close on its own. But while we can technically automate the entire process, that does not mean we should. Removing yourself from the loop comes at a cost, and that cost has a name: **agent slop**.

## But you'd be producing _agent slop_

> **Agent slop**: low-quality AI agents, mass produced by other AI agents. Often the result of agents optimizing against imperfect evals and datasets.

You want your agent to behave the way you decided is right, with the nuance you care about. That nuance lives in your head and is based on your continuously evolving opinion. Automate the entire loop and the agent optimizes toward a target that is not complete, and becomes stale over time.

<Frame fullWidth>
  ![Without course correction along the way, the loop drifts off the path and never reaches the optimal destination](/images/blog/2026-06-09-ai-is-eating-ai-engineering/agent-slop.png)
</Frame>

This produces agents that behave sort of how you want, but people can feel the quality bar is lacking. Your users deserve better than that, and it's your responsibility to hold the bar high.

A practical example of an incomplete target function is when we ran [autoresearch on the Langfuse skill](/blog/2026-03-24-optimizing-ai-skill-with-autoresearch). An agent optimizes against the evaluator's gradient, so misspecify the target and it will move in the wrong direction very quickly.

## What to automate, and what to keep manual

We do see a future where most of this loop runs on its own. But you need to make **deliberate choices on what an agent can own, and keep yourself involved where your judgment is the product**.

<Frame fullWidth>
  ![Manual work is high effort, automating everything sacrifices quality; the ideal balance shifts your effort toward judgment for higher-leverage, higher-quality work](/images/blog/2026-06-09-ai-is-eating-ai-engineering/automate-manual-quadrant-v2.png)
</Frame>

If you do this well, your quality should improve, because you can focus on the high-leverage work you would otherwise not have time for. But if you overdo it, you risk producing _agent slop_.

### Keep looking at your traces manually

AI applications produce behavior you cannot predict in advance. If you only read the traces an agent or previously set up evaluators flagged for you, you only ever see the slice it was already told to look at. To catch what would otherwise slip through, sample your traces regularly and read them yourself. **This is also where your opinion gets formed**.

While forming your opinion, you'll leave feedback on these traces that the agent can then pick up. These corrections steer the agent back towards what you consider good.

<Frame fullWidth>
  ![The AI engineering loop annotated with the steps where you should keep looking at traces manually](/images/blog/2026-06-09-ai-is-eating-ai-engineering/manual-steps-loop-v2.png)
</Frame>

One thing worth mentioning is the value of **implicit user signals**. It's technically automated, but the input stays human. It's a great way to surface traces worth a closer look, that you didn't tell the system to look at.

### Automate the rest

Everything else can be handed to an agent, **as long as it has the context to do it well**.

What your app should do, what counts as a good answer, which behaviors are unacceptable: only you can teach the agent that. You give that context in concrete forms: the feedback you leave on traces as you monitor, and the direction you set for what to evaluate. From there, you can build the datasets and evaluators together with the agent.

<table>
  <thead>
    <tr>
      <th>Step</th>
      <th>Manual</th>
      <th>Automated</th>
      <th style={{
        backgroundColor:
          "color-mix(in oklab, var(--surface-cta-primary) 22%, transparent)",
      }}>Ideal balance</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
        <strong>Trace</strong>
      </td>
      <td>-</td>
      <td>One-time setup; traces flow in automatically.</td>
      <td style={{
        backgroundColor:
          "color-mix(in oklab, var(--surface-cta-primary) 22%, transparent)",
      }}>Automated.</td>
    </tr>
    <tr>
      <td>
        <strong>Monitor</strong>
      </td>
      <td>You read every trace by hand. Insightful but unsustainable.</td>
      <td>Agent flags known rules and obvious mistakes; quality plateaus early.</td>
      <td style={{
        backgroundColor:
          "color-mix(in oklab, var(--surface-cta-primary) 22%, transparent)",
      }}>
        Automate it, but keep sampling traces to catch unanticipated behavior.
      </td>
    </tr>
    <tr>
      <td>
        <strong>Build datasets</strong>
      </td>
      <td>You hand-pick every example. Representative but slow to maintain.</td>
      <td>
        Agent builds datasets from its own labels; they plateau with your
        monitoring.
      </td>
      <td style={{
        backgroundColor:
          "color-mix(in oklab, var(--surface-cta-primary) 22%, transparent)",
      }}>
        Your monitoring feedback keeps the dataset diverse and representative.
      </td>
    </tr>
    <tr>
      <td>
        <strong>Experiment</strong>
      </td>
      <td>You test variants by hand. Thorough but limited in reach.</td>
      <td>Agent generates and runs variants to push the metrics.</td>
      <td style={{
        backgroundColor:
          "color-mix(in oklab, var(--surface-cta-primary) 22%, transparent)",
      }}>Automate by default; step in ad-hoc.</td>
    </tr>
    <tr>
      <td>
        <strong>Evaluate</strong>
      </td>
      <td>You grade runs and build evaluators by hand. Accurate but tedious.</td>
      <td>Evaluators self-update; quality plateaus once the obvious is fixed.</td>
      <td style={{
        backgroundColor:
          "color-mix(in oklab, var(--surface-cta-primary) 22%, transparent)",
      }}>
        Review a sample and let the agent calibrate from your feedback.
      </td>
    </tr>
  </tbody>
</table>

As your application matures, this context becomes more and more about opinionated nuances that only you can capture. **All of this comes from you looking at your traces**, and the sharper the context, the more of the loop you can safely hand off.

Automation only pays off once you have a good enough understanding of what to evaluate continuously, and what representative datasets and metrics look like for that. [Error analysis](/academy/monitoring/error-analysis) is a good way to build that understanding before you hand off.

## Your taste is the edge

The mechanical work of the loop is going to agents, and that is good news: it frees you for the part that makes your agent yours. With the labor becoming the same for everyone, what sets your agent apart is your sense of what good looks like, and the care you put into teaching it.

<!-- agent-instructions -->

---

## Agent Instructions

This page is part of the [Langfuse](https://langfuse.com) documentation, published as plain Markdown for AI agents. Every page is available as Markdown by appending `.md` to its URL, or by sending an `Accept: text/markdown` header. This page: `https://langfuse.com/blog/2026-06-09-ai-is-eating-ai-engineering.md`.

### Querying these docs

If the answer is not on this page, query the documentation instead of guessing:

- **Semantic search** across all Langfuse docs, returning an answer with the relevant pages and excerpts. Ask a specific, self-contained question:

  ```bash
  curl -sG "https://langfuse.com/api/search-docs" --data-urlencode "query=How do I trace a LangGraph agent?"
  ```

- **Index of every page**: <https://langfuse.com/llms.txt>, with per-section indexes [llms-docs.txt](https://langfuse.com/llms-docs.txt), [llms-integrations.txt](https://langfuse.com/llms-integrations.txt), and [llms-self-hosting.txt](https://langfuse.com/llms-self-hosting.txt).

### Before writing Langfuse code

- **Install the [Langfuse Agent Skill](https://langfuse.com/docs/api-and-data-platform/features/agent-skill).** It encodes Langfuse's own best practices for instrumentation, prompt management, and evaluation, and materially improves results.
- **Read [What does a good trace look like?](https://langfuse.com/docs/observability/best-practices.md)** before instrumenting an application.
- **Verify endpoints, parameters, and response fields** against the [API reference](https://api.reference.langfuse.com) instead of inferring them from code examples.
- **Use the [Langfuse CLI](https://langfuse.com/docs/api-and-data-platform/features/cli)** (`npx langfuse-cli api <resource> <action>`) to read or write traces, prompts, datasets, and scores from the terminal.

Found an error in these docs? Please open an issue at <https://github.com/langfuse/langfuse-docs/issues>.