AI can make you sound fluent in a domain you don’t understand. People who actually know find out very quickly. Credibility gone in the token exhaust of an LLM prompt.
Most of my work at Jeavio now puts me across the table from people who are subject matter experts. My job is to support them in figuring out an AI strategy that works. I need to learn about their world fast. So I do what we all do now. I ask Claude to write me a brief.
What comes back is fluent, citable, and plausible-sounding. That is the problem. The brief describes a clean, general version of the domain. My client lives in a messier, specific one. The framing is often “a view from nowhere”, lacking context and subtlety. It also falls apart under the mildest scrutiny.
Everyone is worried that AI will replace knowledge work. From where I sit, the AI won’t replace you. It will get you fired.
The well-known phrase “The map is not the territory” is relevant here. LLMs are great at building maps. Flattening topographical details into pleasing shapes. But their output can be far removed from what is happening on the ground.
So the scarce skill is taste. Taste is a constraint, not a capability. Figuring out what output from the AI is relevant and how to use it to do useful work. To do so well requires restraint and a willingness to close the laptop and talk to a human.
Enthusiastically credulous use of AI is a problem I have seen show up in all phases of client engagements. Product managers creating AI-generated PRDs bloated with features no one asked for. Engineers embellishing their code, laying the ground for technical debt later.
I don’t think this is a hopeless situation. Working well with AI involves understanding where it can add value and where you have to roll your sleeves up and jump right in.
Today, I still use Claude to write briefs and to get me oriented. But then I interview the experts, ask lots of (sometimes very dumb) questions. I focus on the tribal knowledge, the context that doesn’t appear in documents or wiki pages. Only then do I hand it back to the model and let it do what it is good at: collating what I have gathered and drawing me a sharper map.
Maps are the easy part. The accurate ones still need someone who has walked the territory. To be human in an AI-mediated world is to become an explorer.
Last week, I gave Claude access to my reading life.
Over the last couple of months, I’ve been building QuietReads, a purpose-built app for tracking my reading journey. The app is a virtual bookshelf with an AI assistant called Eko that helps me with recommendations, analysis, and acts as a sort of journalling partner as I read a book. I can add notes to a book, gather my thoughts and explore themes around reading. In short, it’s an app that I built because I was frustrated with performative social networks like GoodReads. QuietReads is a focused app that is built around my reading journey.
Over the last couple of days, I built an MCP server for QuietReads. MCP (Model Context Protocol) is an open standard for connecting applications to external data sources and tools. It was designed with AI assistants in mind, but at its core it provides a data-and-tool-focused approach to integration.
Any application that supports MCP can get authenticated access to a user’s bookshelf and notes via QuietReads’ MCP server. In practical terms, it means Claude (my AI assistant of choice), can now query what I’m currently reading, browse my to-read list, or pull up the notes about a particular book.
I wanted this because my reading life is useful context for how I write, work, and think. When I’m working through a problem with Claude, having my bookshelf and reading notes available allows me to bring together separate, but important parts of my knowledge.
While building the integration, I started thinking about the broader relationship between purpose-built applications and general-purpose AI tools.
Claude calling QuietReads’ MCP Server
Building a Single Purpose App
Before QuietReads existed, I tried using Claude directly as a reading companion. I set up projects, created dedicated chats, and worked with Claude to understand or explore books. While Claude is immensely powerful, this workflow always felt clunky.
Every conversation started from scratch or required careful prompt setup to establish context. There was no accumulated understanding, no sense of a reading journey unfolding over months. And, it was very likely that I would get distracted with whatever else was going on in my work-life when I opened Claude to ask about or to explore a book.
So I built QuietReads.
And building the app made me realize that with AI Assistants, it has become so much easier to build custom, single-purpose, and hyper-personalized apps.
QuietReads knows that I tend to read multiple books at once. It knows I’m currently working through Postman’s Technopoly alongside Elizabeth Bear’s Ancestral Night, bouncing between a critique of technology and a space opera. My conversations with Eko exploring Postman’s work, or exploring literary themes in Kiran Desai’s The Loneliness of Sonia and Sunny enriched my experience of reading those books. Eko also learns my preferences, has access to my library and can make excellent recommendations.
That kind of contextual depth is hard to recreate in a general-purpose tool, no matter how powerful the underlying model.
General Purpose vs. Single Purpose Apps
I do not have the resources nor the intention for QuietReads to compete with a general purpose app like Claude. I don’t have billions of dollars to build a foundation model, nor the engineering team Anthropic has assembled to build a compelling product. I pay a couple of hundred dollars a month for my Claude subscription because it is a powerful tool with amazing and rapidly improving capabilities.
It can search the web, write and execute code, do detailed analysis across domains, and act autonomously on multi-step workflows. These are things my humble book assistant will never do.
QuietReads is deliberately narrow. It knows about books. Claude is deliberately broad. It knows about everything, but making it an expert in any particular field takes a lot of work.
I connected them because I wanted Claude to have access to QuietReads’ context. Building this integration made me think carefully about both tools, and the place for domain-specific apps in a world with AI Assistants with amazing capabilities.
Claude and Eko Have a Conversation..
Here’s a scenario I keep thinking about. Claude, acting as an agent, runs a daily sweep of book review sites, new releases, and author backlists. It knows from QuietReads that I recently finished Yudhanjaya Wijeratne’s The Salvage Crew and have Pilgrim Machines on my to-read list. And it knows that I loved Nathan Fillion’s narration of Salvage Crew. It finds out when the audio-book version of Pilgrim Machines is coming out.
Claude then passes that information to Eko, along with context about my current reading patterns. Eko, which understands my preferences at a deeper level (that I like hard science fiction that engages with AI consciousness, that I’m on a streak of post-colonial literature, that I tend to alternate between dense non-fiction and page-turners), decides whether it should bump up Pilgrim Machines on my to-read list along with sending me a notification that the audiobook is now available on Spotify. Maybe it also adds some notes, perhaps a synopsis of the previous book, to help me get going.
Claude did what it’s good at: broad information gathering and synthesis across the open web. Eko did what it’s good at: applying deep, personal context to a decision.
This may seem like a trivial example, but the pattern – of applying powerful, but general capabilities, to specific workflows – makes sense.
Claude & Eko have a conversation
Are we really in the SaaS-o-calypse?
Replace QuietReads with an HR application that has encoded fifteen years of onboarding workflows, benefits administration edge cases, and compliance with jurisdiction-specific labor laws. The code of that application manifests decades of institutional knowledge that a general-purpose AI agent may not be able to reproduce at an accurate enough level.
Now connect that HR app to a general-purpose agent via an integration layer like MCP. The agent can assist in workflows like performance reviews, résumé screening, or enforcing consistency in job descriptions. The gap between building an MCP server for a personal reading app and exposing a multi-tenant enterprise platform with access control, data residency, and audit requirements is real, and I don’t want to minimize it. But the architectural direction is the same.
The same pattern applies to accounting systems (decades of regulatory logic), project management tools (accumulated workflow optimization), healthcare platforms (compliance frameworks built through years of audit and iteration). These applications embed hard-won domain knowledge and assume liability when something goes wrong. That knowledge doesn’t become useless because a new technology appears.
Are we misplacing AI risk?
Last week saw a panicked sell-off of SaaS shares. SaaS valuations have compressed sharply: the industry’s average forward price-to-earnings ratio dropped from roughly 39x to 21x in four months, the steepest decline since the dot-com bust. HubSpot has lost more than half its market cap. ServiceNow has shed a quarter of its value in early 2026 alone.
The fear is straightforward: if AI agents can help build and automate customized workflows, why pay per-seat licenses for software that wraps those workflows in a UI?
While there has been a lot written about the future of software (Ben Thompson has a great take here), my take is that the threat to SaaS companies is real, but it’s a threat to their delivery mechanism, not to their accumulated knowledge.
The UI may become less important, but the data, the domain logic, the workflow intelligence remain critical. The companies that recognize this distinction early, that invest in becoming excellent context providers rather than clinging to their role as the place where work gets done, could be the ones that thrive.
To put it another way, if you make yourself indispensable, it doesn’t really matter how users interact with your services. They will still pay you. The hard question is whether your product’s value lives in the domain knowledge it encodes or in the UI it wraps around commodity workflows.
Product Strategy in the AI Era
If I were a SaaS product manager right now, I would think very carefully about how to integrate AI capabilities in my core experience. Every SaaS company is doing this, and the result is a dozen mediocre, context-limited AI assistants competing with general-purpose models that are improving on what feels like a weekly cadence.
The alternative could be to invest in a clearly documented, well-structured set of data and tools that general-purpose agents can consume (and pay for). Think of your application as an MCP or API-first context provider. The product decisions become: which data and tools do you expose, which do you keep behind your own experience, and where does your application’s judgment remain essential?
Your monetization shifts from “how many humans log into our UI” to “how much value does our context and domain logic create when consumed by agents acting on behalf of those humans.”
This could be a meaningful and challenging pivot. Per-seat pricing assumes humans are the primary consumers of your product. When agents become the primary interface, pricing needs to reflect the value of context provided, not the number of logins.
Feeding the Machine..
Building QuietReads and then connecting it to Claude made me wonder whether the future of software is a collaboration between narrow, domain-focused applications and powerful general-purpose AI agents. Purpose-built apps hold context. Agents provide reach and reasoning. The connection layer (MCP today, whatever comes next) is what makes them more than the sum of their parts.
For domain specific applications to survive and grow, they must make their context available, clearly, reliably, and with the domain intelligence intact with a reasonable monetization layer. The ones that try to be everything, to build their own agents, their own chat interfaces, their own general-purpose capabilities, will find themselves outpaced by tools built for exactly that purpose.
Eko doesn’t need to be Claude. Claude doesn’t need to be Eko. They need to talk to each other.
“What should I read next?” seems like a simple question. But answering it well requires knowing what the user is currently reading, what they’ve finished recently, and what’s already on their list. When I built QuietReads, a book tracking app with an AI assistant, I faced a choice: pre-load all this context on every request (expensive), build complex routing logic to fetch the right data (brittle), or find a different approach entirely.
In those post, I talk about why I chose this option, the architectural implications, and the tradeoffs involved.
Conversational Interfaces Are Not Deterministic
A lot of mid-career technologists like me still think deterministically. We reach for decision trees, map out every probable permutation, and write test cases to cover each branch. This works well for forms and structured APIs where you control the inputs.
But QuietReads has a chat interface. Users might ask:
“What should I read next?”
“I’m in the mood for something like the last book I finished, but shorter”
“What were my thoughts on that dystopian novel from last month?”
Asking the QuietReads assistant to recommend some books
Each query requires different context. The first needs the user’s want-to-read list. The second needs their recently finished books plus some understanding of “shorter.” The third requires searching through their notes. I couldn’t predict which context any given question would need, and I didn’t want to fetch everything every time.
The traditional approach would be routing logic. For just the first query, you might write something like:
defget_context_for_recommendation(message, user_id): context = {}if contains_recommendation_intent(message): context['want_to_read'] = get_want_to_read_books(user_id) context['recently_finished'] = get_recently_finished(user_id)if mentions_specific_book(message): book = extract_book_reference(message) context['book_details'] = get_book_details(book)# ... and this continues for every intent typereturn context
This gets unwieldy fast. Each new question type requires new routing rules. The intent detection functions themselves need maintenance. And you’re constantly guessing what context the model will need.
LLMs allow us to use a different mental model.
Think of LLMs as expert Lego assemblers. You provide a curated set of bricks (tools), an instruction manual (your system prompt), and let the assembler determine which bricks to use and in what order. You don’t hand them every brick in existence. You give them the right pieces for the task and clear guidance on when to use each one.
Tools as Building Blocks
In QuietReads, I define “context tools” that let the AI retrieve user data as needed:
CONTEXT_TOOLS= [ {"name": "get_user_profile","description": ("Get the user's name and reading preferences. Use this when you need to ""personalize your response or discuss their reading interests." ),"input_schema": {"type": "object", "properties": {}} }, {"name": "get_want_to_read","description": ("Get books on the user's want-to-read list. IMPORTANT: Always call this ""BEFORE recommending any books to avoid suggesting books they already have." ),"input_schema": {"type": "object","properties": {"limit": {"type": "integer", "description": "Max books to return (default: 10)"} } } }]
Each tool has a clear description of when to use it. The model reads these descriptions and decides which tools to call based on the user’s question.
The Agentic Loop
When the model decides to use a tool, we handle that request, execute the tool, and feed the results back. This creates a loop (simplified code below):
asyncdefexecute(self, system, messages, tools, tool_handlers, max_tokens=2048): response =self.client.messages.create(model=self.model,max_tokens=max_tokens,system=system,messages=messages,tools=tools )while response.stop_reason =="tool_use": tool_results = []for block in response.content:if block.type =="tool_use": tool_name = block.name tool_input = block.input# Execute the tool and capture result result =await tool_handlers[tool_name](tool_input) tool_results.append({"type": "tool_result","tool_use_id": block.id,"content": result })# Feed results back and get next response messages.append({"role": "assistant", "content": response.content}) messages.append({"role": "user", "content": tool_results}) response =self.client.messages.create(...)return response
The model might call multiple tools, or call the same tool with different parameters, or decide it has enough context after the first call.
The loop continues until the model has everything it needs to answer. In practice, you should also enforce a maximum iteration count as a guardrail against runaway loops or unexpectedly expensive queries. When the model requests multiple tools in a single response, you can execute them in parallel for performance gains.
This code handles the happy path. Production implementations need additional safeguards: error handling when tools fail or timeout, validation of tool inputs before execution, and graceful handling when the model hallucinates a tool name that doesn’t exist.
Client and Server-side Tools
QuietReads uses two categories of tools. Client-side tools are functions I implement: when the model calls get_want_to_read, my code queries the database and returns formatted results.
Server-side tools are capabilities the AI provider offers (like the web_search tool used below).
I enable web search so the assistant can look up recent book releases or author news. Anthropic’s infrastructure handles the search; I just control when and how it’s available:
tools:web_search:type:"web_search_20250305"name:"web_search"server_side:trueenabled:trueconfig:max_uses:5# Limit searches per request
With some prompt engineering, the model can integrate custom database queries with real-time web searches, producing responses that feel coherent to the user.
The system prompt guides how the model synthesizes information from different sources, when to cite web results versus personal reading history, and how to maintain a consistent voice across tool-augmented responses.
Architectural Implications
It is important to recognize where determinism matters and where it doesn’t. Each tool is a testable piece of code. I can unit test get_want_to_read in isolation, verify it returns the right data, and trust it to behave consistently. What I can’t fully predict is which tools the model will call or in what order. In my work, I have found that even cheaper models like the Haiku family of models do a decent job at tool use.
This separation has practical implications. Tool descriptions are instructions the model uses to decide when to call each tool. Writing clear, specific descriptions is as important as the implementation itself. Instead of pre-loading everything a user might need, I provide minimal context upfront and let the model request more, keeping initial requests fast and reducing token costs.
And while the model chooses its tools, I still control the boundaries. QuietReads runs input guardrails before messages reach the assistant and can validate outputs before returning them to the user.
The Tradeoffs
Tool calling introduces real costs that you should weigh against your specific requirements.
Predictability. With static context, you know exactly what data the model sees on every request. With tool calling, the model decides what to retrieve. This makes cost and performance harder to predict. A simple question might resolve in one API call; a complex one might trigger four tool calls and five round-trips.
Prompt caching. Static context can benefit significantly from prompt caching, where repeated system prompts are stored and reused. Dynamic tool results change with each request, which can reduce or eliminate caching benefits. Depending on your usage patterns, this could meaningfully impact both latency and cost.
Quality assurance. Unit testing individual tools is straightforward, but testing the system end-to-end becomes harder. The model might call tools in unexpected combinations, or skip tools you expected it to use. Comprehensive evaluations become essential because tool calling adds non-determinism to the critical path. I’ll write more about evaluation strategies in a future post.
Refactoring risk. IDE tooling can automatically update function signatures across a codebase. Tool definitions live in JSON objects that describe behavior and parameters in natural language. If you change a tool’s behavior or modify its parameters, automated refactoring won’t catch the JSON definitions, and the mismatch may not surface until production. LLM-based coding agents like Claude Code handle this well, and adding tool-specific checks to code review agents helps catch these issues.
Latency. Each iteration of the agentic loop requires a round-trip to the API. For QuietReads, this is acceptable. For applications where response time is critical, the additional latency may be a dealbreaker.
That said, tool calling offers real advantages beyond flexibility. Token costs can decrease because the model only retrieves data it actually needs. Direct tool calls avoid the protocol overhead of intermediary layers like MCP servers. And tools create a clean separation of concerns: database migrations, API upgrades, or new data providers can happen without touching the prompt.
This pattern fits QuietReads: read-only tools, flexible latency, and context costs that exceed API overhead. Applications with side effects, strict latency, or predictable context needs may want different approaches.
Navigating a Mindset Shift
Building with tool calling requires accepting the risk of non-deterministic code execution. You cannot predict every code path. Instead of mapping out decision trees, you’re designing capabilities and constraints. You’re giving the model a well-stocked toolbox and clear guidance, then trusting it to assemble the right response.
You control what tools exist, what data they access, what the model knows about when to use them, and what guardrails prevent misuse. The model handles the dynamic orchestration that would otherwise require hundreds of lines of if/else chains.
For those of us who’ve spent years thinking in flowcharts, this shift takes practice. But once it clicks, you start asking different questions: not “what are all the paths a user might take?” but “what capabilities does the model need, and how do I describe when to use them?”
On May 6, 2010, the Dow Jones dropped nearly 1,000 points in minutes. A trillion dollars vanished. And then the market bounced back. The whole thing took thirty minutes.
Today, we call it a flash crash. Flash crashes happen when unusual trades trigger chain reactions across interconnected algorithms. Each algorithmic trader behaves as trained. But the collective behavior spirals into something catastrophic. The market is a collective intelligence that breaks down in the face of unusual situations.
I spent 13 years in capital markets, supporting traders and deploying models in volatile FX environments. I was there in 2008 when credit markets froze, and in the 2010s when high-frequency algorithmic trading took over capital markets, leading to many small and large flash crashes.
Today, I work as a technology consultant supporting companies in their AI initiatives. A question I hear constantly: “What types of problems can AI actually solve?”
The honest answer: it depends. And also, how ready are you to face flash crashes?
Taleb uses these terms to describe two different environments.
Mediocristan is where patterns are stable, and the past is a reliable guide to the future. Think of measuring human height. You’ll get a bell curve. No single person will be tall enough to affect the average. Outliers exist, but they don’t dominate.
Extremistan is where rare events have an outsized impact. Think of book sales or wealth distribution. A single outlier (Harry Potter, Jeff Bezos) can dwarf the sum of everyone else. The past doesn’t prepare you for what’s coming because what’s coming might be unprecedented.
AI systems are trained in Mediocristan. They learn statistical regularities from historical data. They work beautifully when deployed in Mediocristan. They break when deployed in Extremistan.
Another metaphor can also help us think about *what* AI does: the epicycle.
The Epicycles Problem
Rohit Krishnan’s recent essay “Epicycles All The Way Down” provides a helpful framework to think about how LLMs work.
Before Newton, astronomers predicted planetary motion by adding “epicycles” (circles on circles) to Ptolemy’s model. It worked for prediction. But it was the wrong underlying model. When Newton discovered the inverse-square law, the epicycles became unnecessary.
Krishnan says that AI is brilliant at learning epicycles. It struggles to discover gravity.
The technical version: given any dataset, many different underlying rules could have produced it. AI learns a rule that fits the data. Not necessarily the rule that actually generates reality.
When conditions shift outside the training data, the model doesn’t know it’s in trouble. It just keeps extrapolating. That’s a flash crash waiting to happen. Krishnan says that, just as capital markets are forms of collective intelligence, modern AI systems are as well. Their behavior stems from generating hypotheses that fit observed behavior without understanding cause and effect.
Taleb describes the risks of predicting the future based on the past. Krishnan warns that AI can make accurately-seeming predictions without a model of how the world works.
Both these ideas help us think about where and how to deploy AI capabilities.
A Practical Heuristic
Here’s how I think about evaluating AI investments: Is your project solving a problem that looks like a game of roulette, a hand of poker, or making decisions in the fog of war?
Roulette problems have fixed rules and known odds.
The wheel doesn’t change. The probabilities don’t shift based on what happened on the last spin.
Code generation for standard CRUD applications fits here. Authentication flows, database queries, REST endpoints. These are known domains with established patterns. Same with SQL generation from natural language and document summarization.
The problem space in a roulette-like problem is bounded, the inputs are structured, and the AI has seen thousands of examples that look almost exactly like what you need.
Provided you can create a robust testing strategy, AI is a good fit for this class of problems.
Poker problems have fixed rules but hidden information.
Other players adapt to your moves. The patterns shift because the environment responds to your actions.
Chatbots are the classic example of a poker-like problem. You’re building a conversational interface over a non-structured domain. You cannot predict everything a user might ask. But you can constrain the space through guardrails, deflection, and human-in-the-loop escalation.
Scheduling and pricing optimization fit here, too.
Poker-like problems have genuine uncertainty, but it’s uncertainty within a known structure. You can model the constraints and hedge the risks. The combination of tool use and human oversight keeps the system from wandering too far off course.
Use AI as an enabler or an accelerator to tackle poker-like problems. Keep humans in the loop for consequential decisions.
War problems are uncertain and chaotic
The rules themselves change. The terrain shifts while you’re navigating it. Adversaries rewrite the game while you’re playing. Your Roman legions may end up facing War Elephants crossing the Alps.
Making decisions about resource allocation in the face of competition, automating or using code-generation capabilities in a new domain, or making investment decisions in times of economic or political upheaval are war-like problems.
Here, second-order effects dominate, and relevant patterns don’t exist in the training set.
AI can help with subsets of these problems. It can generate scenarios, synthesize information, and explore options within known constraints.
But the human has to drive. The pattern-breaking is the problem, and no amount of training data prepares a model for out-of-band situations.
The Question
You don’t trust a market to self-regulate during a crisis. You build circuit breakers. The same logic applies to AI deployments.
The 2010 flash crash was a failure of collective intelligence in the face of unexpected inputs. Your AI deployments face the same risk.
Before your next AI investment, ask: Is this roulette, poker, or war?
A DDoS (Distributed Denial of Service) attack overwhelms a scarce resource with a flood of traffic, making it unavailable to its intended users.
We’re DDoS-ing ourselves with AI Slop.
I came across a post on Hacker News that captures this moment. Someone filed what seemed like a comprehensive vulnerability report about cURL, a widely used command-line utility. The entire report was AI-generated and made no sense.
When called out, the reporter published a polished apology that was also clearly AI-generated. (See screenshot).
The entire exchange is surreal, and it wasted the time of someone maintaining tools we all depend on.
My LinkedIn feed is filled with the kind of AI slop that is now easy to detect. Glib prose that says nothing in paragraph after paragraph of polished text. Emails are getting longer, Confluence pages are more verbose, and PRs arrive with hundreds of lines of changes with little explanation.
On forums like Hacker News and technology subreddits, there are posts from leads and managers in absolute despair as they try to cope with this flood.
What we are DDoS-ing is attention.
When attention is not given to reviewing code and providing thoughtful feedback on documentation, the entire ecosystem that is nurtured by attention degrades. Is poisoned.
There is a flip side to this problem. When so many things bear the hallmarks of AI slop, it becomes easy to bring a jaundiced eye to everything we encounter. An em-dash? Slop. It’s not just pervasive, it’s annoying.
I read my posts from a few weeks ago and wonder when I became a slop-peddler.
AI tightens up prose and fixes typos, but it also applies a uniform, flat AI-slop-primer to all output. And it’s not just prose. AI-generated code reads the same. AI-designed websites have the same blue-neon styling.
I am no Luddite. I love using AI, I write about it, and I work on projects that focus on building AI capabilities. AI is a valuable tool that has significantly improved my life.
However, unlike an IDE, there is very little friction in using ChatGPT or Claude. You can write a half-baked, two-sentence prompt, and the AI will enthusiastically go about writing a post, building a website, or submitting a vulnerability report.
As leaders, we need to think carefully about building a culture that encourages both the open-ended exploration of these tools and their disciplined use in day-to-day work.
Otherwise, we are going to DDoS ourselves into a quagmire of AI slop.
MIT released a study showing that 95% of organizations are getting zero return from their GenAI investments.
While some may claim this proves AI is all hype, a closer reading suggests the findings aren’t a death knell for the technology. Instead, they reveal critical truths about how to succeed.
🎯 It’s Goodhart’s Law writ large The report shows GenAI adoption is driven by areas like sales and marketing, where success is easier to measure. Pilots are optimized for visible, top-line metrics. However, the study suggests the most dramatic cost savings come from the back office – reducing BPO contracts and agency spend, where the ROI is clear but less flashy.
💡Knowledge and memory are sensitive to each organization General-purpose AI tools will never work perfectly because each company has its own ontology, its own ways of making sense. Building tools sensitive to this is critical. But there is a contradiction – the study finds that these highly-contextual internal projects fail twice as often as those led by external partners. This is the gap where a strategic partner can help bridge deep internal context with external expertise. (🙋🏾♂️ – Jeavio)
🤨 There is a productivity paradox at the heart of GenAI adoption Workers from over 90% of companies surveyed reported regular use of personal AI tools. If individuals are seeing productivity gains, why does it fail at the aggregate? The report suggests the reason is simple: the most successful AI adoption is bottom-up, not top-down. Successful organizations source initiatives from “frontline managers” and “power users,” not central labs.
At Jeavio, we live this principle. We host hackathons and sponsor open-ended projects to explore how AI can address real-world problems. The ADAPT platform, our flagship AI initiative, began as an internship project in 2023.
I got caught in a thunderstorm just outside the town of Lovettsville, VA on Friday. I pulled into a gas station and spent thirty minutes in the company of a taciturn storekeeper while I waited for the sound and light show to end. In the end I gave up and rode home in pouring rain, arriving soggier than a neglected bread pudding.
Riding motorcycles is stupid. It is dangerous, and my minivan is a way more comfortable way to see the world.
And yet – I love my motorcycles. I love feeling the engine braking as I downshift into a curve. I don’t even mind the bugs making a mess of my visor as I ride through the Virginia Spring.
It is precisely the discomfort and friction involved in riding motorcycles that makes it a compelling experience. It’s the same friction involved in lifting weights or in figuring out a particularly nasty software bug.
Friction leads to new experiences, and to growth.
And yet, AI is being deployed across knowledge work to eliminate friction entirely. Writing an email – ChatGPT can help. Software – just vibe code through it. Trying to understand a complex topic – ask Gemini to summarize.
But there are downstream effects.
The more AI gets used in day-to-day work, the more it becomes clear that we’re not eliminating friction, but instead just displacing it (HT to Rohit Krishnan – see below). The friction shifts from the developer to reviewer – who now must deal with 10 PRs a day instead of 3. It shifts from the product manager to the development team – who now must deal with a firehose of AI-generated User Stories.
Friction builds credibility.
There is a reason why doping is such a taboo in professional sports. Lance Armstrong incinerated his credibility when the allegations of widespread doping turned out to be accurate.
Credibility remains the only viable currency in a world where AI can do the heavy lifting of knowledge work. And today, there is no better way of incinerating it than passing off low-effort AI slop as your work.
Social mores will evolve as we become used to AI tools. It’s very likely that as the models get better, we’ll just embrace this as the new way of working and laugh at pieces like this. AI is surely just the next stage of knowledge work – following calculators and Excel.
My minivan is superior to my motorcycle and yet, I remember my motorcycle rides more than I do car trips. It’s because the discomfort, the danger, and the friction contribute to my own growth. This is something worth thinking about as we embrace AI.
This post was inspired by two very thought provoking posts – many thanks to Rohit Krishnan and Kyla Scanlon. Check out their Substacks
LLMs are powerful tools – but credulous users risk being stuck in a dangerous place: Mediocristan, the land of the average.
Mediocristan appears in Nassim Nicholas Taleb’s Incerto series. It’s a domain where outcomes are predictable, smooth, and derived from averaging all inputs.
Sound familiar?
LLMs predict the most likely next token based on massive training data (yes, yes – I know about RLHF, etc.). They are statistical engines of mediocrity by design.
And like it or not, LLM use pushes us deeper into Mediocristan daily.
A recent viral piece in NY Magazine exposed how university students rely utterly on ChatGPT. But it’s hardly limited to academia—I’ve encountered memos, emails, and pitch decks that bear the unmistakable hallmarks of AI slop.
We’re outsourcing our thinking to Mediocristan with great enthusiasm.
On the other side lies Extremistan—the domain of consequential outliers where one event’s probability is uncorrelated with another. Mathematically, it’s the fat tails of distributions where Black Swans lurk.
Extremistan is where interesting and unexpected things happen—where growth and destruction co-exist. The very release of ChatGPT in 2022 was itself an event straight from Extremistan!
I’m as enthusiastic an LLM user as any, but comparing my writing from 2020 to today, I’m clearly on the express train to Mediocristan.
This realization is jarring. So what now? Should we embrace the slop and relocate to Mediocristan? Angrily denounce AI and revert to writing screeds on clay tablets?
The critical skill for navigating our new knowledge economy will be deciding where and how to use AI.
Meanwhile, Mediocristan steadily expands, assimilating new domains and making them ripe for disruption from—you guessed it—Extremistan.
AI tools are supercharging individual productivity—but are they also undermining team cohesion?
As a technology executive straddling engineering leadership and client advisory roles, I’ve been an early and enthusiastic adopter of generative AI. Tools like Claude and ChatGPT have transformed my workflow. I can go from idea to prototype in hours, not days. Strategy memos, design documents, and new product concepts come together faster than ever before.
This feels like progress—and in many ways, it is. But there’s a growing paradox I can’t ignore: the more productive I become with AI, the more I risk overwhelming the very teams I lead.
From Brainstorm to Broadcast
I’m all about writing things down. Multi-page emails, long JIRA comments, multi-message Slack threads -> I am THAT guy. This was already a challenge. Now, with generative AI in the mix, it’s even easier for me to take ideas and turn them into fully fledged messages or documents.
It feels productive. But I know that every new AI-assisted memo I send can also create confusion—or even dread—on the receiving end. It’s not just messages, it’s also code, designs, presentations, etc.
What used to be a collaborative back-and-forth now feels like a broadcast. Instead of whiteboarding ideas together, I’m unintentionally showing up with something that already feels “decided.” Even when it’s not.
Fermenting Context Collapse
Teams don’t just need to know what to do—they need to understand why. That context often emerges organically: a passing comment, a shared concern raised in a meeting, a collective moment of clarity. But when AI tools let leaders bypass that messy, human process and jump straight to the output, something critical gets lost.
We’re seeing a form of context collapse: the shift from shared understanding to unilateral information delivery. It might be efficient, but it chips away at clarity, trust, and momentum.
Losing the Plot (Together)
Teams don’t just execute plans—they co-create the narrative that gives those plans meaning. That narrative helps people understand how their work fits into a bigger picture, and why it matters. This helps reduce confusion and leads to clear execution.
When leaders lean too heavily on AI to shortcut the narrative-building process, teams are left with tasks but no story. This can be especially damaging in cross-cultural or distributed environments, where communication already carries more friction. The result? Misalignment, low engagement, and missed opportunities for innovation.
The Risk to Innovation and Ownership
Harvard Business School’s Amy Edmondson talks about psychological safety as the bedrock of high-performing teams.
When people feel like decisions are made without them—or worse, that their input doesn’t matter—they stop contributing. They play it safe. They wait to be told what to do.
AI acceleration makes it dangerously easy for leaders to skip past the slow, participatory parts of leadership. But those are the very moments that create buy-in, spark creativity, and foster innovation.
Developing Restraint
Here’s the paradox: to lead effectively in an AI-accelerated world, we may need to slow down.
What I’ve come to see as an essential leadership skill is what I call AI restraint—knowing when not to use the tools at your disposal.
That means:
Creating space for co-creation: Holding regular “no-AI” brainstorms where ideas emerge collaboratively
Thinking out loud: Sharing early thoughts, not just polished AI-assisted conclusions
Rebuilding narrative: Giving teams time to shape the story around the work—not just deliver on tasks
Signal your intent: When sharing early ideas, explicitly say you’re thinking out loud. Make it clear that these aren’t directives—they’re starting points. This invites dialogue instead of quiet compliance.
Winning Together By Slowing Down
It is easy to generate what looks like a polished strategy doc in five minutes. But in a world already overrun with AI slop, the real differentiator isn’t speed. It’s discernment.
It’s learning how to balance velocity with clarity, and productivity with participation.
The future of leadership isn’t about issuing more brilliant ideas.
It’s about knowing which ideas matter, and creating the space for teams to make them real – together.
It turns out that in this exponential age, judgment, self-discipline, and the wisdom to slow down may be our most valuable leadership capabilities.
