Claude Engineering Lead: Developers Underutilize AI by Acting as Manual Conveyor Belts

Claude engineering lead Felix Rieseberg argues developers waste AI potential by manually shuttling tasks between prompts instead of designing closed-loop workflows where agents access full context, tools, and validation loops to independently complete complex engineering tasks.

macrozheng
macrozheng
macrozheng
Claude Engineering Lead: Developers Underutilize AI by Acting as Manual Conveyor Belts

The Gap Between Model Capability and Usage

Felix Rieseberg, former engineering lead for Claude.ai, Cowork, and Claude Code Desktop, observes a wide gap between what modern models can do and how developers actually use them. In an interview with Silicon Valley Girl, he explains that many developers have integrated Claude Code into daily work but still hover over every step — copying crash logs to Claude, moving fixes to another session for review, and manually stitching together outputs. Rieseberg calls this the "Claude conveyor belt" : the model does the work, but the developer remains stuck in mechanical coordination.

Felix Rieseberg: If we only ask AI to "summarize this email," we haven't truly used the new generation's intelligence.
Felix Rieseberg: I'm just Claude's conveyor belt.
Felix Rieseberg: Put the final result you want directly as the task for the model.

Models can now read repositories, call tools, and sustain multi-step problem solving, yet developers still issue one small instruction at a time — a workflow inherited from early chatbots that leaves humans doing the most repetitive part.

A Crash Log Case Study: From Manual Handoff to Autonomous Triage

Rieseberg describes his own experience 18 months ago: he would fetch a single crash record from the system, paste it to Claude with "please fix this," then repeat for the next record. He realized he was merely transporting data between systems.

Felix Rieseberg: I'd go check crash logs, pick one, bring it to Claude, say "fix this issue." I quickly realized I was just Claude's conveyor belt.

He changed the workflow: instead of feeding one record at a time, he gave Claude access to the entire crash database and let it decide which issues were worth fixing and which could be ignored.

Felix Rieseberg: Claude should access all crash data and judge for itself which need fixing and which don't.

This shift requires upfront investment — data access, tool permissions, test environments, stop conditions, and result logging — but eliminates recurring manual distribution.

Role Prompts Are Cosmetic, Not Functional

Early prompt tutorials loved role assignments: "You are a world-class engineer" or "You are a senior data scientist." Rieseberg now avoids these.

Felix Rieseberg: I never tell Claude: "You are an excellent X expert."

The problem isn't politeness. Asking a model to play an expert yields professional vocabulary and tone, not necessarily expert problem-solving methods.

Felix Rieseberg: We need the techniques, tools, and knowledge professionals actually use, not just the vocabulary that sounds professional.

In a code task, "You are a senior backend engineer, optimize this query" lacks database scale, slow-query logs, latency targets, index constraints, and rollback requirements. Replacing that with "Read execution plans and monitoring data, confirm P95 latency sources; allow new indexes, don't change API response; provide load-test results and rollback SQL" gives Claude the actual materials a professional needs.

One Session Cannot Validate Itself

Handing off larger tasks raises the question: what if Claude makes mistakes? Rieseberg's answer goes beyond "human review." He splits generation, attack, and adjudication across separate sessions.

One session produces a solution.

Multiple sessions hunt for factual errors, missing conditions, and counterexamples.

A separate "judge" session decides whether criticisms are valid.

Verified feedback loops back to the original session for revision.

Felix Rieseberg: These sessions have only one task: attack this result, prove where it's wrong.
Felix Rieseberg: I rarely let the current session evaluate its own output.

Multiple Claude instances aren't enough — they may share blind spots or be misled by the same bad context. Rieseberg prioritizes hard external evidence (test results, monitoring data, compiler output) over model-to-model critique.

Felix Rieseberg: I prefer to find hard external evidence to judge whether a result is valid or invalid.

Parallel Run: A Safe Migration Path

When a host noted that all agent outputs still funnel through her, creating a bottleneck, Rieseberg didn't suggest immediate handover. Instead:

Felix Rieseberg: Run the human process and Claude in parallel for a while.

Developers continue reviewing documents, code changes, or customer calls while Claude independently provides feedback. After several rounds, compare agreements and disagreements, then codify recurring human judgments into rules.

Felix Rieseberg: See what feedback Claude gives, where it differs from humans, where it agrees.

Teams can feed agents historical issues in a non-production environment, compare root-cause identification, change scope, and test coverage, then decide whether to move from advisory mode to auto-commit. Permissions should be tiered so agents get verified action ranges, not unlimited access.

Engineer Value Shifts from Memorization to System Integration

As Claude writes code, reads tools, and composes systems, the criteria for evaluating software engineers change. Rieseberg describes an identity crisis: is value still in memorizing every React API? His answer is clear — the value of remembering specific interfaces is declining.

Felix Rieseberg: I've always evaluated engineers by the actual impact they produce.
Felix Rieseberg: What still has value is combining different systems in interesting ways.

A beautiful implementation that delivers no user benefit has limited value; engineers should measure work by final impact. The idea that "soon we'll only need to write prompts" is wrong. Wiring payment, inventory, message queues, and risk-control systems still requires understanding data flow, failure propagation, and permission boundaries. AI lowers implementation cost but amplifies the impact of integration errors.

For new developers, Rieseberg's advice is simple: build real projects.

Felix Rieseberg: Go build something real, prove you can finish it.

A portfolio shouldn't be just a polished demo. The ability to find real needs, communicate with users, scope agent permissions, verify results, and deliver stable functionality demonstrates whether someone can actually do software engineering.

Closing: Remove Yourself from the Conveyor Belt

Rieseberg doesn't ask developers to exit the workflow. He wants to replace the judgment-free, purely mechanical handoffs. Engineers still own goal selection, permission boundaries, feedback-loop design, and release decisions. Agents handle material reading, tool invocation, task execution, and massive repetitive checks. If humans still copy-paste between them, the chain stays slow no matter how fast the AI.

Teams can start with one high-frequency, rollback-safe maintenance task: prepare historical data, tool entry points, and acceptance criteria; run Claude alongside the human process; compare results; add tests and logging; once stable, remove the manual handoff. Developers don't need to hand over the keyboard entirely — just step off the conveyor belt first.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

AI agentsprompt engineeringsoftware developmentworkflow automationdeveloper productivityAI-assisted codingClaudeagent workflows
macrozheng
Written by

macrozheng

Dedicated to Java tech sharing and dissecting top open-source projects. Topics include Spring Boot, Spring Cloud, Docker, Kubernetes and more. Author’s GitHub project “mall” has 50K+ stars.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.