Daniel Rock: What Automation Means for How We Organize Jobs

Ben: What happens to a job when its tasks are exposed to AI? And why does the order in which tasks get automated matter just as much as which tasks get automated at all? My guest today is Daniel Rock, an assistant professor at the Wharton School and a co-founder of WorkHelix. His research focuses on how technology changes the nature of work within firms and the economy at large. Here's our talk.

Ben: Welcome to The Economics of Work. I'm excited to welcome Daniel Rock, assistant professor at Penn and co-founder of WorkHelix. We'll talk more about WorkHelix, but most importantly, he's the person I call when I want to work through a half-baked idea. Daniel, welcome to the show.

Daniel: Thanks for having me, Ben. Great to talk with you, man.

00:35 What AI exposure really means

Ben: Let's start with exposure, AI exposure. What exactly is exposure? How should we think about it?

Daniel: AI exposure is a very limited thing. The first question is: what's exposed? It could be a task, a job, or a system.

Ben: Jobs can be exposed? What would that even mean? I understand the exposure of tasks; that makes sense. Is the exposure of a job really a meaningful concept?

Daniel: It can be. Exposure for a task means the task has the potential to be changed with AI. You can pick any technology and ask whether a task is exposed to it: could it be changed by that technology? You just need a decent way of generating the measure. The exposure of a job, similarly, is whether the job could be changed with AI. I agree with you that's a less meaningful concept if you can't point to what it means for the job to change, other than through the tasks underneath it. But you might have a summary measure at the job level that says there's a lot this person should be doing with AI. To the extent there's someone with agency making choices about how they do their work, they'll pick certain things to do with AI and decide how to allocate their time across tasks.

Exposure is often confused with automation, and I often have to correct people: these exposure scores, the ones I've worked on and the ones others have worked on, don't correspond to automation on their own. That kind of measure is much more difficult to create, if it's possible at all.

02:35 Can granular exposure mean automation?

Ben: Let me take the pro-automation position, just to play with it. I totally get that exposure at an aggregate level, like a job, doesn't translate into automation of that job. But say you had tasks at a very, very granular level. Could you interpret exposure as automation then? Even if a task is supported by AI, isn't that really automating one little component and complementing the rest? Could we interpret exposure as automation if it were done at a granular enough level?

Daniel: Okay. This is where what you're rating and what exposure means are jointly determined and very difficult to separate. I agree with what you said, but I want to be specific about how. If we keep blasting a task apart into more and more subtasks, to the point where you're down to the studs, "move finger to touch key," then yes, if you're talking about exposure to, say, a typing robot, we're talking about automation. That's what roboticists often have to do: figure out the really precise thing the machine will have to do.

But at the level of a task taxonomy, like the one you all have made, or O*NET, a task is an aggregate of a bunch of those "move finger to touch keyboard" pieces. Once it's a mixture, it's what the posthumanist sociology crew might call an assemblage. I'll shout out David Holtz and Avi Collis, who will appreciate that.

Ben: Ooh, I like that word. I'm going to copy "assemblage."

Daniel: There's an old idea, not to get too deep into it, that an army is not a pile of soldiers, a pile of uniforms, and a pile of tanks. It's a bunch of people operating together with affordances and constraints, as I learned in grad school. So once you're at an aggregated level, you've got a system again, and at that point it's not automation, or at least not clearly.

Ben: I really like this idea of assemblage. There are a few papers on the nature of assembly, if we want to think about it that way, that I want to get your thoughts on.

Daniel: Not where I expected to go today, but it's fun.

05:42 How granular should tasks be?

Ben: It's a cool subtopic. So say we have these super-micro subtasks like "move finger." That's clearly not useful as the atomic unit of a task.

Daniel: Right.

Ben: So if we want to manage tasks and how they fit together, what's the right granularity? Here are two ways I'd think about it. One is what technology can affect wholesale: if AI affects part of something and not the other part, that by itself is enough to say that workflow, that set of tasks, should be split. Another is weak bundles and strong bundles: if some tasks so obviously belong together that unbundling them would be very costly, they should stay together, and we should think of tasks as distinct only insofar as unbundling is too costly. What do you make of that? Is there a right number of tasks in the world?

Daniel: No. I'm increasingly coming around to the systems-based view that Tim Bresnahan has put forth, along with the folks at Toronto, Kristina McElheran, Avi Goldfarb, Ajay Agrawal, Joshua Gans, the usual suspects to some degree. I'm starting to think that combining organizational economics with task determination, using the org econ toolkit to understand how different types of jobs and tasks fit together, is where all the interesting action is.

There are macro models, like the task-based model, or even ordinary labor-demand task models with Cobb-Douglas or CES structure, and I think those are really useful. Papers like Autor, Levy, and Murnane are classics that kick off a whole literature and get you a lot of understanding of different trade-offs. But they fall short in certain places. If I augment someone and they do the job of 10 people, does that mean we hire more people or fewer? You can't answer that with a task-based approach alone; you need more. Likewise, if I automate part of a weak-bundled job and people start focusing on the strong-bundled residual, like the relational work Alex Imas or Luis Garicano have been writing about recently, automation or augmentation could lead to really big shifts in labor demand in either direction, or barely any shift at all. Now it's the organizational context driving the differences, and that's where the systems view really comes in.

09:27 The chaining tasks paper

Daniel: There's a paper I love that came out recently by Mert Demirer, John Horton, Nicole Immorlica-

Ben: Task chaining?

Daniel: Yeah, "chaining tasks." Peyman Shahidi just presented it at our Wharton Future of Work conference and did a fantastic job. It completely changed how I think about things.

Ben: I also love that paper. I think it's the first one that shows not only that the aggregation function, from tasks to jobs, matters, but also that the sequence determines how we should think about aggregating or assembling them.

Daniel: Right. And there's this really neat idea that if I can put multiple AI-driven tasks in a row, maybe my validation step can cover all of them, and I only pay the fixed cost of validating once. It resonated so much with everything I'm doing with Codex, Claude Code, Gemini CLI. I'm running all of them at once and having them check each other's work, and there's a cognitive overhead to checking each stage, as opposed to having a coherent testing strategy that runs at the end. If you can figure out that coherent testing strategy, you just saved yourself hours of time on something that's already been cut from months to a couple of days. Maybe I'm being greedy, but I don't just want my months cut to days. I want my days cut to hours.

Ben: There's no shortage of stuff to do.

Daniel: Absolutely. I love that paper, and my guess is there's going to be a series of papers, along with the weak bundle, strong bundle paper, establishing a new wave of producer theory that blends in org econ insights. Another great example is Enrique Ide and Eduard Talamàs, who have a series of papers, mostly with each other, though they're also writing some individually, that fit in this literature. I think it's a new labor and org econ hybrid that's a really exciting area of research.

11:51 Are handoffs a cost or a benefit?

Ben: It sounds very exciting. My critique of the task-chaining idea, and I've mentioned this to Peyman and John Horton, so I'm not throwing shade, is this. I'm sympathetic to the idea that clustering automatable things together lets you modularize and offload them. Say you have 10 tasks. If you offload tasks 2, 4, 6, and 8, there's a lot more tracking and human overhead than if you automate 4, 5, 6, and 7. But I'm less convinced that the human involvement is purely a cost. If you're checking in on steps 2, 4, 6, and 8, and you have these handoff costs, there are also handoff benefits that could be interesting.

Daniel: Tell me about that. Handoffs are usually a pain.

Ben: Obviously it depends on the workflow, and there are some handoffs I really don't like. But if I'm building a statistical model, I really like being able to trace exactly what it's doing at each step, to take it apart along the way, see where it is at some intermediate step, and check that it's behaving. If it's misbehaving, I can say, "This step is broken." If it's behaving, I'm ready to move on. Even though it's totally unnecessary, since you could throw everything into a complex model and it'll just work, I personally really like breaking a model into bits, into different parts of the sequence, to understand it. Then explaining becomes easier, and when it misbehaves, which it always does, you know where. Everyone has different styles of work, but I think that's a productive one.

14:23 Learning while you build

Daniel: I think you bring up a really interesting and valuable point, and it's silent in the chaining tasks model, but that's sort of a different paper. Any work process serves at least two functions for knowledge workers. One, of course, is getting the work done. The other is a process of generating knowledge, judgment, and taste. Lump it all into human capital.

I'll shout out your data here. Right now, as we've discussed, I'm fine-tuning large language models with Revelio job postings data.

Ben: Nice.

Daniel: We're going to open-source them once they're ready; they're encoders. One of the things we can show is that contrastive loss is really important. It gets you much better, much more meaningful embeddings.

15:27 Contrastive loss and better embeddings

Ben: What do you mean by contrastive loss?

Daniel: There's the initial fine-tuning step: one thing we did was fine-tune ModernBERT. Downstream, we push a job posting through ModernBERT and get a set of vectors, embeddings. How do we evaluate whether those vectors picked up job content? One way is to look at the Revelio taxonomy, say at the K250 level, I think, and see whether they predict the right tag. Or we look at whether they predict the right O*NET tag. Or we predict the salary and look at the R-squared. Those are three different evaluation tasks.

You can stop at that fine-tuning step, or you can take another one. Say I submit a query for "dredge operator," and I have text that goes with "dredge operator" from a posting. That's a positive pair. But if I see "dredge operator" next to a bunch of content that has nothing to do with it, or that's very close but clearly not it, those are negative examples, and I want to push those things away from each other in the space. That's contrastive loss.

Ben: Yeah.

Daniel: And it works way better. Why? Kawin Ethayarajh, who's at UChicago, has a paper from 2019 in EMNLP showing that these embeddings are what you'd call anisotropic: the space is a little warped, and distances aren't maintained. BERT has anisotropic embeddings. If you had a recipe space, distances between recipes in BERT space might be consistent, and distances between jobs might be consistent, but if you try to compare distances between recipes and distances between jobs, the geometry is really strange.

Ben: So you can't do the "king minus man plus woman equals queen" algebra? Have you ever been able to do that, or has it always been kind of a lie?

Daniel: You can do it, but you have to introduce some sort of regularization of the space.

Ben: So you can linearize it somehow, by aligning to something.

Daniel: Kawin's paper has some suggestions, and contrastive loss also starts to solve it, which he and others have pointed out. But to get back to the original point, since it's very easy to get me ranting about embeddings-

Ben: Always a fun rant.

Daniel: Why am I learning from this? As we're training these things, I'm picking up judgment with my teammates: what will work for this problem, where it'll break down, what kinds of mistakes it'll make. That will be useful for another project later, or for having intuition about how to fix things or adapt them to better use cases. I don't need that to do this task. I could stick it in an auto-research tool and say, "Build a good predictive model of this." The chaining tasks paper covers that, but it doesn't cover what I lose by not introducing that verification breakdown. You have to make that trade-off. But whatever: Mert, John, Peyman, Nicole, the whole team can go build another paper on top of this one.

Ben: Totally. What I like so much about the paper is how extendable it is. You have a model where sequence matters in a very specific way, and you could have another model where sequence matters in a very different way.

Daniel: I don't want to forget Brendan Lucier.

Ben: What?

Daniel: Brendan Lucier, the one author I forgot to mention.

20:19 Why are tasks bundled into jobs?

Ben: This idea of bringing org econ into the space is so exciting. You told me a story years ago about your conversation with Joe Stiglitz.

Daniel: Did I tell you that story?

Ben: Yeah. What was that story exactly?

Daniel: This is one of those highlights of a grad student's life. There was a lunch at the AEA annual meeting, the ASSA, in Philadelphia, and we were at Maggiano's of all places, to discuss AI and the economy broadly. I sat down, and there was an empty seat next to me. Joe Stiglitz had been invited, which I didn't know, but he was late. Of course, if you're going to get stuck next to the grad student, the way to do it is to be late. I like sitting next to grad students, and maybe Joe enjoyed the conversation too.

I described what I was working on, thinking about tasks and bundles of tasks as jobs, and he asked a question I just didn't have an answer for at the time, but I thought it was so profound and useful: "Why are tasks bundled together into a job in the first place? What creates those bundles?" You can hand-wave and say coordination costs, the boundary of the job, transaction cost economics, and so on. But I didn't have a good way to operationalize that, certainly not back then. I think the recent paper by Luis Garicano and his co-authors starts to get much closer, and it's really cool. But that sent me down a rabbit hole for a while, thinking about the task model and where it is and isn't useful. Sometimes a chance encounter over Italian food can lead you somewhere fun.

22:08 Will we ever explain how jobs form?

Ben: Do you think that in five years, we as a discipline will have a really good answer to that question? If someone asks how work gets determined, what process results in a job, will we be able to understand that?

Daniel: I think people will make progress, but I don't think there will be a convincing, be-all, end-all answer. The reason, and it's a little amorphous, is that jobs are equilibrium objects in their own right. They're negotiated, a kind of supply-and-demand equilibrium. At a high level, we settle on names for broad bundles of tasks as jobs, so people can say, "This is what I do," if someone asks.

Ben: Yeah.

Daniel: Then there's what you really do, like that old meme, "What my mom thinks I do" versus "What I actually do." I love that meme; I wish they'd bring it back. What someone actually does every day comes out of something like Nash bargaining over what people like and what they get paid for, coordination costs, all of that. So you could write down something that sets a job boundary in theory. But when it comes to understanding what has happened and predicting how work will change, ultimately it's a mixture of tastes, skills, and the company's needs, and I think that's too broad a set of things to model perfectly.

Where I think there will be a lot of progress, and what's really interesting, is how you aggregate up from whatever that Nash bargaining is doing, or whatever model people use, to the aggregate "this is what I tell people I do," with education in there too. If you can crack that mapping, how things get categorized and why, that's why I love your book on taxonomies. Taxonomies are a big piece of this. They're objects that impose structure on the world. The map becomes the terrain a little bit.

Ben: That second part sounds a little easier to me, because people will presumably say whatever is most descriptive, and that shows up on the internet. And this idea of a job as an object that results from a bargaining process sounds like a really good start.

25:16 How work gets defined at a startup

Ben: Let me ask you: you're also a co-founder at WorkHelix. You're making stuff for the world. I want to hear what you all are doing there, but even before that: it's a company, and you work with people to make things. How do you think work gets determined within your company?

Daniel: Even there, there are roles and responsibilities, things we try to do in streamlined ways, processes. But startups are a very strange place to study this, because there's so much open connectivity between what people do. I'm sure you know this from Revelio in the early days versus now. In the beginning, it's hard to say this person can only do this or should focus on that, because so much needs to get done that it's hot potato all over the place. What you'd like to do is solidify and streamline things so people can specialize and play to their strengths.

So an early-stage company is a harder place to understand the solidified version, but it's a very good place to learn the process of phase transition, from "everything, all the time" to "oh, this is my job." I think that's what a lot of people who like startups enjoy: having a more general-purpose role, being asked to do harder things or first-time things. But gradually, processes get solidified, and you start doing the same things as you find product-market fit. Ideally, you find product-market fit, and then customers and the product start to govern what needs to be done. Once you know that, you can specialize roles, with a little flexibility to catch latent demand, as Boris Cherny at Anthropic would call it. They apparently see a lot of latent demand in Claude Code, and they say, "This is what people are doing; we need to build features for it." If you can get into that flywheel of collecting information and adjusting, you've got a more solidified structure for innovation.

At WorkHelix, we're trying to help organizations make AI go better broadly: optimize what's going well and expand it, learn where it's not going well, a bit like change-management software, but also understand how work is changing. That's a pretty broad set of things to work on. In practice, we show people the value of the work that's going through, and the processes we know are valuable, we just keep repeating.

28:30 What academics and founders can learn from each other

Ben: Having a foot in startup land as an entrepreneur and a foot in academia, what do you think entrepreneurs can learn from academics, and what can academics learn from entrepreneurs?

Daniel: Oh boy. I have to organize my thoughts on the fly; that's a wonderful question. I've heard something from academics that has a grain of truth, though there are important places where I disagree: that being an academic is like being an entrepreneur who starts lots of little companies, and those companies are papers. In some sense that's true. The analog to product-market fit is finding a paper that's high impact but also fits within a literature, so it's useful to other people. If you're not thinking about what would be useful to your research community, even if the community doesn't realize it yet, and you're not trying to educate people about what you're learning, it falls on deaf ears, which isn't good. So there's a demand side. And you have to be self-motivated to generate the work, and really care about the outcomes and making the quality as good as possible. So I see an analog there.

But I think a startup as a company, as opposed to a paper, is a much more difficult object, way tougher than any paper. You can have an entrepreneurial mindset, but entering a competitive field and trying to discover something people will pay you for, something they really need to get their work done, or to make something useful happen in their organization if you're B2B, or useful or at least entertaining in their lives on the consumer side, is much harder. If you write a paper and nobody reads it, it's a bummer, but the cost is pretty limited. You might get a publication with a couple of citations. Oh well. If you start a company and nobody wants it, that's much more costly, and you have to be fanatical about wanting that thing to exist. The stakes are so much bigger, and the requirements to meet them are much higher.

What entrepreneurs can maybe learn from academics: a lot of academics take a portfolio approach to their projects. They see what's working and what's not. That experimentation gene is helpful for startups, and ironically, there's a lot of academic literature on this. It's hard in some places to separate signal from noise, and that's what you have to optimize for in the early days of a startup: how do I tell genuine signal from noise? It's not easy. So entrepreneurs can learn to be scientific, to really test hypotheses, and then to be flexible about what evidence means, because you won't have statistically large samples for most of what you're doing. You'll have four or five examples, and you have to reason from them. That scientific method is useful from an academic-startup blend.

Ben: That makes sense, and I like that idea. As an entrepreneur, I find it very hard to be intellectually honest in a certain way. You start a company and have to sell the idea to people you want to join you on the journey, and to clients, and you have to believe it's a bigger deal than it probably is. You need a little bit of delusion.

Daniel: I don't think I'm delusional, then.

Ben: Maybe you become delusional the more time you spend in it. No, I think part of me is a little delusional. People ask, "How big can this be?" and I say, "This is going to be a Fortune 500 company someday." And people say, "Okay, let's chill. That's very unlikely."

Daniel: I'll turn it back to you. You have the same blend of experience, maybe weighted a little more one way than the other. What have you picked up?

Ben: I agree that academia is a lot more entrepreneurial than I expected. I was never really an insider in academia, but now I work with a lot of academics, providing data and so on, and I'm surprised by how much it takes to be an academic researcher. You need to work with vendors, pitch the vision, find a team and co-authors. There's politicking. You need some hustle and a business mind, which is a really distinct set of skills from being a good writer, thinker, and statistician. So I'm very impressed by what successful academics accomplish. It's a very varied job.

34:58 Job reconfiguration happens every day

Ben: One narrower idea I'm curious to hear your take on goes back to how work adapts. We're still a small company. When a client has some need, we change around what people do. When someone leaves, we change around what people do. We're constantly reconfiguring people's jobs. Every day something comes up and we ask who's the best person to take it on, or someone doesn't really like something, or isn't good at it. So when I hear that AI is going to change the task composition of the economy too fast for us to reconfigure, that just feels wrong, because reconfiguration happens every day, and 99% of the time it has nothing to do with technology. A secular technological trend is a small part of job transformation. What do you think? Granted, I'm not at Pfizer, where everyone is a cog in an assembly line.

Daniel: Apologies to Pfizer.

Ben: No offense to Pfizer. Some very procedural organization, you know?

36:39 Retrofitting vs. AI-native firms

Daniel: I bet they'd feel differently. The way I put it, since I talk with folks at large companies and at startups quite a bit: there's a natural tension, when you have a big, successful company, to not blow up the money printer. What we're seeing a lot of throughout the economy, and this happens with any early-stage, super-transformative technology, and I think AI is in that bucket. I think AI might be like electricity or bigger; I think that's within the support of the distribution here.

Ben: It's a GPT, as we know.

Daniel: It's a GPT, and, as some recent papers have pointed out, it's also an invention of a method of invention. It can help us discover all sorts of cool things; it turbocharges the discovery engine. I'm hoping that means TFP multiplication on the outside.

If this technology is like other technologies that have been really transformative, the initial instinct is the same one we had with the steam engine and the electric dynamo: how do we retrofit our existing steps and processes, sprinkle a little AI magic into all of them, and get a 30% improvement across a few? That translates into nice productivity growth, but not transformative productivity growth. It's not as exciting as one would hope. Then there's a new type of business, the AI-native business, mostly smaller and younger firms right now, but not only. I'm thinking of StrongDM, for example. They've talked about their build process and how much they get out of agentic coding systems, and it's astounding. They rebuild all sorts of software they have no intention of selling, just to test their products. Things that would have been unhinged 10 years ago are table stakes for them.

So what I think about is the intersection of industrial organization and org econ: where will there be enough competitive pressure that retrofitting isn't good enough, and you're forced to start reconfiguring your processes? A startup has to; it's more like putty. But think about an established company like Nike or Coca-Cola. I'm picking companies with incredible brands. You could replicate Coke, put it in a can that says "Zweig Cola," and people still wouldn't buy it, even if it tasted the same.

Ben: That would be a very naive way to think about a company's value chain.

Daniel: Exactly. So for them, the incentives to shift to AI-native might not be as strong. Same with Nike. Maybe they're pursuing it aggressively because there are all sorts of operational benefits; I'm not inside these companies. But you can build a theory where, if you have great complementary assets, your money printer may be safe for a while, and you don't have to do radical transformation.

40:16 Incumbents and complementary assets

Ben: This is a really interesting take. It seems to be in a bit of contrast to a wonderful paper I know, by Daniel Rock, about IT. Correct me if I'm misunderstanding, but it seems like with IT, there were a lot of gains from dependencies: to take advantage of the latest and greatest IT, you needed databases, networking, the building blocks, and then you could take advantage. Whereas with AI, it sounds like you think not having dependencies is a big strength. If you can start from scratch, you may be better off.

Daniel: I'd reconcile that by saying you still need the complements, but in different proportions. A startup is building the complements and can do it with the configuration it wants. The incumbency advantage is that you have them installed already, so you can start moving on your existing market. It's a play on what Clay Christensen said, I think: you're trying to get distribution before your competitors get innovation on the startup side, and vice versa. The question is your incentives to innovate, where you adopt, when you start blowing things up, and what you build in parallel as a secondary system that looks new. You might skunk-works an AI version of your company. There are lots of ways people have conceived of getting that kind of innovation in incumbents. But that tension is very real for a lot of large organizations.

42:13 Incentives during an AI transition

Daniel: And it has cool interactions with org econ ideas, like high-powered incentives. Say I have a sales team, and I incentivize them with the standard quota to sell the exact same thing we've been building for the last 10 years. And at the same time, I say, "You need to be AI-native and radically change your use of technology." That takes time. People need a chance to learn what will and won't work for them. If you have high-powered incentives, it's very difficult to divert effort from selling now toward enabling yourself to sell more later. So you need a new contract: for a while, "I'll give you a day every two weeks to upskill, and I want to see you hitting that mark as well as some of the sales targets, with a little leeway." I don't think I've seen many organizations be really deliberate about that. There are a couple, and they're doing great. I won't name them, but I've seen a few doing a really great job.

43:19 Why AI layoffs can backfire

Ben: It's a cool idea, and it's very much in conflict with the idea that AI is going to be a big deal, so we should lay off a bunch of people. That leaves everyone with even less bandwidth to try new things.

Daniel: And it locks in the capital stack. If I lay people off, I'm depending on automation or AI-assisted capital to do exactly what I was doing before. You've killed your innovative capacity if you've taken all the slack out as cost savings. And that's a signal: a signal that demand isn't expanding for what you do. It can be the right answer, but in many cases I think it's a mistake people make.

44:19 Is AI different from past GPTs?

Ben: That sounds right. I sometimes wonder whether AI is different from other technologies, other GPTs, in a couple of ways. One is that it doesn't seem to have a lot of dependencies: anyone who knows how to write can write with it. That seems new and interesting. Another, which is different from your point about AI-native companies, is that AI seems to be designed to fit within existing systems and replace certain tasks. That's at least how the frontier AI companies talk about what they're doing.

Daniel: Some of them do, and I think they're changing their tune.

Ben: They're learning, I guess. But it still has the vibe of a task-automating technology. Do you think it's different from other GPTs in that way? Is this time different in any important way?

45:45 The case for optimism

Daniel: I think it's emergent. There's been a lot of discussion on both sides of this, and I tend to take an optimistic view. There are amazing things we can do with these technologies. I don't know if you saw the news about the pancreatic cancer trial. I spend too much time on Twitter, so I'm not sure whether it's verified, but there are other examples like it. The five-year prognosis for pancreatic cancer is not great; most people pass away. My grandmother died from it. It's an awful disease. And apparently there was a trial with an AI-assisted design for an mRNA vaccine.

Ben: Yes, Derek Thompson wrote something about this.

Daniel: I think that might be where I saw it.

Ben: I try to stay off Twitter, but I read people who write Substacks about what showed up on Twitter, so it's very third-hand.

Daniel: You don't want to go wrong on Twitter. But the people in that trial are alive years later. Or there was a guy in Australia who wanted to cure his dog's skin cancer, went through all kinds of trouble to get a vaccine synthesized, and managed to do it, to his credit. The vaccine taught the dog's immune system to attack its cancer. I find these things deeply inspiring, and also mildly, or very, infuriating, because we don't have an immediate boom in providing these sorts of things. You start to think about what bottlenecks exist and whether they matter.

I think there's an organizational equivalent: a lot of the AI transformation we'll see may have nothing to do with AI. We're seeing the potential for change, going back and appraising what we're currently doing, and saying this makes sense and that doesn't. What I'd like to see is more optimism about what we can do with these tools and how they can expand frontiers. We shouldn't get caught in the mindset that what we do now is the only thing we'll ever do. It's going to change over time, like you say. I think it'll be the labor market of Theseus: we'll gradually swap things out. It's worth planning for disruptions and inequities and trying to help people who get displaced. But I think the majority of the story in the long run is going to be extraordinarily positive.

Granted, that's a bias I have, and I try to keep it at home when it comes to my scientific work, where I want an honest appraisal of what's going on and how it works. But I find it impossible to look at these healthcare and biology advances with AI's assistance, and at science generally, or math, like the recent DeepMind results solving nine Erdős problems, and not ask, "What is going on?" We're seeing the green shoots, the early days of a golden age for science and technology. If we manage it properly, it's going to be an extraordinary time, one that makes me a little sad that I probably won't be around for the coolest long-term effects. But maybe we'll figure out some longevity drug that doesn't turn us into zombies.

Ben: Or we'll be able to upload our brains to something. No, I think at some point, what you'd once consider a bias becomes, the more time you spend on it, an informed opinion. So I wouldn't call it a bias.

49:53 What Daniel wishes more people saw

Ben: Final question for you. I think of you as existing in a few places: you're an East Coast academic, but you're also an insider in West Coast startup land, embedded in those networks, and you see how people there are thinking. To get to this positive place, what are you seeing that you wish other people saw?

Daniel: The experimentation I see among people building software with these tools is very exciting, and it's hard work. You see communities form, in group chats, for example, where people say, "This works really well for me," or "I built a harness for this," or "Has anyone tried Gas Town?" There's all sorts of stuff like that. I think that community formation, and how organic it's been, quietly drives a lot of innovation behind the scenes, and that part is really cool. I'll shout out Dan Shapiro at Glowforge, who posts really interesting tools, and Jesse Vincent. Usually I sit back for a few months, see what's solidified into something all these people are using, and then I pick it up and teach my students about it.

I think people should start thinking about what it looks like if software becomes very cheap to produce for almost any purpose, as long as you have a vision for what it needs to do. I'm inspired by one of my former students, Dan Swenson. He was a military special forces operator before becoming an MBA student. He doesn't write code; he'll tell you openly he's never written any Python. But he has five or six projects, out of the 30 or so he's done over the last year, generating meaningful value for whatever his goal was. One was a phone app for sports medicine that he built to help his sister. Others relate to private equity. He's a wide-ranging guy, and when you listen to him talk, he sounds like a software architect.

There are lots of people like him who, if they can define a problem well and have the grit to push through, will blaze a trail for the rest of us to be builders. That will come with a whole bunch of complements, too. If you tell a chief information security officer that their entire sales force is going to be coding, they're not excited about that at first. So we have complements to build. Anyway, I think blending East Coast skepticism, the sense that things take a while and can be challenging, with West Coast optimism is the way to go. And then you end up as a Midwestern economist like me.

Ben: A Chicago person, right in the middle. That's exciting. Thank you so much for being part of the show.

Daniel: It's great.

Ben: And listeners, check out Daniel's papers, research, and Twitter presence.

Daniel: All right, thanks.

Ben: The Economics of Work is brought to you by Revelio Labs, workforce data for research and benchmarking. If you enjoyed this episode, please remember to rate, review, and subscribe. It'll help us reach other curious listeners. I'm your host, Ben Zweig. Our producer is Cole Wagner. Thanks for listening.