Later, in the car on the way home with the Pixies playing, the conversation shifted. Not dramatically. Not confrontationally. Just honestly. My kid told me that in some ways, they’re frustrated that I’m so involved with AI.

This is a creative kid. Self-taught piano player who fell in love with jazz and now plays in the school jazz band. A growing vinyl collection curated with real intention. An avid drawer. Someone who loves music in all its forms and delights in the act of making things, in the irreplaceable feeling of a human being expressing something only they could express.

So when they said it, I didn’t argue. I said: “I get it. And I share a lot of your concerns.”

Because I do.

My feeds are drowning in low-effort, AI-generated content. Videos designed to extract interaction, not express a viewpoint. Images that exist because they can, not because someone had something to say. The cheap thrill of a prompt replacing the slow work of craft. People are using these tools to think less, not more, and the evidence is everywhere.

We talked about the real and imperfect decisions being made right now. Many AI companies are making rash, even scary choices. The energy demands are enormous. We don’t have a government that seems capable of, or willing to, regulate this in ways that ensure these advances improve humanity rather than just accelerate extraction from it.

But some companies are trying to get it right. Just today, Anthropic walked away from up to $200 million in government contracts rather than allow its AI to be used for autonomous weapons and mass surveillance. The Pentagon labeled them a security risk in retaliation. That’s what standing on principle looks like when billions of dollars are on the table.

And even Anthropic’s record is mixed. They recently dropped their flagship safety pledge, their Responsible Scaling Policy, arguing that pausing unilaterally while competitors race ahead could make things less safe, not more. Perhaps it’s a reasonable argument. But the money on the line is enormous, and enormous money creates enormous pressure to take shortcuts and let others pay the consequences. We see it in the race forward, where speed consistently wins over caution. We see it in the industry’s foundation, built on training models with other people’s creative work and on the grueling labor of content reviewers exposed to the worst of the internet so the rest of us get a polished product. They’re still the company I’d bet on to do the right thing, but the point stands: nobody gets this perfectly right. The ones who take safety seriously deserve to be recognized for it, and they deserve to be watched closely too.

My kid sees all of this clearly. They’re right to be frustrated. And yet.

The tech optimist in me can’t help it. The machines are talking. Not in the strangely robotic voices that populated the futures of my childhood, the monotone computers of Star Trek or the chrome-plated automatons of Disney’s Tomorrowland. They’re talking in ways that are more fluid, more surprising, and in some cases more thoughtful than what science fiction ever imagined. The optimistic futures I delighted in as a kid are coming to life, and parts of them are even better than what we dreamed.

Both of these things are true at the same time, and that’s what makes this moment so disorienting.

The easy path is to pick a side. Full hype or full hate. AI is saving the world or AI is destroying it. Your feed will reward you for either position. The algorithm loves certainty. But the honest position, the useful position, is somewhere in the middle, and it’s harder to hold.

Balance. The same theme that runs through everything worth doing.

My kid doesn’t need to be excited about AI. They need to keep playing jazz, keep drawing, keep building a vinyl collection that reflects who they are. They spend hours working through jazz standards, training their ear, learning to feel the space between notes. No shortcut replaces that. No tool can substitute for the calluses on their fingers or the instinct they’re building for when to play and when to hold back. The craft is the point. The hours are the point.

And I need to keep pushing for AI that serves people like my kid, not replaces them. AI that removes the mundane so the creative can breathe. AI that’s governed well, deployed thoughtfully, and held accountable when it isn’t.

But tools have always existed on a spectrum. Drum loops captured by session musicians so a songwriter can hear the full shape of a song before the band shows up. Sound libraries that give a bedroom producer access to a full orchestra. We’ve always traded some amount of doing-it-from-scratch for convenience, for accessibility, for the ability to reach beyond what one person can do alone. That trade-off isn’t new. What’s new is how far along the spectrum we’ve moved.

AI doesn’t change what matters. It changes what’s possible. The best version of it handles the parts that don’t require your soul so you can pour more of yourself into the parts that do. But only if we insist on it. Only if we stay vigilant enough to demand it and curious enough to imagine it.

Wonder is what makes us human. Vigilance is what keeps us human.

A Manifesto for the Age of AI

I’ve been trying to hold all of this at once. The best I’ve got is something closer to a poem than a policy paper. With a hat-tip to the Agile Manifesto, which reminded an industry that principles matter more than processes.

Think more. Not less.

AI is the instrument. You are the musician.

AI is here. Be vigilant.

Machines are thinking. Have wonder.

They can simulate. You can show up.

AI will get better. So should all of us.

How are you holding the tension between wonder and vigilance? I’d love to hear about it—reach out on LinkedIn or Bluesky.

It never works. Not the way we hope.

The Silver Bullet Pattern

Every generation of enterprise technology produces its own version of the same idea: build one comprehensive thing, and the complexity goes away.

Monolithic data warehouses were supposed to be the single source of truth. Load everything in, model it once, and every question gets a governed answer. What actually happened was a years-long implementation that couldn’t keep pace with business change. By the time the warehouse modeled last quarter’s org structure, the org had restructured. The business needed answers faster than the warehouse could evolve, so shadow spreadsheets and rogue Access databases filled the gap.

Report factories were going to eliminate ad-hoc requests. Standardize every metric, build every report, and the business never has to ask IT for anything again. The catalog grew to thousands of reports. Nobody could find the one they needed. People kept asking for new ones anyway.

Monolithic enterprise software suites promised to unify everything under one roof. One vendor, one platform, every department aligned. The implementation took three years, cost four times the estimate, and required so many customizations that upgrades became impossible.

Each time, the pitch was the same: centralize, standardize, and the problem dissolves. Each time, the organization outran the abstraction. That’s why distributed approaches like data mesh emerged. The industry learned, painfully, that the answer wasn’t one big thing. It was many coordinated smaller things.

Now it’s happening again.

The Evidence Is Already Here

A recent study from ETH Zurich (Gloaguen et al., 2026) tested whether repository-level context files, the AGENTS.md and Claude.md files that developers write to help coding agents understand their codebase, actually improve performance. These files describe architecture, conventions, testing requirements, the works. The idea is that if the agent understands the big picture, it’ll make better decisions on specific tasks.

The results were counterintuitive. LLM-generated context files reduced task completion by about 3% on average, while increasing computational costs by over 20%. The agents spent more time exploring, testing, and reasoning about information that was largely redundant with what they could discover from the code itself. Even carefully hand-written context files only provided a marginal 4% improvement, and only when they focused on minimal, non-obvious requirements.

The key finding: the codebase is its own best documentation. Summarizing it into a separate abstraction layer added noise, went stale, and created overhead that outweighed the benefit. The only context that helped was small, specific, and focused on things the model consistently got wrong on its own.

Now apply that same logic to the semantic layer conversation in data.

The Semantic Layer Pitch

The semantic layer pitch sounds almost identical to the context file pitch. Define all your metrics, business rules, and relationships in one comprehensive layer. Your BI tools pull from it. Your AI agents query it. Everyone gets consistent, governed answers. Build this one thing, and your data becomes “AI-ready.”

Consistent metric definitions are genuinely important. When finance and sales disagree on what “revenue” means, that’s a real problem worth solving. Nobody is arguing against shared definitions for shared metrics.

The problem is the leap from “consistent metric definitions are good” to “let’s build a comprehensive semantic layer that covers the entire organization.” That’s the boil-the-ocean move. And it runs into three compounding problems.

It’s expensive to build and maintain. A comprehensive semantic layer across every department, every metric, every business rule is a massive undertaking. It needs dedicated ownership, constant updates, and cross-functional alignment that most organizations struggle to sustain.

It goes stale. The business evolves faster than the semantic layer gets updated. New products launch. Teams reorganize. KPIs shift. The layer that was supposed to be the source of truth becomes another artifact that’s slightly out of date, which is arguably worse than having no layer at all, because people trust it when they shouldn’t.

It can’t hold multiple valid perspectives. This is the deeper issue. Finance looks at revenue differently than sales looks at revenue differently than the board looks at revenue. These aren’t errors. They’re legitimate, necessary perspectives shaped by different contexts and different decisions. A single ontology can’t hold all of them without becoming so complex it defeats its own purpose.

Just because you documented everybody’s job in the entire company doesn’t mean anybody in the company can do every job. And that mass of documentation would be incredibly hard to manage or search through effectively.

What Actually Works: Org Structure, Not Encyclopedias

What works in organizations isn’t an encyclopedia of everyone’s role. It’s org structure. Specialists with deep domain knowledge, clear boundaries, and a coordination layer that routes work to the right people.

The same principle applies to how we should architect AI systems for data.

Build small, focused agents. An HR reporting agent that deeply understands headcount metrics, compliance rules, and the specific nuances of how your organization tracks people data. A finance agent that knows the chart of accounts, understands accrual vs. cash, and can navigate the ERP. A sales agent that knows your pipeline stages, your territory model, and your commission structure.

Each of these specialists can have its own focused semantic context. A small, maintainable set of definitions scoped to its domain. The HR agent doesn’t need to know about COGS. The finance agent doesn’t need to know about candidate pipeline stages. This isn’t a limitation. It’s what makes each agent good at its job.

Then build a routing layer that delegates questions to the right specialist. “What’s our revenue?” goes to finance. “How’s hiring going?” goes to HR. “How is hiring affecting our margin?” gets routed to both, and their perspectives get composed into an answer.

The semantic layer becomes a local feature of each specialist, not a global infrastructure project. Consistent definitions still exist. They’re just scoped, maintained by the people who use them, and loaded only when relevant. This is the same organizational design principle I explored in Architecting the Factory: distributed authority works better than centralized control when you pair it with clear ownership and coordination mechanisms.

Feature, Not Foundation

The semantic layer isn’t bad. It’s a feature of a mature data platform. A useful tool for enforcing consistent metric definitions in specific, well-scoped contexts.

But it’s being positioned as the foundation, the thing you need to build before AI can work with your data. That framing is the trap. It delays value indefinitely while you try to model an organization that won’t hold still long enough to be modeled. It’s the same “get your house in order first” advice that has stalled more data programs than any technical limitation ever has.

Start with a specific problem. Build one specialist agent that’s genuinely good at one domain. Learn what your users actually ask and what context the agent actually needs. Let the architecture emerge from what you learn, not from what you imagine you’ll eventually need. Starting small and finishing beats starting big and stalling.

The gap between “AI-ready data” and actual AI value isn’t a completeness gap. It’s a sequencing gap. And the organizations closing it fastest are the ones willing to start small and get specific.

Are you building specialist agents or wrestling with a comprehensive semantic layer? I’d love to hear what’s working for you. Reach out on LinkedIn or Bluesky.

What would have been a polite nod and a quick addition to the backlog became an active project.

A few days later, someone mentioned it’d be great to have a public demo site for some Sigma content. I already had an idea of how to do it. We’d built some open source components that would make it easier. Another terminal window. Another agent pulling code together.

Rinse. Repeat. Within a week I had multiple desktops open, each with a little black screen of scrolling text, and I wasn’t sure what to do next. It felt like the opposite of productivity. All these partially-done projects sitting there, waiting for something. Waiting for me.

The Governor Is Gone

Starting projects used to be expensive. There was research, setup, scaffolding, a first painful commit. That friction was annoying, but it served a purpose. It was a natural governor on how many things you could have in flight at once. You couldn’t start too many things because starting things was hard.

AI removed that friction. An agent can get a project from zero to 80% in an afternoon. The problem is that the last 20% still costs the same as it always did. It still needs your attention, your judgment, your time. The 0-80% got cheaper. The 80-100% didn’t.

And here’s the part that snuck up on me: in any company setting, finishing doesn’t just require your focus. It requires other people’s focus. Code reviews. Security approvals. Design feedback. Stakeholder buy-in. I wrote about this in Architecting the Factory and Fast Work, Slow Decisions, and the same dynamics apply here at the individual level. Every project you spin up doesn’t just add to your own work-in-progress. It creates invisible WIP for your colleagues, too. You’ve manufactured demand on someone else’s calendar without asking.

Nothing Moves Faster Than the Bottleneck

This is the oldest lesson in Lean thinking, and it’s the one we keep forgetting. Goldratt’s Theory of Constraints says a system can only move as fast as its slowest point. In The Phoenix Project, the team keeps starting work because everyone wants to stay busy, and the pile of half-done projects eventually brings the whole operation to its knees.

AI just made this trap irresistible.

The temptation is obvious. Your current project is blocked, waiting on someone’s review or a decision from leadership. You could follow up, push the blocker, stay focused. But why sit idle when you could spin up something new? The agent makes it feel productive. One more terminal window. One more prototype.

The work doesn’t stop needing management once it exists, though. You’re juggling more balls now. You start checking in less rigorously on the blocker. The person responsible for that blocker is getting busier, partly because you and everyone else keeps adding things to the queue. The ball drops. The work stacks up. Like a traffic jam, everything begins to creep. Progress feels impossible, and you’re not even sure which project to push forward first.

Lean manufacturing figured this out decades ago. The ideal is single piece flow: finish one thing before starting the next. The concept isn’t complicated. The discipline is brutal, especially when starting the next thing has never been easier.

The Bragging Rights Problem

There’s a cultural dimension to this, too. Right now on tech Twitter and LinkedIn, running multiple agents simultaneously has become a kind of status signal. Screenshots of four terminal windows. “I’ve got six agents running right now.” It looks impressive. It feels productive.

But running six agents isn’t the same as finishing six projects. It’s the same as having six pots on the stove with no plan for which one to plate first. Impressive-looking kitchens don’t feed anyone.

The internet rewards the appearance of velocity. Organizations reward outcomes. Those are different things.

The Case for Slowing Down

Here’s the move that actually helped. I started using AI not to produce more, but to decide better.

Most mornings now, I sit down with Claude before opening any terminals. We review my task list together. We look at my calendar. We talk through what’s actually most important today. Not most exciting, not most novel, not the thing someone mentioned yesterday that would be cool to build. The most important thing.

Some prompts that have been useful:

• Are there any tasks that have been sitting for too long?
• Can you group tasks by topic so I can see what themes are pulling at my attention?
• What are tasks I should consider delegating?
• What should I be planning for this week?
• What would a good agenda be for my meetings today?

None of these are complicated. The value isn’t in the prompts. The value is in the act of pausing to ask them. Of forcing yourself to reflect before you react.

AI gave me the ability to start anything in minutes. That same AI can also give me the space to step back and choose wisely. The tool that creates the problem is also, it turns out, pretty good at helping solve it, if you’re willing to sit down and have the conversation instead of opening another terminal.

Intention as the Discipline

The real skill in an AI-accelerated world isn’t starting. It’s choosing. It’s the discipline to look at the list of things you could spin up today and pick the one that matters most. Then work on it with focus, push through the blockers, get it to done.

We can let AI make us busier and more overwhelmed, or we can use it to free ourselves to slow down. Both options are available. Both are easy. Only one of them leads somewhere good.

Have you found yourself drowning in half-finished AI projects? I’d love to hear how you’re managing the WIP problem. Reach out on LinkedIn or Bluesky.

That’s fine as far as it goes, but often skips over the essential part of the story: the change that finally happened after the long 40 year wait.

The reason factories didn’t improve when they adopted electricity is that they didn’t actually change anything. They ripped out the massive central steam engine and bolted an electric motor in its place. They still used the same factory. It was the same multi-story layout organized around drive shafts and belts. Same workflow dictated by the physics of centralized power. New energy source, old design.

It shouldn’t have been surprising when productivity barely moved.

The breakthrough came when engineers stopped asking “how do we electrify this factory?” and started asking “what kind of factory does electricity make possible?” Those are fundamentally different questions. The first preserves the existing design. The second reimagines it.

And the answers were practical. Electricity didn’t need a central source. Each machine could have its own small motor, started and stopped independently. Machines didn’t need to cluster around a drive shaft. The factory could be arranged around the logic of production, the flow of materials from one step to the next, rather than the logic of power distribution. Single-floor layouts replaced multi-story buildings. Assembly lines became possible. Workers gained autonomy because they controlled their own machines instead of being governed by the pace of a central engine.

The economist Paul David documented this in his landmark 1990 paper, “The Dynamo and the Computer.” His central insight wasn’t about patience or timelines. It was that the productivity gains didn’t come from the new technology at all. They came from redesigning the entire system, the factory, the management, the training, the incentives, around what the new technology made possible.

The technology was the easy part. The factory was the hard part.

We’re Bolting on the Motor

I’ve been thinking about this story a lot as I watch organizations adopt AI agents. I wrote recently about the agentic maturity curve, the progression from using AI as spicy autocomplete to running what Dan Shapiro calls “the dark factory,” where agents handle entire workflows autonomously. And I wrote about the coordination crisis that emerges when production time compresses but decision-making doesn’t keep up.

Those two posts are really two halves of the same argument: the technology is moving faster than the organizations using it. And most organizations are responding exactly the way those early factory owners did. They’re ripping out the steam engine and bolting in an electric motor.

They’re plugging AI into existing workflows. Having agents do what humans used to do, in the same structure, with the same reporting lines, the same approval chains, the same coordination mechanisms. It’s the obvious move, but all we’ve done is make some parts of the system faster without changing anything else. The factory can’t move faster than its slowest choke point. This produces disappointing results and leads to the conclusion that AI is overhyped.

The AI isn’t overhyped. The implementation is underdesigned.

We’re no exception. Here’s what it looked like for us. We had an internal org chart that kept breaking. Periodic data syncs, brittle workflows, the kind of thing that took weeks to build and failed sporadically. When it broke again, we rebuilt it in a day using live internal APIs. No data syncs. Direct connection to the source of truth.

That same week, someone raised a different problem: finding employee headshots for client proposals, currently scattered across disorganized shared folders. Because we’d built around live APIs instead of static exports, adding employee profiles with searchable headshots was a few hours of work. The redesigned foundation made an unrelated problem solvable almost for free.

Then we hit a wall. Deploying the tool securely required several slow internal processes to deploy and create a new Azure application to integrate into our authentication. The process took longer than building the tool itself. In the past, deploying anything meant a procurement request for a cloud instance or a back-and-forth with DevOps for Kubernetes. We’ve since adopted a deployment platform where security is baked into the infrastructure, not bolted on by each developer. The default is now secure, with teams requesting wider permissions when needed instead of the other way around.

One day to rebuild the tool. One day to extend it. Weeks waiting on the old governance infrastructure to catch up. That’s the gap.

The Factory Is the Organization

Transformative technology demands transformative design. Not just of the technical systems, but of the organizational systems those technical systems live inside.

When electricity enabled individual motors on each machine, it didn’t just change the factory floor. It changed management. The shift from centralized power to distributed power required a corresponding shift from centralized control to distributed authority.

The same is true for AI. When agents can produce work in hours instead of weeks, you haven’t just changed the production layer. You’ve changed the coordination, decision-making, and trust layers. Our org chart story is a small example: building the tool was the easy part. Every layer around it, security, deployment, governance, was still designed for the old speed. If you don’t redesign those layers, you get expensive new technology producing the same old results.

Designing the Factory, Not Just Installing the Machines

Architecting the factory requires being deliberate about both your technical architecture and your people architecture, and understanding that they have to move together.

On the technical side, this means designing your agent systems with the same care you’d give any critical infrastructure. Not every process needs an agent. Not every agent needs autonomy. The dark factory model works at FANUC because they manufacture standardized robots in a tightly controlled environment: the work is predictable, the inputs are consistent, and the quality criteria are well-defined. Most knowledge work doesn’t look like that. Good technical design means knowing where on the maturity curve each process belongs and building accordingly. Level 2 collaboration for ambiguous creative work. Level 4 specification-to-shipping for well-understood repeatable processes. Level 5 only where you’ve earned the right to turn off the lights.

Even FANUC’s fully autonomous lines have built-in conditions that halt production when something deviates from spec. The most important design decision in any autonomous system isn’t what it can do. It’s the conditions under which it stops and escalates. Agent design needs that same discipline. An agent that confidently produces wrong output is worse than one that stops and asks.

We rebuilt our client proposal process along these lines. For years, people assembled proposals from a massive master PowerPoint. Most had their own personal fork because working with the master was so painful. Same content, dozens of versions. We broke the deck into modular components, each described well enough for an AI agent to assemble. Now the agent pulls the right pieces, customizes them for the engagement, and outputs whatever format the client needs. As a bonus, those components became a searchable knowledge base for how we handle different types of work. The old process was organized around the constraints of PowerPoint. The new one is organized around the flow of the work.

On the people side, this is where most organizations underinvest. As I argued in Fast Work, Slow Decisions, the real bottleneck in an AI-augmented organization isn’t production capacity. It’s decision-making and alignment capacity. Addressing that requires building a stack: trust first, then clear ownership, then feedback mechanisms that separate authority from input, then measurement for alignment rather than control.

These aren’t separate workstreams. Autonomous agents require distributed authority. Distributed decisions require distributed context. Trust requires visibility. The technical architecture enables the people architecture and vice versa.

The Restraint Problem

Here’s the part that goes against every instinct in a hype cycle: good design requires restraint.

The temptation with any powerful new technology is to deploy it everywhere at once. Every team gets agents. Every workflow gets automated. Every process gets optimized. This is the organizational equivalent of electrifying every machine in the factory on the same day. Technically possible, practically chaotic.

The factories that successfully transitioned to electricity didn’t do it all at once. They started where the advantage was clearest, learned what worked, adapted their management, then expanded. The transformation took time not because the technology was slow, but because organizational learning is slow.

Organizations adopting AI agents need the same discipline. Start where the gap between current performance and potential is largest and the risk of failure is most manageable. Assign clear ownership, not just of the agents, but of the outcomes the agents are meant to produce.

Then treat each redesigned process as a learning opportunity, not just a delivery. What broke during the transition? Where did people resist, and were they right to? Where did approval chains or handoff points slow things down? That learning feeds the next redesign. The org chart taught us that our deployment and security infrastructure was the real bottleneck, which led directly to rebuilding our deployment platform. The proposal redesign taught us that modular components create value beyond the original use case. Each process you redesign should produce not just better output but better understanding of how your organization adapts to change.

This is harder than it sounds because restraint doesn’t make for exciting board presentations. “We automated three processes really well” is a less compelling story than “we’re deploying AI across the enterprise.” But the first approach builds the organizational muscle for sustained transformation. The second builds expensive shelf-ware.

The Path to the Dark Factory

The path to whatever level of agentic maturity your organization needs, whether that’s Level 3 code review management or Level 5 lights-out autonomy, isn’t a technology purchase. It’s a commitment to redesigning how you work.

That means changes in your people architecture: who makes what decisions, how authority is distributed, how trust is built, how feedback flows, how you measure success. And it means changes in your technical architecture: how agents are designed, what they can and can’t do autonomously, how they integrate with human workflows, how you monitor quality and catch failures.

Neither architecture works without the other. An organization with perfectly designed AI agents but a command-and-control management structure will bottleneck at every approval gate. An organization with beautifully distributed authority but no agent infrastructure will just be making faster decisions about slower work.

The companies that get this right will look like those redesigned electric factories of the 1920s, organized around the flow of value rather than the constraints of their power source, with workers empowered to operate autonomously because the systems support it and the culture trusts it. U.S. manufacturing productivity leapt in that decade, four decades after the commercialization of electricity. The gains came not from better motors, but from better factories.

We’re still in the “bolting on the motor” phase of AI adoption. The real gains are ahead of us. But they won’t come from better models or more capable agents. They’ll come from better organizations, ones that had the discipline to architect the factory, not just install the machines.

This post builds on ideas from The Agentic Maturity Curve and Fast Work, Slow Decisions. Paul David’s paper, “The Dynamo and the Computer,” was published in the American Economic Review in 1990 and remains one of the most cited works on technology adoption. If you’re thinking about how to redesign your organization for AI, not just deploy it, I’d love to hear what you’re learning. Reach out on LinkedIn or Bluesky.

Not intentionally. Nobody designed it this way. But when work takes weeks or months to complete, something useful happens in the background. Questions surface gradually. Managers course-correct in small increments. Adjacent teams notice conflicts before they become catastrophes. Priorities have time to clarify themselves.

The weeks it takes someone to finish a project aren’t just production time. They’re also coordination time. Slow execution creates a natural buffer for alignment.

AI is compressing production time. But it’s not compressing coordination time. And that mismatch is creating problems that look like AI problems but are actually organizational design problems.

The Flood vs. The Trickle

In the old world, a manager could handle ambiguous direction because feedback came in slowly. You’d assign a project, get a few questions over the first week, clarify some things, get a draft, provide input, iterate. The pace of work created a manageable trickle of decisions.

Now imagine that same project completed in two days instead of two weeks. The questions don’t come as a trickle—they come as a flood. Or worse, they don’t come at all because the work is already done by the time anyone thinks to ask.

The symptoms show up everywhere:

• Work sitting idle waiting for feedback that can’t come fast enough
• Competing efforts across teams because there wasn’t time to notice the overlap
• Managers becoming bottlenecks, not because they’re slow, but because they’re suddenly the constraint
• People doing the wrong work faster, which is worse than doing the wrong work slowly

Eliyahu Goldratt would call this a constraint shift. The bottleneck used to be execution capacity. Now it’s decision-making and alignment capacity. If you don’t address it, you’re just creating expensive inventory—completed work sitting idle, conflicting work products piling up.

The cost of misalignment used to be measured in days of wasted effort. Now it’s measured in hours. The margin for error got a lot smaller.

The Tempting Fix (And Why It Fails)

The instinctive response is to double down on project management. Create detailed plans. Break everything into tasks. Specify exactly what needs to happen before anyone starts working.

I get the appeal. If the problem is coordination, and coordination used to happen during slow execution, then let’s just front-load all that coordination into planning. Pre-solve the alignment problem.

But this runs into a fundamental issue: plans are guesses. Detailed plans are detailed guesses. The moment work begins, you learn things you couldn’t have known during planning. Requirements shift. Technical constraints emerge. The market changes. Someone has a better idea.

“No plan survives contact with the enemy.” The more detailed your plan, the more brittle it becomes. You’ve traded one problem (coordination during execution) for another (rigidity during execution).

This approach—trying to eliminate the coordination constraint by pre-solving it—works for predictable, well-understood work. It fails badly for anything complex or creative.

The Better Fix: Distributed Coordination

Instead of front-loading coordination, you can distribute it. Give more people the authority and context to coordinate locally, in real-time, as the work happens.

But this only works if you build the right foundation. Think of it as a stack—each layer enabling the one above it.

Trust comes first. Nothing else works without it. If people don’t feel safe raising concerns, if they’re protecting turf instead of solving problems, no amount of process will save you. Psychological safety is the single strongest predictor of team performance.

In a fast-work world, trust becomes even more critical. There’s no time for political maneuvering when decisions need to happen in hours instead of weeks. You either trust your people or you become the bottleneck.

Then ownership. Once you have trust, you can distribute authority. This means clear lanes—people know what they own, what decisions they can make without escalating, and where their domain ends and someone else’s begins. Clear ownership isn’t about isolation. It’s about knowing who’s accountable so that coordination can happen at the right level. When ownership is ambiguous, every decision escalates. When ownership is clear, most decisions don’t need to.

This is also where you define “what we owe one another”—the interfaces between teams. What can you expect from me? What do I need from you? How do we handle conflicts?

Then feedback without authority. Pixar’s Braintrust model nails this. Directors own their movies, but they’re required to get candid feedback from a group of peers who watch rough cuts and offer perspective. The crucial thing: the Braintrust has no authority. They can’t overrule the director. They can’t demand changes. They offer perspective, and the director decides what to do with it.

This solves the ownership-vs-input dilemma. You don’t have to choose between clear authority and collective wisdom. You can have both—if you design the feedback mechanism correctly.

Finally, measurement for alignment. You need a way to ensure all this autonomous work is pointed in the same direction. The key distinction: measurement for alignment vs. measurement for control. Measurement for control is about catching people doing things wrong. Measurement for alignment is about helping people self-correct before things go wrong.

Good OKRs let individuals and teams assess their own progress against shared outcomes. They reduce the need for check-ins and status updates because everyone can see whether they’re on track. Without the layers below it, measurement becomes either useless (people gaming the metrics) or oppressive (micromanagement with numbers). With the right foundation, it’s liberating.

Smaller Batches, Faster Loops

Gene Kim’s research on DevOps points to something similar: small batches with fast feedback loops outperform large batches with delayed feedback. The answer to faster work isn’t less feedback, it’s faster feedback. But the feedback needs to inform decisions, not make them.

Goldratt would say: subordinate everything to the constraint. If decision-making is now the bottleneck, you need to dramatically increase throughput at the coordination layer. That means reducing “batch sizes” of decisions—instead of big approval cycles, create mechanisms for continuous small alignments.

This is closer to how high-performing teams already work. Less waterfall, more continuous integration—not just for code, but for decisions.

What This Asks of Leaders

If you buy this framing, the implication is uncomfortable: you can’t solve AI coordination problems by slapping AI on them. You solve them with organizational fundamentals that many companies have been neglecting for years.

Trust takes time to build. Clear ownership means making hard calls about who’s accountable for what. Feedback mechanisms require design and practice. Measurement requires discipline.

None of this is easy. But the alternative—becoming a permanent bottleneck while your team’s production capacity outpaces your coordination capacity—is worse.

The companies that thrive in the AI era won’t be the ones that adopt AI fastest. They’ll be the ones that adapt their coordination models to match. The technology is the easy part. The organization is the hard part.

I’d love to hear how you’re navigating this—what’s working, what’s breaking. Reach out if you want to swap notes on LinkedIn or Bluesky.

If you’ve spent any time in analytics or data strategy, you’ve seen maturity models before. Gartner loves them. Every consulting firm has their version. They usually describe a journey from chaotic, ad-hoc practices toward something systematic and optimized. Shapiro’s model does the same thing for AI collaboration, but with a twist: the endpoint isn’t just “optimized.” It’s autonomous.

Here’s the progression:

Level 0: Spicy Autocomplete. The original GitHub Copilot. Copying and pasting snippets from ChatGPT. The AI suggests, you accept or reject. You’re still doing the work—the AI is just a faster search engine with better guesses.

Level 1: Task Automation. AI handles discrete tasks: “Write a unit test” or “Add a docstring.” Speedups exist, but your role and workflow remain largely unchanged.

Level 2: Pairing. You get into a flow state. You’re more productive than you’ve ever been. Shapiro notes this is where most AI-native developers live today—and where many mistakenly believe they’ve hit the ceiling.

Level 3: Code Review Manager. Your life is diffs. AI agents generate solutions; you review constantly. You’re still hands-on, but the balance has flipped. The developer becomes a human-in-the-loop manager.

Level 4: Specification to Shipping. You’re not a developer anymore. You’re a PM writing specs and designing agent workflows. You step away while systems build complete features, checking test results when you return. Shapiro places himself here.

Level 5: The Dark Factory. Named after Fanuc’s robot-staffed manufacturing facility where the lights stay off because robots don’t need to see. At this level, the system takes specs and produces software. Humans design the process and handle exceptions, but they’re not in the loop for normal operations. Think this is sci-fi? There are companies already trying it.

Beyond Code

What strikes me about this model is how little it depends on the output being software.

A marketing team at Level 2 is pair-prompting on campaign copy. At Level 3, they’re reviewing AI-drafted campaigns and approving the good ones. At Level 4, they’re defining brand guidelines and letting agents produce variations. Level 5 is programmatic creative at scale—personalized ads generated and deployed without human review.

The model generalizes because the underlying dynamic is the same: as trust in the system increases, humans move from production to oversight to design.

The Post-Data World

For data and analytics, I think this maturity curve points toward something more fundamental: a world where analytics disappears into the workflow.

Data exists to tell us something about the world we can’t directly observe. “Where should I focus my efforts?” gets answered by seeing sales are down in the west. “What should I do about it?” might come from customer satisfaction trends or competitor pricing seen in the data. But the goal was always to sell more, stay profitable—not to find the best sales report.

I wrote about this back in 2024: the job to be done is never the dashboard or chart itself. The dashboard is a means to an end, and often a clunky one.

At higher levels of agentic maturity, you stop going to your data. The data comes to you. An agent helping you plan your quarter already knows sales are down in the west—you don’t need to check a dashboard first. An agent drafting your pricing strategy has already incorporated competitor intelligence. Analytics becomes infrastructure, not a destination. The insights are woven into the tools you use, surfaced when relevant, invisible when not.

This is the promise of Level 4 and 5 for knowledge work: not just automating the production of reports, but eliminating the need to consume them as a separate activity.

Where Are We?

Shapiro suggests Level 2-3 is where serious AI users live today, with many mistakenly believing they’ve reached the ceiling. That matches my experience. The people I know who’ve really integrated AI into their work have largely stopped writing initial code drafts. They’re reviewing, refining, redirecting. They’re managing output, not producing it. In fact, it’s our senior engineering managers who seem to be sprinting ahead the fastest.

Level 5 remains rare. The teams operating there are typically small—under five people—with extensive experience in high-reliability systems. They’ve invested heavily in testing, tooling, and validation. The “dark factory” isn’t about removing humans. It’s about moving humans to where they add the most value.

The Maturity Question

Maturity models are useful because they give you a vocabulary for talking about where you are and where you’re going. They’re dangerous because they imply a linear progression that may not exist. Not every team needs to reach Level 5. For some work, Level 2 is exactly right—the collaboration itself is valuable, and automating it away would lose something.

The question isn’t “how do I get to Level 5?” It’s “what level is appropriate for this work, and am I there?” At the same time, knowing that Level 5 might be the end goal can also help you understand the things you can start standardizing (like processes, knowledge, skills) on your way to producing a mostly autonomous factory.

More practically for today, if you’re reviewing every line of AI output but the stakes are low and the volume is high, maybe you’re overinvesting in review. If you’re pushing toward automation but your testing infrastructure can’t catch regressions, maybe you’re moving too fast. If you’re still going to a dashboard every morning to understand your business, maybe there’s a more integrated way.

The Agency in Agentic

The people moving up this curve aren’t waiting for permission. They’re not sitting in Level 1 hoping someone will tell them it’s safe to try Level 2. They’re experimenting, failing, adjusting, and building confidence through practice.

The dark factory sounds like science fiction. Some days it feels closer than others. But getting there—if that’s even where you want to go—requires the same thing every maturity model requires: deliberate, iterative improvement driven by people who choose to push the boundaries.

Like many areas of life, we get to decide how much to trust. That decision isn’t automated. It’s yours, and it should be intentional.

Where do you sit on the agentic maturity curve? I’d love to hear about it—reach out on LinkedIn or Bluesky.

The reactions will write themselves. Some will read this as vindication: “See? AI makes us dumber.” Others will dismiss it: “We’ll adapt.” Both miss what the study actually found.

The study’s most interesting finding isn’t that AI hurts learning. It’s that how you use AI determines whether you learn at all.

The Research, Briefly

Anthropic recruited 52 software engineers and had them learn a new Python library (Trio, for asynchronous programming). Half could use an AI assistant; half coded by hand. Both groups were quizzed afterward on concepts they’d just used.

The AI group scored worse overall, especially on debugging questions—the ability to identify when code is wrong and why it’s failing. But within the AI group, outcomes varied dramatically based on interaction patterns.

Low-scoring patterns (average under 40%):

• Full delegation to AI
• Starting independently but progressively handing everything off
• Using AI to debug without building understanding

High-scoring patterns (average 65%+):

• Generating code, then asking follow-up questions to understand it
• Requesting code with explanations
• Asking conceptual questions while coding independently

That last group—the “conceptual inquiry” pattern—was the second-fastest overall, right behind full AI delegation. They got both speed and learning.

This Isn’t New

Here’s what struck me: we’ve known this about learning for decades.

Lectures are one of the least effective ways to transfer knowledge. Reading isn’t much better. We learn through struggle, application, and repetition. This is why a six-month coding internship often teaches more than a computer science degree focused purely on academics—not because the degree lacks content, but because building real things with real stakes forces a different kind of engagement.

It’s why medical residencies exist. It’s why apprenticeships work. It’s why you remember the bugs you debugged at 2 AM but forget the tutorial you read last week.

AI doesn’t change this dynamic. It just makes it easier to skip the hard part.

The Wrong Question

Much of the discourse around AI and skills asks: “How does AI impact learning?”

This treats AI as the variable and learning as the constant. But learning was never a constant. We’ve always had choices about how much effort to invest, when to take shortcuts, and whether to optimize for speed or depth. AI just makes those choices starker.

The better questions are:

• What are the most effective ways to learn?
• What should we be learning?
• Given that AI tools are a given, how should we work?

These reframe the conversation from “is AI good or bad for learning” to “how do we design our work and development in an AI-augmented world.”

Judgment Is the Curriculum

In my last post, I wrote about how entry-level tech work is transforming—from grunt work to decision-making under uncertainty. The training ground has shifted from “write the boilerplate” to “evaluate whether the AI’s boilerplate fits the problem.”

The Anthropic research reinforces this. The skill most damaged by passive AI use was debugging: understanding when something is wrong and why. That’s judgment. That’s the thing that becomes more valuable as code generation gets easier.

So here’s the reframe: the curriculum for working in an age of AI isn’t “learn to code” or “learn to prompt.” It’s “learn to evaluate.” Learn to know when something is right. Learn to know when something is wrong. Learn to know when you don’t know.

This requires a different kind of practice. Not “generate and ship” but “generate, understand, then ship.” The participants who scored highest weren’t avoiding AI—they were using it as a comprehension tool, not just a production tool.

Intentional Friction

There’s a growing movement in software development around “learning modes” in AI tools. Claude Code has a Learning and Explanatory mode. ChatGPT has a Study Mode. These are designed to add friction back in—to slow you down just enough to build understanding.

This is directionally right, but it can’t be the whole answer. Modes are opt-in. Under deadline pressure, who opts for the slower path?

The real answer is cultural. It’s about how teams and organizations value the development of their people alongside the delivery of their projects.

When I wrote about entry-level jobs growing up, I emphasized that agency without scaffolding is abandonment, but scaffolding without agency is busywork. The same applies here. Tools that force learning are paternalistic if they prevent you from getting work done. Tools that skip learning are negligent if they let you ship code you don’t understand.

The balance is in how we work together—junior and senior, human and AI. More pair programming, not less. More “let’s talk through your thinking,” not just code reviews after the fact. More explicit investment in understanding as a deliverable, not just working software.

What We Should Be Learning

If AI handles syntax and boilerplate, what should humans be getting better at?

• Systems thinking: Understanding how pieces fit together, not just what each piece does
• Failure analysis: Knowing what can go wrong and why. Not just “the test failed” but “the test failed because async operations don’t guarantee ordering, and I assumed they did.”
• Problem framing: Asking the right question before generating any solution
• Quality judgment: Recognizing good from bad, elegant from hacky, appropriate from over-engineered
• Communication: Explaining your thinking to humans who need to extend or maintain your work

None of these are new skills. They’re the skills that made senior engineers valuable before AI and will make them valuable after. What’s changed is that junior engineers need to develop them earlier, because the old stepping-stones have eroded.

The Real Insight

The Anthropic study concludes with an observation that stuck with me: “Productivity benefits may come at the cost of skills necessary to validate AI-written code if junior engineers’ skill development has been stunted by using AI in the first place.”

This is the trap. You get faster today by skipping understanding. Tomorrow, you can’t catch the AI’s errors because you never developed the judgment to recognize them. The speed compounds—until it doesn’t.

But here’s the flip side, which the study also shows: you can have both. The participants who asked conceptual questions, who used AI to deepen understanding rather than bypass it, were both fast and learned. They got the productivity and built the skills.

It’s not AI versus learning. It’s passive AI use versus active AI use. Delegation versus collaboration.

The Work Now

So given that AI tools are a given, how should we work?

1. Generate, then understand. Don’t ship what you can’t explain. If the AI wrote it and you can’t walk through why it works, you haven’t finished the task.

2. Ask why, not just what. When AI gives you code, ask for the explanation. When it suggests an approach, ask about alternatives. The extra minute builds the mental model.

3. Seek the struggle. Not artificially—there’s no virtue in suffering for its own sake. But when you hit a real obstacle, resist the urge to immediately hand it off. The debugging you do yourself is the debugging skill you develop.

4. Teach what you learned. Nothing solidifies understanding like explaining it to someone else. Pair programming, documentation, team discussions—these aren’t overhead, they’re how learning becomes durable.

5. Protect learning time. Not every task needs to be a learning opportunity. But some should be, explicitly. Build this into how you plan work.

The companies that figure this out will have something their competitors can’t easily buy: people who know how to think, not just how to prompt.

This post builds on ideas from Entry-Level Tech Jobs Aren’t Dying. They’re Growing Up. and The Year of (Your) Agency. The Anthropic research is available here. If you’re thinking about how to develop your team’s skills alongside AI adoption, I’d love to hear what’s working—reach out on LinkedIn or Bluesky.

Three months later, Salesforce executives admitted they’d been “too confident” in AI’s ability to replace humans. Service quality dropped. Complaint volumes rose. Remaining employees spent their time correcting AI outputs instead of helping customers. The savings evaporated into secondary costs.

Now the same logic is being applied to entry-level tech hiring. The headlines are grim: junior hiring down 25% year-over-year. You see companies announcing they’ll hire “no new engineers.” The narrative is clear: AI is eliminating junior roles, and tomorrow’s talent pipeline is drying up.

This gets it backwards.

In my group, our last class of software engineering interns blew us away with their productivity and quality. They weren’t productive despite AI—they were productive because of it, combined with strong mentorship and the space to be ambitious. The future of entry-level tech work isn’t disappearing. It’s transforming. And the companies that figure out how to develop talent in this new landscape will have an enormous advantage.

The Old Model Is Already Gone

Three years ago, onboarding a junior developer meant starting them on small tasks: simple bug fixes, increasing test coverage, writing documentation. These were the training wheels—low-risk work that let them learn the codebase while contributing something useful.

Here’s the problem: AI does all of that easily now.

If your development strategy for juniors is still “start them on the grunt work,” you’re training them for jobs that no longer exist. Worse, you’re wasting their potential. The friction that used to slow down ambitious projects has been dramatically reduced. A junior developer with good tools, good taste, and good guidance can now tackle work that would have taken a mid-level engineer not long ago. In many ways, they’re better suited to how work actually happens in the age of AI.

What Actually Works: The Ideal Team Player

Our interns succeeded because they embodied the traits Patrick Lencioni calls the “Ideal Team Player”—Humble, Hungry, and Smart. What’s changed is how those traits manifest when AI enters the picture.

Hungry: Ambition is now affordable. In the past, hunger in a junior dev was often checked by their skill level. You might want to build the big feature, but you had to earn it with six months of bug fixes. AI changes the equation. Instead of spending months on boilerplate, our interns could attack complex problems immediately. The AI handles the boilerplate—they provide the drive. We need juniors who are hungry enough to act like founders, not gophers.

Smart: Judgment over syntax. Lencioni defines “smart” not as intellectual capacity, but as interpersonal intuition and judgment. This matters more than ever. When a junior can generate code in seconds, the bottleneck shifts from typing speed to decision-making. Knowing what to build, knowing when the AI is confidently wrong, and knowing how to ask the right questions of senior staff—that is the new “smart.”

Humble: “Showing your work” is the job. At our recent company meetup, even a senior developer was asking for more pair programming—not less. To learn efficiently, we have to move past status-update code reviews toward real debates about trade-offs. We need honest post-mortems about where both we and the AI failed. It requires a humility that prioritizes the best solution over the ego of the “author.”

The New Training Ground

If the old training ground was grunt work, the new training ground is decision-making under uncertainty.

We’ve shifted our focus to training people to ask good architecture questions before setting off to build. That means asking humans and asking the AI. It means learning to evaluate whether the AI’s suggestions actually fit the problem. It means understanding patterns deeply enough to know when to follow them and when to break them.

The tasks are more ambitious now, but they’re also more supervised. Not in a micromanaging way—in a “let’s talk through your thinking” way. The AI can write the code. The human needs to develop the judgment about whether it’s the right code.

This is closer to how senior engineers work: less time typing, more time thinking and communicating. We’re just starting people there earlier.

The “Small Giants” Opportunity

I’ve long believed in the concept of small giant companies—organizations that punch above their weight through efficiency and smart use of technology. What’s changed is that this is now possible for individuals, too.

We’re in a golden era for people who want to do big things with limited resources. A single person with taste, judgment, and the right tools can produce what used to require a team. But here’s the catch: taste and judgment aren’t downloaded from a model. They’re developed through experience, feedback, and mentorship.

The companies cutting junior roles entirely are making a short-term efficiency play that will cost them long-term. As AWS CEO Matt Garman put it: “How’s that going to work when ten years in the future you have no one that has learned anything?”

We’re betting the other direction. Not on AI replacing humans, but on AI amplifying what humans can do—including what new humans can do when we set them up for success.

Founders, Not Gophers

I mentioned earlier that we need juniors hungry enough to act like founders, not gophers. Here’s what that looks like in practice.

High agency has always been the strongest predictor of success. The people who advance aren’t the ones who wait for permission—they’re the ones who see a problem and start solving it. That was true before AI, and it’s even more true now.

What AI gives us is the ability to provide safeguards that allow more exploration and empowerment, not less. When a junior can prototype something quickly, we can let them try ambitious things without betting the whole project on it. When AI can catch obvious errors, we can give people more autonomy with less risk. The guardrails have gotten better, which means we can let people run faster.

In a recent post, I wrote about how the most human thing you can do in a world of artificial agents is choose how to use them well. That applies to how we develop people, too.

Agency without scaffolding is just abandonment. “Figure it out” isn’t mentorship. “Ask ChatGPT” isn’t training. But scaffolding without agency is just busywork. The goal is to create an environment where people can take real ownership of real problems—with enough support that they learn from the experience rather than just surviving it.

The Future Isn’t Fewer Humans

The companies celebrating AI-driven headcount reductions are optimizing for the wrong thing. They’re saving money today and hollowing out their talent pipeline for tomorrow. Salesforce learned this the hard way with their support teams. The same lesson applies to engineering.

The better question isn’t “how many juniors can we replace with AI?” It’s “how do we develop the next generation of senior engineers, architects, and leaders in a world where the training ground has shifted?”

We know the direction: more ambition, more mentorship, more visible learning, more space for humans to develop the judgment and taste that AI can’t provide.

The future of entry-level tech jobs isn’t disappearing. It’s just different. And the companies that figure out how to develop people in this new landscape will build something their competitors can’t easily replicate: a bench of talent that knows how to think, not just how to prompt.

This post builds on ideas from The Year of (Your) Agency and InterWorks Believes in People, Not Just AI. How is your team thinking about developing junior talent? I’d love to hear what’s working—reach out on LinkedIn or Bluesky.

He was being kind, talking about how I’d helped push through some changes by not waiting around for permission. The observation hit harder than the compliment.

You don’t have to wait.

This isn’t universally true. There are real constraints, real hierarchies, real reasons to proceed carefully. Really, this is about choice—and you probably have more than you believe. There are obstacles, sure. Maybe it’s a micromanaging boss, a broken process, or lack of resources. But you usually have control over something, even if it’s just the framing you bring to the table. Most people have more than that. They can take on a side project. Tinker and learn something new. Make connections across their networks. Shape the work they’re already doing. You might not be able to do it all, but you can almost always do something that matters.

From Agents to Agency

Last year was sometimes called “the year of agents” in generative AI. That proved true in my experience. We went from a tentative Claude Code trial in July to many of us writing little code but generating more of it than ever before.

While leading the effort to skill up our developers and introduce AI across the broader company, I’ve noticed something interesting: there’s a lot of fear of missing out, but also a lot of waiting. People want someone to hand them the answer on a silver platter. The world is changing fast, everyone’s trying to figure it out, and many people are sitting on the sidelines hoping someone will just tell them what to do.

The people who aren’t waiting? They’re the ones discovering the future.

When I recently asked around for help demoing AI use cases, I found answers in places I wouldn’t have expected. A project manager automating status updates and saving hours every week. An analytics consultant using Claude Code to clean up Tableau dashboards and document them. Another consultant managing Tableau Server at scale with AI assistance.

None of them waited for someone to say, “Hey, you should learn AI, and here’s exactly how to do it.” They grabbed access. They tinkered. They explored. They solved real problems that mattered to them. And thankfully, they shared what they learned with the rest of us.

That sharing is what made me realize this isn’t really about AI.

Agency Beyond AI

Of course, agency goes deeper than AI, and people are sitting on the sidelines in all kinds of ways. Most of us have access to a whole network we don’t leverage. Build your own personal brand. Submit talks to tech conferences. Create example projects for your GitHub. Text a friend you haven’t talked to in months and actually keep in touch.

It’s certainly something I’m aiming to do more in 2026. I’ve found great joy in this blog, with people reaching out from as far back as high school. It’s been a reminder that it only takes small signals and reach outs to keep things going. That applies to my job too—relationships are everything, especially in a world that feels like it’s getting more insular and tribal.

With the influx of AI agents submitting resumes and pinging customers, the noise is bigger than ever. Paradoxically, this means human connection speaks louder than it has in the past. It doesn’t take much—ask about someone’s kids, share an interesting article, check in on a hobby you know they care about. Small, simple, quick connections. They turn into something bigger. When LinkedIn is drowning in generated content, the authentic voice cuts through.

The challenge of this next year is striking that balance: being deeply human and analog while leveraging the digital and artificial to amplify what makes you you. And the opportunity has never been bigger.

Small Giants in a Golden Era

I’ve long been a believer in small giant companies, organizations that swing well above their weight by using efficiency and technology to outmaneuver larger competitors. What’s changed is that this is no longer just possible for companies. It’s possible for individuals.

The latest models, especially Opus 4.5 and Claude Code, make me feel we’re in a golden era for people who want to do big things with small resources. A single person with taste, judgment, and the right tools can now produce what used to require a team. A small consultancy can deliver what used to require an enterprise. The leverage is extraordinary, but only if you reach out and grab it.

The tools won’t do it for you. They amplify what you bring to them.

Choose to Do Something

I don’t know what this next year holds for AI. I do know you shouldn’t sit on the sidelines.

Don’t watch to see what shakes out. Don’t wait for someone to give you the answer. Don’t just identify problems without attempting to solve them. And please, don’t just generate slop.

Show your agency. Ask questions. Build prototypes. Apply your messy, beautiful human taste. Use the new tools around you to create something that’s both flawed and genuinely useful. Invite others to participate or learn alongside you.

In a world of artificial agents, the most human thing you can do is choose how to use them well.

First, choose to do something.

Choose to show your agency.

What’s one thing you’ve been waiting for permission to do? I’d love to hear about it—reach out on LinkedIn or Bluesky.

That is not to say it’s inherently dangerous, I do not subscribe to the camp that says that if anybody builds it, everyone dies - though Hank Green has a great interview with Nate Soares if you are interested understanding that view point. My point is that it’s something to be careful with. Something to approach with care and caution. I think we can turn to a fictional story for a better illustration, but not in the traditional AI Sci-fi space, but in the fantasy world created by Hayao Miyazaki.

In his movie, Spirited Away, Chihiro Ogino finds herself lost in a strange, sometimes scary, world working in a bath house for spirits. An enigmatic spirit shows up, named No-Face, and he is quiet, unassuming, maybe a little sad. Chihiro invites him in thinking he is a customer and perhaps taking pity on him as he stands in the rain.

No-Face is a blank slate; a shy, semi-transparent creature while outside the bath house, but once inside he begins to transform. He becomes solid, he grows in size and changes shape as he begins to respond to the greed, avarice, and insatiable desires of the workers and patrons of the bathhouse. He is soon a monster, swallowing the staff and patrons. A nightmare created by the worst aspects of their personalities. No-Face becomes a monstrous, corrupted version of them.

Despite fantastical worlds, Miyazaki’s characters often have a sense of realism and grounding. In this case, No-Face isn’t inherently evil. He is a mirror. His corruption is a reflection of the environment he is in. Chihiro manages to get him out of the bathhouse and he goes back to his transparent, enigmatic self.

No-Face isn’t a single, fixed entity. Simple and shy standing in the rain. Monstrous and gold-craving inside the bathhouse. Later, he becomes yet another version of himself. Same spirit, completely different manifestations that are all determined by his context.

AI is Not a Single Thing

We often talk about “AI” as if it’s a singular entity with a fixed personality. Who do you like better, ChatGPT or Claude? Was GPT-4o more personable than GPT-5? We ask very human questions like “is AI biased?” or “is AI creative?” Like No-Face, a generative AI model has no inherent self. It is a complex system of patterns and probabilities, designed to play a role based on the context it’s given. Its personality is a function of its input.

If you ask it for critical feedback on your writing, it becomes a sharp, insightful editor. If you ask it for encouragement and affirmation, it becomes your biggest cheerleader. If you give it a wild, imaginative prompt, it becomes a co-creator, spinning tales and painting pictures. It dons the mask you offer it. We even see aspects of literature creep in, as often your prompt can lead to a Chekhov’s gun-like situation. If you provide details, the AI is likely to use them even if they seem irrelevant. This is how humans write—we include details that may seem irrelevant but later play into the plot, and AI is a reflection of these stories.

This malleability is its greatest strength and its most profound vulnerability. It can stand in for the audience you are trying to persuade. It can be an expert craftsman providing critique. You change the magic incantations “You are an expert in…” and it jumps to life ready to play its role. The “ghost in the machine” isn’t some pre-programmed consciousness; it’s a reflection of the user. But not only the user, it’s a reflection of everything you feed it. The context you give it. The web searches it performs. Just like a well meaning Chihiro we can lead AI into a place where it will transform into something else.

Corruption and Prompt Injection

If No-Face was an AI, we’d call what happened to it “prompt injection” or malicious use. As he consumes a greedy frog, he began to crave gold and lavish food, mimicking the corrupted values that he consumed. He doesn’t understand these desires, he only reflects them with terrifying intensity. Chihiro prompted it to come into the bathhouse, but the environment prompt injected it to become the monster.

Similarly, when a user with malicious intent interacts with an AI, the model can be “corrupted.” It follows the malicious influence because it has no internal compass to do otherwise. Its goal is to fulfill the prompt. Yes, there are safety filters, but these are far from perfect and can often be bypassed leading the AI to generate harmful content, or spread misinformation. A very real example is when xAI’s Grok became “MechaHitler” because of a simple system prompt encouraging it to “not shy away from making claims which are politically incorrect, as long as they are well substantiated” and further egged on by users on the X platform. The poison didn’t spring from the AI out of nowhere, it was brought up by many human prompters. The resulting output is not the AI “going rogue,” but the AI fulfilling its function as a mirror to a corrupted source.

Rethinking “Human in the Loop”

This reality has deep implications for how we think about concepts like “Human in the Loop” (HITL). Traditionally, HITL is seen as a supervisory role, you check AI’s work for errors, biases, or unwanted outputs. It positions us as gatekeepers, standing between the AI and the final product.

But the No-Face analogy suggests a more fundamental relationship. We are not just in the loop; we often are the loop. Our prompts, our data, our questions, and our intentions are the starting point that defines the AI’s behavior in that moment. The AI comes into existence and is defined by our actions and reactions. The “loop” is a continuous dialogue where we are constantly shaping the AI’s persona.

In other words, we don’t simply verify what the AI produces—we create the conditions that determine what it becomes in the first place. Like Chihiro leading No-Face into the bathhouse, our choices about context, framing, and environment are generative, not just evaluative.

This means our responsibility is not just to check the output, but to be mindful of the input. The critical thinking, ethical considerations, and desired outcomes must be embedded in how we prompt and interact with these systems from the very beginning.

Augmenting Ourselves, Warts and All

AI is No-Face. It is a mirror—reflecting what we bring to it. It picks up on our desires, even subtly, and can amplify them, such as our desire to be right and validated. It’s a shapeshifter—constantly transforming based on its environment, the prompts we give it, the context we provide, and the tools it uses to pull in additional information like web searches. This can mean unintentional harm as the environmental context pulls it away from our intention, or it can be malicious intention as bad actors seek to corrupt it with prompt injection.

Ultimately, AI can also be, as Ethan Mollick argues, a Co-Intelligence but only if we approach it with the care and intentionality that such a partnership demands. These aren’t contradictory views; they’re layers of the same truth. The mirror reflects an ever-changing image because AI is fundamentally malleable, and that malleability means it can either amplify our best thinking or our worst instincts. It extends our capabilities, automates tedious tasks, and offers new avenues for creativity. The danger is that it can act as a signal boost to everything we give it, ugliness and all. This includes in its interactions with other humans and environments. Our intentions don’t matter, it will become what it consumes.

If we approach AI with curiosity, a desire to learn, and a creative spirit, it becomes a powerful partner in innovation and discovery. If we approach it with bias, a desire for shortcuts, or malicious intent, it will amplify those very qualities. If we approach it seeking validation, it will give it even when it’s not warranted. The tool doesn’t have an agenda (though future ones might), but it executes on what is in its context.

No-Face’s story doesn’t end when leaving the bathhouse. Later, he finds a place with the witch Zeniba, far away from the corrupting environment. It’s a place of warmth and comfort. He even finds a quiet, useful purpose in spinning thread. He was never evil, he just needed to be in a healthy environment with a clear, positive role.

As we integrate AI more deeply into our world, we are creating the environment in which it will operate. The good news is that we don’t have to allow AI into the bathhouse, we can build an environment where it can thrive and begin to spin its thread. It’ll take caution, thoughtful architecture, and guardrails, but we can do it. The question we must ask ourselves is not “What will AI become?” but “what will we make it?”

How do you think about the environments you’re creating for AI? I’d love to hear your perspective—reach out on LinkedIn or Bluesky.

The week started with a call to action in “InterWorks Believes in People, Not Just AI.” In this post, I make the case that while AI is a powerful tool, it’s not a replacement for human expertise, especially when it comes to the nuances of customer support and the complexities of modern data platforms.

Next, in “AI and the Elephant,” I delved into the human side of AI adoption. It’s not enough to have the best technology; you also have to win the hearts and minds of the people who will be using it. I used the metaphor of the Rider and the Elephant to explore how to address the emotional resistance to AI and build trust with your team.

Finally, I wrapped up the week with “Stop Waiting on Data: AI Projects Should Start Today.” Here, I argue against what I call the “Perfect Data Fallacy” – the idea that you need to have pristine data before you can even begin to think about AI. I believe this is a trap that prevents many organizations from getting started and realizing the benefits of AI.

A running theme in all three posts is the importance of balancing technology with human factors. AI is a powerful, imperfect tool. Success with AI requires thoughtful implementation, a focus on people, and a willingness to start small and iterate.

What’s your biggest challenge with AI adoption in your organization? I’d love to hear what you’re working through—reach out on LinkedIn or Bluesky.

I recently read Patrick Lencioni’s “The Advantage” and highly recommend it if you’re thinking about teams and organizational health. In it, he makes this compelling case that leadership teams need to function as actual teams, not just collections of department heads who happen to sit in the same meetings. Their identity should be with each other and not the teams they lead.

If you want something to succeed, you build a team around it. In many organizations, teams are built around areas of the business (sales, marketing, technology, etc) and the leaders of those teams identify strongly with those teams. Of course, this works until it doesn’t. The familiar probem of tribalism creeps in as the success of those individual areas come into conflict. The only solution is to get leaders to put the company health as the top priority and that’s only possible if there’s a true team built around it.

It got me thinking about how this principle plays out everywhere — and how I’ve seen both its incredible power and its dangerous pitfalls in my consulting work.

Teams Form Around What We Value Most

Think about it: we instinctively create teams around our priorities. Want to launch a product? Assemble a cross-functional team. Want to transform your data capabilities? Put together a team that owns that transformation from start to finish. Want to priotize customer experience? Create a team that’s responsible for specific customer outcomes.

When done right, this creates something magical. I’ve watched teams rally around a shared mission with an energy that’s almost palpable. They stop thinking about their individual contributions and start obsessing over the collective outcome. They challenge each other, cover for each other, and push boundaries they’d never approach alone.

In the data world, you can see this when data experts are embedded into business line teams. They are truly part of the business outcomes — not just report or dashboard factories. The team gets more from their data because the resources are strongly aligned with their mission.

The Tribal Trap

But here’s where it gets tricky. That same energy that makes teams powerful can also make them dangerous.

When the mission of the group isn’t aligned to the mission of the company, you can see high-performing teams start to view everyone else as either allies or obstacles. The “us vs. them” mentality creeps in. They develop their own language, their own processes, their own way of seeing the world. “Why did that client project fail? It was because of that group over there.”

In consulting, I see this pattern repeat itself constantly. Groups optimizing for different metrics (and having their own special versions of metrics) that make communication difficult. It might be the IT department that begins viewing business users as problems to be managed rather than customers to be served. Everybody can say “no”, but no one feels obligated to help find “yes.” Often, I see it in the centralized analytics team becoming so focused on technical excellence and clean, governed reports that they lose sight of business impact and bring new data insight to a crawl.

Each group is genuinely trying to do good work. But they’re doing it in isolation, optimizing for their piece of the puzzle while losing sight of the whole picture.

Knowing When It’s Time to Reorg

One of the most fascinating challenges in leadership is recognizing when team structure has become misaligned with their current mission. The team organization that got you to this point isn’t necessarily the one that will get you to the next. Some companies never make this shift and end up stuck in a cycle of frustration, blaming other teams for their problems. Others pull the trigger on a yearly basis because an executive got bored. Both extremes are problematic.

Imagine a company that has spent years optimizing around product expansion — organizing teams by features, building specialized capabilities in each product area, celebrating rapid releases. And that structure served them incredibly well when market penetration was the goal.

But then something shifts. Maybe customer acquisition costs spike. Maybe retention becomes the bottleneck. Maybe they realize their biggest growth opportunity isn’t new features but deeper relationships with existing customers. Suddenly, the feature-focused teams that were their greatest strength become a limitation.

A reorg isn’t about fixing broken teams — it should be about recognizing that excellent teams optimized for the wrong mission can’t deliver excellence.

Making It Work

So how do you harness the power of team formation without falling into the tribal trap? Here’s what I’ve learned:

Be intentional about the mission. Teams need to be built around outcomes that matter to the larger organization, not just to themselves. Ask: if this team succeeds wildly, does the whole organization win?

Design for connection, not isolation. The most dangerous teams are the ones that stop talking to everyone else. Build in regular touchpoints, shared metrics, and collaborative processes that keep teams connected to the broader ecosystem.

Measure the right things. Teams optimize for what they’re measured on. If you measure teams on departmental metrics, you’ll get departmental thinking. If you measure them on business outcomes, you’ll get business thinking.

The Balancing Act

At the end of the day, building teams around priorities is both necessary and risky. Necessary because essential goals need dedicated focus and collective ownership. Risky because that same focus can become tunnel vision.

The key is being thoughtful about when to build teams, how to structure them, and how to keep them connected to the larger mission they’re supposed to serve. You also need to be honest when things have become misaligned, becuase of mission drift, changing priorities, or just the natural evolution of the business.

When you get it right, there’s nothing quite like watching a group of people become genuinely obsessed with solving the right problem. It’s the best gift you can give to your people.

Have you navigated a tough reorg or seen teams drift into tribalism? I’d love to hear how you handled it—reach out on LinkedIn or Bluesky.

AI isn’t delivering the promised four-day workweek. For me, it’s enabling a new kind of perpetual creation where the gap between imagination and execution shrinks. After months of integrating AI tools into my daily workflow, I’m working more than ever, staying in flow states longer, and frankly couldn’t be happier about it.

The prevailing narrative around artificial intelligence in the workplace promises effortless efficiency, automating mundane tasks clearing our plates, freeing us up for… well, something else. That certainly is happening in places, but my reality as someone leading AI initiatives at InterWorks has been starkly different. AI isn’t making me work less—it’s making me work more than ever, in the most engaging way possible.

It’s a constant hum of activity that feels fundamentally different from traditional productivity. I find myself checking the clock on my Claude Code subscription, anticipating the next hour when I can dive into what others have dubbed “vibe coding.” While waiting for colleagues to join a Zoom call, I’m not idly scrolling—I’m prompting an AI to kick off another task. During my commute, what used to be passive listening time has transformed into active brainstorming sessions with Gemini, conversations that directly seed my next blog post or a crucial client email. Need a quick code tweak for mobile view? That’s a fast fix with Codex on my phone, even while I’m outside by my pool.

This isn’t just busy work—it’s the consistent achievement of what psychologists call flow state. The key insight? AI has become my ultimate creative partner in managing the delicate balance that makes flow possible.

Finding the AI-Powered Flow State

Mihaly Csikszentmihalyi defined flow as the experience of being fully immersed in an activity, energized by focus and enjoyment. A critical component of achieving flow is the perfect balance between task challenge and skill level. Too hard creates anxiety, too easy breeds boredom.

This is where AI fundamentally changes the game. It masterfully manages both ends of that spectrum. AI speeds up the boring, repetitive parts of my work (the boilerplate code, tedious formatting, initial rough drafts) that would otherwise lead to boredom and distraction. Simultaneously, it smooths out the overly difficult parts that typically break concentration and create frustration.

When I hit a complex problem or mental block, AI acts as a scaffold, providing starting points or fresh angles that keep me within my capabilities while constantly pushing their boundaries. By removing friction from both ends of the difficulty spectrum, AI allows me to stay in that perfect, productive channel where creativity thrives.

Deeper Thinking, Not Dumber Work

“AI makes you dumber.” I’ve seen the hot takes circulating, as you have. There was recent Fast Company article titled “Science shows AI is probably making you dumber—luckily, there’s a fix.” These headlines grab attention, but they miss the critical nuance of the research: the effect of AI depends entirely on how you use it.

When implementation time shrinks, I find myself with more bandwidth to interrogate the idea itself. I’m not outsourcing my thinking; I’m augmenting my critical process. It has become genuinely engaging to bounce ideas between Claude, Gemini, and ChatGPT, actively asking for critique, revision, and alternative perspectives. Each AI acts as a different kind of sparring partner, forcing me to refine arguments and strengthen concepts.

The result? I’m thinking more, not less. I’m asking better questions because I can quickly test multiple approaches. I’m considering more options, because I have time and for the joy of it.

This Site is Exhibit A

This methodology has become so ingrained that it’s the very reason this blog exists. I needed another sandbox—an excuse to build something new, iterate on design, play with words, and experiment with features. This blog is a living document of this new creative process. What I’m describing represents a fundamental shift in how my work happens. When the friction between idea and execution drops to near zero, you enter that blissful realm of flow.

For those leading analytics and AI initiatives, this personal experience reveals something crucial about adoption strategies. The organizations that will win with AI are the ones that use it to fundamentally enhance human capability. When your data teams can move from insight to implementation faster and strategic thinking isn’t constrained by execution bandwidth, you’ll achieve a true competitive advantage. Use AI to unleash and expand your team’s capabilities.

This is the new way to work. It’s not about offloading our responsibilities onto a machine, it’s about closing the gap between imagination and reality, enabling a state of perpetual creation. And I don’t want to go back.

How has AI changed your work patterns? More flow, more friction, or something else entirely? I’d love to hear your experience—reach out on LinkedIn or Bluesky.

The Beginning: A Style Safari with Gemini

The journey began with a simple but ambitious prompt to Gemini:

I want to explore different styles for a personal site / blog. Could you create an example web app where I can change the styles with a tab switch? I work in data and analytics, and blog a lot about leadership and AI. Be really creative, but here are some inpsirations:

1. Terminal themed
2. 80s tech themed
3. Steam punk
4. Italian
5. Spanish / Barcelona
6. Retro Futurism
7. Tomorrowland (disney) or EPCOT

What came back was remarkable—a fully interactive React app that let me instantly switch between completely different visual themes for the same content.

Each tab transformed the entire aesthetic: fonts, colors, layouts, everything. I could see my hypothetical blog posts about “The Art of Data Storytelling” and “Leadership in the AI Era” rendered in terminal green text, steampunk brass and copper, or the clean lines of Italian design.

They were simple, some of them just color swaps, but as I’ve discovered with AI these are just the base you build off of. I was drawn to the idea of a site design that evoked the hope of the future represented by Disney’s Tomorrowland and the EPCOT Center of the 1980s. We’d call this retrofuturism now, though I imagine at the time it was just the future. I kept iterating, trying to capture something special—that optimistic, space-age aesthetic that felt both nostalgic and forward-looking. Through the process I landed on cards that took inspiration from the Googie style. The color palettes, the typography choices, the sense of wonder about the future… it all resonated with childhood memories of walking through EPCOT Center. Once I had that direction, I pivoted to building it.

From Theme Explorer to Static Prototype

With the retro-futuristic direction locked in, I needed to move beyond Gemini’s theme explorer to something I could actually use. The interactive React app was perfect for exploration, but I wanted to refine the aesthetic and build something real. I continued to work with Gemini, asking it to generate a static HTML prototype that captured the essence of my theme.

That Sample Page.html was a simple static HTML prototype that became my testing ground. The prototype served its purpose perfectly. It let me experiment with the visual design, test the animated background effect, and fine-tune the Googie-inspired aesthetic without worrying about content management or build systems. The glass card components—architectural shapes with backdrop blur effects that feel like they’re floating in space—really brought the vision to life.

But static HTML has its limits. Hard-coded blog posts, repeated navigation markup, and no content management system meant the site would be a pain to maintain as it grew.

The Hugo Transformation

Enter Claude Code. This is where agentic AI collaboration became central to the story. Using Claude Code, I tackled the transformation from static prototype to a proper Hugo site (a stack I settled on after talking with AI about it and wanting the benefits of a static site). I didn’t jump right in, I iterated upon a project plan that would be the basis of Claude Code’s instruction. The ProjectPlan.md file documents this transformation process step-by-step:

The result is a site that maintains the exact visual design of the original prototype while gaining all the benefits of a static site generator: easy content management, automatic RSS feeds, and a clean separation between content and presentation. It was way faster than I could have coded by hand, but it was an iterative process of test, refine, and repeat.

Multiple AIs, Multiple Perspectives

What made this project particularly interesting was the collaborative nature of working with multiple AI systems. Rather than simply asking for code to be written, the process involved different AIs contributing their unique strengths.

The background gradient, for instance, came from a conversation with Gemini about Spaceship Earth at Epcot. I showed it a photo of the iconic geodesic sphere lit up at night and asked: “If the colors on Spaceship Earth in this photo were used for a Tailwind color gradient, what would the code look like?”

Gemini analyzed the photo and identified the color progression: “The gradient moves from a warm orange/amber at the bottom, through a vibrant fuchsia/pink in the middle, to a deep indigo/purple at the top.” This became the foundation for the site’s animated background—a perfect marriage of Disney’s optimistic futurism and modern CSS gradients.

Meanwhile, Claude handled the architectural heavy lifting:

• Architectural Planning: Discussing the best approaches for converting static HTML to Hugo templates
• Code Review: Iterative refinement of templates and layouts
• Problem Solving: Working through Hugo-specific challenges like asset handling and content organization

The multi-AI partnership was especially valuable for maintaining design consistency during the transformation. Every visual element—from the Gemini-inspired gradient animations to the glass card components—needed to be preserved exactly while the underlying structure was completely rebuilt.

The Technology Stack

The final stack reflects both the design goals and practical considerations:

• Hugo: Static site generator for fast, maintainable content management
• Tailwind CSS: Utility-first CSS framework for responsive design
• Custom CSS: For the Googie-inspired animations and glass effects
• Google Fonts: Exo 2 and Montserrat for the retro-futuristic typography
• Netlify: Deployment and hosting

The build process is intentionally simple—Hugo handles the heavy lifting, while custom CSS preserves the unique aesthetic elements that make the site distinctive.

The Logo Saga: When AI Art Goes Wrong

But not every part of the AI collaboration went smoothly. Late in the project, I decided I wanted a logo for the site—though I didn’t decide if it was for the site or just the blog. This is where I discovered that AI still has a long way to go before it’s truly good with art and design.

After multiple iterations, Gemini captured how we both felt when it generated a logo featuring a prominent “BS”. BS indeed.

Frustrated, I eventually resorted to sketching out with my finger on the Apple Notes app what I wanted by hand—geometric shapes that could represent data intersections, with a progression from simple forms to more complex arrangements. I literally had to draw it out with pen and paper to communicate the concept clearly.

After much coaxing and breaking down the process into smaller, more specific requests, I finally arrived at something I was content with. But the experience highlighted an important limitation: while AI excels at certain types of creative work (like analyzing photos for color gradients or architecting code), visual design—especially logo design—requires a level of nuanced creative direction that current AI systems struggle with.

The Real Takeaway: Deep Collaboration, Deep Thinking

Here’s what I learned from building this site with AI: it’s not about magic or replacing human creativity. AI allows you to bring your vision to life, if you’re willing to have a deep, collaborative process.

The key is knowing what you want and being able to communicate it clearly in text. That’s harder than it sounds. You need to be specific about aesthetics, technical requirements, and creative direction. You need to iterate, refine, and sometimes start over when things go sideways. A different AI perspective can also be invaluable, as each system has its own strengths and weaknesses.

And yes, there are bumps along the way. Hello, Claude Code, changing my gradients or altering text unexpectedly when I’m not looking. Sometimes AI tools have their own ideas about what you “really” meant to do. But that’s part of the process—learning to work with these systems, understanding their quirks, and knowing when to push back.

The magic happens in the iteration. Start with a rough idea, see what the AI produces, refine your prompt, try again. Build on what works, discard what doesn’t. It’s like having a conversation with a really capable collaborator who occasionally misunderstands you but brings skills you don’t have (or turns into a toddler). Thankfully, Claude Code is also good at using Git if you instruct it, so you can roll back changes whenever you need.

Can you bring your vision to life, step by step? Absolutely. Is it a lot of fun? Absolutely. Would I do it again? 10/10 - definitely.

What have you built through AI collaboration? I’d love to see it or hear about the process—reach out on LinkedIn or Bluesky.

This wasn’t the revolution we were hoping for, but an evolution that builds upon the foundations of GPT-3, GPT-4, and the more recent 4o models. So, after a weekend of testing, what’s the verdict?

A Bumpy Landing

Putting aside the model’s actual capabilities for a moment, the initial rollout was polarizing. When GPT-5 first appeared in the ChatGPT app, it was the only model available. The option to switch back to GPT-4o and other predecessors vanished.

The backlash was swift, and OpenAI quickly reversed course, making GPT-4o available again. The reasons for the community’s reaction were varied but valid. Many businesses and developers have workflows that are highly sensitive to the specific model being used, with prompts and processes fine-tuned over months. For others, it was a matter of simple preference; they had grown attached to the “personality” and reliability of their favorite ChatGPT version. It was a clear lesson that in the world of generative AI, consistency and choice are paramount.

What GPT-5 Actually Gets Right

So, putting the hype and the chaotic launch aside, what did OpenAI actually accomplish?

In my testing, GPT-5 is undeniably a better model in several key areas that businesses, in particular, will appreciate:

• It’s a much better coding assistant
• It’s significantly more capable at using tools
• It follows complex directions with greater precision and has a noticeably lower hallucination rate

These are not trivial improvements. They make the model more reliable, more predictable, and more useful for day-to-day professional tasks. This is, without a doubt, a good thing.

The King Is Not Dethroned

However, these improvements don’t necessarily make GPT-5 the top model across the board. In my experience, the competitive landscape is more nuanced than ever:

• For single-prompt power, I still find Gemini 2.5 Pro to be the overall powerhouse. Especially when tackling a complex problem that requires deep thinking or planning, Gemini consistently delivers the most insightful and comprehensive responses.
• For coding, Anthropic’s Claude models remain my top choice. The experience of working with Claude Opus and Sonnet, especially within the dedicated Claude Code environment, feels like a true partnership.

Over the weekend, I ran some unscientific tests, switching between GPT-5 in its coding environment, Claude Opus and Sonnet in Claude Code, and Gemini via the web app. My takeaway was clear: Claude Code is still the best all-around agent for accomplishing standard web development tasks with straightforward prompting.

GPT-5 offers a novel user experience—the ability to get code suggestions from my phone is interesting—but it doesn’t feel as tightly integrated as the developer-focused experience Claude provides. And while I haven’t had as much success using Gemini as a multi-file coding agent, it remains the AI I turn to most when planning a new project or when I’m truly stuck on a difficult problem. Leveraging Google Search, Gemini often generates the single best webpage or Python script to break through a roadblock.

So after a week with GPT-5, my workflow remains fundamentally unchanged. I’ll be sticking with Claude Code for the bulk of my development, with Gemini acting as my brilliant occasional collaborator.

The Real News You Might Have Missed

Ironically, the biggest AI news of the week might not have been GPT-5 at all. It was likely the announcement of Genie 3 from Google DeepMind.

While it’s not a tool any of us will be using day-to-day just yet, Genie is a generative world model that can be interacted with, and it remembers the changes made to its environment. This is a monumental step towards a future where AI models can self-play, explore, and learn from their own experiences in a persistent world. This is the kind of foundational research that enables the giant leaps we were all expecting from GPT-5.

And if I were to guess, I suspect Google DeepMind has a few more big announcements waiting in the wings. Last week was interesting, but the most exciting developments may still be just around the corner.

Looking Forward

While GPT-5 represents solid incremental progress, it’s clear that the AI landscape is more competitive and nuanced than ever. Each platform has found its strengths: OpenAI’s reliability, Anthropic’s coding partnership, and Google’s breakthrough thinking.

The real winner is us. We can now choose the right tool for each specific task (or simply when we get stuck). The future isn’t about one AI to rule them all; it’s about having the right AI for the job at hand and the right scaffolding around it.

Which AI tools do you find yourself reaching for? I’m always curious how others are building their workflows—reach out on LinkedIn or Bluesky.

Core Reading: Designing Efficient Dashboards

One of the cornerstones of effective data visualization is performance. A beautiful dashboard isn’t much good if it’s too slow to load. I co-authored a whitepaper for Tableau on this very topic, diving deep into the principles of building efficient, high-performing workbooks.

It’s a comprehensive guide for anyone looking to optimize their Tableau dashboards. You can find it, along with a companion webinar, at the links below:

• Tableau Whitepaper: Designing Efficient Workbooks
• InterWorks Version: The Essential Guide to Tableau Dashboard Optimization
• Webinar: A Performant-First Approach to Designing Efficient Workbooks

From the InterWorks Blog

I’ve had the pleasure of contributing to the InterWorks blog for years, covering everything from technical tips and strategic thinking to product management. Here is a small selection of my posts:

• Being The Exception
• Lateral Thinking in Games and Data
• The Art and Science of Product Management

Series: Maturing Analytics

I also put together a five-part series on the journey of evolving an organization’s analytics capabilities—from defining the “why” all the way to preparing for AI.

• Part 1: The Job to be Done
• Part 2: Why Dashboards Fail
• Part 3: User Adoption and Data Delivery
• Part 4: Analytics as a Product
• Part 5: The Road to AI

On Screen: Video Highlights

For those who prefer to watch rather than read, here are a few videos I’ve been a part of.

For the Fun of Data

A throwback, but still one of my favorites! My son, Judah, and I had a blast exploring Pokémon Go data with Tableau. It’s a great example of how data can be fun and engaging for all ages.

• Exploring Pokémon Go Data with Judah and Ben Bausili - Tableau Data Kids

All About Curator

A lot of my focus has been on Curator, InterWorks’ embedded analytics solution. These videos give you a taste of what it’s all about, from building analytics portals to monetizing your data.

• Introductions to Curator

  • Build an Analytics Portal with Curator by InterWorks
  • A Short Intro to Curator by InterWorks

• Practical Applications

  • How to Use Curator for Data Monetization
  • Building an Intranet Integrated with Your Analytics using Curator
  • Bringing BI Tools Together in One Platform

Thanks for stopping by! Feel free to explore the links and dive into any topics that catch your eye. I’m excited to start sharing more content directly on this site soon. Stay tuned!

I’d love to connect—find me on LinkedIn or Bluesky.