What Is Your Job Now, Farhan Thawar | Compile 26

0:00My name is Farhan Thawar. I'm the head of engineering at Shopify, and I want to spend some time thinking through this question, which is with AI coming and doing so many parts of the jobs of engineers, I want to explore what is our job now? Because really, things have really changed, especially for engineering, but across all of R&D and even actually for other disciplines as well. And so I want to explore this question. But before we explore this question, I first want to take a little bit of a moment of silence. This tweet

0:26really hit me hard. This is the culmination of all of the software that we have come to use in all of our lives, including many of you, me too, that we wrote character by character, and it's amazing to think that everything up until now was written this way. So moment of silence, a little bit of crying maybe because it was how we did things in the past and not really how we're going to do things in the future. And I want to

0:53explore what has changed. And if you look at the SDLC, the software development life cycle, what you'll notice is that where we spend our time is moving. So if you look at the chart on the left, you'll see the majority of time was spent in coding. You of course, spend time planning and verifying and testing and maintaining, but a lot of the big bulk, that big blue box, was the coding step. And what's changed when you look at the right is that the coding part has changed dramatically because you're going to spend more time using tools to plan and analyze. You might be spending your time validating what's

1:26coming out of the AI tools, but that coding step is very different. And there's two kinds of things to think about in that coding step. There's what's on the screen there, which is like parallel coding. So this idea of I'm going to break my tasks down into subtasks, and then within those subtasks, I'm going to have agents act upon those, and then I come back and consolidate and do some kind of

1:45validation. But there's also this notion of sequential, very heavy like critique loops. This idea of, I'm going to really pair with one AI, I'm going to do something in a deep way, use an extra high or reasoning model. I'm going to have potentially another model come and interrogate that. But again, you're the one not necessarily writing the code. You are working with an AI agent, and you are trying to plan out how to build something for your end customers. And so things are changing, and how you spend your time is changing. Hence the question of like, what is our actual job? And it turns out your value just changes from the person who typed

2:21character by character all of those commands into your programming, your ID of choice and the programming language you chose, to these other things, taste, judgment. When should I build something? Why should I build something? What should I build? How do I think about the architecture of what I'm building? Companies famously think about things in different ways. At Shopify, for example, we have a monolith. We try to build things

2:44into the monolith, and we try not to break things down into sub microservices. Other companies might choose it differently. How does that fit into your workflow? But of course, understanding the problem, spending a lot of time thinking through problems with your customers, also thinking through the possible set of solutions. We have this line inside Shopify where we talk about when someone brings something to us, we might say, "That's cool, so it works. How did you choose this solution among the 10,000 possible right solutions? How did you land on this green path solution?" And then,

3:11of course, learning. A real part of building software and actually working with customers and inside your teams is the learning process. We actually have a funny story about this. Pre-LLMs had a pretty large team, about 50 engineers working on one of our projects, and they spent 18 months building out, in this case, like something for our

3:28merchants. And we were just about to launch it. We had a famous Tobi review. Tobi's our founder and CEO. And we walked through the architecture, we walked through everything we built. We showed it to him. He's like, "This is great. We should launch it." And right when we were walking out the door from the

3:42meetings, pre us being remote, he stopped and he said, "Actually, one question. If you could start over, how would you build it?" And the team kind of stopped and they're like, "Well..." And then somebody went up to the whiteboard and said, "Well, knowing everything I know now, we would've built it this way." And he described a completely different and simpler architecture. And Tobi said, "Well, why

4:01don't you build that?" And literally what happened was we pivoted, and he said, "Just delete what you did and start over." Because what he was trying to show us was the learning was the collateral, not the code. And so what we did was we deleted that. We didn't actually delete the code because that's super hard to do. But we came up with this way to actually use what we learned, meaning we were allowed to look at that code but not cut and paste it, because that is the natural tendency. And we rebuilt the system in three months. And what happened was we had a much simpler,

4:29elegant solution because the learning was the collateral, not the code. And so what's happening now with the changes in AI in terms of workflow and SDLC is the bottleneck. I don't know if folks have read this book. It's a very good book, a fictional book about a guy in a factory, and he's trying to optimize various stages

4:45in the factory. And what happens actually is that he goes to fix a bottleneck, and what happens there is that he solves the bottleneck there, and then he realizes, "Oh, my God, I'm looking at this workflow, and another bottleneck has appeared." And so then he goes and fixes that bottleneck. And guess what? Another bottleneck appears. And so what's happening is he is optimizing the factory, and he is finding things that are bottlenecks and then turning them into not a bottleneck, and

5:09then he finds something else. It's exactly what's happening right now. The AI step of writing the code is moving the bottleneck to other parts of the SDLC. And so as you're spending time planning or validating, or in this case writing code, your bottleneck is going to move, and that's fine. You're just going to find out how to resolve that bottleneck. And guess what? You'll find another bottleneck. And the same thing's going to happen over and over. But it's a very good book to read. And again, it's going to go back to what we saw in the last slide, is your taste and judgment, and you still bring a lot of value to the process. It's

5:39just a different bottleneck. And so why do we care at Shopify? Like, why am I talking about the SDLC? Why am I talking about AI? Well, it turns out we actually power a lot of the commerce infrastructure all over the world. We spend a lot of time thinking through how to build things in a way such that people can build on top of us. One mantra we have at Shopify is we always try to build infrastructure. So one example If I could build a feature in two weeks, or I could build infrastructure in two months that allows me to build that same feature in one hour,

6:10I will always choose the latter. That means we try to focus on infra as the way to enable our developers and our ecosystem of developers to build on top of our infrastructure. And the reason we do that is because we believe that it's unclear what's going to happen in the future, and if we build the infra, again, I can build that feature in an hour on top of it. Who

6:30knows what else other people can build on top of it? So that's how we're focusing. And now what's funny is I gave you that example, but with LLMs, it might be possible not to have to make that trade-off anymore. If I have my problem defined well enough, do I have to actually make a trade-off between two weeks and two months? Maybe they're about the same because the clanker, which is a term that Toby likes to use, can write all the code. I don't have to think through that trade-off of two weeks versus two months. And here's

6:55some stats just to show you that we are at scale. We try to spend a lot of time optimizing our infrastructure as well. Performance matters a lot. Simplicity matters a lot. Resiliency matters a lot. Availability matters a lot. And you can still, of course, get all of these things using AI to write your code. It just means, again, the place where you spend your time is going to move. Now, our journey in AI has been going on for a while. We were the first users of GitHub Copilot in 2021. That's a year before ChatGPT. I mostly bullied the CEO of GitHub to give it to us,

7:24and that allowed us to be in this age of autocomplete, if you folks remember that. Where I would start writing a line of code and then it would autocomplete the remaining line, or I would write a comment inside of a file and it would just fill out a function. This idea of pairing with the AI. This ability to go back and forth and let's try to build something together. We launched features using ChatGPT right away, and this was really the couple of years of the AI centaur phase where you have a brain and an LLM and you

7:51bring those two to work, and together you build something. And of course, what happened in 2025, last year? Toby dropped what we call the tweet heard around the world, which is that AI is going to be a baseline expectation for employees at Shopify. What was funny about this tweet was not that it was first an internal memo and then it became a tweet, was that CTOs and CEOs would text me after this came out and

8:14share with me their own version of this same message inside their companies. Because what they wanted people to understand was that we want you to understand how to use this tool. We want you to be AI reflexive. What does that mean? AI reflexive means we want the distance that you travel between running into a problem and reaching for AI to be very small. How quickly can you

8:36reach for AI? How long does it take you to get stopped and then go, "Oh, hold on, let me pull this in, in a way that I can quickly move through AI." And so we spent time thinking about AI reflexivity at Shopify. We wrote articles. We started to share different ways in which companies, including ours, could use it in various disciplines. Not just engineering, not just product, not just in

8:58R&D, but across the company. And we had lots of examples of how to do this. One of the main ways I brought AI reflexivity to Shopify was via Cursor. We deployed Cursor in 2025, and I quickly ran out of Cursor licenses. We're a company about 8,000 people. I bought 1,500 licenses, and in the first week, I ran out of all of those licenses. And I think the most interesting thing that I learned, and also I shared with

9:23Cursor, was that it wasn't the typical disciplines that were using AI. So I thought right away it would be engineers, product, data scientists, maybe designers. Instead, what I saw was finance, HR, sales, marketing. They were using Cursor as a way for them to get a window into these agents. Even though they weren't looking at the code,

9:46they were looking at using this as a way to interact with their back-end LLM. And so it was really interesting to me to see this happening, and of course, I procured more licenses and more licenses until, by the way, almost all of Shopify was using these tools. Today, we have a huge set of tools, including Cursor, that people use. They use Pi, and they use Claude Code, and they use Codex, and we even have an internal tool called River that we use. It's like an agentic substrate across the whole company that you can ask it questions. It can write

10:15code for you. But it just shows you that people have choice, and our first step in getting to that AI reflexive moment was literally just dropping Cursor. That line shows you when the internal memo was dropped. So for those of you thinking through in your companies, can a mandate like this change behavior? Literally, Toby's memo, and you see everything go up from there. It made a huge change in how Shopify thinks about things. Not only did we see actually Cursor usage and people adopting these

10:41tools, we saw real use cases. The support team built a tool called Scout, which allows you literally to ask it questions about the feedback we were getting from our support teams, and now our product management team uses it all the time. You can go in any day and see what are the top merchant frustrations. We had customer success teams building out monthly business reviews and quarterly business reviews using Cursor, and it was

11:01a real way to get information and insight to their customers. Finance built forecasting tools. So it's really cool for us to see how not just engineers were using what we had built. The other thing I really wanted to change was the culture in the company at the same time. In 2024, we had 75 interns at Shopify, and in 2025 and in 2026, we have 1,000.

11:25The reason to bring the interns for work was not for charity. Some people are like, "Oh, it's community service. Bring interns, and it's good for them, and it's a good experience." It was the opposite for us. We wanted them to come in and teach us how to work. Think about the interns and the folks in college these days in early talent. What

11:42percentage of their life have they been with AI? This year, 2026, the graduating class had their entire college life having ChatGPT or another tool. And so these folks, we wanted them to come to our offices and question everything about how we work. Why do things work this way? We wanted their hunger, their intensity. We wanted

12:00to change the culture in the company. So a thousand interns came in. We ended up hiring a lot of them as well to come work full-time with us. But it's a great way to kickstart your company and make a cultural change. Not just the mandate of AI being reflexive, but also changing the culture of the types of people that came into your company. And again, the key part for me here, this is literally my tweet,

12:19was the AI centaur moniker. The idea of human plus LLM together can build something better. And I really like this term, AI centaur. Like I mentioned, we had it for a few years, 2021 to 2024, 2025-ish, and unfortunately, it didn't last as long as I wanted. It was this amazing time when we could pair with the AI and that the AI still really needed us to talk about and

12:46give it advice on code. And, as you know, in December of 2025, it all went away. Why? Well, people call it the Opus 4.5 moment or GPT 5.2 moment. This is where a lot of the world's top engineers during the Christmas break said, "I think the LLM is better at coding than I am." And so this whole notion, and this is again the ethos of an engineer and being like, "Oh my God, my job was to write code and everything about my life and my work is about typing in character by character the thing that the machine will turn into machine code and execute for me,"

13:23to now I'm going to be the AI steering person because when the LLM is better at writing code than you, you should focus the bottleneck, which used to be writing code, to somewhere else in the pipeline. And so this was the big moment for us. And this is again, the clanker versus human. This is where you have to really

13:41step back and introspect to yourself. Where do I want to spend my time? If the AI is better at writing code, should you write code anymore? It's an open question. Are there times when maybe there's something specific that you're writing that the LLM won't be good at, that you have to write code? Potentially. But I would contend 90-plus percent of the code now at a lot of companies should be written by AI because it's just better than you are. And in 2026, right after that December 2025

14:08moment, we started changing also how we think about expectations of the company. The word token maxing became a noun because what's happening is people are just using tokens over and over. And because we had become AI reflexive at the beginning, we wanted to move away from reflexivity because we had the whole company now using AI to AI leverage. This ability to not only use AI for your work and to remove your toil and for you to focus on your area that you care about and that you can bring human value and judgment to,

14:36but also this notion of how can I brag about how lazy I am? This ability to be like, "You know what? I just built this in five minutes. It would've taken me five months." And so we wanted to role model, and we wanted to show people what's possible. We, of course, like everyone else, had a LLM leaderboard. This ability to show everybody, "Hey, look how many tokens I used, and I'm in the top 10." And we moved away from that to a usage dashboard, which really, it does still show you what your token spend is and how you can gauge yourself against your peers, but it's not focused on being on the

15:06leaderboard anymore. It's not focused on being in the top 10. It's focused about providing value. And what's interesting about it is you not only can see, of course, who's using the most tokens or what disciplines are using the most tokens, or what seniority or manager versus IC or even area of the world they live in, but also who's using the most expensive tokens. Something interesting is this idea of, hey, these people are doing actual reasoning, and the tokens they use are more expensive per million tokens versus those people who are just using lots of tokens. We don't have

15:32any limits of tokens at Shopify. We do have circuit breakers. A circuit breaker really is just something to find whether you have a runaway agent, and we've seen this happen. You might try to introspect some large piece of code or might give a problem that the agent might go off in a weird tangent, and what'll happen is you'll get stopped. You'll get a Slack message that says, "Hey, we've stopped your agent. You used $X today. Are you sure you want to keep going?" And people are like, "Yep, I want to keep going," and then we don't block you. You might say, "Nope, I don't want to keep going because actually you're right. I didn't think that

16:03this was going to take this much money or this amount of time," and I can stop it. But outside of that, we're still in this mode of opening the tools and letting people use whatever they want to accomplish their goals. Some things haven't changed, by the way, as we move to AI. I talked about some of the things that did change. This is something that hadn't. Parkinson's Law, one of my favorite laws, which is basically the amount of time you give

16:23something is how long it's going to take. If I ask you for something by Friday, you'll give it to me by Friday. If I ask you for something for next Friday, you'll give it to me next Friday. And now what's amazing about Parkinson's Law and AI is that everything has changed because the roadmap is no longer going to be six months. It's typically be like, why can't you finish it this month? Why can't you finish it this week? Why can't you finish it today? And this idea of prototyping quickly and then taking that prototype and maybe showing something to a customer very early on because you've got

16:48these clankers writing the code for you. It's not as hard as you think, and you should really look at Parkinson's Law again and pull all those roadmaps in. We have this saying that we can finally see the end of the roadmap at Shopify now because we've got these tools. What else is not changing? Learning. I talked about this before. Everything that we focus on is to learn as much as possible. The code is not the collateral. The learning is the collateral. You want to make sure that you are actively asking your teams, and you know how some people talk about

17:13shipping every week? We talk about learning every week. What is it that you learned this week? What is unintuitive? What is a secret that you believe that others don't because you looked at the data, you've tried and prototyped something, you put something in front of a customer? What is it that you've learned that allows you then to make a different decision next week? This hasn't changed. I love this picture. This is what I got when I asked the AI to create a picture for pair programming. Makes no sense, but I think it's funny because literally it's like, this is what pair programming is to me. I'm like, well,

17:38not on one keyboard, but on multiple keyboards. But pair programming hasn't changed. There's going to be things that you learn with another human in front of a computer, along with an LLM, that you wouldn't learn with an LLM alone. And yes, you can use these clankers to write the code, and you're going to learn some things, but having another smart human and working together at the planning stage and at the validation stage, and of course the coding stage, will allow the learning to increase. And again, don't forget,

18:03learning is the goal. This is a real picture of pair programming. Two people, one computer, typically could be two monitors and two keyboards, but the idea is two people working together against the same goal. And yes, in today's parlance, they will have an LLM also. This is one of my favorite pair programming quotes, not to make this talk about pair programming,

18:21but the idea is that it's not lines of code. It's never been lines of code. Anytime I talk to executives, they're like, "Wait a sec, if I get two engineers, they're going to write less." I'm like, "Yeah, hopefully even less than that." The whole point is not lines of code. And I think it's funny when people look at

18:34token maxing or lines of code to try to figure out if teams are productive. And so if you can't use those, what can you use? So we have a bunch of things that we've noticed over time by looking at the Shopify ecosystem to see what we are noticing as things that potentially are interesting artifacts, but none of them, even the whole set, could be used to identify whether we're efficient or not. PRs per engineer are up. That's probably not a

19:01surprise. I think everyone's seeing that across the industry. We're seeing the complexity of PRs going up. So each PR, yes, the numbers are going up, but the complexity of each one is also going up. We're noticing the project duration is going down. So we have a product management system, and we can see, based on no other changes, that actually the duration of projects is shortening, so we're attributing that to AI as well. And then the more importantly, the ambition of projects is going up. The things people are attempting, the things they're trying to bring to our customers is going up as well, and it's actually causing us to be more ambitious in how we think about the problem. We

19:30still like to do weekly demos. We think this is a great way. If you're always wondering, when I talk to executives, like, "What's the best way to gauge engineering velocity?" Weekly demos. It's the best way to see what's going out to your customers. And then don't confuse the map with the territory. This happens to me all the

19:43time. An executive vibe codes something and shows it to you, like, "Look how easy it is. I built this thing," and, "Why can't you just deploy this production?" A prototype is not production. I see this all the time. Don't forget, I have a CEO who codes. He will say the same thing to me, "Wait a sec, I just built this thing in five minutes. Why did it take the team a month?" I'm like, "Because the prototype

20:01is not the production level quality of code." Still true, and has not changed, but prototyping is an amazing way to get feedback and to try things out. We try really, really hard to delete the prototype code, or don't use it, because it's really a green pathing exploration exercise versus actually the code you can use in production. Here's an example. I had an intern delete six lines of code

20:24and save over $600,000 per year in our infrastructure. So tell me which of those metrics on the previous slide would have showed me that this intern is awesome. None of them. I actually don't even know, but I'm pretty sure this intern did many more things that term instead of this, and it would've been fine if they did this one thing. So there's really no way to manage by spreadsheets. So if you think you're going to try to manage by spreadsheet because you have AI, good luck to you. So I'm going to go through five things that we talk about at Shopify as how we work, and so people can get a sense, and I'd love to talk to folks

20:52after about what they're seeing. One, model selection. We still only allow our engineers to use the largest, most expensive models. We let them only use Opus 4.5 or GPT-5.5, or Gemini 3.5. We don't let them use a smaller model because we believe that the human time is worth more than the clanker time. What that means is, if a human used a smaller model and a small bug was introduced, it would take them many, many hours to find it, versus if they just used the bigger model. So as the bigger models come out, we use them. We don't let

21:22people use smaller models, at least in engineering. Two, the bottleneck is code review. You probably already thought about this when I came up with that bottleneck slide. Lots of code is being generated. How do you review it all? Let me show you the four scariest letters in the human language. Every fucking PR says this thing, and then it might still have a problem in it. It might still cause a line side incident. It's insane. And so if you thought your current process is working, and you're like, "I can't let an AI look at my code," look at these

21:49letters. Your humans were not looking at the code. They were not good at this. So you should do something else. And so we use accounts, and I'll show you a slide on the Council of LLMs, but we use lots of other things, using AI tools to actually help figure out whether these code artifacts should go to production or not. Is it perfect? Of course not. Were

22:10the humans perfect? Of course not. I have people complaining to me now who say, "Oh my god, it takes an hour for the AI LLM to review my code." I'm like, "Before the LLM, didn't it take 24 hours or 48 hours for a human to give me the LGTM?" Who cares? The LLM is better. The LLM is going to be more accurate. Is it 100% accurate? No. Is it better than

22:29humans? Yes. Here's an example of what a council of LLMs looks like. This is fictional, but the idea is that we have different models having different tasks, and they look at different parts of the code as it goes through and look for different things, like you can see, accessibility here. They're looking for other things, and we use all of these judges to be like, "Should this code go to production or not? Should I send it back with some commentary?" Responsibility. We do not let AI take responsibility at Shopify. You get to work with an LLM. You get to have it write as much code as you want. You, of course, do validation, but

23:03your name goes on the PR. You might also tag your LLM. Cool. But it is not about the LLM, it is about you. Responsibility can be shared, but it cannot be given away. Your name on the PR, your PR going to production. This one is an interesting one, how to think about hiring. The shrug emoji there is because we have no idea how to hire for AI. I don't think anybody does. I don't even know how-- Actually, Cursor famously didn't allow you to use Cursor for your interviews, so I don't know what Cursor's doing now, but we are definitely still trying to figure this out. But I like this model, by the

23:33way, which is an interesting model to think through the problem. I went to Waterloo. My first year, I did a math degree. We were not allowed to use a calculator, so the whole first year was no calculator, and then second year, we got a calculator. It forced me to learn everything by hand. Everybody learned everything by hand, and then you can introduce the calculator. So AI is kind of similar. If we want people to understand the underlying parts of AI, we want them to be able to work without

23:54AI. So that's number one. Giving them a problem they can't use AI on. Number two, AI optional. So maybe I can't

24:03do it by hand, but maybe I can use AI. So you can optionally pull it in if you want. And then lastly, AI mandatory. I'm going to give you a problem so large, not enough time, and now you have to wield this tool. And I think when you look across all three of those, you get a good sense of if somebody is good across all three of those. The thing it'll miss is like the savants. This is like the chess player who just makes a move and he says it feels good. There's going to be people like that who can just use the AI and be like, "I

24:27don't understand code, but I can wield the tool in a way that gets me amazing results." And then lastly, I think the funniest thing from executives is, "Oh, can't I make my dev team smaller?" This is like the funniest thing I hear. Like, "Oh, we have 100 engineers. What if we just had 10?" I'm like, that's so fucking unambitious. We think about the other way. I'm like, "We have 3,000 engineers. Why can't they

24:46act like 100,000?" That's literally the line we use. Because that is more ambitious. You can do more. Jevons paradox, you make something cheaper, you make something available, more people will use it. We're trying to solve the problem of entrepreneurship. Why aren't there more entrepreneurs? You think we're going to try to shrink? No, we think everyone can be more productive. There's even a funny blog post that came out. Somebody wrote this. The AI setup behind Shopify is 23,000 engineers. I'm like, I'm a quarter of the way there. It feels like we have 23,000 engineers to somebody. That's awesome. We only have 3,000. I want somebody to write the

25:16article that says, the power behind Shopify is 100,000 engineers. All right, lastly, just to close. So some things have changed and some things haven't. The clankers will write and review code. Get over it. This is what's happening. You should try to embrace it. You will spend more time on other parts of the ecosystem, of the SDLC. You're going

25:36to spend time on planning, you're going to spend time on validation. And you might change your seniority mix. I just introduced 1,000 interns. And by the way, I convinced Cloudflare to do 1,000 interns. And then I saw Matt Garman at AWS hire 11,000 interns this year. Everything's changing across seniorities. You might decide differently. You might decide to hire more mid-level. You might

25:52decide to hire more senior. And then what's the same? Taste and judgment. You're still going to have to care about taste and judgment, what goes out to your users, and you're going to have more time to spend on it because you can go deeper into the problem. It still remains hard to gauge engineering performance. That's not going to change. You're not going to be able to manage by spreadsheet. You're not going to be able to all of a sudden be like, "Hey, we figured out the formula." Like for salespeople, it's just how much they can sell. Like engineers, it's how many

26:16what? I don't think there is a metric. And finally, and importantly, learning still remains the goal. So for those thinking about running engineering teams, don't look at the collateral. It's not about the code, it's not about shipping. It's like, how quickly are you learning? Because you can use these tools to build whatever you want as quickly as you want.

26:35Thank you very much.