본문 바로가기
Post · 2026.08.24

From using AI well to redesigning how we work

This page is a translation of the Korean original. Read the Korean original →

Using AI well is no longer something to boast about — it’s fast becoming table stakes. What matters now, I’ve been thinking, is increasingly the ability to redesign systems, organizations, and the way we work.

This morning my computer was unusually sluggish, and when I checked why, I found way too many things running in the background — auto-briefings, scripts, all the stuff I’d set up. It’s almost funny: the very things I built to get AI to do work for me were the reason I was irritated by the slowness first thing in the morning. (No secret that a Mac Mini is slow.)

Honestly, the rules I’ve built up lately aren’t holding. I kept stacking up “do it this way when this happens” rules one at a time, and at some point there were just too many. So things get skipped. Or handled sloppily. Things get declared “done” without actually being done. If a person did this, we’d call it slacking off.

Apparently I’m not the only one going through this. I recently noticed the unlazy (https://lnkd.in/g_QyBttT) skill on GitHub — as the name suggests, it’s a tool for stopping AI agents from being lazy. The core idea is something called a Depth Tree: you break one task into multiple layers, and give each small leaf task the same time budget as the whole task. It already has over 800 stars.

What caught my eye, though, wasn’t the methodology so much as the version notes for this skill. v1 told the model to “try harder.” v2 doesn’t ask — it enforces. Completion criteria live in a file, verification is actually run via commands, and the model is blocked from declaring “done” without evidence. It turned a request into a design.

What I’d been doing until now was exactly v1. When it wasn’t followed, I’d write the instruction more forcefully; when that still didn’t work, I’d tack on one more clause….

Sorting through this, here’s where my thinking has landed lately:

First, from a work standpoint, people are a kind of agent too. So the real question isn’t “should we use AI” but “which work do we hand to AI, and which do we leave with people.” It’s not a tool-selection problem — it’s a problem of dividing and allocating work, and that falls squarely within the broader domain of organizational design.

Second, managing AI isn’t like managing people. When you manage a workforce, a manager puts a lot of effort into understanding what motivates each person and what training will build their capability, all to raise productivity. But motivation doesn’t work on AI. Instead, you have to design the work around what the AI is good at, where it breaks down, and how it tends to fail. Assigning work to AI the way you manage people usually doesn’t produce the results you expect.

Third, what to leave behind, and in what form, is itself a design question. Whether it’s chat, email, or a direct conversation, if you just leave it as is, it’s gone by next week. This isn’t a question of individual diligence — it becomes a rule and a design problem the team has to decide on. Handled well, it becomes a long-term organizational asset, and it’s central to collaborating with AI or delegating independent work to it.

Fourth, you need to decide up front where a human will make the call. If you start from the premise that you don’t trust AI 100%, only one question remains: at what point does a person review it, and on what basis do they let it pass. Without that, automation can churn out wrong answers quickly and at scale, leading not just to side effects but to work that ultimately demands a huge amount of human effort.

Last, human understanding itself can become the biggest bottleneck. Every time I get AI to do something, so much happens in such a short window that just reviewing the reasoning and logic behind it takes an enormous amount of my time. Over the course of a week, the reports or decisions AI produces can amount to a book’s worth of material, or more. I’ve tried to cut this down, but it isn’t easy, and I’ve come to think this, too, is ultimately a design problem.

Working through all this, it comes back to me in the end. Adding one more rule is, honestly, the easy choice — it feels like you’ve done something about it. But adding a rule on top of rules that already aren’t being followed just leaves you with two rules that aren’t followed.

I saw a similar picture running organizations spread across multiple countries. It feels like déjà vu. The thicker the rulebook gets, the less anyone reads it to the end, and people end up working their own way regardless. What was needed then wasn’t more clauses but three things: removing rules that weren’t being followed, making the things that must be followed visible, and moving the point where a person or system checks the work.

So this week, I’m going to start by rebooting my harness. If anyone has wrestled with something similar, I’d appreciate any approach or resource worth looking at.

#AIAgents #AILeadership #OrganizationalDesign #ClaudeCode #AgenticAI

Tips on this topic

Tips →

More on this topic

Continue the conversation on LinkedIn →