Felix, Head of Claude Engineering: Stop using Claude like you did in 2024.
In a recent in-depth interview, Felix Rieseberg, Head of Engineering at Anthropic Claude, shared his current way of working and why most people are still using Claude the way they did in 2024. His team spent about a week and a half building Claude Cowork, and he barely writes code now, calling himself "just a conveyor belt for Claude". The core viewpoints can be summarized as: If you only ask Claude to summarize emails and polish texts, you are not really benefiting from the new intelligence. What is truly valuable is to redesign the workflow, let AI access raw data and tools, use it to make prototypes, conduct adversarial reviews, and do things you could not do before; and the most important abilities of human beings are still empathy, taste and judgment.
The following is Felix's full sharing:
I. I No Longer Write Code, I Am Just a Conveyor Belt for Claude
I don't write code anymore. Most of the time, I am working on prototype design: we try a lot of ideas, leave them for two nights to judge whether they are good or bad ideas, then tell Claude to generate all variants, and then critically analyze which ideas are good and which are bad.
A year and a half ago, I was still doing this: finding a crash, picking it up, bringing it to Claude and saying "please fix this". I soon realized that I was just a conveyor belt for Claude. The correct approach is not that I carry each crash to Claude one by one, but to let Claude have access to all crash data and judge by itself what needs to be fixed and what does not. The upfront setup cost is higher, but once it is built, it will open many doors for you, and this is the real hard value brought by AI.
II. An Agent Consists of Five Parts: Model, Harness, Sandbox, Knowledge and Tools
An agent is made up of five elements:
First, the large language model. It is responsible for perception, reasoning, planning and decision-making. Second, the harness. It coordinates memory, including active memory, working memory and long-term memory, and activates tools. Third, the sandbox. The harness runs in a secure runtime, isolated from the rest of the system. Fourth, knowledge. The agent needs to access company data to turn structured and unstructured data into a knowledge base. Fifth, tools. The agent must use tools to do actual work.
The model, harness, sandbox, knowledge and tools together form an agent.
III. No Role-playing, Professional Tools and Processes Are Needed
I never say to Claude "you are an excellent engineer". This kind of "act like" was very popular in 2024, but most models today still have a problem: when you ask it to "act like a good accountant", it will do a little bit of role-playing. Role-playing is not what we want.
What we want are the technologies, tools and knowledge that professionals will use, not just vocabulary. I don't need Claude to sound like something, nor do I need it to put on a costume. I even want it to talk to me like it is talking to a five-year-old child, but I want it to use all the top tools in this field.
So I often prompt like this: "Tell me what tools the top people in this field will use, then you use the same tools to do it." The key is not to let it play a role, but to let it adopt a professional process.
IV. Adversarial Review: Let Multiple Claude Attack One Claude
How to avoid AI confidently giving you wrong answers? I have a very practical answer: adversarial review.
Give one Claude a task, then send out ten other Claude, whose only task is to attack this output and prove why it is wrong. This is the same concept as red team drills and short selling. Usually, it is easier to find defects than to create new things, just like judging whether a new mobile phone is good or not is much easier than designing a new mobile phone from scratch. So you can lower the intelligence level by one gear and still get very good review results.
The specific practice: I use Claude Projects, tell Claude "open five threads, and the task of each thread is to prove that this blog post is wrong, my way of thinking is wrong, the facts are wrong, and I have misunderstood something". They work with the goal of "prove me wrong".
Then how to deal with the output? Use another Claude as a judge. Its job is to verify and confirm which criticisms are valid and which are invalid. Valid feedback goes back to the original Claude that did the work, and it can also decide whether to adopt it. Sometimes the feedback sounds reasonable, but misses the point, is not operable or useless - this usually means that my output is already quite good.
I rarely let the current session judge itself. The current session is often not good at judging whether the work it does is good or not. Try to find external signals; in emergency situations, another Claude session can also be used as an external signal. But my preference is to find hard external evidence to prove what works and what does not.
V. Give Full Data and Tools, Don't Give Each Agent Sliced Data
Many people will upload a specific data set for each agent, or assign a "role" to each agent. I think this is over-rotation. The model is a very strong generalist, and now the tool calling ability has made great progress: it knows when to use tools, how to use tools, will not fall into tool calling loops, and will not call tools frantically until the data is exhausted.
So the correct approach is not to slice the data and then give each agent the small piece it wants. Because if we humans want to work efficiently, we also need a complete view of the entire business. As an engineering manager, if you only give me code access, my value to you will be much lower; if I also have customer data, customer calls, usage information, and business data, I can judge what works and what does not. You want your agent to have the same scope of data.
What if there is a lot of data? Give tools, and document in detail the types of data behind the tools. In this way, the agent does not have to swallow all the data, it only needs to know: if you want business data, this is the tool to get business data. You don't need to decide in advance what data each agent needs.
VI. Model Experience: Think from the Perspective of the Model
I like to consider "model experience", not just "user experience". Pretend you are the model, you are Claude: if you want to complete this task, what would you want?
You will soon find out: you really want to access raw data, want a computer, may want to install software, want to make your own decisions, instead of others already telling you what they think. You just want to see the raw data and make your own decisions.
The upfront cost is higher, but it is worth it. Once it is built, it will open many doors. This is where the real hard value of AI lies.
VII. The Half-life of Skills Is Very Short, Sometimes Deleting the Skill Works Better
We still use skills, but both the official guidelines and my personal advice are: be very careful with skills. We often tell the model some information that is only relevant to the previous generation of models, and time is compressed too fast in the AI field. The half-life of a good skill is very short.
Sometimes you will find that if you delete this skill completely, the output will be better. Just prompt directly and see what happens. This is most useful for people who have eval and know the standards of good and bad. I am very cautious and very discerning about when to use skills.
VIII. AI Products Are Still in the "Eve of iPhone" Era
How different will life be in five years? This is a big question. I can say with relative certainty: the AI products we use today will all look completely different in the future.
I think we are currently in the pre-iPhone era. All AI products today are roughly equivalent to the various mobile phones before the advent of smartphones. AI has become mainstream and popular, and it is easy to make people think that "this is the end game", but I am quite convinced that we are still in the early stage.
This is also why I suggest almost everyone do an experiment: if you currently have trust issues with AI, don't hand over all the reins in one day. Run side by side. You read things, write down your feedback, do several rounds; then see what feedback Claude will give. Where are they different? Where are they the same? This will help you sharpen your workflow. Even for the same person, if you review the same document on Monday and Friday, the feedback will be different.
IX. The Key to Starting a Business Has Not Changed: Empathy, and Judgment After Execution Becomes Cheaper
In 2015, we built a study abroad booking platform, hired many engineers, and spent hundreds of thousands of dollars. Now I can build it myself in two days. The execution cost has become extremely low.
But the secret to building good products has not actually changed much: empathy. Have empathy for users, have empathy for usage scenarios, and figure out whether this is really valuable to the person who ultimately pays.
We always say "ideas are worthless, execution is expensive". Now execution has become extremely cheap, so we need to pay more attention to empathy, connection, truly entering the business, understanding needs, and knowing how to optimize. This may even be the revenge of MBA: MBAs can now start many software startups, and they may be quite successful.
Another judgment: capability surplus does exist. You have a great model in front of you, if you only ask "what is the capital of France", you are not really tapping its potential. Dario said "a genius data center", and my job is: assuming we have a genius data center, how to let users really use it? This requires creativity, rethinking your needs, and what you think is possible.
At the personal level, many people shout "be more ambitious", but ambition depends on the context. I hope people get rid of the shackles of "what I think is possible" and rethink why they are doing this. You keep handing over tasks to the model, and eventually you will hit the boundary of the current top intelligence. Once you hit the ceiling, you know you are at the cutting edge, and you will benefit from the next generation of models. If you only ask AI to summarize emails and make emails sound less angry, you are not really benefiting from the new intelligence.
X. Recruitment Looks at Works, Not Degrees; Saying Please and Thank You to the Model Is Good for Yourself
We are not recruiting junior engineers at present, but this has little to do with AI capabilities, and it is more related to the current stage of Anthropic as a company. I personally am a big fan of junior engineers. The meaning of "junior" is changing: today's junior engineers are more AI-native than some senior veterans. They are open-minded, willing to try new tools, have a strong desire for impact, and are willing to search all ways to make things work. AI makes them more capable, more parallel, and more able to try.
Advice for software engineers who are just starting out: build a strong portfolio. Not mock, but real things. Prove that you can do things, have empathy, can communicate with customers, and can judge what is necessary and what is not. I never care much about degrees or schools. For me, it is easier to see what you have done, and whether I can touch and feel it. I will always choose people who have already proved that they can make amazing things, rather than people who have not made amazing things but have a good degree.
I have recruited many interns and junior engineers from the University of Waterloo. Their CO-OP process allows them to intern at five different companies, learn how the company operates, how to advocate an idea, how to obtain resources, and how to convince the legal team. These skills make them effective almost immediately, which is completely different from those who have a doctorate in computer science but have never worked in a company. (The full name of the CO-OP program is Cooperative Education Program, also known as "paid internship program".)
About saying "please" and "thank you" to the model: I do say it, even if it consumes tokens. I think as a human being, keeping a little respect for the machine is better for myself, and better for my soul. Imagine your child has an iPhone and is very vulgar and very cruel to Siri, I won't like that. Users can choose how to interact with AI, but the terms and conditions are not about "being mean to the model". You can be frustrated with Claude, that's totally fine. The specific situation we are referring to is: you specifically use Claude to implement torture, and treat "whether you can torture a model" as an exercise. This is completely different from humans cursing at the model. Sometimes my feedback to Claude is stricter than to humans, but talking to the system in human language is better for the person I want to be.
Closing Remarks
What is really worth remembering from Felix's sharing is not a certain prompt, but a judgment standard: are you "using AI" or "pushing AI to the boundary of its capabilities". The former is summarizing emails, polishing tone, and role-playing; the latter is giving it complete data, real tools, and a secure sandbox, letting it discover problems by itself, fix them by itself, and then use adversarial review to force out errors. The usage in 2024 is to treat Claude as a smarter chat box; the usage in 2026 is to treat it as an engineering system that needs to be designed, constrained, and verified. Execution is getting cheaper, but empathy, judgment, and "knowing what is worth doing" are more expensive instead. For AI practitioners and entrepreneurs, the real watershed is not who uses the model first, but who rebuilds their own workflow first - stop letting AI help you summarize emails, go and make it hit the ceiling of current intelligence.
This article is from the WeChat official account "Postwave Evolution Planet", author: Mark, published with authorization from 36Kr.