Stop Carrying Tasks to AI: Felix Rieseberg on Better Workflows

Felix Rieseberg used to find a crash report, carry it over to Claude, and ask for a fix. Then he would find another report and repeat the process. Eventually, he realized that he had become a conveyor belt for the model.

He changed the workflow. Claude would get access to the relevant crash data and work out which problems needed attention. Connecting the information and tools took effort up front, but it allowed the model to take responsibility for a more complete task.

That experience spoke to host Marina Mogilko's problem. Her team of 35 already used AI extensively, yet its output still passed through the team and ultimately through her. Production had accelerated; the person making the final decisions had become busier.

Their conversation explored how work should be redistributed as AI becomes capable of doing more of it.

Start with what should happen after the task

Rieseberg says much of his day now involves prototyping: developing ideas, asking Claude to build variations, and deciding which are worth keeping. Engineering managers once had to estimate development, maintenance, and opportunity costs before committing. More questions can now be tested with a working prototype and actual users.

Human attention remains scarce. He illustrates the imbalance with 1000 possible prototypes and someone willing to examine perhaps 1 carefully each day. The comparison describes an attention bottleneck; it is not a measured productivity result.

He looks for products that people understand quickly and that help them do something they could not do before. Adding buttons is easy. Deciding which buttons should never exist requires an understanding of the person using the product.

He distinguishes automation from augmentation. Automation saves repetitive work. Augmentation lets someone cross a barrier created by missing knowledge, technique, or tools. Taking advantage of that often requires changing the workflow itself.

A useful question is what outcome the immediate task is supposed to enable. Fixing individual crashes is a task; improving software reliability is a goal. Producing an analysis is a task; helping a team make a better decision is a goal. When the goal is specific and testable, the model has more room to choose a useful route.

Professional work depends on methods and tools

Calling a model a leading expert may simply produce more expert-sounding language. Rieseberg cares about whether it uses methods that actually work in the field.

His example is a weather query. A model that guesses the correct temperature should not automatically receive a passing grade. A model that establishes the location and consults reputable sources has a more trustworthy process, even if its answer is off by 0.5 degrees. The sources and the inspectable steps matter for repeatability.

Creative work also has a process. Rieseberg describes writer Adam Davidson asking Claude to strengthen an argument, develop the strongest counterargument, or identify points of disagreement. Those are concrete editorial operations through which taste can influence the work.

Discussing animation and 3D work, he mentions Opus 5.5 alongside the importance of professional tools such as Blender. He does not know how to use Blender himself, yet he can ask Claude to create assets for his website and judge whether the result works. That is his experience, not evidence that arbitrary creative tasks have been solved.

A more useful instruction follows from this: identify the raw materials, tools, and steps that an excellent practitioner would use, then actually use them. Professional vocabulary is only the surface. The method has to become part of execution.

Separate production from evaluation

A confident answer can still be wrong. Rieseberg's practical response is adversarial review: give another conversation the explicit job of finding faults in the work.

For a blog post, he describes launching 5 independent threads to try to disprove it. They look for incorrect facts, weak reasoning, or misunderstandings. Another independent session acts as a judge, deciding which criticisms are valid before useful feedback goes back to the author. He explains the approach in the video's discussion of adversarial review.

Criticism needs scrutiny too. A plausible objection can miss the objective or offer nothing actionable. Finding a flaw can also be easier than creating something from scratch, so the reviewer may not always need the most expensive model. The result remains task-dependent.

Rieseberg is reluctant to let a conversation grade its own work. His preference is hard external evidence. A separate Claude session provides another signal when stronger verification is unavailable.

He describes having 100% trust in one editorial checking workflow: asking Claude to find a reliable primary source for every number in a presentation. That is a statement about his confidence. The interview provides no independent test establishing 100% factual accuracy.

The distinction matters. Agreement among several sessions cannot replace source data, observed execution, or user feedback. Reviewing is useful when it exposes problems and reconnects judgment to evidence.

Retrieve data as needed and retest Skills

Rieseberg organizes work into projects but rarely starts by assigning the model a fixed persona. General-purpose models can work across disciplines; rigidly deciding that one only does research and another only understands finance may limit their use of relevant information.

An engineering manager who can only inspect code will struggle to understand customer problems. Customer conversations, usage patterns, and business results can all affect a decision. AI needs a corresponding view of the work.

That does not require loading every document into a conversation. Rieseberg provides tools with clear descriptions of the data behind them, allowing the model to retrieve what it needs. In an implementation, access should remain within the information relevant to the task and authorized for use.

The crash-report example captures the benefit. Connecting the data takes initial effort, but it reduces the recurring human work of finding, copying, and assigning individual items.

Skills also need to be revisited. His team still uses them extensively. However, detailed instructions written for an older model can sometimes make a newer model perform worse. With a clear evaluation standard, practitioners can compare results with and without a rule before deciding to retain it.

The prerequisite is an ability to distinguish good output from bad. Without that comparison, it is hard to know whether an instruction protects quality or has become a burden.

For getting started, he suggests trying real work through the desktop app's browser capabilities and observing whether the workflow is useful. A more efficient connector can come after that has been established. An observable result gives a team something to calibrate before it builds a larger system.

Turn historical feedback into a standard that can improve

Mogilko estimates that a published piece might retain 70% of Claude's output, with her changes making up the other 30%. She sees her taste in those changes. Yet the feedback is scattered across conversations and may never reach the next generation attempt.

Rieseberg proposes starting with those actual records: collect previous feedback, distill it into rules and principles, and ask the model to suggest preferences the person may hold without having stated them explicitly. Those inferred preferences still need the person's confirmation.

Repeated edits might reveal a preference for concrete examples or an unwillingness to accept numbers without sources. Standards drawn from real decisions are easier to check than a comprehensive style guide invented in advance. These examples explain the method; they are not claims from the interview about Mogilko's preferences.

Trust can develop gradually. Rieseberg recommends running human and AI reviews side by side. The person writes an assessment independently, then compares it with Claude's feedback, looking for omissions, mistaken judgments, and areas of agreement.

After several rounds, the team has better evidence about what can be delegated and what still needs review. He also points out that the same person's response to a document can differ between Monday and Friday. Judgment can be calibrated without becoming perfectly stable.

An operational implication follows: feedback has to reach later work. Otherwise, the team simply produces material for managerial review more quickly, leaving the final bottleneck with the same person.

Cheaper execution still leaves the work of understanding users

Will easier software production undermine existing products? Rieseberg expects people to keep paying for products that solve their problems well, sometimes in ways they would never have devised themselves.

He is more interested in replacing awkward software that people tolerate because they lack alternatives. Hotel desks, airports, and dental offices contain workflows that could be improved. Finding the opportunity requires observing how people work and understanding the relationships, procedures, and constraints around the software.

He assesses engineers along similar lines. Real projects, user benefit, customer communication, and useful combinations of systems matter to him. Memorizing an individual API may have become less valuable; understanding systems and applying them to actual needs still matters.

That helps explain his admiration for the internship experience of some University of Waterloo graduates he has worked with. They had already encountered different organizations and learned how to advance ideas, obtain resources, and collaborate across functions. This is his management experience, not a general ranking of degrees or universities.

His advice to younger people is concrete: build things others can actually use, encounter real business problems, and demonstrate the ability to understand a need and deliver. Technical ability becomes visible through those outcomes.

Expand the goal and find the boundary through results

Rieseberg sees a large gap between model capabilities and everyday use. He does not conclude that AI can take responsibility for every conceivable goal. An instruction as broad as making money will usually get little traction on its own. The useful level is a goal valuable enough to matter and concrete enough to advance and evaluate.

He also recounts a story about someone asking Claude to examine public NASA data and possibly finding a new planet candidate. He explicitly says the result is unconfirmed and that he is not an astrophysicist. The anecdote illustrates his interest in exploring a wider range of tasks; it does not establish a discovery.

Looking ahead, he compares current AI products with devices from the period before smartphones matured. Their form may change substantially, and today's habits may age quickly. This is his outlook, not a product timetable supported by the interview.

The working method running through the conversation is to define the goal, provide relevant information and professional tools, and test the result against independent evidence. People can gradually spend less time carrying and assigning tasks and more time on needs, tradeoffs, and feedback. How much to delegate should be decided through results that can actually be checked.

Original source: Claude Engineering Lead: “Stop Using Claude Like It’s 2024”, Silicon Valley Girl, published 2026-10-20, duration 49 minutes 23 seconds. Hosted by Marina Mogilko, with guest Felix Rieseberg.

Rieseberg's personal website lists his engineering leadership work on Claude.ai, Cowork, and Claude Code Desktop. Further reading: his essay How to be more ambitious: A tutorial for humans with models. This article synthesizes the complete English automatically generated captions, with names, products, and key terminology checked. Advertising and repeated conversational material have been omitted; personal judgments, unconfirmed anecdotes, and capability limits have been retained. It is not a verbatim transcript.