Claude engineering lead Felix on how to use Claude: fewer role-based Agents, use adversarial review to constrain output

Claude engineering lead: stop using Claude the 2024 way; stop being a mouthpiece, give it the full data and tools, use adversarial review, and stop piling on role Agents

@felixrieseberg, in an interview with @siliconvalleymm, expressed the same views as in his article: Felix barely writes code anymore. The core is not "building more role Agents" but handing crash data, business tools, and a computer to the model, constraining output with adversarial review and external evidence, and upgrading from "you being the conveyor belt" to "the model picking its own problems and using its own tools."

Youtube video: https://t.co/BfqdAb3drL

Felix's current day-to-day work · The team built Claude Cowork in about a week and a half; he is now the Claude engineering lead and calls himself "Claude's conveyor belt"; in the past he would pick one crash and toss it to the model to fix; the right approach is to let the model directly touch all the crash data and decide for itself what to fix and what not to fix. · In the morning there is an agent briefing; day-to-day is mostly prototyping: sleep on an idea for a few days to weigh it → have Claude make multiple versions → humans do the critique. You can make a thousand prototypes, but a person's attention can only seriously look at about one a day; the signal of a good product is that a few people "light up" as soon as they try it and can do things they couldn't do before, and buttons should be fewer rather than more.

Automation vs augmentation · Automation: cutting out annoying, expensive, time-consuming work, where the economic value is clearest right now. · He cares more about augmentation: supplementing skills/methods/knowledge so people can do things they couldn't do before. What really creates the gap is often changing the workflow and defining what good looks like, not just the tool itself.

How to judge "good" in knowledge work · Reporting the weather: guessing the temperature blindly and happening to be right = failing; being half a degree off but with reliable location, sources, and reasoning = better. Process and verifiability take priority over "looking right." · Writing: don't say "Claude, write this paragraph well"; learn the processes of excellent authors, amplify the argument, find the strongest rebuttals, and follow professional steps. Many creators emphasize processes honed through hard practice, not mystical feel. · Motion/3D: Unlock is often "using the same tools as professionals" (e.g., having Claude use Blender), not just shouting "act like a professional animator."

Preventing hallucinations: adversarial review + Judge · A practical trick: for the same output (article, PPT), open multiple threads dedicated to "proving you wrong"—facts, logic, misunderstandings; then open another thread to act as judge and filter which criticisms hold; feedback that holds can go back to the original conversation, and the original conversation can also judge whether to adopt it. · Finding faults is often easier than creating, and the adversarial side can sometimes use a slightly weaker model. · Two types of tasks: when you have no idea what good or bad looks like → throw more tokens/more rounds of AI at it; when you can act as the "client" and judge the feel (e.g., he doesn't understand Blender but can judge whether a website's 3D looks good) → the feel is enough.

How to arrange Agents, Skills, and data · A somewhat provocative view: the industry has over-rotated on "Agent role-playing"; models are strong generalists, and after DeepMind's custom math silver medal, generalist models soon took gold. Rigidly forcing "you are a data scientist" often limits how it can be used; for most of his tasks he sets no persona. · Rather than slicing off a small piece of data for each agent, give a panoramic business view + well-documented tools (if business data is needed, call the business tool; no need to pour the whole database into context). Now that tool calling has become stronger, he no longer prioritizes deciding "which piece of data should go to whom." · Skills: both the official guidance and his personal advice say use them cautiously; their half-life is extremely short, and sometimes deleting a skill produces better output; the rules of the previous generation of models often constrain the new model. · Put yourself in the "model's experience": you would want raw data, a computer, permission to install software, and fewer others drawing conclusions for you first, rather than only hearing people relay things.

What he doesn't trust · When asked "what do you still not trust agents to do," he changed his answer: he trusts the same conversation's self-evaluation even less; having the current conversation be the judge of its own work is still very unreliable. Try to find external signals (another conversation, real metrics). · For things like fact-checking: he dares to trust a single thread (finding primary sources, verifying source quality). · Feedback loop: give tool permissions in Slack/GitHub etc., let the model gather feedback itself → compress it into principles → then dig into principles of "what you think you believe but actually may not," for use in later reviews; you can also have humans and the model write feedback side by side for several rounds and then align.

Startups and software · One-person/two-person teams building big companies is more feasible, but the secret hasn't changed: empathy—whether it is truly valuable to users, the scenario, and the people who pay. · What will disappear is "barely adequate, no alternative" bad software; for truly good products, most people still won't come up with them on their own. · He likes to go to hotel front desks and similar places to look at the machines used in the real economy: many are still clunky old systems, and vertical cleanup is an opportunity; old jokes like dentist office software—relationships and distribution are still hard. · Capability overhang: top-tier intelligence vs most people still asking "what is the capital of France"; Dario's "genius data center" needs to land in usable form by rethinking needs and possibilities. At the individual level: do less "help me polish this email" and more handing the model the result you truly want, until you hit the current ceiling—that's how you get the dividends of the next generation of models.

For engineers and the next generation · An engineer's value is judged by whether users are willing to pay for the result, not by memorizing the entire React API. Advice: build a portfolio of real work you can touch, and prove empathy and the ability to integrate multiple systems; memorizing a single API depreciates, while stitching multiple systems together appreciates. · When hiring, look at what someone has done and whether they were on a winning team, more than at school degrees. · For his daughter (still young): understand early how business runs, how to collaborate, and how to find value; he admires the Waterloo-style multiple internships—knowing how to push an idea, ask for resources, and get through legal is often faster to pick up than pure CS theory. · Five years from now: it will be hard to intuitively keep up with the intelligence index; what he can say with more confidence is that today's AI products are probably still at the feature-phone stage before smartphones, and their form will change drastically. His own advice may also need a revision in ten weeks.