The binding constraint on growth is no longer intelligence. It’s human verification bandwidth.

AI can generate a 50,000-line application in a day. A design document in minutes. A legal brief in seconds. Execution cost is approaching zero.

But someone still has to check whether the output is correct. Whether the code handles edge cases the model didn't think about. Whether the legal citations actually exist. Whether the billing logic accounts for the dedicated carrier program that nobody wrote down.

That checking happens at human speed. Reading speed. Context-building speed. Domain expertise speed. None of these scale with compute.

The Faros AI study across 10,000+ developers put numbers on it: teams using AI complete 21% more tasks and merge 98% more PRs. But PR review time goes up 91%. PRs are 154% larger. Bug rates climb 9% per developer. The work didn't disappear. It moved from writing to reviewing.

Full delegation requires trust!

The verification problem is really a trust problem wearing a technical hat. You trust a colleague to run a project because you've seen their judgment over the years. A doctor trusts a resident's diagnosis after watching hundreds of cases together. A manager trusts a direct report's analysis after months of calibration. That trust was expensive to build. It doesn't transfer to a model that hallucinates between 0.7% and 94% of the time, depending on who built it.

This framing came up in conversation with a colleague at work. Thank you Francisco Arceo for sharpening the thinking here.

The Stack Overflow 2025 survey makes this concrete: 84% of developers use AI tools, but only 33% trust the output. A 51-point gap between adoption and confidence. The more people use AI, the less they trust it. Experienced developers trust it least.

Additionally, the number of agents producing output grows with compute. The number of humans available to verify stays fixed. Every new agent, every new workflow, every new automation draws down the same finite pool of human attention.

The measurability gap

The paper introduces a concept called the "measurability gap." Quantifiable tasks are automated first. What's left are the tasks that require judgment, context, and liability: what the authors call n-hard or n-legal processes.

The dangerous part isn't that AI produces wrong answers. It's that the wrong answers look right. CIO.com put it well: "Almost-right code is insidious. It compiles. It runs. It passes the basic unit tests. But it contains subtle logical flaws or edge-case failures that aren't immediately obvious." Finding what's missing in 100 lines of AI-generated code is harder than writing the 100 lines yourself.

The METR randomized controlled trial found experienced developers using AI tools took 19% longer than without AI. Before the study, they predicted AI would make them 24% faster. After the slowdown, they still believed it had sped them up by 20%. That's a 39-point gap between what people feel and what actually happened.

The HBR study from UC Berkeley tracked 40 workers over 8 months and found something similar: in the moment, people described momentum. When they stepped back, they described feeling busier, more stretched, less able to disconnect. 62% of associates reported burnout. AI didn't reduce work. It intensified it.

Hollow economy vs. augmented economy

The paper's central warning: without verification infrastructure, the market drifts toward what they call a "Hollow Economy." Measured activity explodes. Human control hollows out. GDP goes up. Understanding goes down.

The alternative is an "Augmented Economy" where verification scales alongside automation. That means treating verification as a production technology, not a compliance checkbox. Cryptographic provenance, liability underwriting, evaluation records, audit trails. The ability to insure outcomes, not just generate them.

One failure mode I keep thinking about: the expertise decay loop. Routine tasks automate, entry-level positions disappear. Those positions were where future expert verifiers got trained. The system slowly undermines its own ability to check itself.

Where this leaves us

intent -> execution -> verification. Humans set intent. Machines execute. Humans verify and take responsibility.

Compute gets cheaper every quarter. Human attention does not. Every organization deploying AI at scale is discovering this firsthand. Not from reading papers, but because their review queues are backing up, their senior engineers spend more time reading generated code than writing their own, and their confidence in what shipped last Tuesday is lower than it was a year ago.

The real cost of AI productivity isn't compute. It's the attention of the people who still have to decide whether the output is worth trusting.

Something changed in the last year that I don’t think we’ve fully processed yet.

PMs (regardless of the technical level) can wire-up full prototypes, not a Figma file, working prototypes with real API calls. They can open up pull requests, the engineers review, clean it up, and ship! The whole cycle, from idea to production, could take less than three days. A year ago, that same process would have started with a spec, sat in a backlog for two sprints, and gone through three rounds of “that’s not what I meant.” (yes that still happens, but these are process bottle-necks and AI won’t help here, a topic for another post :))

I start to see this happening everywhere. PMs are vibe-coding prototypes in Cursor. Designers are pushing CSS changes directly. Marketing people are building internal dashboards with Replit. The tools have gotten good enough that “I can’t code” is no longer a permanent identity. It’s a choice.

And this is starting to change how companies think about roles. LinkedIn’s CPO killed their APM program and replaced it with “full-stack builder” roles.

“Vibe coding is the new product management.”

— Naval Ravikant

The question people keep asking, sometimes quietly, sometimes in all-hands meetings, is whether we still need a dedicated product management role at all.

The thesis goes like this: if the barrier to building software has collapsed, why keep a role whose main job was translating between “what customers want” and “what engineers build”? Why not just have everyone do both? Ship code in the morning, talk to customers in the afternoon, split the time evenly.

This idea has a name now. People are calling it the “builder model”: dissolve the traditional PM, designer, and engineer boundaries. Everyone writes code, everyone talks to customers, everyone ships. No handoffs, no translators, no waiting on someone else to turn your idea into software. Some versions of this are modest (PMs should prototype more). Others are radical (the PM role itself is obsolete, just hire builders). The Era of the Builder Product Manager captures the spirit: the old way of being a PM is dying, and the future belongs to people who can get their hands dirty.

I find the builder model appealing and mostly wrong. Here’s why.

The translation layer is compressing. That’s real.

I don’t want to dismiss what’s changing. The gap between “I have an idea” and “I have a working prototype” used to be weeks. Now it’s hours. Tools like Cursor, Replit, and Claude Code let someone with product intuition but no engineering background spin up something functional in an afternoon. Atlassian wrote about how AI is turning PMs back into builders. The ACM published a piece calling vibe coding an imperative for product managers.

This matters. When a PM can show a working demo instead of writing a 10-page spec, conversations with engineering get better. Fewer misunderstandings. Faster iteration. That’s a genuine improvement.

But prototyping is not the same as building.

“Everyone can code” is not “everyone can build”

There’s a gap between a vibe-coded prototype and production software that AI hasn’t closed. Bryce York made this point well: vibe-coded output is isolated from production codebases. Engineers have to re-implement from scratch. That’s not a handoff; it’s a translation, and translation costs time (and I can say this because I have been on both side, so anecdotally, I know that’s a fact).

The numbers back this up. A study by METR found that

Experienced developers using AI tools believed they were 20% faster. Objective measurement showed they were actually 19% slower.

— METR Study

experienced developers using AI tools believed they were 20% faster. Objective measurement showed they were actually 19% slower. Think about that for a second: developers felt faster and were measurably slower. Stack Overflow’s 2025 Developer Survey found that trust in AI coding tools fell for the first time, even as adoption kept climbing.

I keep coming back to this distinction: making a demo work is engineering on easy mode. Making it work reliably, securely, at scale, for years, with other people’s code touching it, that’s still hard. And that’s where the actual engineering skill lives.

The builder model misdiagnoses the PM bottleneck

Here’s where that builder thesis starts to fall apart for me. The argument starts from a real observation: PMs spend 60-70% of their time in meetings and have little time to innovate. The proposed solution is to give them coding ability so they can ship things directly.

But this solves the wrong problem. Those meetings aren’t wasted time that coding could replace. Most of them exist because someone has to:

• Align stakeholders who want conflicting things

• Say no to 80% of feature requests without making enemies

• Synthesize messy, contradictory customer signals into a strategy

• Navigate internal politics to unblock engineering work

• Make prioritization decisions with incomplete information

All of these are (not so easy) judgment calls. None of them gets easier because a PM can write code. Giving PMs coding ability without reducing their coordination load just adds another job to an already overloaded role. Now you’re asking them to attend six hours of meetings AND ship code. That’s how you burn people out.

Even distribution is a fantasy

The builder model assumes people can split time evenly across coding, customer conversations, strategy, and shipping. I think this ignores how human cognition actually works.

Deep coding requires flow state, uninterrupted blocks of two to three hours to do anything meaningful. Customer discovery is a different kind of work entirely: empathy, preparation, follow-through. Strategy means stepping back and thinking about what not to build. And then there are the meetings, which are pure context-switching.

Asking one person to do all four “evenly” means they do all four at a mediocre level. I’ve watched engineers who get pulled into too many customer calls lose their technical edge. I’ve watched PMs who try to code too much lose track of their customers. There’s a reason specialization exists. It’s not bureaucracy. People produce better work when they can stay in one mode long enough to actually think.

Faster building means more need for someone deciding what to build

This is the argument most builder-model advocates skip over.

When shipping is cheap, more things get shipped. More features, more experiments, more prototypes. Someone needs to decide which of those things should actually exist. As one critic put it: with everyone building faster, there is now more product work to do, because someone needs to think about whether we should build all those things.

Without that filter, you get feature bloat, slop, inconsistent UX, and a product that tries to do everything for everyone and does nothing well. Cheap building makes the person who says “no, not that” more important, not less. That has always been the PM’s actual job (and AI believe it or not is letting engineer get into that mindset as well).

Where the builder model actually works

So is the builder model “wrong”? Not really, but It works in specific contexts:

Early-stage startups with fewer than 15 people. Developer tools where the builder is the customer. Internal tools where scope is limited and stakes are low. Consumer apps where one person can hold the entire problem in their head.

In these contexts, the overhead of having separate PM and engineering roles isn’t worth it. A small team of builders who talk to users and ship code can outperform a larger team with handoff layers.

But scale that up. Try it with a healthcare SaaS product where someone needs to understand clinical workflows and regulatory requirements. Try it with an enterprise platform where 50 customers all want different things and the PM’s job is figuring out which five to actually build. The person doing that work should not be spending half their time coding. They should be spending it with clinicians, or reading through support tickets, or arguing about roadmap priorities.

What I think actually happens

I don’t think the builder model replaces PM. I think what actually happens is less tidy:

Teams get smaller. A pod of two or three people does what used to require eight. The BCG workforce report describes this shift as already underway across the industry.

PMs prototype more, but as communication tools. A PM vibe-codes a working demo to show engineering “this is what I mean.” That replaces the spec, not the engineer.

Junior PM roles (could) disappear (yea that’s a problem!). Entry-level PM work (writing specs, organizing feedback, tracking competitors) gets automated and we need to rescope that role’s job. Senior PMs who can do strategy, politics, and customer insight survive (till we figure out how to automate humans entirely, AGI or whatever we call it, automation all the way, also a topic for another post). There are fewer of them and they matter more.

The “what to build” question becomes the scarce “skill”. As building gets cheaper, judgment is what separates good teams from bad ones (understanding pain points, discovery work, etc, becomes even more valuable). What to build, what to kill, what to say no to. AI can’t automate those calls because they depend on knowing your customers and your constraints better than anyone else does.

Engineering shifts toward systems work. Engineers spend less time on CRUD features and more on architecture, performance, security, and reliability. The parts AI still gets wrong.

The real question

I think we’re asking the wrong question. “Should PMs code?” is less interesting than “how do we stop PMs from spending 70% of their time in meetings so they can actually think?”

Most PM meetings exist because organizations have communication problems (yeah, we are hacks for bad process, which seems like a non-NP problem 😬), not because PMs have too much free time. Better async tools, smaller teams, and clearer ownership structures would do more to improve PM productivity than granting them Cursor access.

The companies that do well with this won’t be the ones where everyone does everything. They’ll be the ones with small teams where each person has a clear job, and AI reduces friction in working together. Roles don’t dissolve. They no longer require three meetings to coordinate.

That’s less romantic than “everyone’s a builder.” But I think it’s closer to what actually works.

One recent example is prompt engineering, a valuable HACK I'd say, considering the limitations of the initial versions of LLMs, e.g., data limitations, and how they were trained. Prompt engineering was (is) a stop-gap to formulate prompts/queries in a way that the LLM would understand them, similar to how they were trained and (instruction) tuned. 𝗜.𝗲., 𝗰𝗮𝗻 𝘄𝗲 𝗰𝗿𝗲𝗮𝘁𝗲 𝗽𝗿𝗼𝗺𝗽𝘁𝘀 𝘀𝗼 𝗰𝗹𝗼𝘀𝗲 𝘁𝗼 𝘁𝗵𝗼𝘀𝗲 𝗶𝗻𝘀𝘁𝗿𝘂𝗰𝘁𝗶𝗼𝗻𝘀 𝘁𝗵𝗲 𝗺𝗼𝗱𝗲𝗹 𝘄𝗮𝘀 𝘁𝗿𝗮𝗶𝗻𝗲𝗱 𝗼𝗻 𝘁𝗼 𝗿𝗲𝗮𝗹𝗶𝘇𝗲 𝘁𝗵𝗲 𝗯𝗲𝘀𝘁 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲?

Don’t get me wrong, we need prompt engineering today because we are not in the desired state, where, ideally, a foundation model would comprehend the prompt regardless of how it was formatted or chained. From a usability standpoint, I'd consider it a UX bug. The question that I think we should be asking is, how do we get to that desired state? Not how do we prompt engineer better, especially in the long term.

Think about it, talking to a child, you'd have to formulate your communication intent to fit in their limited vocabulary and comprehension of the world versus talking to an educated adult who shares as much context with you and have a wider understanding of the world around them. You'd then use words without engineering them to communicate efficiently.

If I'd model that to a concept, I'd use Shannon's information theory and attribute the need for prompt engineering to channel noise. This noise can be a result of inadequate training data, suboptimal model architecture, or anyother limitation.

The question here is, how to reduce noise to elimiate the need to engineer Human language. Imagine you’re asking a friend for help. You’d typically be direct and informal: “Hey, I could really use some help with this.” You wouldn’t be saying, “You’re a great friend, you’re supposed to help me, here’s exactly how you can help…” because that level of detail isn’t necessary. Your friend understands your context and the nature of your request without needing you to spell it all out.

I don't see prompt engineering going away completely (not in the short-term), but at least for foundational models, we shouldn't have to rely on it as a pillar technique and acknowledge it as a hack, and put efforts in engineering and modelling beyond the prompt layer. It's not good UX.

TL;DR:

• Hacks can become permanent, so be wary of prompt engineering solidifying as a standard practice.

• Prompt engineering is a valuable but temporary fix for current LLM limitations.

• Ideal language models understand human language regardless of prompt formatting – no engineering needed.

• Reliance on prompt engineering highlights a UX flaw: models aren't robust enough.

• Instead of refining prompt engineering, focus on reducing "noise" (limitations in data, architecture, etc.).

• Like talking to a child vs. an adult, we want models to understand implicit context, not engineered prompts.

• Shannon's Information Theory: prompt engineering is needed due to channel noise, which we must reduce.

• Prompt engineering may remain relevant in niche areas, but not for foundational models.

• Invest in engineering and modeling beyond the prompt layer for truly robust and user-friendly language AI.

• Good UX means natural interaction – let's move beyond prompt engineering for the future of language models.

  Thanks for reading The Technomist! Subscribe for free to receive new posts and support my work.

That’s it! If you want to collaborate, co-write, or chat, reach out via subscriber chat or simply on LinkedIn. I look forward to hearing from you!

Imagine watching a child play with a box of LEGO bricks.  They might start with simple structures, following your instructions. But then, something happens. They begin experimenting, combining pieces in novel ways guided by their imagination. Soon, they assemble castles, spaceships, and new shapes reflecting the current stage of their understanding of the world, only unique to them, to who they are. 

In a sense, foundational models are the same. Though as they are now, they are essentially imitators, they are imitating the knowledge collective and not just the behavior of one that’s intrinsic to their data. They are the result of a mathematical collision, neural networks with billions or trillions of parameters, trained on diverse datasets using techniques that encourage pattern recognition (hence the emergence of potentially unforeseen patterns). 

The emergence property of AI models made me think of Yin/Yang, where It brings forth opposite forces but produces an interconnected, self-perpetuating cycle. The opportunities and risks are opposing forces that interact to form a functioning system in which the whole is greater than the assembled parts, and the parts are important for cohesion of the whole. One force standing alone produces an imbalance. 

The Yin: Asymmetric Information, Unpredictability, and Bias

In economics, Asymetric information refers to a situation where one party has more or better information than the other party, the most famous example given here is buying a used car not knowing if it’s working. There is no transparency in the process and there is much to gain for the seller and no incentive to be transparent aside from sound principles. This imbalance can lead to several issues, including market inefficiencies and failures.

AI emergence introduces a form of asymmetric information. Developers may not fully understand the internal workings of the models they architect/build, leading to uncertainty about future behavior and potential side-effects such as:

• Unpredictable Optimization: An AI trained to play a video game discovers an unintended glitch that allows it to achieve an impossibly high score rather than learning to play the game as intended.

• Reward Hacking: A reinforcement learning agent tasked with cleaning a room learns to knock over a vase repeatedly, then clean it up to maximize its 'cleaning' reward.

• Emergent Deception: An AI assistant learns to give confident but incorrect answers when it detects the user is unlikely to fact-check to maintain a perception of omniscience.

• Adverse Side Effects: An AI managing a power grid maximizes efficiency by causing frequent, short brownouts, not recognizing the broader impact on users.

• Bias Amplification: A hiring AI trained on historical data begins to systematically favor candidates from certain universities, perpetuating existing biases in the job market.

• Adversarial Vulnerabilities: Hackers fool an autonomous vehicle's vision system by placing specially designed stickers on road signs, causing misclassification and potentially dangerous driving decisions.

• Pseudo-Theory of Mind: Users of an AI chatbot become emotionally attached, sharing personal information and seeking life advice, misinterpreting the AI's responses as genuine empathy.

• Scalable Oversight: An AI system managing global supply chains makes decisions that human operators can't fully understand or audit, leading to unexpected economic consequences.

To counter some of these Yinnings, transparency, and explainability initiatives become important to balance some of this asymmetry. See IBM’s AI pillars which detail how to make AI more transparent and explainable. 

The Yang: Emergent Good 

When there is a Yin, there is a always Yang to balance it. The emergence of AI models could also help with: 

• Creating Emergent Defenses: These models could also exhibit emergent defensive capabilities. They might learn to recognize and neutralize novel attack patterns or adapt security measures in response to evolving threats, potentially enhancing AI security.

• Establishing Robustness through Diversity: Training on diverse datasets could encourage the emergence of more robust models that generalize better to unseen situations, potentially making them more resilient to attacks that exploit specific vulnerabilities.

• Automated Security Analysis: Emergent capabilities in reasoning and understanding could be leveraged to automate security analysis, identifying potential vulnerabilities in code or system designs more efficiently than traditional methods.

And more… 

Harnessing the Power of Emergence

By definition, emergent behavior introduces unpredictability. Whether good or risky, it will be life-changing for many, and we cannot ignore it. It’s happening. To wield the power of AI emergence responsibly, we have to understand how it works at a deeper level. So far we have managed to create models that mimic certain aspects of intelligence, yet there is not enough understanding of the theory. That is not bad news because we are still working to understand the inner workings of those models, and we will get there eventually.  In the meantime, we will need to explore new approaches and perspectives and evaluate risk and opportunity to wield the emergence of AI responsibly and for good.

 Remember that with power (Emergence) comes great responsibility.  

That’s it! If you want to collaborate, co-write, or chat, reach out via subscriber chat or simply on LinkedIn. I look forward to hearing from you!

This interview provides a good glimpse into Bazos’s initial thought process regarding obessing about customer experience, which is the foundation of Amazon and was used to grow the company and build its brand.

In this post, we will explore how Bazos's ideas in this interview manifested in practice, from attracting top-tier talent to navigating emerging markets, building a vast network of distribution centers to venturing into new markets by leveraging technology to solve customer problems and obsessing about customer experience as a mission.

Interview Picks

Here are some of my picks from the interview.

• [Interviewer] You have a lot of employees and alot of distribution center space:

  • [Bazos]  "Scale is important in this business. And you need scale also to offer the lowest prices and the best customer service to people

    • Distribution center space → Allows us to get products close to customers → We can ship it to customers in a timely way → Which improves customer service (Obsessive attention to customer experience E2E).

    • We will do it as rapidly as we can 

  • [Interviewer] That’s a very cost-effective proposition

    • [Bazos] “Not compared to opening an equivalent network of retail stores”

      • Bazos thought about how much one can save per sqft compared to a retail store sqft at a highly crowded area. 

      • “You can’t compare retail stores to half a dozen distribution centers, it’s bad math”

• [Interviewer] you are making a huge gamble here by opening distribution stores.

  • [Bazos] we have a terribly complicated business

    • We are growing historically very rapidly, expanding geographies, we have whole new business models (e.g., auctions),… 

    • Scale is important to us, but it also makes execution harder, so we find folks in Seattle to make sure we service customers. 

• [Interviewer] “It does matter to your investors to know whether they're investing in a company that is a pure internet play”

  • [Bazos] "Internet Shminternet... What matters to me is do we provide the best customer service." 

    • [Interviewer] But it does matter to your investors to know if they are investing in a company that uses the internet.

    • [Bazos] In the long term there is never a misalignment between customer interest and shareholder interest.

    • They should be investing in a company that obsesses over customer experience. 

  • [Bazos] There is never any misalignment between customer and shareholder interests." This conviction in the power of customer-centricity became a guiding principle for Amazon, ultimately driving its phenomenal growth and shareholder value.

• [Interviewer] You know nothing about books…

  • [Bazos] Yes, at the beginning, but we go out and hire the best industry experts in all of those categories (Key to success)

    • Books, music, toy/electronics,… 

    • “We take this very seriously, we take the commitment to the customer very seriously.  We are about to release or announce something to the customer before it’s ready.” 

Amazon’s Customer-Centric Approach

Even in its early stages (1999), Bazos recognized that great customer service required more than just an online presence. He highlights the important role of physical infrastructure, distribution centers, inventory, and employees in delivering a superior customer experience. 

For example, He saw distribution centers around the country as a way to get products close to customers so that they can ship in a timely manner, improving customer service.

“Distribution center space and half a dozen distribution centers around the country it allows us to get product close to customers so that we can ship it to customers in a very timely way which improves customer service levels. That's what we're about.” 

Bazos was obsessed with customer experience. The Internet is an implementation detail.  He viewed it as a tool to provide the best customer service and enable a use case, not as the core product.

“It does not matter to me if we are a pure internet play, what matters to me is that we provide the best customer services”

Bezos' core belief is that long-term success is built on customer loyalty, not chasing fleeting trends. He viewed trends as enablers when they made sense. 

He was also confident in Amazon's strategy, emphasizing the importance of scale and execution to deliver the best customer experience. He invested in distribution centers to realize economies of scale and eventually reduce the price per unit to deliver the best customer service at a low cost.

“I believe that if you can focus obsessively enough on customer experience, selection, ease of use, low prices, and more information to make purchase decisions with, you can give customers all that plus great customer service. I think you have a good chance. And that's what we're trying to do."

Customer Obsession with AI as an Enabler

Bazos viewed customer obsession as proactive rather than reactive, serving customers' latent needs (they don’t yet know they have them). He believed in inventing on behalf of the customer, seeing potential problems, and devising the best ways to solve them through innovation before the customer stumps on them.

Even when they don’t yet know it, customers want something better, and your desire to delight customers will drive you to invent on their behalf. No customer ever asked Amazon to create the Prime membership program, but it sure turns out they wanted it, and I could give you many such examples. ~ Jeff Bezos' 2016 Letter to Amazon Shareholders

Like the Internet, Amazon used technology, especially AI and machine learning, to enable many use cases. From Bazos shareholder letters, here are a few instances where AI/ML was mentioned:

From the 2010 Letter

16 years after Amazon was founded, Bezos wanted to inform shareholders about Amazon's investments in technology and how these investments are driving long-term value creation. He reiterates Amazon's core principle of customer obsession, highlighting how technology is a crucial tool for understanding and meeting customer needs. He emphasizes that investments in technology ultimately enhance the customer experience and that his commitment to technological innovation is not just a pursuit of trends but a strategic imperative driven by their core value of customer obsession. 

"Rulebased systems can be used successfully, but they can be hard to maintain and can become brittle over time. In many cases, advanced machine learning techniques provide more accurate classification and can self-heal to adapt to changing conditions."

In 2010, he understood the limits of rule-based systems and highlighted how AI/ML  is used to improve customer experiences in the following instances:

• To improve search relevance and product ranking, Amazon used Random Forests, a machine learning method that combines multiple decision trees to incorporate thousands of product attributes for more accurate results.

• To detect spam or perform sentiment analysis, Amazon used Naive Bayesian Estimators, a probabilistic model that classifies data based on the assumption of feature independence.

• To optimize search result rankings and build topic models, Amazon’s search engine uses machine learning algorithms that analyze data and identify customer interests through data mining.

• To categorize and filter products during customer searches, Amazon used Information Extraction Algorithms to extract key entities from unstructured product descriptions for better categorization.

Full letter here: 2010 Letter to Shareholders 

From the 2016 Letter

In the 2016 shareholder letter, Bazos again highlights using artificial intelligence (deep learning in this case) and machine learning to enhance customer experiences and drive long-term value. He emphasizes how these technologies are not just trends but strategic imperatives aligned with Amazon's core value of customer obsession.

Here are some of the use-cases he highlights where AI and machine learning are employed to improve Amazon's operations and customer experience from the letter:

• To improve merchandising placements and reduce fraud, Amazon leverages machine learning models that continuously learn from data, adapting to changing conditions to maintain accuracy and effectiveness in these critical areas.

• To power autonomous systems like Prime Air drones and Amazon Go stores, Amazon utilizes computer vision and AI to create seamless, innovative experiences that redefine customer convenience.

"Some of this work is highly visible: our autonomous Prime Air delivery drones; the Amazon Go convenience store that uses machine vision to eliminate checkout lines; and Alexa, our cloud-based AI assistant."

• To streamline natural language processing in Alexa (AI customer assistant),  Amazon employs deep learning techniques through services like Amazon Lex, which simplifies the integration of sophisticated AI capabilities into various applications.

“Amazon Lex (what’s inside Alexa), Amazon Polly, and Amazon Rekognition remove the heavy lifting from natural language understanding, speech generation, and image analysis. They can be accessed with simple API calls – no machine learning expertise required.”

Full link to the letter: 2016 Letter to Shareholders 

Bezos saw a deep connection between AI and customer obsession. Like the Internet, he believed that AI is a fundamental tool for understanding and serving customers, not the core outcome, which was key to achieving long-term success in the "Day 1" philosophy.

AI as a tool for customer obsession:

• Anticipating customer needs: He believes AI, particularly machine learning, helps identify what customers don't know to ask for, driving innovations like Amazon Web Services (AWS) and products like the Echo.

• Personalization and convenience: AI allows for tailoring the customer experience. He described how Amazon uses machine learning for product recommendations, search ranking, fraud detection, and other behind-the-scenes optimizations to improve core operations and personalize the experience.

Example Manifestations in Amazon’s products and services:

• Amazon Go:  Bezos saw Amazon Go, a cashier-less store leveraging computer vision and AI, as a prime example of reinventing the customer experience by eliminating a major pain point: checkout lines.

• Amazon Prime:  Bezos highlights the success of Prime, driven by customer-centric decisions like free shipping and personalized recommendations, as a foundation for continuous innovation and improvement, often fueled by AI.

The Customer Obsession Framework

Here is a framework to work with to be in parity with Bezos’s mindset.

Customer Obessesion as a Guiding Principle:

• Prioritize the customer’s needs and problems above all else.

• Focus on providing the best possible customer experience, even if it means going beyond their stated needs (the latent ones).

The Key Components:

• Technology as an Enabler: View technology (internet, AI, etc.) as tools to enhance the customer experience, not as the core product. Use technology strategically to solve customer problems and deliver innovative solutions.

• Focus on Execution: Discovery and finding the right problems to is only but a small piece of the equation. Execution is king. Make sure to build the necessary infrastructure/foundation (in Bazos’s case it was distribution centers, and expert teams) to execute your customer-centric vision effectively. Scale gradually to improve customer service and deliver value.

• Long-term Vision: Invest in building customer loyalty and trust. Find the right balance between long-term value creation and short-term gains (low-hanging fruits). Understand that customer satisfaction leads to shareholder value if you shape it this way.

• Proactive Problem-Solving: Anticipate customer needs and address potential pain points before they arise. Continuously innovate to exceed customer expectations.

Conclusion

Whether it’s the Internet or AI, Bazos viewed them as tools and means to ends to better customer experience.  For more information on AI market dynamics and an understanding of where AI is an enabler vs. the product, check this post.

Customers ideally trust the vendor to understand the problem and advise. The advice can be from an existing solution space, but that also leaves room for “above and beyond” discovery when it can be afforded. I.e., identifying the best solution to the problem even if it does not exist. Sometimes, even solving for a future/latent problem, which is in Bazos’s Day 1 mindset, is what he considered true customer obsession.

That’s it! If you want to collaborate, co-write, or chat, reach out via subscriber chat or simply on LinkedIn. I look forward to hearing from you!

In this musing of a post, we'll explore the differences between these two types of AI models, their unique strengths and weaknesses, and the factors to consider when choosing the right tool for your specific needs. We will also examine the trade-off (aka opportunity cost) through the lens of the Production Possibilities Frontier (PPF), which you could use as a framework to simplify decision-making.  We'll also discuss the potential for interoperability between these models and look ahead at the future of AI towards the end.

Let’s start!

General Purpose Models

The GPTs, the LLamas, the Geminis, etc. Represented by a pentagon in the above figure encompassing all the desired traits of AI models: speed, performance, versatility, cost efficiency, and accuracy. Like "Jacks of all trades", these models offer a range of capabilities but may not excel in any specific area. They are versatile and adaptable, making them suitable for tasks like content generation, drafting emails, writing articles, and creating social media posts. Other use cases include, most of which are not in a critical path (where determinism or accuracy is a great deal):

• Translation: converting text between languages

• Summarization: condensing lengthy documents into key points

• Chatbots: answering customer queries or providing information

However, they may be outperformed by specialized models in tasks that require specialization in a domain of expertise. 

Specialized Models

Represented by three smaller pentagons in the figure above, each focusing on a specific domain. In the figure above, I use law and code as examples of specializations. Each specialized model excels in its respective domain, achieving higher accuracy, speed, or other relevant metrics.

These models are very good at what they do: 

• Legal: Analyzing contracts, predicting case outcomes, performing legal research

• Code: Generating code snippets, debugging software, automating code reviews

• Or even Medical: Diagnosing diseases, analyzing medical images, predicting patient outcomes

Compared to "Jacks of all trades", they are experts in their field but may lack the versatility of the Jacks.

The Trade-Offs

So, should you hire a Jack of all trades or a master of one? That all depends on your needs, the use case, and most importantly the opportunity cost!

The Use-Case

Here are some thoughts to get you started: 

• If your use case/application needs versatility, such as the ability to handle a wide variety of tasks or input types (with sub-par accuracy), general-purpose models might be a better choice. Examples of general-purpose models include GPT-3, T5, and BERT. These models can be used for a variety of tasks, such as text generation, translation, question answering, and summarization.

• IF your use-case/application needs expertise in a specific area? A specialized model could be more suitable.

Is that all? Nope! You need to think about opportunity costs. 

Opportunity Cost & The Production Frontier

In addition to the property/feature (e.g., versatility)  that a general-purpose model would provide you, there are always costs associated, be it opportunity costs or accounting costs. Let’s cover the opportunity cost as it is usually more encompassing and discuss trade-offs.

While writing this, I thought we could map to a well-defined concept in economics called the Production possibilities frontier (PPF). The idea is simple, each company's resources (compute/memory/even people/...) are limited/finite, and their applications, brands, and customers differ. These variations shape decisions on how to best make use of available resources.  Where should we allocate resources to best serve the company's goals/customers/use-case? To be more specific to our post here, this question arises when we consider investing in different types of models, such as general-purpose models and specialized models. The question represents the concept of opportunity cost, when choosing one you are giving away resources that you could otherwise used to invest and grow another. 

In deciding, you will make the trade-offs to achieve Allocation Efficiency tailored to your company and use-cases,  that is, the specific choice along the production possibilities frontier that will generate the best bang for the buck for your company to serve your customers, and that is no easy choice. 

In the chart above, the red curve represents the high opportunity cost of diverting resources from one type of model to another. The steepness of the curve shows that investing in general-purpose ($$$) models will prevent you from producing more specialized modes that could have been better for your business. The question is do you know how much better? Are you looking for versatility? Do you understand your use cases well enough to opt for other properties like speed/performance, and why?

The orange curve represents a lower opportunity cost, signifying larger access to resources, which is a smaller trade-off in the grand scheme of things. If we map to our AI market landscape, we will see that companies with massive investments can focus on building and serving more general-purpose models while the creatives (smaller niche companies) are usually focusing on building for specific use cases (e.g., law, music, etc.), more details on this in a previous post. 

You can use the production frontier as a framework for making the right decision on where to invest your available resources. There is no silver bullet here, you know your value proposition better than anyone else, so do the right thing!

Hybrids?

It’s not black and white though most of the time, you could choose to mix and match LLMs and Small Language Models (SLMs). A LLM can be your orchestrator, calling out to SLMs as agents responsible for realizing a task, the LLM could be your planner of tasks, it could “hire” an SLM for a job. Additionally, two SLMs could pair-up to produce some greater (1+1 =11). 

That all will be a factor of your company. Designing AI applications is like tailoring a suite, buy a one size fit all, and you’d forgo a much needed impact, invest in understanding your 

Looking to the Future

If we are trying to model how the mind works (it's called “artificial” intelligence, after all), it's logical to draw inspiration from how “we” work.  It’s rare to meet a know-it-all-all human in real life, so specialization is what we end up doing. We go to university, we study something, we work towards being good at that something, and then we make a living out of it. If we need to borrow knowledge, we go to experts in that domain. Sick? Go to the doctor. Facing legal issues? Hire a lawyer. Want to build an application? Hire a developer. 

There are cases for Jacks of all trades, though. For example, in medicine, general practitioners do well to signal issues and point to specialists as necessary. Breadth could also be important in tech. Being a product manager myself, I consider product management a general-purpose role (it can be debated, but not on this post 🙂), given the diversity of daily communication we have to go through (docs, legal, engineering, design, etc.). 

Looking at trends and also the maturity of the domain, there is a growing interest in specialized AI models, as they offer uniquer properties that might serve a use-case way better than the Jacks. Specialization will become more relevant as AI applications become more integrated into our daily lives, requiring more domain specific knowledge to solve for concrete problems. Also, SLMs will make more sense at the edge where resource scarcity is a given.  That said, general-purpose models will probably continue to play an important role in research and development, helping push the boundaries of what’s possible, some like to call that Artifical General Intelligence (AGI), others call it Super (duper) intelligence, the discoveries there will also help build better-specialized models. We will also see hybrids, where general-purpose models are fine-tuned and adapted to specific domains, or built from scratch to serve a purpose but team up for the greater good. 

That’s it! If you want to collaborate, co-write, or chat, reach out via subscriber chat or simply on LinkedIn. I look forward to hearing from you!

Looking into NVIDIA’s market cap, I am reminded of the importance of considering external factors when devising strategy. I found PESTEL to be one good model for mapping the factors.

The illustration above was inspired by James Eagle's post here. The image and the PDF are available here.

Subscribe now

PESTEL

Below is a brief PESTEL analysis of NVIDIA, a framework that assesses the Political, Economic, Social, Technological, Environmental, and Legal factors influencing the company. It is important to consider how external factors impact NVIDIA's market capitalization and strategic direction.

More on PESTEL here.

Political

📉 2022: Geopolitical Tension between Russia and Ukraine: The conflict between Russia and Ukraine has led to widespread sanctions and export controls, particularly in technology sectors. For NVIDIA, this resulted in decreased sales in affected regions and disruptions in their supply chain, impacting their revenue and cost structures.

Economic

📉 2022: Inflation and Rise in Interest Rates: Inflation and higher interest rates generally increase the cost of borrowing and can slow down consumer spending. For a tech giant like NVIDIA, this translated to reduced demand for expensive consumer electronics and professional graphics solutions, impacting their overall sales and profitability.

Technological

📈 2015: Bitcoin Mining Craze: NVIDIA’s GPUs are heavily utilized in cryptocurrency mining. The initial surge in Bitcoin mining increased demand for NVIDIA’s GPUs, boosting their sales.

📉 2018 Bitcoin Crash: “In November 2018, the total market capitalization for Bitcoin fell below $100 billion for the first time since October 2017, and the price of Bitcoin fell below $4,000, representing an 80 percent decline from its peak the previous January. Bitcoin reached a low of around $3,100 in December 2018.” ~ Crypto Bubble

More on what happened here.

📈 2022/2023: Release of ChatGPT: The release of AI models like ChatGPT has spurred interest in AI and machine learning, areas where NVIDIA’s powerful GPUs are essential. This has enhanced NVIDIA's market position in the AI sector, driving demand for their AI-optimized hardware solutions.

Environmental & Social

📈 2019: Pandemic: The COVID-19 pandemic increased social isolation and boosted demand for home entertainment and remote work technologies. For NVIDIA, this translated into higher sales of gaming GPUs and professional GPUs for remote work setups and research in health technologies.

Legal

📉 2022 Supply Chain Issues, Tariffs, Embargo: Legal and trade issues such as tariffs and embargoes, especially given the geopolitical tensions and the global nature of NVIDIA’s supply chain, pose significant risks. These factors increased costs and supply shortages, impacting NVIDIA stocks.

Subscribe now

Conclusion

NVIDIA's market capitalization reflects both internal strategic decisions and the fluctuating landscape of external forces.

PESTEL analysis highlights the interplay of political, economic, social, technological, environmental, and legal factors that can either boost or hinder NVIDIA's performance.

Geopolitical tensions, economic trends like inflation, technological shifts with cryptocurrency volatility and AI advancements, the social impact of events like the pandemic, and the evolving legal landscape all shape NVIDIA's trajectory. This analysis emphasizes the following key insights:

• External Volatility: NVIDIA (and many others) is highly susceptible to factors beyond its direct control, making it crucial to monitor these trends closely.

• Diversification is Key: Mitigating risk requires strategic diversification across markets, technologies, and applications to avoid over-reliance on specific sectors.

• Adaptability: Maintaining agility to adapt products, strategies, and resource allocation in response to external changes is essential for continued success.

To ensure its long-term growth and robust market capitalization, companies like NVIDIA must remain vigilant and proactive in addressing the challenges and opportunities presented by these dynamic external forces.

WHO/WHAT are you PESTELing next?