I’ve been talking to a lot of friends about AI lately, and there’s one shared feeling: the tools keep getting stronger, but everyone ends up doing the same thing — writing faster, drawing faster, searching faster. That’s not useless. But if all AI does is accelerate existing work by 30%, it’s not a steam-engine-level change.
The problem is that we’re all staring at the most visible spot.
In 1956, a trucking company owner named Malcom McLean sailed the first container ship from Newark to Houston.
Before that, ocean freight meant break-bulk cargo. A ship would pull into port with its hold packed full of boxes, burlap sacks, barrels, machine parts — every piece a different size, different weight, different fragility. Dockworkers had to carry each piece off by hand. Unloading a single mid-sized cargo ship took hundreds of workers a full week. At the time, loading and unloading accounted for more than half of total shipping costs, and ships spent more time sitting in port than sailing at sea.
This created a natural pressure: every factory minimized handling by locating as close to a port as possible. Get loaded once, get it over with.
Then came the container. Everyone knows what it looks like now: a standardized metal box. Load it whole onto a ship, unload it whole at the other end. A single gantry crane handles one box per minute. A ship gets unloaded in hours instead of a week. Loading costs dropped from dollars per ton to cents per ton.
That was the first layer of the container dividend: faster loading, lower costs. Every port could capture it, and they all did. By the 1970s, every major ocean route had switched to container ships.
But that’s not where containerization rewrote history. If it had stopped there, the dividend would have been modest. The bigger dividend — the one that reshaped the global order — was different.
A different group of people spotted the real opening. Loading costs had collapsed. That meant factory location was no longer chained to port proximity.
In the break-bulk era, inland manufacturing meant a nightmare of extra handling: truck to port, unpack and repack, load onto ship, arrive at destination port, unpack and repack again. Every repacking step cost a fortune. So the logic was brutally simple: minimize handling by building right next to the port. American manufacturing concentrated in the Northeast and Great Lakes region — New York, Chicago, Detroit, Pittsburgh — all port or waterway hubs.
With containers, the standardized metal box could flow seamlessly from factory to truck to train to ship, switching modes four or five times without ever being opened. The number of handling nodes stayed the same, but the cost per node dropped by orders of magnitude. Factory-inland versus factory-at-port had once been a world of difference. Now it was negligible.
Once people thought this through, the entire logic of factory location flipped. Variables that had been suppressed by handling costs — labor costs, land costs — could finally drive decisions. American manufacturing underwent a massive migration from the 1970s through the 1990s, moving from the Northeast and Great Lakes to the South. Alabama became an auto manufacturing hub. Tennessee became a center for appliances and automobiles. BMW’s Spartanburg plant in South Carolina became BMW’s largest factory in the world. These places had been too far from ports to ever be manufacturing cores. Containers made them new centers.
How big is the gap between the two layers? First layer: ports got cheaper. Second layer: the entire global industrial geography was redrawn. These are not the same order of magnitude.
And the second layer didn’t come automatically. It required a group of people to figure out that the location logic had changed, and to bear the cost of scouting new sites, building new factories, training new workers. During that window, staying in the old port-area factories was the safe option. Only those who grasped the second layer, and were willing to endure the short-term pain, captured the vastly larger returns.
Drop this framework onto AI, and things become clear.
AI’s first-layer dividend is what everyone is capturing right now. Write code faster, write documents faster, design faster, draft copy faster. Point-level productivity gains — no question, and everyone is doing it. All the major companies are in on it, and individual users aren’t behind either. The first layer is table stakes, not a competitive advantage.
AI’s second-layer dividend sits somewhere deeper. What rewrote history for the shipping container wasn’t cheaper single-load costs — it was that factory location got unchained from the port constraint. What’s the parallel for AI? The collapse of handoff costs in engineering tasks. Before, getting a tool from idea to production required going through requirements, cross-team alignment, scheduling, frontend, backend, QA, release. Every handoff carried information loss, coordination overhead, queue time. Added together, these aren’t about any single step being slow — it’s that human-to-human, team-to-team information transfer and waiting add up to an absurd total cost. AI enables one person to complete an entire chain of work. Once this stabilizes, practices that were previously suppressed by high coordination costs — building a custom tool for a one-off problem, having one person cover what used to be several roles — become everyday decision options.
This has moved beyond optimization. When the pricing changes, the old optimal strategies stop being optimal.
Note: The following Pinterest case study is a constructed illustrative demo, designed to demonstrate how AI changes workflows. It does not represent an actual event at Pinterest.
Last year, Pinterest launched a new product called shoppable collages, where users could browse a set of curated images, each linked to a purchasable product. A few weeks in, the data came back. Overall dwell time and engagement looked solid, but actionability — the percentage of users who actually clicked through to a product — was at 0.6% against an expected 1%. For an e-commerce product, that gap is significant.
The VP pulled the data scientist on the project into a review, and in a room full of stakeholders, asked one question: why. That answer would determine where a hundred-plus engineers would be deployed next quarter. Was the entire product strategy flawed and in need of a reset? Was the engineering implementation too slow? Was the user targeting off? This is a real, familiar decision scenario.
Under the old cost structure, this data scientist’s optimal move was to conserve code. She faced a classic bind in data science: speed, scale, and readability — pick two. SQL slicing gave her speed and scale, but she couldn’t see what was happening inside any individual slice. Sampling session logs gave readability but couldn’t scale, and the data format was messy, forcing her to fill gaps by intuition. Requesting a custom dashboard gave scale and readability, but required a two-week scheduling window — and her VP needed an answer tomorrow.
Under these constraints, the answer she’d deliver would most likely be a plausible-sounding narrative built on thin evidence — data science as storytelling, stitching aggregate numbers into a reasonable hypothesis, then directing a hundred people’s work based on that guess.
I want to pause here. This isn’t this analyst’s fault, and it’s not just a data science problem. Engineering, product management — we’ve all been trained in the same value system. Think about how we judge competence. It’s like evaluating a traditional Chinese medicine practitioner who can diagnose your illness with a single pulse reading — and be right, as if they’d run a CT scan. An engineer who debugs by glancing at two or three log lines and instantly knows where the bug is — we regard that person as brilliant. But if someone actually reads tens of thousands of log lines and then tells you with certainty “this is the bug,” we’re somehow less impressed. Our entire training system was built in an era when writing code was expensive. So it naturally valorized the ability to reconstruct truth from sparse clues, like a detective. But think about it: that’s a strange ability to prize. If you can afford non-sparse clues, why would you train for this?
AI changed the premise. With the marginal cost of code collapsing, she no longer had to compromise within the triangle. She built a custom observation tool for this specific problem: an afternoon’s work, a few thousand lines of code, with a web frontend, fully interactive. Her first tool was a behavioral visualization, plotting every session’s loopiness score. The result wasn’t a normal distribution — it was a clean bimodal split. Converting users had low loopiness; they were direct, saw what they liked, clicked. Non-converting users had high loopiness; they were exploratory, going in circles.
That 0.6% average was compressing two completely different populations into a single number, masking the truth. Neither one-size-fits-all solution would work — they needed to be handled separately.
Her second tool, a Session Explorer, visualized every user’s interaction lifeline. She discovered that the high-loopiness peak actually contained two distinct groups. One group kept opening images, saving, editing, zooming, re-arranging — going in circles, lost in the creative flow. Buying wasn’t their intent. The other group had timelines dense with red failure markers — they wanted to buy but were blocked by infrastructure friction. The system was too slow.
She brought these three charts back to the VP’s meeting and delivered not a plausible story, but a layered conclusion backed by physical evidence: 0.6% wasn’t a single problem. It was two problems mixed together. Half was segmentation — these users weren’t here to shop, so the product positioning needed rethinking. Half was friction — these users wanted to buy but couldn’t get through, so the engineering pipeline needed fixing. Two entirely different problems, requiring entirely different solutions.
So far, this is still the first layer: she used AI to do deeper, faster, more persuasive analysis.
But zoom out one step, and the second layer emerges. These two tools, together a few thousand lines of code with a web frontend — under the old cost structure, this was a standard engineering project: data analyst writes the spec, frontend engineer builds the UI, backend engineer builds the data pipeline, UX designer handles the interaction, PM coordinates. Two to three months from kickoff to launch. She did it alone, in one afternoon.
It’s easy to draw the wrong conclusion here: AI made her a superhuman. No. Her judgment, her business understanding, her sensitivity to data — those were the same person. The frontend code she wrote would likely have countless things a professional frontend engineer would nitpick.
What actually happened is that the capabilities of five roles underwent organic integration within a single person. When five people collaborate, each sees only their slice of the picture: the analyst sees numbers, the frontend sees UI, the backend sees pipelines, the designer sees interaction, the PM sees progress. The complete picture lives in no single person’s head — it exists only in the sum of meeting notes, design docs, and cross-team syncs. And the information in those artifacts is always partial and out of sync.
The point isn’t that she saved a few headcount. It’s that she produced something that even having those headcount might not have guaranteed. One person plus AI, writing frontend code while understanding the business meaning behind the numbers, designing interactions while knowing what the behavioral signals meant. The bimodal distribution, the mix of segmentation and friction, the coexistence of creators and blocked buyers — none of these discoveries were visible to any single role working alone. They lived in the seams between roles, and the seams between roles are where information loss is most severe in traditional workflows. So many opportunities you can clearly see when working alone simply vanish in all those layers of friction. When those seams get stitched together, the ceiling of what’s possible jumps.
Let’s return to the container story. From McLean’s first ship sailing to the first wave of global factory relocation, roughly thirty years passed. Throughout those thirty years, every port was capturing the first-layer dividend. The factory owners who captured the second layer were mostly concentrated in the first ten to fifteen years — the ones who figured it out early, acted early, and bore the restructuring costs first. By the late 1980s, when the second layer had become common knowledge, latecomers were earning dramatically smaller returns.
Where is AI now? Everyone is capturing the first-layer dividend, and that’s fine. Capturing the first layer just means you haven’t fallen behind — it doesn’t mean you’re ahead. The window for the second layer has just opened.
Here’s a closer example. Traditional code review served two functions: finding bugs and transferring knowledge. Both made sense when code was expensive and slow to write — catching bugs early avoided costly fixes, and seniors passing knowledge to juniors kept team capabilities alive. AI weakens both functions simultaneously. Pattern-level bugs — null dereferences, deadlocks, resource leaks — AI catches faster, more comprehensively, and with fewer misses than humans. And knowledge transfer, in a world where code itself can be regenerated by AI, now hinges on something scarcer: not code details, but intent, business constraints, design tradeoffs. Those were never readable in code review anyway — they lived in specs, in chat logs, in someone’s head.
Anthropic is experimenting with a two-tier approach: AI reviews implementation — style, security, edge cases; humans review intent — technical approach, business logic, design tradeoffs. This isn’t handing code review over to AI. It’s re-dividing the work. Extract the manual labor and give it to AI, freeing humans for higher-level judgment. Their engineering lead Boris Cherny has said that every PR at Anthropic now goes through Claude Code review as a first pass, and the level of detail in the bugs it finds shocks him.
There’s a detail in the container story that’s easy to miss: the transition from break-bulk to containers wasn’t because dockworkers weren’t working hard enough, or because they resisted change. It was that the cost structure of loading and unloading itself dictated everyone’s behavior. When the cost structure shifted, the old best practices stopped being the best practices.
The AI era works the same way. The question isn’t whether you can do your current tasks faster or cheaper. It’s whether the implicit assumptions underlying those tasks have already been shaken. When code was expensive, the optimal strategy was to conserve code — let specialists handle it. Now that code has become cheap, the optimal strategy may be to spend code, consume code, and stop splitting a single task across five people just because the coding barrier used to be high.
The dividend AI brings isn’t that we can do things faster. It’s that we can start doing different things. Every optimal strategy built around the old pricing needs another look, needs to be unlearned. It doesn’t necessarily need to change — but you have to at least ask: does the premise behind this still hold?
Pick something you’ve been wanting to figure out, and run it through AI yourself. Saving time is a side effect. What you’re really building is a feel for how the pricing has changed. What you’ll get isn’t just the answer to that one thing — it’s judgment about what’s already not the same. That’s where one person’s second-layer dividend begins.