Playbook for Success Based on Dan Shipper's AI Predictions from Lenny's Podcast

Most companies are experimenting with AI. Dan Shipper is living in its future.

Every — his 30-person media and software company — operates entirely inside Codex and Claude Cowork. Not just the engineers. Every writer, editor, salesperson, and operations person. The whole company. Shipper gets beta access to frontier models before they ship publicly, meaning the workflows and patterns his team is navigating today are what most builders will be dealing with in twelve to eighteen months. When he describes what he's seeing, he isn't speculating from the outside. He's reporting from inside the most advanced AI productivity experiment running in any company right now.

This month, he sat down with Lenny Rachitsky on Lenny's Podcast to share twelve predictions for how work changes in the AI era. Here is what each one actually means — and what to do about it before the window closes.

1. The future of work will happen inside Codex or Claude Code

We're rushing to build an ecosystem where agents work with other agents autonomously. After hundreds of hours building and consulting with dozens of businesses, Dan believes that all will bow down to ChatGPT Codex and Claude Code. They already have the market dominance, our confidence, and are working through the governance and compliance layers of every business. So of course it would make sense that enterprises would prefer to allow a handful of trusted agents into their repos.

His enthusiasm mostly comes from seeing how OpenAI's Codex and their browser, Atlas, can work through problems and learn from observing us. Because the browser runs inside the LLM, it can watch how we work and be more aware of how to help.

The value creation runs deeper when he imagines the LLM loading our most important SaaS platforms inside the browser. What this creates is an environment where a single agent — Codex or Claude Code — knows everything about us, holds all our credentials, and executes multi-stage plans across multiple SaaS platforms. "I basically feel like I have this parallel work buddy that not only can it respond and write in the document, but then it can go do research, it can use my computer to basically do anything that I can do on my computer."

Implication for builders: His prediction goes completely against the dominant POV that every SaaS will needs its own agent and that agents will interact with each other via CLI and others machine-preferred methods. In this scenario, we would be locked into OpenAI and Anthropic because of their relationships and preferred access. To succeed at this every one of us would need to create our ideal environments that would enable the super agent to work on our behalf, rather than authorizing dozens separately and dealing with different pricing schemes and limitations for each.

2. Every company will have one "super-agent" inside their Slack

What if every company ran on one super-agent accessible in Slack — one organizational brain everyone queries and delegates to throughout the day? Shipper believes that's exactly where this is heading. Shopify already has one. Ramp has one. The companies building this now are creating something that functions like institutional infrastructure: a single place where the company's decisions, context, and operational knowledge live — queryable by anyone, updated continuously, maintained by someone whose job is to keep it accurate. Competitors who build this later don't just face a technology gap. They face a context gap that took years to fill.

The reason this works — and the reason most company-wide agents quietly fail — comes down to maintenance. An AI agent is not a product you deploy and walk away from. It accumulates context over time: what the company actually sells, why pricing changed last quarter, who owns which decisions, what the leadership team agreed to in November. When something goes wrong — a wrong answer, a missed context, an outdated assumption baked into a workflow — someone has to investigate, diagnose it, correct it, and update the instructions. An agent nobody feels personally responsible for maintaining starts giving confidently wrong answers with nobody catching them. A company-wide agent tended by a dedicated person who treats it like a product compounds. "In order for an AI agent to be useful right now, it really needs a human who cares about it — a human personal connection with someone who's watching what it does and makes sure it's doing the right thing."

Implication for builders: Building a company super-agent is one of the highest-leverage investments a leadership team can make right now — a single system that accelerates the work of everyone in the organization, accumulates institutional knowledge that compounds over time, and narrows the gap between what your people know and what they can actually execute on in a day. The companies building these now are not cutting teams. They are giving their existing teams a faster brain to work alongside. The barrier isn't the technology. It's the governance: 36% of enterprises have no formal plan for supervising their AI agents, and without clear ownership, even well-built agents drift, give confidently wrong answers, and create the kind of liability that kills programs. Invest in the super-agent. Then find the person who will own it the way a PM owns a product.

3. SaaS is not dead — "I would buy SaaS stocks right now"

Shipper's most contrarian call in this conversation: "I would buy SaaS stocks right now." Every runs entirely on Codex and Cowork, and their SaaS spend is still up year-over-year. Agents don't replace SaaS products — they become high-volume power users of them. GitHub is already feeling this at a scale nobody anticipated: AI agents opened 17 million pull requests on the platform in March 2026 alone, up from 4 million in September 2025 — infrastructure designed for human throughput buckling under machine-speed volume.

"What agents do is increase the number of users of SaaS, not get rid of it." The logic: when Codex or Cowork loads your product inside its in-app browser, your SaaS becomes part of the super-agent's execution toolkit. The agent navigates your product the way a human would — logging in, taking action, retrieving data — but at machine speed and without friction limits. Every SaaS that can be operated through a browser becomes, effectively, an extension of the agent's capabilities. That's not a threat to SaaS demand. It's a structural amplifier of it.

The strategic choice this creates is one most SaaS teams haven't fully reckoned with. The conventional assumption is that every SaaS needs its own AI layer — its own models, its own assistant, its own embedded agent. Shipper's prediction, taken seriously, inverts this. If the super-agent handles intelligence and orchestration, SaaS products become the execution layer: the place where the agent takes action, not the place where intelligence lives. The products that win in this environment aren't the ones with the best embedded AI. They're the ones with the most reliable high-throughput infrastructure and the clearest data model for agents to work with. That's a very different product strategy than what most teams are currently executing. The economic implications of this shift — what it means for SaaS margins when users bring their own AI access — flow directly into prediction #4 below.

Implication for builders: Don't abandon a SaaS product you believe in because the room is full of people declaring the category dead. The pressure is real — SaaS valuations hit decade-plus lows in Q1 2026 as markets priced in AI disruption, with the median EV/Revenue multiple falling from 18x at peak to 5x — but the end of one competitive posture is not the end of the market. Expand the capabilities that benefit both users and agents: cleaner APIs, better data models, faster interfaces, tighter integration with the tools your users already depend on. Go back to prioritizing UX as a genuine differentiator. When AI handles the intelligence layer, the products that win are the ones that are a pleasure to navigate and reliably easy to integrate. AI capability alone is no longer a defensible moat — and the SaaS companies betting on embedded AI as their primary differentiation are going to learn this at the worst possible time.

4. SaaS economics will shift — users will bring their own AI tokens

Most SaaS teams building AI features today assume they need to own the AI layer — pay for the model, manage the inference costs, absorb the margin hit. Shipper's prediction is that assumption is already becoming obsolete. When users access your product through Codex or Cowork, they're doing so with their own Codex or Claude subscription already active. Their existing AI access handles the intelligence layer. You don't get billed for those interactions. The model runs on their account, not yours. Shipper already operates this way: Proof, his markdown editor, has zero AI inference costs. "It changes your margins back to, well, I don't really have to pay for tokens anymore because the user's going to bring AI."

This inverts the assumption most SaaS teams are building against right now — that you need to build and subsidize an AI layer to stay competitive. What you actually need is a surface that behaves well when an agent is working alongside a human. That's a substantially smaller engineering problem, and a much better margin structure.

The margin implications compound: no inference costs, and a simpler product because agents handle the complexity — formatting, tables, layout — that you used to have to build features for.

Implication for builders: Before committing roadmap cycles to building AI into your product, ask a simpler question: are your users already bringing AI with them? If they're accessing your product through Codex or Cowork, they already have an intelligence layer on top of your surface — and you're not paying for it. The right investment isn't building and maintaining your own model layer. It's making your product a great place for an agent to work: clean data, predictable behavior, fast responses, clear error states when something goes wrong. That's a smaller engineering problem and a dramatically better margin structure. Teams that figure this out in the next two quarters will carry a meaningful advantage over those still building AI features their users are getting for free. For more on how the token economics are shifting, see how OpenAI and Anthropic are pricing access in 2026.

5. PMs will thrive in the AI era

Most product conversations right now center on what engineers can do with AI. Shipper's most bullish bet is on a completely different role: product managers.

His evidence is concrete. Marcus, a PM at Every, previously ran a major writing product at Axios with a full team. He is lightly technical — knows what a database migration is, can read code when he needs to. He now ships faster than almost anyone at Every, alone, with Claude Code. What makes him dangerous isn't technical depth. It's that his product judgment — the eye for users, the instinct for what matters, the ability to turn a hundred conversations into a coherent direction — drives output directly. No team between him and the thing. No translation layer. No sprint cycle absorbing the signal.

"The coding models have gotten good enough that he can pair the technical knowledge that he does have with his really spiky product sense... and it's so dangerous."

The reason this compounds is structural. Every technical limitation that previously required handing off to an engineer — building the feature, writing the tests, deploying it — is increasingly something a PM with basic technical literacy can close alone. The translation layer between judgment and output is collapsing. What's left is the judgment itself, and PMs who have spent years developing it are sitting on a suddenly very liquid asset. The role isn't being automated away. It's being amplified, for the people who reach for the tool.

Implication for builders: If you're a PM treating Claude Code as the engineers' domain, you are actively ceding the most important development in your career in years. The building is increasingly becoming yours. The question is whether you're picking up the tool. Get into Codex. Ship something small enough to do alone this week. The feedback loop from that experience — seeing your judgment realized immediately, without a team between you and the outcome — changes how you think about your role permanently. The workers who pull the most from these tools are the ones who understand how their skills connect into the work of others — who think in systems, trace decisions upstream, and know where quality breaks down across the whole product cycle. That's not a technical skill. It's the core of good product management. The feedback loop from building something yourself — owning the full stack from judgment to shipped feature — is what sharpens that systems thinking to its edge. Harvard Business Review's 2026 research confirms the pattern: the organizations accelerating AI adoption fastest are the ones building product management thinking into how they evaluate and deploy AI systems.

6. Full-stack designers will become superheroes

There's a visual uniformity to most AI-built products right now. You can see the Vercel template, the default palette, the components that all look like cousins of each other. Vibe coding pulls from the same training data with the same defaults and produces the same outputs. The slop aesthetic is real, it's recognizable, and it's spreading — soft gradients, Inter font, 8px border radius on every button, the same "clean, modern" look on every AI-generated product.

The person who breaks through it is the designer who can build. Not because they're writing production backend systems — but because they can take their visual instincts and ship them without a handoff. The handoff is where design dies. The specific interaction that made something feel right gets approximated, then generalized, until it's indistinguishable from everything else.

At Every, designers make pull requests directly. The thing they designed is the thing that shipped. Shipper also sees this as an entrepreneurial opening that most designers haven't fully registered yet: "They can make stuff now. And I think designers are such creative people, and I think AI is a super tool for anyone like that."

Implication for builders: Design is not primarily a production skill. It is a judgment skill — the capacity to look at something and know precisely what's wrong with it and why. Taste, critique, the ability to hold the user's full experience in your head at every level from data model to tap target: these are the things the model cannot generate. What AI changes is that a designer with those instincts no longer needs a handoff to realize them. You can build the prototype, make the pull request, ship the thing you designed — without approximation. The designers who win right now are not the ones who generate the most with AI. They are the ones who know what good actually looks like, can see why most AI-generated interfaces fail at the exact moments that matter, and can then go fix it. Taste without execution has always been the unclosed loop in design. The loop just closed.

7. The AI job apocalypse is not happening

The apocalypse narrative is wrong. But the comfort people are drawing from it is also wrong.

Shipper's model for how this actually works: every model release makes a prior level of human competence cheap and broadly available. That competence becomes the new baseline. Humans, forced to push further, move into territory the models can't yet cover. The models catch up. Repeat. "What models do in general is they make yesterday's human competence cheap... What humans do is we sort of go in there, and we're like, 'Yeah, we have all this frozen human competence from yesterday. How do I use this to make something new and interesting?'"

Higher volumes of AI output create more demand for humans who can evaluate, direct, and elevate it — not less. More code means more engineers needed to determine what actually belongs in the codebase. More data science output means more demand for the data scientists who can handle the questions the bot can't frame correctly.

For junior and mid-level workers specifically, this is the distinction that matters: the entry point to a career is changing, not disappearing. The first few years of a career used to be about executing tasks at volume to build competence. They're increasingly about learning to evaluate, direct, and improve AI output — which is harder, requires more judgment, and compounds faster. A junior analyst who learns to frame the right question, even when the model does the computation, is building exactly the skill that matters most as models get stronger. The risk isn't that entry-level work vanishes. It's that workers who treat AI as a shortcut to skip the learning are building a skills gap that widens with each model release. We've published a full playbook for knowledge workers navigating this shift — and the pattern is consistent across roles. For the structural argument about what happens to compensation when companies optimize for this dynamic, see our piece on the 100x organization.

Implication for builders: The four moves that consistently work in this market — drawn from our full knowledge worker playbook — come down to this: identify the specific capability where colleagues route the hard questions to you; make that expertise visible and attributable rather than tacit and invisible; use AI as a multiplier on that capability, not a substitute for it; and find the audience that values it most. MIT Sloan's research on AI and workflow transformation shows what happens to the people who execute this well: when AI automates routine tasks, those who redirect toward judgment-based work pull significantly ahead. The ones who treat AI as a shortcut to skip the judgment-building are the ones who end up with nothing the market can't replicate. For the fuller structural argument about what this means for compensation and career, see our piece on the 100x organization.

8. Forward deployed engineer is the new most essential role

The most important new role in enterprise AI barely exists on most org charts yet. Shipper calls it the forward deployed engineer — and the closest precedent is what companies like Palantir built during the enterprise software era: technologists embedded directly into client operations, close enough to the actual problems to catch what the system gets wrong before it causes damage. The AI version of this role is internal, but the logic is identical. The market is already validating it: forward deployed engineering job postings were up 729% year-over-year as of April 2026, with OpenAI, Anthropic, and Google all hiring at scale.

The profile is specific in ways most "AI engineer" job descriptions miss. They need enough technical depth to read agent logs and trace a wrong answer back to its source — a bad prompt, a missing context, a business assumption that changed three months ago and nobody updated in the system — and fix it before it propagates. They need enough organizational knowledge to distinguish a model failure from a process failure. And they need the patience to spend most of their day in conversation with a system that behaves inconsistently, because reducing that inconsistency is the actual job.

At Every, Nitesh fits this profile exactly. He spends most of his time in Slack talking to Claudy — Every's internal agent that runs the consulting practice — diagnosing why it did something wrong and correcting it. "A lot of it is just talking to it and being like, 'Why did you do this dumb thing? Let's fix that.'" The primary output of this role is not code. It's a reliable AI system that works for people who can't fix it themselves.

The mistake most companies make is treating this as a transitional need — something they require only until models get smart enough to self-correct. Shipper's observation points the other direction: as agents take on more responsibilities, the stakes of a misaligned agent rise, not fall. The forward deployed engineer becomes more critical as the agent does more. 94% of organizations that deployed AI agents last year weren't ready for what followed — and poor maintenance ownership is a primary reason why.

Implication for builders: This role doesn't exist on most org charts yet. The question isn't whether you need it — you do — but who on your current team has the profile: technically strong, genuinely curious about AI systems, willing to spend their day in conversation with an agent rather than building features in isolation. Find that person and give them the role. The ROI data on enterprise AI deployments suggests ownership gaps — not capability gaps — are the most common reason AI investments underdeliver. The companies that name this role and staff it deliberately are starting from a very different place.

9. CLIs are over

The command line had a moment. Claude Code was exploding and a school of thought emerged that the terminal was the natural habitat of AI-native work. Shipper's read: we speed-ran that era. "We speed ran the CLI era. It was nice while it lasted." The terminal was the delivery vehicle for Claude Code's early success, not the cause of it. The actual innovation was an agent with access to everything on your computer. Move that into a GUI with an in-app browser and you get identical capabilities in a surface that is genuinely better for most of the work most people actually do. "We made GUIs for a reason, and it's just nicer to be in a GUI."

At Every, most of the technical team has moved to Codex and Claude Code desktop UIs. The terminal is a fallback. The people who concluded the terminal was why Claude Code worked were observing the symptom, not the cause.

Implication for builders: If your product strategy assumed CLI-first because that's what the early Claude Code wave demanded, you built for a moment, not a market. The users coming behind the early adopters — PMs, designers, ops, non-technical knowledge workers — are not coming to the terminal. Build the GUI that wraps the same capabilities. That's where the growth is.

10. Automation is a lie

"Automation is a lie, in the sense that every time you automate something, in order to make sure the automation is working well, you need a human on top of it making sure that it's working well." Every time you automate something, you create a new job: making sure the automation works. Shipper learned this directly. He vibe-coded Proof entirely, launched it, and spent the next 24 hours watching servers collapse every 10 minutes while the agent patched one issue and created four more. He needed two senior engineers to rewrite the codebase from first principles. "I have so much automation, so much AI, and I also work way more."

His senior engineer benchmark makes the deeper point. Current models, told to fix a list of issues, will try to fix those issues. A human senior engineer looks at the codebase first and says "this needs to be rewritten, not patched — and here is why I'm telling you that before I touch anything." The model lacks that specific confidence: the confidence to refuse the task as framed and push for a better frame. That judgment is still the human's job.

Implication for builders: Every agent you deploy creates a new category of work: issues to diagnose, edge cases to correct, new capabilities to research and configure, and possibilities that only become visible once the agent is running in the real environment. Shipper runs more AI than almost any company in the world and works more now than before Every adopted it — not less. That is the pattern. The question isn't "how much can this agent replace?" It's "who owns making this agent better over time, and what do they need to do their job?" Plan for teams that grow alongside the automation rather than shrink because of it. Research from MIT Media Lab found that workers who offload cognitive work to AI without maintaining engagement accumulate cognitive debt — the judgment capacity the automation was supposed to free actually atrophies. The humans who compound alongside agents are the ones staying inside the work, not floating above it.

11. We will read way more AI-generated writing and we will like it

The resistance to AI-generated writing inside organizations is running on borrowed time. What's happening, quietly, across thousands of companies, is that AI-directed documents are becoming better than the human-only alternatives.

Shipper ran Every's Q4 2025 planning entirely through Notion agents. Each team member was interviewed by an agent that asked about goals, metrics, and outcomes — pushed back on vague answers, connected individual plans to company strategy. He received high-quality planning documents for every function and used them to identify which teams needed to coordinate. Work that previously required weeks. "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 like dinking and dunking their fingers on the keyboard."

The distinction between quality AI writing and slop is worth internalizing: slop is a document where the sender took less time to make it than it takes you to read it, and they can't defend any specific line. Quality AI writing is directed, reviewed, and owned — the author stands behind what's in it.

Implication for builders: Most business writing — status updates, project documentation, planning materials, process specs, meeting summaries — is better when AI writes it. Not because AI writes beautifully, but because it considers all the inputs, catches what a time-pressured human would skip, and produces something complete rather than selective. The case for AI-written documentation is about coverage and consistency, not convenience. The writing that still requires humans is the writing that makes a judgment: strategy documents that declare what matters and what doesn't, vision statements where someone puts their name behind a directional bet, any communication where the message is "here is what I believe and why." AI can draft those too. But someone has to own them — and own them in the sense of being able to defend every line under challenge. The distinction worth setting on your team now: writing you can delegate to the agent, and writing the agent should draft but you must stand behind. Teams that don't set that norm early will find it very hard to set once the habits form.

12. We'll be building software for humans and agents to use together

The current assumption in most product teams is bifurcated: you build either for humans or for agents. Human-first is traditional SaaS. Agent-first is CLIs and APIs. What Shipper describes is a third paradigm that barely exists yet in most categories — software designed for a human and an agent working on the same problem simultaneously, each aware of what the other is doing.

Proof already receives bug reports generated by agents: exact reproduction steps, a read of the relevant code, a diagnosis. These become GitHub issues immediately, and another agent attempts the fix. The loop from "user ran into something" to "fix is in review" closes in minutes. "You can see the glimmers of this very fast closed loop."

The products that do this well will look different from their predecessors — simpler surfaces, because agents handle formatting and complex operations — but with new infrastructure underneath: approval flows so users can see and approve what the agent did, logs both humans and agents can read, fast rollback without needing engineering access, and architecture that handles agent-volume requests without degrading.

Implication for builders: The companies that win the next product cycle are the ones that start designing for this now, while it's still early enough to build it in rather than bolt it on. Pick one workflow in your product where a human and an agent might be active simultaneously. Design the experience. Build the approval flow. Ship it. The organizations that have done this thinking when the mainstream market arrives will have an advantage that is very difficult to close from behind.

---

Dan closes by saying he's simultaneously "extremely AI-pilled and very bullish on humans." That's not a diplomatic hedge. It's the actual finding from running the most AI-native company in the world for the last two years. The tools are transforming. The judgment required to use them well is still human, still scarce, and still the thing that separates the builders who win from those who don't.

The window to build that judgment is now — not when the market makes it obvious.

---

Sources:
- Dan Shipper on Lenny's Podcast: "The AI Paradox: More Automation, More Humans, More Work" — Lenny Rachitsky, May 2026
- Agent pull requests are everywhere. Here's how to review them. — GitHub Blog, 2026
- What is a Forward Deployed Engineer: The AI Role OpenAI, Anthropic, and Google Are Hiring in 2026 — MarkTechPost, May 2026
- The Vibe-Coding Landscape: Why Every AI Coding Tool Looks Identical — Medium
- Why SaaS Stocks Have Dropped — and What It Signals for Software's Next Chapter — Bain & Company, 2026
- Enterprise AI Agent Security Report — Zenity Research
- To Drive AI Adoption, Build Your Team's Product Management Skills — Harvard Business Review, February 2026
- How AI Is Reshaping Workflows and Redefining Jobs — MIT Sloan Management Review
- Your Brain on ChatGPT: Accumulation of Cognitive Debt When Using an AI Assistant — Kosmyna et al., MIT Media Lab, 2025