One of the most common forms of AI content you’ll see on X or LinkedIn is people showing off beautiful landing pages they made with AI. What you’ll almost never see is someone showing what it takes for a pretty design to become an actual Landing Page.

That’s because the design step is only one (increasingly commoditized) step in a much longer process that produces an asset that represents your brand, communicates your unique value proposition, and excites customers.

In May, I spent sixty-four hours redoing Offline’s landing page in an AI-native way. Here’s exactly what happened.

It Always Starts With Process and Context

For me, AI always starts with Process and Context.

Always.

If there’s just one thing you take away from the stuff I put out about AI, remember this: it always starts with Process and Context (that’s why I capitalize them).

Here’s what that looks like for a landing page:

Stage One: What to Say

The starting point for a great landing page isn’t design, it’s figuring out what the page needs to communicate.

“What to say” breaks down into three distinct steps, with a human-in-the-loop review between each one:

Since Offline records all of our sales calls, I exported a chunk of ~20 sales calls to use for voice-of-customer:

I then fed these to Opus 4.7 alongside a GTM Strategist Persona prompt, which defined the role for Opus 4.7 and directed it to the sales calls, our company vision, and a document that defines the features/mechanics of our core product:

Once we had a positioning thesis, I used a simpler prompt that further refined the positioning into a precursor of the landing page: a cohesive set of ASCII-wireframed panels with real copy.

Stage Two: Design

Now, and only now, does design enter the picture. At this point, I have confidence in the way we’ve gradually reduced the altitude from customer conversations to positioning to wireframe/copy.

I have a great feel for how we’re communicating and for the flow of the page.

This is where most X/LinkedIn content picks up: in the design of the page itself:

The initial prompt was simple, since I had Opus 4.7 write a handoff doc for Claude Design that I dropped in alongside the ASCII wireframe file.

I let Claude Design drive the 3-wireframe set with limited interruption:

Whenever I see beautiful landing pages, I always wonder how much back-and-forth shaping was actually involved.

How much handwaving is going on when people say “Claude one-shotted this” or “I built this beautiful landing page in Claude Design in 10 minutes?”

To give you some visibility into how the sausage is actually made, I exported my exact Claude Design logs so you can see my entire conversation, turn by turn:

Session: Landing Page Design

As you can see, there’s a lot more wrangling involved than just “drop it in and let Claude cook!” Maybe it’s a skill issue, but my suspicion is that this is the norm.

The final output from Claude Design was a desktop-and-mobile-approved site design (no assets yet) to hand back to Claude Code:

Stage Three: Production Build

This is where the rubber meets the road: integrating your landing page into your existing production environment.

The handoff from Claude Design to Claude Code was smooth, and Opus 4.7 implemented one panel at a time with HITL review after each.

The asset wiring required access to Offline’s API and to assets in our Google Drive. I took a couple hour detour to apply AI-generated image tags to our entire 1,500+ corporate asset library for future reference.

You can see the live page here:

Offline Events

How I Got to 64.39 Hours (and the Old Way)

One of my habits is checking Claude Code session logs to understand how long things actually take.

It helps me hold a magnifying glass up to the claim that “AI makes me so much more productive” and look at it critically.

One of the most interesting findings, and the one led to my framing of this entire article, is that the design part was only 5.94 hours out of 64.39.

In other words, “design” was under 10% of the time.

Figuring out what to say took nearly three times that, and the production build was two-thirds of the whole thing.

When I first saw 64.39 hours, it felt long. That’s ~1.5 weeks of full-time work, parsed out over the course of three or four weeks.

But then I compared it to the old way of doing it.

Let’s take a minute and remember what that would have looked like.

But first, let’s remember that this was 64.39 hours of only my time (and Claude’s).

A quick reminder of how time works when multiple people are involved:

In The Old Way, there would have been time spent just discussing the necessity for a new landing page. In other words, the landing page effort itself would have had to get prioritized and agreed upon as a priority by all the different people involved.

10 total unproductive hours before anything even starts.

Then, in all likelihood, there would have been a separate kickoff meeting between sales and marketing to set the stage and discuss what needs to go on the page.

My guess is that to get the copy (even just a v1) transferred from whoever owns VoC over to marketing, then having it written, rewritten, and rewritten again is at least 3 full-time days. I’m talking all the meetings, all the iterations, and all the approvals across all the people involved.

Then you have the handoff to the designer.

If you’re lucky, there’s no scope creep around brand that sneaks into the landing page redesign, but let’s be real…there almost always is.

Any time you’re redoing something as substantive as the LP from scratch, the temptation is not just to update the asset, but to slip in those brand tweaks: the font that has really been bugging you, the new color you want to see, whether your motion seems modern enough, etc.

Then you have the design work itself.

Let’s say v1 takes a full-time day for a top-notch designer working with no other cooks in the kitchen.

Then meetings for feedback.

How many in the feedback meetings? 2 people? 3? Let’s call it a half day combined for feedback.

And did I mention v2?

After v2 design, there are even more approvals by even more people. With additional tweaks, you’re lucky if it’s less than a full-time combined day.

Development is next, even if your designer doubles as a Webflow/Wordpress/Framer expert.

In almost all cases, this is where you find out that your design won’t translate pixel-perfectly.

Development is a day, maybe two, maybe three, maybe four. It depends on how much live content you need inside of the product, what that requires from engineering, how fast and competent your front-end developer is, and the inevitable back-and-forth tweaks as design constraints break inside the development environment.

Finally, you have the reality that somewhere along the way — from sales to marketing, marketing to design, design to development — this three-legged stool of copy, design, and development has made trade-offs.

The wording isn’t quite as punchy once you see it live, or it doesn’t fit the design constraints just perfectly, or the design constraints force the rewriting of copy, or the copy forces the rewriting of design…all the while development tries to keep it in balance.

This process chews up countless hours and time, frustrates people, slows things down, and turns a project into something that can span weeks or months.

Along the way, the initial enthusiasm and initiative around why we so badly needed a landing page turns into: are we sure we actually need this? Can’t we just exist without it?

I’m being generous with these calculations, and I still would guess that the total is somewhere around two hundred hours, stretched out across months, and at the expense of many other things.

The AI X-Factor: How to Create Compounding

So The Old Way is ~200 hours, and my build was ~64.

A big difference, but still only 1/3 of the time. Not 1/10th. Not 1/100th. Not the crazy numbers you see from AI influencers.

Crazy efficiency numbers like “10x more effective” get thrown around so much, but the question you have to ask yourself is: what are you 10xing?

If you’re just one-shotting something pretty 10x faster than you used to, then you’re 10xing slop.

Anybody now (literally anybody) can open up Claude and ask for a “pretty SaaS landing page” and marvel at what gets spit out. But there’s a huge difference, a huge gap that anybody can see, between something pretty that AI makes and what a landing page actually is: a crisp, compelling (and yes, beautiful) articulation of your value proposition that speaks to the end customer and makes them take action.

This is why I insist that Process and Context matter so much.

There are a series of steps, well worn grooves, that create what we think of as a landing page. There are ingredients that go into that, and there’s ordering that goes into that. And that’s fundamental.

It takes more time to encode and follow those steps, but the reward is that “64.39 hours” is the most time it’ll ever take.

Because once you encode that Process/Context map, the next landing page will take forty, maybe thirty hours.

And the one after that may get down to twenty.

But most importantly, you won’t just be cutting time. You’ll be cutting time while knowing you’re creating value at the end, and building something that accomplishes the end purpose it was designed for.

We’re entering an era now of AI Slop, and the pendulum is already starting to swing back against the slop.

The way to get true compounding is not to produce slop, but to take the time to teach AI to produce value, then lock in the system that produces that value.

you can find more at davidmshaner.com

How it started: getting “gstack pilled”

Over the last two weeks, I’ve had my biggest AI breakthrough since Opus 4.6 last November.

And it started in a completely unexpected way: a Slack message about gstack, Garry Tan’s open-source skills repo that launched on March 12th.

As a rule of thumb, I’ve been extremely skeptical of open-source skill files.

Under the hood, it turns out that “THIS ONE SKILL AUTOMATED MY ENTIRE MARKETING STACK (IT’S OVER!)” ends up just being a simple prompt that Claude could have written if I said, “write me a skill that automates YouTube thumbnails.”

My experience with gstack has been fundamentally different.

If a YouTube huckster’s thumbnail skill is the equivalent of the fart and flashlight apps of ’08, then gstack is more like using the Airbnb app for the first time.

It’s not so much the feeling that you borrowed someone else’s prompt, as it is the feeling that you’re using someone else’s product.

There’s the sophisticated-feeling preamble that boots up like a program, the hard gates that keep the model on the rails even when you drag it down 15 rabbit holes, the structured questions, the status receipts after each phase that create a feeling of clear progression, etc. I could go on.

And if you look at the source code, gstack’s 14,000 lines of markdown look a lot more like application code than basic prompt.

But it wasn’t gstack per se that was the breakthrough for me — it was just the gateway drug to something bigger.

Superskills: an entirely new category

gstack and others are part of a new class of what I’m calling “superskills” that are creating an entirely new product category.

There’s Superpowers, Jesse Vincent’s Claude Code plugin, which launched in late 2025 and is now at 139k+ stars on GitHub. There’s Compound Engineering by Every Inc, launched early 2026, which completely dominated my X feed for several weeks. gstack itself hit 50k stars within 16 days of launching in March. In a recent email exchange with Brad Feld, I found out about CEOS — his open-source EOS skills for Claude Code — and CompanyOS, a private skill system running his entire company with two people.

These are just four examples of independent, brilliant entrepreneurs who are all independently converging on the same architecture: an OS of opinionated, structured “superskills” for getting the best out of LLMs.

What makes a superskill? A regular skill file has maybe one of these. A superskill has most-if-not-all of them:

1. Ceremonial initialization: a preamble that gathers real system state and prints a header. You know a program started, not that Claude is thinking
2. Hard gates: phases that block progression until conditions are met. Not suggestions — if/else branches.
3. Structured user interaction: AskUserQuestion prompts, not questions buried in paragraphs.
4. Status receipts: every phase ends with a formatted block showing what happened.
5. Opinionated defaults: 80% of decisions are automatic. It only stops for things requiring human judgment.
6. Learnings capture: the skill logs what it discovers for future sessions.
7. Self-updating architecture: versioned, composable, cross-referenced.

Something big is obviously happening again, and this post is my attempt to understand it.

Observation #1: superskills provide “a harness for the harness”

As far as I can tell, this layer of superskill infrastructure is emerging at a perfect time.

It could just be my immediate circle, but I’m sensing a broader realization that implementation of AI, even for those of us that consider ourselves to be advanced, is much more difficult than we initially thought.

We’re living through a constant seesaw between “holy shit, I can do that” and “why did it break” or “will it ever NOT break?”

The issue is not the LLM’s raw intelligence.

Ironically, the frustration with AI is not that dissimilar from the frustration of managing an extremely high performing employee whose behavior is just erratic enough to question why you keep them on your team at all.

What gstack demonstrates to me is that part of the formula for managing these eccentric new employees is that you need to put a “harness on top of the harness.” In other words, there are now four clear layers to my AI stack:

• Layer 1: The Brain: this is the raw LLM, e.g. Opus 4.6 or GPT-5.4.
• Layer 2: The Body: this is a built-in harness provided by a program like Claude Code that wraps the brain and gives it arms and legs — the ability to actually accomplish tasks.
• Layer 3: The Role: simple skills and prompts that equip the body with a job (“e.g. you are a digital marketer, accomplish this task”).
• Layer 4: The System: the superskill provides structured methodology/coaching across multiple roles that allows raw material to be turned into actual value—a harness on top of the harness.

Because of the Guy Pearce problem and because of the general difficulty of managing a probabilistic entity (human or AI), Layer 4 is absolutely essential to creating scalable value.

To insert a sports analogy, Layer 3 is “you are a point guard,” and Layer 4 is “run the triangle offense.”

Observation #2: the first Lean Startup was a book, but the next will be a superskill.

What’s fascinating about superskills is that they don’t just encode knowledge, they also encode processes and coaching.

In this sense they exist in a new category that combines three previously separate domains.

• A book encodes knowledge
• A SaaS encodes a methodology/process
• A coach watches you work and corrects in real time
• A superskill does all three simultaneously, infinitely, for free

When Eric Ries wrote The Lean Startup (the startup book du jour when I started Offline), he was encoding knowledge paired with a systematic process for de-risking a startup idea.

But the business-self-help industry’s biggest problem has always been the gap between reading and doing. How many founders (myself included) read The Lean Starup, nodded dutifully, and then proceeded to violate every single principle in the book?

With superskills, you have the ability to take encoded knowledge and methodology (Lean Startup, High Output Management, EOS or any of these systems), and actually help people cross the chasm from hearing advice to enacting it in their own lives.

How many times have founders passed around Traction or Scaling Up or The Challenger Sale? How many instantiations of that knowledge died on the vine because they were read by well-intentioned people who were not able to actually effectuate the ideas?

The best of the self-help industry is somewhat useful when read, but extremely useful when practiced.

Observation #3: the “skill file ratchet” ratchets on

The third thing I would say is that these superskills represent another version of “the skill file ratchet,” something I’ve written about before and am fascinated by.

The core idea is that there are extremely strong, one-way incentives for brilliant people to open source their skill files in order to build their brand. gstack is literally the best possible example of the principle at work.

The catch is that doing so commoditizes hard-fought, hard-won wisdom forever. This is the one-way ratchet in effect.

Does the next founder really need to buy/read Traction when they can simply apply an open-source set of EOS skills?

Do they necessarily need to hire an EOS coach when they can record their leadership team meetings and pass them through those same skills?

How much less do they need to hire a designer when a superskill doesn’t just encode “make me a good design,” but strings together a series of highly specialized roles and opinions that take them from raw idea through to finished product interface?

To a certain extent, since the release of the internet, there’s been a tremendous amount of knowledge deflation. I remember when Stanford open sourced their computer science program and there was a lot of noise made about how anybody could learn to code now and the value of specialized knowledge was starting to deflate.

And there was some truth to that at the time.

But superskills represent a very specific evolution because they’re not just open-sourcing the knowledge, they’re open-sourcing the application of the knowledge: the patterns and grooves that people follow when they try to operationalize intelligence.

We’re in the early innings of encoding and open-sourcing experience, which is fundamentally different and more disruptive.

Ok, now for my personal experience

A couple of weeks ago, shortly after using gstack for the first time, I was reviewing an agent I had created that wasn’t working properly.

My first-principles belief about all AI successful implementation is that it exists at the intersection of well-understood process and carefully-curated context. It’s a hard-won, simple-but-wise paradigm that has emerged over the last decade of operating.

Because of this strongly held belief, every single time I begin to debug an AI process that is failing, I bring this specific worldview to the table during the diagnosis. Is this a process issue? A context issue? What do I need to do to find out?

As I was running this mental model for the 70th or 80th time, I realized that my mental model was just a superskill-in-the-making—that I could probably sit down and, if I tried hard enough, encode this process-and-context paradigm into a superskill that Claude Code could use to impersonate…me.

In other words, I could encode my experience and my unique point of view.

And it worked.

The next day our CTO was in town wrestling with a very challenging problem that exists precisely at the intersection of application code and business process. It was a problem he had been struggling with for weeks.

After force-feeding him this superskill, he resolved it in a single day.

That interaction was the start of what has become an enormous breakthrough in my productivity — the largest I’ve experienced since Opus 4.6.

Today when I open up Claude Code — the harness — I add my own harness by invoking my own superskill, which is essentially an infinite mirror of me invoking myself.

We’re all familiar with AI extending our ability to write emails or write code, but when it extends your ability to be yourself and to bring your unique point of view to a problem, and it does it reliably, that’s an entirely new thing.

The experience is impossible to describe.

I now constantly envoke a series of me-shaped superskills to create agents, debug agents, identify and create processes, diagnose processes, etc.

It’s no surprise that my “/shaner-consulting” skill is now my 2nd most used skill only 14 days after creating it. Why wouldn’t it be? It’s a skill file of myself, and I’m me.

I think it’s entirely possible that, over the next couple of quarters, we look back on the emergence of superskills as an unexpected and distinct stage in the evolution of AI.

Or as an engineering friend of mine recently said:

If you want to jam on anything related to superskills or AI in general, shoot me at note at david@davidmshaner.com

https://davidmshaner.com/

I’ve spent a lot of time reading hot takes on what AI is going to do over the next few years.

Most of it falls into one of two camps: either everyone’s going to lose their jobs, or AI is going to usher in some golden age of prosperity. Neither one describes what I’m actually seeing, and I’ve been trying to put my finger on why.

None of the takes seem to address the actual mechanics of how this is playing out at the individual level, on the field, between three distinct groups of players.

Before I get into the mechanics, let me define the players.

In every company, there are (1) generalists and (2) specialists. The generalist is the person who knows a little about a lot. This is the CEO who can talk product, finance, marketing, and engineering in the same meeting, or the founder who writes the pitch deck, reviews the contract, and mocks up the landing page all in the same week. They’re usually not the best at any one thing, but they understand how all the pieces fit together.

The specialist is the opposite. They know everything about one thing. This is the designer who can tell you why that button is 2 pixels too far left, or the tax attorney who knows the exact IRS ruling that applies to your specific situation. They’ve spent years going deep in a single domain.

Then there are (3) the labs — companies like OpenAI, Anthropic, and Google that build the AI models themselves. They’re the ones releasing ChatGPT, Claude, Gemini, and the other tools that both generalists and specialists are now using. Think of them as the arms dealers — they supply the weapons, and everyone else fights with them.

With those three groups in mind, let me take a stab at describing three distinct phases that I think play out over the next ~three years.

We’re in the first one right now.

Phase I (Now + Next 18 Months): The Rise of the Generalists

If you spend any time at all on X, you’ve seen the posts from the generalists. These are mostly founders like me who have turned into full-throated AI zealots because they wake up every day and can’t believe their luck.

I’ve been using Claude Code for 72 hours straight and you won’t believe that I just did ___.

They’re building landing pages in hours. Drafting pitch decks in minutes. Prepping for board meetings with voice dictation. Writing legal docs that are actually good.

All without calling in a single specialist to help.

But this makes sense when you back up and think about who these people usually are. These are people who’ve always been able to effectively direct work across half a dozen different areas, but usually had to delegate the actual execution of the work.

As AI has collapsed the gap between vision and execution, the generalists have been the best positioned to exploit it.

Again, I want to be clear about what I mean by “generalist.”

When I say “generalist,” I don’t mean pure middle managers with no real execution skills . I’m not talking about people throwing a prompt into Claude and thinking they can vibe-code a production app.

I’m talking about people who truly understand the fundamentals of many domains — finance, legal, product, engineering, marketing — and have an intuitive sense for the Pareto principle (the 80/20 rule) within each one.

They know that 20% of the effort gets you 80% of the result, and more importantly, they know which 20%.

In other words, to be a legit generalist, first-principles knowledge is a prerequisite.

I keep coming back to a basketball metaphor.

A center has a natural advantage in basketball — height. But that advantage has historically come with trade-offs. Centers historically couldn’t dribble or shoot like a point guard.

Now imagine you gave every 7-footer in the NBA 90% of the best point guard’s ball-handling and passing skills overnight. Not 100% — but enough that the positional lines start to blur.

It’s not obvious anymore why you need five distinct positions when the center can bring the ball up the court, run a pick-and-roll, and hit an open three at a reasonable clip.

That’s what AI has done for generalists. It has given them 90% of the specialist’s execution ability in every domain they already understood conceptually. And 90% turns out to be a lot.

Take the landing page as an example. Everybody remembers when AI first started making landing pages.

They were incredible for the fact that AI was making them at all — but they lacked taste.

Purple gradients everywhere. The same three fonts. No soul. The gap between “AI made this” and “a designer made this” was obvious to anyone with a decent eye.

But as a generalist who wanted to harness this new capability, I started trying to close the gap.

I got better at prompting — that helped, maybe 5%. I found a front-end design skill plugin (essentially a file that packages a real designer’s taste and judgment into instructions an AI can follow) — another 5–10%.

I noticed the animations still felt generic, the components not quite unique enough, so I found some UI component libraries and had Claude refine things further. Another few percent.

Each refinement got me a little bit closer, and all the while the underlying AI models were improving as well. Eventually, I could work with Claude to build a landing page and be genuinely blown away: a complete, functional, world-class, deployed page.

The difference between this landing page and the best landing page in the world? Pretty marginal.

The amount that a generalist can accomplish in February of 2026 is astounding, and the result is a power shift that is already underway.

In the labor market, we’re in the early innings of a tilt toward generalists and away from specialists — most visibly so far in copywriting, software development, customer support, and design.

So where are the specialists in all of this?

It’s not that they’re sitting it out. The leading-edge specialists are already experimenting. Some of them are already feeling the FOMO. They see what generalists are posting on X, and they can tell the gap is closing.

But for the majority? Their deeply embedded workflows still get them the 100% output they’re looking for. The raw AI output — the stuff they see out of the box from Claude, Gemini, etc.— genuinely isn’t good enough for them.

A great designer looks at what Claude produces and thinks, “this isn’t even close to my best work.” A financial analyst reviews an AI-generated pro forma and spots a dozen errors or things they’d do differently. The base output might hit 80% of the specialist’s standard, and that remaining 20% is exactly what they’ve spent years mastering. So they dismiss it.

What most of them haven’t fully reckoned with yet is what happens when a generalist who understands first principles gets their hands on the raw output. The generalist doesn’t just accept the 80% — they shape it, prompt it, refine it, push it to 90 or 95%. And suddenly the gap between “AI output” and “specialist output” isn’t as obvious.

And the generalist starts asking: is that last 5% really worth paying a specialist for?

I’ve seen this over and over for the last 18 months. Show AI-generated code to engineers — “not as good.” Show AI-generated designs to designers — “not as good.” And they’re not wrong. But they’re evaluating the base model, not what a skilled generalist can coax out of it.

My guess is that it will be this way for another 18 months before this fully plays out and the next phase takes over.

Phase II (18–36 Months): The Specialists Strike Back, aka The Return of Comparative Advantage

Back to the landing page example for a second.

My Claude-collab pages may have gotten pretty good, but still, if I look at them next to the best landing pages in the world, I notice the gaps. They might just be a pixel here, a subtle typography issue there, the way the eye moves through the page, etc., but they’re there.

And here’s the thing. I don’t just need one great landing page. I end up needing an entire site map of a dozen pages. And they all have to maintain consistent styling, copywriting, etc.

And that style has to cascade into my product. And into my email. And into my social.

That’s where I start to feel the limits.

Even with AI getting me 95% of the way there 10x faster than before, closing that last 5%, scaling it, and maintaibing it still requires me to become more of a specialist.

And as a generalist, I just don’t have the time for that. I may only have Monday for the landing page. Tuesday is the marketing campaign. Wednesday is sales. Thursday is legal and compliance.

That’s the generalist’s life. I’m 10x more productive than I used to be, but I’m still spreading myself across everything.

Once the generalists find where the sidewalk ends, I think we all rediscover the first principle of comparative advantage.

The generalists may start out ahead and get pretty far with their natural proclivity for AI and early adoption, but eventually the specialists catch up.

The designer eventually embraces the same AI tools I’m using and spends Monday through Friday on nothing but design. And that last 5%? It’s not hard for her to spot it and address it because she already understands it deeply.

She builds 15 landing pages in a week. She figures out how to create and maintain entire design systems using AI. She develops workflows and prompt patterns that consistently produce output at a level I can’t reach, because she can see things I can’t see and ask for things I don’t know to ask for.

The specialist armed with AI in their domain will eventually be more effective than the generalist armed with AI across all domains.

And when they respond, I think the benchmark for what “great” looks like resets entirely. Today’s best landing page was probably made by a designer using Figma or Framer, no AI.

Over 18 months, generalists using AI will produce work equivalent to today’s best. But by then, the new best will be whatever specialists-plus-AI are creating — probably something we can’t even imagine right now.

The bar will keep moving, and the specialists will be the ones moving it.

In other words, the point guard asks: “what do I do when the center can handle the ball?”

The answer: get really good at something the center still can’t do. And there’s always something.

Phase III (all along the way): The Deflationary Squeeze

Here’s where it gets uncomfortable for everyone.

In the old world, a generalist who needed a one-off landing page hired a designer. That cost maybe $2k. In Phase 1, the generalist looks at that and thinks, “I just replaced $2k with a $20/month Claude subscription.”

In Phase 2, the specialist reclaims the quality edge. The generalist goes back to hiring a specialist whenever they need that last 5–10%— just like before.

Comparative advantage may have won again, but the specialist’s economics have changed forever.

What used to take two days now takes two hours. They can charge a premium over the generalist’s output, sure. But they can’t charge the old premium, because every other specialist with the same depth is also producing at 10x speed. The supply of “world-class” work has exploded. Pricing compresses.

This is what I think Phase 3 looks like: everyone — generalist and specialist alike — is arbitraging on top of the same underlying models. The model is the commodity. The human layer is the margin. And as the models get better, that human layer gets thinner.

The specialist still has more margin than the generalist in their domain. But I think both are on a downward slope.

The Skill File Ratchet

There’s a mechanism that I think makes this deflationary pressure structural, not just competitive.

Remember those design skill plugins I mentioned earlier — the ones that helped close the gap between AI slop and real design?

What actually happened there?

Someone took a designer’s judgment and packaged it into a “skill file” that any generalist could install. The generalist didn’t actually get any better at design—they just plugged in someone else’s taste.

In the old world, a specialist’s knowledge was locked inside their head. It took years to develop and was incredibly difficult to transfer.

Even when a world-class designer posted YouTube tutorials showing their exact workflow, the generalist still had to invest dozens of hours watching, practicing, and failing before they could even begin to approximate the output.

The transfer cost of human skills was a huge moat for people in the labor market. The emergence of skill files obliterate that transfer cost:

1. A specialist builds a library of prompt patterns, workflows, and context engineering systems to get AI output that meets their standards.
2. They publish it on GitHub.
3. A generalist says “hey Claude, install this skill.”
4. They’re instantly upgraded even during cycles when the underlying AI model didn’t improve.

The friction of skill transfer goes from years of studying and failing to one prompt in the command line.

So why do the specialists keep open-sourcing their knowledge like this? Because the incentives are too strong not to.

Specialists who publish skill files and plugins gain reputation, followers, community, etc. Enough specialists find it worthwhile to share their hard-won intuitions and workflows for free that there’s a constant stream of new skills flowing into the ecosystem every day.

Sometimes, the specialists who are releasing these files are even employed by AI labs, and so the release of their skills is a net-gain for the lab’s brand without threatenign the specialist livelihood (for now).

So the specialist faces a double squeeze. From above, the labs keep improving the base models and shipping their own skill files. From the edges, other specialists keep externalizing their domain knowledge into transferable packages.

The differentiation layer doesn’t just get competed away by other specialists — it gets packaged and distributed to everyone, instantly.

This is a one-way ratchet that continually closes the distance between generalist output and specialist output and fuels the overall deflationary force.

So, What Holds Value?

The natural question is: so what holds its value when all of this plays out?

I don’t have a good answer yet.

The obvious ones — relationships, taste, trust, distribution — are probably true, but they’ve been said before, and I don’t think I have a unique perspective on that part of the problem today.

What I do think I have is a useful framework for the mechanics — the part I felt was missing from the conversation.

Generalists move first, specialists reclaim the quality edge, but all the while deflationary pressure squeezes everyone, accelerated by the fact that specialist knowledge keeps getting packaged into instantly transferable files.

I think that’s the shape of the next ~three years.

When I talk about the timelines of these phases, I want to be clear: I’m talking about how long it takes for these waves to wash over the majority of knowledge workers, not the leading edge. The bell curves overlap. Some specialists are already adapting and some generalists are falling behind. I’m attemption to describe when the center of the bell curve moves.

Yesterday I got an email from Scot Wingo inviting me on his podcast.

Scot runs the Tweener Fund — one of our investors at Offline and one of the more prominent funds in the Southeast — and he asked if I’d talk about what I’ve figured out with AI, because he thinks other companies could benefit from it.

Today, after launching my 5th parallel Claude Code instance, I thought “how would I even begin to explain what I’ve learned.”

Where do I start? What do I omit? How do I make it useful?

Over the last ~3 years I’ve gotten so deep into AI that it’s almost impossible to remember what work was like before it. As a father of 4, it reminds me of trying to remember life before kids. It essentially is gone from my memory.

What I decided to do here is twofold:

1. Attempt to retrace my steps — specifically and honestly — about how AI happened at one company so that I can share them for the benefit of others.

2. Do it using AI so I don’t spend my whole day writing a blog post.

I have an aversion to people who take their n=1 sample of how things happen or how things should work and try to extrapolate it out to broad generalization. Having said that, at the end, I’ll try to draw some general conclusions.

Take them with a grain of salt.

The Preconditions

Before AI showed up, two things were already true about how I operated. These two things ended up mattering more than anything else.

The First Precondition: Process Obsession

Offline has run on EOS for years. By 2022/2023 I’d spent somewhere in the range of 20,000 hours obsessively seeing every part of the business as either a repeatable process that needed documentation or an experiment in search of a repeatable process.

What that does to your brain over time is it instills this deep way of bifurcating the world into patterns and not-yet-patterns.

You get really good at decomposing work into sets of steps at increasing levels of abstraction. Maybe at first you document the steps for signing a contract and onboarding a restaurant. Over time you start to see the pattern in taking a sales call, extracting the new objections and market insights, and using those to re-evaluate your landing page and marketing material. Etc, etc.

Everything becomes a process or a process-in-waiting.

The Second Precondition: Packaging Context

As a solo founder operating across many domains daily, I was constantly context-switching. In a single day I might need to run a sales call with a restaurant, draft an investor update email, and finalize a landing page design in Figma.

Three completely different domains.

To make that work, I got better and better at capturing not just the process for each domain, but the context needed to execute in it. For the restaurant sales call, I could pop open my “Account Executive SOP” and re-read my meeting outline, my mindset statements, my objection-and-response library — and I’d only need a few minutes to get ready.

For the investor update, I had links to all my previous updates, and I knew the raw ingredients: our most recent board meeting notes, the product release notes, the top three issues from our last executive meeting.

I could load up context for a domain I only touched a couple times a month and be operating effectively in minutes.

Without realizing it, I was building the exact two muscles that would later make AI adoption feel almost natural: breaking work into processes, and packaging context so that someone — or something — could get up to speed fast.

These two muscles — process and context — show up at every stage of what happened next.

My AI Journey (Or “Where Does the Sidewalk End?”)

If you’ve ever used AI obsessively and iteratively and still hit a wall — the thing it just can’t do, the task where it falls apart — you’ve found where the sidewalk ends.

For years now, I’ve been iteratively evaluating tools and looking for that wall. And every time I think I’ve found it, the sidewalk gets longer.

In 2022–2023, the sidewalk ended pretty quickly. AI could write you a paragraph or a poem or a joke, but it couldn’t build you a product. In 2024, it could prototype a front end, but it couldn’t really ship a production app. In 2025, it could ship an app, but it couldn’t operate your business.

Each time, I’d bump up against the limit, file it away, and move on. And then a few months later, the limit would move.

Phase 1: The Copywriting Intern (2023)

We all remember when AI was basically good-enough copywriting and overhyped coding. Offline was already a process-driven company, so I immediately started scanning our process map for places where we could swap in AI. And for a while, it was a really effective intern. Write me a social media caption. Draft this email. Summarize these notes.

Useful. Not transformative.

But something happened very early on that caught my attention and was even more interesting than the outputs we were getting.

I was watching how people used AI on my team, and very quickly two buckets of people emerged:

• Bucket A would try to get the model to do something, they’d be unsatisfied with the output, and they’d blame the model. This thing is dumb. It doesn’t get it. This was most people.
• Bucket B had different instincts and was very rare. Rather than blaming the model, these people asked: what context or instruction is the model missing?

Bucket B people like me were able to hold two things in their minds simultaneously. One: this particular output wasn’t great. Two: the benchmarks these models are hitting are crazy, so the raw horsepower must be there.

In other words, if the output is bad, you should first look in the mirror.

It’s the same thing I’d learned managing people. When an employee does something you’re not happy with, some people reflexively blame the employee’s capability. Other people ask themselves what context that employee might have been missing. I found that this exact idea applies to AI.

The other thing I noticed was that most people were trying to swap AI in for an undefined workflow — “write me a blog post” — instead of decomposing the work into its component parts.

The more effective approach was to think about the preceding steps (e.g. extract the key insights from this phone call, turn it into an outline, use this voice, apply these QA edits), which then become raw material for a blog post.

Decomposing the work into smaller process steps, and giving the model the right context at each step, was the unlock. Most people weren’t doing either.

As we rounded the corner to 2024, AI was transitioning from good copywriting to good code, and I was mainlining all of it on X all day long.

For copywriting and marketing, I felt like we’d already found where the sidewalk ends — and we were putting our toes over the line daily. But for code? I didn’t know exactly where the sidewalk ended. I just knew it was further than our team was, it was moving fast, and I was watching a tiny number of people master it on X while I felt like we were on the sidelines.

If you’ve ever had a boss who’s wired like that, you know what comes next.

I started clipping videos, sharing links, asking questions, nudging, prodding, questioning — generally lobbing bombs at my technical people. The implied message was always the same: check this out. You should probably wake up and figure it out. Or if you don’t want to figure it out, we should figure out why you don’t want to figure it out.

If you’ve ever been on the receiving end of that kind of messaging, you know the dynamic too. You develop a healthy ability to pay attention but also kind of tune it out, because it’s your job to get actual work done and push priorities forward.

So it went like that for a while — me lobbing, the team nodding politely — until I decided to stop telling and start doing.

Phase 2: The Wake-Up Call (October 2024)

For the last year, people on X had been hyping this tool called v0. I had played with it once or twice, had been impressed by the vision, but had felt like I found the end of the sidewalk relatively quickly. But with everything going on at Offline, I hadn’t played with it since OpenAI had released GPT-4o.

I quickly found out that the sidewalk had moved a lot.

As I played with v0 and started developing some prototypes, I also downloaded Cursor for the first time and made my first Supabase account.

All of a sudden, this new way of building started to crystalize for me. I realized that a new layer of tooling was rapidly emerging and we were going to be left behind.

But I needed an actual project to stress-test it. I wanted to prove to myself and my team that this stuff wasn’t just X hype.

Something we’d always wanted to do at Offline (but never had the engineering bandwidth for) was build an integration with Square to pull in transaction data from any restaurant partners using Square and show the real impact of what Offline was doing for them.

I’m moderately technical (chemical engineering undergrad, been around software and engineers long enough to understand the basics), but I’m by no stretch of the imagination a developer — especially at the 3rd-party authentication and API layer.

So this was a perfect test.

I vividly remember pasting the Square developer docs into ChatGPT and talking through the problem.

Because I thought about everything as a process, I could articulate the problem as a clear sequence of steps: authenticate with Square, pull transaction data, isolate the Offline transactions using the transaction object schema, display these calculations on a dashboard with these views, etc.

And because my instinct was to load context, I pasted in the actual developer documentation, our actual current SOP, etc., rather than just saying “build me a Square integration.”

GPT-4o laid out the whole thing: here’s how you’d build it, here’s the front end, here’s the authentication flow, here’s how you’d save the auth tokens, etc.

I fired up Cursor and v0, put on my tunnel vision, and hacked away for several weeks.

When I picked my head up, I had

• a Square developer account
• successfull authentication from localhost
• the ability to ingest historical and new test transactions display them on sophisticated front-end dashboard, and parse out the Offline ones
• a multi-restaurat, scalable schema, etc.

In other words, I had a full-stack proof-of-concept application, and I hadn’t had to ask my engineers for help once.

That was a watershed moment for me.

At some point, I grabbed Taylor — our head of product, who sits across from me — I was like, ”Hey, come over here. You need to see this. This is crazy”

Phase 3: The Production POS Integration ($10k, 60 days)

That moment opened the floodgates in two important ways:

1. It showed the technical feasibility of the technology in the hands of a non-developer, something that I know my team (and even I) still had some doubts about at that point in time.
2. It kicked off a healthy peer competition between me and the rest of the team for who was “ahead” in their mastery of AI. It’s like in a family when one day the little sibling beats you at something you used to beat them at. It created a healthy escalation of skills.

To up the ante, I decided to take the POS integration proof-of-concept, expand it, and bring it to production. My goal was to do it in 60 days while also juggling everything else that goes with running a company.

To increase my leverage, I ran a hiring process on Upwork. I realized that if I could find an overseas developer who was also an early adopter of these tools, I’d get both the leverage of AI and the cost arbitrage of offshoring. I ended up working with a development company in Pakistan.

Our contract kicked off on December 29th, and by mid-February we had live integrations with both Square and Toast and launched them across a handful of our restaurant partners. The entire project, start to finish, was less than $10,000 and we finished it in under 60 days.

And again, this was something I was managing on the side — one of many threads I was pulling on at the time.

The reason this moved so fast wasn’t just the tools. It was that the business process of partner impact tracking was already clear in our SOPs. We knew what data mattered, how the outputs needed to be shared, what other data it needed to be packaged with, etc.

In other words, the process was mapped and we just needed the software.

For our company, this POS integration software was seismic. For the first time, we could see real-time transaction data and the real-time impact that Offline was having on our partners.

Something that was previously out of our reach came within it because of AI and completely transformed our value proposition on the merchant side.

For our culture, it was yet another AI proof point. This app had a complex front-end dashboard that looked like a venture-backed SaaS company, complex database queries, a thorough data ingestion engine, etc. It was also the first time any of us had run an application that started from scratch on Supabase.

The whole thing was eye-opening.

The most important lesson it taught us was this: building with AI when you’re starting from scratch is incredibly fast. Contrast that with trying to build with AI inside an existing, large codebase — which felt slow and cumbersome, because the amount of context the model needed to operate effectively just wasn’t there.

Phase 4: The Cambrian Explosion (April–August 2025)

That greenfield vs monolith insight unlocked a new wave of building.

We realized the move was to build internal APIs that let us pull data out of our monolithic codebase and into these rapidly deployable apps. It’s like building tributaries around the main river — you’re diverting water flow so you can move in parallel.

Every app was taking a piece of a process we had already defined and turning it into software.

In April 2025, the Cambrian explosion happened. We went from one GitHub repo to six active repos that we were committing to on a regular basis with the same number of employees:

• We built on the point-of-sale integration app.
• We built an events app for partners to self-service create events.
• We built a case studies app that pulled in all our POS and backend data into elaborate dashboards for partners.
• We built an Instagram tracking app.
• We built a content creator portal.

It seemed limitless. Have a process bottleneck? Hit the internal API, pull the data out, build the thing.

From April to October, we probably built more net-new software than we had in the previous three or four years.

This only worked because of both muscles. Process: each app mapped to a business process we’d already articulated in The Offline Way. Context: we had unlocked a ton of our data through internal APIs, and MCP connections were rapidly proliferating for everything else (Hubspot, ClickUp, Github, etc.).

Taylor, our head of product, was pushing more GitHub commits than anyone else because he was weaving in and out of internal APIs and building new apps—not boxed in by the monolithic database and code structure he had to maintain.

This was one of the first times I could really see how software engineering was going to change.

Moderately technical people who were really good at problem-solving were going to play a unique role alongside traditional engineers.

I also realized that any company started in the pre-AI era would need a specific first-principles pathway to make the transition: internal APIs, building around the main application, pushing and pulling in and out of it — not trying to transform the monolith itself.

Phase 5: The Juxtaposition (Fall 2025)

By around November 2025, me, Page, and Taylor were all effectively engineers.

And this is when something weird started happening.

I was constantly reading and hearing about pain points that companies were having with AI — all while we seemed to be moving through it at 120mph.

I routinely saw prominent people on X calling out vibe coding as only good for prototyping. Threads saying “show me one useful thing vibe coding has actually built besides a rip-off of Trello.”

I was looking around our company thinking: dude, this has transformed our whole business, what are these people talking about.

What made this hit hard was that I was seeing these struggles from really smart, really successful people — across industries — wrestling with the same problems I’d first observed back in the intern phase in 2023.

They were blaming the model’s capability. They were trying to get AI to do entire workflows in one shot. They weren’t decomposing the work. They weren’t packaging context.

The patterns I’d noticed on my own team in 2023 were playing out everywhere, at scale, in 2025, but they were now happening with the backdrop of existential fear of being left behind in the AI wave.

Phase 6: Sales Automation and n8n (August–November 2025)

As Taylor and Page took on more of the frontier vibe-coding work on the application side, I jumped to the next opportunity I saw: applying AI automation to sales operations.

I’d already used Zapier for years. We’d built little things — press an AI bot icon in Slack and have something happen with the OpenAI API. They were cute, but not business-transformative.

I’d worked briefly with an AI and automation consultant in June and seen the power of applying models to lead qualification, so I dove into n8n around August or September 2025.

Going back to the idea that Offline was already a process-driven company, I was able to pull up our sales process (which starts with ingesting data to create leads, then enriching those leads, then qualifying them, then reaching out), and I just started taking it apart piece by piece using workflow automation with AI.

There were two ways this was powerful.

1. You can inject AI reasoning directly into the workflow path. Take our qualification criteria — we won’t work with a restaurant if it’s a chain, if it has low ratings, if it’s a food truck. Previously, a human had to make those calls because they were nuanced. Now I could have an LLM in the automation chain that could take in that context and make a judgment about whether a lead should be qualified.
2. AI writes the glue code you can’t write yourself. A lot of these workflows require transforming data — and n8n has code nodes where you can inject JavaScript or Python. I can’t write JavaScript. I can’t write Python. But I can say ”here’s the structure of this JSON going in, and I need it to look like this coming out”*— and Claude writes the code node for me.

That’s not just AI doing the task. That’s AI letting me build the machine that does the task. Different level of leverage.

The context lesson also showed up here in a specific way.

AI was pretty bad at building an entire n8n automation front to back from scratch, especially when it involved APIs that it wasn’t familiar with.

So I had to think about the right context to give it just to write *one node* correctly at a time, validate it, and continue. I ended up building what I called my “n8n cookbook” — a massive file full of pre-configured nodes: Pre-configured HubSpot nodes, pre-configured Offline API nodes, pre-configured Gmail nodes, pre-configured code nodes, etc.

All of them were like pre-built Lego blocks that I could stitch together to create a workflow quickly — or that I could point Claude to if it needed to understand correct node implementation.

The cookbook was the context-packaging instinct applied to automation. Same muscle, new domain.

This culminated in about 40 production n8n workflows doing everything from scraping websites for leads to enriching and qualifying leads to matching them to companies to writing outreach briefs.

Phase 7: Claude Code and the Singularity (August 2025–Present)

I started using Claude Code in August 2025. I was on a trip to Austin and had a Saturday alone in a hotel. I’d heard about Claude Code and decided to dive in.

I couldn’t stop.

I was using it at the hotel. Hotspotting in the Uber to the airport. My flight was delayed — I used it the whole time. I paid for Wi-Fi on my flight to keep going.

The experience of giving AI arms and legs — taking it out of the browser, out of a desktop app, putting it right into the terminal — is just crazy. For someone who’d been playing with this stuff for a few years, you could immediately see this was where it was all heading.

But you could still find where the sidewalk ends. Claude Code would still trip out, make a lot of major mistakes, and sometimes I would just hop back into Claude Desktop or ChatGPT for the simplicity.

And then, in my opinion, the singularity happened on November 25th, 2025 when Anthropic released Opus 4.5.

I remember in early December, me and Taylor being on Google Meet calls, just talking about how something fundamental had changed. The tasks that Claude Code could take on were just on a different level.

I’d always been fascinated by the idea of an AI Chief of Staff, and so I started stress testing it. My mantra was: “I should start every single thing I do in the terminal.”

If there was a task I wanted Claude to do and it didn’t have access to the process or context, it was my job to document that process and pull in that context.

This was the process and context muscles fully industrialized. “Start everything in the terminal” is a process discipline. Skill files, system instructions, MCP servers, API access — that’s all context packaging, systematized. I went from doing it informally for myself with SOPs and meeting outlines to building a literal system that loads context into AI agents at startup.

And it turned out there was just not that much left that it couldn’t do.

Create a new logo. Done. Create a new brand. Done. Build landing pages. Done. Use our internal API to build dashboards. Done. Build new applications. Done. Suck in all my n8n workflows every day and build me an AI automation manager. Done. Print all my kids’ school emails on my home printer so I actually read them. Done.

Now I start every day in a local repo called Chief of Staff. I spin up anywhere from 2 to 6 Claude Code instances that all operate at different altitudes in the folder structure, and I just get to work.

It’s not an exaggeration to say I’m 10x more productive than I was a year ago.

Some things are probably 50x.

The amount of stuff that me, Page, Taylor, and Steve on the Offline team will ship in January 2026 is at least six months of work in the old world.

The Guy Pearce Test

Now that you’ve seen the journey, here’s the mental model that I think captures the whole thing.

I’ve written about this before, but the single most useful framework I’ve found for understanding AI is the movie Memento.

Guy Pearce plays a man trying to find his wife’s killer while suffering from short-term memory loss. Every time he wakes up, his memory is wiped. So he has to leave clues for himself — tattoos, polaroids, notes — so that when he wakes up tomorrow, he can look at them and reload who he is, why he exists, and what his purpose is.

An AI agent is no different. It wakes up with no memory. Your job is to leave it the right tattoos — process instructions and context — so it can orient itself and get to work before its memory runs out.

But if you haven’t seen Memento, let me put it in terms that are a little closer to home — and a little closer to why I’m writing this post.

Imagine someone like Scot Wingo shows up at your company and offers to work in your company for one hour every day. He costs 20 cents/hour. The catch: he forgets everything at the end of each hour.

There are three types of people who encounter this offer.

The first group says: That seems like too much trouble. I already have employees who don’t forget everything every hour. They cost more than 20 cents, but I’d rather just do business as usual.

The second group tries a session with Scot. They spend 55 minutes trying to get him up to speed, get 5 minutes of productive work, and then he forgets it all. They decide he’s just not that smart, and they give up.

The third group sees beyond that. They think: I know he forgets everything. I know I only get an hour. But he’s really, really smart — and he’s 20 cents. I’m going to figure out how to make this work.

So the first day, it takes 55 minutes to onboard Scot and you get 5 minutes of real work. But the next day you learn from that. You figure out how to shorten onboarding to 50 minutes. You get 10 minutes of work. You write everything down so he knows what he did yesterday.

And you keep going. You realize Scot has superhuman reading speed. You get onboarding down to 5 minutes. You get 55 minutes of productivity. You get him to take notes along the way for tomorrow.

And now you have infinite Scot Wingo labor for 20 cents an hour.

That’s the game.

The difference between the people who win and the people who give up is process and context — the ability to break down the work so Scot can execute it, and the ability to package context so Scot can get up to speed fast.

A Few Generalizations (With a Grain of Salt)

This is one company’s story. Limited sample size. But a few things feel like they generalize.

1. AI implementation lives at the intersection of process and context.

If you can’t break a problem down into a process and document it, AI can’t run it. If you can’t package the context needed to execute that process, the AI will flounder. The companies and people succeeding with AI tend to already be strong at both — or they get strong at both fast.

2. When the model gets something wrong, it’s almost always a context problem.

This is the single most important mental model shift. When AI gives you a bad output, the instinct is to blame the model’s intelligence. Nine times out of ten, the issue is that you didn’t give it what it needed. The model is a genius with amnesia. Your job is to get better at packaging what it needs to know.

3. Greenfield beats monolith.

If you’re a company that existed before AI, don’t try to transform your main application with AI tools on day one. Build internal APIs. Pull data out. Build new apps around the edges. Move in parallel. The tributaries strategy is dramatically faster and gives your team real wins while your core codebase evolves at its own pace.

4. Someone has to lead by doing, not just by telling.

The inflection point at Offline wasn’t when I told my team about AI. It was when I built something with it that was previously impossible and then showed Taylor and Page. The peer pressure of doing is orders of magnitude more powerful than the peer pressure of talking.

5. The moderately technical, entrepreneurial problem-solver is a completely new animal.

There’s an emergent role — someone who isn’t an engineer but has a founder mentality, strong problem-solving instincts, and enough technical fluency to work with AI tools. That person, armed with AI, can do a lot more than they used to be able to. This changes the math on who builds what inside a company, and I’m still not clear on the long-term implications.

6. “Where does the sidewalk end?” is the right question to keep asking.

Every few months for the last few years, I thought I’d found the limit of what AI could do. Every time, the sidewalk got longer. The people who gave up at any point along that timeline — at the copywriting phase, at the vibe-coding-is-just-prototyping phase, at the it-can’t-work-in-my-codebase phase — left enormous value on the table. The right posture is to keep probing.

That’s how AI happened at Offline.

It started with years of process discipline and context packaging that I didn’t know would matter.

It accelerated when I stopped telling my team and started showing them.

It exploded when we figured out the tributaries strategy.

And it became the default operating mode when the models got good enough that the only remaining bottleneck was how well I could document what I wanted done.

As far as I’m concerned, the singularity happened on November 24th, 2025 when Anthropic released Opus 4.5.

We crossed a threshold.

AI agents went from a nice theoretical — requiring constant human-in-the-loop guidance — to the default way I attempt to run any new initiative in my life. Everything from complex organizational planning to printing out school emails on the printer behind me now starts with a Claude Code agent.

There’s a lot of hand-wringing about “agents” — a lot of misunderstanding about what makes them work and why they fail. In my experience, the single most useful framework for understanding agents and their limitations is the movie Memento.

Guy Pearce plays a man trying to find his wife’s killer while suffering from short-term memory loss. Every time he wakes up, his memory is wiped. Because of this condition, he has to leave clues for himself — tattoos, polaroids, notes — so that when he wakes up tomorrow, he can look at them and reload into his mind who he is, why he exists, and what his purpose is.

An AI agent is no different.

An instance of Claude Code has a 200,000 token context window. That’s the equivalent of Guy Pearce’s 24-hour memory. As that instance wakes up, you equip it with tattoos: skill files, system instructions, MCP servers, API access. You attempt to provide as much context as efficiently as possible so it can orient itself toward your desired task before it runs out of tokens and has to compact.

A bad tattoo: “You are a helpful assistant for a restaurant company. Help manage accounts receivable and follow up on late payments.”

A good tattoo: A skill file that maps all 47 partners to their payment terms, an MCP server connected to the accounting system, a markdown doc with escalation rules and email templates, and a system prompt that says “You are the AR agent. Read the skill file first. Never send an email without checking payment history.”

The difference isn’t intelligence. It’s context.

Now imagine running a company or complex process composed of fifteen different Guy Pearces. You can start to see the architectural challenge of building a multi-agent system.

It requires a different skill set than being the executor. You become the tattoo artist — the person who thinks through the most efficient, effective, and clear way to leave behind clues for agents about who they are, what their purpose is, and what your desired outcome is.

Just like in Memento, a lack of clarity or an inefficient use of a day can compound over time. You wake up having solved the wrong problem. Or worse, you solve the right problem wrong.

But here’s where the metaphor breaks down — and where most people’s intuitions fail them.

In Memento, Guy Pearce is a smart but relatively average person. In the world of AI, each agent is effectively a genius.

This is incredibly misunderstood. When models give bad outputs, people build incorrect perceptions about the model’s intelligence. But think about it: these models have read more than any human ever will. They can write code, analyze contracts, debug systems, and synthesize research across domains — all in seconds. The raw capability is there.

Nine times out of ten, the bad output had much more to do with the tattoo artist than with the agent. Or it had to do with expecting the agent to remember information you gave it yesterday — after it fell asleep and its memory got wiped.

The game of 2026 is building an army of Guy Pearces. The people best equipped to win are the ones practicing their tattoos.

In fact, after searching, I couldn’t find a single detailed real-world example.

So I decided to create one.

The Why

In response to the macro pressures of 2024/2025, consumers are leaning hard into value in their purchases.

My go-to visual for this is the 2024 stock chart for Walmart (black) vs Target (blue):

We wanted to respond to these pressures by making Offline feel like even more of an undeniable deal. A stupid-no-brainer.

Before the test, our standard pricing was $120/year or $15/month. In exchange, Members received two restaurant credits per month that typically saved $10-$30 per meal.

Our test pricing cut the first year to $59, with 1-year renewal still set to $120.

Left-digit bias makes $59 feel meaningfully cheaper than $60, and more than 50% cheaper than $120.

Rather than running a perfect A/B test (which takes months at our scale), we funneled all traffic to this new price to get fast, actionable data.

Short, Medium, and Long-Term Impact

When you change pricing, there isn’t an immediate single metric that determines success. Instead, there are a series of success checkpoints over a long period of time.

1️⃣ Short-Term: The Signup Funnel & Trial Conversion

When a potential subscriber starts a 30-day Offline trial, they commit to a plan and give us a credit card up front.

We expected lower price to immediately increase the conversion rate from site visitor to trial, and it did. Here was our full-funnel conversion rate before and after the price change:

Full-funnel conversion rate increased ~30%, which was not nearly enough to offset the price cut and indicates that a solid chunk of our potential subscribers are not price-sensitive at these prices.

However, the compounding effect was that it shifted a huge chunk of audience towards annual trials because of the even steeper deal on annual:

We also saw a nominal increase in free-to-paid trial conversion rate. This makes intuitive sense, since being willing to pay $59 when your trial ends seems more broadly appealing than paying $120:

However, the increase wasn’t statistically significant, which suggests that trial conversion is driven more by product experience than price.

In other words, once someone starts a trial with Offline, it doesn’t really matter if the price is $59/Y or $120/Y — their decision to convert depends more on how good Offline’s product is.

This combination of changes led to a slight increase in revenue from the $59/Y cohort, despite a 50% reduction in price:

An astute observer might notice that the first group actually had more overall traffic — so if traffic had been the same in both periods, the revenue increase would have been even bigger.*

That’s true, and an easy way to think about that is to standardize to Revenue per Site Visitor:

Once you’ve standardized based on Revenue Per Site Visitor, you can adjust the Revenue at Conversion as if the $59/Y cohort had the benefit of 22,336 site visitors instead of 20,629:

This gives a much more accurate picture of what would have likely happened in a controlled A/B test: a 10.7% lift in revenue by cutting price 50%

2️⃣ Medium-Term: Year-One Renewal & Retention

Since our price adjustment successfully cleared the first checkpoint, we can move on to the second: what happens post-signup?

Even though more people choosing annual plans boosts short-term revenue, it also means that revenue is being “pulled forward.” It’s possible that the higher share of monthly users at the $120/Y price point could lead to more revenue over time.

Of course, the only way to know for sure would be to wait a full year annual subscribers in those cohorts to renew and for monthly subscribers to contribute a year’s worth of payments — but startups don’t have that kind of time.

So instead, we modeled the long-term impact using real historical churn data for both monthly and annual plans. Here’s what we found:

• The $59/Y + $15/M plan generates more revenue at conversion.
• The $120/Y + $15/M plan briefly pulls even around month 10.
• Once annual subscribers come up for renewal, the $59/Y plan pulls way ahead for two reasons: 1.) it has a much higher percentage of annual subscribers and 2.) the price is $59/Y for the first year and the renewal is at $120/Y.

Assuming that $59/year subscribers will renew at $120/year is a big assumption. But the fact that the trial-to-paid conversion rate didn’t change much with the price drop suggests something important — if people like the product, they’re probably willing to pay $120/year for it.

That said, it would be responsible to run the worst-case scenario that we can only generate renewals at $59/Y. Here’s what that looks like:

• Assumes 100% of subscribers who signed up at $59/Y renew at $59/Y and 100% of subscribers who signed up at $120/Y renew at $120/Y.

In a worst-case scenario, these two plans are essentially neck and neck. All of the long-term revenue upside potential is with the $59/Y plan.

3️⃣ Long-Term/Strategic: Multi-Year Behavior & Market Penetration

In looking specifically at price, we’ve glossed over an important strategic point in pricing shifts: total volume of active subscribers and market penetration.

A reduced price leads to more active subscribers, and with more of those subscribers on annual plans, a longer lifespan for each active subscriber.

Here’s what that looks like (normalized for the same amount of site traffic per cohort):

For Offline as a marketplace business, more active subscribers compounds into more value for restaurants, which strengthens our flywheel.

If we can pull in more active subscribers at the same revenue levels, it’s a good strategic decision for us.

The Real Debate: Capturing Value Now vs. Creating Asymmetric Value

This test isn’t just about pricing—it highlights a fundamental tension in any subscription business: do you capture margin now or do you attempt to create asymmetric value to grow.

Here’s the gist of that argument:

Approach #1: Capture Value Immediately

• Every transaction should be fair and balanced—customers pay for exactly what they get. They don’t feel like they’re getting a too-good-to-be-true deal, but they also don’t feel like they’re getting screwed.
• This biases towards business sustainability and avoids attracting the wrong consumers.
• The risk? It can slow adoption and limit network effects.

Approach #2: Create Asymmetric Value to Drive Scale

• Transactions feel “too good to be true.”
• This biases towards business growth and network effects, sometimes at the expense of profit or sustainability. Examples abound: Facebook’s cheap early advertising rates, Uber’s cheap early prices, Costco’s $4.99 rotisserie chicken, etc.
• The risk? You’re betting on future value creation, and you might be wrong.

For Offline, we believe in the long-term value of a stronger marketplace. If we can scale faster without sacrificing revenue, that’s a strategic win.

What We’re Watching Next

This test isn’t over, and we’ll continue to monitor a few key things over the next year:

1. Subscriber spend & audience quality. As a marketplace, we have to be careful about attracting customers that damange our reputation on supply side. Luckily, we have extremely sophisticated systems in place for measuring consumer spend at restaurants, so we can measure the impact direclty.
2. Behavior change. Does a lower first-year price have negative affects on usage, renewal rates, etc. Only time will tell.

* and they might notice that if you manually add up the conversion data in the table you won’t get the exact revenue number. This is due to two of our cities having slightly different pricing structures.

A $10,000 Lifehack — For Free

If I told you that you could save you 15 minutes a day for the rest of your life, and it was totally free — no gadgets, no subscriptions, no learning curve — would you believe me?

Because that lifehack exists.

It’s called keyboard shortcuts.

Most people don’t realize it, but they’re sitting on a goldmine of time every single time they type.

A few small habits — copying, pasting, switching tabs, searching — done multiple times a day, could be done 3x faster. And once you learn the shortcuts, they stick for life.

Let me show you how much this time is worth.

The Drop-Off Line Story

At a school auction I recently attended, a parent bid $10,000 for a pass that let them skip the carpool drop-off line every morning.

That line takes about 10 minutes a day.

But they weren’t buying a parking spot — they were buying back time.

Time they could spend with their kids, or getting to work, or just breathing. That parent saw what many of us miss: time is worth more than money.

Now zoom out. How many digital drop-off lines are we stuck in every day?

Every time you move your hand to the mouse, hunt through a menu, or repeat a tiny task you could automate with a keystroke, you’re waiting in line.

Shortcuts are how you skip it.

Introducing Shorty

Shorty’s mission is to take one of the most universally useful, shockingly overlooked skills in computing — keyboard shortcuts — and make it fun, easy, and sticky to learn.

Because this is bigger than personal productivity. Let’s take a look:

• There are over 60 million knowledge workers in the U.S.
• 15 minutes saved per person, per day = 3.1% productivity gain in an 8-hour day
• That’s millions of hours of increased productivity — every day.

This is a cheat code for the modern economy. And no one’s teaching it.

So we are.

One keystroke at a time.

On one extreme, we can evaluate people (or ourselves) based on the effort they put in, such as the number of hours worked or tasks completed.

On the other, we can focus purely on output, like how many sales were made or how many features were shipped.

Both measures have merit, but both also carry significant pitfalls when viewed in isolation.

The Two Extremes

Measuring effort alone can be tempting. After all, more activity should theoretically translate into more results.

The problem with this thinking is that it assumes all effort is equally effective. Someone can be extremely busy — making endless phone calls, attending meetings, cranking out code — but without much to show for it.

Solely rewarding effort is essentially rewarding busyness for its own sake, and effort becomes divorced from impact.

You might end up paying people to push buttons, but not necessarily to make progress.

On the other hand, focusing solely on output — what someone achieves — is actually equally problematic.

If you only measure the outcomes, you could easily overlook whether someone is working to their full potential.

It’s actually pretty common, especially as people become more experienced, for someone to be able to hit their targets with minimal effort, achieving “just enough” to meet expectations without really pushing themselves or the business forward.

In this scenario, the company ends up underutilizing talent and wasting resources, because people could be achieving far more.

Sales and Fishing

To make this idea more concrete, let’s use the quintessential example of effort vs productivity: sales.

In sales, you can either measure someone by their activity (calls made, emails sent, meetings booked) or by their output (sales closed, quota attained).

Measuring only one of these metrics gives an incomplete picture of performance.

Compare sales (or any role) to fishing.

If you measure only by the number of fish caught (quota/goal attainment), you’ll end up with people who can hit their targets with just a few hours of effort.

Maybe they’ve found a lucky spot where the fish are biting that day. Maybe they’ve gotten better at reading the pond and finding the opportunities every day.

Either way, this looks like success superficially.

But is it really?

If someone can hit their target with minimal effort, it begs the question of what more they could achieve with a full day on the water.

Are they fishing to their potential? If not, the company (and the person) is missing out.

Alternatively, if you measure only by how many times someone casts their line (activity), you will obviously also run into trouble. Lots of casts might suggest hard work, but if there are no fish being caught, that effort isn’t translating into results.

Just because someone is making 100 calls a day doesn’t mean those calls are strategic or effective.

Paired Indicators

In Andy Grove’s High Output Management he addresses this paradox through the concept of paired indicators.

Grove argues that certain metrics must be paired with others to give a full understanding of performance. In isolation, a single metric can be misleading.

Activity and output are perfect examples of paired indicators.

When we only look at activity, we reward people for staying busy without ensuring that their busyness drives results. If we only look at output, we miss the opportunity to push people to higher levels of performance.

When paired together, we can make adjustments to ensure people are both working hard and working smart.

The Role of Great Management

One of the things that separates good managers from great managers is their ability to a.) recognize the necessity of tracking both effort and output and b.) help each of their direct reports navigate this duality based on their unique circumstances.

There’s no simple formula for knowing when to push harder on effort versus effectiveness — it’s case-dependant.

The real magic happens when a manager can discern whether a person is underperforming because they’re coasting to their goal or because their max effort isn’t translating into results.

This requires close attention to both the activity levels and outcomes of each individual — something a manager who is only focused on one or the other will miss.

The Objection: “Isn’t Quota/Goal All That Matters?”

In the context of an early-stage startup, this objection isn’t just flawed — it’s dangerous.

In a startup, the goal isn’t just to meet expectations—it’s to exceed them and continuously find the ceiling of what’s possible.

If someone can hit their goal with less time and effort than expected, it’s a signal that we’ve set the bar too low. And in a startup, where every ounce of potential matters, that’s a major problem.

The mindset that “the goal is all that matters” fails to recognize the need for constant exploration.

If people can consistently hitting targets with minimal effort, you’re leaving value on the table. And if you’re leaving value on the table, the company is effectively wasting money.

Everyone at a startup, from top to bottom, should be asking, “What more can I do?” If there’s untapped capacity, it’s up to both the individual and the manager to raise the bar, find additional value-adding activities, or push for steeper quotas.

Wrapping Up

The paradox of effort vs output is something every company and every individual grapples with.

The highest performing people and managers understand that measuring both is essential, because each metric on its own gives an incomplete picture.

It’s not enough to just be busy, and it’s not enough to meet expectations with leftover capacity.

It’s about pairing effort with results and pushing beyond the limits of what we think is possible.

Why Level 10 Meetings Matter

In the early days of Offline, before I started using Level 10 meetings (better known as “L10s”), my meetings were a mess.

There was no rhythm, no structure — just a chaotic scramble whenever something urgent came up.

We didn’t have a regular time set aside for discussing the most important issues, and as a result, things got missed. Problems festered, and the company lacked real accountability.

The first time we ran an L10, I realized how much we’d been missing. The structure forces you to focus on what’s important: tracking your company’s biggest priorities (rocks), holding people accountable through measurable numbers (scorecards), and solving real issues (IDS).

All of a sudden, we had a framework to make sure the right things were getting discussed and moved forward.

But even a great framework isn’t a silver bullet—it’s only as good as the person running it and the people participating in it.

I’ve made mistakes with L10 meetings — plenty of them — and I’ve seen how easily they can go off track.

Here are the biggest pitfalls I’ve encountered when running L10 meetings.

Pitfall #1: The Leader’s Meeting Trap

One of the biggest problems I’ve run into is turning the L10 into “my meeting.”

When the meeting leader is the one adding all the issues to the list and suggesting all the solutions, something’s wrong. It’s a clear sign that the team isn’t engaged, and the leader is carrying too much weight.

The L10 is supposed to be a collaborative meeting.

If it’s not, it’s a clear sign that the rest of the team either isn’t comfortable speaking up, or they don’t feel responsible for identifying issues.

And when the leader is the one coming up with all the solutions, we’re missing out on valuable perspectives. The best solutions come from the team — not just from the leader.

Pitfall #2: Scorecards That Don’t Matter

Early on, I noticed that our scorecard updates started feeling like a formality.

We’d go through the numbers, but it felt like no one really cared.

If the numbers were red, there was no urgency. If they were green, no one felt proud.

The team wasn’t emotionally connected to the results, and that’s a big problem.

The scorecard only works if people feel responsible for their numbers.

It’s supposed to create a sense of ownership — where the team feels the pain of a red number and celebrates a green one. If that’s not happening, the scorecard becomes just another meaningless routine, and the team isn’t really bought in.

Pitfall #3: Trying to Cram Everything Into One Meeting

There was a time when I used the L10 meeting as a catch-all.

Every conversation, every update, every decision — it all went through the L10.

But the more I did this, the more bloated and inefficient the meetings became. The L10 started to lose its focus because we were trying to do too much in one sitting.

I’ve learned that not everything needs to flow through the L10. It’s a meeting specifically for focused execution around the most important issues and numbers.

Other conversations — quick updates, tactical discussions, or smaller problems — should happen outside the L10.

Trying to do everything in one meeting is a mistake that makes the L10 less effective.

Pitfall #4: Misusing the Issues List

At the beginning, I encouraged the team to put everything on the issues list. I wanted to foster participation, so I didn’t filter anything.

But as time went on, the issues list became a dumping ground for every minor annoyance. We’d waste time discussing things that didn’t really matter, and important issues were getting buried.

There’s a balance here.

You want people to feel comfortable raising issues, but it’s the leader’s responsibility to help shape and coach what belongs on the list.

Some problems are better handled through a quick Slack message or phone call, while others need more in-depth discussion.

The L10 issues list is for the big stuff — the problems that could derail the company or block our progress.

Pitfall #5: Using the Wrong Metrics on the Scorecard

Figuring out the right metrics for the scorecard can actually be really hard.

Traction tells you to focus on “leading indicators,” but in a startup, it’s not always that simple.

Sometimes, you don’t have enough repeatability to even know what your leading indicators should be.

It’s better to wait until you have some repeatability before you lock in weekly scorecard metrics. In the meantime, I’ve found it’s helpful to track experiments and report on what’s working and what’s not.

You can always add weekly metrics later once you know what’s actually moving the needle.

Pitfall #6: Not Doing the Pre-Work

The L10 isn’t magic — it’s part of a bigger system.

I’ve had weeks where the L10 felt disconnected, and it’s always because we hadn’t done the work outside the meeting.

If the team doesn’t have clarity on the company’s vision, priorities, and key metrics, the L10 can’t do its job.

You can’t expect the L10 to fix everything on its own. The real work happens before the meeting — figuring out what matters, getting the team aligned, and making sure everyone’s on the same page.

Without that foundation, the L10 becomes a band-aid, not a solution.

The Right Way to Hold an L10 Meeting

After running literally hundreds of L10s, here are two things I’ve learned about the right way to run an L10:

#1: A great L10 meeting should feel pretty simple.

Simple doesn’t mean easy or calm. Simple means it shouldn’t feel overly complicated or forced. When everyone is aligned on the vision, priorities, and metrics before the meeting starts, the conversation flows naturally.

#2 The L10 isn’t about the leader — it’s about the team.

If you do the hard work of creating a space where people feel responsible for the numbers, empowered to bring up issues, and committed to solving them together, then L10s are an incredibly powerful tool for execution.

But sculpting doesn’t stop when the meeting ends. In fact, one of the most crucial, yet often overlooked, areas where sculpting needs to happen is in the day-to-day work of a startup.

Startups live or die on execution. But more often than not, that execution is filled with undocumented processes, workarounds, and ad-hoc decisions that live only in people’s heads.

This is a huge problem — just as it’s a problem when ideas in meetings remain abstract. Without documentation—without the “sculpting” of how work is done—a startup risks building on sand.

When people leave or the company attempts to scale, everything crumbles because nothing was ever concretely defined.

But there are ways to fix this, and they mirror the sculpting metaphor I used for meetings.

The Worst Way: Letting the Sculpture Live in Your Head

The worst-case scenario for any startup is when someone does important work, but nothing is written down.

No processes. No documentation. Everything is tribal knowledge.

If the person leaves or tries to delegate their work, all they can do is describe the elephant they’ve sculpted in their mind. And just like in a meeting where everyone imagines a different elephant, the interpretation of that work will vary wildly depending on who hears it.

Even worse, the person doing the work might not accurately remember what they did.

Memory is fallible, and when it comes to explaining a complex series of tasks, memory is almost always wrong.

Like eyewitness testimony in court, what people think they remember and what actually happened often diverge.

So when they try to explain their process later, it’s not just that others will misinterpret it — the process itself might be wrong in the first place.

Slightly Better: Sculpting After the Fact

The next step up is what most startups do: the work gets done, and later, the worker sits down to document what they did.

There are two key flaws here.

First, it’s still prone to memory error. Think about writing down the steps of a complex sales call days after it happened, or trying to document how you’ve been managing a social media account after months of running it.

Even with the best intentions, you’ll inevitably miss details or misunderstand what was important.

Second, and more critically, most people never get around to writing it down at all.

Documentation becomes a task for “later,” and in a startup, “later” often means never.

The day-to-day hamster wheel always takes priority, and that documentation gets pushed to the bottom of the list.

The Right Way: Sculpting as You Go

The best way to document work in a startup is to sculpt as you go. As you’re doing the work, you’re simultaneously documenting the process.

This is real-time sculpting, just like in meetings. It’s continuous and evolving.

As you figure out what works, you shape it, mold it, and document it in real time.

Not only does this ensure that nothing is forgotten, but it also creates a feedback loop where the documentation itself improves the work.

So what’s the problem here?

Over-documentation.

It’s easy to get bogged down in the minutiae of every step, turning what should be a flexible, living process into a rigid script.

Think about documenting how to tie your shoes: you could list every micro-step, but in doing so, you risk missing the point.

What matters is that the shoes are tied securely, not that you followed an exact sequence of motions.

The Fourth Level: Sculpting for Flexibility

To create a truly effective process, the goal is to capture the why behind it.

Why are you tying your shoes in the first place? What is the desired outcome? This allows others to continue sculpting, adapting the process without losing sight of the end goal.

The final level of sculpting goes beyond simply documenting and aims to embed purpose into the documentation.

You’re not just recording what you did — you’re explaining why you did it and what the ultimate goal is.

This is the equivalent of creating a living sculpture, one that others can pick up and reshape as needed.

Processes in startups shouldn’t be static. They should evolve as the company grows.

The danger is that, over time, a company can become calcified by the very processes that once helped. This happens when the sculpting stops—when people forget to question the underlying value of what they’re doing.

The best startups are constantly sculpting, not just the processes but the outcomes. They measure everything against the ultimate goal: creating value.

If a process is no longer creating value, it needs to be revisited, re-sculpted, and improved.

Just like in meetings, startups need sculptors in the day-to-day work: people who can take raw actions and turn them into something tangible that others can build on.

The worst thing you can do is let that sculpture live only in your head. The best thing you can do is continuously shape the work in real time, documenting as you go, but with a focus on why the work matters and how it creates value.