David Monnerat

Product + AI | Systems Thinker | Enterprise Reality

Category: technology

  • Triage Isn’t a Process Failure

    Triage Isn’t a Process Failure

    Every quarter we grade unplanned work like it’s a mistake. What if it’s just the job?

    The retro slide had two numbers on it. Unplanned work: thirty percent last quarter, forty percent this one. Next to it, a line for next quarter, how much capacity to hold open for the same thing happening again. Nobody could say what that number should be with any confidence, if we knew in advance how much unplanned work was coming, it wouldn’t be unplanned, but holding zero capacity for it, after two straight quarters trending up, wasn’t really an option either.

    The trend line matters more than either number alone. It’s not that the team got worse at planning. It’s that whatever’s generating the unplanned work, shifting priorities, a business figuring itself out in real time, isn’t slowing down. An ER’s caseload isn’t a reflection of the ER. It’s a reflection of what’s happening in the city. Ours was telling us something about the business, not about us.

    Then someone on the product side pointed at something else on the list entirely, something planned, already prioritized, already committed to.

    Where are the requirements for this?

    That was a fair question, aimed at the wrong kind of item for it to sting the way it usually does. The work itself wasn’t a walk-in. It had been on the roadmap for weeks. Nobody had done the diagnostic work of figuring out what it actually was before it landed there, someone with authority had said it mattered, and that had substituted for a spec. The requirements gap was real. It just wasn’t the same gap as the number climbing one line above it.

    I’ve watched this exact scene play out more than once, in multiple organizations, two different problems getting read as one complaint.

    The List Already Works

    Every quarter we build the same artifact: must have, should have, nice to have. We present it like a plan. Stakeholders nod, occasionally push on something they care about, and by and large the list ends up matching what actually needed to happen. That part isn’t broken. We’re good at knowing what matters.

    What we don’t have is the thing the list implies we have: a clean chain from requirements to prioritization to execution. Nobody says “this isn’t on the list because we don’t have requirements yet.” Nobody says “this item is already at risk because the requirements aren’t there.” We skip straight to the list, because we already know, more or less, what needs to get done.

    Two Different Problems Wearing the Same Complaint

    “We don’t have requirements” gets used to describe two different things, and they’re not the same failure.

    One is the true walk-in: work that shows up mid-quarter, unscheduled, because something broke or something new became urgent. Nobody could have scoped it in advance. That’s the situation an ER doctor treats without taking a full history first, not negligence, just the job.

    The other is work that’s already on the list, already prioritized, already committed to, and still has no real definition of what it actually is. Someone with authority said this matters, so it went on the roadmap, and the team started building before anyone had done the diagnostic work of figuring out what “this” means. That’s closer to a case getting booked into tomorrow’s OR schedule off a referral: the surgeon commits to the slot because the person making the call is trusted, not because the workup happened. The team ends up defining the work in real time, mid-procedure, because the priority call substituted for the specification.

    Both get called “no requirements.” Only one of them is actually about triage.

    Unplanned Work Needs Triage, Not Negligence

    For the true walk-ins, the skill isn’t complete information, it’s making the right call fast, with what you have, and adjusting as more comes in. That’s a real discipline. It has its own competence, its own way of being good or bad at the job, and it looks nothing like a GP’s.

    What that competence actually looks like, concretely: someone with the authority to make a fast call without waiting for a full workup. A shared, fast way to size up what’s in front of you, more like a severity check than a requirements doc. Capacity that’s planned for the unplanned, a real percentage of the quarter held open, not treated as slack that shouldn’t exist. Retros that ask whether the call was good, given what was known at the time, instead of asking why the paperwork wasn’t done.

    The scheduled-but-unspecified work needs a different fix, and it has to happen earlier. By the time the case is booked into the OR schedule, it’s too late to ask what the surgery actually involves, the slot is already committed. The fix isn’t a better question mid-procedure, it’s a checkpoint before the slot gets booked: whoever has the authority to say “this is a priority” also owns getting a rough diagnostic done before it lands on the list, not a full requirements doc, just enough to know what kind of case this is. If that checkpoint doesn’t exist, the priority call itself becomes the only gate the work has to pass, and everything downstream inherits however vague that call was. That sits with whoever controls the list, not with whoever ends up doing the work. In a lot of orgs that’s not a formal role, it’s whichever PM said yes fastest, or whoever has five other titles and this happens to be one of them. The fix doesn’t require a new position. It requires that whoever already holds that yes also holds the job of asking one more question before it counts as a priority.

    The Dance

    Naming which one you are doesn’t mean sitting still inside it. Two different problems, two different responses.

    The true unplanned work isn’t a visibility failure to be coached out of the business. The business doesn’t know either. That’s the actual condition, not a lack of effort on their part. Something being on the list at all is already the earliest signal they have, the moment they know enough to say “this is coming” is usually the moment it lands on the roadmap, half-formed. There isn’t a version where they see further ahead and hand you a cleaner list. The lever here isn’t upstream, it’s capacity: plan for the volume, not the shape. Hold room open on purpose, sized to the trend, not to some target number that assumes the volatility will politely go down because a slide says it should.

    The planned-but-unspecified work is the one place a real lever exists, because it’s already inside your process, not out in a business that doesn’t know yet. If something’s on the list and nobody can say what it actually is, that’s grounds to question whether it belongs there, or belongs there yet. Being on the list because someone with authority wants it isn’t the same as being ready to build. Pushing back on that isn’t obstruction. It’s the checkpoint from the previous section, just applied with some teeth.

    That’s the actual work, every quarter: not eliminating unplanned work, since that’s asking the business to know something it doesn’t, but sizing capacity to absorb it honestly, and refusing to let priority substitute for a spec on the things that are supposed to be plannable. One problem gets absorbed. The other gets pushed back on. Different tools, because they’re not the same problem.

    Nobody’s Picked

    Here’s what actually demoralizes a team: not being an ER. Being asked to run like one and graded like a GP, quarter after quarter, without anyone in leadership saying out loud which one we’re supposed to be, or admitting that some of our work is genuinely one and some is genuinely the other.

    A GP shop is a legitimate way to run this work. Slower cycles, real requirements gathering up front, patience from stakeholders while that happens, a willingness to say no to the mid-quarter fire because it doesn’t fit the plan. An ER shop is also legitimate, with its own version of rigor, just a different one. What isn’t legitimate is asking for ER speed with GP process, or booking OR slots off referral and then grading the surgeon on intake paperwork.

    Nobody’s picked. And I don’t think that’s neutral, it’s what keeps the frustration alive. Not deciding doesn’t preserve flexibility, it just means everyone keeps operating on their own private guess about which one we are, and gets penalized whenever that guess doesn’t match what leadership grades against. Ambiguity isn’t neutral ground, it’s a cost, paid every quarter, by whoever’s closest to the work.

    Agreement is what changes it. Not agreement in the sense of everyone liking the answer, agreement in the sense of a decision that’s been said out loud, that people are empowered to act on. Once a team knows which one it is, it stops guessing and starts building the things that make that model good: someone with the authority to call it, a checkpoint before priority turns into commitment, a retro that grades the call instead of the paperwork. None of that is possible while the question’s still being avoided.

    I’ve worked in both kinds of shops. The difference was never which one was better. It was whether anyone had actually decided.

  • The Access Paradox

    The Access Paradox

    Enterprise AI access was supposed to be simple. Give everyone the tools; unlock the value. Here’s what actually happened.

    The pitch is always the same. Give everyone AI. Supercharge productivity. Unlock unlimited value across the organization.

    So companies do. They negotiate enterprise contracts, stand up approved tools, build guardrails for data protection, and roll out access. It takes months, sometimes longer. But eventually, the announcement goes out. AI for everyone.

    Then people actually use it.

    Not the way anyone modeled. Not for the specific use cases in the business case. For everything. Writing emails. Summarizing meetings. Answering questions they used to Google. Exploring problems they would have left alone. Token consumption doesn’t grow linearly when people find a tool genuinely useful. It grows exponentially.

    The cost model wasn’t built for this. The contracts were negotiated based on assumptions about usage that were made before anyone knew what real adoption looked like. So the organization that just announced AI for everyone starts asking a different question: who can we actually afford to give it to?

    Governance First, Then Cost

    Access decisions in large enterprises follow a predictable sequence.

    The first filter is governance. Which tools have been vetted? Which data can flow through them? Which use cases have cleared compliance, legal, and security review? This is the right conversation to have, and it takes longer than most organizations plan for. The result is a tiered system: some tools for everyone, more capable tools for specific groups, the most powerful tools in pilot programs with restricted access.

    The second filter is cost. Once governance is satisfied, the assumption is that access can scale. But scaling access scales consumption. A contract negotiated with one usage pattern in mind produces a different cost picture when people actually depend on the tool. The pilot that was generating real value gets shut down not because it failed but because it succeeded too well.

    Now the access decision isn’t “where does this generate the most value?” It’s “who can we give it to with the least risk and the lowest cost?”

    Those are different questions. They produce different answers.

    The Distribution Problem

    The people who end up with access to the most capable tools aren’t necessarily the people who could generate the most value with them. They’re the people whose use cases cleared governance most easily and whose consumption patterns fit within whatever cost model survived the budget conversation.

    The analyst who works with data all day and could use AI to surface insights that previously required weeks of manual work is in a pilot that got shut down because token consumption exceeded projections. The product manager who uses AI to write Jira tickets has full access because connecting to a project management tool presented lower governance risk.

    This pattern holds beyond any single organization. Deloitte’s 2026 State of AI in the Enterprise report found that 37% of companies are using AI at a surface level with little or no change to existing workflows. The ceiling isn’t the technology. It’s the distribution decision — driven by governance and cost rather than by where the work actually changes.

    And the people who don’t have access find it anyway. Up to 65% of enterprise employees report using AI tools not approved by their IT department. The governance risk the restrictions were designed to prevent is materializing without the organizational visibility to manage it.

    The Free Coffee Problem

    Here’s what makes this hard to fix: the ship has largely sailed.

    People have access to tools they depend on. Taking them away produces exactly the behaviors organizations are trying to avoid. Shadow AI. Workarounds. Tools expensed on personal cards. The resentment that comes from removing something people have built their work around.

    This is the free coffee problem. Once the perk exists, removing it doesn’t return you to neutral. It actively makes things worse.

    But there’s a path through it that doesn’t require subtraction.

    Contract renegotiation is the least glamorous and most important lever. Most enterprise AI contracts were signed before real usage patterns emerged. Usage-based pricing that reflects actual consumption is harder to negotiate but produces better long-term alignment between cost and value. It’s a strategic decision that requires someone to own it at the right level.

    Usage limits are imperfect but better than binary access decisions. Daily or monthly caps force prioritization without eliminating access. They make consumption visible and create the conditions for a conversation most organizations haven’t had: where does this actually matter most?

    Model tiering is the most underused option and the one with the most upside. Most users don’t need the most capable model for most tasks. A well-structured tiering system reserves the powerful models for work that actually requires them and routes routine work to capable but less expensive alternatives. The challenge is that most users don’t have enough context about what different models do to make that decision themselves. They don’t know what a context window is or why it matters. They can’t tell the difference between a task that benefits from Claude Opus and one that Haiku handles just as well. That means the organization has to make the tiering decision, not the user. It’s a governance and design problem, not a technology problem. And it’s solvable.

    The Question Worth Asking Now

    The rollout happened the way it happened. The governance conversations were necessary. The cost surprises were predictable in hindsight. The distribution decisions made sense given the constraints at the time.

    The question worth asking before the next contract renewal, the next access decision, the next pilot that gets shut down because it consumed more than projected: where in this organization does AI actually generate meaningful value?

    Not where is it easiest to deploy. Not where does it fit the existing cost model. Where does it change the work in a way that matters?

    The organizations that answer that question first will have more people using AI where it counts. Not fewer people using it everywhere.

  • Solutions Looking for Problems

    Solutions Looking for Problems

    Agentic AI is changing how fast teams can build. The question worth asking before you start is still the same one it’s always been.

    I’ve been in a few conversations recently with consultants selling agentic AI capabilities. The pitch is compelling. Agents can work autonomously, iterate on tasks, chain actions together, and operate at a scale no human team could match. The demos are impressive. The potential is real.

    What’s missing from most of those conversations is a question.

    Not “what problem are you trying to solve?” Not “what does your current process look like and where does it break?” Not “what would success look like and how would you measure it?” Just: here’s what agents can do, here’s how we’d deploy them, here’s what it would cost.

    The capability is the answer. The problem is implied.

    I’ve been thinking about that pattern since reading Andrew Ng’s recent letter in The Batch about agentic coding loops. His framing is worth engaging with directly because it’s honest and specific in a way that a lot of the current conversation isn’t. He’s describing a practice for building 0-to-1 prototypes in domains you don’t fully understand yet. Use a coding agent to build something quickly, react to what it produces, refine the spec, repeat. The argument is that seeing a working prototype is often the fastest way to discover what you actually want to build. Human judgment is scarce and expensive. Agent output is cheap. Use the cheap thing to sharpen the expensive thing.

    That’s a legitimate practice for a specific context. It’s not a general theory of how to use agents.

    When Exploration Becomes the Default

    The pattern Ng describes works because it has a boundary. You’re exploring an unfamiliar domain. You don’t yet have enough knowledge to write a good spec. The agent output isn’t the product. It’s a tool for developing the spec that will eventually drive the product. The iteration is purposeful. You’re getting smarter with each loop.

    The problem is when that exploratory posture gets extracted from its context and applied to everything. When “put agents on it and iterate” becomes the answer to problems that aren’t unfamiliar domains but rather well-understood organizational failures, poorly defined requirements, or processes nobody has bothered to map. When the iteration isn’t developing the spec. It’s substituting for it.

    This is the thousand monkeys problem. An infinite number of agents iterating on an undefined problem will eventually produce something that looks like a solution. You’ll have burned significant compute to get there, you won’t be certain the output is right, and you’ll still need a human to evaluate it against a definition of success that was never written down. The eval problem hasn’t been automated. It’s been deferred.

    What makes this harder to see than it sounds is that the iteration looks like progress. Things are being generated. Outputs are appearing. The agent is doing something. With human teams, the cost of spinning on an undefined problem was visible. It showed up in headcount, in sprint reviews, in frustrated engineers asking what they were actually building. With agents, that friction disappears. The inefficiency doesn’t. It scales.

    Solutions Looking for Problems

    This isn’t a new pattern. Every capability wave produces it. Someone gets good at building a thing. The thing is genuinely impressive. The capability becomes the product. And the question of whether the capability fits the problem gets answered implicitly because the capability is the answer.

    The organizations that get the most value from new technology are consistently the ones that start with a problem worth solving and find the technology that fits it. The ones that start with the technology and work backward to the problem spend a lot of time discovering that the fit isn’t what they expected.

    Agents are not exempt from this. They’re extraordinarily capable. That’s precisely what makes the skipped question more dangerous, not less. The more capable the tool, the easier it is to mistake activity for progress.

    The Question That Should Come First

    Ng’s framing contains the answer to the problem it doesn’t fully address. He says coming up with the spec, the evals, and the test set is one of the hardest tasks in agentic AI. Then he offers techniques for managing that difficulty once you’re already iterating. What he doesn’t dwell on, because his context is exploration where this is expected, is what happens when you start iterating before the spec exists in a context where it should.

    The question that should come before any agent deployment isn’t “what can agents do?” It’s the same question that should precede any technology investment: what problem are we solving, and how will we know when we’ve solved it?

    If the answer is clear, agents may be exactly the right tool. They can execute at a scale and speed that changes what’s possible. But if the answer is vague, or if the answer is “we’ll figure it out as we go,” then what you’re buying is expensive iteration on an undefined target. The agent will work very hard in a direction nobody has specified.

    That’s not a technology problem. It’s the same problem it’s always been.

    When a consultant walks in selling agents, the right first question isn’t about the technology. It’s about what breaks in your organization today that you believe agents would fix. If they can’t answer that, or if they’re surprised you asked, that’s useful information.

    The problem should come before the answer. It always should have.

  • If You Want to Keep Reading This Post

    If You Want to Keep Reading This Post

    If you want to keep reading this, I’m going to need you to type something on your keyboard every two minutes.

    Can you imagine? You’d close the tab. You’d go somewhere else. You’d tell someone about it.

    That’s the experience I had last night trying to activate a new phone through a major telecommunications company — one I actually worked for, about six years ago, when we were identifying these exact kinds of problems and trying to fix them.

    I typed my issue into the chat assistant. It responded with a workflow of pre-set options, none of which matched my situation. I clicked through five or six of them before typing “agent.” It asked me three more questions. Then it connected me to a human.

    The first thing the human said, after the greeting, was that I needed to type a message every two minutes to keep the session alive.

    Not them. Me. The customer who already has a problem. I have to do work to stay connected to the person trying to help me.

    That’s not an AI problem. It’s not even a problem AI can solve. It’s a product decision that someone made, or a technical limitation that someone accepted, and it’s been sitting there making customers feel like a burden since before I worked there.

    The Mute Button That Wasn’t

    While I waited, I started my audiobook on the same phone I was using for the chat. Every time a message came in from the agent, a notification sound interrupted the audio.

    I noticed a mute icon at the top of the chat. I tapped it. The icon changed to show it was muted. I restarted the audiobook.

    The next message came in. The sound played. The audiobook stopped.

    The mute button didn’t mute anything. It changed its icon. Those are not the same thing.

    This is a product problem. A design problem. Someone built a feature, shipped it, and either never tested it in a real use scenario or tested it and accepted the gap between what it looked like and what it did. A customer using a phone to listen to something while they wait on a chat is not an edge case. That’s Tuesday.

    These are the kinds of things you find when you walk through your own product as a customer. Not in a lab. Not with a test account. As a customer, with a real problem, in a real context, trying to get something done.

    An Hour Later

    After about an hour of troubleshooting, the agent, who was genuinely helpful and clearly trying, told me there was a process that needed to run on the back end. They’d put in a ticket. It would be resolved, but not tonight.

    Which meant I’d be without a phone until it was.

    I asked what I should do if there was an emergency. They offered a workaround: set up a new line, activate the phone on that, switch back later. Creative. But if the activation experience was this complicated, kicking it down the road felt like borrowing trouble. I declined and started wrapping up the chat.

    Then the agent, almost certainly prompted by their system, offered to tell me about current internet plan upgrades.

    I want to be precise about what happened there. My problem wasn’t solved. I was going to be without a phone overnight. The chat had taken an hour. And the system fired an upsell.

    That’s not a bug. Someone designed that. Someone looked at the data on upsell conversion and decided the trigger should fire regardless of whether the customer’s issue was resolved. The metric the team is measured on includes upsell attempts. So the system attempts the upsell. The customer experience is not the metric.

    What AI Has to Do With Any of This

    None of these problems are AI problems. The session timeout, the mute button, the upsell timing — none of them require a language model to fix. They require someone to walk through the product as a customer, identify what’s broken, and have the organizational support to fix it.

    Six years ago, when I worked there, we were calling out problems like these. Some got fixed. Some didn’t. The ones that didn’t weren’t technically hard. They were prioritization decisions. There was always something more exciting to work on, something more fundable, something that showed better in a demo. Now that something is AI.

    I work in AI. I know what the technology can do and I believe in it. But companies are investing heavily in making their customer service smarter while the foundational product and design problems that have existed for years go unfixed. The AI layer gets better. The experience layer stays broken. The customer lives in the experience layer.

    Here’s the question worth asking before the next AI investment: if you asked your customers what frustrated them most about your product, would any of them say it doesn’t have enough AI?

    Probably not.

    They’d say the mute button doesn’t work. They’d say they had to type every two minutes to keep the session alive. They’d say someone tried to sell them an internet upgrade after failing to activate their phone.

    Those are fixable. They were fixable six years ago. They’re still broken.

    Not because the technology doesn’t exist to fix them. Because the attention is somewhere else.

    I’m still thinking about the mute button.

  • Show Me the Incentive

    Show Me the Incentive

    AI investment priorities reveal more about what we value than any mission statement. Here’s what the numbers are actually saying.

    I was sitting in the gym at my son’s school on career day, watching kids rotate through tables staffed by a dog groomer, a police detective, a state park maintenance worker, and me. My topic was AI.

    I’d played them a song my son made using AI tools. I’d watched their faces when the music came out of a prompt. I’d thought about what these tools could mean for kids like the ones in that room — kids with different abilities, different challenges, different relationships with the systems that were supposed to serve them. The technology felt genuinely hopeful in that moment.

    Then I drove home and opened my inbox.

    I work in AI. I’ve spent more than a decade in this space. I believe in what the technology can do — I’ve seen it do things that matter. But I also watch the money, and the money is telling a different story than the hope.

    In 2026, four hyperscalers committed to a combined $700 billion in capital expenditure, nearly double what they spent the year before. That same year, federal funding for health and science research took cuts that one analysis described as a screeching, and possibly irreversible, halt for many projects. The Gates Foundation, Novo Nordisk Foundation, and Wellcome jointly committed $60 million to evaluate AI health tools in low- and middle-income countries. Sixty million dollars. Against $700 billion.

    That ratio is not an accident. It’s an incentive structure.

    Charlie Munger said it plainly: “Show me the incentive, and I’ll show you the outcome.” The incentive right now is return. The outcome is what we’re seeing — infrastructure investment at a historic scale, enterprise deployments producing almost no measurable ROI, and the applications that could matter most to the most people starved of the capital that’s going elsewhere.

    The Market Is Working Fine

    That’s the uncomfortable part. This isn’t a story about a broken system. The market is functioning exactly as designed. Capital flows to the highest expected return. Consumer AI applications have enormous addressable markets. Infrastructure that powers those applications generates reliable revenue. Health AI for rare neurological conditions has a small addressable market and a long development timeline. The math isn’t hard.

    Upton Sinclair put the human version of it this way: “It is difficult to get a man to understand something when his salary depends on his not understanding it.” The people making investment decisions aren’t ignoring the potential of medical AI out of malice. They’re ignoring it because the incentive structure doesn’t reward understanding it. Not yet. Maybe not until it’s too late to matter.

    My son has epilepsy. I think about what AI-driven research could mean for conditions like his — better seizure prediction, smarter medication titration, earlier intervention. I think about it the way any parent thinks about something that could help their kid. And I know better than to frame it as epilepsy versus cancer, because that’s a trap. The question isn’t which disease deserves the investment. The question is why we’ve built a system that forces us to choose between them at all, while $700 billion goes elsewhere.

    The answer is incentive. And right now, the incentive doesn’t point there.

    Progress and Profit Are Not the Same Thing

    Companies should make money. Profit funds research, attracts talent, builds the infrastructure that eventually enables the things that matter. The hyperscaler investments aren’t going nowhere — they’re building the compute layer that researchers will use for decades. AlphaFold happened because the underlying models and infrastructure existed. I know this. And the productivity gains from AI deployment are real. The capability improvements are real. Some of what’s being built right now will matter enormously.

    But profit and progress are not the same thing, and we keep talking as if they are. We tell the story of AI as the technology that will solve our biggest problems — climate, disease, inequality — while the actual investment pattern optimizes for something else. That gap between the story we tell and the system we’ve built is worth naming.

    The tendency to optimize for what’s measurable and near-term at the expense of what’s important and long-term is not something AI introduced. We’ve been here before. But the scale of this wave, its speed, and the environmental cost of the compute it requires compound the stakes in ways that previous cycles didn’t.

    The bubble will eventually correct. It always does. Ninety-five percent of enterprise AI pilots are producing no measurable return. The capital is burning, and the patience of the people funding it has a limit. When the correction comes, the investment will contract, the priorities will shift, and whatever window existed to point this technology at the hard problems will have narrowed.

    The people most likely to benefit from AI-driven medical research are not the people funding the infrastructure. The people absorbing the cost of the job displacement are not the people who will capture the upside when the next wave arrives. That asymmetry isn’t new. It’s the pattern every technology wave produces.

    What I Do Know

    The bubble will correct before the incentives do.

    That’s the pattern. And when it does, the window on the things that actually mattered will have narrowed — maybe irreversibly for some of them. Climate doesn’t wait for market corrections. Disease outbreaks don’t pause while capital regroups. Federal research budgets, once cut, don’t come back on the same timeline they left.

    The market won’t fix this on its own. It doesn’t have to — that’s not what markets are for. Regulation could change the incentives. Public funding could change them. Coordinated pressure from the organizations deploying AI could change them if those organizations decided that the story they’re telling about AI’s potential was one they wanted to be accountable for.

    None of that is happening at the speed the problem requires.

    Show me the incentive. The outcome is right there.

    What I’m Left With

    I drove home from career day thinking about those kids. About what the technology could mean for them if it pointed in their direction. About my son and what a different investment pattern might make possible for people like him.

    I still believe in the technology. I believe in what it can do when it’s pointed at the right problems. I’ve seen it.

    I just think we should be honest about where it’s pointed right now. And curious enough to ask whether that has to be true.

    Why are we doing it this way? Does it have to be this way? What would it look like to do it differently?

    Those aren’t rhetorical questions. They’re the ones worth sitting with.

  • The Same Rocket, A Different Ship

    The Same Rocket, A Different Ship

    AI investment is accelerating faster than any technology wave before it. The pattern underneath it is older than most of us realize.

    There is something deeply human about looking up.

    We’ve always done it. We looked at the stars and decided we belonged there. We looked at the horizon and built ships to cross it. We looked at problems that seemed impossible and found ways to make them less so. That instinct, the refusal to accept limits as permanent, is responsible for most of what we’ve built.

    It’s also responsible for a pattern that keeps repeating. And we never seem to learn it.

    Every generation gets a technology that feels like the one. The thing that will finally close the gap between what we can do and what we’ve always wanted to do. Computers. Then software. Then the internet. Then big data. Each one arrived with genuine capability and genuine promise. Each one attracted enormous investment. Each one produced real gains, new industries, new efficiencies, new possibilities that didn’t exist before. And each one, eventually, ran into the distance between what the demo promised and what the real world required.

    That gap never closed the way we expected. So we did what we always do.

    We threw more fuel at it.

    (more…)
  • The Leveler: The Use Cases Nobody Planned For

    The Leveler: The Use Cases Nobody Planned For

    I sat at a table in the gym at my son’s school. Around the room there was a dog groomer, a police detective, someone from the state park maintenance crew, and an archaeologist. We were there for career day. My topic was AI.

    When each group of kids came over, I played them a song. I told them my son made it. He had the idea, shaped the lyrics, and used AI tools to bring it to life. It’s on Spotify and Apple Music. The instruments, the vocals, the production were all generated by AI. But the idea, the story, the words were his.

    Some of the middle school kids had already used ChatGPT. A few had used it for homework. One wanted a training plan for a video game he was trying to get better at. One girl said she used it as someone to talk to.

    That last one stopped me. The adults in the room were thinking about AI in terms of what it might take from these kids. That girl was using it for something none of the adults had thought to offer her.

    (more…)
  • Defining Success Criteria: Do You Know Where You Are Going?

    Defining Success Criteria: Do You Know Where You Are Going?

    It was the tenth call.

    I had been on the first one. A customer data project, matching records across systems to connect outcomes to the right source. It seemed straightforward enough that I handed it off and moved on. What followed was eight more calls between my team and the customer, each one ending with a tweak to the logic, each tweak fixing something and revealing something else.

    The problem wasn’t the code. It wasn’t the team. It was that nobody had defined success criteria before the work started. Nobody had asked: what does done actually look like?

    By the time my team pulled me back in, it was already swirling. The customer’s manager had joined too. I suspect that because the issue still wasn’t resolved, he felt the need to get involved. We had a piece of logic built by people who were no longer on the team, results that were almost always right, and a team that had been grinding on this for weeks.

    I asked a simple question: What do you actually want?

    That was it. Every previous conversation had been about what the code wasn’t doing right, assuming the approach was sound and just needed adjustment. Nobody had stopped to ask whether the approach itself was the right one. The answer to that simpler question was: when this happens, here is what we expect to see. And the solution that followed was far simpler than what we had been building toward. A defined set of conditions, clearly mapped to outcomes. The complexity we had been wrestling with wasn’t a feature of the problem. It was a feature of never having properly defined the problem.

    We left that meeting with a clear destination. We should have had that conversation on call one.

    (more…)
  • The Code Nobody Understands: The Hidden Risk of AI-Generated Code

    The Code Nobody Understands: The Hidden Risk of AI-Generated Code

    The error message appeared at 2:17 a.m. Something about a null reference in a service that hadn’t been touched in weeks. The developer on call pulled up the relevant file, read through it, and felt a familiar but newly uncomfortable sensation.

    She had written this code. Her name was in the commit history. But she hadn’t really written it. She’d accepted it. Reviewed it in the way you review something when you’re moving fast, and the output looks right, and the tests pass. The AI had generated the logic. She had approved the shape of it. And now, at 2:17 a.m., she needed to understand not just what it did but why it did it that way: what assumption it was built on, what edge case it was avoiding, what the author had been thinking.

    There was no author. Not in the sense that mattered.

    (more…)
  • Enterprise AI Implementation: You Were Promised Everything. Here’s What It Took.

    Enterprise AI Implementation: You Were Promised Everything. Here’s What It Took.

    It was, by all appearances, a standard enterprise AI implementation.

    The summaries looked clean.

    At the top of the screen was a concise paragraph capturing a customer interaction: what was requested, what was explained, and what follow-up was required. Action items were listed neatly below. It was the kind of output you could screenshot for a slide deck. Efficient. Polished. Convincing.

    The premise was simple. If employees spent less time documenting interactions, they could spend more time serving customers. Efficiency would increase. Costs would decrease. The model worked in the demo. It summarized transcripts fluently and quickly. The business case felt straightforward.

    It moved forward.

    The strain didn’t appear in the demo. It appeared in real use.

    (more…)