Keep, Compress, or Drop: What Steps Still Matter When AI Speeds Up the Work

A few months into building agents with Claude, I caught myself falling back into my old way of working.

I come from service design and product work, so I have a way I'm used to working. Frame the problem. Explore the options. Design the experience. Produce something solid at each step before moving to the next one.

When I started building things like Kinetiv Copilot and our AI Opportunity Assessment, I brought those same instincts with me.

Then I started noticing how much of the work Claude had already done while I was trying to preserve the process around it.

It wasn't skipping the thinking. It was doing a lot of the in-between work that used to take me much longer: taking an idea, helping frame the problem, designing the experience, recommending an architecture, and turning it into a workable plan.

I was still looking for some of the handoffs I was used to managing myself.

Figuring out where I still add value

I've since built agents and skills to help with different parts of that process. I don't use them blindly, and I don't use all of them every time. But they've changed where I spend my time.

I'm most involved where my judgment and steering have the biggest effect on what gets built. What problem are we actually solving? What should the experience be? Does the proposed approach make sense? Are we still headed toward the thing we intended to build?

I'm much less attached to doing all of the work between those decisions myself.

The artifact I probably hold onto most tightly is the work plan. We track the work in Jira and in our file-based context system. It gives me a direct line of sight into what we're building, what we've completed, what comes next, and whether the work is drifting.

That distinction has become increasingly important to me.

I don't need to control every step of the process. I do want enough visibility to exercise judgment over where the work is going.

That's also why I'm not ready to hand everything over to agents orchestrating other agents and running largely unattended.

Maybe I'll get there. But if I'm no longer in the execution driver's seat, I need another way to know the work is staying aligned to the scope and intent. Otherwise, the speed advantage can disappear pretty quickly into backtracking and rework.

Right now, documenting the work as we go, maintaining that line of sight, and adapting the plan together with AI feels like the right balance.

The old planning instincts are harder to let go

I see the opposite tension too.

There's an understandable instinct to want the speed of AI while keeping all of the planning and control mechanisms we developed when building things was slower and more expensive.

Understand what the technology can do before you start. Get the requirements right. Build the plan. Move through the gates. Limit changes once development begins.

Those habits existed for a reason. When putting something in front of users required significant time and money, getting more certainty up front could save a lot of expensive rework later.

AI changes the equation.

If you can put a working prototype in front of users in hours, you don't have to answer every question before you start building. Some of the questions are easier to answer once people can actually use something.

That doesn't make planning irrelevant. It changes how much planning you need before learning from the real thing.

The management layer is catching up to the building layer

You can see a similar tension playing out across the AI industry.

Microsoft says its own IT organization now has visibility into more than 500,000 agents through Agent 365. Its advice is telling: establish the governance rhythm before the number of agents grows faster than your ability to manage them.

Anthropic's 2026 State of AI Agents report makes a related point. Agents are moving from experimentation into production quickly, and the question is increasingly how organizations deploy and operate them at scale.

Anthropic's research on agent autonomy adds another useful point. More experienced users tend to give agents greater autonomy, but they also shift toward monitoring the work and intervening when needed. The goal isn't necessarily to approve every action. It's to retain enough visibility to know when to step in.

That feels a lot closer to what I'm working through myself.

AI is making more of the work compressible. That doesn't mean every part of the old way of working becomes unnecessary.

I'm starting to look at each step and ask what it was actually doing for me:

  • If it carries judgment or helps keep the work aligned with the intent, I'm likely to keep it.

  • If it's labor AI can do well in a fraction of the time, I'm increasingly willing to compress it.

  • And if it mostly exists because that's how I've always maintained control, it may be time to let it go.

Keep, compress, or drop.

That's becoming a more useful question for me than trying to decide whether the old way or the AI way is right.

Sources

Previous
Previous

Agents that Design Agents: Start with the Idea

Next
Next

Where Does AI Pay Off? We Built a Free Tool for the Answer.