We’d just wrapped up jazz lessons, grabbed pizza, and wandered into a game shop. One of those afternoons where the conversation flows easy and everywhere. My kid and I were just talking, the way you do when you’re full of pizza and browsing shelves with no agenda.

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.

Someone told me recently that “Claude.md is the ontology for AI-assisted coding.” It was meant as a compliment to the practice of writing comprehensive context files for coding agents. But it made me think about ontologies. And then about semantic layers. And then about every other time the industry convinced itself that one big abstraction layer would tame complexity.

It never works. Not the way we hope.

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.

I was on the phone with my boss last week. He mentioned it’d be nice if a certain tool existed. Simple idea, clear use case. Before the call was even over, I had a terminal window open with a Claude Code agent building a prototype.

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.

If you’ve spent any time reading about technology adoption, you’ve probably heard the story of steam and electricity. Edison built the first commercial generating station in 1882. Electric motors could drive factory machinery. But decades later, most factories still looked the same. The punchline usually lands on the timeline: it took 30-40 years for electricity to produce meaningful productivity gains. The lesson, as typically told, is about patience. Transformative technology takes time. Don’t expect instant results.

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.

A lot of organizations have been relying on slow work to stay coordinated.

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.

Dan Shapiro recently proposed a five-level model for AI-assisted programming that’s been rattling around in my head since I read it (hat tip to Simon Willison for amplifying it). It’s useful partly because it’s a good model, and partly because I think it applies to far more than just writing code.

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.

Anthropic just published a randomized controlled trial studying how AI assistance affects skill development in software engineers. The headline finding: participants using AI scored 17% lower on a mastery quiz than those who coded by hand—nearly two letter grades.

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.

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.

Last September, I wrote about betting on people over pure AI automation while Salesforce celebrated cutting thousands of support staff. The thesis was simple: human expertise isn’t a cost center to optimize away. It’s a competitive advantage.

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.