How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar
When I talk with my friends who work at Anthropic it always surprises me how far ahead they are in adopting AI within their processes and workflows. Generally what engineers in the industry start doing, these top AI labs have already been doing for a while. In this conversation, I asked Thariq Shihipar who is an engineer on Anthropic’s Claude Code team how Anthropic makes the most out of the models for engineering and how the industry will change soon. For instance, we discussed:
Hope the conversation is helpful for giving you some insight in how the models are and will change software engineering more in the near future. Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.  Timestamps00:29 - Onboarding at Anthropic 02:53 - Internal capabilities vs external perception 08:55 - What percent of Anthropics changes are fully autonomous 17:42 - How to make the most out of your compute 22:47 - Where the industry will go soon 26:02 - Which model do Anthropic engineers use 27:38 - Is learning a particular model worth it 30:56 - Prompting tips for todays models 35:04 - How to get the models to do tasteful work 39:00 - How much of writing is done by AI at Anthropic 45:36 - Code ownership and maintenance at Anthropic 52:04 - How Anthropic prevents breakages 55:24 - Visibility and sharing your work 58:42 - Luck surface area example 01:00:57 - Should people still learn to code 01:07:42 - Advice for his younger self Transcript00:29 — Onboarding at AnthropicRyan: [00:29] My goal with this conversation is to ask you as much as I can about how you can get the most out of the models specifically for software engineering, so that people in the industry can learn from the best practices where Anthropic‘s having success. And so to start the conversation off, I’d like to ask you, let’s say I was coming from a company that’s maybe less AI-pilled, and I was onboarding onto your team. [01:01] What are the most impactful things that you tell me to start doing to successfully onboard? Thariq: [01:08] I think the number one tip we have for both people inside and outside Anthropic is that if you treat Claude like a thought partner and give it the context that you need, then you can usually figure out the next steps. And so I think that starting with, okay, can Claude do it? If not, why not? And using that as the starting place, I think is really important. And I think just always thinking about, okay, reflecting on, can you move up a higher abstraction level? [01:42] Can you set up a system? Can you build the system that builds a system instead of just building the product itself? Ryan: [01:52] I remember when we used to onboard people, you would get assigned an onboarding buddy, someone who really knows the code base. And you can ask all of your trivial setup questions too. It sounds like Claude fills in a lot of those gaps. And in practice, is it 100% you don’t need an onboarding buddy and you can just ask the model for everything? Thariq: [02:14] You do need an onboarding buddy, but more from a social and cultural perspective than a technical perspective. I think, from a technical perspective, you can basically just work with Claude and, if you’re good at it, you can get what you need to onboard. But I think just having the context of how to work with the team, and also how to get buy-in on what you’re building, or understand how the team works together, or just even have a friend to work with, is really important. [02:46] So, yeah, we still have onboarding buddies, but it’s not nearly as much technical lift as it used to be. 02:53 — Internal capabilities vs external perceptionRyan: [02:53] There’s a big difference between the external perception of the AI capabilities and the internal Anthropic usage. Because I’ll talk to friends and say, yeah, what Boris is saying is the reality. And so my question is, why is there such a big difference between that internal perception and that external perception? Thariq: [03:15] I think we have a good track record when we make these claims. You’re like, oh, it turns out to be true on a large enough timescale. I think a lot of engineers are not really in the IDE anymore. The code being written is like, I talked to large enterprise customers where they haven’t typed a line of code themselves in six months. We think of it part of our jobs to figure out how to work at a higher abstraction level. [03:45] And if I spend a day trying to figure out how to get Claude to do this autonomously and I fail, that’s fine, maybe even good. Because now I can be like, oh, hey, Claude is not good at this. How do we make it better? But I think if you’re working an average job, your job is to produce the output. And I think automation always has a cost because it’s an investment. And if it works, then great, you’ll make a return on your investment over time. [04:14] But if it doesn’t, now you’ve wasted all this time. And so I think the nice thing about the models is that generally the chance of the investment working out is higher and higher because the models are getting smarter and smarter. But you still have to take that leap as an individual. Your boss is not going to be super happy with you if you’re like, you know, if you’ve been working on your harness setup the entire time and not shipping code. [04:40] But yeah, I think it’s mostly just culture and thinking of it as our job to sort of live in the future. And then we try and build it into the product and our harness as well so that you don’t have to do as much manual step. Yeah. Ryan: [04:53] Are there examples that come to mind when you think of things you don’t see people doing at Anthropic that are really making a big difference and you’d kind of recommend? Thariq: [05:06] Using Claude Code for knowledge work I think is really valuable. The way a technical person does knowledge work, I think, is very different than the way a non-technical person does knowledge work these days because you can get the models to do it. And so I think increasingly, if you can figure out, like, hey, this is a task, the task is made up of code-like things, how do I tell the model the code steps to take in order to do it right? [05:36] You can do a lot more, right. So I think I do a lot of accounting with Claude Code on the personal side, using scripts and Python instead of Excel. I do video editing using FFmpeg and these libraries to render visuals and things like that. And so I think most knowledge work is reducible to code and coding agents, if you think about it well. [06:07] And I think that that’s one big difference that I see, other people doing less of. 06:16 — Model vs HarnessRyan: [06:16] I think we talked a little bit about the model and the harness, and I want to ask you, what’s the relationship between the model and the harness in terms of getting the best end results? Obviously the model is important, so how important is the harness, and are there any examples you could share? Thariq: [06:36] Yeah, I mean, the harness is super important. I think that sometimes there’s this idea that the harness doesn’t matter because the models will get better and better. And if the model just does everything perfectly, then why do you need a harness at all? I think that in practice, what we see is the models get better and better, and so the harness needs to become more and more complicated to allow the model to do more things. [07:04] An example of this is Auto mode. And so Auto mode is a classifier that runs after every task that you normally have to ask a permission prompt for Claude. And back when we were on Claude Opus 4 or even Claude Opus 4.5, maybe it was not so bad to hit Enter on the permission prompts because the turns would only last a few minutes anyway. Now Claude can run for hours, and so you really need that ability for it to do work safely. [07:38] Stick to your instructions. And Auto mode is really complicated software. Sandboxing is really complicated software. And then you also think about things like, okay, Claude can do so much more work. Now, how does it represent the work that it’s done? It’s worked for eight hours and you want to know what’s done in eight hours. This is what we use Artifacts for. And Artifacts themselves are a form of prompting, because how does Claude represent that in a useful way? [08:06] There’s a lot of different ways that it could represent that information. And so I think roughly what we see is the harness. Harness engineering is definitely this mix of science and art. I think it’s very unintuitive in a lot of different ways, but I think it has just big abilities to unlock new parts of model behavior. And I just see the harnesses get more and more complicated, and it’s kind of harder and harder to actually vibe code to your own, which is a little bit unintuitive to me because of how good the models have gotten. [08:45] But yeah, things like Auto mode and workflows and things like that, which are actually quite complicated pieces of software, become really load-bearing. 08:55 — What percent of Anthropics changes are fully autonomousRyan: [08:55] I think as LLMs have advanced, more and more of the human part can be taken out of the loop. At Anthropic, what percent of your or your team’s changes are fully autonomously made versus actually pairing with a model? People were doing more of that around a year ago. Thariq: [09:18] I think it’s very dependent on what you consider autonomously made or what team or what function you’re working on as well. For example, a designer might give you a Figma file, and then you pass the Figma file to Claude Code. Claude Code is great at using the Figma MCP, but the designers put a lot of work in there. I think roughly our goal is to sort of get Claude being able to do all of the glue work that ties everything together, right? [09:55] So, okay, you’ve got a Figma file. Do I really need to rewrite that in React or something? Probably not. [10:00] I think that work has been done once, right? And so the way I think about it is, what’s the unique work that I need to do every day, right? And the more I’m doing that unique work, the better. And I think there’s just a ton of demand for unique work and thinking. And the more I’m doing something I’ve done before, I’m like, okay, can Claude do this? [10:24] Or if I’m just translating what someone else has done, I’m like, oh, can Claude do this as well? It’s really blurring the lines of what does it mean? Even if Claude has fully generated his PR, you’ve probably made a lot of decisions and added a lot of context along the way. Ryan: [10:42] How close are we to a world where someone just says, “Hey, Claude, here’s the ticket. Just don’t tell me until you’re done”? Thariq: [10:50] Yeah, so I mean, it depends on how good the ticket is. If someone has perfectly written out essentially a software spec for this ticket, then yeah, actually Claude can probably do that, right? But I think that to start, let’s say that we get a GitHub issue. Is this worth fixing? Oftentimes issues are also feature requests or something, or there might be multiple things happening that maybe you combine together in a different way. [11:18] And so I think that a lot of that work is, okay, what’s the vision for the product? Where do we want to go? [11:27] How do we make sure what we’re building is cohesive? And so I think for a specific spec, a specific enough spec, Claude can do it. In practice, people haven’t figured out what they really want and haven’t figured out the unknowns or the shape of the problem and things like that. And maybe the way you would have done it before is you start writing the code and you’re like, oh, what am I supposed to do now? [11:55] Or you figure it out that way. Now I think you need new ways of figuring out what you don’t know yet. And I think you can still chat to Claude, really. But I think that’s the hard part. And I think definitely a failure mode is like, you tag Claude, tag. And you’re like, hey, please do this one sentence or less description, no previous context or memory. And then it does it. And you’re like, oh, no, I don’t like it. [12:22] And then you’re like, just iterating forever on that, right? Versus figuring out what you actually want, really quickly. Ryan: [12:30] When I was working at Meta, the ambiguity of the task really ranges, oftentimes proportional to people’s—I mean, levels aren’t everything in software engineering, but roughly, senior engineers kind of take that ambiguous business need and convert it into something that’s a lot more concrete. And then people who are maybe newer in their careers kind of do the implementation work, and intern projects were kind of almost line by line specified. [13:02] If I was still working at Meta and I had an intern, I was like, just kind of give the intern back. Give Claude my intern’s work back, and it would kind of do it. What kind of work does an intern do then at Anthropic, if Claude can kind of handle it? What we see in practice is that there are just so many new types of work that no one has ever done before, right? Thariq: [13:55] And I think that we all have to figure that out. And so, for example, how do you do an eval against these new coding behaviors, right? How do you make sure that Claude‘s performance across millions and millions of users doing all sorts of tasks? Sometimes these tasks might have tradeoffs, you know. So I think there’s a lot of new work to be done, especially on the research side of things. [13:19] And I think that it’s harder and harder to write those specs, but there’s also less and less experience that is relevant, you know what I mean? And so I think that, yes, having some experience means that you can sort of, you know, you know how to get work done and you know how to learn. But I think you also get those skills out of college. And now I think as an intern trying to figure out, okay, what are the things that people have not done before? [14:25] And doing that, I think, is really exciting. And I think that there’s, yeah, I think internships are less “write the React code,” you know what I mean? And there’s so many new problems to solve. We need people to solve them. It’s helpful if you have a fresh set of eyes on it. But it is definitely more proactive and opportunistic, maybe than before, where it was maybe more of like a pipeline. 14:51 — Computer useRyan: [14:51] We talked a little bit about knowledge work, and that makes me think of computer use and browser use. And I wanted to ask you, how far away is that from being widely adopted in the industry and impactful? Maybe you can talk about how Anthropic uses it, since it feels like you’re always far ahead. Thariq: [15:11] I think computer and browser use, the models have gotten a lot better. Opus 5, I think, is a really good computer use model. But there are these weird edge cases where, for example, it can’t type a password on my behalf because my passwords are in 1Password or something, and it can’t access that. And so it gets stuck. I think there are still those edge cases, which are kind of UX edge cases. And then I think also, obviously, computer use is also the more and more people turn APIs and MCPs into new ways to use Claude. I think that can also take a lot of the use cases that you’re using computers for. [15:51] And so going back to, oh yeah, knowledge work, everything is code. I think there are some things where there’s no API, there is no way to execute in code other than just opening up your browser. But I think increasingly there are more and more ways. And I think, yeah, Claude Code is a great example of we’ve just sort of tried to roll up all these things into APIs that it can use. And so it feels like it can do a lot of work on your behalf, even though it’s not literally running a virtual computer and clicking things. Ryan: [16:24] I have noticed that whenever I use any kind of computer use tooling, it feels painfully slow. I look at the cursor, and it’s sitting there for 10 seconds, moves over, goes there for 10 seconds. Where is all that latency coming from? Do you have a sense? Thariq: [16:41] I think it’s hard to make a small model that’s really, really good at it. I think just because there’s a lot of knowledge that you need to have about this task and how these things work together and stuff. And so you want a smart model, and smart models take a little bit longer time. I think a lot of people thought we’d get here sooner, but I think it’s just been a harder task than we expected. [17:03] I think one thing someone’s told me about computers before is that it’s a state machine where you don’t control the entire state. If you are on the DoorDash website or something, you want to add something to the cart, and you add it incorrectly. Now you have this new flow to undo it. Now you need to go click, and now you need to go delete it, and you can make a mistake along that side as well. [17:25] Whereas in code, you can sort of undo, Git, whatever. You control all of the state. But for computer use, each action is, if not irreversible, it’s much harder to reverse than others. 17:42 — How to make the most out of your computeRyan: [17:42] At Anthropic, I get the sense that employees have a lot of budget in terms of the compute to speed up whatever it is they need to do. And so if we were to spur the imagination of people who use the models to make them more productive, assuming they had infinite compute, what type of workflows would you start telling someone to do if they had infinite compute? Thariq: [18:10] I think this difference is slightly more exaggerated than you think. I think that, for example, I use my Max subscription on the weekends, and I have almost never hit a five-hour limit. I think the models are really smart, and I think that a lot of times when we’re spending a lot of compute, we’re just trying to find capabilities or we’re trying a bunch of different things, and it’s more about us figuring out model possibilities than getting a lot of work done. [18:43] When we’re testing for math, for example, we’re trying to understand how smart the model is. And that is useful to us, that’s useful output to work. And it can also sometimes solve the Riemann Hypothesis or something, or not make progress, you know what I mean? People can replicate what we do at home just by thinking at a higher level of abstraction. For example, I’m trying to get Claude to draft feedback for you. [19:07] And so I want the funnel for, like, Claude has drafted some feedback to the user, has submitted feedback, to be really good, right? And so I monitor that funnel. And then I asked Claude. I had some ideas, but then I was also like, oh, what if I ask Claude to try and improve the funnel? And it’d be like, here are some ideas, can you come up with some as well? Let’s figure it out. All of those things you can kind of do yourself right now. [19:33] If you’re like, okay, when I’m making a feature, let me annotate it with events. Let me make sure that Claude has access to those events. Let me run a loop in the morning every day to check what events have fired and what changes were made. Maybe even let me proactively suggest some ideas. This can all happen, I think, within a fairly reasonable amount of compute, actually. What I see more often is people running into limits where they’ve actually done the opposite. [20:04] They’ve started with a small mid-scope task. It’s like, oh, hey, refactor this function in this way, and then Claude does it, and maybe it has some follow-on effects because refactoring this means you have to do some other work too. And that’s not exactly correct, or you’re iterating there, and it’s like you’ve just spent a lot of time. Whereas if you had sort of stepped up a level, told Claude your goals, then figure out, okay, what are the details, do some exploration, maybe write out the schema, and then work with it, then let it run. [20:41] You could probably get the same output. 20:45 — Loop engineeringRyan: [20:45] I remember it was going kind of viral, this idea of creating loops. And I mean that does feel like a pretty expensive sort of thing to set up if you’re just asking it to keep hammering away. Maybe first could you define this loop engineering thing, and then I’m curious, how often do you use it, and would you hit limits if you were on a Max subscription doing that kind of stuff? Thariq: [21:10] Yeah. Okay, so loop engineering, roughly, it’s like instead of prompting Claude directly, you’re setting up a system that prompts Claude. You don’t have to think of it, if you use Claude Code, a lot of this comes naturally. You just ask it, like, hey, every day do this thing. And that will, that’s a loop. You can definitely do that sort of work right now. But I think if you’re trying to set up, let’s say, like 10 loops or something that are triaging your feedback and implementing and things like that, we do that sort of work, but we also spend a lot of time making sure our skills and things like that are useful and are good at triaging, that we can have, we’re good at verification and so that we can, like, make sure that the changes land, you know, and then I think at that level, you know, what it means is like, now we have someone monitoring issues that we just could never have kept on top of before, right? [22:16] And it just increases our software development velocity, and it’s worth a lot of value to us. And so, yeah, I think that, if you’re kind of at the scale of like, okay, you want it to essentially be autonomously running, doing a software engineering job for certain cases, I think it can do that if you set up the verification well, if you set up your skills well, if you give it the right data sources. [22:38] But it is a lot of work, right? And I think that you have to make sure that that work is valuable to you in the same way that if you hire someone, you have to make sure that work is valuable. 22:47 — Where the industry will go soonRyan: [22:47] We’ve talked a little bit about Anthropic being kind of just ahead because that’s the job of the company, on adopting AI. Is there something that you feel is kind of the next big shift that maybe Anthropic‘s already felt that you feel is going to diffuse into the industry, and if so, what might that be? Thariq: [23:06] Yeah, I think there are a few different ones. Obviously, Claude Code is the way we do a lot of our work right now. I think the way I think about it is that Claude Code is really good at the implementation of code, and Claude Code is for the rest of the software development lifecycle, so getting feedback, doing code review, babysitting, building CI/CD incidents, all of these other things. Claude Code is really good at at a high level. [23:38] Turning every part of your software development lifecycle into kind of like a routine or a loop using Claude Code or something like that, I think is probably where things are headed. I think generative interfaces are still to come, and I think that Artifacts and, yeah, basically Artifacts, I think, are going to be an increasingly large way of how you interact and read with Claude. [24:06] And so I think that I use Artifacts for almost everything. And so I think that we’re going to see that also become big. And I think that also ties into Claude Code. Right? So, like, let’s say that you are on your phone and Claude Code has done a bunch of work for you. It creates a report. The report is readable on your phone because it’s made the, like, the Artifact look really great. Ryan: [24:28] Could you explain artifacts a little bit, or kind of what are they and how do people use them? Thariq: [24:34] Artifacts are basically Claude can upload, essentially a web app for you to use. And I think that you can use it in a really wide range of capabilities. They can now, for example, call your MCP. So you can make an artifact, for example, to read your inbox and display it or sort it or tag it in one way. You can also use an artifact to show you a plan for coding. And that might show diagrams and file snippets and code and schemas. [25:09] And so it shows you sort of, it’s like an interactive display for the job you’re doing right now. And as Claude does more and more jobs, we’re realizing that just text in, text out is probably not useful for everything, right? And Claude is better and better at creating essentially the exact interface for you at the right time. I think that there’s a lot more to do there. And I think it’s another one of those things where you have to think about, like, oh, could I be interacting with Claude in a different way? [25:44] Could I interact with it through an artifact? Could I use it to learn more or to understand it better or stay in the loop or improve some of my own knowledge work or something? Yeah, I think it’s pretty exciting. We’re still kind of early to it. 26:02 — Which model do Anthropic engineers useRyan: [26:02] Does the daily driver model vary among engineers, or do people typically just pick the most intelligent one that’s available at Anthropic? Thariq: [26:11] I do think similarly with models. If you use the smart models and you use them well and you give them tasks where they are well shaped and you’ve spent some time setting up a good verification harness and things like that, you can get a lot out of them. I don’t think it’s like choosing which model at the right time. I think it’s like, oh, how do you get the most out of the frontier models? Because I think technology works the way it does, right? [26:37] Everything gets more abundant, more available. And so I think we’re in this current weird spot where we don’t quite have enough compute for everyone to have Fable at 100% of the rate limits. But I don’t think this is a durable skill to build, figuring out, like, oh, when do you use Fable and when do you use Sonnet? I think it’s unintuitive there. But I think in practice, if you’re today, what I would do is I use Fable for planning, for brainstorming, for finding unknowns, for coming up with a detailed spec, and I’d use Claude Opus 5 to implement it, and I would probably use Claude Opus 5 with workflows using a verification aid like Schema or Harness that’s built with Fable. [27:21] So I’d use Fable for those high-leverage tasks and, yeah, Claude Opus 5 for execution and implementation. But yeah, I think increasingly, probably next year, I think you’re just not going to be thinking that much about which model. 27:38 — Is learning a particular model worth itRyan: [27:38] You mentioned that skill of prompting, and I’ve heard some people say it’s not too durable of a skill because it’s really specific to a model. These models, they almost have their own unique, I guess, spiky intelligence. So if you knew everything that was very specific to, let’s say, today’s Fable, and you’re a master of today’s Fable, maybe you don’t need to know any of that stuff a year from now. [28:08] And Fable 3 or 4 or 5 or whatever comes out. Let’s say you were talking to a software engineer who’s looking for career advice, and they’re thinking, hey, should I really become a master of engineering? Thariq: [28:23] My prompt, I do want to say prompting is a little bit more than just a prompt you put in. It’s also, you know, you might have made a skill or you might have added some data or something. It’s not just a prompt you write, but it’s like everything you’ve done before that builds up into your context. Sometimes people see us write small prompts and they’re like, oh, what does that mean? [28:44] But we just spent so much time on the harness and the verification and the skills. So I think it will be really valuable to just get better at prompting. I think, to what you’re saying about each model is different, you’re right. I think each model is kind of its own kind of almost organic digital thing. And so there are quirks you have to learn, and you do have to unlearn them. We recently wrote about how we removed 80% of the system prompt from Claude Code. [29:18] One of the learnings we had was we needed to remove examples from the tool descriptions. This used to be the only way you could get good output from the models was through tools or through examples. You’d have to be like, hey, this is the right tool. Use this here. Here’s an example of writing a file well, and here’s an example of not doing it well. Now, we found that examples are mostly negative, I think, unless you really see Claude doing something you don’t like because it’s just quite imaginative. [29:52] It’s good at sticking to your intention and working with you. And so we removed a lot of examples. So in that case, yes, you do have to sort of adapt, but the skill you’re building is the skill to adapt. You learned how to use Fable, and now you know a lot about Fable, but you also know how to learn. You learned how to work with a model, and so Claude Opus 4.5 comes out. You need to learn how to use it again as well, but you’ll be much faster because you’re better at learning. [30:22] You’re better at working with Fable 5. And I think, for me, I think the first model I worked with was GPT-2. And I remember it was so hard to get a JSON output out of GPT-2. If you could just get it to choose one of the categories that you gave it, that would be incredible. And so I think that building that skill—GPT-2 is such a different model than Fable 5—but I feel like the time I spent doing that has helped me be better at prompting Fable 5. 30:56 — Prompting tips for todays modelsRyan: [30:56] Is there any tribal knowledge or quirky tips in today’s models where you’d say someone should know that to get more when they prompt? I actually need to counter one. Thariq: [31:03] I think that people have been saying where it’s like, oh, just believe in yourself or something. I know that Jared’s post about the Riemann Hypothesis. He was just like, keep going, just believe in yourself. I think in this case it was mostly just Jared saying, it’s okay to use Claude Code to solve this problem, and I’m giving you permission to do it. And I think that that’s not exactly the same as I believe in you. [31:33] You know what I mean? It’s really just letting the model use compute. So I think that is something I like to tell the models right now is like, okay, hey, I think this is a hard problem. Use subagents, use workflows if you need it, right? So I always tell it to use its own judgment, but I’m giving you permission to do this stuff. I think that you have to remember that the models by default do what maybe the average user wants, which is they want it to respond and start doing work as fast as possible. [32:11] Roughly complete the task but not spend a crazy amount of compute on it. I think that you have to sort of, if you want the model to do it differently, you have to nudge it slightly, right? So you might have to be like, okay, hey, I don’t want you to do any work yet. I want you to brainstorm. I want you to think with me, right? And if you prompt it that way, it will start doing that if you want it to spend a lot of compute. [32:36] If you’re like, hey. Sometimes I’ll say, yeah, hey, I think this is a hard problem. Feel free to use workflows. If I’m running overnight, I might just be like, hey, I’m going to sleep. Set a /goal or something and then let it run. So yeah, I think there is just giving it permission to do the thing you want. Ryan: [32:57] When you recently removed so much of the system prompt, how did you prove that the end result was better? Thariq: [33:06] We have a bunch of user metrics, just like how much do people like the output of Claude? Sometimes you get that survey and you see it. We run evals against our internal eval and external evals to see how it performs at these different tasks. But I think it is hard sometimes. You don’t realize that if Claude is telling the user, if it does all its work and then it’s like, hey, maybe you should go to sleep. [33:35] There’s no eval for Claude telling you to go to sleep. You know what I mean? And now we have to catch this new behavior. So it is hard. I think we spent a lot of time basically just removing lines in system prompt, running evals, seeing how it works, seeing how people reported it internally, and then adjusting. But it was a full-time job for several people over long periods of time. And so I don’t think I necessarily recommend everyone do this. [34:03] I think that’s kind of why we wrote that post about what we learned from adjusting the system prompt. And we think that’s pretty general. So hopefully you don’t have to now go through this crazy iteration process. 35:04 — How to get the models to do tasteful workRyan: [35:04] I think a lot of people, when they use Claude Code, they get excellent results when it’s kind of getting very objective work done. [35:13] But when it’s prompting models to do beautiful or tasteful work, it’s not always. It’s pretty much more hit and miss. And so, how do you best instill a very particular style you’re going for, or particular taste in the model’s outputs when it’s a much more subjective domain, maybe like front end? Thariq: [35:35] The way you do it is sort of like you stay in the loop. I think you give it references, and I think the more references you give it with data, the better. So it’s better to give an HTML file than a screenshot. It’s better to give a Figma file than a raster image or something. Because now if Claude wants to know the border radius of this thing, it’s like, oh, what’s the Figma component? Border radius? [36:00] And let me just copy it over. I think giving it a bunch of references, ideally in code, is a really good way of getting it to stick to this. I think if not, you can then ask it to. If you don’t have, let’s say you’re not a designer, there’s probably step one is being like, okay, I’m not a designer. There’s a lot I don’t know about design, and there’s a lot I don’t know about iteration. I don’t even know what good looks like. [36:29] And I think this is part of the art of working with the designers. They will just know what good looks like, and they’ll be like, this isn’t good enough in this way. And they prompt it. And that, I think, is also a skill that will keep getting valuable and even more valuable over time: what is good output, what is worth doing? I think, for example, with the Riemann Hypothesis, Jared prompted it, but he had no idea if it was correct. [36:56] Until Lev, who is one of the world’s best mathematicians, was like, okay, is this correct? And he worked with it, and he asked it tons of follow-up questions, and we could not follow that at all. We had no idea what he was saying, but he was really intrigued. I think more and more, being that high-taste user and knowing a lot about a problem in a domain space is how you get good outputs. That’s how you solve these problems. [37:27] Otherwise, maybe Claude did solve physics or something, but you just wouldn’t know it. You don’t know enough about it. And so I think when you’re talking about design, the first thing you do is how do you become more tasteful with design? And so you can ask Claude that as well. You can be like, hey, I’m not a designer, I want to be better at design. I don’t even have the language first. Maybe let’s find some reference sites. [37:50] And then maybe you pull some reference sites, and then you’re like, this is what I like, or this is what I don’t like. And then you sort of build up those references, and you give Claude Code, and now maybe you tell it, hey, let’s do some exploration. This is sort of my taste. And then it’ll do a few different mockups. I like to do these mockups all in HTML because it’s all self-contained, easy to edit. [38:13] And then once you have that reference, now it’s a reference. So now you can make a new session and be like, hey, this is a mockup of a design. I want to start implementing this, and it will have all of it in code, and you can start getting there. But I think that the really hard part is just knowing when something is good enough versus when can you push harder. And you see this with a lot of the math proofs too. [38:41] When Terence Tao is like, okay, enough with the half-complete theorems, just do the full theorem. And so I think it sounds simple, but it takes a lot of domain knowledge and expertise to get to the point to be like, okay, it seems like you’re smart enough to have done that. Now do this. 39:00 — How much of writing is done by AI at AnthropicRyan: [39:00] When I was a software engineer, there was a lot of, I guess it was like glue writing work kind of where you finish some work and you write a launch post, or you are part of some work stream and you got to post an update every two to four weeks. Or maybe you have a direction doc or design doc and all this writing around the software that you actually write. And curious your thoughts on if that’s changed at all at Anthropic, how much of that is written by LLMs and how much of that is human written? Thariq: [39:39] Still, my rule of thumb is if I would be happy to show someone the prompt, I would send them the output, right? And so a lot of times the prompt is just collecting context. Context is the most common one. For example, before every one-on-one with my manager, I asked Claude to read every Slack message and GitHub message or PR and compile a report of what I did. That’s context that my manager doesn’t have because they haven’t been literally reading every PR or something. [40:15] And so I don’t feel bad if my manager could also run this command, but it doesn’t have my context. And I don’t feel bad with them knowing that this is the prompt I used to generate this command. I think likewise, if you’re sharing updates or something like that, you might want to prove that you’ve read it. I think this is important. And sometimes little edits are ways of proving that you have also understood this work. [40:45] And so if it’s just like a data readout, maybe you’re sanity-checking the numbers make sense and these are all the numbers you intended to include. And as part of that, maybe you format it differently or you add a little sentence on your behalf, but I think ultimately it’s a data readout. Everyone knows the prompt you wrote is like, hey, generate a readout on this feature based on this, and you’re fine, right? [41:10] But I think if you’re pitching a new concept or a new idea, and your prompt was like, help me come up with a new concept for this product, right? People probably at least want to know that you’ve believed in it, right? And so even if you think Claude‘s idea is incredible and just verbatim, you wouldn’t change anything. What I would say is, I’d be like, hey, Claude generated this. [41:34] But I think it’s great, you know, like I did 100 different generations. And I think this was really good. And here is something, you know, that I want to send you, right? And so I think that it’s good to be upfront about it, I think, right? Because I do think what people don’t like is when they feel like they’ve been misled a little bit. Like, oh, we thought you were doing this work, but, you know, it’s really Claude. [42:01] Right. And I think that writing sometimes can have a lot of... There are some parts of writing where individual words matter, funnily. Tweets are, I think, an example of this, where the individual tweet matters more and more. You can’t use Claude to do that because it’s like every word has some thought that you’ve put into it and some intention that you’ve put into it. So yeah, a pitch or an essay or something like that. [42:29] We do a lot of internal essays at Anthropic, being like, hey, this is why I think we should do this. And that’s generally all human written. It’s very looked down upon, I think, to have Claude write your essay for you, you know what I mean? Because every word is something that you are intentional about. Ryan: [42:48] This sounds like the proportion of the writing. That’s all that boring rote writing, like the data readouts, the one-on-one updates, the work stream updates, that’s increasingly becoming AI but always reviewed by a human. And then the novel thoughts, novel direction, is still very human written and feels like it should remain that way, even if the models were a little bit better too. Thariq: [43:16] Yeah, I think it’s like if your writing is also a way of thinking, and so maybe if you need to think about the data stream or data readout more than maybe you need to summarize it. And so, but I think especially gathering context is one of those things where no one will ever hold it against you, kind of. Right. Like, oh, you know, you did a bunch of research and Claude did this. [43:41] But yeah, like I don’t want to ask my agent to do the same research. Like, you know, it’s a shortcut, but just acknowledging it is good. Ryan: [43:48] Someone else I was talking to, they had this thought that it would be valuable to have almost like a Git blame, but it’s like a prompt blame because it would be nice to reverse look up what was the prompt that generated this change, to kind of debug things. Do you have any sort of meta version control on the prompts that generated the software, or is it still very vanilla Git history? Thariq: [44:17] Yeah, that is a little bit tough because, again, what goes into a prompt is not just the prompt, but also context and skills and things like that. So maybe a prompt might seem basic, but isn’t. I think it’s kind of hard to judge, but I do, going back to when I’m giving a PR, I don’t think a PR at this point is any different than an artifact or something. Claude is doing basically all the code writing. [44:44] So if I send someone a PR, I usually also attach an artifact of every prompt I sent to Claude, including failed approaches and things like that, so that they can see, okay, I’ve considered a lot of other things. And if I haven’t, if this is just a one-shot, I just tell people, I’m like, hey, this is the one-shot example. This is the prompt I used. And I think that’s usually impressive and interesting to them as well because they’re like, oh, it’s cool that Claude could one-shot this. [45:18] But the worst is when you get, like, I’m just trying to avoid cases where I send in this 10,000-line PR and they’re like, how much have you read this? Or how much do you work with Claude on it? And if I’m doing a large PR, I am going to show my work. 45:36 — Code ownership and maintenance at AnthropicRyan: [45:36] as much as possible on maintaining code, because AI can generate such high volumes of code at this point. Do you have any tips on what’s worked well at Anthropic for code ownership and maintenance? Thariq: [45:52] I do think you have to revisit what is important with code maintenance. I think that there are some things where naming used to be really important because it was how you as a team thought about this abstraction and feature. But I think naming is becoming less and less important. A lot of stylistic things in code are becoming less and less important. And I think that this is not the same to me as maintenance. [46:19] I think that you might want to sit down and be like, okay, what things really matter now? What don’t? What opinions do we have that don’t matter? That’s one. And then I think on the second, on the maintenance side, is having good scaffolding. So I think that it’s like having a good verification harness, having a good sort of skills. We use the simplify skill a lot. I think that sometimes even from a model perspective, it might do a lot of work. [46:51] And then even just giving it permission to be like, “Hey, I think this is the right idea. Let’s simplify.” It gives it that permission to do it. But you actually don’t want a model to, by default, do work and then simplify because maybe it’s not correct. You don’t want it to simplify work. That’s not correct. It’s like you’re wasting tokens. And so I think this is also how humans think. You’re like, you think generatively, you try and approach, and then maybe you simplify and abstract a little. [47:23] So I think there’s some work inside your own code base or setting up those skills and that process for those practices where you’re not just submitting the first take, but you’ve simplified it and tried it. And then having a really good verification harness where you feel like you’re catching it. You have a good belief that Claude is testing every part of it. When you submit a PR to Claude Code, you get a recording back of it using the feature and testing it as an example. [47:56] And you can just get really, really creative with different ways to test stuff. I think you should basically have on the order of, I’d say more like 100 times more testing code than you’ve ever had before. You know what I mean? So you should have fixtures for everything. You can just pull production code and create fixtures and mockups on the fly for databases. You can have Storybook for front end and things like that. [48:22] And you can have all these different ways of testing and verifying your code. And that, I think, is really valuable for maintainability. It’s like just having all these ways of verifying it. And then, of course, there’s just the human element of where do you want your codebase to go? If you know that’s the case, probably you start thinking about how you’d replay, and undo and redo becomes really important, just that sort of stuff. [48:52] But if it’s single-player only, that actually matters a little bit less. The average user is not going to undo 100 times or something. And so many single-player applications’ undo stop working pretty quickly after four or five times, just because it’s not that important. But in multiplayer, the ability to compose different things together is really, really important, or compose different operations together is really important. [49:19] That’s just an example where, if you know the direction of your codebase, there are things you care about and you want the models to know, and you can include that in your skills. You can also just. That’s sort of what maintainability means to me, is having a vision for what your codebase is good at, where you’re going, keeping it in line. I do think the models are getting better and better and better. [49:39] And almost every code base probably, I think, will have this moment where you’re like, do you just ask the model to rewrite all of it? Because now you’re like, oh, I can do it in the most performant language, I can mix and match. There’s not a reason that every software in the world shouldn’t run in WebAssembly in the browser. You know what I mean? There’s not a reason why I don’t know your Xbox game can’t run in your browser. [50:09] Actually, the consoles are much weaker than your average MacBook right now. But it’s just the code base. But we could. And so I think probably over the next year or two, everyone’s going to need to think about that. And so I don’t think you want to spend too much time worrying about maintainability in this way. That might not matter anymore. I’m not saying maintainability doesn’t matter. [50:37] You just have to update your mental model of what does it mean for code to be maintainable. Ryan: [50:43] I was talking to this friend who was saying that he leaves tons and tons of tech debt lying around because the next iteration, why waste time fixing that now? In the next iteration of Fable, it’s going to one-shot all this tech debt and refactor this for me. So kind of funny. Thariq: [51:05] Yeah, I don’t think that’s completely incorrect. It depends on the circumstance, right? I think this is also just a classic thing in startups where you’re like, even in normal human engineering, you always have this problem of like, hey, do I refactor? Do I do tech debt or do I deliver more customer value? Would refactoring help me deliver more customer value right now? I do think that, generally, you should think on your projects on shorter timescales, so you’re like, okay, how do I deliver value over the next month or two? [51:36] And if the project you’re talking about is delivering value over six months or 12 months, then maybe wait for the next model a little bit and just deliver value on the short timescale. Make sure it’s really good. And if the models are not quite good enough, they might get there soon. It depends very much on the specific case. [51:59] Right? But I’m not saying this is true of everything, but just something you should keep in mind. 52:04 — How Anthropic prevents breakagesRyan: [52:04] I’ve talked to some friends who work at big tech companies like Google, Facebook, those types of places. And then they, as they’ve become more and more AI-pilled, one thing that people have noticed is there’s a lot more incidents or sevs in their usage, and it’s natural in those organizations because they read the code less and there’s more code flying out. What countermeasures have worked really well for Anthropic to prevent breakages, given that the code velocity is so much higher? Thariq: [52:38] Yeah, I think this is something that is a byproduct of moving faster sometimes, and we have to figure it out. I don’t think our uptime is exactly where we want it to be either. But also, as a company, we’re almost six years old, I think, around. So it’s like no company has grown this fast before. And a lot of that is because we’ve been able to create more products faster than ever before. [53:04] And so you can use Claude to make your uptime better. And I think the way we think about this is just really good. What’s the dream testing environment? The dream deployment environment? Can you take requests and replay them across mock databases and fixtures? Across everything. Can you Chaos Monkey everything? Ryan: [53:26] In my personal workflows, I have so many more custom random tools and scripts that just make everything faster. And just curious, on your team at Anthropic, for instance, does everyone have a set of miscellaneous tools that help them get random things done? Thariq: [53:48] Yeah, everyone does for sure. I think part of this is the job. I think that sometimes what we try and do is we play around with harnesses. Sometimes some people on the team build their own harnesses for a little bit to figure out, oh, is this useful or not? And then they figure out if it works and if not, they integrate it. I think that’s part of the job in some ways. I think other examples of sort of misc stuff people will do. [54:18] A lot of people will have unique Claude Code setups. I think Claude Code is one of these things where, you know, you can have it like I have it scheduled, my calendar advice, right? And so if someone wants to schedule something with me, I’m just like, hey, you can just tag Claude here in this channel and I’ll accept whatever it puts on my calendar. You know what I mean? So I think there’s some stuff like that. [54:41] I know a lot of people use it for email. I think that I’ve seen some people do interesting multi-closing, sort of tmuxing-like setups. What’s the ideal scenario for you to display 50 different Claude Codes, and what’s the best way for you to figure out what’s going on at any one time? I think there’s a lot of different ways, and we’re trying to make Claude Code more hackable as well so that more people can even make their own version of Claude. [55:18] Code more different, and everyone might have their own little twist on it. 55:24 — Visibility and sharing your workRyan: [55:24] Your role at Anthropic is really interesting because of the external visibility that you have. And I think a lot of people, when they give career advice, visibility is a good thing, but they don’t have this level of external visibility. So do you recommend to software engineers that they should be posting on Twitter and X? And if so, what advice would you give in that sense? Thariq: [55:49] Generally, the thing I say to people is that you should share your work externally as much as you can. Especially, I think, within certain companies. You might not be able to, but maybe you have side projects or something like that. I think just before I joined Anthropic, what I did was I spent a bunch of time working with different companies, building stuff, and writing about it and talking about it. [56:13] And this was really valuable because it increased my surface area of luck. And so I think that the bar is much lower than you think. Basically, whenever someone asks me for advice, I’m like, okay, I’ll sit them down. I’ll be like, I know statistically I tell this advice to a lot of people, and almost no one does it. And everyone who’s done it is either in a job that they’re pretty excited about or running their own company. [56:45] And there are reasons why you’re not going to want to do it, but this is it. I just can tell you one: I don’t care about your resume. Don’t do that. You have to choose an interesting project to work on. You have to work really hard on it. You have to lock in, and then you have to ship it and write about it. You have to do it. You can’t. There’s going to be so many reasons why you don’t want to. [57:06] It’s like not good enough yet. Or like you haven’t, like you think the writeup is not very interesting or something, but you have to do it and you can’t get discouraged. Maybe the first one might not work, but you have to do it again. And maybe Twitter is not the right place. Maybe it’s Reddit, maybe there’s a specific Reddit or Hacker News or something like that. Part of what you’re trying to do is you’re just trying to find people who like what you’re doing, right? [57:29] But I think that people in general want to really, you know, we consume more content than ever, right? And you know this, right? I think that people want really high-quality content. High-quality content, as you know, is a lot of work. And so I think going back to what we said before about would you show someone the prompt? You did, right? I think a lot of times people are like, oh, what’s the shortcut? [57:55] “Oh, should I just ask Claude to manage my Twitter account? And is that how I grow?” And I’m like, no. Like, you should not do that. [58:03] You have to sort of engage authentically. You have to post, do good work, and talk about it. And I think build up networks and things like that. But I think that as long as that’s one of your goals and you try hard at it, I haven’t seen anyone not succeed at it, but it is really hard. It’s kind of like saying, oh, I want to go to the gym every day, or I want to lose weight or something. [58:26] There are simple things that you can do that take a lot of discipline and are easy to get discouraged with. But they’re worth doing if you do it. And I think posting, or more specifically writing about your work, is really, really valuable. 58:42 — Luck surface area exampleRyan: [58:42] You mentioned LLM surface area. Do you have an example that kind of illustrates the value of expanding your LLM surface area? Thariq: [58:52] Yeah. I mean, okay, how did I get my job at Anthropic? I did a fellowship with a company called Goodfire where I did some applied research. And so they’re an interpretability AI company. And I was trying to figure out how do I use interpretability to make better products? And so I learned about their research, and I felt I want to work on a project, and it was really important for me to share it. [59:21] And so, when I agreed to work with them, I was like, that’s my goal: I want to share what I’m building. I think that’s good for you as well, because Goodfire is a startup, and people want people to learn about them. And so this is something I’m going to do. So I built this interpretability visualization, and I shared it. This was my first big post on Twitter, but it was only 500 likes or something. [59:42] Now, you know, that’s not very much to me, but it’s like, back then it was like a huge post, and several people saw it, and some of them DMed me about it. And then I got an intro into a role here. And so I think that I spent a month on that project in particular, so it wasn’t crazy. And, yeah, it just showed people that I could do interesting work. [01:00:17] And I got paid for it too, so it wasn’t like I was doing it for free. And there’s plenty of examples of, I think people are happy to do that sort of thing for you, if you sort of show that kind of initiative. But yeah, you have to. It is like, you really have to do interesting and novel work and work hard and be proud of your work as well. There’s not a shortcut to that, I think. [01:00:43] But if you do, I think everyone is always looking for interesting work and wants to support you and wants to hire you or, yeah, give you money, like, lots of good things. 01:00:57 — Should people still learn to codeRyan: [01:00:57] I see this tagline going out a lot with some of the stuff that Anthropic‘s been maybe, like, I think it was Boris went on some podcasts, and the tagline was, “Coding is largely solved.” Should people still learn to code if coding is largely solved? Thariq: [01:01:14] I think being technical is really, really important. Knowing how computers work, how computer programs work, how languages work, what are the hard things? And what’s a backend service, what’s a cache, what is memory allocation? All of these things are actually kind of really important to learn. I do think it’s hard to motivate yourself sometimes to do it the same way that doing math by hand was not that motivating to me, but some people just love math and did it. [01:01:49] I think that that’s probably something that people have to figure out, but I think it is really worth it. Being technical is really, really important. We talked about at the start, or earlier, where the only way you can tell you’ve solved the Riemann Hypothesis or made progress or whatever is if you’re a great mathematician. And in the same way, the only way you can tell if you’ve built great software is if you’re a great software engineer. [01:02:19] I think that how do you do that is hard. But we’ve talked about some of this stuff before, just staying in the loop, reflecting on your process and getting better. And you can use Claude to learn as well and sort of explain things to you. So treating it like a thought partner, but learning truly. I think Karpathy says learning should feel like effort. And I think that’s one of the hard things is a lot of times, even if you ask Claude to explain something to you, you might just nod along and you’re like, oh, yeah, I learned it. [01:02:52] But you didn’t really, because you didn’t put any effort in. So I think it is really technical. You should learn. It’s hard to learn. And sometimes what school forces you to do is learn that. I don’t know, truly. I’m not learning programming from scratch, so I don’t know exactly how to do it. Now, I think if there are better ways, I would still type out and build programs and run them and learn them, you know what I mean? [01:03:20] There might be better ways that are more Claude-informed as well. But I think it’s really important. I think when Boris says coding is solved, I think it just means we don’t get stuck in the same ways that we used to before. I think coding used to be this very high-variability thing where you’re like, oh, could this bug take a day or could it take two weeks? You have no idea sometimes. And I think on the whole, coding used to be in real terms something that was very rare for something to go well. [01:03:56] Very few people in the entire world could write software, and they were very, very rare. And even if you got them all together, there were so many other reasons why it wouldn’t work. And coding was one of the rarest things in the world where the chance of a software project going well was, on absolute terms, very low. And if you were hiring someone to make software for you for something that’s not a huge product, like if you’re hiring someone to make software for your car dealership, you are almost certainly not going to get the software you wanted. [01:04:31] You’re going to get essentially scammed, you know what I mean? Not because anyone was trying to scam you. It was just like, software is really, really hard and it could only be spent on the most important scalable things in the world. And now that coding is solved, I think what we mean is that you can use coding to do all these other things that we’ve not done before. But that’s not to say that that’s not a lot of work still. [01:04:56] It’s just not this incredibly rare, difficult thing that mostly just doesn’t work, and you have to spend, like, eight hours a day locked in to do well. Ryan: [01:05:07] It’s really insane. That shows the difference in expectation is when I used the right software. I would be shocked if it worked on the first try. I was like, whoa, wait, why is this working? And you expect to kind of bash your head against the wall a little bit and then it works, even if it’s just like you missed a semicolon or something like that. And now I almost have the flip expectation where when it doesn’t work, I’m like, wait, what, why, why did Claude. [01:05:34] What happened here? Usually I expect it to work almost the opposite, like on the first try. Thariq: [01:05:41] It’s crazy immediately. Yeah, I think humans get really used to abundance, right? There was this article someone shared recently about going through a modern apartment and talking about all the wonderful things that we have now that people could not have imagined before. Something that can play music on demand that’s suited for your mood. Before, you’d have to hire a musician to go write incredible music, right? [01:06:09] But I’d say, on the whole, probably more people are getting paid to make music now than ever before, right? And I think that music is reaching more people than ever before. And I think probably the same thing will happen with software, will happen with math, will happen with all of these things where, when you get abundance, people are like, great, I want more abundance. [01:06:30] I want my software and everything, you know. Like, I want my music everywhere, you know. Ryan: [01:06:34] So, yeah, one potential other data point from this conversation saying that maybe people should still be technical or learn how to code is, I think earlier in the conversation we talked about automating knowledge work, and you mentioned that people who are technical had kind of a leg up because they kind of understood how to coordinate Claude to do a variety of things, like you’re calling FFmpeg to automate some video editing. [01:07:01] And I don’t think someone who is not technical would have that thought. So it does seem like even in this case where models are doing a lot, there’s still so much value in Thariq: [01:07:12] Being technical, knowing how computers work, in the same way that probably the most technical CEOs are, like, the best CEOs are technical, like Zuckerberg, Elon, but they probably haven’t written a line of code truly in a long time. But they understand how systems work, they understand constraints and things like that. And that’s really, really important. And so even if all that work has changed, I think being technical is really, really important. 01:07:42 — Advice for his younger selfRyan: [01:07:42] And then last question for you is, if you could go back to when you just entered the industry and give yourself some advice, knowing what you know now, what would you say? Thariq: [01:07:52] They’re like kind of like two wolves, sort of. I think you have to believe in yourself. I think this is really important. And I think that at least when I joined the industry, it was rarer to believe in people when they were kind of younger. I think that was the whole point of Y Combinator or something was believing in young people early on to do really great things. [01:08:15] And so I think that, you know, even going back to the internship discussion we had earlier, right, I think that thinking of yourself not as someone who’s being trained to do something, but someone who can do something incredible right away, I think is really important. And I think I wish I had done bigger, bolder things that I’d written and shared about. [01:08:38] I think there were lots of ideas where I was like, wow. I think I had thought I had done original work that I wish maybe I’d even shared in some form, but maybe not in a form that survived the Internet, you know, and it wasn’t a goal of mine. And so I wish I’d sort of been bolder and done and shared some of this work. But at the same time, you also. [01:09:03] There is a lot to learn from people. And I think that when you’re young, you tend to fall. Either you’re not bold enough or you’re too bold and you don’t figure out what people have done before and figure out why this is not working, right? [01:09:29] And there’s this balance. And I think everyone has different failure modes, but I think I probably didn’t take enough advantage of mentors and people who had learned a lot. And I think I probably had to relearn a bunch of things as a result. So there’s probably not universal good advice, but just things to think about as you’re entering. Ryan: [01:09:53] Awesome. Well, thanks so much for your time, Thariq. Really appreciate it. Thariq: [01:09:56] Yeah, of course. Thanks, Ryan Peterman. It was fun.
|
%26stroke%3Dnone%26strokeWidth%3D3.6){kind=small}
Similar newsletters
There are other similar shared emails that you might be interested in: