On one hand, there’s the likely more familiar story. It’s often in, behind, or around the headlines. It’s being told breathlessly and constantly. Across industries, across the political spectrum, on every major news network, in company meetings. It says that AI is both imminently and, somehow, currently, unnervingly capable. Half unbridled exuberance, half white knuckling anxiety.

The past several weeks have demonstrated the alluring hold this first story has. An open source AI agent framework goes viral, ships with glaring security issues, buys a guy a Hyundai, and gets its creator hired by OpenAI and its AI agent social network spinoff acquired by Meta. A karaoke machine company and a well written sci-fi dystopia compete to see which can elicit a bigger jump scare from the stock market. The exuberance and the anxiety feed off each other.

There are some legitimate reasons this story persists. The St. Louis Fed found that over half of U.S. adults now use generative AI in some capacity, outpacing both PC and internet adoption at the same stage after their first mass market products. In the software industry, AI coding assistants have been a breakout hit, with surveys showing between 72-91% adoption.

But there’s another story also being told. It’s not as loud. It isn’t a secret, it just isn’t as provocative. It’s not typically told by the politicians, the headlines, the CEOs, nor the industry analysts. You’ll hear it when talking to technical folks that regularly use or implement the technology. Their read on things tends to line up with the following:

• According to S&P Global, 42% of companies abandoned most of their AI initiatives, up sharply from 17% the prior year. The average organization scrapped 46% of proof-of-concept projects before reaching production.

• PwC’s Global CEO Survey found that 56% of CEOs report neither revenue increase nor cost decrease from AI over the prior 12 months. Only 12% report both.

• BCG’s AI Radar reported that 60% of CEOs have intentionally slowed AI implementation due to concerns over errors and malfunctions.

In other words, despite high usage and adoption in some areas, implementations are struggling.

The U.S. Census Bureau tells a similar story. AI use in actual production rose from 3.7% in September 2023 to roughly 10% by September 2025. When the Bureau was later prodded to broaden its criteria to include any business function, the number jumped to 17.6% (safe to say that this is including even nominal chatbot usage). Over 50% of Americans are using gen AI but less than 20% of businesses are using it in actual production.

No matter how you look at it, there’s a large gap between both the narratives and numbers of these two stories. But both stories do agree on one point. The capabilities are indeed real.

So if capability seemingly isn’t the problem, then what is?

The Capability-Reliability Gap

Anthropic put out an article a couple weeks ago introducing a measure that looks at theoretical AI capability vs. observed real world usage across a variety of jobs.

This chart of theirs shows the massive gap between theoretical capabilities and actual usage. Even arguably the best fit job categories (i.e. “Computer & math” occupations) are supposedly only at 33% coverage. But the paper frames all of that gap as a diffusion timing problem.

As capabilities advance, adoption spreads, and deployment deepens, the red area will grow to cover the blue.

It’s a teleological assumption. It’s presented as inevitable.

The article pays marginal lip service to asking why the gap exists, but no serious interrogation. This “capability-first” framing is deeply embedded in the AI industry and shows up everywhere.

A draft paper published last month puts some rigorous measurement behind what many of us have been feeling and what I believe helps explain that coverage gap.

“Towards a Science of AI Agent Reliability”, from Stephan Rabanser, Sayash Kapoor, and Arvind Narayanan, evaluated 14 models from OpenAI, Google, and Anthropic across 18 months of releases. Their core finding was that nearly two years of rapid capability progress produced only modest reliability gains.

All three major providers cluster together on this. It’s an industry wide pattern.

It often feels like the AI industry is continually glossing over the fact that capability and reliability are fundamentally different qualities. We tend to use “accurate” and “reliable” interchangeably, but they describe different things. A model can ace a benchmark (capability/accuracy) and still be a liability in production (reliability). The authors put it well:

When we consider a coworker to be reliable, we don’t just mean that they get things right most of the time. We mean something richer: they get it right consistently, not right today and wrong tomorrow on the same thing. They don’t fall apart when conditions aren’t perfect. They tell you when they’re unsure rather than confidently guessing. When they do mess up, their mistakes are more likely to be fixable than catastrophic.

That “richer” meaning is what the paper breaks down into four dimensions.

• Consistency: Agents that can solve a task often fail on repeated attempts under identical conditions. Many models have trouble giving a consistent answer, with outcome consistency scores ranging from 30% to 75% across the board.

• Robustness: Most models handle genuine technical failures (server crashes, API timeouts) gracefully. But if we rephrase the instructions with the same semantic meaning, performance drops substantially.

• Predictability: Agents are not good at knowing when they’re wrong. This is the weakest dimension across the board. When agents report confidence, it often carries little signal. On one benchmark, most models couldn’t distinguish their correct predictions from incorrect ones better than chance.

• Safety: Recent models are noticeably better at avoiding constraint violations, though financial errors, such as incorrect charges, remain a common failure mode. We use safety narrowly to mean bounded harm when failures occur, not broader concerns like alignment. We are still iterating on how we measure safety, so we report it separately from the aggregate reliability score.

So far, scaling up to bigger models has not guaranteed improvements across all these dimensions. Calibration and robustness may see improvements but then consistency takes a hit. More capability often leads to more behavioral range, more ways to do the same thing differently each time. But the standard evaluation practice is to run a benchmark once, report a number, and move on.

OpenAI’s latest and greatest model released March 5 2026, GPT-5.4, scores well on capability benchmarks while simultaneously showing notably high hallucination rates on tests measuring factual recall. And it’s not just OpenAI. The chart below shows a consistent pattern across both OpenAI and Anthropic: as models get more capable, their hallucination rates tend to go up, not down.

Even when industry evaluations acknowledge consistency, the discourse at large tends to downplay it.

The oft-cited METR evaluations show increasing capabilities of LLMs to complete complex and lengthy software tasks. This is too often stated in ways like, “LLMs can now do 10 hours of work successfully.” Rather than, “LLMs can now do 10 hours of software bound work successfully 50% of the time. And 1 hour of software bound work successfully 80% of the time.” Put another way, imagine a colleague who hands you an hour’s worth of work five times a day. Four of those are fine. The fifth is complete slop, and you won’t know which one until you check. Now imagine that same colleague takes on a full day’s project. It’s a coin flip whether what they hand you is fantastic or unusable. Bigger wins, bigger headaches.

So the models are capable. They’re just not comparably reliable. If the AI industry doesn’t develop proper practices that meaningfully address the varying dimensions of reliability, then that red area from Anthropic’s paper, representing actual usage, might not grow smoothly at all. It might stall or grow in uneven ways. It might require reliability scaffolding as a prerequisite. If reliability is the actual bottleneck, then what kind of problem is it?

Reliability Is a Systems Problem

All signs point to reliability not being a property you can scale into existence the same way you can scale raw capability. Rather, it requires intentional design and engineering. It’s a systems problem. It requires architectural decisions, constraints, system design, evaluation, and deep contextual knowledge about the problem you’re trying to solve.

Pluribus, a system built by Carnegie Mellon University and Facebook in 2019, beat elite professional poker players. For years, the broader poker AI field had been throwing scale and deep learning at the problem without cracking multiplayer play. The system that actually beat the pros cost about $144 in cloud compute and ran on a single server. It was a compound system consisting of self-play algorithms, game abstraction layers, and a realtime search engine. Multiple components with distinct roles, working together.

Cicero, a Diplomacy-playing bot that Meta built in 2022 operated on a similar principle. A language model for communication, a future simulator for strategy, a planning engine, all orchestrated together. And in the research paper, the authors mention that they set it up so it wouldn’t lie. Not because of alignment fears (they weren’t afraid it was going to blackmail anyone), but because it would’ve been unfair to other players otherwise.

Computer scientist Cal Newport explained in a recent interview that what made this possible was the architecture:

There’s no amorphous neural network... it’s six or seven components. We know what they do. [...] They wrote that simulator. It’s not a neural network. They wrote it and they just coded it to say, don’t look at possibilities where you lie. So it doesn’t. So that machine can’t lie. There’s no out of control piece to this.

Newport may be oversimplifying a bit there. Cicero’s honesty wasn’t a hard coded rule exactly. The team trained the dialogue model on a curated subset of human games where players weren’t lying, and architecturally constrained the system so that what Cicero says stays tethered to what it actually plans to do. Neural networks were very much involved. But his broader point stands. Cicero is a specialized composed system rather than a single monolithic model doing everything. And because of that compositional architecture, the team could make a design decision about honesty and then actually enforce it.

What made these systems work was human judgment about architecture, constraints, and composition. The model was a component in a broader system.

None of this is radical or novel. This is just how functional software systems have always been built. The monolithic model narrative implicitly asks us to believe that everything we know about how working technology gets developed, deployed, and maintained simply stops applying. That’s the extraordinary claim. Not the idea that systems should be made up of specialized, legible, constrained components.

And the industry intuitively knows this. The meteoric rise of OpenClaw didn’t come from showcasing some breakthrough in raw model capability. It captured imaginations because it gave people the feeling of owning a composable system they could shape. The fully managed frontier models and tooling paradigm structurally can’t offer that. You can use the same proprietary models under the hood, but owning the orchestration layer reintroduces the optionality that full dependence on a provider’s ecosystem can’t provide. And OpenClaw achieved this cultural moment even as it shipped with hundreds of security vulnerabilities and the reliability profile of a hobbyist’s proof-of-concept. Yes, it’s likely partially a fad, and we’ve seen prior waves of AI agent viral moments come and go (AutoGPT, BabyAGI, Manus, rabbit R1s “Large Action Model”, and others). But the gap between what people expect from these technologies and what they can actually deliver is probably closer than it’s ever been, while still being much larger than most enthusiasts want to accept. That narrowing gap has produced a renewed and profoundly larger base of interest in sincerely pursuing composable, orchestrated systems. Even if OpenClaw itself isn’t the answer, the nerve it struck is telling.

I also see this in my work. I build production voice AI systems for businesses. Something as common as a scheduling voice agent, perhaps for a medical clinic, still requires significant engineering and experimentation. There is no tried and true way yet to build and deploy that where a clinic can just turn it on, mostly stop thinking about it, and trust it to function without any issues. Off the shelf solutions still require a considerable amount of customization (not just because of AI agent unreliability, but also because of all the challenges typical to IT integration). Almost nobody talks about this because the dissonance between that reality and the dominant narratives is too uncomfortable to reconcile. These narratives are buoyed by persistent myths like the notion of “effortless AI”, which I’ve written about before.

We’re simultaneously told these models are so powerful they’ll replace entire categories of jobs, and yet reliably automating a phone call to schedule an appointment requires a nontrivial amount of system design and engineering (not to mention ongoing operation and maintenance).

The AI Agent Reliability paper’s recommendations for deployers are pretty straightforward . They stress the importance of clearly distinguishing automation from augmentation. If a staff member reviewing medical appointments scheduled during off-hours via your voice agent catches an error, it may be a bit annoying for them to call that person back later. But a fully autonomous AI agent that books an erroneous appointment causing a patient to miss a doctor’s appointment is unacceptable.

The paper also recommends building internal evaluations tailored to the specific context and considering reliability thresholds before moving from sandbox to production, “the way aviation requires certification before service.”

That evaluation work itself can be a competitive advantage. It’s the type of institutional knowledge you can only build up by experimenting with your actual data. Generic benchmarks won’t tell you how a model will behave in your environment, with your data, or under your constraints. Customized evaluations are a necessity, and the work of building them is deeply contextual. It resists commodification.

You don’t have to take my word on any of this. NVIDIA, the company that has arguably benefited the most from the AI scaling gold rush, itself published a paper in September 2025 literally titled “Small Language Models are the Future of Agentic AI”. The paper argues that for the repetitive, specialized tasks that AI agents actually perform in practice, smaller models are more suitable and more economical, and that the future is heterogeneous systems where small specialized models handle the bulk of the work and large models get invoked selectively. For the company selling the massively expensive shovels, that’s a notable thing to put in writing. NVIDIA also has its own growing family of open source smaller models built for exactly this kind of modular use, from language models (Nemotron) to speech-to-text models (Parakeet). There’s also NVIDIA’s Groq “acquisition”. NVIDIA spent roughly $20 billion acquiring rights to a company’s technology whose entire selling point is custom AI chips built around low latency, low cost inference. That bet lines up with the view they laid out in the SLM paper. If the future is heterogeneous agentic systems running lots of smaller specialized models, you want inference infrastructure optimized for that, not just bigger clusters running bigger models.

Optionality and Agency

In addition to making reliability tractable, composed systems also preserve something else that the dominant paradigm structurally forecloses on: optionality.

Organizations working within composed systems can keep their hands on all the various knobs. At each boundary and breakpoint, they get to make decisions about what to build, what to outsource, what to control tightly, and where to accept tradeoffs. Not every component will be locally owned or fully controlled. Sometimes a frontier model is absolutely the right tool for a specific part of the system or workflow. But the wider architecture itself preserves the agency to decide. Maybe one part of your system requires more external capabilities than you’d prefer, but you’re able to balance that with tighter control in other parts. More responsibility comes with that, yes. More upfront and maintenance labor too. But it also means your institutional knowledge, your domain expertise, your proprietary data, all of it becomes woven into whatever your competitive edge is, rather than remaining an inert input to a commodity model that everyone else also has access to.

The monolithic frontier path collapses this. It concentrates dependency, homogenizes capability, and often leaves organizations waiting for someone else’s next model release to solve their problems.

The incentives for composed systems aren’t purely technical. Compliance and privacy requirements, liability and risk considerations1, competitive differentiation, the basic economics around generating tokens from expensive frontier models. Everything about the current landscape points toward compound, specialized AI systems becoming the norm. The model as one component in a broader system, not the whole product.

The Question That Follows

Which raises a final question.

Hundreds of billions of dollars are being poured into hyperscale data centers right now. Communities are being asked to accept higher electricity prices, pollution, strained resources. All of it premised on the assumption that the future belongs to ever larger general purpose models and that there will be an insatiable demand for them.

But if the actual path to ubiquitous, reliable “AI that just works” runs through specialized, composed, contextual systems (systems that are smaller, more diverse, and more amenable to a distributed mosaic of compute architectures and environments) then the assumptions underwriting that investment may be fundamentally misaligned with where the real value is heading. Their role as but one component in a much broader ecosystem would be in stark contrast to the center of gravity the current narratives require them to be.

What happens to all of that if it turns out most businesses, most use cases, most solutions don’t actually need them nearly as much as everyone currently assumes?

The hardest problems are already on their way to being solved. The friction you’re feeling now is temporary. If you just wait a little bit longer, the models will improve and all those integration headaches will go away.

It sounds reasonable. Why spend time on solving problems that might disappear on their own? Why build complex systems when the ground is still shifting underneath you?

This is the myth of “effortless AI”. The idea that the messy, unglamorous work of stitching new capabilities into real systems will soon be trivial if not outright obsolete. The myth says: the real innovation is happening at the model layer, the infrastructure layer – that it’s happening fast, and it’s being done elsewhere. Your job isn’t to solve hard problems, it’s to wait for the hard problems to get solved for you, then plug in the solutions when they’re ready.

What makes this tricky to talk about is that different strains of AI discourse overlap and twist around each other. You’ll see leaders from big AI labs warn about imminent societal collapse, politicians parrot similar talking points, books with press tours heralding dystopia...all against the backdrop of investment and infrastructure buildouts continuing at dizzying levels. These narratives reinforce each other and mix together into a general atmosphere of not just perpetual substantial advancement of AI but anticipated swift, widespread adoption and integration of it. When I say “effortless AI”, I’m talking about that second part. The adoption and integration. And specifically from the perspective of those who will make up the lion’s share of it: enterprises.

Right now you may be thinking, “Who actually says implementing AI is effortless? I just saw Andrej Karpathy and Ilya Sutskever talking about how hard this stuff is and how many unsolved problems there are.” And you’re right. Many of us working in the field know better. But it’s seldom stated so bluntly. That’s part of what makes it tricky. It’s hard to show absence. It’s hard to show the voided interstitial space where you’d expect more substance. It’s in the “but” that always follows any acknowledgment of difficulty. In the conversational scurry to safety: “but there’s new updates every week”, “it’s all changing so fast”, “we need to be ready”, “this is the worst it’ll ever be”. Don’t get me wrong, I do this too. That’s part of why I wanted to explore this. We launder the narrative of effortless AI by what we’re not saying. And that’s what can make it hard to nail down.

Learned Innovationlessness

“Effortless AI” is a comforting story. It takes the pressure off. It tells you that it’s fine to not have anything figured out yet, it’s just temporary. It allows us to conflate inaction with patience, disengagement with prudence.

But narratives shape behavior. And one behavior I keep seeing, in client conversations, in industry discourse, in the way some teams approach AI projects, is a kind of... “learned innovationlessness”.

It’s this strange paralysis where some people have convinced themselves that unless you’re working at the model layer then you’re incapable of “real” innovation. Everything else is derivative. Doomed to be absorbed by the next model release or the next framework or whatever OpenAI, Google, or Anthropic announces next quarter.

To be clear, the belief isn’t just “AI will get better”. That’s a given. The belief is “AI will get better without me, and therefore I don’t need to act.”

If you squint then it might look like optimism. But it’s more of an optimistic type of fatalism.

It removes personal agency. It devalues context-specific engineering and creativity. It frames innovation as unnecessary and offloads responsibility to labs and vendors. It convinces people that their own domain knowledge, their own hard-won understanding of their business, their systems, their constraints, and their customers is really of no consequence.

By choosing inaction, by deferring to the comfortable narrative of inevitability, the only thing that actually becomes inevitable is what you lose out on. The learnings you would have accumulated. The institutional knowledge about how to make this stuff work in your specific context, in practice. Potentially even a voice in the discussions that will set standards and conventions.1

You’re not much better off than the doomers if you think your own creativity will be deprecated by some company’s future model update. That’s resignation dressed up as excitement.

The Last Ten Miles

I spend my days building production voice AI systems2 for businesses. And what I keep running into are problems that neither better models nor widely accepted solutions have solved.

• Figuring out the right kind of telemetry for workflows hinged upon non-deterministic models so you actually know what’s going on in your system and can explain when and why things go wrong.

• Building guardrails for inputs and outputs to ensure both the integrity and fidelity of the system.

• Accounting for fluctuating throughput and concurrency needs and factoring in how that affects decisions to use cloud APIs vs. dedicated compute / self-hosted deployments.

• Navigating the latency expectations and accuracy tradeoffs that are inherent to real-world spoken conversations.

• Dealing with compliance requirements in regulated industries like healthcare where an intelligible system with auditable, human-readable traces is non-negotiable.

• Designing human-in-the-loop workflows that don’t just treat your subject matter experts as fail-safes or rote approval-button pushers.

• The joys of small business IT systems.

None of these problems are solved by the latest and greatest models nor the currently fashionable agent frameworks. The unavoidable work is figuring out how to actually integrate non-deterministic technology with the messy, specific, constrained reality of a given organization’s systems and needs.

You can see evidence of this everywhere. From study after study of enterprises struggling with implementation, to conflicting reports of flattening adoption curves. And that’s all happening too despite a proliferation of models, frameworks, platforms, SDKs, and protocols for building “AI agents”3. 60+ different approaches, from every major tech company and a small army of startups, with no universal standards and competing interoperability schemes.

If connecting AI models to enterprise systems was a solved problem, we would be regularly seeing unequivocally successful implementations and we wouldn’t have this fragmented landscape. We’d have a handful of dominant patterns that the industry was starting to congeal around and some vendors offering holistic, consistently reliable, production-ready solutions. We’d have growing consensus from tangible evidence, not just talk.

The fact that we don’t have that consensus, after years of intense effort by the best-resourced labs and companies on the planet, suggests that well, we are still early, and that the problems are genuinely hard. And distinctly varied. The variety of solutions reflects how varied and stubborn the problems themselves are.

To be clear, I’m not saying any of the above suggests progress has stalled necessarily. All of the above should be expected. General purpose technologies have this characteristic where the application layer is where most of the value and complexity lives. Electricity was transformative (over decades and decades), but the hard part wasn’t generating power. It was rewiring factories, redesigning workflows, training workers, building appliances. The same goes for the internet. The “last mile” turned out to be most of the miles.

That same dynamic seems to be playing out with AI. The models themselves are increasingly commodified (the capability gap between frontier models has narrowed, and open source models continue to close in). But the integration challenges? Dealing with messy data, legacy systems, compliance requirements, edge cases, modularity, observability, human workflows, and stochastic failure modes? If we’re lucky, a better model might truly solve a couple of those. But most are systems problems, and they’re inherently tied to the implementation context.

Even if we fast forward 5 years to GPT-N, it still will not automatically know your team’s specific processes and workflows. It won’t know the quirks of the custom in-house API middleware you built to talk to some industry-specific integration-hostile external system. It won’t know your compliance team’s audit and documentation requirements. Capability is not the same as applicability.

The Good News

So the problems are hard. But I promise that’s a good thing.

There are plenty of technologists and teams who know that the edge is in the context, in the unique constraints. They understand that solving problems now is not wasted work, and they are not waiting.4

When you solve hard integration problems today, you’re not just solving for today’s models. You get an opportunity to build abstraction layers. Evaluation harnesses. Data flywheels. Orchestration architectures and design patterns that enable you to reliably leverage presently available models, rough edges and all.

It’s not always that simple. There are aspects that are difficult to abstract away. But that doesn’t change the fact that the more you solve today, the greater chance you have at designing a flexible and adaptable system. Not to mention a chance at cultivating valuable institutional technical knowledge that is hard to come by right now. You build the organizational muscle for iterating and adapting as the technology evolves.

Waiting for better models to solve your problems is not a strategy. It’s a decision to accumulate dependency instead of internal capability. It’s betting your future on someone else’s roadmap.

I think people would be surprised by what they can do with current AI models when they neither underestimate nor overestimate them. When they fully accept the limitations along with the capabilities. When they’re willing to stick with experimenting past the initial novelty, past the point where they have to accept that it is “just” a tool. A powerful tool, but still a tool. One that requires the same patient, unglamorous work of integration that every other worthwhile novel technology has required.

The best ideas won’t come from passive observers that only act in response to others. Lead with curiosity instead of expectations and you develop both experience and flexibility.

Reintroducing Gravity

None of this is an argument against commodified or use case specific off-the-shelf solutions. It’s an argument against assuming those things will arrive before the work that makes them possible.

Every team or business that wants to try out AI does not need to be (nor should be) building a whole new system from scratch. Everything I’ve said here is directed at those who are already building AI systems, are thinking about it, or want to. My hope is that what I’m saying evokes curiosity and a desire to experiment, not anxiety about the lack of answers or solutions.

While there are many things about AI that are worrisome, concerning, or outright harmful…it is still just a technology, a tool. And like any other tool, it’s entirely up to people, us, how it will be developed, deployed, adopted, and integrated into our work and lives.

Right now I’m engaging with it as a geek that has always loved janky and experimental tech and as someone that loves demystifying technology for anyone that has questions or anxieties about it. In other pieces I’ll be engaging with it from other perspectives.

Whether you’re a lay person curious or skeptical about AI, a technologist using or implementing it, or a decision-maker considering AI initiatives, here are some ways to bring conversations back to earth if you catch a whiff of the “effortless AI” narrative.

• Ask: “What’s the hardest unsolved problem in this implementation / product / solution, and what’s the plan to address it?”

  • Not “what are the risks” (most will have canned answers for that). But asking specifically about unsolved problems pushes people to admit where the real effort lives. If the answer is vague or hand-wavy, that’s a sign.

• Notice: When someone tells you a problem will be solved by the next model release, ask (them or yourself) what’s being done about it now.

  • If the answer is “nothing” or “waiting,” that’s the myth at play. If the answer is “we’re building something that might work, or might become obsolete, but we’re learning either way,” that’s someone who tries to create opportunities with the technology they have, within their contexts.

• Experiment: The teams and companies getting value from AI right now are the ones that have accepted there isn’t an effortless path.

  • It is always worthwhile to be thoughtful about how you spend your time and energy. But be wary of convenient narratives that dim your curiosity, discourage interrogation, or sideline your intuition – that would prefer you distant from your own problems and dependent on the solutions of others.

The best way to become intimately acquainted with the problems you’re trying to solve is to, well, try to solve them.

Luckily there are some great voices out there that have already been adding more nuanced, critical, and grounded analyses and perspectives that give everyday people and domain experts more practical tools to reason about the AI industry and the technology we're creating and propagating.

My hope is that Inside Voice can be a small contribution to those efforts as well. A place for regular people, tech workers, small businesses, startups, even big enterprises — anyone who's tired of unsolicited "answers to all their problems" and is instead looking for more and better questions being asked about the changing role of technology in our work and lives.

Why am I doing this?

I've been in tech for a decade and I'm now an AI consultant. I've worked extensively with clients on Voice AI projects in particular (think real-time transcription, voice agents, voice-powered interfaces). And whether it's at the beginning of a project or in the middle, many times the question "so why are we doing X this way?" will arise. I love those questions and want to make sure they keep getting asked. But too often, I see them getting drowned out by hype, fear, or the pressure to just ship something. I don't think that's good for business, and I definitely don't think it's conducive to building robust communities around the development of novel tech.

I want to surface and wrestle with more of those “why” questions. My goal is to provide technical literacy that feels like talking with your "tech-y friend" — someone who always has time for your questions, doesn't talk down to you, never shrouds simple ideas in unnecessary mystique, and tries to learn more than they teach. An informed public encourages more and better discourse.

More people need to feel they have a say in where this technology goes. "Development" isn't just what engineers do, it's also the public sentiments we encourage, the habits and norms we cultivate, the everyday choices we make about what to use or refuse, and the conversations we do or don't have. The clearer we understand the tools, the more agency we have in shaping their impact.

So how will this blog be different? You'll find fewer hot takes here and more sincere questions:

Why does so much "innovation" default to excess, to scaling at all costs?

What would it look like if users and businesses had more nimble and contextually appropriate tools and were able to prioritize data sovereignty?

How do we decide when new tech actually solves a problem versus just sounding impressive?

What should every person know before regularly interacting with generative AI tools in their daily lives?

So…what exactly am I going to talk about?

I have a lot of thoughts bouncing around in my head, but my posts will typically be contained to the following topics/sections:

• Industry Analysis
  [How to spot AI hype and ask better questions]
  I'll poke at the hype cycles, the narratives, claims from the big players and AI labs and then ask how does this work, who does this affect, and why does this matter for the rest of us. The goal will always be to help develop your own critical lens for this technology so you can draw your own conclusions about industry claims past, present, and future.

• Workbench
  [Technical explorations and deep dives]
  At my core, I love getting into the fine details of things, the nitty gritty. I love taking things apart, diagnosing bugs, fixing broken machines, and building custom solutions. So I might do a deep dive into things like the anatomy of a low-latency AI voice agent, or the reason voice bots keep interrupting you, or the importance of reciprocity and conversational repair for enjoyable conversations and how to translate that into code, or the nuances of customizing your own task-specific language models. Sometimes I'll have code. Sometimes I'll draw some diagrams. Sometimes it'll just be me banging my head against a problem and sharing the joys of that.

• AI Literacy
  [Plainspoken explainers to demystify AI technologies]
  No matter what, I think generative AI will be here to stay in one way or another. So it is crucial that we continue to develop our own literacy around this technology. I'll provide accessible explainers and mental models that aim to demystify how these systems work so you can intentionally use them (or refuse them). I want people to fully understand what all these AI products and services mean when they say "use with caution".

• Sandbox
  [Cross-disciplinary connections and fun “what ifs”]
  The grab bag, the playground. The place where I'll post the occasional "shower thought”, wild connection, research deep dive, or speculative tangent that doesn't fit anywhere else.

What you shouldn't expect:

• Thinly-veiled promotion for [insert latest cutting-edge AI product].

• "five prompt tricks to 10x your workflow" listicles.

• Dire warnings about AI apocalypse with a vibe that can only be described as "menacing glee".

• Anything I wouldn't bother reading myself.

I want this blog to be a place where curiosity, play, healthy skepticism, and critical analysis are encouraged and appreciated as fertilizer to the soil that grows innovation and fuel for our collective engines of creativity.

If you want hype, if you want doom, those places are easy enough to find. If you want something else that hopefully feels a bit more familiar, maybe more like the type of conversations you’d have with your friends or family or colleagues, then stick around and see if you like it here.

I don't have a content schedule. I'm not promising weekly posts. I'll write when I have something worth sharing.

If all of that works for you, welcome. If not, no hard feelings.