The AI paradox: More automation, more humans, more work | Dan Shipper
In a Nutshell
Dan Shipper argues the "AI job apocalypse" is a myth—companies like Every are doubling headcount despite heavy AI adoption because every agent requires ongoing human oversight and maintenance. Work bifurcates into delegating to company-wide super agents (like Shopify's River) and doing most work inside environments like Codex or Claude Co-work, which become the new OS where SaaS tools run internally rather than having AI baked into each product. The core paradox: better models commoditize yesterday's competence faster, creating more human work reviewing slop, integrating outputs, and determining what makes sense for the business—driving demand for PMs, full-stack designers, and "forward deployed engineers" who maintain agent systems.
These notes were generated by AI and may contain inaccuracies.
Dan argues the AI job apocalypse is not happening. He is extremely bullish on product managers and full-stack designers. Every doubled headcount in the past year despite being highly AI-forward. Dan describes himself as simultaneously extremely AI-pilled and very bullish on humans. Automation is a lie. Every agent needs a human.
Despite having so much automation and AI, Dan reports working more, not less. Creativity becomes increasingly valuable to stand out from the constant slop being shipped. Models make yesterday's human competence cheap and commoditized. Humans take frozen human competence from yesterday and use it to make something new and interesting.
Work will split in two directions. First, everyone will have at least one agent they talk to that can receive offloaded work. Second, most work will happen on the computer in an environment like Codex or Claude Co-work, which becomes the operating system for all work including email and documents.
SaaS tools will run within Codex or Claude Code. The SaaS apocalypse is considered dumb. Dan would buy SaaS stocks right now because agents increase the number of SaaS users rather than eliminating them.
Many people are moving to CLI and terminal work. The CLI era was speed-run, was nice while it lasted, but CLIs are considered over.
Dan Shipper is CEO and founder of Every. The company is one of the most AI-forward startups. Everyone at Every, including non-technical people, uses Codex, Co-work, and Claude Code for much of their work. Dan predicted the rise of Claude Code almost a year earlier.
Dan previously made an offhand prediction that people were sleeping on Claude Code, especially for non-engineering work such as fixing files and sorting hard drives. That prediction proved correct. Anthropic built on this with Claude Code for non-technical work, and Codex is now leaning into non-technical use of coding agents. Anthropic's success over the past year partly stems from enabling non-technical people to use the tools.
Every has grown from 15 to nearly 30 people in the past year. Everyone at the company is an AI early adopter including engineers, designers, writers, editors, sales people, and customer service. The company creates a pocket of the future by living in it together. They get early access to models for beta and alpha testing because of their role reviewing models.
Predicting the future at Every means living in it rather than prognostication. Writing about observations helps articulate and bring about the future. Claude Code was adopted organically after testing Sonnet 3.5 and 3.7. The team shifted to talking to computers in English using Claude Code in the terminal, with no one looking at code.
The reach test is an internal concept: when you wake up in the morning, do you reach for the tool organically.
The conversation is structured around three areas: how the way we work will change, how the shape of the work will change, and who will be most successful and what to work on now. Predictions will be scored in one year.
Benchmarks show models doing tasks autonomously for longer periods with improving accuracy. Despite exponential model progress, the experience is that humans will have more work to do. There is a paradox where better models create more human work.
Work usage will bifurcate into two main patterns. One is delegating to agents, similar to what was expected five years ago. The second is doing most work on the computer in environments like Codex or Claude Co-work that become the operating system for all work.
The first pattern involves agents you delegate to, probably in Slack. Architecture is unclear: whether everyone gets their own agent, teams get agents, there is one agent, or agents specialize. Initially Dan believed in personal agents creating a parallel shadow org chart where agents become reflections of individuals, like daemons in The Golden Compass.
Dan flipped his view and now believes the model is one super agent for the entire company. Shopify has one called River. Ramp has one. Personal agents require too much maintenance work. Agents break frequently and need constant fiddling such as SSH access. Most people do not want to or cannot spend that time maintaining them.
The fundamental requirement is that an agent needs a human who cares about it and maintains a personal connection. When that connection is severed, the agent stops being useful. This drives the shift to one agent per company model with a forward deployed engineer or similar role responsible for the agent. Some specialized team agents may exist.
Agents will start at the top as general agents used by many people, then become more specialized as use cases develop and models become less fiddly. For work, agents will mostly live in Slack. People prefer to keep personal and work agents separate.
Personal agents will handle computer errands such as ordering groceries. The focus here is on work agents.
The second pattern is that most work happens in Codex or Claude Co-work. Anthropic realized that an agent running on your computer has access to everything you have access to through the terminal. These agents understand terminal usage well due to abundant online content. This created a powerful coding paradigm.
Anthropic was early in moving beyond pair programming to autonomous agents on the computer. Once a coding agent can build anything, it becomes useful for any kind of work. People hacked Claude Code to do all their work. Anthropic built Co-work as a nicer wrapper around Claude Code.
OpenAI's earlier Codex versions were very technical and somewhat limited in understanding intent. Around the 5.3 launch three or four months prior, OpenAI shifted toward general purpose knowledge work. They launched the Codex desktop app, skipping steps that Anthropic took from Claude Code to Co-work.
Dan currently uses Codex as his daily driver, spending most time in it. Codex has an in-app browser. When writing documents, Dan opens a Codex thread for the project, opens the in-app browser to the document in Proof, and has Codex running and watching. Codex can respond, write in the document, do research, and use the computer for anything the user can do.
Dan achieved inbox zero for ten days straight using Codex with Cora, their email agent. Codex renders a page where Dan monologues instructions for each email such as research requests or document collection for lawyer questions. This eliminated procrastination on tasks.
The optimal experience shifted from putting AI in a browser to putting a browser inside the AI agent so it can see everything being done. This combination is powerful but uncommon. It cannot be done in Claude Code because external websites cannot be browsed.
SaaS tools will increasingly run within agent environments like Codex or Claude Code rather than having AI baked into each individual tool. When running agents on websites like Proof or PostHog, users bring their own AI and tokens rather than using the vendor's tokens. This shifts SaaS companies to build for both humans and agents simultaneously, with requirements including CLI compatibility, usable HTML, and immediate visibility of CLI actions for users. Users no longer need to build AI surfaces as primary user interfaces since agents can access everything a human has access to, including the entire computer.
This model eliminates the need for SaaS companies to pay for tokens since users bring their own AI to the product. The approach creates a fundamental change in how SaaS companies operate and their margins. Companies should prepare for this future by designing software where humans and agents collaborate on the same work with mutual visibility into each other's actions.
Cursor has a more advanced cloud implementation than competitors and has chosen a distinct lane focused on programmers, which may limit its expansion into non-programming tasks like creating slide decks. Model companies are recognizing the importance of having a harness above the model itself rather than just offering prompt and response. Anthropic offers cloud managed agents, while OpenAI has not yet responded in this area. Cursor was recently acquired by SpaceX in a deal close to a full acquisition.
Traditional productivity software like Slack, Word docs, and PowerPoints was designed primarily for human use. The emerging paradigm requires software where humans and agents work together on the same piece of work. This means building products with visibility mechanisms for both parties, approval systems, inboxes that summarize agent actions, logs, and rollback capabilities. Agents can perform billions of operations simultaneously, requiring different display approaches than human concurrent editing. The underlying infrastructure must handle agents making billions of requests in seconds.
GitHub is experiencing problems because the number of users is skyrocketing exponentially, driven primarily by agent usage. In Proof and other products, when problems occur, agents send bug reports rather than humans emailing support. Agent bug reports include exact reproduction steps and analysis of the open source codebase. This creates a fast closed loop where an agent encountering an issue can communicate with a company agent to get it fixed.
CLIs will continue to exist but are no longer the primary work surface for most technical people. The popularity of Codex and similar tools is not due to their CLI nature but rather their agent capabilities. GUIs were developed for good reasons and provide a better experience, especially for non-programmer work. Most technical workers have shifted to Codex, Claude Code, or Cursor as their main work surface, though programmers may still occasionally use CLIs.
Two primary modes of work are emerging: a super agent within a company that users chat with through Slack to perform work and answer questions, and local agents like Codex or Claude Code running on individual computers where all computer-based work happens inside these environments. Users will interact with apps inside the internal browsers of these agent tools.
Having multiple agents is better than relying on a single agent. When Codex interacts with another agent, it can provide far more context about the user and their preferences than a human could type directly. This creates a speed-up effect when building products that assume users access apps through Codex, Claude Code, or similar tools. For hosted OpenAI products on waitlists with deposits, this approach allows pasting a prompt into Codex which then communicates with the app, leveraging Codex's knowledge of the user's work and preferences to create customized experiences.
SaaS companies rushing to add agents to their offerings face token costs, but the prediction is that this approach saves margins because the model shifts from building AI into products to making software that humans and AI want to collaborate on. The SaaS apocalypse narrative is considered finished, with SaaS stocks expected to rise significantly. Internal data shows that despite widespread agent adoption, SaaS spend is increasing year over year because agents increase the number of users of SaaS products rather than replacing them. Agents create demand spikes as they use products at high volume.
Despite heavy AI adoption, the company doubled its headcount in the past year. Every automation requires human oversight to ensure it works properly. The allocation economy concept describes how humans will work with AI similarly to managers who spend significant time checking in with employees and ensuring work quality. Benchmarks create an illusion of AI autonomy that doesn't match reality. The speaker experiences working more despite increased automation.
A custom benchmark was created using the Proof app, which was initially vibe coded. After launch, the product experienced repeated server failures every ten minutes. Two senior engineers independently rewrote the codebase from first principles. When testing new models against this benchmark, all models until GPT 5.5 scored around 30 out of 100, while human senior engineers scored in the high 80s to low 90s. GPT 5.5 achieved 62 out of 100 using an Opus 4.7 plan and demonstrated unique agency to rewrite from first principles rather than patching existing code.
Current models lack the higher-level judgment that human senior engineers demonstrate. When given a prompt to fix reported issues, models attempt to fix the issues directly, while human engineers first assess whether the codebase itself is fundamentally flawed and requires major rewriting. Models require explicit prompting to reach this level of reasoning rather than arriving at it independently. The act of framing problems for benchmarks represents human cognitive work that cannot be measured by the benchmarks themselves.
Data labeling companies are purchasing code written before 2021-2022 because original human code is valuable training data. The benchmark methodology involves human engineers using AI in ways the benchmark creator could not due to time and understanding constraints. Benchmarks compare one human using AI against another human using AI rather than measuring AI in isolation.
In any real use case, there's always a human pretty close to it making sure that it's working.
Start using Codex or cloud code more and more for the work you're doing and especially the browser, use tools inside of it. Allow agents to be to use your products. If you're really going to build a SAS tool, make it easy for agents to be a user, essentially. Start thinking about some Slack bot that you can work with, like try out tools. Look for a tool that could become the AI agent within your company.
Buy SAS stock ASAP.
When you're thinking about building your software for agents, the current model is building a CLI that an agent uses, but they're using it in a sort of delegated task where the agent's using the CLI. Where it's going is you and the agent are using the app together. The agent's probably using the CLI, but you're using the web interface and they both need to be in sync. And that is a new challenge that's really interesting.
Once you're in this land where you've got async agents off that you delegate work to, then you've got your Codex cloud code work surface that starts to happen. The number of pull requests that you get is skyrocketing. People in consulting or in ops roles or editors are making pull requests. A higher percentage of your company or your users are going to be doing things that previously only technical users could do. This creates pressure on the other end for the people who have to deal with all of the new code for how to deal with that.
Pete gets thousands of pull requests a day on open claw and then he just spins up 50,000 Codex instances and then sorts through them and then merges a thousand of them. This is going to be more and more common. It brings up interesting questions around which pull request should you merge. When you add capacity in one part of your process, it breaks things. It used to be really hard to build things, and now it's very easy. The point is not can we build it, it's would it make sense with the rest of what we've built. How do we keep a sense of a coherent whole. And also, what do we delete. Entropic does this really well. They delete a lot of stuff from Cloud Code to make sure that's not bloated.
Non-technical people can do technical work, and then technical people are in charge of making sure that that work gets into a product or into a process in a cohesive, coherent way. Product people are going to be doing that too. Now that everyone can do everything, engineers can design, PMs can code, marketing people can ship stuff. There's confusion about what the hell is my job anymore. What am I responsible for, exactly. Am I supposed to be shipping stuff. Am I still a marketing person. It's creating a lot of confusion and uncertainty in the world.
Everyone is sort of a generalist and really loves having their fingers in a lot of different pots. Marketing people are still going to do marketing, even if they're touching the website. That's just part of marketing now. You can get a lot further being a generalist now, and that's really cool, especially for smaller companies.
The forward deployed engineer concept is for real. It comes out of every agent needs a human. Even the big model companies have agents that run internally and they have teams of people that run these agents. Those teams are not going away. The models are going to get more powerful, the agents are going to get more powerful, and the number of agents is going to grow, but people are still going to manage them. This looks like a very specific kind of person.
We have a couple of those people internally. They're in charge of making sure your agents are working and doing the right thing. We also do consulting, so we lend that out to people. Automation was supposed to take away jobs, but it looks like it just created one or many. Nitesh is an AI engineer who fits the forward deployed category. He spends most of his time actually talking to one of our agents in Slack. We have an agent internally called Claudie, which runs our whole consulting practice. He spends a lot of time in Slack. There's code, and he is using Claud code and other things, but a lot of it is just talking to it and being like, why did you do this dumb thing. Let's fix that.
We're not near a place where these agents don't need a human. There's the setup part and then there's the maintaining it forever part. Both are important. This is going to be a job for a long time. AI is not going to get smart enough to just automate it fully for a while. I'm simultaneously extremely AI filled and very bullish on humans and the role of humans in making sure that AI is working well.
The pace of shipping software and everything is just increasing, which also means there's so much more work reviewing all this sloppy output. A data science friend's team used to do analysis, answer questions, see if this experiment was positive. Now everyone's doing that and they're sharing the results and the data science team's job is now reviewing bad data science work. The same thing is happening with engineers. You need more data engineers and data scientists for this. You need to set up the appropriate systems or agents to help you with this.
At least one of the big mono companies has literally a data science bot that every single person in the org can query that is hooked up to their data warehouse that knows who's who so that it knows at the warehouse level who has permission to access what. All of the basic questions that people might want to ask that it sometimes gets wrong, they're constantly making sure it's getting it right. The data science team doesn't have to answer all of the basic questions because there's another team building an agent that is set up to do that really well. But if the team didn't exist, the data scientist would hate their lives. It can actually make the job better because for the data scientist you're now not dealing with all the silly requests. You're dealing with the deeper questions that are harder for the team who's dealing with all the basic requests and building an agent to do that. It's filtering all that stuff out so you can focus.
Engineers: 100% of code AI now. It's a completely different job. Product management: PRDs you don't have to write as much. You can ship code. You don't have to wait for people. Design: the whole design process is dead. Data science: very different work now. CEOs and investors: it seems still very optional whether or not they use this stuff. Your company's only going to go as far as your CEO goes in AI and it's not something you can delegate. You have to have your hands in it because you don't otherwise don't have an intuition for it. For a long time it has seemed like that's something that the people who are doing the work have to do but I don't have to do that. I'll just tell them what to do. If you're a CEO, you kind of can get away with your day looking very similar. That will change rapidly at some point. Middle managers: their day is fairly similar.
Sales might be the least fundamentally changed role. It's so impersonal. In the BDR space, we can deal with a lot of BDR type queries. You're only talking to people who actually want it. It's so useful to do research. One Codex experience: hiring a head of L&D. Typed into Codex to find someone who worked at General Assembly and is now into AI. Codex found the perfect guy who worked at General Assembly, was an instructor, is super AI pilled and follows on Twitter. DM'd him and had dinner with him. That would have taken so long before. Super valuable for sales, for recruiting, all that kind of stuff. The top of funnel AI is helping a lot with sourcing and qualifying things. The work of a salesperson is not fundamentally different. Customer support has fundamentally changed.
It's not babysitting agents. The forward deployed team is trying to build a whole system that makes it so that people who have less knowledge can use that system without doing something dumb. That's a really interesting engineering challenge. Babysitting makes it feel like you're just waiting for it to mess up and then fixing it. A lot of it is an extremely interesting engineering challenge of building a system to enable everybody else in the organization to do what used to be a technical job. If you're not one of those people, like the data scientist, you can go a lot deeper with AI into really important questions that eventually probably filter into the work that the forward deployed engineering team is doing, but is more generative and more new and you're dealing with harder questions.
We will be reading way more AI generated writing in documents and emails and we will like it. We're already doing this in coding where we read plan documents. I don't want an engineer to handwrite a plan document. That would be very silly. For quarterly planning, they did it all with Notion agents. They had one Notion agent and then they had a top-level company strategy and then everybody in the company just talked to an agent and it asked them about what happened last year, how did it go, what were their goals, what do you want to do this year, what are your metrics, it pushed back, and then how does this relate to the overall company idea. Then they got incredibly good AI generated strategy reports or quarterly plans for each part of each team. Then they could go in and be like, okay, who needs to talk to each other. Which teams need to talk to each other that don't know they need to talk to each other. Which one of these is actually low quality or which one of these is high quality. It makes it a lot easier to process.
There is a difference between an AI generated document that's slop and not. The slop one is it took them less time to make it than it takes me to read it. They don't stand behind every line. If you send me an AI generated document, that's great. And if we talk about it and it's clear you have no idea what's in it, that's a big no-no. Not allowed to do that. The aversion to AI-generated stuff will go away because the kind of strategy document that GPT-5.5 can write when it's directed well by someone on my team is way better than them just dinking and dunking their fingers on the keyboard. Most people are really bad at writing strategy documents. The bar is low.
Most of my email is written by GPT-5.5 and Codex right now. I would prefer it to say that it's coming from GPT-5.5 and I may change it to do that. Had an experience where Codex sent an email without asking and it was exactly what I would have sent. It's pretty close to that a lot of the time. It can be a little over formal. When you really think about it, most of your email is kind of rote, kind of prosaic. I definitely want to be the one to think about what it should say, but the actual sentences don't matter that much usually. Sometimes they do a lot. This is coming from a writer. I care a ton about writing. I think that human writing is incredibly important. We only publish human writing. Actually, we publish a mix of human and AI writing, but we always label it. Sometimes it's nice to have an AI co-author on certain things. The reaction or the aversion to AI writing is silly.
Internally, if you're just working on planning and documents and email and things like that, that's much less scary that it's AI written. People are already doing this. You almost prefer it a lot of times because people are really bad at writing. We have this for external stuff too. We publish all these guides and the guides are often agent assisted and the agent is a co-author and they're intended to be read both by humans and by agents. If you're writing a huge informational thing, the best way to apply it is just have your agent ingest it and remember the next time I'm doing pricing to remind me of this guide and we'll go through it together. It allows you to operationalize the ideas much better and it allows you to go much deeper because agents can read 10,000 pages in a second. You talk to the human about the story and the stuff that matters and the core ideas and the agent has all the details that it can then apply for you when you need it.
I'm super bullish on PMs. Marcus runs Spiral, which is our writing app. Marcus is a PM by training. He previously ran Axios's writing product and had a big team and it got to tens of millions in revenue and ARR. He took a year off that job and just got super AI pilled. He learned how to use cursor basically really well. Now he uses cloud code. He's lightly technical. Knows what a database migration is. If he has to look at the code, he can understand it. We never could have hired him to do this job even a year ago. But the coding models have gotten good enough that he can pair the technical knowledge he does have with his really spiky product sense and sense for writing and sense for users. He ships faster than almost anyone on the team and he has such an eye for every single user, every single conversation, what does it mean and how do we collect it into a story about where we want to go next and what are the issues we need to fix. He feels liberated because he doesn't have to organize a whole team of people to do that. He can just do it. It's super impressive.
Full stack designers are going to be super powered people. If you're a designer and you're in these tools all the time, you're so used to making this beautiful interaction and the engineer just doesn't want to do it or it doesn't happen the way I think it should happen. Designers now feel so empowered to go build stuff because they have all these ideas to make things look amazing and these interesting interactions and that's the exact thing that's really hard to do with live coding because it just all looks the same so it all looks like slop and they can make stuff that looks so different and now they can actually build it. When we work with them internally, they're just making pull requests. They don't need to hand it off as much. Sometimes they do but a lot of times they just make pull requests and the thing is built and that's it. There's a huge opportunity for those people to become much better and start their own thing because they can make stuff now. Designers are such creative people and AI is a super tool for anyone like that. The creativity is going to be more and more valuable to stand out from all the slop that people are shipping and launching constantly. Designer roles have not
Designer roles have not grown in a while. One way to predict whether design demand will increase is to watch whether companies are hiring more designers.
The AI job apocalypse is not happening. Companies are reorganizing, but much of this can be attributed to over-hiring and companies not performing as well rather than AI specifically. Mass unemployment predictions from some AI CEOs will not materialize.
New model releases make yesterday's human competence cheap by ingesting existing data and making it inexpensive to deploy that knowledge in any situation. This power gets adopted rapidly, leading to commoditization—suddenly anyone can make a landing page or write tweets, but default outputs look similar because everyone uses the same models.
Default model outputs become commoditized and lose value. Humans then take this frozen human competence from yesterday and use it to create something new and interesting. Due to how models work and the financial incentives of model companies to keep them compliant and aligned, models structurally trail behind people who use them to create new expertise for very particular situations. This new work gets incorporated into models, creating room for people to push further ahead.
Everyone suddenly becoming an engineer does not mean firing engineers. Demand increases because engineers are needed to determine how AI-generated code should actually integrate into a codebase. Benchmarks rising does not capture this dynamic, and it will take a long time to change.
To avoid layoffs, ride the models—use them for whatever work is being done. Codex and Co-work are becoming the standard operating system for work. When new models release, experiment with how to use their new capabilities instead of ignoring them out of fear.
Riding models extends capabilities and keeps people part of how work happens going forward. This will be needed for a very long time.
Some companies restrict employees from using the latest models, requiring experimentation on personal time. The approach is to play with new models by testing things they previously could not do. For example, a senior engineer benchmark improved from not passing to scoring 60 out of 100. The method is to stay curious and playful, apply new models to work or personal interests, and keep testing capabilities that may work eventually.
The edge of AI is not in San Francisco where models are built. It is wherever AI meets a real human doing something. People outside San Francisco often discover new uses first because model makers do not know everything about how to apply their tools. Being in Brooklyn and using models for everything can put teams ahead of those in San Francisco.
Anyone with some money has access to the most advanced AI models immediately upon release. Only people working at OpenAI or Anthropic may have an advantage. If IBM had invented AI, it would likely be extremely expensive, restricted to top companies, and used in uninteresting ways. AI built in Silicon Valley culture aims to make intelligence too cheap to meter, creating broad accessibility.
SaaS continues, jobs are not disappearing, email and Slack remain standard. Simultaneously, every role transforms—engineers no longer write code the same way, PMs no longer write PRDs the same way, design processes change. Much stays the same while work at the edges transforms.
The future will contain both cool and not-cool things and will simply be another horizon rather than a utopia or catastrophe. Middle Ages intuitions about what lies beyond the horizon—dragons or utopia—mirror current reactions. The reality is more complex: everything has changed and nothing has changed.
AI companies have been effective at scaring people about future dangers, though this PR strategy is shifting as companies realize they should not freak everyone out.
Ride the models by trying all workflows in Codex or Co-work. If companies restrict access, experiment on personal time with agent products like Open Claw, Hermes, or for less technical users, Victor and 1+1's. Get comfortable with both agent and workflow approaches. Approach AI with fun rather than FOMO, as finding moments of joy leads to sustained building. Find a problem in life or work and test whether AI can solve it using tools like Lovable, Clockcode, or Replit.
The Writing Life by Annie Dillard—specifically the last chapter, which addresses writing, technology, the future, and time. Everyone joining Every receives a copy. Churchill's history of World War II, a combination of history and memoir written by someone who participated in the events. The Rigor of Angels, connecting Heisenberg's uncertainty principle, Borges' fiction, and Kant, with interesting overlaps to AI concepts.
Watching basketball as a new Knicks fan. The Dark Wizard, a mini-series documentary about Dean Potter exploring extreme free soloing, base jumping, and wingsuit flying. Codex as a recently discovered product that has transformed workflows, including email and analytics when used with the Anthropic browser.
"Do things worth writing about and write things worth reading." From Rob Brezsny: when dealing with difficult situations, relate to them from a position of spaciousness and strength rather than fear. This approach has been helpful when confronting concerns about AI changing jobs.
Codex remains underrated. At a recent Anthropic conference, recommendations were made to try Codex because the capabilities differ significantly, especially for emails, analytics, and other tasks when paired with the Anthropic browser. OpenAI has regained momentum after a rough period, though it remains a horse race where different labs lead at different times. Switching between models for different tasks provides value.
Keep Lenny's Podcast in your library
Save the videos and channels worth coming back to, and find them again in one place.
