I interpret all three studies as providing labor cost savings from AI, broadly construed—in particular, meaning that all three studies include both automation and task complementarity elements. For instance, for the GitHub Copilot users in Peng et al., the authors’ interpretation is that some of the subtasks previously performed by programmers, such as the writing of common routines, are now done by the Copilot. Along the lines of the discussion in Section 2.2, suppose that programming in JavaScript involves N subtasks, which need to be completed for a successful program. These include initial planning (which approach to adopt, how to organize the program, etc.), composition of subroutines, putting the subroutines together, debugging the subroutines, debugging the master program and then assessing whether the program achieves the planned aims. When all of these subtasks are performed, then the task at hand—the writing of a specific computer program—is completed. We can think of generative AI as taking over a subset of the composition of subroutine tasks. Then in line with the framework in Acemoglu and Restrepo (2018, 2019b), the use of this new technology will create displacement and productivity effects. Overall performance will increase because of productivity effects, provided that this technology is better than/faster than humans at composing some subroutines (but humans are still needed for the other subtasks, including planning, debugging and checking). Demand for human labor in this task may increase or decrease depending on the magnitude of the displacement and productivity effects and the elasticity of substitution between this task and other tasks (as well as the demand elasticity for the product that is ultimately being produced for the market).

2025 is the year that AI crossed a capability threshold necessary to build all kinds of impressive programs simply via English, forgetting that the code even exists. Amusingly, I coined the term “vibe coding” in this shower of thoughts tweet totally oblivious to how far it would go :). With vibe coding, programming is not strictly reserved for highly trained professionals, it is something anyone can do. In this capacity, it is yet another example of what I wrote about in Power to the people: How LLMs flip the script on technology diffusion, on how (in sharp contrast to all other technology so far) regular people benefit a lot more from LLMs compared to professionals, corporations and governments. But not only does vibe coding empower regular people to approach programming, it empowers trained professionals to write a lot more (vibe coded) software that would otherwise never be written. In nanochat, I vibe coded my own custom highly efficient BPE tokenizer in Rust instead of having to adopt existing libraries or learn Rust at that level. I vibe coded many projects this year as quick app demos of something I wanted to exist (e.g. see menugen, llm-council, reader3, HN time capsule). And I’ve vibe coded entire ephemeral apps just to find a single bug because why not - code is suddenly free, ephemeral, malleable, discardable after single use. Vibe coding will terraform software and alter job descriptions.

Lastly, monitoring the adoption and impact of AI technologies in work settings can offer a real-world perspective on the practical AI advancements. This can most easily be observed in one’s own area of work – for example, in economics, generative AI has been adopted heavily by younger researchers such as PhD students and assistant professors, whereas older generations of economists lag behind, making it harder for them to assess advances in AI. Oftentimes I learn about new AI capabilities by looking over the shoulders of my younger colleagues.

““I’m not joking and this isn’t funny. We have been trying to build distributed agent orchestrators at Google since last year. There are various options, not everyone is aligned, etc. I gave Claude Code a description of the problem, it generated what we built last year in an hour.

It’s not perfect and I’m iterating on it, but this is where we are right now. If you are skeptical of coding agents, try it on a domain you are already an expert in. Build something complex from scratch where you can be the judge of the artifacts”.”

One widely circulated “a-ha” moment has been from Andrej Karpathy, a cofounder of OpenAI. Andrej has not been involved in OpenAI for years, and is known to be candid in his assessment and critique of AI tools. Last October, he summarized AI coding tools as overhyped on the Dwarkesh podcast (emphasis mine):

“Overall, the models are not there. I feel like the industry is making too big of a jump and is trying to pretend like this is amazing, and it’s not.

It’s slop.

They’re not coming to terms with it, and maybe they’re trying to fundraise or something like that. I’m not sure what’s going on, but we’re at this intermediate stage. The models are amazing. They still need a lot of work.

For now, autocomplete is my sweet spot. But sometimes, for some types of code, I will go to an LLM agent”.

Two months on, that view had been thoroughly revised, with Karpathy writing on 26 December (emphasis mine:)

“I’ve never felt this much behind as a programmer.

The profession is being dramatically refactored as the bits contributed by the programmer are increasingly sparse. I have a sense that I could be 10X more powerful if I just properly string together what has become available over the last ~year, and a failure to claim the boost feels decidedly like a skill issue.

There’s a new programmable layer of abstraction to master in addition to the usual layers involving agents, subagents, their prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP, LSP, slash commands, workflows, IDE integrations, and a need to build an all-encompassing mental model for strengths and pitfalls of fundamentally stochastic, fallible, unintelligible and changing entities suddenly intermingled with what used to be good old fashioned engineering.

Clearly some powerful alien tool was handed around, except it comes with no manual and everyone has to figure out how to hold and operate it while the resulting magnitude 9 earthquake is rocking the profession.

Roll up your sleeves to not fall behind”.

One forecast which many – including me – were sceptical about was made by Anthropic’s CEO, Dario Amodei, last March, when he said:

“I think we will be there in three to six months, where AI is writing 90% of the code. And then, in 12 months, we may be in a world where AI is writing essentially all the code”.

Yet it came to pass in December, when 100% of Cherny’s code contributed to Claude Code was AI-written. Playing devil’s advocate, one could point out that Claude Code is closed source, so the claim is hard to validate. And of course, the creator of something like Claude Code wants to showcase its high-performance capabilities. But I’ve talked with Boris and trust him; also, my own experience of using Claude Code tallies with his: I let Claude Code generate all the code I end up committing.

The central topic of this paper is thus how to steer progress in AI so as to increase demand for labor rather than displacing labor. We identify what the labor market effects of a given innovation are and how to categorize AI-based innovations according to their effects on labor demand. For this, it is necessary to pinpoint what the key conceptual properties of an innovation are that increase labor demand and therefore raise wages and employment. For example, AI-based intelligent assistants complement and augment human labor; they include navigation systems that allow unskilled workers with little geographical knowledge to take up jobs as drivers. On the other hand, technologies such as Autonomous Vehicles may predominantly substitute for workers and may lower demand for human labor. Similarly, AI agents that automate human work, such as call center agents, are likely to lower labor demand whereas agents that speed up research processes, such as in drug development, are likely to increase labor demand.

“As already discussed, some early studies show that within narrow occupations, lowerperforming or lower-expertise workers are the ones benefiting from generative AI. This raises the possibility that AI could be more complementary to lower-skill workers and may reduce labor income inequality.”

“I also explore AI’s wage and inequality effects. I show theoretically that even when AI improves the productivity of low-skill workers in certain tasks (without creating new tasks for them), this may increase rather than reduce inequality.” ([Daron Acemoglu, p. 1]

“Importantly, however, in this experimental setting, we do not see the displacement effects, because each of the treatment subjects are given the task and there is no possibility of reducing the number of workers performing this task.”

On the other hand, there are some very talented programmers who could design sophisticated algorithms. As Mark Zuckerberg puts it, “Someone who is exceptional in their role is not just a little better than someone who is pretty good. They are 100 times better.” Or in the words of Netscape cofounder Marc Andreessen, “Five great programmers can completely outperform 1,000 mediocre programmers.” Based on this worldview, it is desirable to use top-down design of technology by exceptional talent to limit human mistakes and their costs in workplaces. Replacing workers with machines and algorithms then becomes acceptable, and collecting massive amounts of data about people comes to be viewed as tolerable. This approach further justifies reaching human parity, rather than complementing humans, as the criterion for progress and comfortably fits with the emphasis of corporations on cutting labor costs.