From personalmagic to anengineeringprocess

You cannot freely experiment with agentic pipelines

A developer receives a specific subscription, not a company compute budget. They therefore explore the best way to fit a task into the tool they were given—not the best way to solve it.

Trying Claude instead of Codex means requesting another subscription, waiting for approval, and explaining why it is needed. If the experiment fails, switching back is just as awkward. Even within one subscription, the quota must be saved for current work: today’s task still has to be finished, and the search for a better process competes with it for the same tokens.

The last option may be expensive in compute yet cheap in human attention: the task is completed in one shot, and the developer spends fifteen minutes accepting the result. But this hypothesis cannot be tested within one personal quota.

A personal quota distorts the selection criterion: instead of searching for the most effective approach, the developer tries not to exhaust the available limit. They end up attached to the first accessible process and improve it locally without testing fundamentally different alternatives.

Engineering processes cannot be compared fairly

The final result of a task is visible. The way it was produced is not.

One developer says they complete tasks in one shot. Another replies that their tasks are inherently harder, cannot be completed in one shot, and the agent merely adds briefing, waiting, and corrections—making the work longer. Neither claim can be tested: people solve different tasks, in different environments, with different amounts of manual finishing. There is no shared benchmark set.

Even the subscription price explains nothing. Someone on a $20 plan may have built a highly efficient pipeline—or may simply write half the code by hand, consuming expensive human time. Someone on a $200 plan may have achieved high autonomy—or may spend the quota on personal projects and a cascade of ten checks that does not improve the result.

The true cost of an accepted result cannot be determined

The cost of an accepted result has two components: agent expenses and the time during which a developer actively contributed their expertise.

If a task was assigned to a developer for six hours, that no longer means six hours of their work. The agent may have spent five hours implementing it while the person spent ten minutes clarifying the brief and another twenty checking the result. The cost calculation should include the agent’s work and those thirty minutes of expert involvement; the rest was waiting.

A result produced by a cheap model may ultimately be expensive if it requires reruns, micromanagement, manual fixes, and several review cycles. Conversely, an expensive model may cost less if its one-shot result is accepted after a quick check. The visible subscription price is not the cost of the result.

Token usage or a share of the subscription must be counted, while only the developer’s active involvement should be recorded separately: briefing, expert decisions, rejections, review, and manual corrections. Neither the task’s elapsed time nor the time spent waiting for the agent can replace this calculation.

Compute capacity is fragmented across people

The company simultaneously has paid, unused capacity and tasks waiting for someone else’s quota to reset.

A personal subscription is often a bundle of mismatched capabilities. A programmer uses Codex but barely touches the powerful web model or image generation. An artist needs image generation but not a coding agent. One person hits a weekly limit while another uses less than half of the capacity the company paid for.

A centralized pool would change the unit of planning itself: compute would be assigned to a task for as long as needed. Running a benchmark set on Kimi once a week would not require a monthly subscription for a particular employee. The team could see its total shortage and idle capacity, then buy resources for the actual workload.

Parallelism hits the local runtime ceiling

While agents work without human involvement, a developer could run several independent tasks. In practice, the limit is set by their computer: it can usually sustain only one or two heavy sessions.

Every parallel task needs a separate working copy or worktree, its own branch, and isolated project state. Multiple Unity or editor instances quickly consume RAM and CPU. Builds, tests, and automated QA compete for the same resources. Caches, dependencies, screenshots, and artifacts multiply on disk.

Even when an agent needs no attention, the person must monitor local processes, switch between windows, and wait through heavy compilation. A check takes only a few minutes with long pauses between them, yet those pauses cannot be filled with other runs: the laptop is already occupied.

The issue tracker no longer reflects a task’s lifecycle

The status “task assigned to developer” now conceals an entire production pipeline.

A lead can no longer understand the person’s true workload. Are they busy and not to be interrupted—or free and merely waiting for a long agent implementation that may run for five or six hours? Can they take a second task—or is the local runtime already full? Delegation is invisible, so the issue tracker cannot answer a basic management question: where is the work right now?

Developers became agent managers—without management discipline

With an agent, a programmer increasingly does not produce code but assigns work to an executor, supervises it, and accepts the result. This is delegation, not merely the use of a tool.

If AI is treated as a tool, constant hints, micromanagement, and manual finishing seem natural. If it is treated as an executor, the same actions point to weak delegation: the task was poorly framed, the executor lacks autonomy, and the pipeline demands too much attention.

Real delegation ends with reviewing and accepting the result. A manager who finishes the executor’s work every time has not built a functioning system. Yet developers rarely count rejections, interventions, and failed one-shots; they do not measure their own attention or develop the skills of briefing, supervision, and acceptance.

Management cannot assess these competencies either: Jira does not show who built an autonomous process and who spent the day micromanaging an agent. New management work has appeared, but organizationally it is treated as if it does not exist.

Actual human work is not reflected in issues

A particular Jira issue increasingly becomes a benchmark for work the developer did in advance: configuring the harness, writing a skill, selecting tools, and formalizing project conventions.

When a task is completed in one shot, the person’s role is impossible to understand. Did they merely copy the issue title—or spend weeks turning project expertise into executable instructions? If the task is not completed in one shot, a strong developer usually does not begin writing it by hand. They debug the pipeline: why the agent called one tool twenty times, why it chose the wrong prefab, or which context the skill lacked.

Meanwhile, Jira says the person “built a prefab from a mockup,” even though they may never have opened the mockup. Their actual work was improving the UI layout skill and the harness that should solve the entire class of similar tasks. The tracker records the final instance but loses the creation of the production method.

The actual executor is inaccessible to the rest of the team

The agent explored the code, wrote the implementation, and retained the task context. Yet QA, the lead, and another developer cannot ask it a question directly.

QA asks about regression risk or requests a branch rebase. The developer reads the message, copies it into the local agent session, receives an answer, and sends it back. Often they add no expertise of their own: a dedicated skill already knows how to formulate the answer for QA.

The developer becomes a manual API gateway to their own agent. Their mediation adds delay but no value. The actual executor should be a digital identity within the process, accessible to everyone who needs its context.

The harness is inaccessible to other people and teams

Even a good pipeline cannot simply be “handed over” to a game designer or a developer on another team: it changes constantly and depends on the operating system, tools, secrets, and local environment.

An agentic prototyping pipeline can be configured for a game designer once, but a week later the original harness will have evolved while its copy remains stale. The roles should be divided differently: the engineer responsible for the harness develops the agentic pipeline, while the user runs it without reproducing the entire infrastructure locally.

Isolation also gets in the way of ordinary teamwork. A client developer should not necessarily wait for a server developer to become available: they could ask the server agent to build a temporary stub and begin integration. In turn, the server programmer could ask the client agent about implementation details for supporting the server contract. Today, every agent is confined within its owner and runtime.

Access, security, and accountability are not formalized

While agentic pipelines live in personal configurations, the company cannot see the boundaries of their access or formally assign accountability.

One agent only reads a diff; another has shell access and write access to the repository, build, or deployment. Without a shared system, these differences remain local settings, while a common policy exists only in words.

Skills are not a shared, managed asset

A skill cannot be separated from its pipeline as easily as a library can be separated from an application. It depends on the runtime, model, tools, vision capabilities, launch methods, and secret storage.

A QA skill built on Linux Computer Use may be useless to a developer on Windows. Copying a folder is not enough to run it: the environment, tools, and permissions must also be reproduced. Even the same instruction may need different emphasis for different models.

A ZIP archive diverges into separate versions as soon as it is shared. A dedicated repository attached as a submodule adds synchronization work for every project participant, including those who do not need the skill locally and could not run it anyway. A plugin does not solve the mismatch between runtime environments.

Yet a skill directly affects production code while being managed worse than an ordinary library: it has no clear recommended version, owner, compatibility history, or retirement process. What must be shared, therefore, is not the instruction file but the entire executable pipeline of which that skill is a part.

A failed agent session cannot be reproduced and examined

“Agents are stupid; it did not work for me” cannot be diagnosed without the original brief, context, skill version, tools, model, execution trace, and points of manual intervention.

Previously, someone could open the code, show a flawed approach, and explain how to improve it. Now the delegation process itself must be examined. But the session history stays local, the environment changes, context becomes stale, and the next demonstration happens on a different task and proves nothing.

As a result, the team does not learn from real failures. There is no way to see precisely where the developer went wrong: framing the task poorly, providing insufficient context, choosing the wrong tool, skipping the plan, or intervening too early.

Onboarding degenerates into folklore: “install some model, configure some harness, try a prompt like this.” The old engineering culture changes, but a new one does not emerge because experience is not captured in reproducible artifacts.

Agent memory is shaped by a personal set of tasks

Each developer develops their agent on a small fragment of project history, even though the true source of experience is every task in the project.

One person completed several profiling tasks, wrote a skill, and learned the typical pitfalls. A month later, another developer receives a similar task and starts from scratch. For that person it is the first such task; for the project, it is far from the first. Millions of pieces of context exist, but they are scattered across local agents and personal histories.

A project needs shared memory, not “my memory”: successful approaches, failures, review comments, QA findings, accepted decisions, and traces of how the agent reached them. Otherwise, several smaller copies of one pipeline evolve more slowly than a shared executor learning from the whole team’s experience.