Перейти к содержимому
Оригинал
Paper Compute · Engineering Blog· bekahhw·· 20.07.2026Оценка ИИ62

该被裁掉的是智能体工作流,不是工程师

Оригинальный заголовок: The Coming AI Layoffs Should Be Agents, Not Engineers

Заголовок и краткое изложение на выбранном языке ожидают перевода.

Краткий обзор ИИ

作者认为企业在用 AI 缩减工程师编制前,应先按会话数据审查并关停那些失败、重复、空转或无人使用的智能体工作流。他给出一份审查清单,包括近 7 天和 30 天的会话数、完成与失败比例、总花费与每次成功运行的花费、工具调用次数、成本由哪些模型驱动,以及输出是否真正上线或被复用。作者同时区分可修复与应关停的工作流,并建议在关停前导出会话数据、把成功模式沉淀为带作者和版本的 Skill。

Полный текст

Полный текст на выбранном языке ожидает перевода. Пока показан оригинал.

Most of us are guilty of anthropomorphizing agents when it is useful for a demo. But the flip side is also often true: companies dehumanize employees when it is useful for a budget.

We introduce agents as never sleeping teammates. We give them a name, an avatar, and sometimes even a launch announcement. And if the experiment underperforms, the cost gets folded into “AI transformation.” The human team is then asked to justify its existence against the theoretical productivity the agent was supposed to create.

But I think that accounting is backward.

An agent workflow is software with variable inference cost. It should have an owner, a purpose, a success condition, and an operating history. If it can’t show what it produces, it isn’t a digital employee.

Why are we not reviewing deployed workflows and removing the ones that don’t earn their cost before we start cutting engineers? The easiest spreadsheet answer will be to say AI lets the company operate with fewer engineers. But that answer should not survive after we look at the session data.

Before cutting the humans who understand the systems, we should terminate the agent workflows that are failing, duplicating work, looping, or producing output nobody needs. The coming AI layoffs should be agents, not engineers.

Give the agents a performance review

For each recurring workflow, ask:

  • How many sessions did it run in the last seven and 30 days?
  • How many completed, failed, or were abandoned?
  • What was the total spend and spend per successful run?
  • How much agent time and how many tool calls did success require?
  • Which models drove the cost?
  • Are the longest sessions genuine deep work or repeated failure?
  • Did the output ship, inform a decision, or become reusable knowledge?

paper console already captures the raw material for this review: session status, cost, tokens, duration, tool calls, model mix, success rate, and recent time windows. Suggestions flag cost outliers and spend on unfinished runs. The session list makes running work visible instead of waiting for it to appear on an invoice.

Status

Name

Model

User

Turns

Cost

Last active

Running

wire outcome detector into cursor cache

~/code/papercomputeco/console

Claude Fable 5+2brian(You)42$18.4012m ago
Completed

fix flaky export-sessions test

~/code/papercomputeco/tapes

Claude Sonnet 5maya11$2.101h ago
Completed

migrate span search to direct reads

~/code/papercomputeco/tapes

Claude Opus 4.8+1brian(You)67$31.753h ago
Completed

scaffold billing exporter cron

~/code/papercomputeco/infra

GPT-5.2 Codex+1devon24$6.885h ago
Failed

triage grove sync failure

~/code/papercomputeco/paper-forest

Claude Haiku 4.5maya8$1.04yesterday
Live demo — hover a model chip with a +n badge for the cost breakdown

We’re not ranking engineers here. We’re reviewing automated systems.

I want that distinction to be explicit. A failed agent run might show a broken tool, missing context, or an unreasonable task. Those are conditions the organization should fix, not evidence that the person supervising the agent is unproductive.

Some agents need training. Some need severance.

Not every weak workflow should be deleted immediately.

A repeated failure may point to a missing skill. A long setup phase may be compressible into a reusable procedure. A high-cost model may be doing work a cheaper model can complete. A brittle tool integration might need repair. A task might need a clearer definition of done.

Those workflows deserve intervention and another measured attempt.

Others should be shut down:

  • The background agent whose output nobody reviews.
  • The automated report that reproduces data already available elsewhere.
  • The code-review bot that generates comments developers habitually dismiss.
  • The retry loop that treats an unavailable permission as a reasoning problem.
  • The agent launched because leadership wanted an “AI use case,” not because a user needed the result.

Deleting these workflows is not anti-AI. It is what mature adoption looks like.

No company proves its cloud sophistication by preserving every container it has ever started. Agent count shouldn’t be the next vanity metric either.

Preserve the institutional knowledge before you cut

When a workflow is retired, its history shouldn’t disappear.

Export the session data. Preserve representative failures. If the agent discovered a procedure worth keeping, generate a skill from the successful sessions and publish it to the team library with an author, source links, and a version.

The workflow may not deserve to run continuously, but the knowledge it produces may still save the next engineer hours.

This is one reason session-level records matter more than aggregate ROI decks. They allow a company to separate the disposable automation from the durable learning.

Humans are not the rounding error

Engineers do more than produce code. They decide which problems matter, negotiate constraints, recognize when requirements are incoherent, carry historical context, review risk, and take responsibility when the system fails.

Agent sessions depend on that environment even when the dependence is hidden behind a prompt.

Cutting engineers because agent spend rose is especially perverse. It removes the people most capable of diagnosing why the agents are expensive and whether their output is safe.

The right cost question is, “Which work should exist, which parts should be automated, and what evidence shows the automation is helping?”

If leadership can’t answer that at the session level, it’s not ready to answer it at the headcount level.

Terminate your zombie workflows. Retrain the fixable ones. Turn the successful patterns into shared skills. Keep the humans who can tell the difference.

Those are the layoffs an AI-native company should make first.

Источник: Paper Compute · Engineering Blog · papercompute.com